题记：本文编译自 Anthropic 博客《Multi-agent coordination patterns: Five approaches and when to use them》，由 Cara Phillips 撰写。
用一个 Agent 搞不定复杂任务？上多 Agent 吧。这个判断现在大家基本都认了。但上多 Agent 之后紧跟着一个更具体的问题：这些 Agent 之间怎么配合？
我之前写过 Anthropic 的 Harness 设计和 Managed Agents 架构，都涉及到多 Agent 的分工协作。但那两篇偏重怎么搭基础设施，没有系统聊过协调模式本身该怎么选。网上能找到的多 Agent 教程大多也停留在“拆任务 + 合结果”这个层面，对模式之间的取舍和演进路径讲得不多。Anthropic 刚发的这篇博客正好补了这个缺口，把多 Agent 协调归纳成五种模式，从最简单到最复杂，还给出了什么时候该从一种演进到另一种的判断标准。
读完最大的感受是：大部分团队的问题不是不知道多 Agent 的好处，而是上来就挑了一个听起来最酷的模式，结果被协调开销拖死了。Anthropic 的建议是，从最简单的能跑通的模式开始，看它哪里撑不住了，再往上演进。
模式一：生成-验证
这是最简单的多 Agent 模式，也是部署最广的。
逻辑很简单。一个 Agent 负责生成输出，另一个负责评估。评估通过就结束，不通过就把反馈打回给生成方，重新来一轮。循环下去直到通过或者达到最大迭代次数。
最典型的应用是代码生成：一个 Agent 写代码，另一个写测试、跑测试。客服场景也适用，生成方起草邮件回复，验证方检查是否准确引用了产品文档、是否回应了用户提到的每个问题。
这个模式看着简单，但踩坑的地方也很集中。
最常见的失败是验证标准太模糊。如果你只告诉验证方检查输出是否足够好，它大概率会糊弄人，放行所有东西。验证方的价值完全取决于你能不能把“好”拆成具体的、可检查的标准。
这一点在我之前写 Harness 设计那篇里也提过。Anthropic 的工程师 Prithvi 花了很多精力调教 Evaluator，反复看日志、找判断偏差、改 Prompt，来回迭代了好几轮才让它的评分标准达到合理水平。
另一个问题是迭代循环可能卡死。生成方解决不了验证方提的问题，两边来回震荡不收敛。所以必须设最大迭代次数，加一个兜底策略，比如升级给人处理，或者返回当前最好的版本并标注问题。
模式二：编排-子 Agent
这是层级式的分工。一个 Agent 当 Team Lead，负责规划任务、分配工作、汇总结果。子 Agent 接到具体任务后执行完就汇报。
Claude Code 用的就是这个模式。主 Agent 自己写代码、编辑文件、跑命令，需要搜索大型代码库或者调查独立问题时，就在后台派 subagent 去做，自己继续手头的活。每个 subagent 在自己的上下文窗口里工作，完成后把精炼过的结果返回给主 Agent。
这个模式适合任务拆分清晰、子任务之间依赖少的场景。比如自动化代码审查：一个 PR 进来，需要查安全漏洞、检查测试覆盖率、评估代码风格、验证架构一致性。每个检查维度独立、上下文不同、输出格式明确。编排 Agent 把每个检查派给专门的子 Agent，收集结果后合成一份统一的 Review。
问题出在信息瓶颈上。当子 Agent 发现了对其他子 Agent 有用的信息时，这条信息必须经过编排 Agent 中转。安全子 Agent 发现了一个认证漏洞，这个发现影响架构子 Agent 的分析。编排 Agent 需要识别这种依赖关系并正确路由信息。经过几轮中转之后，关键细节经常被丢失或者在摘要中被省略掉。
我在用 Claude Code 的 subagent 时也有类似体感。subagent 搜完代码库回来的结果有时候会把关键上下文压缩掉，主 Agent 拿到的是一个干净但不够完整的摘要。对于简单查询这不是问题，但对于需要子 Agent 之间共享发现的复杂任务，编排模式就开始吃力了。
模式三：Agent 团队
编排模式里的子 Agent 是用完即弃的。接到任务，干完活，交结果，走人。但如果任务需要 worker 在多轮中积累经验呢？
Agent 团队模式的区别就在这里：worker 是持久的。
一个协调者启动多个 worker Agent 作为独立进程。领任务，干活，交结果。不重置，不遗忘。每个 worker 在多轮迭代中积累对自己负责领域的熟悉度。
最直观的例子是大规模代码迁移。每个 worker 分管一个服务，在反复处理这个服务的依赖、测试、部署配置的过程中，逐渐摸清它的脾气。一次性 subagent 每次接手都要重新理解服务的配置约定和依赖关系，持久 worker 第一次弄明白之后后续迭代直接复用，省掉重复的上下文加载。
但独立性是硬前提。
团队模式里的 worker 没有中间人帮忙传话。一个 worker 的改动影响了另一个，谁都不知道，产出可能冲突。多个 worker 操作同一个代码库时尤其明显，常见的应对方式是文件级别的分区或者合并前跑冲突检测，但这增加了协调者的复杂度。完成时间的参差也是个问题，一个 worker 两分钟搞定，另一个要二十分钟，协调者得有耐心等。
模式四：消息总线
前面三种模式都有明确的协调者在指挥交通。但如果 Agent 数量继续增加、交互模式变得不可预测呢？
消息总线引入了一个共享通信层。核心操作就两个：发布和订阅。Agent 订阅自己关心的 topic，路由器负责分发。新 Agent 上线不需要改已有的连接，订阅相关 topic 就能开始接收工作。搞过微服务事件驱动架构的应该不陌生，本质上就是 Kafka 那套思路，只不过参与者从服务变成了 Agent。
Anthropic 举的例子是安全运维自动化。告警从多个来源进来，分诊 Agent 分类后路由给对应的调查 Agent，调查结果再流向响应协调 Agent。事件一个阶段接一个阶段地流下去，新出了什么威胁类型就加个新 Agent，各个 Agent 还能独立开发部署。
代价是可追溯性变差了。一个告警触发五个 Agent 之间的事件级联，要搞清楚到底发生了什么，调试难度比编排模式那种顺序决策链高了不少。路由器分错类或者丢了事件更麻烦，系统会静默失败，什么都不处理但也不崩溃。
模式五：共享状态
前四种模式里都有一个中心角色在管理信息流。共享状态模式把这个中间人去掉了。
没有中央协调者。Agent 自主运行，读写一个共享的数据库、文件系统或文档。工作一般从往存储里丢一个问题或数据集开始。停下来的条件有几种：时间到了、结果收敛了，或者有个专门的 Agent 判断存储里的东西已经够用了。
研究综合场景是这个模式的主场。多个 Agent 分头调查一个复杂问题的不同方面，学术 Agent 发现了一个关键研究者，这条信息对行业 Agent 调查这个研究者的公司立刻就有用。不用等协调者来路由，发现直接写进存储，其他 Agent 马上就能看到。附带好处是没有单点故障，任何一个 Agent 停了，其他 Agent 继续读写。
代价也很明显。Agent 可能重复工作或者走互相矛盾的方向。更棘手的是反应式循环：Agent A 写了一个发现，Agent B 读到后写了跟进，Agent A 看到跟进后又回应。系统持续烧 token 但不收敛。重复工作和并发写入有成熟的工程方案，加锁、版本控制、分区都行。但反应式循环是行为层面的问题，必须认真设计终止条件：时间预算、收敛阈值，或者专门的 Agent 来判断何时该停。
这个模式让我想到分布式系统里的最终一致性。没有强协调者的好处是吞吐量高、没有瓶颈，但你需要在应用层面处理冲突和收敛问题。Agent 领域也是同样的取舍。
怎么选，怎么演进
五种模式摆在面前，选哪个？Anthropic 给了几组对比的决策逻辑，我觉得最实用的是前两组。
编排-子 Agent vs Agent 团队
两者都有协调者分派工作，区别在于 worker 需要维持上下文多久。子任务短小、输出明确的，用编排模式。子任务需要多步骤持续工作、会从积累的上下文中受益的，用团队模式。判断标准是：当子 Agent 需要跨调用保留状态时，团队模式更合适。
我自己的经验也验证了这一点。Claude Code 日常的代码搜索、文件查阅用编排模式完全够用，subagent 干完就走。但之前写复杂 feature 的时候，需要多个 Agent 持续处理不同模块的开发和测试，编排模式的一次性 subagent 就不够用了，每次都要重新理解模块上下文。
编排-子 Agent vs 消息总线
两者都能处理多步骤工作流，区别在于工作流结构是否可预测。步骤顺序事先已知的，用编排模式。工作流由事件驱动、可能随发现变化的，用消息总线。有个经验法则：当编排 Agent 里的条件分支越来越多、需要处理越来越多的特殊情况时，就该考虑换消息总线了。
Agent 团队 vs 共享状态
各管各的互不交叉，用团队模式。发现需要实时流通，用共享状态。一旦 worker 之间需要互相沟通而不只是最后汇总结果，共享状态更自然。
消息总线 vs 共享状态
事件从一个阶段触发到下一个阶段然后完成的，用消息总线。Agent 在持续积累的知识基础上反复迭代的，用共享状态。还有一个值得留意的信号：如果消息总线里的 Agent 发布事件是为了分享发现而不是触发动作，那你可能需要的是共享状态。
写在最后
实际生产系统往往会混用多种模式。常见的组合是外层用编排-子 Agent 管整体工作流，内层某个协作密集的子任务用共享状态。或者外层用消息总线做事件路由，每种事件类型由一个 Agent 团队来处理。这五种模式是积木，不是互斥的选项。
Anthropic 的建议是从编排-子 Agent 开始。它能覆盖最广的问题范围，协调开销也最低。等它在特定场景下撑不住了，再根据具体瓶颈演进到其他模式。
Claude Code 就是编排-子 Agent 模式的典型实现，对大多数日常任务来说完全够用。只有当任务复杂到需要多个 Agent 持续协作、共享中间发现的时候，才值得引入更复杂的模式。
有意思的是，不同框架对协调模式的抽象思路差异很大。Anthropic 这套分类偏描述性，告诉你有哪些模式、怎么选。LangGraph 走的是 graph-based 的路子，用状态图来定义 Agent 之间的流转逻辑，更偏编程范式。CrewAI 则是角色分工优先，先定义 Agent 的角色和目标，协调模式隐含在角色关系里。三种抽象各有适用场景，但底层要解决的问题是一样的：谁跟谁通信、信息怎么流、什么时候该停。
相关资源：
- 原文链接：https://claude.com/blog/multi-agent-coordination-patterns
- 构建多 Agent 系统：https://claude.com/blog/building-multi-agent-systems-when-and-how-to-use-them
- Harness 设计：https://www.anthropic.com/engineering/harness-design-long-running-apps
- Managed Agents：https://www.anthropic.com/engineering/managed-agents
- 构建有效 Agent：https://www.anthropic.com/engineering/building-effective-agents
欢迎长按下面的二维码关注 Feisky 公众号，了解更多云原生和 AI 知识。
