协作模式

一句话理解：Router 负责“分给谁”，Manager / Worker 负责“派活再汇总”，Supervisor 负责“盯着过程把关”，Handoff 负责“整个交出去”，并行负责“同时开工”；五种模式真正的区别是：控制权在谁手里、谁对最终答案负责。

上一课的结论是“能不用多 Agent 就不用”。但当你确实需要多个 Agent 时，第二个常见错误随之而来：模式选错了。比如客服场景里用了 Manager 模式，结果每句用户回复都要经过经理 Agent 转述一遍，又慢又走样；或者 SEO 批量诊断用了 Handoff，结果 Agent 之间接力传了 50 次，任何一棒出错都会让整条链断掉。

这一课把五种常见协作模式放在一起比较。需要说明的是，不同框架和文章对这些模式的命名并不统一，例如同一种结构有人叫 Manager，有人叫 Orchestrator 或 Supervisor。记住结构和控制权，比记住名字更重要。

先用一张图看清本模块的全貌（图 1）：为什么拆、怎么协作、Agent 之间怎么连接，以及底部必须配套的代价控制。

五种模式总览

模式	控制权	谁面对用户	信息流	适合	主要风险
Router 路由	路由器只做一次分派	被选中的 Agent	输入 → 分类 → 单个 Agent	请求类型差异大、互不相关	分错类后无法纠正
Manager / Worker	始终在 Manager	Manager	Manager ⇄ 多个 Worker	需要拆解与汇总的复杂任务	Manager 成为瓶颈，汇总时丢信息
Supervisor 监督	Supervisor 掌握审核与重派权	Supervisor 或流程出口	执行者产出 → 审核 → 返工或放行	质量要求高、有明确验收标准	反复返工，成本失控
Handoff 交接	转移给接手的 Agent	当前接手的 Agent	A → B → C 单向接力	多轮对话中切换专业领域	上下文丢失，责任边界模糊
并行 Fan-out / Fan-in	由编排方（代码或 Agent）掌握	汇总方	一分多、多合一	大量相互独立的同类子任务	重复劳动，结果不一致

下面逐一展开。

Router：先分诊，再处理

Router 的结构如图 2：

例子：客服入口收到工单，先判断是退款、订单查询还是技术问题，再交给对应的 Agent。

要点：Router 本身往往不需要是 Agent。一个分类模型、规则，甚至菜单按钮就能完成，这时它更接近 常见 Workflow 模式 中的路由。只有当分类需要多轮澄清时，才值得用 Agent 做路由。设计时要为“分类不确定”留出口，比如追问用户或交给通用 Agent。

Manager / Worker：派活并汇总

Manager / Worker 的结构如图 3：

例子：研究报告 Agent 中，Manager 把“远程办公对团队协作效率的影响”拆成学术研究、行业调查、企业案例三个子问题，分派给多个 Worker，最后综合成一份报告。

要点：这就是 Anthropic 在《Building effective agents》中描述的编排者-执行者（orchestrator-workers）模式：由一个中心 LLM 动态拆解任务、分派给执行者并综合结果，适合事先无法预知子任务的情况。OpenAI 的 Agent 构建指南称之为 Manager 模式，并指出它适合“只希望一个 Agent 控制流程、并与用户交互”的场景。Worker 通常以 Agent as Tool 的形式被调用，调用完就把结果还给 Manager。

Supervisor：盯过程、把质量关

Supervisor 的结构如图 4：

例子：Coding 场景中，实现 Agent 写完代码，审核 Agent 检查是否符合需求、测试是否通过，不通过就带着具体意见打回。

要点：它和 评估者-优化者 结构相近，区别在于 Supervisor 通常还能决定“换一个执行者”或“升级给人”。关键设计有三点：审核标准要尽量可程序化验证（测试、Schema、业务规则），见 自我检查与外部验证；必须设置返工次数上限；超过上限时要转人工，而不是无限循环。

Handoff：整个交出去

Handoff 的结构如图 5：

例子：用户先问“我的订单到哪一步了”，分诊 Agent 回答后，用户又说“那我不要了，退款吧”，分诊 Agent 把对话整个交给退款 Agent，由退款 Agent 直接和用户继续对话。

