TECH NOTE
2238 字 11 分钟 系列 2 / 2202 五种模式总览与选型:先认脸,再挑人
ON THIS PAGE / 目录13 节
一句话讲透:多 Agent 就五种基本打法——Subagents(主管派活)、Handoffs(转接电话)、Skills(随用随翻手册)、Router(前台分诊)、Custom workflow(自己画流程图)。先认全这五张脸,再按”要不要并行 / 要不要换人格 / 要不要省上下文”来挑。
一张表认全五种模式
原文的定义(下表第二列是原文意思的中文转述,“控制权在谁手里”一列是补充解读):
| 模式 | 原文怎么定义 | 说人话 | 控制权在谁手里 |
|---|---|---|---|
| Subagents | 主管 Agent 把子智能体当工具调用;所有路由都要经过主管,由它决定何时调、传什么、怎么合并结果 | 主管手里有份”外包名单”,派活给专家,收结果再对人说话 | 主管(用户只跟主管对话) |
| Handoffs | 行为根据状态动态变化:工具调用更新一个状态变量,从而触发路由或配置变化——切换 Agent,或改变当前 Agent 的工具与提示词 | 像客服转接电话:上一环节把”当前状态”交给下一环节,下一环节用不同的身份/权限继续 | 当前活跃的那个 Agent(用户可以直接跟它对话) |
| Skills | 专用提示词与知识按需加载;单个 Agent 全程保持控制权,需要时才去加载 | 一个老员工 + 一柜子说明书,遇到什么活翻哪本 | 同一个 Agent 从头到尾 |
| Router | 一个路由步骤先给输入分类,再定向到一个或多个专用 Agent,最后把结果汇总成一个回答 | 医院分诊台:先判断你该看哪个科,可能同时开几个检查,最后医生合并结论 | 路由层(用户不直接跟专家对话) |
| Custom workflow | 用 LangGraph 搭定制执行流,把确定性逻辑和 Agent 行为混在一起;可以把其它模式当节点嵌进去 | 流程图由你画:哪一步是固定代码、哪一步交给模型,你说了算 | 你(图怎么连就怎么走) |
四种能力维度,官方给你打星
原文用四个维度给模式打分(⭐ 越多越强):
| 模式 | 分布式开发 | 并行化 | 多跳(连续调多个) | 直接跟用户交互 |
|---|---|---|---|---|
| Subagents | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
| Handoffs | - | - | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Skills | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Router | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | - | ⭐⭐⭐ |
四个维度的含义(原文注释):
- 分布式开发(Distributed development):不同团队能不能各自独立维护组件?
- 并行化(Parallelization):多个 Agent 能不能同时跑?
- 多跳(Multi-hop):支不支持串联调用多个子智能体(A 的结果喂给 B)?
- 直接跟用户交互(Direct user interaction):子智能体能不能直接跟用户对话?
🧭 补充解读(非原文):这张表最好这么读——
- Handoffs 的”并行”是空的:它是串行换人,前一棒交完才轮到下一棒。
- Router 的”多跳”是空的:它只做一层分诊 + 汇总,不适合”A 完了接着 B”。
- Subagents 的”用户直连”只有 ⭐:用户永远只跟主管说话,子智能体是”后台工人”。
- Skills 四项都高,是因为它压根没拆 Agent——所有能力都在一个 Agent 身上,只是知识按需加载。
怎么选:先问三句话
决策树
flowchart TD START["需求:到底要不要多 Agent?"] --> Q1{"单 Agent + 好工具/好提示词<br/>能搞定吗?"} Q1 -- "能" --> STOP["先别拆:优化工具与提示词<br/>(见 01 篇)"] Q1 -- "不能" --> Q2{"瓶颈主要是哪一种?"} Q2 -- "知识/提示词太长,要按需加载" --> SK["Skills:单 Agent + 技能按需加载<br/>(见 06 篇)"] Q2 -- "要同时问多个领域,越并行越好" --> RT["Router:先分诊,再并行,最后汇总<br/>(见 07 篇)"] Q2 -- "会话里要换身份/换阶段(像转接电话)" --> HO["Handoffs:状态驱动,切换行为<br/>(见 05 篇)"] Q2 -- "要上下文隔离 + 集中管控 + 可能多跳" --> SUB["Subagents:主管 + 子智能体<br/>(见 04 篇)"] Q2 -- "流程有硬性步骤/分支/重试,还要混固定代码" --> CW["Custom workflow:自己画 LangGraph<br/>(见 08 篇)"]这张图在说什么:① 第一步永远是”要不要拆”,能单 Agent 解决就别拆;② 第二步看瓶颈类型:上下文太长 → Skills;要并行 → Router;要换人格/换阶段 → Handoffs;要隔离 + 集中管控 → Subagents;有硬流程 → Custom workflow。③ 这只是”首选”,真实系统经常混用。
30 秒版选择器
| 你的首要目标是 | 首选 | 为什么 |
|---|---|---|
| 一次请求只干一件事,想最省调用 | Handoffs / Skills / Router | 三者都是 3 次调用(见 03) |
| 同一会话反复问同一领域 | Handoffs 或 Skills | 有状态,第二轮能省掉一次交接/加载 |
| 一次涉及多个领域,还能并行 | Subagents 或 Router | 并行执行,token 也最省 |
| 长上下文领域,怕污染主对话 | Subagents 或 Router | 上下文隔离 |
| 任务简单、只想要”按需加载说明书” | Skills | 不拆 Agent,最轻 |
| 用户要直接跟”专家”对话、来回追问 | Handoffs | 唯一支持子智能体直接面对用户的模式 |
| 流程是硬编码步骤 + 局部用模型 | Custom workflow | 只有它能混确定性逻辑 |
五种模式长什么样(官方示意图)
Subagents:主管把子智能体当工具

