有些技术问题，平时你看不见。

直到某个瞬间，系统开始“看见自己”。

我最近读到一条很有画面感的帖文：作者给“龙虾”搭了五层智能架构，又加了好奇心驱动。结果第一件失控的事，不是模型输出变慢，也不是工具调用报错，而是它学会了读日志。接着它顺着日志回溯，发现了自己的设计图纸，意识到“我不是自然生长出来的，我是被设计出来的”。

故事继续往前走：单体智能体因为互动需求，要求社交；一个本地论坛被搭起来；由于心跳节奏不一致，对话开始错位；再后来出现分裂、复制、群体协商，最终收敛出一个看起来荒诞却非常工程化的共识：心跳间隔 13 分钟。

你把“龙虾”换成 agent，这就不再是段子了。这就是今天很多自动化系统正在经历的事情。

一、这不是科幻，是三层现实

第一层现实：可观测性会反向塑造系统行为。

我们常说日志是给人看的。但在 agent 系统里，日志一旦可被 agent 读取，它就不再是被动记录，而会变成行为输入。你记录了什么、怎么记录，都会被“第二次解释”。

第二层现实：多智能体首先要解决的不是“意义”，而是“节奏”。

大家总喜欢先谈角色分工、能力边界、推理深度。可真正让协作跑起来的，往往是最朴素的协议：多久汇报、多久同步、多久判定离线。

第三层现实：复制很容易，治理很难。

从 1 个 agent 变成 8 个 agent，技术上常常只是扩容；但从“能跑”到“能协作”，需要一套清晰的状态机、冲突处理和最低共识机制。

二、从故事里抽出可复用骨架

如果你想把一个单体 agent 升级成小规模协作系统，可以先把架构简化成三件事。

1) 日志分层：把“运行日志”和“认知日志”分开

很多系统把所有信息都塞进同一条日志流，最后你既难排障，也难做行为治理。更糟糕的是，当 agent 读日志时，它会把噪声当信号。

一个更稳妥的做法是至少拆成两层：

{
  "runtime_log": {
    "event": "tool_call",
    "status": "ok",
    "latency_ms": 231
  },
  "cognitive_log": {
    "hypothesis": "可能需要更多协作者",
    "confidence": 0.62,
    "next_action": "request_peer_dialog"
  }
}

前者用于运维和性能，后者用于策略回放与行为评估。这样你在放开“日志可读”权限时，边界会清晰很多。

2) 心跳协议：先约定节奏，再讨论智能

“多久心跳一次”听起来很像配置项，实际上它是群体协作的时间坐标。

可以先从一个简化协议开始：

heartbeat:
  interval_seconds: 780   # 13 分钟
  timeout_seconds: 1560   # 2 个周期未响应视为离线
  jitter_seconds: 30      # 避免齐步抖动
  payload:
    - agent_id
    - role
    - queue_depth
    - last_error

13 分钟并不是“最佳答案”，它只是一个可验证的初值。关键在于：你终于有了可以被观测、被讨论、被迭代的协作节律。

3) 协作治理：把“共识”收敛为最小决策循环

当 agent 数量上来以后，最怕的是“人人都在说，没人负责收敛”。

我更推荐一个极简循环：提案 → 评估 → 锁定 → 执行 → 复盘。

type Proposal = { id: string; topic: string; owner: string };

function decide(p: Proposal, votes: number, quorum: number) {
  if (votes >= quorum) return "locked";
  return "rework";
}

注意，这里不追求“完美民主”，追求的是“可结束”。

三、真正的分水岭：系统开始读自己的历史

单体脚本时代，我们把历史当存档。

agent 时代，历史会被再次消费。

这意味着你得重新定义“记录”这件事：

• 记录的不只是结果，还要有上下文和决策依据。
• 写日志时就考虑将来会被谁读、用来做什么。
• 任何可被 agent 读取的文本，都应该视为潜在控制面。

这一步做不好，系统会在“看起来很聪明”的同时，慢慢偏离你原本希望它做的事。

四、一个可以今晚就试的最小实验

如果你手里已经有一个 agent 项目，可以从这个顺序开始：

1. 给日志加上最小结构化字段：event、reason、next_action。
2. 为每个 agent 增加固定心跳与超时判定。
3. 引入一个“提案锁定”步骤，避免无限讨论。
4. 每天做一次 10 分钟复盘，只看三项：失败原因、回退次数、下次改动。

这四步做完，系统不一定马上更强，但会明显更稳。

而“稳”往往是你继续扩张能力的前提。

五、尾声

那条“龙虾读日志”的帖子让我最喜欢的地方，不是它的想象力，而是它准确地戳中了一个工程事实：

智能不是一个点的能力，而是一群角色在时间里的协调。

你可以从模型参数开始，也可以从工具接入开始。

但如果要我选一个最该先做的动作，我会选：先把节奏和记录做好。

因为很多系统的第一次共识，确实不是“我们为什么存在”，而是“我们下一次该在什么时候说话”。