pranav-afk

单代理调试基本已成定局：看 prompt、看工具调用、看输出。

多代理图则不同。持续困扰团队的模式是：

  1. Agent A 把任务移交给 Agent B
  2. B 调用工具
  3. 结果返回给 A
  4. A 据此做出决策
  5. 三步之后，最终答案明显出错

故障通常不在第 5 步。错误发生在移交（第 2 步）。等到你盯着最终输出时，只能手动从日志中重建调用链。

这就是多代理调试的代价。

为什么移交会静默失效

在单条链路中，一个组件负责维护状态。

在多代理运行中，状态通常是隐式的：

  • A 记录：“我传对了。”
  • B 记录：“我收到的东西看起来合理。”
  • 两者在各自视角下都“正确”。
  • A 意图传递的内容与B 实际操作的内容之间的差距，正是静默失败的藏身之处。

如果你只记录每个代理自身的输出，那段差距永远不会显现。

三个在完美工具出现前就能帮忙的做法

1. 把移交视为一等事件

记录的内容应多于“Agent A 完成”/“Agent B 开始”：

  • 决定移交的原因（why）
  • 传输中的有效负载（payload）
  • 接收方被告知了什么
  • 接收方能够访问什么（工具、内存范围、权限）

最后一条很重要。有效负载可能匹配，但权限仍可能不同（B 无法读取 A 以为它可以读取的内存）。

2. 优先单步检查而非完整重跑

当工具存在副作用（已发送邮件、已更新工单、已转移资金）时，重跑整个图既慢又危险。

你首先需要的是：直接跳到移交步骤，在那里检查状态。

3. 低成本地尽早发现差异

一个实用模式：在边界处做快照。

  • 发送方快照：A 放在传输线上的内容
  • 接收方快照：B 在首次工具/LLM 调用之前绑定的工作状态
  • 对比两者

如果存在差异，你会在第 2 步就捕获到，而不是第 5 步。比完整回放更省：只需对比快照，无需重新执行图。

从节点分叉（在该状态下测试不同的工具/策略，而无需重放上游）是恢复的另一半。检测才是大多数团队从未构建的那一半。

这对“代理可观测性”意味着什么

通用的“展示 LLM span”对单条链路有帮助。

多代理系统需要边界感知的运维：

  • 跨代理的嵌套/链接运行
  • 决策时可见的内存
  • 被授权的工具
  • 按逻辑任务汇总的成本和重试

这就是我们正通过 Cartha 构建的方向（SDK 优先：trace、作用域内存、预算、多代理嵌套）。我们仍处于早期阶段，尚未实现完整的从节点分叉和自动移交差异探测——对此我们保持诚实。

如果你只能记住一个想法：记录移交，而不只是记录代理本身。

给你提几个问题

如果你正在运行多代理图（LangGraph 或其他）：

  1. 你是将移交记录为一等事件，还是仅记录每个代理的 I/O？
  2. 当你“重放”时，是完整重跑还是单步检查？
  3. 你是否构建过任何检查：发送方有效负载 == 接收方解释后的状态？

欢迎分享你在生产环境中有效（或失败）的经验。

文档 / 试用：cartha.in/how-to-use