官方图注意为「Subagents 模式:主 Agent 把子智能体当工具协调」。看图重点:所有箭头都要经过中间那个主管——子智能体之间不直接说话,用户也只面对主管。
Handoffs:靠工具调用把控制权交给下一个 Agent

官方图注意为「Handoffs 模式:Agent 通过工具调用转移控制权」。看图重点:这是一条横向的接力链(A → B → C),每个 Agent 都能”直接回应用户”或”交给下一个”。
Skills:单 Agent 按需加载专业上下文

官方图注意为「Skills 模式:单个 Agent 按需加载专用上下文」。看图重点:只有一个 Agent,旁边挂着一排”技能”,用到哪个加载哪个。
Router:先分类,再分发

官方图注意为「Router 模式:路由步骤把输入分类后分发给专用 Agent」。看图重点:左边一次分类,中间并行分发给多个专家,右边汇总成一个回答。
💡 提示:五种模式长什么样,光看图容易”看着都懂、选时懵”。建议把
03篇的性能数字和本篇的决策树对着看——图决定结构,数字决定代价。
别把这五种当单选题:可以混着用
原文的原话很直接:
You can mix patterns! For example, a subagents architecture can invoke tools that invoke custom workflows or router agents. Subagents can even use the skills pattern to load context on-demand.
(你可以混着用!比如 Subagents 架构里的工具可以去调 Custom workflow 或 Router;子智能体自己也可以用 Skills 模式按需加载上下文。)
🧭 补充解读(非原文):常见的三种混法——
- Router 套 Subagents:先分诊到”业务域”,域内再由主管管一群子智能体。
- Subagents + Skills:主管不把所有领域知识塞给子智能体,而是让子智能体自己去
load_skill。- Custom workflow 打底 + 其它模式当节点:固定步骤用代码写,需要”动态决策”的节点才放进 Agent(这也是最贴近真实生产系统的做法)。
小结
- 五种模式 = 五种控制权安排:主管集中管(Subagents)/状态驱动换人(Handoffs)/一人多技能(Skills)/先分诊再汇总(Router)/你自己画图(Custom workflow)。
- 四个维度看能力边界:分布式开发、并行、多跳、用户直连——哪一项是硬需求,就直接排掉不支持的模式。
- 选型先看瓶颈:上下文长 → Skills;要并行 → Router;要换人格 → Handoffs;要隔离+管控 → Subagents;有硬流程 → Custom workflow。
- 模式可组合:真实系统几乎不会只用一种,Subagents / Skills / Router / Custom workflow 可以互相嵌套。
- 代价见
03:一次性请求 Handoffs/Skills/Router 最省(3 次调用),重复请求有状态模式最省,多领域并行模式最省 token。
一句话选型
- 单选题就按决策树走:单一领域 + 省调用 → Handoffs 或 Skills;多领域并行 → Subagents 或 Router;用户要跟专家直接聊 → Handoffs。
- 拿不定主意就选 Subagents:它最通用(四项能力里三项满星),代价是每次多一次”汇总”调用。
上一篇:01 为什么需要多 Agent | 下一篇:03 性能对比:调用次数与 Token