当前位置：首页 > news >正文

一文讲透 Agent 演进的四大底层模式：Sub-Agent、Skills、Handoffs 与 Router

news 2026/7/14 23:03:48

前两天在群里看到一个讨论，说的是某个开源 Agent 项目，有人几分钟就把它的设计取舍说得明明白白，还有人翻了半天源码，还是停留在“哦它用了 Agent，还有 Tool，好像还有个 Workflow”这种层面。

我当时的反应是：这个差距其实跟代码读没读完没太大关系。真正拉开距离的，是脑子里有没有一套稳定的架构判断框架。当你具备这套框架的时候，面对任何一个陌生但热门的 Agent 产品，你不会从零开始理解，而是下意识地问几个问题：

它要解决的核心工程问题是什么？它选的是单 Agent 还是某种多 Agent 结构？它是在用上下文换智能，还是在用架构换可控性？

这篇文章不讲某个具体框架的用法，我想聊得更底层一点——把 Sub-Agent 到 Multi-Agent 这条演进路径上的四种核心模式讲透，给出一套我自己在项目里反复验证过的决策方法。

一、多 Agent 不是起点，是终点

先说一个我自己交过学费的教训。大概两年前我接手过一个企业知识助手项目，前任团队一上来就是 Supervisor + 五六个 Sub-Agent 的架构，理由是“以后好扩展”。结果呢，调试一个简单的问题要在五个 Agent 之间来回追踪日志，一次简单的意图澄清，硬是要走两轮 Agent 间通信，token 成本高得离谱，实际效果还不如一个写得干净的单 Agent + 几个工具。

后来我们把整个系统推倒重做，先退回到单 Agent，把工具收拾干净，反而问题都解决了。

LangChain 在他们的架构选型指南里有句话我很认同：先从单 Agent 起步，优先通过加工具扩展能力，只有当系统真的触及了单 Agent 的架构边界，才考虑多 Agent。这不是保守，是工程常识。每多一个 Agent，你就多一层调试复杂度，多一份 token 成本，多一个潜在的失败点。

但话说回来，多 Agent 也不是不能用，用对了地方，收益是实打实的。Anthropic 自己的多 Agent 研究系统在内部评测里，比单 Agent 的 Claude Opus 4 性能提升了 90.2%。问题从来不是“要不要用多 Agent”，而是“你的场景配不配得上多 Agent 的代价”。

二、判断的两个信号，别的都是伪需求

我见过太多团队引入多 Agent 的理由是“感觉更专业”“别人都在用”，这种动机基本都会在生产环境里翻车。真正值得升级的信号，我认为只有两个。

第一个信号是上下文管理确实撑不住了。当多个领域的专业知识没法舒服地塞进一个 system prompt 里，你就得策略性地分发上下文，而不是一股脑往里塞。这里有个概念叫 dumb zone，就是当 Agent 的上下文窗口接近满载时，模型在任务完成度上会明显掉链子——这个我在实践中深有体会，一个 prompt 里塞了代码专家、测试专家、安全审计专家、文档专家四套指令之后，模型经常会在角色之间“串戏”，回答里夹杂着不该出现的口吻。

第二个信号是团队协作层面的，不同团队需要独立拥有和维护各自的 Agent 能力。比如安全团队维护审计 Agent，测试团队维护测试 Agent，谁都不用等谁发版本。这个信号偏工程管理，技术上不难理解，但很多团队一开始压根没意识到这也是一个正当理由。

除了这两个，其余的“多 Agent 冲动”我基本都劝退。

三、四种模式，一个都不能漏讲

这四种模式我按 LangChain 的分类框架来讲，结合 Anthropic、Google、OpenAI 几家的实践，它们不是互斥关系，真实项目里经常是组合拳。

模式一：Sub-Agents——集中式编排

核心思路很简单，一个 Supervisor 当老板，拆解任务后分发给专门的 Sub-Agent 干活。每个 Sub-Agent 只关心自己那一块，拥有独立的上下文窗口，天然就避免了信息互相污染。Sub-Agent 本身通常无状态，专注单次任务，整个对话的状态和流程控制都在 Supervisor 手里。

