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