原文：Building multi-agent systems: When and how to use them 作者：Cara Phillips（Paul Chen、Andy Schumeister、Brad Abrams、Theo Chu 等参与贡献） 译文说明：面向 算力 / AI 工程 / Agent 编排 读者的技术向编译；专名保留英文。若部署在 共绩算力 等云上环境，可把「多实例」与「token/延迟成本」与本文框架对照阅读。
多智能体系统（multi-agent）：多个 LLM 实例在独立对话上下文中运行，由代码协调。协调模式包括 agent swarm、基于能力的划分、消息总线等；本文聚焦 orchestrator–subagent（编排者–子代理） 层次结构——主代理为子任务生成并管理专职子代理，协调模型直观，适合团队入门。其他模式留待系列后续文章。
现实里，多智能体常被用在单智能体本已足够的场景；随着模型变强，这一「性价比」判断会不断变化。Anthropic 观察到：有团队花数月搭复杂多智能体，最后发现单智能体 + 更好的提示即可等价。
在大量实践后，团队归纳出 三类 场景下「多代理稳定优于单代理」：上下文污染、可并行子任务、专业化（工具/提示/领域）带来收益。除此之外，协调成本往往大于收益。
本文将说明：如何识别单代理边界、三类适用场景、以及常见实现误区。
先证明单智能体够用
设计得当的单智能体 + 合适工具，能力往往被低估。
多智能体带来额外开销：每多一个代理，就多一个失败面、一套要维护的提示、一类意外行为。团队曾做过「规划 / 执行 / 审查 / 迭代」分代理的复杂架构，结果在每次交接丢失上下文，协调消耗的 token 多于执行。内部测试里，同等任务下多智能体实现通常比单智能体多 3～10× token——来自上下文重复、代理间协调消息、交接摘要等。
多智能体决策框架
只有在单智能体无法克服的约束明确存在时，才值得上多智能体架构；收益必须覆盖额外成本。
1. 上下文保护（Context protection）
上下文有限，过长时质量会掉。若某子任务带入的信息与后续子任务无关，即 context pollution（上下文污染）。子代理可在干净上下文里只做自己的事。
例：客服既要查订单又要诊断技术问题。若每次查单把数千 token 订单历史塞进主对话，推理技术问题时会被无关信息稀释。
单代理路径（示意）：对话历史里堆满订单详情 → 技术诊断时仍背着 2000+ token 无关内容。
多代理思路：订单查询由独立 OrderLookup 子代理完成，只返回主代理需要的摘要（如几十到一百 token），主代理上下文保持聚焦。
适用条件（原文归纳）：子任务产生高 volume 上下文（常 >1000 tokens）且大部分与主任务无关；子任务边界清晰、可定义「要抽取什么」；属于先检索再过滤类工作。
2. 并行化（Parallelization）
多代理并行可探索更大搜索空间，对检索与研究类任务尤其有效。Claude Research 即：主代理拆解查询，多子代理并行查不同侧面，再汇总蒸馏结果；相对单代理，可在更大信息空间上提升覆盖与准确度。
核心实现：分解问题 → asyncio.gather 并行子代理 → 主代理综合。
代价：多智能体通常 3～10× token；并行能减少墙钟时间，但总计算量上升，整体耗时不一定更短。并行带来的核心价值往往是更全面，而非单纯更快。
3. 专业化（Specialization）
工具集专业化
工具过多时选型变差。三个信号：
- 数量：工具很多（例如 20+）时难以选准。
- 领域混杂：DB、API、文件系统等跨域工具混在一起，易混淆适用域。
- 增量伤害：新工具拖累旧任务表现，说明「工具管理容量」到顶。
系统提示专业化
不同任务需要冲突的人格/约束（客服要共情，代码审查要苛刻；合规要死板，头脑风暴要发散）。单代理频繁切换模式，不如拆成不同 system prompt 的专职代理。
领域专业化
法律、医学等需要大量领域上下文时，不宜全部塞进一个通才；可由领域子代理承载专注知识。
例：多平台集成：CRM、营销自动化、消息平台各 10～15 个端点，单代理 40+ 工具易选错；拆成 CRM / Marketing / Messaging 专精代理 + Orchestrator 路由，可缓解误选。代价是路由复杂度与提示维护量上升；适合域边界清晰、分流规则明确时。
何时算「单智能体架构已不够用」
除上述框架外，若出现以下信号，可考虑升级：
- 逼近上下文上限：长期占用大量上下文且效果下降（注意：compaction 等上下文管理进展正在缓解单代理限制）。
- 工具极多（15～20+）：优先评估 Tool Search Tool——按需发现工具而非一次加载全部，可显著降 token（原文称最高约 85%）并改善选型。
- 天然可并行的子任务：多源研究、多组件独立测试等，并行子代理收益大。
阈值会随模型迭代变化，以上为经验区间，非铁律。
以「上下文」为中心切分任务
常见错误是按问题类型切分（一人写功能、一人写测试、一人审查），导致交接像传话游戏，协调成本吞噬收益。
更稳妥的是 context-centric decomposition（以上下文边界切分）：
- 问题-centric（常适得其反）：按工种拆，手递手丢上下文。
- 上下文-centric（通常更有效）：同一功能从实现到测试尽量同一代理持有上下文；只有真能隔离上下文时再拆。
较合理的边界：独立研究路径、接口清晰的前后端黑盒并行、只需跑测试报结果的 verification 等。
较差边界：同一功能的规划→实现→测试强耦合阶段、需频繁同步的组件、强共享状态的工作。
验证子代理（Verification subagent）模式
跨领域都较稳的一种模式：独立验证代理只负责测试/校验主代理产出。
能力更强的编排模型（如 Claude Opus 4.5）有时可直接评估子代理产出而无需单独验证步；但在编排模型较弱、验证需专用工具、或流程上需要显式检查点时，验证子代理仍有价值。
验证代理成功的原因：验证所需上下文传递少，可近似黑盒测试，不必了解实现全过程。
实现要点：主代理完成一单元工作 → 向验证代理提供待验工件、明确成功标准、验证工具；验证代理无需理解「为何这样实现」，只需判断是否满足标准。
适用：QA（测试/lint/schema）、合规检查、交付前输出校验、事实/引用核对等。
「过早宣布胜利」问题
验证代理最常见的失败是没测全就标通过（跑一两个用例就当完成）。
缓解：具体标准（如「跑完整测试套件并列出全部失败」）、多场景与边界、负例、以及显式指令（如「在标为通过前必须跑完全套测试」）。
向前推进（Moving forward）
多智能体很强，但并非默认选项。在增加协调复杂度之前，请确认：
- 存在真实约束——上下文、并行机会或专业化需求——且多智能体确实在解决它。
- 分解遵循上下文边界，而非仅按工种/阶段硬切。
- 存在清晰验证点，子代理可在不拿全量上下文的情况下完成校验。
建议：从最简单的可行方案开始，有证据再堆复杂度。
本文为系列第一篇。单智能体模式见 Building effective agents；上下文工程见 Effective context engineering for AI agents；Claude 多智能体 Research 实现见 How we built our multi-agent research system（均为 Anthropic 官方材料，原文页末有链接）。
致谢（译注）
原文：Written by Cara Phillips, with contributions from Paul Chen, Andy Schumeister, Brad Abrams, and Theo Chu.