单 Agent 的瓶颈与多 Agent 收益

用途：判断当前任务是否真的需要多 Agent，而不是为了架构而架构

单 Agent 的三个真实瓶颈

瓶颈	表现	多 Agent 是否解决
上下文窗口有限	长任务后期遗忘早期约束、塞满无关历史导致质量下降	部分解决（分而治之，各子任务上下文更小）
串行延迟	一个长链路顺序执行，墙钟时间线性累加	解决（可并行分支）
角色冲突	同一上下文里既要发散又要批判，倾向自我肯定	解决（分离生成者与验证者）

多 Agent 引入的代价

1. 协调成本：任务拆分、结果合并、冲突处理都需要额外机制，且这些机制本身会出错。
2. 成本倍增：Token 与调用次数随 Agent 数上升，常达数倍。
3. 可观测性下降：一条结果由多个 Agent 产出，出错时定位困难（谁在什么上下文下做的判断）。
4. 错误放大：上游 Agent 的错误假设会被下游当作事实继续推理，形成“共识性错误”。
5. 归属困难：并行修改同一仓库时的 diff 归属、责任划分（见“冲突与 diff 归属”）。

什么时候确实值得

同时满足两条以上再考虑：

• 子任务可独立验证（各自有明确成功判据），不需要共享大量隐式上下文。
• 存在真实并行收益（多个互不依赖的检索、审查、生成任务）。
• 需要角色分离（生成 vs 评审、探索 vs 收敛），且同一上下文内自我批评已被证明无效。
• 任务规模超过单上下文容量，且能清晰切分边界。
• 有预算与评测能力衡量“多 Agent 是否真的更好”。

什么时候不值得

场景	原因
强顺序依赖的小改动	协调成本高于收益
需要全局一致性判断的重构	拆分后各 Agent 视野受限，一致性反而更差
单纯“想让它更聪明”	多 Agent 不提升单步推理质量，只改变信息组织方式
没有验收标准	无法判断哪个 Agent 出错，问题不可归因

替代方案（常常更优）

1. 单 Agent + 更好的上下文管理：检索式记忆、阶段性摘要、外部状态文件（任务清单、设计文档）。
2. 单 Agent + 工具：把可机械化的判断交给编译器、测试、静态分析，而不是再派一个 Agent。
3. 流水线（固定步骤）：步骤确定时用工作流编排（DAG），比自由协商的多 Agent 可控得多。
4. 自检循环（同模型不同提示）：生成 → 用严格评审提示复查，成本远低于多实例。

经验判断：多数“多 Agent 编排”的收益，可以用“上下文管理 + 工具化验证 + 固定流水线”以一半成本拿到。真正的增量出现在可并行与角色分离这两类需求上。

常见误区

误区	修正
Agent 数量越多越聪明	数量增加错误传播面与成本
让 Agent 自由协商决定分工	分工由编排层定义，Agent 只执行子任务
无验收标准就并行	无法归因，结果不可信
用多 Agent 替代测试与门禁	机械验证交给工具，不靠另一个模型的意见
忽略成本与延迟预算	见“成本与延迟预算”

延伸阅读

• 本站：编排拓扑、任务分解粒度、评测与基准
• 关于 LLM 多智能体协作与辩论（multi-agent debate）的公开研究论文