内容
在前一篇文章中，我们探讨了多智能体系统何时能带来价值，以及何时单个智能体是更优选择。本文面向那些已做出决策的团队，帮助他们确定哪种协调模式最适合当前问题。
我们发现许多团队在选择模式时更倾向于听起来“高级”的方案，而非真正契合问题的方案。我们建议从最简单的可行模式开始，观察其在哪些环节遇到瓶颈，再逐步演进。本文将深入剖析五种模式的机制与局限：
- 生成-验证模式（Generator-verifier）：适用于对输出质量要求极高且具备明确评估标准的情境
- 编排-子智能体模式（Orchestrator-subagent）：适合任务分解清晰、子任务边界明确的情形
- 智能体团队模式（Agent teams）：适用于并行、独立且需长期运行的长周期子任务
- 消息总线模式（Message bus）：适合事件驱动型流水线，且智能体生态持续扩展的场景
- 共享状态模式（Shared-state）：用于协作式工作流，各智能体能基于彼此发现进行迭代深化
模式一：生成-验证模式
这是最基础的多智能体模式，也是部署最广泛的一种。我们在前文中将其称为"验证子智能体模式"，而本文采用更广义的"生成-验证"框架——因为生成者本身未必需要承担编排职能。
运作原理
生成器接收任务后产出初步结果，并将其提交给验证器进行评估。验证器检查输出是否符合既定标准，若通过则标记为完成；否则返回包含具体问题的反馈信息。当反馈被重新路由至生成器时，后者会据此调整策略并生成修订版本。此循环将持续直至验证器接受输出，或达到最大迭代次数限制。
适用场景
以客服邮件回复系统为例：生成器依据产品文档和工单上下文撰写初始回复；验证器则对照知识库核查准确性，按品牌指南评估语气，并确认是否完整回应所有诉求点。若发现错误（如将某项功能误归于错误价格档位），验证器会精准指出问题所在。
该模式适用于以下情形：输出质量至关重要，且评估标准可明确量化。在代码生成（一个智能体编写代码，另一个负责测试）、事实核查、评分制作业批改、合规性审查等场景中表现优异——任何领域只要错误成本高于额外生成轮次的代价，都值得采用此模式。
局限性
验证器的有效性完全取决于其判断标准。若仅告知"检查输出是否良好"而无具体维度要求，验证器就会沦为形式上的盖章工具。最常见的失败案例是未明确定义验证逻辑就启动循环，看似建立了质控体系实则形同虚设（我们在前文讨论过这种早期胜利陷阱）。
此外，该模式假设生成与验证属于不同技能范畴。若评估创意方案之难度不亚于创作本身，验证器可能无法有效识别潜在缺陷。
最后需注意迭代死锁风险：当生成器无法响应验证反馈时，系统将在无效循环中无限震荡。设置最大迭代次数并配套降级策略（转交人工处理/返回最佳尝试但附注说明）可有效规避此问题。
模式二：编排-子智能体模式
该模式建立在层级结构之上：一个主智能体扮演团队负责人角色，负责规划工作流、分配子任务并最终整合结果；子智能体则专注执行特定职责并汇报进展。
运作原理
主智能体接收顶层任务后制定执行策略：可能亲自处理部分子任务，同时向其他子智能体分发剩余工作。各子智能体完成任务后将结果回传，由主智能体最终合成统一输出。
Claude Code即采用此架构：主智能体直接编写代码、编辑文件并运行命令；当需要检索大型代码库或调查独立问题时，会后台调度专用子智能体——这样既能保持主要工作流的连续性，又能实现探索过程的并行化。每个子智能体在其独立上下文窗口内运作，仅返回提炼后的关键发现，从而确保主智能体的注意力始终聚焦于核心目标。
适用场景
以自动化代码审查系统为例：当拉取请求到达时，需依次检测安全漏洞、验证测试覆盖率、评估编码规范及架构一致性。这些检查相互独立，所需上下文各异，且均能产生结构化输出。主智能体可将每项检查分配给对应专家子智能体，收集结果后形成综合评审报告。
该模式适用于任务分解明确、子任务间耦合度低的情形：主智能体把控全局目标一致性，各子智能体则深耕细分领域。
局限性
主智能体成为信息瓶颈：当某个子智能体发现对其他子任务有价值的信息时（如安全检测员发现认证缺陷影响架构分析），必须经主智能体中转传递。随着此类跨任务信息流转增多，关键细节极易丢失或被过度简化。
串行执行也限制了吞吐量：除非显式并行化设计，否则子任务顺序执行意味着系统需承担多重智能体token开销却无速度优势。
模式三：智能体团队模式
当工作可拆解为长期独立运行的并行子任务时，编排-子智能体模式会变得过于僵化。
运作原理
协调器创建多个作为独立进程的工人智能体。团队成员从共享队列认领任务，自主完成多步骤工作后标记结束。
与编排-子智能体的本质区别在于工人智能体的持久性：后者为单次有界子任务临时创建，完成后立即销毁；而团队成员存活于整个生命周期，持续积累领域上下文与专业能力，随时间推移性能持续提升。协调器仅负责任务分配与结果收集，不会在每次任务间重置工人状态。
适用场景
以大型代码库迁移为例：每位成员可独立迁移单个服务模块（含自身依赖、测试套件及部署配置）。协调器将各服务指派给对应成员后，后者自主推进迁移流程（更新依赖→修改代码→修复测试→验证）。协调器最终收集已完成迁移并执行全系统集成测试。
该模式适用于子任务高度独立且需多步骤深度工作的场景：每个成员通过持续积累形成领域认知优势，远胜于一次性派遣的短期行为。
局限性
独立性是核心前提：不同于编排模式中主智能体可主动协调子智能体间的交互，团队成员完全自治，难以实时共享中间发现。若某成员的工作影响其他成员（如A修改了B依赖的接口），双方均不知情可能导致输出冲突。
完成度检测也更复杂：由于成员工作时长差异巨大（几分钟到几十分钟不等），协调器必须处理部分完成状态。
共享资源会加剧上述问题：当多个成员操作同一代码库/数据库/文件系统时，可能出现并发编辑冲突或互斥变更。因此必须精心设计任务划分策略并配备冲突解决机制。
模式四：消息总线模式
随着智能体数量增长及交互复杂度提升，直接协调变得难以维护。消息总线引入共享通信层，各智能体通过发布/订阅事件进行异步交互。
运作原理
智能体通过两个基本操作交互：发布与订阅。订阅者关注特定主题，路由器自动投递匹配消息。新增智能体只需注册相关主题即可接入现有网络，无需重构既有连接。
适用场景
安全运维自动化系统完美诠释了该模式的价值：来自多源的告警经分类代理按严重程度分流（高危网络告警转交网络调查代理，凭证类告警移交身份分析代理）；各调查代理可发布补充情报请求，由上下文采集代理响应；最终结果汇聚至响应协调代理决定处置措施。
该流水线天然契合消息总线模式：事件驱动的工作流、可扩展的智能体生态、各团队可独立开发部署新类型智能体。
适用于事件驱动型流水线——工作流程由事件触发而非预设序列决定，且智能体生态系统预期将持续扩展。
局限性
事件驱动的灵活性带来追踪难题：五跳级联事件中定位根因需精细日志记录与关联分析，远不如跟踪编排器的线性决策直观。
路由准确性同样关键：若路由器误判或丢弃事件，系统将静默失效——既无报错也不崩溃，只是什么都不处理。基于LLM的路由器虽具语义灵活性，但也引入了新的故障模式。
模式五：共享状态模式
前述四种模式中的编排器、团队领导及消息路由器均承担信息中心角色。共享状态模式则移除中介层，让智能体直接通过持久化存储（数据库/文件系统/文档）读写协作。
运作原理
智能体自主运行，直接从共享存储读取数据并写入新发现。无需中央协调器。各智能体检查存储中相关信息，采取行动后更新存储。工作流始于初始化步骤填充问题或数据集，终止条件包括：时间耗尽、收敛阈值达成，或由指定智能体判定存储已包含充分答案。
适用场景
以科研综述系统为例：文献调研、行业报告分析、专利检索、新闻监测四个智能体并行开展研究。某文献代理发现关键学者后，该信息应立即同步给行业分析代理——这正是共享状态的优势所在。各代理的发现直接写入共享库，形成动态演进的集体知识库。
该模式还消除了单点故障风险：任一代理宕机不影响其他代理继续读写。而在编排或消息总线系统中，协调器/路由器故障会导致整个系统停滞。
局限性
缺乏显式协调导致重复劳动或矛盾路径：两个代理可能独立调查同一线索。系统行为由智能体互动涌现而非顶层设计决定，结果可预测性降低。
更隐蔽的故障模式是反应性循环：A写发现→B读后写跟进→A见跟进又响应…系统持续消耗token做无效工作。虽然可通过加锁/版本控制/分区解决并发写入，但反应性循环属于行为学问题，必须内置终止条件：时间预算、收敛阈值（N轮无新发现）、或专职裁决代理判断存储是否足够。
模式选择与演进
正确选择取决于几个结构性问题：在前期文章中我们主张以上下文为中心的分解原则——按各智能体所需上下文划分工作而非按任务类型划分。这一原则同样适用于此处。不同模式在上下文边界管理与信息流控制方面存在显著差异。
编排-子智能体 vs. 智能体团队
两者都涉及协调器分发任务。关键差异在于工人是否需要维持长期上下文。
- 选择编排-子智能体当子任务短平快且产出明确（如代码审查系统中每项检查独立完成分析并返回报告）
- 选择智能体团队当子任务需持续多步深化（如代码库迁移中成员需熟悉服务依赖图、测试模式、部署配置等累积知识）
当子智能体需在多次调用间保留状态时，智能体团队更合适。
编排-子智能体 vs. 消息总线
两者都能处理多步骤流程。关键区别在于流程结构的确定性。
- 选择编排-子智能体当流程固定（如代码审查遵循收PR→跑检查→合成结果的固定管线）
- 选择消息总线当流程由事件驱动且可能动态变化（如安全运维系统无法预知告警类型及所需调查路径，新威胁出现需快速适配）
随着编排器中条件逻辑膨胀以应对复杂情况，消息总线能将路由逻辑显式化、模块化。
智能体团队 vs. 共享状态
两者都支持自主工作。关键问题在于是否需要实时共享中间发现。
- 选择智能体团队当各成员处理互不干扰的分区（如代码库迁移中各成员独立处理各自服务）
- 选择共享状态当工作需要实时协同（如科研综述中文献代理发现的学者信息应立即影响行业分析代理的调查方向）
当团队成员需要频繁交互而非仅共享最终结果时，共享状态更自然。
消息总线 vs. 共享状态
两者都支持复杂多智能体协作。关键区别在于工作流是离散事件流还是累积知识库构建。
- 选择消息总线当智能体响应事件流水线（如安全运维逐阶段处理告警事件）
- 选择共享状态当智能体持续构建集体知识（如科研综述系统不断积累新发现并调整后续调查）
消息总线仍依赖中心路由器，而共享状态是完全去中心化的。若消除单点故障是首要目标，共享状态更具优势。
若消息总线系统中的智能体本意是分享发现而非触发动作，则共享状态更合适。
实施建议
生产环境常混合使用多种模式：常见组合是用编排-子智能体管理主干流程，共享状态支撑高协作性子任务；或用消息总线路由事件，配合团队式工人处理各类事件。这些模式是积木式组件，非互斥选项。
下表总结各模式适用场景：
| 情境 | 推荐模式 |
|---|---|
| 质量敏感型输出，有明确评估标准 | 生成-验证 |
| 任务分解清晰，子任务有界 | 编排-子智能体 |
| 并行长周期独立子任务 | 智能体团队 |
| 事件驱动流水线，智能体生态扩展 | 消息总线 |
| 协作型研究，需实时共享发现 | 共享状态 |
| 要求消除单点故障 | 共享状态 |
多数场景建议从编排-子智能体起步——它能以最低协调成本覆盖最广问题域。观察其瓶颈后再针对性演进其他模式。
后续文章将深入剖析每种模式的生产级实现与典型案例。欲了解多智能体系统的投资价值，请参见构建多智能体系统：何时及如何使用它们。
致谢
由Cara Phillips主笔，Eugene Yang、Jiri De Jonghe、Samuel Weller及Erik Schluntz共同参与完善。