正式开讲前，先甩个灵魂拷问：为啥有些 AI 新品一亮相，咱们秒变“人间清醒”，瞄一眼就能把它扒得底裤都不剩；而另一些却像雾像雨又像风，看完只剩一句“啊这”？上周直播，有位同学cue到当红炸子鸡开源项目 OpenClaw。群里大佬们直接开启“显微镜模式”，三言两语就把它的核心设计扒得明明白白；而萌新们只能原地挠头，弱弱地嘟囔：“呃……它好像用了 Agent / Tool / Workflow 啥的？”

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

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

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

俗话说：站得高，看得远。本文的目标并不是交你某一个具体框架，而是帮你建立一种可以立刻用于拆解当下热门产品，也能长期指导工程设计的通用方法论。

何时该升级到多 Agent?

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

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

那么当你遇到以下场景时，就该考虑升级到多 Agent 架构了：

  • 你的任务需要同时处理多个复杂子任务，每个子任务都有自己的智能需求。
  • 你的任务需要协调不同的 AI 模型或服务，每个模型或服务都有自己的特殊能力。
  • 你的任务需要处理高并发、高延迟的场景，单 Agent 架构无法满足性能要求。

两个核心触发条件

信号一：上下文管理挑战

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

信号二：分布式开发需求

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

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

我们从工程视角出发，系统梳理出以下四种核心设计模式：

四种核心设计模式

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
# 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），非常容易实现这种架构。

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

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

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

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
---
name: deploy
description: "Deploy application to production environment"
allowed-tools: ["Bash", "Read", "Edit"]
---

## 部署步骤

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

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

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

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

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

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

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

Claude_Code_sub_agents_handoffs

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

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

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

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

Claude_Code_sub_agents_handoffs_customer_service

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

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

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

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

2.每个阶段都是一个“角色约束的 Agent 视角”，比如：阶段一：信息收集; 阶段二：问题分析; 阶段三：解决方案生成; 阶段四：用户确认; 阶段五：结束。

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

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

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

当前阶段：intake

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

当 Claude 输出：

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

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

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

这就是一次 handoff。

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

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

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

Router 模式的核心在于对输入进行语义拆分与职责分流。

系统首先由 Router 对用户请求进行分类和分解，然后将子查询并行分发给各自负责的专业 Agent，最后再将多个结果统一合成为一个对用户友好的响应。

例如在企业知识库场景中，用户一次提问可能同时涉及政策文档、业务数据和实时指标，Router 可以将“退货政策”交由政策文档 Agent 处理，将“销售数据”交由数据分析 Agent 处理，并在上层完成结果整合后统一返回给用户。

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

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

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

  1. 主 Agent 中的一段路由决策逻辑(最常见)
  2. 一个可调用的 Tool（Router-as-Tool）
  3. 一个轻量的 Sub-Agent(只负责分类，不负责执行)

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

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

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

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

来看一个项目的 Agent 架构通常如何演进。

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

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

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

第一阶段：单 Agent + Tools

适合大多数初期场景。不要过早引入多 Agent。

Claude_Code_single_agent_tools

第二阶段：单 Agent + Skills

Claude_Code_single_agent_skills

第三阶段：Supervisor + Sub-Agents

当不同领域需要独立的上下文空间和专业知识时引入。

Claude_Code_supervisor_sub_agents

第四阶段：混合架构

成熟系统中，不同类型的任务流可能采用不同的模式: Router 处理分类，Sub-Agent 处理并行研究，Handoff 处理顺序流程。

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