在上一篇文章中，我们讨论了多Agent系统何时有价值，以及何时单Agent才是更好的选择。这篇面向的是已经决定采用多Agent方案，接下来需要决定到底该选哪一种协调模式的团队。
我们见过不少团队不是根据问题结构来选择模式，而是根据“听起来是否高级”来做决定。我们的建议是：先从最简单、但可能有效的模式开始，观察它卡在哪里，再从那里逐步演化。本文将逐一拆解五种模式的运作方式与适用场景：
- Generator-verifier：适用于输出质量要求极高、且评估标准可以明确写出来的场景。
- Orchestrator-subagent：适用于任务拆解清晰、子任务边界明确的场景。
- Agent teams：适用于并行、彼此独立、且持续时间较长的子任务。
- Message bus：适用于事件驱动的流水线，以及会持续扩张的Agent生态。
- Shared-state：适用于协作式工作，多个Agent需要基于彼此发现继续推进。
模式 1：Generator-verifier
这是最简单也是应用最广泛的多Agent模式之一。它在上一篇里被称为 verification subagent pattern（验证子Agent模式），但这里我们采用更广义的 generator-verifier 表述，因为负责生成结果的并不一定是orchestrator。
工作原理
一个生成器（generator）接到任务后，先生成初始输出，再把结果交给验证器（verifier）评估。verifier检查输出是否满足预设要求：如果满足，则接受并结束；如果不满足，则带着反馈驳回。generator根据反馈进行修订。这个循环持续进行，直到verifier接受输出，或达到预设的最大迭代次数。
适合场景
想象一个客服系统，需要自动为客户工单生成邮件回复。generator基于产品文档和工单上下文生成回复草案；verifier则对照知识库检查事实准确性，对照品牌规范检查语气，并确认是否回应了用户的所有问题。如果未通过，反馈会明确指出具体问题。
当输出质量非常关键，且评估标准可以写得很明确时，这种模式就很适用。它尤其适合代码生成（一个Agent写代码，另一个写并运行测试）、事实核验、基于rubric的打分、合规验证等“错误输出的代价高于多跑一轮生成”的场景。
潜在问题与局限
验证器能力的上限，取决于其掌握的评估标准。如果只告诉verifier“检查输出好不好”，却不给具体标准，它很可能流于形式。最常见的失败方式，就是实现了循环却从未认真定义“验证”到底意味着什么，这只能制造质量控制的幻觉。
该模式还隐含了一个前提：生成和验证是可分离的技能。如果评估一个创造性方案和提出方案本身一样难，那么verifier也未必能稳定地发现问题。
此外，迭代循环本身也可能卡住。如果generator无法有效回应反馈，系统就会来回振荡。因此，必须设置最大迭代次数，并配置兜底策略（如转人工处理或返回“当前最好版本”），以避免无限循环。
模式 2：Orchestrator-subagent
这种模式的核心是层级结构。一个Agent充当团队负责人（orchestrator），负责规划、分派任务并综合结果；子Agent（subagent）则承担具体职责并回报结果。
工作原理
一个主导Agent接收到任务后，规划如何处理。它可能自己完成部分子任务，同时将其他部分派发给子Agent。子Agent完成工作后返回结果，最后由orchestrator进行综合，形成最终输出。
Claude Code 就采用了这种模式。主Agent自己负责写代码、改文件、运行命令；当需要搜索大规模代码库或调查多个独立问题时，它会在后台分派子Agent，让主线工作继续推进，同时接收子Agent提炼后的结论。每个子Agent在独立的上下文窗口运行，只返回关键发现，从而确保orchestrator的上下文始终聚焦在主任务上。
适合场景
设想一个自动化代码评审系统。收到一个pull request后，系统需要检查安全漏洞、验证测试覆盖率、评估代码风格、判断架构一致性。每一项检查都很独立，需要不同上下文，输出也相对清晰。此时，一个orchestrator就可以将这些检查分派给不同的专家子Agent，收集结果后再综合成统一的评审结论。
当任务拆解足够清楚，且子任务间相互依赖很少时，这种模式就非常合适。orchestrator能维持整体目标的一致视角，而子Agent则专注于各自的责任领域。
潜在问题与局限
orchestrator很容易变成信息瓶颈。如果一个子Agent的发现关系到另一个子Agent的工作，这条信息必须先绕回orchestrator，再由它决定如何转发。转手次数一多，关键信息就容易丢失或被过度摘要。
此外，除非显式并行化，否则子Agent通常是顺序执行的。这样一来，你承担了多Agent的token成本，却拿不到并行带来的速度收益。
模式 3：Agent teams
当任务能被拆分成多个彼此独立、且能长时间并行推进的子任务时，orchestrator-subagent模式就可能显得束手束脚了。
工作原理
一个协调者（coordinator）启动多个工作者Agent（teammate），让它们作为独立进程持续存在。teammate从共享队列领取任务，围绕任务自主工作多个步骤，完成后发出信号。
它与orchestrator-subagent最大的区别在于worker的持续性。在后者中，子Agent为有边界的子任务而生，完成后即结束；而在agent teams中，teammate会跨多个任务持续存活，逐渐积累上下文和领域专长，从而提升表现。coordinator负责分配工作和收集结果，但不会在每次任务间重置worker。
适合场景
设想将一个大型代码库从某个框架迁移到另一个框架。每个服务（service）都可相对独立地迁移，有各自的依赖、测试套件和部署配置。coordinator将不同服务分派给不同的teammate，每个teammate围绕自己负责的服务自主推进迁移工作，最后coordinator收集所有结果并运行集成测试。
如果子任务彼此独立，且能从持续、分步骤的工作中受益，那么这种模式就很合适。每个teammate能逐渐建立自己负责领域的深度上下文。
潜在问题与局限
这套模式最关键的前提是：任务之间必须真正独立。在agent teams中，teammate是自主运作的，无法轻松共享中间发现。如果一个teammate的工作会影响到另一个而彼此不知情，最终输出就容易冲突。
另一个难点是完成检测更复杂。teammate以不同节奏工作，coordinator必须处理部分完成的情况。
共享资源会让问题加剧。多个teammate同时操作同一个代码库、数据库或文件系统，可能产生冲突。因此，这种模式需要谨慎的任务切分和明确的冲突解决机制。
模式 4：Message bus
当Agent数量增多、交互关系复杂时，直接协调会变得难以维护。Message bus 引入了一层共享通信层，让Agent通过发布和订阅事件来协作。
工作原理
Agent之间通过两个基本动作互动：publish（发布） 和 subscribe（订阅）。每个Agent订阅自己关心的话题，由路由器（router）将匹配的消息投递给它。这样，即使新增带有新能力的Agent，也无需重连已有结构，只需让其订阅相应主题即可。
适合场景
一个安全运营自动化系统能体现这种模式的优势。告警从多个来源涌入；一个分类（triage）Agent按严重程度和类型分类，将高严重度网络告警路由给网络调查Agent，将凭证相关告警路由给身份分析Agent。各调查Agent在需要时可继续发布信息补充请求，由负责收集上下文的Agent完成。调查发现再流向响应协调Agent，由其决定行动。
这种流水线很适合message bus，因为事件从一个阶段流向下一个阶段。随着威胁类别演化，团队可以不断新增Agent类型，各Agent也能独立开发、部署。
如果你的工作流由事件驱动自然生长，而非固定顺序；或预期Agent生态会持续扩张，那么这种模式很合适。
潜在问题与局限
事件驱动通信最大的代价是可追踪性变差。如果一个告警触发了五个Agent之间的一连串事件，要弄清发生了什么，必须有非常仔细的日志和关联机制。调试比跟踪orchestrator的顺序决策要难得多。
此外，路由准确率非常关键。一旦router错分或丢失事件，系统就会悄无声息地失效。基于LLM的router带来了语义灵活性，但也引入了新的失败模式。
模式 5：Shared state
前面几种模式中，orchestrator、team lead或message router本质上都在集中管理信息流。而 Shared state（共享状态） 移除了这个中间层，让Agent直接通过一个所有人都能读写的持久化存储来协作。
工作原理
多个Agent自主运行，直接读写共享数据库、文件系统或文档。没有中心协调者。Agent检查存储中是否有相关信息，基于读到的内容采取行动，再把自己的发现写回去。工作通常从一个初始化步骤开始（如放入一个问题），结束则依赖终止条件（如时间上限、收敛阈值，或由某个指定Agent判断“答案已足够”）。
适合场景
设想一个研究综合系统，需要多个Agent分别调查一个复杂问题的不同方面：一个查学术文献，一个分析行业报告，一个看专利申请，另一个盯新闻报道。每个Agent的发现都可能影响其他Agent的调查方向。
在shared state模式下，发现被直接写进共享存储。行业Agent可立刻看到学术Agent的发现，无需等待协调者转发。各Agent能建立在彼此工作之上继续推进，共享存储本身也逐渐演化为知识库。
Shared state还消除了协调者这个单点故障。一个Agent停掉，其他Agent仍可继续读写。而在orchestrator或message bus系统中，协调者一旦失效，整套系统就会停摆。
潜在问题与局限
没有显式协调时，Agent很容易重复劳动或采取矛盾路径。系统行为由Agent互动自然涌现，而非自上而下设计，结果更难预测。
更棘手的是反应式循环（reactive loops）。例如，Agent A写入一条发现，Agent B读到后写入后续结果，A看到后又继续回应。系统不断消耗token却不收敛。重复劳动和并发写入有成熟的工程手段处理（锁、版本控制等），但reactive loop是行为问题，必须把终止条件作为一等公民来设计。
如何在不同模式之间做选择与演化
哪种模式合适，取决于系统的结构性问题。我们在上一篇提过，拆解工作应采用以上下文为中心的思路：按每个Agent需要的上下文来拆。这个原则在此同样适用。不同模式的真正差异，在于它们如何管理上下文边界和处理信息流动。
Orchestrator-subagent vs. agent teams
两者都涉及由协调者分派工作。真正该问的问题是：worker需要把自己的上下文保留多久？
- 当子任务较短、聚焦，能产出清晰结果时，选 orchestrator-subagent。如代码评审系统，子Agent完成分析、产出报告后即结束，无需跨周期保留上下文。
- 当子任务能从持续、多步骤的工作中受益时，选 agent teams。如代码库迁移，每个teammate会逐渐熟悉自己负责的服务，这种积累的上下文是临时Agent难以替代的。
Orchestrator-subagent vs. message bus
这两种模式都能处理多步骤工作流。真正该问的问题是：工作流结构是否可预测？
- 当步骤顺序一开始就已知时，选 orchestrator-subagent。如固定的代码评审流水线。
- 当工作流由事件自然驱动、且会随发现而变化时，选 message bus。如安全运营系统，无法预知告警类型和调查路径，新的处理逻辑可以轻松加入。
Agent teams vs. shared state
两者都允许Agent自主工作。真正该问的问题是：Agent是否需要看到彼此的发现？
- 当Agent负责彼此分离、互不互动的分区任务时，选 agent teams。如代码库迁移，各teammate负责自己的服务。
- 当Agent的工作具有协作性，且彼此发现应实时流动时，选 shared state。如研究综合系统，一个Agent的发现会立刻影响另一个。
Message bus vs. shared state
两者都支持复杂协调。真正该问的问题是：工作是以离散事件流动，还是会沉淀成共享知识库？
- 当Agent围绕一连串事件做流水线式反应时，选 message bus。如逐阶段处理告警。
- 当Agent会随时间不断基于累积发现构建知识时，选 shared state。如研究综合系统持续沉淀知识。
Message bus仍依赖router，存在中心部件；shared state是去中心化的。如果你的优先级之一是消除单点故障，shared state更彻底。
如何开始
生产环境中的系统往往会混合多种模式。例如，整体工作流用orchestrator-subagent，在协作密集的子任务内部使用shared state；或用message bus负责事件路由，再用agent team风格的worker处理不同事件类型。
这些模式是构建模块，而非彼此排斥的单选题。
下表概括了每种模式的适用情况：
| 情况 |
适合的模式 |
| 输出质量要求极高，且评估标准明确 |
Generator-Verifier |
| 任务拆解清晰，子任务边界明确 |
Orchestrator-Subagent |
| 工作负载可并行，且子任务彼此独立、持续时间较长 |
Agent Teams |
| 工作流由事件驱动，Agent生态会持续增长 |
Message Bus |
| 协作式研究，多个Agent需要共享发现 |
Shared State |
| 需要消除单点故障 |
Shared State |
对于大多数场景，我们建议先从orchestrator-subagent开始。它以最小的协调开销覆盖了最广泛的问题类型。先观察它会卡在哪里，再随着具体需求逐步演化到其他模式。
在后续文章中，Claude官方会继续深入每个模式，给出生产级实现和案例分析。若想回看“什么时候多Agent值得投入”这个问题，可参见上一篇《精读Claude官方Agent博文：多 Agent 不是越多越好，先判断什么时候该用》。
对构建多Agent系统感兴趣，想深入交流架构设计与模式选择，欢迎来云栈社区的人工智能版块一起探讨。
发表于 6 小时前
|
查看: 8|
回复: 0