要点：OpenAI 的指南把这种结构称为去中心化模式：多个 Agent 地位平等，交接是单向的执行权转移，适合不需要某个 Agent 集中控制或综合结果的场景。交接时带什么上下文、接手者有什么权限，是设计的核心，下一课详细展开。

并行 Fan-out / Fan-in：同时开工

并行的结构如图 6：

例子：全站 SEO 诊断，每个页面由独立的 Agent 实例检查，最后汇总成问题清单。

要点：当子任务的拆分方式是确定的（按页面、按文件、按区域），拆分和汇总最好由代码完成，只把单个子任务交给 Agent。这样并发数、重试和失败处理都是确定的。只有当“怎么拆”本身需要判断时，才让 Manager Agent 来拆。Anthropic 研究系统的早期版本就出现过子 Agent 之间重复劳动、分工不清的问题，所以每个子任务都要有清晰的边界。

LLM 编排还是代码编排

选择协作模式时，还有一个正交的问题：流程由模型决定，还是由代码决定？OpenAI Agents SDK 的文档把两者区分得很清楚：

维度	LLM 编排	代码编排
下一步由谁决定	模型根据情况自主规划、调用工具、交接	代码按预设逻辑串联、分支、并行
优点	灵活，能应对事先想不到的路径	在速度、成本和表现上更确定、可预测
常见手法	工具调用、Handoff	结构化输出后由代码判断；串联多个 Agent；评估者循环直到通过；用并发原语并行运行
适合	开放式任务	流程清楚、只在节点内需要判断的任务

实际系统往往是混合的：外层用代码编排保证可控，节点内部用 Agent 处理判断。

选型四问

1. 最终答案需要一个人统一负责吗？ 需要 → Manager / Worker；不需要，且专家应直接面对用户 → Handoff。
2. 子任务独立且拆分方式确定吗？ 是 → 代码驱动的并行。
3. 质量能被明确验收吗？ 能，且值得返工成本 → 加 Supervisor。
4. 请求类型差异大、处理方式完全不同吗？ 是 → 入口加 Router，而且优先考虑非 Agent 的路由。

常见误区

• “一个系统只能选一种模式。” 真实系统常常是组合：入口 Router，某个分支里是 Manager / Worker，Worker 内部再用并行。关键是每一层的控制权清晰。
• “Supervisor 越多越保险。” 模型审核模型，错误可能相关；审核层级越多，成本和延迟叠加越快。能用程序验证的，优先用程序。
• “Handoff 就是转发消息。” Handoff 转移的是执行权和对话，接手的 Agent 要能独立完成后续工作，交接内容和权限必须专门设计。
• “让 Manager Agent 自己决定开多少个 Worker。” 没有上限时很容易失控。Anthropic 的文章提到早期版本曾为简单查询派出 50 个子 Agent，后来通过在提示中明确“按任务复杂度决定投入”来约束。

产品经理检查清单

• 每一层的控制权在谁手里？谁对最终答案负责？
• 用户在整个过程中和哪个 Agent 对话？会不会感觉“换了一个人”？
• 拆分与汇总是由代码还是由模型完成？为什么？
• 有没有并发数、返工次数、交接次数的上限？
• 子 Agent 之间是否可能重复劳动或产出冲突结论？如何发现和处理？
• 每种模式的失败出口是什么：追问用户、降级、还是转人工？

练习

为下面三个需求各选一种（或一组）协作模式，画出 ASCII 结构图，并写出选择理由（30–45 分钟）：

1. 电商客服：同时处理订单查询、退款、发票三类请求。
2. 竞品调研：对 6 家竞品分别调研定价、功能、渠道，输出对比报告。
3. Coding Agent：实现一个新接口，要求测试全部通过、通过代码规范检查后才能提交 PR。

延伸阅读

• Anthropic：Building effective agents
• OpenAI Agents SDK：Agent orchestration
• OpenAI：A practical guide to building agents（PDF）

下一步

Manager 调用 Worker，与分诊 Agent 把对话交给退款 Agent，看起来都是“一个 Agent 找另一个 Agent”，机制却完全不同。下一课「Agent as Tool 与 Handoff」讲清这两者。