多 Agent 系统调试：为什么「跑通了」不等于「对了」

当 Agent 系统从单链原型演进到多 Agent 生产流水线时，一种新的失败模式变得常见：Agent 在技术上执行了指令，但结果仍然是错的。调试单个 LLM 调用很简单——看看 Prompt，看看响应，完事。调试多 Agent 系统则完全是另一个问题——一个请求在经过 4-5 个 Agent 转交后可能因为以下原因失败：

• 选错了工具（但工具调用本身是成功的）
• 检索到的上下文准确但已过期
• 一个 Agent 写入了某个 memory scope，另一个 Agent 之后因为无关原因从中读取了数据
• 最终输出看起来没问题，但产生它的推理路径不对

核心问题：大多数追踪工具只记录「发生了什么」，而不是「为什么」。一条显示"Agent B 调用了工具 X，参数如下"的追踪记录只告诉你调用发生了。它不会告诉你 Agent B 为什么决定调用工具 X、它当时认为什么是真的、或者那个上下文是否仍然有效。

真正有用的做法：

• 用意图标记内存事件，而不仅仅是内容——记录为什么发生了一次写入，而不仅仅是写了什么
• 让每一步都可以独立回放——你应该能够从任意节点分叉一次运行，只重新执行那个片段
• 区分「工具调用成功了」和「工具调用是对的」——这两者在大多数日志方案中被混为一谈，而真正影响调试的是第二个

我们在构建 Cartha（一个面向 AI Agent 集群的治理和可观测性层）时遇到了这个问题，它改变了我们对追踪的思考方式——把 memory scope 和决策理由当作一等公民、可查询的数据，而不是埋在某行日志里的东西。

很好奇其他人是怎么处理这个问题的——是在做自定义插桩，还是依赖 LangSmith/Langfuse 并接受其中的差距？