译者编注: 这篇文章的价值，不在于又列出了几种多智能体协作模式，而在于它把一个很容易越做越复杂的问题讲清楚了：什么时候该拆成多个智能体协作，什么时候其实一个智能体就够了。比起追求“更高级”的架构，这篇更强调从简单模式起步，再根据真实问题逐步演进。
正文开始
在之前的一篇文章中，我们探讨了多智能体系统何时能提供价值，以及何时单个智能体是更好的选择。本文面向那些已经做出决策、现在需要决定哪种协调模式适合自己的问题的团队。
我们观察到，团队往往根据听起来是否“高级”来选择模式，而不是看它是否适合当前问题。我们建议从可能有效的最简单模式开始，观察它在哪些地方遇到困难，然后逐步演进。本文探讨了五种模式的具体机制和局限性：
- 生成器-验证器，适用于有明确评估标准、对质量要求高的输出
- 编排器-子智能体，适用于任务分解清晰、子任务有边界的场景
- 智能体团队，适用于并行、独立、长时间运行的子任务
- 消息总线，适用于事件驱动的管道和不断增长的智能体生态系统
- 共享状态，适用于智能体相互利用彼此发现成果的协作性工作
模式1：生成器-验证器
这是最简单的多智能体模式，也是部署最广泛的模式之一。我们在上一篇文章中将其作为验证子智能体模式引入，这里我们使用更广泛的“生成器-验证器”框架，因为生成器不一定是编排器。
工作原理
生成器接收任务并产生初始输出，然后将其传递给验证器进行评估。验证器检查输出是否满足所需标准，如果满足则接受为完成，否则拒绝并附带反馈。如果被拒绝，该反馈将路由回生成器，生成器利用它进行修正尝试。此循环持续进行，直到验证器接受输出或达到最大迭代次数。
适用场景
考虑一个支持系统，它生成对客户工单的邮件回复。生成器使用产品文档和工单上下文生成初始回复。验证器根据知识库检查准确性，根据品牌指南评估语气，并确认回复解决了提出的每个问题。未通过的检查会返回给生成器，并附带明确指出问题的反馈，例如将某个功能归因于错误的定价层级，或某个工单问题未被回答。
当输出质量至关重要且评估标准可以明确时，使用此模式。它适用于代码生成（一个智能体编写代码，另一个编写并运行测试）、事实核查、基于量规的评分、合规性验证，以及任何错误输出代价高于额外生成周期的领域。
局限性
验证器的好坏取决于其标准。一个只被告知“检查输出是否良好”、没有进一步标准的验证器，只会对生成器的输出例行盖章通过。团队最常见的失败方式是实现了循环，却没有定义“验证”的具体含义，这造成了有质量控制的假象，实则没有实质内容。（我们在上一篇文章中讨论过这种“过早胜利”的问题。）
该模式还假设生成和验证是可分离的技能。如果评估一个创意方案和生成一个创意方案一样困难，那么验证器可能无法可靠地发现问题。
最后，迭代循环可能会陷入停滞。如果生成器无法处理验证器的反馈，系统就会振荡而无法收敛。设置最大迭代限制和后备策略（升级给人类、返回带免责声明的最佳尝试）可以防止其变成无限循环。
模式2：编排器-子智能体
层次结构定义了此模式。一个智能体充当团队领导，负责规划工作、委派任务并综合结果。子智能体处理具体职责并汇报。
工作原理
领导智能体接收任务并决定如何处理。它可能直接处理某些子任务，同时将其他子任务分派给子智能体。子智能体完成工作并返回结果，编排器将这些结果综合成最终输出。
Claude Code 使用了此模式。主智能体自行编写代码、编辑文件、运行命令，同时在后台分派子智能体来搜索大型代码库或调查独立问题，这样在结果流回的同时，工作可以继续进行。每个子智能体在自己的上下文窗口中运行，并返回精炼后的发现结果。这使编排器的上下文专注于主要任务，同时探索工作并行进行。
适用场景
考虑一个自动化代码审查系统。当收到一个拉取请求时，系统需要检查安全漏洞、验证测试覆盖率、评估代码风格和架构一致性。每个检查都是独立的，需要不同的上下文，并产生明确的输出。编排器将每个检查分派给专门的子智能体，收集结果，并综合出统一的审查意见。
当任务分解清晰且子任务之间的相互依赖性最小时，使用此模式。编排器保持对整体目标的连贯视图，而子智能体则专注于具体职责。
局限性
编排器成为信息瓶颈。当一个子智能体发现了与另一个子智能体的工作相关的信息时，该信息必须通过编排器传递。如果安全子智能体发现了一个身份验证缺陷，而这个缺陷会影响架构子智能体的分析，编排器必须识别这种依赖关系并适当地路由信息。经过几次这样的交接后，关键细节常常会丢失或被过度概括。
顺序执行也会限制吞吐量。除非显式并行化，否则子智能体会一个接一个地运行，这意味着系统会承担多智能体的 token 成本，却没有获得速度上的好处。
模式3：智能体团队
当工作可以分解为能够长时间独立进行的并行子任务时，编排器-子智能体模式可能会变得不必要的约束。
工作原理
一个协调器生成多个工作智能体作为独立进程。团队成员从一个共享队列中认领任务，自主地跨多个步骤工作，并发出完成信号。
与编排器-子智能体的区别在于工作者的持久性。编排器为一个有边界的子任务生成一个子智能体，子智能体在返回结果后终止。而团队成员则会在多次任务指派中保持存活，积累上下文和领域专长，随着时间的推移提升其性能。协调器分配工作并收集结果，但不会在任务之间重置工作者。
适用场景
考虑将一个大型代码库从一个框架迁移到另一个框架。一个团队成员可以独立迁移每个服务，包括其自己的依赖项、测试套件和部署配置。协调器将每个服务分配给一个团队成员，每个团队成员自主完成迁移工作：依赖项更新、代码更改、测试修复、验证。协调器收集完成的迁移，并在整个系统上运行集成测试。
当子任务相互独立且能从持续的、多步骤的工作中受益时，使用此模式。每个团队成员会建立起关于其领域的上下文，而不是每次分派都从头开始。
局限性
独立性是关键要求。在编排器-子智能体模式中，编排器可以在子智能体之间进行协调并路由信息，而智能体团队中的团队成员则自主运行，无法轻易共享中间发现。如果一个团队成员的工作影响到另一个，双方都无从知晓，它们的输出可能会相互冲突。
完成检测也更困难。由于团队成员自主工作，持续时间可变，协调器必须处理部分完成的情况——一个团队成员两分钟完成，而另一个需要二十分钟。
共享资源会加剧这两个问题。当多个团队成员在同一个代码库、数据库或文件系统上操作时，两个团队成员可能会编辑同一个文件或进行不兼容的更改。该模式需要仔细的任务划分和冲突解决机制。
模式4：消息总线
随着智能体数量的增加和交互模式变得复杂，直接协调变得难以管理。消息总线引入了一个共享的通信层，智能体可以在其中发布和订阅事件。
工作原理
智能体通过两个原语进行交互：发布和订阅。智能体订阅它们关心的话题，路由器将匹配的消息传递给它们。具有新能力的新智能体可以开始接收相关工作，而无需重新配置现有连接。
适用场景
安全运营自动化系统展示了此模式的优越性。警报从多个来源到达，一个分类智能体按严重性和类型对每个警报进行分类，将高严重性的网络警报路由给网络调查智能体，将与凭证相关的警报路由给身份分析智能体。每个调查智能体可能会发布富集请求，由上下文收集智能体来满足。发现结果流向响应协调智能体，由其确定适当的操作。
这个管道适合消息总线，因为事件从一个阶段流向下一个阶段，团队可以在威胁类别演变时添加新的智能体类型，并且团队可以独立开发和部署智能体。
对于事件驱动的管道——工作流由事件本身而非预定顺序驱动，且智能体生态系统可能不断增长——使用此模式。
局限性
事件驱动通信的灵活性使得追踪更加困难。当一个警报在五个智能体之间触发一连串事件时，理解发生了什么需要仔细的日志记录和关联。调试比跟踪编排器的顺序决策更加困难。
路由准确性也至关重要。如果路由器错误分类或丢弃了一个事件，系统会静默失败——什么也不处理，但也从不崩溃。基于 LLM 的路由器提供了语义上的灵活性，但也引入了自身的故障模式。
模式5：共享状态
前面模式中的编排器、团队领导和消息路由器都集中管理信息流。共享状态去除了中介，让智能体通过一个所有智能体都可以直接读写的持久化存储来进行协调。
工作原理
智能体自主运行，从一个共享的数据库、文件系统或文档中读取和写入。没有中央协调器。智能体检查存储中是否有相关信息，对其发现采取行动，并将发现结果写回。工作通常以一个初始化步骤开始，该步骤向存储中植入一个问题或数据集，并在满足终止条件时结束：时间限制、收敛阈值，或者一个指定的智能体判定存储中已包含足够的答案。
适用场景
考虑一个研究综合系统，其中多个智能体调查一个复杂问题的不同方面。一个探索学术文献，另一个分析行业报告，第三个检查专利文件，第四个监测新闻报道。每个智能体的发现可能会为其他智能体的调查提供信息。学术文献智能体可能发现一位关键研究人员，而行业智能体应该更仔细地检查该研究人员的公司。
使用共享状态，发现结果直接进入存储。行业智能体可以立即看到学术智能体的发现，而无需等待协调器来路由信息。智能体们彼此利用对方的工作成果，共享存储成为一个不断发展的知识库。
共享状态还消除了协调器作为单点故障的问题。如果任何一个智能体停止工作，其他智能体会继续读写。在编排器和消息总线系统中，协调器或路由器的故障会使一切停止。
局限性
没有显式的协调，智能体可能会重复工作或采取相互矛盾的方法。两个智能体可能独立调查同一条线索。智能体之间的交互产生系统行为，而不是自上而下的设计，这使得结果的可预测性降低。
更棘手的故障模式是反应循环。例如，智能体 A 写下一个发现，智能体 B 读取它并写下后续发现，智能体 A 看到后续发现并作出回应。系统持续消耗 token 做毫无进展的工作。重复工作和并发写入有已知的工程解决方案（锁、版本控制、分区）。反应循环是一个行为问题，需要第一等的终止条件：时间预算、收敛阈值（连续 N 个周期没有新发现），或者一个指定智能体负责判定存储中是否已包含足够答案。将终止视为事后考虑的系统往往会无限循环，或者当某个智能体的上下文填满时随意停止。
在模式之间进行选择和演进
正确的模式取决于关于系统的几个结构性问题的答案。在我们之前的文章中，我们主张以上下文为中心的分解，即根据每个智能体需要什么上下文来划分工作，而不是根据它做什么类型的工作。这个原则同样适用于此。这些模式的不同之处在于它们管理上下文边界和信息流的方式。
编排器-子智能体 vs. 智能体团队
两者都涉及协调器将工作分派给其他智能体。问题在于工作者需要维护其上下文的时间长度。
- 选择编排器-子智能体：当子任务短小、聚焦，并产生明确输出时。代码审查系统在这里工作良好，因为每个检查运行其分析，生成报告，并在一次有边界的调用内返回。子智能体不需要在多个周期中携带上下文。
- 选择智能体团队：当子任务能从持续的、多步骤的工作中受益时。代码库迁移适合这里，因为每个团队成员对其分配的服务——依赖图、测试模式、部署配置——建立起真正的熟悉度。这种累积的上下文以一次性分派无法复制的方式提升了性能。
当子智能体需要在多次调用之间保留状态时，智能体团队是更合适的选择。
编排器-子智能体 vs. 消息总线
两者都可以处理多步骤工作流。问题在于工作流结构的可预测性。
- 选择编排器-子智能体：当步骤的序列是预先知道的时。代码审查系统遵循一个固定的管道：接收 PR、运行检查、综合结果。
- 选择消息总线：当工作流由事件驱动，并可能根据发现的内容而变化时。安全运营系统无法预测什么警报会到达，或者它们需要什么样的调查路径。可能出现需要新处理方式的新警报类型。消息总线通过将事件路由给有能力的智能体（而不是遵循预定的序列）来适应这种可变性。
当编排器中累积的条件逻辑越来越多，以处理不断扩大的各种情况时，消息总线使这种路由显式且可扩展。
智能体团队 vs. 共享状态
两者都涉及智能体自主工作。问题在于智能体是否需要彼此的发现结果。
- 选择智能体团队：当智能体在不交互的独立分区上工作时。代码库迁移适合这里，因为每个团队成员处理其自己的服务，协调器在最后组合结果。
- 选择共享状态：当智能体的工作是协作性的，并且发现结果应在它们之间实时流动时。研究综合系统是更好的匹配，因为学术智能体对一位关键研究人员的发现，立即与行业智能体的调查相关。
一旦团队成员需要彼此通信而不仅仅是共享最终结果，共享状态使这一点更加自然。
消息总线 vs. 共享状态
两者都支持复杂的多智能体协调。问题在于工作是以离散事件的形式流动，还是积累到一个共享的知识库中。
- 选择消息总线：当智能体对管道中的事件作出反应时。安全运营系统逐阶段处理警报，每个事件在完成之前触发下一个事件。该模式在将事件路由给有能力的智能体方面是高效的。
- 选择共享状态：当智能体随着时间的推移，建立在累积的发现成果之上时。研究综合系统持续收集知识。智能体反复回到存储，查看其他人发现了什么，并调整自己的调查。
消息总线仍然有一个路由器，这意味着一个中央组件决定事件去向。共享状态是去中心化的。如果消除单点故障是一个优先事项，共享状态能更彻底地满足这个需求。
如果消息总线系统中的智能体发布事件是为了分享发现而不是触发动作，那么共享状态是更合适的选择。
入门指南
生产系统通常组合使用多种模式。一种常见的混合方式是对整体工作流使用编排器-子智能体，而对一个协作密集的子任务使用共享状态。另一种方式是使用消息总线进行事件路由，并使用智能体团队风格的工作者处理每种事件类型。这些模式是构建块，而不是互斥的选择。
下表总结了每种模式适用的场景。
| 场景 | 模式 |
|---|---|
| 对质量要求高的输出，有明确的评估标准 | 生成器-验证器 |
| 任务分解清晰，子任务有边界 | 编排器-子智能体 |
| 并行工作负载，独立的长时间运行的子任务 | 智能体团队 |
| 事件驱动的管道，不断增长的智能体生态系统 | 消息总线 |
| 协作性研究，智能体共享发现 | 共享状态 |
| 要求无单点故障 | 共享状态 |
对于大多数用例，我们建议从编排器-子智能体开始。它能以最少的协调开销处理最广泛的问题。观察它在哪些地方遇到困难，然后在具体需求变得明确时向其他模式演进。
在接下来的文章中，我们将结合生产实现和案例研究，深入探讨每种模式。关于多智能体系统何时值得投资的背景信息，请参阅 构建多智能体系统：何时以及如何使用它们。
致谢
作者：Cara Phillips，贡献者：Eugene Yang、Jiri De Jonghe、Samuel Weller 和 Erik S。
正文结束
译者大白话
一句话核心： 让多个 AI 分工合作，就像带团队干活。有五种常见的“带团队”方式，从最简单的开始用，遇到问题再升级。
生成器-验证器（一个写，一个检查）
- 一个 AI 干活，另一个 AI 专门挑毛病。
- 挑出问题就退回重改，改到合格为止。
- 关键：得说清楚“怎样算好”，否则检查就是走过场。
- 适合：写代码、审合同、回客服邮件等必须准确的任务。
编排器-子智能体（一个组长，分任务给组员）
- 一个 AI 当组长，把大任务拆成小份，分给不同的 AI 去干。
- 组员干完就汇报，组长汇总结果。
- 关键：组长是唯一的“大脑”，所有信息都要经过它。
- 适合：任务能拆成几步、每步相对独立，比如代码审查（一个查安全、一个查风格）。
智能体团队（几个长期员工，各管一摊）
- 和上面很像，但组员不会干完就消失，而是长期存在、越干越熟。
- 关键：组员之间不怎么商量，各干各的，最后合并。
- 适合：子任务需要多步处理，且彼此互不影响，比如把一个大项目拆成多个模块，每个 AI 负责一个。
消息总线（像工作群，谁有事就发消息，谁有空就接活）
- 没有组长。AI 们通过一个公共“公告板”发布消息，谁有能力谁认领。
- 关键：流程不固定，可以随时加新的 AI 类型。
- 适合：任务随机出现、后续可能要扩展功能，比如安全警报系统（警报来了→分类→不同 AI 处理）。
共享状态（大家共用一个小本本，谁发现什么就记下来，别人直接看）
- 所有 AI 共用一个“笔记本”（数据库或文件），随时读写。
- 没有中央调度，AI 们互相借用彼此的发现。
- 关键：要设置“什么时候停”，否则可能无限循环。
- 适合：协作研究，比如多个 AI 调查同一个复杂问题，各自发现的东西别人马上能用。
到底该选哪种？
建议从最简单的“编排器-子智能体”（一个组长分任务）开始，因为大部分问题用它就能解决。如果你发现：
- 需要反复检查 → 考虑加“生成器-验证器”
- 组长太忙、任务太杂 → 考虑“消息总线”
- 需要长期自治的 AI 员工 → 考虑“智能体团队”
- 需要 AI 们互相借力 → 考虑“共享状态”
核心原则：别一上来就搞复杂，先跑通最简单的，不够用了再升级。
译者总结
这五种模式不是选美比赛——别挑最“高级”的，而是从最简单的“组长+组员”开始跑通，遇到具体困难再升级。先能干活，再谈优化。