你好，我是黄佳。

了解子代理的来龙去脉之后，我们这一讲接着深入聊相关的工程实践和设计模式。

正式开讲前，我想先抛出一个很多同学都比较困扰的地方：为什么我们有时很快就能“看懂”某些新出来的 AI 产品，而对另一些却始终感觉云里雾里？

上周直播时，就有同学提到一个当下讨论度很高的开源项目 OpenClaw（Clawdbot）。在讨论群里，有人一眼就能说清它的核心设计取舍，而初学者却只能停留在“它好像用了 Agent / Tool / Workflow”的层面。

这背后的差别，往往不在于你有没有把源码读完，而在于你脑子里有没有一套稳定的“架构式思维框架”。

当你具备这种整体架构模式的认知时，面对一个陌生但热门的 AI 产品，你不再是从零开始理解，而是会下意识地问几个问题：

它解决的核心工程问题是什么？

它选择的是单 Agent，还是某种多 Agent 结构？

它是在用上下文换智能，还是用架构换可控性？

今天这一讲，虽然不在课程原有大纲之内，但我非常建议你在后续子代理工程实操之前，先把这一套“架构视角”建立起来。还是那句老话：站得高，看得远。

这节课的目标，并不是教你某一个具体框架、某一个流行用法，而是帮你建立一种可以立刻用于拆解当下热门产品，也能长期指导工程设计的通用方法论。学完今天的内容，你不仅能更好地理解 Sub-Agent、Skills 这些概念，也会更清楚：什么时候该用，什么时候不该用，为什么。

何时该升级到多 Agent？

在 AI Agent 的工程实践中，有一个经典的误区——过早引入多 Agent 架构。

LangChain 在其架构选型指南中给出了明确建议：

“Start with a single agent. Add tools before adding agents. Graduate to multi-agent patterns only when encountering clear architectural limits.” （先从单 Agent 起步，优先通过引入工具扩展能力；只有当系统确实触及单 Agent 的架构边界时，才考虑采用多 Agent 的设计模式。）

这不是保守，而是工程智慧。每增加一个 Agent，你就增加了一层调试复杂度、一份 token 成本、和一个潜在的失败点。但当你的任务真的跨越了单 Agent 的能力边界时，正确的多 Agent 架构会带来巨大性能提升——Anthropic 的多 Agent 研究系统在内部评测中，比单 Agent Claude Opus 4 性能提升了 90.2%。

那么，到底我们应该何时从单 Agent 升级到多 Agent？这需要你先想明白一个前置问题：你的场景真的需要多 Agent 吗？

两个核心触发条件

LangChain 在 Choosing the Right Multi-Agent Architecture 这篇文章中总结了两个让多 Agent 成为必要选择的工程信号。

信号一：上下文管理挑战

当多个能力领域的专业知识无法舒适地塞进单一 prompt 中时——你需要策略性地分发上下文，而不是把所有东西堆在一起。当 Agent 的上下文窗口接近满载时，模型在任务完成上的表现会显著下降，进入所谓的 dumb zone（迟钝区）。

信号二：分布式开发需求

当多个团队需要独立拥有和维护各自的 Agent 能力时。比如安全团队维护审计 Agent，测试团队维护测试 Agent，各团队可以独立迭代而不互相干扰。

单 Agent 的困境： ┌─────────────────────────────────────────────────┐ │ System Prompt: │ │ - 你是代码专家（200行指令） │ │ - 你也是测试专家（150行指令） │ │ - 你还是安全审计专家（180行指令） │ │ - 你同时是文档撰写专家（100行指令） │ │ ... │ │ Token 爆炸，模型注意力分散 │ └─────────────────────────────────────────────────┘

下面我们从工程视角出发，系统梳理 Sub-Agent 到 Multi-Agent 的四种核心设计模式，并给出性能、成本、可控性三个维度的决策框架。

四种核心设计模式

