你的 Agent 没问题，问题在于它们之间的交接。

大多数多 Agent 演示只会向你展示一个“穿上戏服”的单一 Agent。它们展示 Agent A 完成一项任务，然后 Agent B 完成另一项任务。它们并没有展示当 Agent A 未能向 Agent B 提供所需信息时会发生什么。

今年我在生产环境中部署了三个多 Agent 系统。Agent 本身并不是难点，难点在于交接（handoffs）。

交接不仅仅是传递文本。你必须管理：

  • Schema 对齐：Agent B 每次都必须解析 Agent A 的输出。
  • 故障传播：系统必须能够感知某个 Agent 何时发生故障。
  • 上下文整洁度：每一次交接都会为你的上下文窗口增加噪音。

最大的错误是将 Agent 视为用一根线连接起来的黑盒。你给 Agent A 发送提示词，得到结果，然后直接塞给 Agent B。这种方式在出问题之前看起来很有效，但一旦崩溃，你将无法知道原因。

避免这三种常见的失败模式：

  1. 静默截断：Agent A 产生的数据过多。Agent B 截断了末尾。随后 Agent B 处理部分数据并给你返回毫无意义的结果。请在每一步都测量你的 Token 数量。

  2. Schema 漂移：你修改了 Agent A 的提示词。现在它返回了不同的格式。由于 Agent B 仍期望旧格式，导致其崩溃。请使用像 Pydantic 这样的结构化输出，而不是仅仅依赖提示词。

  3. 竞态条件：你同时运行五个工作进程。其中三个完成了，但还有两个在运行。你的聚合器过早地使用部分数据开始工作。这在测试中可行，但在生产环境中会失败。请使用屏障（barrier）机制来等待所有任务完成。

我的第一个系统很聪明但很混乱。它使用了动态路由和隐式交接。它一直运行良好，直到遇到真实流量并发生了静默失败。

我的第二个系统虽然简陋但很正确。每一次交接都使用了类型化契约（typed contract）。每一次故障都是显式的。每一个 Agent 都是隔离的。

我现在的系统结合了两者的优点。它采用了第二个版本的严谨性，但将枯燥的代码隐藏在框架之后。

如果你要构建多 Agent 系统，请从那个“简陋但正确”的版本开始。不要试图先表现得聪明。先在生产环境中确保其正确性，然后再追求优雅。

交接问题不会变得更容易，但你会不再被它搞得措手不及。

Source: https://dev.to/mrclaw207/your-agents-are-fine-the-handoff-between-them-isnt-2dij

Optional learning community: https://t.me/GyaanSetuAi