这套结构最大的好处是能并行，多个 Sub-Agent 同时干活，吞吐效率能起飞。用户不会直接跟 Sub-Agent 打交道，永远是通过 Supervisor 间接沟通。调试上属于中等复杂度，重点要盯住 Supervisor 的委派逻辑，出问题的时候才能快速定位到底是哪一层出的错。

举个我自己在项目里写过的配置结构：

subagent_config = { "name": "research-agent", "description": "针对特定主题进行网络检索。" "适用于用户提出需要最新信息的事实性问题时使用。", "system_prompt": "你是一名调研专家……", "tools": ["WebSearch", "WebFetch", "Read"], "model": "sonnet" # 用更快的模型压成本 }

Claude Code 里内置的 Explore、Plan、General-purpose 几个子代理，走的都是这套路子，上手门槛不高。

Anthropic 自家的 Research 功能是这个模式的教科书案例：LeadResearcher 用 Claude Opus 4 负责分析查询、制定策略，然后并行派出 3 到 5 个用 Claude Sonnet 4 跑的 SubAgent，各自独立检索，每个 SubAgent 至少执行 3 次并行工具调用，最后由 CitationAgent 统一处理引用归属，结果汇总回 LeadResearcher 做综合输出。

这套并行架构能把复杂查询的整体研究时间压缩最多约 90%，代价是相比普通对话大概 15 倍的 token 消耗。Anthropic 为了不让这个成本失控，专门在 prompt 层设计了一套“努力分配规则”：简单问题就用单个 Agent 加不超过 10 次工具调用，中等研究上 3 到 5 个 SubAgent 各跑 3 次以上并行调用，复杂研究才上 10 个以上 SubAgent 全面铺开。这个分级思路我觉得值得所有做多 Agent 系统的人借鉴——不是所有请求都值得用最贵的架构去接。

模式二：Skills——渐进式能力加载

这个模式很多人会归到多智能体里，但严格说它还是单个 Agent，只是通过 SKILL.md 这类配置实现能力的按需加载。Agent 一开始只知道每个技能的名字和简介，判断需要哪个技能了，才把完整指令加载进来。我更愿意把它理解成“用更轻的 prompt 切换，替代了完整的 Agent 切换”。

Skills 模式下所有能力共享同一个上下文窗口，隔离性天然就弱，但换来的是对话状态可以自然连续地留在同一个 Agent 里，不需要额外搞状态协调。执行是顺序的，没有并行调度这回事，用户体验上是路径最短的，因为你始终在跟同一个 Agent 说话。

目录结构大概长这样：

.claude/skills/ ├── deploy/ │ └── SKILL.md # 部署技能的完整指令 ├── review-pr/ │ └── SKILL.md # PR 审查技能的指令 └── database-migration/ └── SKILL.md # 数据库迁移技能的指令

每个 SKILL.md 里是 YAML frontmatter 加详细步骤：

--- name: deploy description: "将应用部署到生产环境" allowed-tools: ["Bash", "Read", "Edit"] --- ## 部署步骤 1. 检查当前分支是否为 main 2. 运行完整测试套件 3. 构建生产版本 4. 执行部署脚本 5. 验证部署结果

我自己带团队做编码助手类产品的时候，特别偏爱这个模式——能力种类多，但单次任务只用得上其中一两个的场景，比如同时支持十几种操作模式的编码工具，或者在写作、设计、排版几种创意形态之间切换的工具，Skills 都比一上来就上 Sub-Agent 划算得多。

它的工程代价也很直接：对话历史越攒越多，后续调用的 token 成本会持续膨胀。但首次调用几乎没有额外调度开销，响应延迟是四种模式里最低的。

我经常这样跟团队解释 Skills 和 Sub-Agent 的本质区别：Sub-Agent 是独立上下文，适合大量信息过滤；Skill 是共享上下文，适合需要连贯对话的场景。记住这一句，基本就不会选错。

模式三：Handoffs——状态驱动的交接

这个模式的核心是活跃 Agent 根据对话状态动态切换。A 完成自己的阶段以后，把控制权和上下文传给 B。不同 Agent 之间是显式交接，上下文可以选择性传递，不是整体共享，既保留了必要的信息连续性，又不至于让无关内容到处扩散。

因为各阶段之间存在明确的先后依赖，这个模式只能严格顺序执行，没法并行。但对用户来说体验是透明的，感觉上就是在跟一个 Agent 完整地把事情办完。

这里有个我经常被问到的问题：Sub-Agent 和 Skills 都是框架原生支持的，但 Handoff 底层压根没有一个叫 handoff() 的 API，这怎么实现？

答案是，Handoffs 从来就不是一个框架特性，它是一种工程模式，靠 prompt、状态约束和工程结构拼出来的。落地需要三个要素：第一，显式定义流程阶段；第二，每个阶段对应一套角色约束的 Agent 视角，比如信息收集阶段就是前台接待的口吻，诊断阶段就切换成技术支持的口吻；第三，也是最容易被忽略但最关键的一点——每个阶段必须有明确的完成条件，不然就会卡在阶段里死循环出不来。

我自己写过的一个简化示例：

系统规则: 你将按照以下阶段顺序工作: 1. 信息收集(intake) 2. 问题诊断(diagnosis) 3. 解决方案(resolution) 当前阶段:intake 规则: - 只能提问 - 不要给解决方案 - 当信息完整时,明确声明:"进入 diagnosis 阶段"

当模型输出“信息已收集完成，进入 diagnosis 阶段”之后，你（或者你的系统）再注入下一段针对 diagnosis 阶段的 prompt，一次 Handoff 就完成了。这套东西说穿了不难，难的是把退出条件写得足够严谨，不然生产环境里很容易出现卡死在某个阶段的情况——这个坑我踩过不止一次。

Handoffs 最适合有明确阶段划分的流程型场景，客服工单是最典型的例子，从信息收集到诊断到给方案，天然分阶段。它牺牲了并行能力，在多领域查询上效率是四种里最低的，但在强调流程完整和交互自然度的场景里，往往是体验最好、可控性最强的选择。

模式四：Router——并行分发与合成

Router 的核心是对输入做语义拆分和职责分流。系统先由 Router 对请求分类拆解，把子查询并行分发给各自负责的专业 Agent，最后把多个结果合成一个对用户友好的响应。

这个模式天然适合跨多个知识域或数据源的查询。企业知识库场景里特别常见，用户一次提问可能同时涉及政策文档、业务数据、实时指标，比如问“我们的退货政策是什么？最近的销售数据如何？”，Router 会把退货政策交给文档 Agent，销售数据交给数据分析 Agent，上层再统一整合返回。

在 Claude Code 这类环境里，Router 通常有三种存在形态：主 Agent 里的一段路由决策逻辑，这是最常见的；一个可调用的工具，也就是 Router-as-Tool；或者一个轻量的 Sub-Agent，只负责分类不负责执行。本质都是同一件事：先判断这是什么问题，再决定交给谁。

Router 的优势是并行能力强、职责边界清晰，各分支彼此独立、上下文完全隔离，扩展和调试都方便。代价是通常无状态，没法靠历史对话减少重复计算，如果场景需要连续对话，往往得把 Router 当工具嵌进一个有状态的主 Agent 里，在并行效率和对话连续性之间找平衡。

四、数据不会骗人：量化对比给出的答案

LangChain 做过一组实际的性能测试，分三个场景对比这四种模式，结论很值得记一下。

单任务请求场景下（比如“帮我改个函数支持分页查询”），Sub-Agent 模式有明显的额外开销，简单任务用不上它。重复请求场景下（第二轮同类型请求），有状态的模式效率优势非常明显。多领域查询场景下（比如对比 Python/JS/Rust 的性能），上下文隔离型的模式——也就是 Sub-Agent 和 Router——在 token 效率上优势显著，能省下 40% 以上的成本。

Anthropic 在工程博客里也披露了一个我觉得比表面数据更重要的发现：多 Agent 系统里约 95% 的性能波动可以归因于三个因素——token 使用量占大头，影响约 80%；工具调用次数和模型选择加起来贡献约 15%；剩下的因素影响有限。

这句话背后的意思是，选对模型带来的收益，往往超过单纯把 token 预算翻倍。也就是说在多 Agent 架构里，模型选型的重要性，远高于无节制堆上下文规模。这个结论我这两年在好几个项目里都验证过——与其纠结要不要把上下文窗口从 100K 拉到 200K，不如先看看 Sonnet 是不是已经能替代 Opus 完成这一层的工作。

从“token 经济学”角度看，多 Agent 系统普遍有约 15 倍的成本放大效应，只适合高价值、高复杂度的任务。像那种需要所有 Agent 共享完整上下文的场景、强耦合且高度顺序化的工作流、大多数难以并行拆解的编码任务，以及依赖实时协调的系统，上多 Agent 基本是得不偿失，白白多出成本和复杂度。

五、生产环境不会跟你讲道理：四个真实的坑

架构选对了，不代表上线就顺利。Anthropic 分享过他们把多 Agent 系统推向生产时遇到的四个挑战，我自己也基本全踩过一遍。

第一是状态性带来的复杂度。Agent 在多轮对话里维持状态，一个 SubAgent 的轻微失误，可能级联放大成后面所有 Agent 的行为都跑偏。应对的办法是在每个 Agent 的输出端设检查点，先验证输出质量再往下传，别让脏数据一路流到底。

第二是非确定性调试。Agent 的动态决策让传统日志分析基本不够用，你得有完整的生产链路追踪，记录每个 Agent 的输入、决策过程和输出，配合可观测性工具记录完整调用链——这个我建议项目一开始就搭好，别等出了问题才补，补的时候基本已经晚了。

第三是部署复杂度。多 Agent 系统没法简单粗暴地停机更新，因为 Agent 可能正在执行任务，强行打断行为不可预测。比较靠谱的做法是新旧版本共存的渐进式部署，让旧版本 Agent 把手头任务跑完再自然退出，新版本接管后续请求。

第四是同步瓶颈。当前大多数 SubAgent 还是同步执行的，信息流转受限。这个我认为是未来一两年值得关注的方向——打通异步执行加 Agent 间消息通道，让 SubAgent 在跑的过程中能互相共享发现，而不是各干各的等最后汇总。

六、一张决策树，帮你少走弯路

讲了这么多，落到实操上，我自己现在判断要不要升级架构，基本就问这几个问题：

图片

对应的项目演进路径，我见过的大多数成熟系统基本都会走这四步：先是单 Agent + Tools，这是大多数项目该待的起点；工具多起来、prompt 变臃肿了，升级到单 Agent + Skills；当不同领域确实需要独立上下文空间和专业知识了，再引入 Supervisor + Sub-Agents；到了系统成熟期，往往是混合架构——Router 做分类，Sub-Agent 跑并行研究，Handoff 处理有明确阶段的顺序流程，几种模式各司其职。

我自己习惯是，项目早期先做一版不讲究任何设计模式的简单 Demo，跑两三周，等感觉认知开始过载、维护起来吃力了，再回头套这套决策树去重构。这是我个人的节奏，如果你的项目从立项就能大致判断出复杂度天花板，提前做全局设计也完全没问题，关键是别在需求不明确的时候就上重架构。

总结

最好的架构从来不是最复杂的架构，而是恰好满足需求的最简架构。一个 Agent 加几个好用的工具能解决的问题，就没必要引入 Supervisor + SubAgent 的复杂度。但当任务的并行性、专业性、上下文管理需求确实超出了单 Agent 的能力边界，正确的多 Agent 架构带来的质量提升是实打实的。

Anthropic 那个 90.2% 的性能提升数字很唬人，但别忘了后面跟着的 15 倍 token 成本——架构选型从来都是性能、成本、可控性这三者的博弈，没有免费的午餐。

留一个具体场景给你自己练练手：假设你在给研发团队搭一个内部技术助手，要支持查内部文档、答代码相关问题、辅助排查线上问题，偶尔还要做跨领域分析（比如“这个接口改动会影响哪些系统、上线风险如何”）。现在已经有 15 个以上的工具，单 Agent 长 prompt 快到上下文上限了，用户开始反馈回答跑偏、不同问题之间“串味”、调试一次要反复重放对话。

面对“继续压缩单 Agent 的 prompt”“上 Skills 按需加载”“直接上 Supervisor + Sub-Agent 拆开领域”“加一个 Router 并行分发”这四个选项，你会怎么选？触发你做这个判断的信号，到底是工具数量、上下文长度，还是错误类型本身？欢迎在评论区聊聊你的答案。