Agent 协作正在从一个工程问题，变成一个产品架构问题。
过去讨论多 Agent，很多人会想到一个简单画面：拉一个群，把几个 Agent 丢进去，让它们互相讨论，最后得出一个答案。
但真实的 Agent 协作远不止如此。
如果只是让多个 Agent 一起说话，本质上仍然是“群聊式智能”。它可能适合头脑风暴、观点碰撞、方案讨论，但很难支撑真实组织里的复杂任务交付。
真实工作里的协作，关心的不是谁说了什么，而是：
谁来负责？
谁来拆任务？
谁来执行？
谁来审核？
谁来拍板？
上下文怎么流动？
过程怎么追踪？
失败怎么恢复？
结果怎么验收？
经验怎么沉淀？
所以，Agent 协作设计的关键，不是简单回答“到底有几种协作模式”，而是要先建立一个更底层的分类框架。
本文提出一个三层范式：
Agent 协作设计模式 = 执行层 × 控制层 × 验收层
执行层决定任务怎么跑。
控制层决定谁来调度。
验收层决定结果如何被判断。
只有把这三层分清楚，才能从“多 Agent 群聊”走向真正可生产、可追踪、可验收的 Agent 协作系统。
一、为什么不能只用“六种协作模式”理解 Agent 协作？
最近很多产品开始把 Agent 协作总结为几种常见模式，比如 Solo、Roundtable、Critic、Pipeline、Split、Swarm。
这类总结很有价值，因为它把多 Agent 从抽象概念变成了可理解的产品入口。
但从生产级设计看，这还不够。
原因很简单：这些模式混合了不同维度。
例如：
Pipeline 讲的是任务执行顺序。
Roundtable 讲的是多角色讨论方式。
Critic 讲的是质量审核机制。
Swarm 讲的是多个候选方案竞争。
Supervisor-Worker 讲的是控制权结构。
Human-in-the-loop 讲的是人类验收节点。
它们不是同一层级的概念。
如果不拆层，就会出现设计混乱：
明明需要的是 Pipeline，产品却做成了 Roundtable；
明明需要的是 Critic，系统却让同一个 Agent 自己生成、自己审核；
明明是高风险任务，却没有 Human Review；
明明只是一个简单任务，却为了“多 Agent 感”强行启动一堆 Agent，导致成本、延迟和错误传播同时上升。
OpenAI Agents SDK 官方文档把 orchestration 定义为 Agent 在应用中的流动方式：哪些 Agent 运行、以什么顺序运行、如何决定下一步；并明确提出两类编排方式：让 LLM 自主决策，或者由代码确定流程。这个划分说明，多 Agent 不是单一模式，而是控制权、流程和决策机制的组合问题。
Google Agent Development Kit 也把多 Agent 设计总结成多种模式，包括 Sequential Pipeline、Coordinator / Dispatcher、Parallel Fan-out / Gather、Hierarchical Decomposition、Generator-Critic、Iterative Refinement、Human-in-the-loop 等。这进一步说明，多 Agent 协作本质上是一组可组合的工程与产品模式，而不是一个固定枚举。
因此，更合理的方式是把 Agent 协作拆成三层。
二、三层范式：执行层、控制层、验收层
1. 执行层：任务怎么跑？
执行层回答的是：
这个任务应该以什么结构被完成？
常见模式包括：
| 执行模式 | 核心问题 | 适合场景 |
|---|---|---|
| Solo | 一个 Agent 能不能独立完成？ | 简单任务、低风险任务 |
| Pipeline | 是否有明确先后步骤？ | 内容生产、数据处理、代码流程 |
| Split / Fan-out | 子任务能不能并行拆分？ | 研究、竞品分析、资料处理 |
| Swarm | 是否需要多个候选方案竞争？ | 命名、标题、创意、视觉方向 |
| Iterative Refinement | 是否需要多轮打磨？ | 高质量文章、方案、代码优化 |
| Hierarchical Decomposition | 是否是长周期复杂任务？ | 企业流程、长任务、复杂项目 |
执行层的核心不是“让 Agent 更多”，而是选择最合适的任务结构。
简单任务应该 Solo。
标准流程应该 Pipeline。
大任务应该 Split。
创意任务可以 Swarm。
高质量任务需要 Iterative Refinement。
长周期复杂任务需要 Hierarchical Decomposition。
2. 控制层：谁来调度？
控制层回答的是：
谁拥有流程控制权？
常见模式包括：
| 控制模式 | 核心结构 | 适合场景 |
|---|---|---|
| Router / Dispatcher | 入口 Agent 判断意图并分派 | 客服、企业助手、多能力入口 |
| Supervisor-Worker | 主管 Agent 调度多个执行 Agent | 复杂任务、研究报告、代码任务 |
| Handoff | 当前 Agent 把控制权交给另一个 Agent | 多轮对话、跨领域咨询 |
| Group Chat / Roundtable | 多个 Agent 公开讨论 | 战略判断、产品评审、头脑风暴 |
| Agent-as-Tool | 主 Agent 把其他 Agent 当工具调用 | 可审计、可控的多专家系统 |
LangChain 官方文档把多 Agent 模式拆成 Subagents、Handoffs、Skills、Router 等；其中 Subagents 是主 Agent 把子 Agent 当工具协调，Handoffs 则是 Agent 之间转移控制权。这个区分很重要：前者是中心化调度，后者是动态接力。
OpenAI Agents SDK 也明确提到 agents-as-tools 和 handoffs 两类常见编排方式：前者适合由一个 manager agent 保持控制并统一输出，后者适合把对话控制权交给更合适的 specialist。
控制层的关键是：不要让责任消失。
生产级 Agent 系统里，最危险的不是 Agent 不够多，而是每个 Agent 都参与了，但没有一个主体负责最终结果。
因此，复杂任务默认应该优先使用 Supervisor-Worker，而不是纯 Roundtable。
3. 验收层：结果怎么判断？
验收层回答的是：
这个结果凭什么算完成？谁来判断它好不好？
常见模式包括：
| 验收模式 | 核心机制 | 适合场景 |
|---|---|---|
| Generator-Critic | 一个生成，一个审核 | 代码审查、事实核查、内容质检 |
| Evaluator | 用规则、模型或指标评估结果 | Swarm 择优、自动化评测 |
| Human-in-the-loop | 人类在关键节点审批 | 发布、部署、付款、客户交付 |
| Guardrails | 安全、合规、权限边界 | 企业系统、敏感操作 |
| Acceptance Criteria | 明确验收标准 | 所有可交付任务 |
Google ADK 把 Generator-Critic 和 Human-in-the-loop 都列为关键多 Agent 模式。前者强调生成与审核分离，后者强调在高风险节点引入人类确认。
这一层经常被低估。
很多 Agent 产品失败，不是因为不会生成，而是因为不会验收。
Agent 能生成一份报告，不代表报告可信。
Agent 能写一段代码，不代表代码可合并。
Agent 能产出一个方案，不代表方案符合业务目标。
Agent 能自动执行任务，不代表它应该被允许自动完成高风险动作。
所以，生产级 Agent 协作必须有验收层。
没有验收层的多 Agent，本质上只是多个模型在堆输出；有验收层的多 Agent，才开始接近真实工作流。
三、三层组合以后，才是真正的 Agent 协作模式
很多人问：Agent 协作到底有几种？
更准确的答案是：
单独看，常见模式大概有 10–12 种；真实产品里，它们往往不是单独出现，而是三层组合。
例如，一个高质量研究报告任务，不应该只是“多个 Agent 讨论一下”。
更合理的组合是：
执行层：Split 并行调研 + Pipeline 写作
控制层：Supervisor-Worker 统一调度
验收层：Critic 审查 + Human Review 最终确认一个产品命名任务，则可能是：
执行层：Swarm 多方案生成
控制层：Supervisor 汇总
验收层：Evaluator 打分 + Human 选择一个代码修复任务，则可能是：
执行层：Pipeline 修复流程
控制层：Supervisor 调度 Code Agent / Test Agent
验收层：Critic Review + 测试验证 + Human Merge一个企业客服任务，则可能是：
执行层：Solo 或 Pipeline
控制层：Router / Handoff
验收层：权限校验 + 必要时人工接管这就是三层范式的价值。
它把“模式枚举”升级为“模式组合”。
四、Agent 协作的 12 个核心模式
下面是一个更完整的模式库。
1. Solo：单 Agent 独立完成
Solo 是最基础模式。它适合边界明确、风险较低、上下文简单的任务。
典型场景：
- 改写一段文案
- 总结一篇文章
- 生成一段代码注释
- 转换格式
- 简单问答
Solo 的优点是速度快、成本低、上下文简单。缺点是缺少制衡，容易自信错误。
产品设计建议：
不要为了多 Agent 而多 Agent。低风险任务默认 Solo。
2. Router / Dispatcher：路由分发
Router 负责判断用户意图，并把任务分派给最合适的专家 Agent。
典型场景：
- 企业助手
- 客服系统
- 内部知识库
- 多能力 Agent 入口
- 工具调用路由
Google ADK 将 Coordinator / Dispatcher 描述为一个中心 Agent 接收请求，并根据意图分派给专业 Agent。
产品设计建议：
用户不应该先理解系统里有哪些 Agent。系统应该先理解用户要做什么，再自动选择合适的 Agent 或协作模式。
3. Supervisor-Worker：主管-工人
Supervisor 负责拆任务、分配任务、收集结果、合成最终输出。Worker 负责局部执行。
典型场景：
- 研究报告
- 复杂内容生产
- 多模块代码任务
- 产品方案
- 运营项目
OpenAI Cookbook 中的多 Agent 组合示例强调 agents-as-tools 模式，适合透明、可审计、可扩展的多 Agent 协作。
产品设计建议：
复杂任务必须有一个最终负责人。Supervisor-Worker 应该是生产级多 Agent 的默认模式。
4. Handoff：接力转交
Handoff 是当前 Agent 判断自己不适合继续处理时，把控制权交给另一个 Agent。
典型场景：
- 客服从售前转技术支持
- 通用助手转法律、财务、技术专家
- 多轮对话里的领域切换
Handoff 适合对话型系统，不一定适合强交付型任务。强交付任务更适合 Supervisor 收口。
5. Sequential Pipeline：流水线
Pipeline 是最适合标准化流程的模式。每一步的输出都是下一步的输入。
典型场景：
- 调研 → 分析 → 写作 → 审校 → 发布
- 需求解析 → 方案设计 → 代码生成 → 测试 → 文档
- 数据清洗 → 结构化 → 摘要 → 报告
Google ADK 把 Sequential Pipeline 类比为 assembly line，强调它线性、确定、容易 debug。
产品设计建议：
只要任务有明确步骤，就优先 Pipeline。它比 Roundtable 更适合交付。
6. Parallel Fan-out / Split：并行拆分
Split 把大任务拆成多个相对独立的子任务，由多个 Agent 并行处理，最后统一合并。
典型场景：
- 国内竞品、海外竞品、技术路线、商业模式并行调研
- 多文件代码审查
- 多资料摘要
- 多市场分析
Google ADK 把 Parallel Fan-out / Gather 描述为多个 Agent 同时执行独立任务，再由 synthesizer 汇总。
产品设计建议：
Split 的难点不在拆，而在合并。必须配置 Synthesizer 或 Supervisor。
7. Roundtable：圆桌讨论
Roundtable 是多个 Agent 公开讨论同一问题，彼此可见观点，最后由 Moderator 收束。
典型场景：
- 战略判断
- 产品评审
- 投资分析
- 选题判断
- 多视角风险识别
AutoGen 早期文档把 group chat 作为典型 conversation pattern 之一，与 two-agent chat、sequential chat、nested chat 并列。
产品设计建议：
Roundtable 是判断模式，不是交付模式。它适合“该不该做”，不适合“把事情做完”。
8. Generator-Critic：生成-批评
一个 Agent 负责生成，一个 Agent 负责审核。审核不通过则打回重做。
典型场景：
- 代码生成与代码审查
- 报告生成与事实核查
- 合同生成与风险审查
- SQL 生成与安全检查
- 内容生成与合规审查
产品设计建议：
高质量任务不要让同一个 Agent 自己生成、自己终审。生成和审核必须分离。
9. Iterative Refinement：迭代打磨
这个模式在 Generator-Critic 基础上进一步升级，不只是一次审核，而是多轮优化，直到达到质量阈值或触发最大轮次。
典型场景：
- 高质量文章
- 公开演讲稿
- 产品方案
- 关键代码优化
- Prompt 优化
- 设计稿迭代
产品设计建议：
迭代打磨必须设置退出条件。否则系统会陷入无限优化、成本失控、边际收益下降。
10. Competitive Swarm：竞选择优
多个 Agent 针对同一任务独立生成多个方案，再由 Evaluator 或人类选择最佳方案。
典型场景：
- 产品命名
- 标题
- 广告文案
- 视觉概念
- 活动创意
- 多版脚本
产品设计建议：
Swarm 适合创意，不适合确定性任务。不要用 Swarm 做财务计算、事实核查、权限操作。
11. Hierarchical Decomposition：层级拆解
高层 Agent 拆解大目标，中层 Agent 管理子任务，底层 Agent 执行具体动作。
典型场景：
- 长周期任务
- 企业流程自动化
- 多阶段项目
- 复杂研发任务
- 端到端内容生产系统
2026 年一篇关于 Agent-as-Tool 和并行子任务拆解的论文提出，将 Agent 和工具都抽象成统一可学习的动作空间，并由轻量 orchestrator 进行状态感知的并行拆解、委托和异步执行。这类研究进一步说明，未来 Agent 协作会越来越强调“统一调度、并行拆解、状态反馈”。
产品设计建议：
长任务不应该只是长上下文。长任务应该是一个可追踪的 Task Session，并在内部形成层级化执行图。
12. Human-in-the-loop：人类参与决策
Agent 负责执行和准备，人类负责关键节点判断、审批、打回或终止。
典型场景：
- 对外发布
- 生产部署
- 财务付款
- 客户交付
- 法务合同
- 敏感数据操作
产品设计建议：
人不应该参与所有过程，但必须参与关键决策。Agent do，Human decide。
五、从 12 种模式到产品默认：不要把复杂性暴露给用户
虽然底层可以有 12 种模式，但产品不应该把 12 种都直接暴露给普通用户。
更好的产品设计是：
用户只表达目标，系统自动选择协作模式。
例如，用户说：
帮我写一篇可以发布的深度文章。
系统应该自动选择：
Pipeline + Critic + Iterative Refinement + Human Review用户说：
帮我调研一个技术框架。
系统应该自动选择：
Split + Supervisor-Worker + Fact Check + Final Synthesis用户说：
给我 20 个产品命名。
系统应该自动选择：
Competitive Swarm + Evaluator + Human Selection用户说：
帮我修复这个 bug。
系统应该自动选择：
Pipeline + Code Agent + Test Agent + Critic + Human Merge因此，产品层应该只暴露少数高频入口。
建议默认提供 7 个用户可理解的模式：
| 产品显示名 | 底层模式 | 用户理解 |
|---|---|---|
| 快速完成 | Solo | 一个 Agent 快速处理 |
| 专家分派 | Router / Dispatcher | 自动找合适专家 |
| 主管协作 | Supervisor-Worker | 一个负责人调多个专家 |
| 流水线生产 | Pipeline | 按步骤完成复杂任务 |
| 并行研究 | Split / Fan-out | 多个 Agent 同时处理不同部分 |
| 审核打回 | Generator-Critic | 一个做，一个审 |
| 圆桌讨论 | Roundtable | 多角色讨论后给判断 |
高级模式放在系统内部自动触发：
| 内部模式 | 触发条件 |
|---|---|
| Iterative Refinement | 用户要求“高质量、可发布、精修” |
| Competitive Swarm | 用户要求“多个方案、命名、标题、创意” |
| Handoff | 多轮对话中需要换专家 |
| Hierarchical Decomposition | 长任务、复杂项目、多阶段交付 |
| Human-in-the-loop | 高风险动作、客户交付、发布、部署 |
六、一个实用的模式选择公式
设计 Agent 协作系统时，可以用下面五个问题选择模式。
1. 任务是否简单、低风险？
是，用 Solo。
2. 是否有明确先后步骤？
是，用 Pipeline。
3. 子任务是否可以并行？
是，用 Split / Fan-out。
4. 是否需要多视角判断？
是，用 Roundtable。
5. 是否需要质量审核或人类拍板？
是，加入 Critic / Evaluator / Human-in-the-loop。
再进一步，可以形成一个产品侧的 Mode Selector：
User Goal
↓
Goal Contract
↓
Mode Selector
↓
Execution Pattern
↓
Control Pattern
↓
Validation Pattern
↓
Artifact Delivery
↓
Human Feedback
↓
Context / Taste / Skill 沉淀这个结构比“Agent 群聊”更接近真实产品。
七、Agent 协作的真正边界
多 Agent 不天然更强。
它只在以下几类场景中有明显价值：
第一，任务复杂到单 Agent 难以完整覆盖。
第二，任务可以拆成多个相对独立的子任务。
第三，任务需要不同专业视角。
第四，任务需要生成与审核分离。
第五，任务需要多方案竞争。
第六，任务需要长周期状态管理。
第七，任务需要人类在关键节点决策。
反过来，如果任务简单、低风险、上下文短、验收标准不高，多 Agent 反而可能是负优化。
它会带来：
- 更高 token 成本
- 更长延迟
- 更多上下文传递损耗
- 更复杂的错误定位
- 更难的责任归因
- 更高的产品认知负担
所以，Agent 协作的第一原则不是“多”，而是“刚好”。
能 Solo，不要强行 Roundtable。
能 Pipeline，不要强行群聊。
需要质量，就加 Critic。
需要判断，就加 Human。
需要规模化，才上层级调度。
八、最终判断：Agent 协作不是聊天范式，而是任务操作系统范式
Agent 协作的本质，不是让多个 Agent 一起说话，而是让多个 Agent 围绕一个任务目标，以结构化方式完成分工、执行、审核、交付和沉淀。
未来真正有价值的 Agent 产品，不会只是一个“AI 群聊工具”，而会更像一个 Task OS：
目标进入系统
→ 被解析成 Goal Contract
→ 被选择合适协作模式
→ 被拆成 Task Session
→ 被分派给 Agent / Skill / Tool
→ 被持续追踪状态
→ 被审核和验收
→ 被交付为 Artifact
→ 被沉淀为 Context / Taste / Skill这也是 Agent 产品从个人效率工具走向组织基础设施的关键一步。
一句话总结：
Agent 协作设计模式不应该按“几个 Agent 怎么聊天”来理解，而应该按“任务如何执行、流程由谁控制、结果如何验收”来设计。
也就是：
执行层决定任务怎么跑，控制层决定谁来调度，验收层决定结果怎么算完成。
只有这三层都成立，Agent 才不是在群聊里表演智能，而是在真实工作流里交付结果。