多智能体协作的坑：Bug在第二步，你却在第五步才发现
最典型的剧本是这样的：Agent A 把任务传给 Agent B → B 调用工具 → 结果传回 A → A 根据结果做了个决定 → 过了三步之后，最终输出的结果错得离谱。
这时候最绝望的来了：你盯着第五步的错误结果发呆，然后得像个侦探一样，手动翻几千行日志，回溯到第二步，才发现其实是 Agent A 在移交给 B 的那一刻，传的东西就走样了。
这种“静默失败”简直是多智能体架构的隐形成本。
为什么移交环节总是悄悄崩掉？
单链条模式下，状态是线性的。但多Agent模式下，状态往往是“隐式”的。
你在日志里看到 A 说：“我已经把正确的信息发过去了。”
接着看到 B 说：“我收到了一个看起来还行的数据。”
单独看，两个 Agent 表现得都像个模范员工。但问题就出在 A 的“意图”和 B 的“实际接收”之间那个真空地带。如果你的日志只记录每个 Agent 的输入输出，这个缺口永远被掩盖，直到最后一步崩盘。
几个实操层面的避坑指南
在公司里为了不被产品经理催死，我总结了几个能快速定位问题的野路子，建议直接照搬：
一、把“移交”当成一级事件来记录
别只写 Agent A finished 或 Agent B started。这种日志在排查时毫无意义。你应该记录：
- 为什么决定移交（决策链路）
- 传输的真实 Payload（原始数据）
- 接收方被告知了什么
- 接收方的权限范围（比如 B 是否真的能访问 A 认为它能访问的内存空间）
二、停止盲目全量重跑
很多同事习惯于修改一个提示词后重新跑一遍整个图。这不仅慢，而且如果你的 Agent 涉及发邮件、改 Jira 单子等有副作用的操作，重跑一次可能会给客户发十封重复邮件。
最高效的方法是实现“节点跳转检查”，直接跳到出错的那个移交节点，检查当时的 State 镜像。
三、在边界处做快照比对（低成本预警）
我尝试过一个方案，在 Agent 边界强制做 Snapshot：
- 发送方快照：A 发出时的状态
- 接收方快照：B 在执行第一个 LLM 调用前，绑定到工作状态的数据
- 对比 Diff
如果这两者不一致，Bug 在第二步就会被揪出来，而不是等到第五步。
给个具体的配置思路
如果你在写自定义的 State 检查逻辑，可以参考这个简单的伪代码逻辑，在 Agent 切换的拦截器里加一段：
def handoff_interceptor(sender_state, receiver_state):
# 强制校验关键字段是否在传输中丢失或变形
critical_keys = ["user_id", "task_context", "session_id"]
for key in critical_keys:
if sender_state.get(key) != receiver_state.get(key):
# 触发警告，直接在日志中高亮，而不是等结果出错
print(f"[CRITICAL_DIVERGENCE] Key {key} changed during handoff!")
print(f"Sender: {sender_state.get(key)} | Receiver: {receiver_state.get(key)}")总结一下
现在的所谓“AI 可观测性”工具，大多在关注 LLM 的 Token 消耗或单次调用耗时，这对于单链条有用，但对于复杂的多智能体系统来说太浅了。
真正的痛点在于：谁在什么时候看到了什么内存？谁在移交时把信息搞丢了？
如果你也在折腾 AI Agent 工作流，记住一句话：记录移交过程，比记录 Agent 本身重要得多。
