翻译自 Anthropic 官方博客，原文链接：https://claude.com/blog/multi-agent-coordination-patterns
五种多智能体协调模式、各自的权衡取舍，以及何时从一种模式演进到另一种模式。
在此前的一篇文章中，我们探讨了多智能体系统何时能带来价值、何时单个智能体是更好的选择。本文面向已经做出这一判断、现在需要决定哪种协调模式适合其问题的团队。
我们发现，许多团队选择模式时往往基于"听起来复杂高端"，而非"是否契合实际问题"。我们建议从最简单的可行模式出发，观察其局限所在，再逐步演进。本文将分析以下五种模式的机制与局限：
- 生成器-验证器（Generator-Verifier）：适用于有明确评估标准的质量关键型输出
- 编排器-子智能体（Orchestrator-Subagent）：适用于任务分解清晰、子任务边界明确的场景
- 智能体团队（Agent Teams）：适用于并行、独立、长时运行的子任务
- 消息总线（Message Bus）：适用于具有不断扩展的智能体生态的事件驱动管道
- 共享状态（Shared State）：适用于智能体需要在彼此发现的基础上协作推进的场景
模式一：生成器-验证器（Generator-Verifier）
这是最简单的多智能体模式，也是部署最广泛的模式之一。我们在上一篇文章中将其介绍为"验证子智能体"模式，这里使用更宽泛的"生成器-验证器"表述，因为生成器不一定是编排器。
工作原理
生成器接收任务并产生初始输出，将其传递给验证器进行评估。验证器检查输出是否满足所需标准，若满足则接受，若不满足则附带反馈信息拒绝。拒绝后，反馈被路由回生成器，生成器据此生成修订版本。此循环持续进行，直到验证器接受输出或达到最大迭代次数为止。
适用场景
以一个针对客户工单自动生成邮件回复的支持系统为例：生成器根据产品文档和工单上下文生成初始回复；验证器对照知识库检查准确性、依据品牌指南评估语气，并确认回复是否涵盖了所有问题。未通过检查的内容会以具体反馈（如将某功能错误归属于某定价层级、或遗漏了某个工单问题）返回给生成器。
当输出质量至关重要且评估标准可以明确定义时，适合使用此模式。它在代码生成（一个智能体写代码，另一个写并运行测试）、事实核查、基于评分标准的评级、合规性验证等领域均有良好表现——凡是"错误输出的代价高于额外生成一次的代价"的领域，都适合此模式。
局限所在
验证器的能力上限取决于其评估标准的质量。如果验证器仅被告知"检查输出是否良好"而没有进一步标准，它往往会直接通过生成器的输出。团队最常见的失败之处在于：实现了循环，却没有定义"验证"究竟意味着什么，从而制造了质量控制的假象，而非实质。
此外，该模式假设"生成"与"验证"是可分离的技能。如果评估某种创意方案与生成它一样困难，验证器可能并不能可靠地捕获问题。
最后，迭代循环可能陷入停滞。若生成器无法解决验证器的反馈，系统将在不收敛的情况下反复震荡。设置最大迭代次数并制定回退策略（升级给人工、带注释返回最优结果）可以防止无限循环。
模式二：编排器-子智能体（Orchestrator-Subagent）
这一模式以层级关系为核心。一个智能体充当"团队负责人"，负责规划工作、分配任务、综合结果；子智能体负责处理特定职责并汇报结果。
工作原理
主导智能体接收任务后决定如何处理：部分子任务由自身直接完成，其余分派给子智能体。子智能体完成工作后返回结果，编排器将其综合为最终输出。
Claude Code 使用的正是这一模式。主智能体自行编写代码、编辑文件、运行命令，并在需要搜索大型代码库或调查独立问题时在后台派遣子智能体——工作在结果回流的同时并行推进。每个子智能体在自己的上下文窗口中运行，返回提炼后的发现，从而使编排器的上下文专注于主要任务，而探索工作在并行中完成。
适用场景
以自动化代码审查系统为例：当 Pull Request 到来时，系统需要检查安全漏洞、验证测试覆盖率、评估代码风格、评估架构一致性。每项检查相互独立，需要不同的上下文，输出清晰明确。编排器将每项检查分派给专职子智能体，收集结果后综合为统一的审查报告。
当任务分解清晰、子任务之间相互依赖度低时，适合使用此模式。编排器保持对整体目标的连贯视图，而子智能体则专注于各自职责。
局限所在
编排器会成为信息瓶颈。当某个子智能体发现了与另一个子智能体工作相关的信息时，该信息必须通过编排器中转。若安全子智能体发现了影响架构分析的认证漏洞，编排器必须识别这一依赖关系并适当路由信息。经过多次此类交接后，关键细节往往会丢失或被摘要删除。
此外，顺序执行也会限制吞吐量。除非显式并行化，子智能体将依次运行，这意味着系统承担了多智能体的 Token 成本，却未获得速度上的收益。
模式三：智能体团队（Agent Teams）
当工作可以分解为能够长时间独立并行推进的子任务时，编排器-子智能体模式可能过于局限。
工作原理
协调者（Coordinator）将多个工作者智能体作为独立进程启动。团队成员从共享队列中认领任务，自主完成多步骤工作，并在完成后发出信号。
与编排器-子智能体的核心区别在于工作者的持久性。编排器为单个有界子任务派遣子智能体，子任务完成后子智能体即终止；而团队成员则跨多次任务持续存活，不断积累上下文和领域专知，随时间推移提升表现。协调者分配工作、收集结果，但不会在任务之间重置工作者。
适用场景
以将大型代码库从一个框架迁移到另一个框架为例：每个服务可以由团队成员独立迁移，包含其各自的依赖、测试套件和部署配置。协调者将每个服务分配给某个团队成员，成员自主完成迁移工作：依赖更新、代码修改、测试修复、验证。协调者收集完成的迁移结果并在整个系统上运行集成测试。
当子任务独立、且能从持续多步骤工作中获益时，适合使用此模式。每个团队成员会积累对其负责领域的熟悉程度，而非每次从零开始。
局限所在
独立性是关键前提。与编排器-子智能体不同（编排器可以在子智能体之间中转信息），团队成员自主运行，无法轻松共享中间发现，其输出可能因此产生冲突。
完成检测也更加困难。由于团队成员自主工作且时长不固定，协调者必须处理"部分完成"的情况——某个成员两分钟完成，另一个需要二十分钟。
共享资源会加剧上述问题。当多个团队成员操作同一代码库、数据库或文件系统时，可能出现编辑同一文件或做出不兼容更改的情况。此模式需要仔细的任务分区和冲突解决机制。
模式四：消息总线（Message Bus）
随着智能体数量增加、交互模式日趋复杂，直接协调变得难以管理。消息总线引入了一个共享通信层，智能体通过发布和订阅事件进行交互。
工作原理
智能体通过两种原语交互：发布（Publish）和订阅（Subscribe）。智能体订阅自己感兴趣的主题，路由器（Router）将匹配的消息分发出去。新增的具备新能力的智能体可以立即开始接收相关工作，无需重新布线现有连接。
适用场景
安全运营自动化系统是此模式的典型示例：警报从多个来源涌入，分类智能体按严重程度和类型分类，将高严重性的网络警报路由给网络调查智能体，将凭据相关警报路由给身份分析智能体。每个调查智能体可能发布上下文收集请求，由专门的上下文收集智能体来满足。发现结果流向响应协调智能体，由其确定适当的行动。
此管道适合消息总线，因为事件从一个阶段流向下一阶段，团队可以随着威胁类别演变添加新智能体类型，各智能体可以独立开发和部署。
当工作流程由事件驱动而非预定顺序产生，且智能体生态系统可能持续增长时，适合使用此模式。
局限所在
事件驱动通信的灵活性使追踪变得更加困难。当一个警报触发跨五个智能体的事件级联时，理解发生了什么需要仔细的日志记录和关联分析，调试难度远高于跟随编排器的顺序决策。
路由准确性也至关重要。若路由器错误分类或丢弃某个事件，系统会悄无声息地失败——什么都没处理，却也没有崩溃。基于 LLM 的路由器提供了语义灵活性，但也引入了其自身的故障模式。
模式五：共享状态（Shared State）
前述各模式中的编排器、团队负责人和消息路由器均集中管理信息流。共享状态通过让智能体直接读写持久化存储来协调，从而去除了中间人。
工作原理
智能体自主运行，从共享数据库、文件系统或文档中读取和写入信息，没有中心协调者。智能体检查存储中的相关信息，基于发现采取行动，并将结果写回。工作通常从初始化步骤开始（在存储中植入问题或数据集），在满足终止条件时结束：时间限制、收敛阈值，或某个指定智能体判断存储中已有足够的答案。
适用场景
以研究综合系统为例：多个智能体调查某个复杂问题的不同方面——一个探索学术文献，一个分析行业报告，一个检查专利申请，一个监测新闻报道。每个智能体的发现可能影响其他智能体的调查方向。学术文献智能体发现的某位关键研究者，可能正是行业智能体需要深入研究的公司的创始人。
有了共享状态，发现结果直接写入存储。行业智能体可以立即看到学术智能体的发现，无需等待协调者路由信息。智能体在彼此工作的基础上持续推进，共享存储成为不断演化的知识库。
共享状态还消除了协调者作为单点故障的风险。若任意一个智能体停止运行，其他智能体仍可继续读写；而在编排器和消息总线系统中，协调者或路由器的故障将导致一切停摆。
局限所在
没有显式协调，智能体可能重复工作或追求相互矛盾的方向。两个智能体可能独立调查同一条线索。智能体之间的交互产生系统行为，而非自上而下的设计，使结果难以预测。
更难处理的故障模式是反应式循环：智能体 A 写入一个发现，智能体 B 读取并写入跟进内容，智能体 A 看到跟进并再次响应——系统持续消耗 Token，却没有收敛。重复工作和并发写入有成熟的工程解决方案（锁、版本控制、分区），而反应式循环是行为问题，需要一流的终止条件：时间预算、收敛阈值（N 个周期内无新发现），或某个专门负责判断存储答案是否充分的指定智能体。将终止条件视为事后补充的系统往往会无限循环，或在某个智能体上下文填满时随机停止。
模式的选择与演进
正确的模式取决于系统的几个结构性问题。在前一篇文章中，我们倡导以上下文为中心的分解方式——按每个智能体所需的上下文来划分工作，而非按工作类型划分。这一原则同样适用于此。各模式的区别在于它们如何管理上下文边界和信息流动。
编排器-子智能体 vs. 智能体团队
两者都涉及协调者将工作分派给其他智能体，区别在于工作者需要维持上下文多长时间。
- 选择编排器-子智能体：子任务短暂、聚焦、输出清晰。代码审查系统适用于此，因为每项检查完成分析、生成报告，并在单次有界调用内返回，子智能体无需跨多个周期持有上下文。
- 选择智能体团队：子任务从持续多步骤工作中获益。代码库迁移适用于此，因为每个团队成员会对其负责的服务形成真正的熟悉程度——依赖图谱、测试模式、部署配置，这种积累的上下文能带来一次性派遣无法复制的效果。
当子智能体需要跨调用保留状态时，智能体团队是更好的选择。
编排器-子智能体 vs. 消息总线
两者都能处理多步骤工作流，区别在于工作流结构的可预测性。
- 选择编排器-子智能体：步骤顺序提前已知。代码审查系统遵循固定管道：接收 PR、运行检查、综合结果。
- 选择消息总线：工作流由事件产生，可能因发现的内容而变化。安全运营系统无法预测会到来哪些警报或需要什么调查路径，也可能出现需要新处理方式的新警报类型。消息总线通过将事件路由给有能力的智能体来适应这种可变性，而非遵循预定顺序。
当编排器中为处理不断扩展的案例类型而积累了大量条件逻辑时，消息总线能让这种路由变得显式且可扩展。
智能体团队 vs. 共享状态
两者都涉及自主工作的智能体，区别在于智能体是否需要彼此的发现。
- 选择智能体团队：智能体在互不交互的独立分区上工作。代码库迁移适用于此，每个团队成员负责自己的服务，协调者在最后合并结果。
- 选择共享状态：智能体的工作是协作性的，发现需要实时在它们之间流动。研究综合系统更适合此模式，因为学术智能体发现的关键研究者，立即与行业智能体的调查相关。
一旦团队成员需要相互通信，而不仅仅是共享最终结果，共享状态更加自然。
消息总线 vs. 共享状态
两者都支持复杂的多智能体协调，区别在于工作是以离散事件的形式流动，还是以共享知识库的形式积累。
- 选择消息总线：智能体在管道中对事件做出反应。安全运营系统逐阶段处理警报，每个事件在完成前触发下一个事件，该模式擅长将事件路由给有能力的智能体。
- 选择共享状态：智能体随时间推移在积累的发现上持续构建。研究综合系统持续积累知识，智能体反复返回存储，查看他人的发现并调整自己的调查方向。
消息总线仍有路由器这个中心组件来决定事件走向；共享状态则是去中心化的。若消除单点故障是优先级，共享状态能更完整地做到这一点。
如果消息总线中的智能体正在发布事件来共享发现而非触发行动，共享状态是更好的选择。
快速入门
生产系统通常会组合使用多种模式。常见的混合方式是：用编排器-子智能体处理整体工作流，同时在协作密集的子任务中使用共享状态；或使用消息总线进行事件路由，用智能体团队风格的工作者处理每种事件类型。这些模式是构建模块，而非互斥的选择。
下表总结了各模式的适用情境：
| 情境 | 模式 |
|---|---|
| 质量关键型输出，有明确评估标准 | 生成器-验证器 |
| 任务分解清晰，子任务边界明确 | 编排器-子智能体 |
| 并行工作负载，独立的长时运行子任务 | 智能体团队 |
| 事件驱动管道，智能体生态持续增长 | 消息总线 |
| 协作性研究，智能体共享发现 | 共享状态 |
| 不允许单点故障 | 共享状态 |
对于大多数用例，我们建议从编排器-子智能体开始。它以最低的协调开销处理最广泛的问题。观察其局限所在，再根据具体需求向其他模式演进。
在即将发布的文章中，我们将结合生产实现和案例研究深入探讨每种模式。关于多智能体系统何时值得投入的背景，请参阅《构建多智能体系统：何时以及如何使用》。
致谢：作者 Cara Phillips，贡献者 Eugene Yan、Jiri De Jonghe、Samuel Weller 和 Erik S.