多Agent协作的7种模式：从顺序链到A2A协议，你该用哪种？

程序猿李巡天

347人浏览 · 2026-06-13 20:32:09

程序猿李巡天 · 2026-06-13 20:32:09 发布

搭了个多Agent系统，三个Agent分工明确，跑起来一看——Agent A的输出Agent B没收到，Agent C等半天还没开始，编排器把简单任务拆成了5步，并行执行的结果没人合并。

问题不是Agent能力不够，是协作模式选错了。我见过一个团队花了两周搭编排者-工作者架构，最后发现顺序链就够了——白白浪费了两周。

顺序链、路由分发、编排者-工作者、并行执行、评估循环、图工作流、A2A协议互联——每种模式解决不同的问题。选错了，要么过度复杂，要么协作失灵。

这篇文章从Anthropic、OpenAI、Google、CrewAI、A2A五大官方来源提取出7种核心协作模式，告诉你每种模式干什么、什么时候用、各框架怎么实现。

一、为什么需要7种模式？

很多人把"多Agent"等同于"编排器+子Agent"，但这个理解只覆盖了其中一种模式。

Anthropic在《Building Effective Agents》里把这个分得很清楚：他们把所有变体统称为agentic systems，但区分了两大类——

Workflows：LLM和工具通过预定义代码路径编排，流程是固定的
Agents：LLM自主决定流程和工具使用，动态规划

这个区分很关键。Workflows适合你能预判流程的场景，Agents适合你无法预判的场景。而现实中，多数系统介于两者之间——核心流程固定，局部动态。

7种模式不是7个独立选项，而是从最简单到最复杂的渐进阶梯。Anthropic说得很直白：“Keep it simple. Only increase complexity when it demonstrably improves outcomes.”

二、模式1：顺序链（Sequential/Prompt Chaining）

干什么

任务按固定顺序执行，前一步的输出自动成为后一步的输入。A→B→C，不需要任何调度器。

各框架实现

框架	术语	实现
Anthropic	Prompt Chaining	直接用LLM API串行调用，中间可加程序化检查（gate）
Google ADK	SequentialAgent	`SequentialAgent(sub_agents=[agent1, agent2])`
CrewAI	Sequential Process	按Task列表顺序执行，`context`参数可自定义上下文来源
OpenAI	代码编排链式调用	一个Agent输出转下一个输入，Python顺序执行

什么时候用

任务可以清晰拆成固定步骤
每一步有明确的输入输出格式
中间需要质量检查（gate）

实际案例

内容创作流水线：研究Agent收集素材 → 写作Agent生成初稿 → 审校Agent检查事实和语法 → 发布Agent排版输出。每一步都可以加检查——比如审校Agent发现事实错误，直接回退到研究Agent。

深坑

延迟叠加：每一步都要等上一步完成，链越长越慢
错误传播：第一步出错，后面全跟着错，没有自动纠偏机制
过度拆分：3步能搞定的事拆成7步，中间步骤的prompt设计和格式转换全是负担

三、模式2：路由分发（Routing/Handoff）

干什么

一个分类Agent（或路由器）判断输入属于哪个领域，然后转交给对应的专家Agent处理。

各框架实现

框架	术语	实现
Anthropic	Routing	分类器LLM判断类别，导向专门的后续处理
OpenAI	Handoffs	`handoff(agent=refund_agent)`，自动生成`transfer_to_refund_agent`工具
Google ADK	RouterAgent（实验性）	`RouterAgent(agents=[primary, fallback], strategy="fallback")`
CrewAI	Hierarchical中的manager	manager根据Agent能力动态委派，但更接近编排者-工作者而非纯路由

OpenAI Handoff的关键设计

OpenAI的Handoff机制是目前最精细的路由实现：

控制权转移：新Agent接管对话，不像"Agent as Tool"那样返回后控制权回到原Agent
Input Filter：可以过滤对话历史，不让新Agent看到敏感信息
Handoff Inputs：模型在转交时可以携带元数据（如升级原因reason、语言language）
嵌套历史：将之前的对话折叠为一条摘要，避免历史过长

# OpenAI Handoff 示例"Triage agent"

什么时候用

不同类别的输入需要完全不同的处理方式
专家Agent之间不需要协作，只需要独立处理各自领域
客服场景是经典案例：退款、账单、技术支持各有专家