综合 LangChain（这是下面4种多智能体模式的主要来源）、Anthropic、Google 和 OpenAI等前沿公司的最佳实践，多 Agent 系统可以归纳为四种核心架构模式。它们不是互斥的——实际项目中经常组合使用。

模式一：Sub-Agents（子代理委派 / 集中式编排）

Sub-Agents的核心设计思想是一个 Supervisor Agent 充当老板，将任务分解后委派给专门的 Sub-Agent。每个 Sub-Agent 解决一个特定的任务。

在 Sub-Agent 架构中，上下文隔离能力非常强，每个 Sub-Agent 都拥有独立的上下文窗口，从根本上避免了信息相互污染。Sub-Agent 本身通常设计为无状态组件，专注于完成被委派的单次任务，而整体对话状态与流程控制则由 Supervisor 统一维护。

这种结构天然支持并行执行，多个 Sub-Agent 可以同时展开工作，从而显著提升复杂任务的吞吐效率。用户并不直接与各个 Sub-Agent 交互，而是始终通过 Supervisor 间接沟通，由其负责任务拆解、结果汇总与最终输出。

在调试和可控性层面，该模式的复杂度处于中等水平，工程上需要重点关注 Supervisor 的委派逻辑与决策路径，以便在出现偏差时能够准确定位问题来源。

Claude Agent SDK 中的 Sub-Agent 定义（概念示例）

