多 Agent 的代价
成本倍增、信息丢失、责任不清与调试困难。
一句话理解：每多一个 Agent，就多一份 Token 账单、一次信息压缩、一个责任接口和一段需要追踪的调用链；只有收益明确大于这四项代价时，多 Agent 才值得。
多 Agent 方案在演示时通常很惊艳：几个 Agent 各司其职，屏幕上同时滚动着多条进度。问题往往在上线后才暴露：账单比预估高出几倍；汇总报告里出现了没有任何子 Agent 真正查到过的“事实”；用户投诉结论错误，团队花了一下午才弄清楚是哪个 Agent 在哪一步出的错。
前几课讲了多 Agent 能带来什么，这一课专门清点代价。它的作用是帮你在方案评审时问出正确的问题，并在确实采用多 Agent 时提前准备好对策。
图 1 先把四项代价放在一起：
代价一：成本倍增
多 Agent 的成本增长来自三个地方：
- 重复的固定前缀。 每个 Agent 都有自己的系统指令和工具定义，每次调用都要发送。
- 各自独立的探索。 每个子 Agent 都在自己的上下文里多步探索，而 Token 随步数增长很快（原理见 成本模型）。
- 协调开销。 主 Agent 需要规划、分派、阅读所有子 Agent 的结果并综合。
Anthropic 在多 Agent 研究系统的文章中给出的数据是：在他们的场景中，多 Agent 系统消耗的 Token 大约是普通聊天的 15 倍，单 Agent 约为 4 倍。
用一个例子估算。 全站 SEO 诊断，比较单 Agent 与“1 个 Manager + 5 个 Worker”两种方案。单价均为 假设值：输入 ¥20 / 百万 Token，输出 ¥100 / 百万 Token，不考虑缓存。Token 数也是示意性假设，实际应以 Trace 统计为准。
| 方案 | 输入 Token | 输出 Token | 模型费用 | 端到端耗时 |
|---|---|---|---|---|
| 单 Agent 串行检查 | 150,000 | 5,000 | ¥3.00 + ¥0.50 = ¥3.50 | 约 6 分钟 |
| Manager | 60,000 | 4,000 | ¥1.20 + ¥0.40 = ¥1.60 | |
| 5 个 Worker（每个 80,000 / 3,000） | 400,000 | 15,000 | ¥8.00 + ¥1.50 = ¥9.50 | |
| 多 Agent 合计 | 460,000 | 19,000 | ¥11.10 | 约 2 分钟 |
图 2 把两种方案的费用和耗时并排放在一起：
多 Agent 方案约为单 Agent 的 3.2 倍成本，换来约 3 倍的速度，以及可能更全面的覆盖。这笔交易是否划算，取决于两个问题：用户是否真的在乎这 4 分钟？在同一份评测集上，质量提升了多少？如果质量没有明显提升、用户也不急，单 Agent 甚至批处理才是更好的选择。
代价二：信息丢失与冲突
多 Agent 之间传递的是 摘要，而每一次摘要都是有损压缩，类似“传话游戏”（图 3）：
关键的限定条件（canonical 指向别处）在两次压缩中被丢掉了。
更隐蔽的问题是 隐含决策冲突。Cognition 在《Don’t Build Multi-Agents》中提出：行动本身隐含着决策，相互冲突的决策会带来糟糕的结果。两个并行的 Worker 分别决定“按移动端标准评估”和“按桌面端标准评估”，各自都合理，合在一起的报告就自相矛盾。
对策：
- 结构化返回。 规定子 Agent 的输出字段，包含结论、证据、前提条件与置信度，不允许只返回一句话。
- 共享决策记录。 在分派前由 Manager 明确全局约定（评估标准、时间范围、口径），写进每个子任务的委派中。
- 产物走引用。 大块原始结果写入文件或存储，只把引用传回主 Agent，需要时再读取原文。Anthropic 的研究系统采用了这种做法来减少多阶段处理中的信息丢失。
- 单一写入者。 对共享产物（报告、代码、业务数据）只允许一个 Agent 执行写操作，其他 Agent 只提供输入。
代价三：责任不清
单 Agent 出错，责任链很短：这个 Agent 的指令、工具或模型出了问题。多 Agent 出错时，会出现一连串难以回答的问题：
- 结论错误，是 Worker 查错了，还是 Manager 综合错了？
- 两个 Agent 给出相反结论时，以谁为准？
- 需要用户审批的操作由哪个 Agent 发起？用户看到的审批请求是否包含了足够的上下文？
- 权限是否被“借用”：一个只读的调研 Agent 能否通过请求另一个有写权限的 Agent，间接完成它自己无权做的操作？
最后一个问题尤其危险。如果读取外部网页的 Agent 被 Prompt 注入 攻击，它可以在返回给主 Agent 的“结论”里夹带指令，诱导拥有写权限的 Agent 执行操作。多 Agent 之间传递的内容，应该和工具返回的外部内容一样被视为不可信数据，敏感操作仍需按 最小权限与凭据管理 和审批规则单独校验。
图 4 画出了这条攻击路径和对应的防线：
对策： 为每个 Agent 写清职责、权限和输出契约；明确唯一的“最终答案负责人”；冲突结论必须在最终产物中显式呈现，而不是由模型悄悄选一个。
代价四：调试与评估困难
Agent 本身就是非确定的，多个 Agent 叠加后，同一个输入每次运行的路径差异会更大。几个现实问题：
- 错误会累积。 Anthropic 在文章中指出，Agent 是有状态的，长时间运行中的小错误可能不断放大；他们的做法是持久化执行并设置检查点，出错后从出错的位置恢复，而不是从头重跑。
- Trace 必须跨 Agent 串联。 每个 Agent 的运行都要挂在同一个 trace_id 下，并保留父子关系。OpenTelemetry GenAI 语义约定定义了
invoke_agentSpan，其指标约定还特别说明：子 Agent 或被交接 Agent 发起的模型调用应计入它们自己的调用，保证整棵调用树中每次模型调用只被统计一次。OpenAI Agents SDK 的内置追踪会为 Handoff 单独记录 Span。 - 评估要看终态。 多 Agent 的执行路径变化多端，很难逐步断言“应该先调用谁”。更可行的是评估最终产物和系统状态是否正确，再辅以对关键轨迹的检查，见 结果评估与轨迹评估。
- 发布要谨慎。 多 Agent 系统的运行时间可能较长，更新时正在运行的任务可能处在任意阶段。Anthropic 提到他们使用彩虹部署（rainbow deployments），在新旧版本同时运行的情况下逐步切换流量，避免打断正在运行的 Agent。
失败模式速查表
| 症状 | 可能原因 | 对策 |
|---|---|---|
| 多个子 Agent 查了同样的东西 | 委派没有划定边界 | 委派中写明范围与排除项；由代码按确定维度拆分 |
| 简单问题也派出大量子 Agent | 缺少投入规模的规则 | 在指令中按复杂度规定子 Agent 数量；设置并发与花费上限 |
| 汇总报告中出现无出处的结论 | 综合阶段幻觉，或摘要丢失限定条件 | 要求每条结论带证据引用；汇总时只允许引用子 Agent 的结构化结果 |
| 各部分风格、口径不一致 | 并行 Agent 各自做了隐含决策 | 分派前统一全局约定；由单一 Agent 负责最终成稿 |
| Agent 之间来回委派、迟迟不结束 | 缺少停止条件和交接上限 | 设置最大轮次与交接次数；超过上限转人工 |
| 只读 Agent 间接触发了写操作 | 权限通过 Agent 间请求被“借用” | Agent 间消息视为不可信输入；写操作独立校验与审批 |
| 出错后无法定位是哪个 Agent | Trace 未跨 Agent 串联 | 统一 trace_id 与父子 Span；记录每个 Agent 的版本 |
常见误区
- “成本高一点没关系，效果好就行。” 要用同一份评测集去证明“效果好”，并确认用户愿意为此付费。很多时候同样的预算给单 Agent 更多步数，效果差距并不大。
- “让模型自己协调，冲突会自动解决。” 模型倾向于把冲突抹平成一个看似合理的说法。冲突应该显式暴露给程序或人来决定。
- “多 Agent 更安全，因为权限分开了。” 只有当 Agent 之间的消息也被当作不可信输入处理时，权限隔离才真正有效。
- “调试多 Agent 和调试单 Agent 差不多。” 没有跨 Agent 的 Trace，多 Agent 的问题几乎无法复现和定位。这项基础设施必须先于多 Agent 上线。
产品经理检查清单
多 Agent 方案上线前的评审清单：
- 是否在同一份评测集上对比过单 Agent 与多 Agent 的质量、成本和延迟？结论是否支持多 Agent？
- 单任务成本的 P50 / P95 是多少？是否设置了子 Agent 数量、嵌套深度与总花费上限？
- 每个 Agent 的职责、权限和输出契约是否写清楚？最终答案由谁负责？
- 子 Agent 的返回是否结构化，并包含证据与前提条件？
- 相互冲突的结论如何处理：显式呈现、程序裁决，还是转人工？
- Agent 之间传递的内容是否被当作不可信数据？写操作是否独立校验？
- Trace 能否跨 Agent 串联？出错时能否从检查点恢复？
- 发布新版本时，正在运行的长任务如何处理？
练习
完成本模块的综合实践（60 分钟左右）：
- 选一个你已经做过的单 Agent（例如 SEO 诊断或销售分析），把它改造成 Manager / Worker 结构（可以只在纸面上设计，也可以用 SDK 实现）。
- 用同一组 10 个任务分别运行或推演两种方案，填写下表：
| 指标 | 单 Agent | Manager / Worker |
|---|---|---|
| 任务成功数 | ||
| 平均 Token 与估算成本 | ||
| 平均耗时 | ||
| 出错时定位问题所用时间 |
- 写一段 200 字的结论：在这个场景下是否值得使用多 Agent，并引用上面的数据。
延伸阅读
- Anthropic：How we built our multi-agent research system
- Cognition：Don’t Build Multi-Agents
- OpenTelemetry GenAI 语义约定：Agent Spans
下一步
无论是单 Agent 还是多 Agent，最终都要由人来监督和验收。下一模块从「从聊天到监督」开始，讲如何为 Agent 设计让人放心的交互界面。