深坑

分类不准：路由器判断错误，任务交给不合适的Agent，结果更糟
Handoff循环：Agent A handoff给B，B又handoff给A，无限循环
上下文丢失：Handoff时对话历史可能被截断，新Agent缺少关键信息

四、模式3：并行执行（Parallelization）

干什么

多个Agent同时执行，结果在最后合并。有两种变体——

分片（Sectioning）：把大任务拆成独立子任务并行执行
投票（Voting）：同一个任务交给多个Agent，取多数一致或最优结果

各框架实现

框架	术语	实现
Anthropic	Parallelization	Sectioning拆分 + Voting投票
Google ADK	ParallelAgent	`ParallelAgent(sub_agents=[agent_a, agent_b])`
OpenAI	代码编排	`asyncio.gather`并行调用多个Agent

什么时候用

子任务之间完全独立，没有依赖关系
需要加速执行（多个子任务同时跑）
需要多视角验证（多个Agent独立判断，降低单点错误）

实际案例

代码审查：安全Agent查漏洞 + 性能Agent查瓶颈 + 风格Agent查规范，三个Agent并行执行，结果合并成一份完整审查报告。

情报分析：3个Agent分别从技术、商业、法律角度分析同一份报告，投票取共识。

深坑

结果合并困难：并行Agent输出格式不同，合并需要额外编排逻辑
资源消耗：多个Agent同时运行，token成本翻倍
冗余浪费：Voting场景下，多数Agent做的是同样的工作

五、模式4：编排者-工作者（Orchestrator-Workers）

干什么

这是大多数人理解的"多Agent"——中央编排器动态分析任务，决定拆成几个子任务、分给哪些工作者Agent，最后综合结果。

关键区别：子任务不是预先定义的，而是编排器根据输入动态决定的。

各框架实现

框架	术语	实现
Anthropic	Orchestrator-Workers	中央LLM动态拆任务、委派worker LLMs、综合结果
OpenAI	Agents as Tools	`Agent.as_tool()`，编排Agent保持对话控制权，调用专家Agent作为工具
CrewAI	Hierarchical Process	必须指定`manager_llm`，管理者动态委派+审核验证
Google ADK	Collaborative Workflows	单个Agent作为动态协调者，与一组指定sub-agents协作

Anthropic vs OpenAI的关键差异

维度	Anthropic Orchestrator-Workers	OpenAI Agents as Tools
控制权	编排器始终掌控	编排Agent始终掌控对话
专家角色	Worker LLM独立完成子任务	专家Agent作为工具被调用
对话历史	Worker不继承完整对话	被调用Agent不继承对话历史
适用	子任务动态变化、结果需要综合	需要合并多个专家输出、执行共享护栏

什么时候用

无法预测子任务的数量和性质（比如编码时需修改的文件数取决于具体任务）
需要一个Agent统筹全局、合并多个专家结果
复杂搜索任务：从多个来源收集和分析信息

深坑

编排器过载：所有决策压在一个Agent上，编排器本身可能出错或超时
Worker结果质量参差：不同Worker返回的结果格式和质量不统一，合并困难
成本失控：动态拆任务意味着每次执行的子任务数量不同，成本难以预估

六、模式5：评估-优化循环（Evaluator-Optimizer / Loop）

干什么

一个Agent生成结果，另一个Agent评估并给出反馈，循环迭代直到结果达标。

各框架实现

框架	术语	实现
Anthropic	Evaluator-Optimizer	生成Agent + 评估Agent循环迭代
Google ADK	LoopAgent	`LoopAgent(sub_agents=[reviewer], max_iterations=3)`

什么时候用

有明确的评估标准（代码必须通过测试、文案必须满足事实准确率）
单次生成不够可靠，迭代改进有明显价值
代码生成场景是经典案例：生成→测试→修改→再测试

深坑

循环不收敛：评估Agent和生成Agent来回扯皮，永远不达标——我实际跑过Evaluator-Optimizer，3次迭代就能收敛的算是运气好，5次以上才收敛的比想象中多
必须设上限：max_iterations是必需的，否则可能无限循环烧token
评估标准模糊：如果评估Agent的标准不明确，循环变成"我觉得还行" vs “我觉得不行”

七、模式6：图工作流（Graph Workflows）

干什么