subagent_config = { "name": "research-agent", "description": "Research specific topics by searching the web. " "Use when user asks factual questions requiring " "up-to-date information.", "system_prompt": "You are a research specialist...", "tools": ["WebSearch", "WebFetch", "Read"], "model": "sonnet" # 用更快的模型降低成本 }

Claude Code 中内置就有很多子代理（Explore、Plan、General-purpose），非常容易实现这种架构。

在 Anthropic 的真实生产系统中，Research 功能采用的就是一种典型的 Sub-Agent 架构。

Anthropic 的 Research 功能采用了经典的 Sub-Agent 模式：

LeadResearcher（Claude Opus 4）分析查询、制定策略

并行派出 3-5 个 SubAgent（Claude Sonnet 4），各自独立搜索

每个 SubAgent 执行 3+ 个并行工具调用

CitationAgent 处理引用和来源归属

结果汇聚回 LeadResearcher 综合输出

工程评测显示，并行化的 Sub-Agent 执行方式可将复杂查询的整体研究时间最多缩短约 90%，但其代价是相较普通对话约 15 倍的 token 消耗；在高价值研究任务中，这一成本换来了高达 90.2% 的整体性能提升。

为了在不同复杂度任务中控制资源消耗，Anthropic 在 Prompt 层引入了明确的“努力分配规则（Effort Scaling）”，例如对简单问题仅启用单个 Agent 和有限次数的工具调用，而在复杂研究场景下则调度更多 Sub-Agent 全面并行执行。

简单查询：1 个 Agent，3-10 次工具调用中等研究：3-5 个 SubAgent，各 3+ 次并行工具调用复杂研究：10+ 个 SubAgent，全面并行执行

这一架构特别适用于需要并行检索多个信息源、跨多个知识领域协同工作的研究系统，个人助手协调日历、邮件、CRM 等，同时也通过上下文隔离显著降低了信息串扰和泄漏风险。

不过，因为在每次交互中都会引入额外的模型调用和结果回传过程，Sub-Agent 架构会增加一定的延迟和 token 成本，但换来的则是更强的集中控制能力和可预测的工程行为。

模式二：Skills（技能 / 渐进式能力加载）

LangChain把Skills也视为一种多智能体模式。其实此时仍然是单个 Agent（或SubAgent），但通过SKILL.md 文件（或类似配置）实现能力的渐进式加载。Agent 一开始只知道技能的名称和描述，当判断需要某个技能时，才加载完整的指令。

这是一种“准多 Agent”方案——用更轻量的 prompt 切换替代完整的 Agent 切换。

在 Skills 模式下，系统仍然由单一 Agent 负责全部推理与执行，所有技能共享同一个上下文窗口，因此在上下文隔离能力上相对较弱，但换来的好处是对话状态可以自然连续地保留在同一个 Agent 内部，无需额外的状态协调机制。

由于不存在多个 Agent 的并行调度，整体执行过程以顺序方式展开，并行能力相对有限，但在多数交互式场景下已经足够。用户始终与同一个 Agent 直接交互，交互路径最短，体验也最为流畅。

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

在Claude Code 的配置中，每个 SKILL.md 包含 YAML frontmatter（元数据）和详细的步骤指令：

name: deploy description: "Deploy application to production environment" allowed-tools: ["Bash", "Read", "Edit"]

部署步骤

检查当前分支是否为 main
运行完整测试套件
构建生产版本
执行部署脚本
验证部署结果

Skills 模式特别适合那些能力种类繁多、但单次任务只需要调用少量能力的场景，例如需要同时支持十余种操作模式的编码助手，或在写作、设计、排版等多种创意形态之间切换的创意工具。在这类系统中，Agent 可以在保持连续对话体验的前提下，按需加载对应技能，避免在一开始就引入过多指令。

这种模式的复杂度最低，执行路径清晰、因果关系明确，非常适合早期系统，在需要频繁迭代的情况下，能快速定位问题。其工程代价在于，对话上下文会随着历史交互逐步累积，后续调用的 token 成本可能持续膨胀；但相应地，这种模式在首次调用时几乎没有额外调度开销，响应延迟最低，同时也为用户提供了最自然、最直观的交互体验。

我想这样概括 Skills 模式与 Sub-Agent模式的关键区别。

Sub-Agent：独立的上下文 → 适合大量信息过滤 Skill：共享的上下文 → 适合需要连贯对话的场景

模式三：Handoffs（交接 / 状态驱动的 Agent 切换）

Handoffs的核心思想是活跃的 Agent 根据对话状态动态切换。Agent A 完成自己的阶段后，通过调用 handoff() 工具将控制权（和上下文）传递给 Agent B。

在 Handoffs 模式下，不同 Agent 之间通过显式的交接机制完成角色切换，上下文并非整体共享，而是可以根据需要选择性地传递。这样能在保持必要信息连续性的同时，避免无关内容的扩散。系统状态在 Agent 切换过程中被持续保存和传递，使得多阶段流程能够自然推进而不会丢失关键信息。

由于各阶段之间存在明确的先后依赖关系，该模式采用严格的顺序执行，不支持并行展开。对用户而言，Agent 的切换过程通常是透明的，用户可以像与单一 Agent 交互一样完成整个流程。

在工程调试层面，这种模式的复杂度处于中等水平，需要重点关注状态在不同阶段之间的流转路径，以便在出现异常时准确定位问题发生的环节。

Handoffs的典型应用是客服工单流程：

此处你可能会问：Sub-Agent和Skills这两种模式都是Claude Code原生的，很容易理解，但是Hand-off 如何实现？

的确，在 Claude Code 中并不存在一个底层 API 叫 handoff()， Handoffs 是通过 Prompt + 状态约束 + 工程结构模拟出来的。

换句话说： Handoffs 是一种“工程模式”，不是一个“框架特性”。

我们来看看在 Claude Code 中实现 Handoffs 的三大工程要素。

1.明确的阶段状态（State）—— 你需要显式定义流程阶段。

2.每个阶段都是一个“角色约束的 Agent 视角”，比如：阶段一：信息收集（前台接待）；阶段二：技术诊断；阶段三：执行与修复。

3.显式的阶段完成条件（Handoff Trigger）。这是 Handoffs 能稳定运行的核心。每个阶段都必须有完成条件（Exit Criteria），否则就会“卡在阶段里出不来”。

下面是一个“Claude Code 风格”的 Handoffs 示例：

系统规则：你将按照以下阶段顺序工作： 1. 信息收集（intake） 2. 问题诊断（diagnosis） 3. 解决方案（resolution）

当前阶段：intake

规则： - 只能提问 - 不要给解决方案 - 当信息完整时，明确声明：进入 diagnosis 阶段

当 Claude 输出：

信息已收集完成，进入 diagnosis 阶段。

系统（或你自己）再注入下一段 Prompt：

当前阶段：diagnosis 你现在是技术支持 Agent……

这就是一次 handoff。

Handoffs 模式最适用于具有明确阶段划分的流程型场景，例如从信息收集到问题诊断再到解决方案输出的多阶段客服或工单系统，尤其适合那些需要在满足前置条件后才能逐步解锁能力的业务流程。在多轮对话中，该模式能够自然地完成角色切换而不打断用户体验，是对话连续性要求最高的架构选择。

Handoffs 模式的严格的顺序执行限制了并行能力，在涉及多个领域或多源查询时效率最低，但在强调流程完整性和交互自然度的场景中，往往是体验最优、可控性最强的方案。

模式四：Router（路由器 / 并行分发与合成）

Router 模式的核心在于对输入进行语义拆分与职责分流。系统首先由 Router 对用户请求进行分类和分解，然后将子查询并行分发给各自负责的专业 Agent，最后再将多个结果统一合成为一个对用户友好的响应。

这种架构天然适合处理跨多个知识域或数据源的查询，例如在企业知识库场景中，用户一次提问可能同时涉及政策文档、业务数据和实时指标，Router 可以将“退货政策”交由政策文档 Agent 处理，将“销售数据”交由数据分析 Agent 处理，并在上层完成结果整合后统一返回。

用户提问：「我们的退货政策是什么？最近的销售数据如何？」

Router 分解： ├── 查询 1：退货政策 → 政策文档 Agent ├── 查询 2：销售数据 → 数据分析 Agent └── 合成结果 → 统一回答

在 Claude Code 中，Router 通常以下面三种形态之一存在。

主 Agent 中的一段路由决策逻辑（最常见）

一个可调用的 Tool（Router-as-Tool）

一个轻量的 Sub-Agent（只负责分类，不负责执行）

本质都是同一件事：先判断“这是什么问题”，再决定“交给谁处理”。

Router模式的工程优势在于极强的并行能力和清晰的职责边界，各处理分支彼此独立、上下文完全隔离，既有利于扩展，也便于独立观测和调试。

其代价在于该模式通常是无状态的，无法充分利用历史对话上下文来减少重复计算；在需要连续对话的场景中，往往需要将 Router 作为一个工具嵌入到有状态的主 Agent 中，以在并行效率和对话连续性之间取得平衡。

性能、成本、可控性的量化对比

LangChain 对这四种模式做了实际的性能量化测试，分别从单任务请求的模型调用次数、重复请求的效率，和复杂问题的Token消耗三个方面进行了对比，结果非常有参考价值。

场景一：单任务请求（如“帮我修改函数支持分页查询”）

场景二：重复请求效率（第二轮相同类型的请求）

场景三：多领域查询（如“对比 Python/JS/Rust 的性能”）

比较上面几个表的结论，可以看出，简单任务中，Sub-Agent 模式有额外开销。多轮对话中，有状态模式效率优势明显。而在多领域查询中，上下文隔离的模式（Sub-Agent、Router）在 token 效率上优势显著——节省 40% 以上的 token 成本。

Anthropic 在工程博客中公开了他们的多 Agent 研究系统的完整设计，其中也涉及到性能和成本的权衡。Anthropic 认为多 Agent 系统中的性能差异在很大程度上是可解释的，其中约 95% 的性能波动可以归因于三个因素：Token 使用量占据主导地位，其影响约为 80%；工具调用次数与模型选择共同贡献约 15%；其余因素的影响则相对有限。

一个关键发现是，选择更合适的模型（如 Claude Sonnet 4）所带来的性能提升，往往超过单纯将 token 预算翻倍的效果，这意味着在多 Agent 架构中，模型选型的重要性显著高于无节制地增加上下文规模。

从“Token 经济学”的角度看，多 Agent 系统普遍存在约 15 倍的 token 成本放大效应，因此只适合用于高价值、高复杂度的任务；对于需要所有 Agent 共享完整上下文的场景、强耦合且高度顺序化的工作流、大多数难以并行拆解的编码任务，以及依赖 Agent 之间实时协调的系统，多 Agent 架构往往得不偿失，反而会引入不必要的成本和复杂度。

同时，从可控性和工程调整的角度，Anthropic 也分享了它们在将多 Agent 系统推向生产时，遇到了四个关键挑战。

状态性带来的复杂度。Agent 在多轮对话中维持状态，微小的失败会级联放大。一个 SubAgent 的轻微错误可能导致后续所有 Agent 的行为偏离。这种情况的应对策略是在每个 Agent 的输出端设置“检查点”，验证输出质量再传递。

非确定性调试。Agent 的动态决策使得传统的日志分析不够用。你需要完整的生产链路追踪（Production Tracing），记录每个 Agent 的输入、决策过程和输出。可以引入 Observability 工具，记录完整的 Agent 调用链。

部署复杂度。多 Agent 系统的部署不能简单地“停机更新”。因为 Agent 可能正在执行中，打断它会导致不可预测的行为。可以考虑采用新旧版本共存迁移的渐进式部署策略（Rainbow Deployment），让旧版本的 Agent 完成当前任务后自然退出，新版本接管后续请求。

同步瓶颈。当前大多数 SubAgent 是同步执行的，SubAgent 之间的信息流受限。未来的方向是打通异步执行 + Agent 间消息通道，让 SubAgent 在执行过程中可以相互共享发现。

从 Sub-Agent 到 Multi-Agent 的架构演进路径

理解了四种模式，并且清晰的理解了各种模式的性能、成本、可控性差异后，让我们看看一个项目的 Agent 架构通常如何演进。

首先给出一个升级决策树，也就是先回答这个问题——我的项目或者说任务是不是已经复杂到需要引入多Agent架构的程度了。

你的任务需要多 Agent 吗？ ├─ 单一领域、工具 < 5 个、上下文 < 50K tokens │ └─→ 不需要。用单 Agent + 好的 prompt 即可 │ ├─ 单一领域、但工具 > 10 个 │ └─→ 考虑 Skills 模式（渐进式能力加载） │ ├─ 多领域、各领域需要独立上下文 │ └─→ 使用 Sub-Agents 模式 │ ├─ 需要多步骤状态流转（如客服工单流程） │ └─→ 使用 Handoffs 模式 │ └─ 需要跨多个数据源并行查询 └─→ 使用 Router 模式

下面是一个典型的项目架构演进路径。

第一阶段：单 Agent + Tools 适合大多数初期场景。不要过早引入多 Agent。

第二阶段：单 Agent + Skills 当工具数量增多、prompt 变得臃肿时，用 Skills 实现渐进式加载。

第三阶段：Supervisor + Sub-Agents 当不同领域需要独立的上下文空间和专业知识时引入。

第四阶段：混合架构成熟系统中，不同类型的任务流可能采用不同的模式。Router 处理分类，Sub-Agent 处理并行研究，Handoff 处理顺序流程。

在佳哥个人的项目实践中，我一般上来先做简单Demo，不用什么设计模式，SubAgent和Skills，到了两三个礼拜后，感觉认知过载了，有点吃不消了，我才开始考虑上面的架构决策树。这是我个人习惯，你也可以在项目一开始就开始全局性的考量，根据具体项目性质和任务的复杂度而定，对整体架构进行详细的设计和规划。

总结一下

今天的内容讲的模式比较多，需要你多一些耐心消化理解。为了帮你更好的抓住重点，让我们做下总结。

模式选择速查表

这里也给出从单一Agent到复杂智能体系统设计的一系列黄金法则：

从单 Agent 开始 → 只在遇到明确瓶颈时才升级
先加工具，再加 Agent → Tools 是最小的扩展单位
选对模型 > 堆更多 token → 升级模型的效果超过翻倍预算
上下文隔离是核心价值 → 多 Agent 的第一价值不是并行，是隔离
Token 成本要求高价值任务 → 不是所有场景都值得多 Agent

从 Sub-Agent 到 Multi-Agent，不是一个线性的“升级”过程，而是一个根据任务特征选择合适架构的工程决策。

最好的架构不是最复杂的架构，而是恰好满足需求的最简架构。当你能用一个 Agent + 几个好 Tool 解决问题时，就不需要引入 Supervisor + SubAgents 的复杂度。但当任务的并行性、专业性和上下文管理需求确实超越了单 Agent 的能力边界时，正确的多 Agent 架构会带来显著的质量提升。

Anthropic 多 Agent 研究系统的 90.2% 性能提升证明了这一点——但 15x 的 token 成本也提醒我们：架构选型永远是性能、成本和可控性的三角博弈。

顺便提一句，开源社区里的 OpenClaw，在设计上走的是一条非常克制的路线：它并没有一开始就强调“多 Agent 协作”，而是把重心放在任务拆分、执行隔离和结果回收上。

如果用我们今天所讲的四种模式去嵌套它的设计理念，我会这样概括。

最后，用一句话总结今天这节课： Agent 的复杂度，不是靠“更聪明的模型”解决的，而是靠“更好的结构”消化的。

在2026年，Agent 已经明显从 “玩 Prompt”，进入 “拼工程结构” 的阶段了。大家都在谈 Sub-Agent、Workflow、Orchestrator，但真正的问题是：哪些是必需的？哪些是过度设计？而佳哥的新作《Agent设计模式》这本书，做的正是这件事：把 Agent 从“感觉很强” 变成 “你知道它为什么强、什么时候会失效”。

如果你希望把 Agent 当成一个可以长期演进、可调试、可维护的工程系统，而不是一次性的 Demo 或玩具，那你可以把这本书以及我们即将推出的Agent设计模式相关专栏，当成今天这套方法论的完整版与延展阅读。

思考题

思考题 1

回顾你最近做过的一个 AI Agent 项目：你引入多 Agent 的动机，是真正遇到了架构瓶颈，还是因为“看起来更先进、更专业”？

思考题 2

在你的项目中，当前最大的瓶颈更接近哪一类？（如果有别的瓶颈、痛点也欢迎分享讨论）

A. 上下文塞不下 B. 状态难以维护 C. 多领域并行效率低 D. 调试和回溯困难对应地，你现在用的架构模式是否真的对症？可以考虑一下如何重构吗？

思考题 3

你正在为公司搭建一个企业内部技术助手，主要服务研发团队，支持后面这些功能。

查询内部技术文档（设计文档、规范、Wiki）

回答代码相关问题（接口含义、调用方式）

辅助排查线上问题（日志、监控、错误码）

偶尔需要做跨领域分析（比如： “这个接口改动，会影响哪些系统？上线风险如何？”）

当前系统状态如下：

已经有 15+ 个 Tool（代码搜索、日志查询、监控查询、文档检索等）

单 Agent + 长 Prompt 已经接近上下文上限

不过用户反馈开始出现下述问题。

回答偶尔跑偏

不同问题之间互相“串味”

调试一次问题需要反复重放对话

现在团队里出现了各种方案：

方案 A：继续用单 Agent，但重写 Prompt，压缩上下文

方案 B：引入 Skills，把能力拆成按需加载的 SKILL.md

方案 C：直接上 Supervisor + Sub-Agent，把代码、文档、运维拆开

方案 D：加一个 Router，让问题并行分发给不同专家 Agent

你会选择哪一个作为“下一步演进”？为什么不是其他三个？你做这个选择的“触发信号”是什么？是工具数量、上下文长度，还是错误类型？你会如何控制这一步升级的 token 成本和调试风险？ —— 非常期待在评论区看见大家对这个问题的讨论和回答！