多 agent 协作与它的真实代价
拆成多个角色看着很美，但交接处丢的信息、翻倍的成本都得有人付。
学完这节你能做到
- 判断一个任务是否真的需要多个 agent
- 设计交接协议，把上下文损耗降到可接受
- 识别多 agent 系统里最常见的三种失败
「架构师 agent 出方案，开发 agent 写代码，测试 agent 验证，审查 agent 把关」—— 这套图画得很漂亮，落地时经常比单个 agent 还差。
这一节讲清代价，以及什么时候它确实值得。
先问：是不是只需要更长的上下文
大多数「需要多 agent」的直觉，实际是「上下文不够用」的错觉。检查顺序:
- 工具输出裁剪了吗？（L1）
- 工具集收窄了吗？
- 压缩策略调过吗？
- 需要长时间保留的中间产物，能不能写文件而不是留在上下文里？
四条都做完还是不够，再考虑拆。单 agent + 好的上下文管理， 在绝大多数任务上优于多 agent。
拆分的三种形态
| 形态 | 结构 | 适合 |
|---|---|---|
| 委派（sub-agent） | 主 agent 派子任务，只收结论 | 上下文隔离，L2 讲过 |
| 流水线 | A 的输出是 B 的输入，单向 | 阶段清晰、可独立验证的任务 |
| 对等协作 | 多个 agent 互相讨论 | 几乎从不划算 |
第三种要格外警惕:让两个 agent「讨论」出方案，成本翻倍、延迟翻倍， 而且没有任何机制保证结论更好 —— 它们的知识和偏差高度同源。
成本是乘法
假设一个任务，单 agent 要 30 轮:
| 方案 | 模型调用 | 上下文重建 | 交接损耗 | 墙钟 |
|---|---|---|---|---|
| 单 agent | 30 | 0 | 0 | T |
| 流水线 3 段 | ~35 | 3 次（每次要重述背景） | 2 处 | 约 T |
| 对等 2 个讨论 | ~70 | 持续 | 每轮都有 | 约 1.5T |
「上下文重建」这一栏是最容易漏算的:每个新 agent 都要重新拿到 系统提示、工具声明、任务背景 —— 而背景往往还得由上一个 agent 用自然语言复述一遍。
交接协议：结构化产物，不是自然语言转述
多 agent 系统里最大的信息损耗发生在交接处。解决办法是交接结构化的东西:
// ❌ 自然语言转述：信息在两次改写中衰减
"架构 agent 说要用策略模式，把三个分支拆成三个类，注意保持接口兼容"
// ✅ 结构化产物：可校验、无歧义
{
decision: "strategy-pattern",
files: [
{ path: "src/pay/alipay.ts", action: "create", implements: "PayStrategy" },
{ path: "src/pay/index.ts", action: "modify", note: "保留导出的 pay() 签名" },
],
constraints: ["不改 src/pay/types.ts 的公开接口", "不引入新依赖"],
openQuestions: ["退款路径是否也要拆？未确认"],
}openQuestions 这一项尤其重要 —— 它让「不确定」能被传下去，
而不是在转述中被抹平成确定的结论。
把交接物写进仓库里的文件（PLAN.md、handoff.json）， 下一个 agent 自己去读。好处是：可审查、可修改、可重放， 而且不占用交接双方的上下文。
三种失败形态
目标漂移
子 agent 拿到的任务描述缺少主上下文里的前提，做出来的东西答非所问。 症状:每个 agent 的产出单独看都合理，拼起来对不上。 对策:任务描述自包含 + 结构化约束清单。
责任真空
「A 以为 B 会写测试，B 以为 A 已经验证过了」。 症状:整条流水线跑完，没有任何一步做了端到端验证。 对策:显式指定每个环节的验收标准和责任人，最后一环必须是「验证」。
互相等待与循环
审查 agent 要求改，开发 agent 改完再审，又要求改 —— 三轮之后还在原地。 症状:同样的意见反复出现。 对策:硬性轮次上限 + 「第 N 轮仍未收敛就交给人」。
单 agent 犯错，错在一个地方，容易发现。 三个 agent 基于同一个被误解的前提各自展开，你会得到三份互相矛盾的产物 —— 而定位到最初那个误解要花的时间，远超省下的那点上下文。
什么时候确实值得
- 上下文隔离（委派模式）—— 中间过程主 agent 不需要看。这是最稳的收益。
- 阶段之间有客观验收——「先生成 OpenAPI，再据此生成客户端代码」， 中间产物是可校验的文件，交接损耗接近零。
- 需要不同的工具集/权限——「诊断 agent 只读、执行 agent 有写权限且需人确认」， 拆开是为了权限边界而不是能力，这个理由很硬。
- 真正的并行且互不依赖——三个独立仓库同时改一样的东西。
最后一类在 Pi 的语境里有个朴素答案:用 tmux 起三个 pi。 不需要编排框架，也不需要 agent 之间通信。
下面哪个理由最能支撑「这个任务确实需要拆成多个 agent」？
这一节的结论
- 先怀疑「只是上下文没管好」，四条检查做完再考虑拆。
- 委派 > 流水线 > 对等讨论;最后一种几乎从不划算。
- 成本是乘法:模型调用 + 上下文重建 + 交接损耗。
- 交接结构化产物（最好写成文件），并且允许传递「不确定」。
- 值得拆的硬理由:上下文隔离、可校验的中间产物、不同的权限边界。
- 真并行的场景，tmux 起几个 pi 就够，不需要编排框架。