用有向图（DAG）定义执行路径——支持条件分支、循环、并行、顺序的任意组合。这是最灵活的模式，但也是最复杂的。

各框架实现

框架	术语	实现
Google ADK 2.0	Graph Workflows	`Graph` + `Node` + 条件路由
LangGraph	StateGraph	基于状态图的节点+边+条件分支

Google ADK 2.0的Graph示例（基于官方架构推断）

"my_workflow""start""process""start""process""start""process"lambda"needs_processing"

什么时候用

流程有条件分支（根据中间结果走不同路径）
需要混合顺序+并行+循环
工作流本身很稳定，但路径选择需要动态判断

深坑

过度设计：简单任务用图工作流是杀鸡用牛刀
调试地狱：图越复杂，调试越难——哪个节点出了问题？哪个分支走错了？
状态管理：每个节点之间的状态传递需要精心设计，否则信息丢失

八、模式7：A2A协议互联（Protocol Interop）

干什么

前面6种模式都是在同一个框架内协作。A2A协议解决的是跨框架问题——不同团队用不同框架开发的Agent，如何互相通信协作？

Google的A2A（Agent-to-Agent）协议是一个开放协议，让Agent通过JSON-RPC 2.0通信，无需暴露内部状态、记忆或工具。

A2A vs MCP：不是替代，是互补

维度	MCP	A2A
连接对象	Agent → 工具/资源	Agent → Agent
交互方式	函数调用（结构化输入输出）	对话式（多轮、有状态）
对象特征	无状态、明确定义	自主、有状态、可推理
协议层	Agent内部工具集成	Agent间高层协作

类比：MCP是Agent的手（连接工具干活），A2A是Agent的嘴（跟其他Agent商量）。

一个客服系统的完整架构：

用户 → 客服Agent（A2A交互）
客服Agent → 账单Agent（A2A协作）
账单Agent → 数据库查询工具（MCP调用）
账单Agent → 零件供应商Agent（A2A协作）

什么时候用

不同团队用不同框架（LangChain团队 vs Dify团队）
需要跨组织Agent协作（供应商Agent对接采购Agent）
Agent需要保持不透明（不暴露内部逻辑和记忆）

深坑

通信延迟：Agent间多轮对话比单次函数调用慢得多
发现机制：Agent Card描述能力，但描述可能不准确或不完整
安全边界：跨组织协作需要认证和权限控制，A2A目前这方面还在演进

九、选型决策树

不要一上来就用编排者-工作者。Anthropic说得对：能用简单模式解决的，别用复杂模式。

你的任务能拆成固定步骤吗？

    ├─ YES → 顺序链（模式1）

    │    └─ 中间需要质量检查？ → 加gate

    │    └─ 不同步骤需要不同专家？ → 路由分发（模式2）

    │

    └─ NO → 子任务之间独立吗？

        ├─ YES → 并行执行（模式3）

        │    └─ 需要多视角验证？ → Voting变体

        │

        ├─ NO → 子任务数量能预判吗？

            ├─ YES → 图工作流（模式6）

            │

            ├─ NO → 编排者-工作者（模式4）

            │    └─ 结果需要迭代优化？ → 加评估循环（模式5）

            │

            └─ 跨框架协作？ → A2A协议（模式7）

核心原则：

单Agent+好prompt能解决的，别搞多Agent
顺序链能解决的，别搞编排器
路由分发能解决的，别搞图工作流
同框架内能解决的，别引入A2A

十、各框架全览

模式	Anthropic	OpenAI	Google ADK	CrewAI	A2A
顺序链	Prompt Chaining	代码编排链式调用	SequentialAgent	Sequential Process	—
路由分发	Routing	Handoffs	RouterAgent(实验)	—	Agent Card发现
并行执行	Parallelization	Python asyncio(非SDK原生)	ParallelAgent	—	—
编排者-工作者	Orchestrator-Workers	Agents as Tools	Collaborative	Hierarchical	—
评估循环	Evaluator-Optimizer	while循环+评估Agent	LoopAgent	—	—
图工作流	—	—	Graph(ADK 2.0)	—	—
协议互联	—	—	—	—	A2A JSON-RPC

注：CrewAI的Hierarchical Process同时覆盖路由分发和编排者-工作者两种模式——manager既做路由决策也做任务委派。OpenAI的并行执行依赖Python原生并发（asyncio.gather），不是SDK内置模式。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～