在之前的文章中，我们探讨了多智能体系统何时能带来价值，何时单一智能体更为合适。本文面向已经决定采用多智能体系统的团队，帮助他们选择最适合自己问题的协调模式。
我们发现团队常常根据听起来复杂的方案来选择模式，而非根据实际问题需求。我们建议从最简单的可行模式开始，观察其不足之处，再逐步演进。本文将介绍五种模式的机制与局限：
- 生成-验证模式：适用于对输出质量要求极高且有明确评估标准的场景
- 协调者-子智能体模式：适合任务分解清晰且子任务有限的情况
- 智能体团队模式：适合并行、独立且长期运行的子任务
- 消息总线模式：适合事件驱动的流程，且智能体生态不断扩展
- 共享状态模式：适合智能体协作，彼此基于对方发现持续构建成果
模式一：生成-验证
这是最简单且应用最广泛的多智能体模式。我们之前称之为验证子智能体模式，这里用更广义的生成-验证来描述，因为生成者不一定是协调者。
工作原理
生成者接收任务，产生初步输出，交给验证者评估。验证者检查输出是否满足标准，若合格则接受，若不合格则反馈具体问题给生成者，生成者据此修正输出。该循环持续，直到验证者认可或达到最大迭代次数。
适用场景
例如客户支持系统自动生成邮件回复。生成者根据产品文档和工单上下文生成初稿，验证者核对知识库准确性、品牌语气规范，确认回复涵盖所有问题。若未通过，反馈具体错误，如功能归属错误或遗漏问题。
此模式适合输出质量关键且评估标准明确的场景，如代码生成（一个智能体写代码，另一个写测试并运行）、事实核查、基于评分标准的评分、合规验证等，错误成本高于多次生成成本时尤为有效。
局限性
验证者的能力取决于评估标准。若只检查“是否好”，无具体标准，验证者可能放行所有输出，造成虚假的质量保障。团队常见失败是未定义验证标准，导致循环无实质效果。
此外，生成与验证需是可分离技能。若创意评估难度与生成相当，验证者可能难以发现问题。
迭代循环可能陷入停滞，若生成者无法解决反馈，系统会反复震荡。设置最大迭代次数及后备方案（如人工介入或返回最佳结果并附带说明）可避免无限循环。
模式二：协调者-子智能体
该模式基于层级结构。一个智能体作为团队负责人，规划任务、分派子任务并整合结果。子智能体负责具体职责并反馈。
工作原理
协调者接收任务，决定处理方案。部分子任务由自身完成，部分委派给子智能体。子智能体完成任务后返回结果，协调者整合成最终输出。
Claude Code采用此模式。主智能体负责写代码、编辑文件、运行命令，后台派遣子智能体处理大规模代码库搜索或独立问题调查，保持主任务上下文专注，探索并行进行。
适用场景
例如自动代码审查系统。收到拉取请求后，需检查安全漏洞、测试覆盖率、代码风格、架构一致性等。每项检查独立，需不同上下文，输出明确。协调者派发给专门子智能体，收集结果后综合评审。
适合任务分解明确、子任务相互依赖少的场景。协调者保持整体目标视角，子智能体专注具体职责。
局限性
协调者可能成为信息瓶颈。若子智能体发现对其他子智能体有影响的信息，需通过协调者转发，信息多次传递后可能丢失或简化。
顺序执行限制吞吐量。若无显式并行，子智能体依次运行，增加多智能体成本却无速度优势。
模式三：智能体团队
当任务分解为可独立并行且长期运行的子任务时，协调者-子智能体模式可能过于受限。
工作原理
协调者启动多个工作智能体作为独立进程。团队成员从共享队列领取任务，独立多步骤完成并报告完成。
区别于协调者-子智能体的是工作智能体的持久性。协调者为单个有限子任务启动子智能体，任务完成即终止。团队成员持续存在，积累上下文和领域专长，提升表现。协调者分配任务并收集结果，但不重置工作智能体。
适用场景
例如将大型代码库从一个框架迁移到另一个。每个团队成员独立迁移一个服务，处理依赖、测试、部署配置。协调者分配服务，团队成员自主完成迁移，协调者收集结果并执行集成测试。
适合子任务独立且需持续多步骤工作的场景。团队成员积累领域上下文，而非每次任务重头开始。
局限性
独立性是关键。与协调者-子智能体不同，团队成员无法轻易共享中间发现。若一个成员工作影响另一个，双方可能不知情，输出冲突。
完成检测更难。团队成员工作时长不一，协调者需处理部分完成情况。
共享资源加剧问题。多个成员操作同一代码库、数据库或文件系统，可能出现冲突修改。需精细任务划分和冲突解决机制。
模式四：消息总线
随着智能体数量增加，交互模式复杂，直接协调难以管理。消息总线引入共享通信层，智能体通过发布订阅事件交互。
工作原理
智能体通过发布和订阅两种操作交互。智能体订阅感兴趣的主题，路由器负责传递匹配消息。新智能体可无须重连即可接收相关任务。
适用场景
例如安全运营自动化系统。来自多个来源的警报由分诊智能体分类，严重网络警报路由到网络调查智能体，凭证相关警报路由到身份分析智能体。调查智能体发布补充请求，由上下文收集智能体完成。结果流向响应协调智能体决定行动。
该流程适合消息总线，事件从一阶段流向下一阶段，团队可随威胁类别演变添加新智能体，且智能体可独立开发部署。
适合事件驱动流程，工作流由事件驱动而非预设顺序，且智能体生态可能扩展。
局限性
事件驱动通信灵活但追踪困难。警报触发五个智能体的事件链，需详尽日志和关联分析。调试难度大于顺序协调。
路由准确性关键。路由器若误判或丢弃事件，系统静默失败，无法处理但不崩溃。基于大模型的路由器语义灵活但有自身故障风险。
模式五：共享状态
前述模式中协调者、团队负责人和消息路由器均集中管理信息流。共享状态模式取消中介，智能体通过可读写的持久存储直接协调。
工作原理
智能体自主操作，读写共享数据库、文件系统或文档。无中央协调者。智能体检查存储中的相关信息，基于发现采取行动，并写回结果。工作通常从初始化步骤开始，存入问题或数据集，结束于终止条件，如时间限制、收敛阈值或指定智能体判定答案充分。
适用场景
例如研究综合系统，多智能体分别调查复杂问题的不同方面。一智能体研究学术文献，另一分析行业报告，第三审查专利，第四监控新闻。各智能体发现可相互启发，如学术智能体发现关键研究者，行业智能体据此深入调查。
共享状态使发现直接写入存储，其他智能体即时可见，无需协调者转发。智能体基于彼此成果持续构建，存储成为不断演进的知识库。
共享状态消除协调者单点故障。任一智能体停止，其他仍能读写。协调者或路由器故障则整个系统停摆。
局限性
无显式协调，智能体可能重复工作或采取矛盾策略。两个智能体可能独立调查同一线索。智能体交互产生系统行为，非自上而下设计，结果难以预测。
更难处理的是反应循环。例如智能体A写入发现，智能体B读取后写入后续，智能体A再响应，系统不断消耗资源但无收敛。重复工作和并发写入有工程解决方案（锁、版本控制、分区），反应循环是行为问题，需明确终止条件：时间预算、收敛阈值（N轮无新发现）、或指定智能体判定答案充分。忽视终止条件的系统易无限循环或因上下文溢出任意停止。
模式选择与演进
合适模式取决于系统结构性问题。我们之前提出以上下文为中心的分解原则，即按智能体所需上下文划分工作，而非工作类型。各模式区别在于如何管理上下文边界和信息流。
协调者-子智能体 vs 智能体团队
两者均由协调者分配任务，关键在于工作智能体需维持上下文的时间长度。
- 选择协调者-子智能体：子任务短小、聚焦、输出明确。代码审查系统适合此模式，每项检查独立完成并返回结果，无需跨多轮保持上下文。
- 选择智能体团队：子任务需持续多步骤工作。代码库迁移适合此模式，团队成员积累对服务的深入理解，提升表现。
子智能体需跨调用保持状态时，智能体团队更合适。
协调者-子智能体 vs 消息总线
两者均支持多步骤工作流，区别在于工作流结构的可预测性。
- 选择协调者-子智能体：步骤顺序预先确定。代码审查系统遵循固定流程：接收PR、运行检查、综合结果。
- 选择消息总线：工作流由事件驱动，基于发现动态变化。安全运营系统无法预测警报类型和调查路径，消息总线支持灵活路由和扩展。
随着协调者中条件逻辑增多，消息总线使路由更显式和可扩展。
智能体团队 vs 共享状态
两者均为智能体自主工作，区别在于是否需要彼此发现。
- 选择智能体团队：智能体处理独立分区，无需交互。代码库迁移适合此模式，团队成员独立处理服务，协调者汇总结果。
- 选择共享状态：智能体协作，发现需实时共享。研究综合系统更适合，学术智能体发现即时影响行业智能体调查。
当团队成员需相互通信而非仅共享最终结果时，共享状态更自然。
消息总线 vs 共享状态
两者均支持复杂多智能体协调，区别在于工作是离散事件流还是累积知识库。
- 选择消息总线：智能体响应流水线事件。安全运营系统阶段性处理警报，事件触发下一阶段，路由高效。
- 选择共享状态：智能体基于累积发现持续构建。研究综合系统持续收集知识，智能体反复访问存储，调整调查。
消息总线有路由器，中心化决定事件流向。共享状态去中心化，若优先消除单点故障，共享状态更优。
若消息总线系统中智能体发布事件仅为共享发现而非触发动作，共享状态更合适。
入门建议
生产系统常结合多种模式。常见混合是整体流程用协调者-子智能体，协作密集子任务用共享状态；或消息总线路由事件，智能体团队处理各事件类型。这些模式是构建模块，非互斥选择。
下表总结各模式适用场景。大多数用例建议从协调者-子智能体开始，因其覆盖面广且协调开销低。观察其不足，再根据需求演进至其他模式。
未来文章将深入探讨各模式的生产实现与案例。关于多智能体系统何时值得投入，详见多智能体系统构建：何时及如何使用。
致谢
本文由Cara Phillips撰写，Eugene Yang、Jiri De Jonghe、Samuel Weller和Erik Schluntz贡献内容。
