多 Agent 架构设计模式
何时升级到多 Agent？
两 个核心触发条件
| 触发条件 | 说明 |
|---|---|
| 上下文管理挑战 | 多个专业领域无法塞进单一 prompt |
| 分布式开发需求 | 多个团队需要独立维护各自 Agent |
原则：先从单 Agent 开始，优先通过工具扩展，只在遇到明确架构边界时才升级
四种核心设计模式
模式对比
| 模式 | 核心思想 | 上下文隔离 | 并行能力 | 复杂度 |
|---|---|---|---|---|
| Sub-Agents | Supervisor 委派任务 | 强 | ✅ 高 | 中 |
| Skills | 渐进式能力加载 | 弱 | ❌ 顺序 | 低 |
| Handoffs | 状态驱动切换 | 中 | ❌ 顺序 | 中 |
| Router | 并行分发与合成 | 强 | ✅ 高 | 中 |
模式一：Sub-Agents（集中式编排）
- Supervisor（主代理）分解任务 → Sub-Agent 执行 → 结果汇总
- 上下文隔离强，每个 Sub-Agent 独立上下文窗口
- 适合：多领域研究、并行检索
- Token 消耗增加约 15 倍，但性能提升 90%
# Claude Agent SDK 中的 Sub-Agent 定义
subagent_config = {
"name": "research-agent",
"description": "Research specific topics by searching...",
"tools": ["WebSearch", "WebFetch", "Read"],
"model": "sonnet" # 用更快的模型降低成本
}
模式二：Skills（渐进式加载）
- 单一 Agent，按需加载 SKILL.md
- 共享同一上下文，上下文隔离弱
- 适合：能力种类多但单次只需少量的场景
- 首次调用无额外开销
Skills vs Sub-Agents：
- Sub-Agent：独立的上下文 → 适合大量信息过滤
- Skills：共享的上下文 → 适合需要连贯对话的场景
模式三：Handoffs（状态切换）
- Agent A 完成阶段后交接给 Agent B
- 通过 Prompt + 状态约束模拟，不是底层 API
- 三要素：
- 明确的阶段状态
- 每个阶段是"角色约束的 Agent 视角"
- 显式的阶段完成条件
系统规则：你将按以下阶段工作：
1. 信息收集（intake）
2. 问题诊断（diagnosis）
3. 解决方案（resolution）
当前阶段：intake
规则：只能提问，不要给解决方案
当信息完整时，声明：进入 diagnosis 阶段
- 适合：客服工单等有明确阶段划分的流程
模式四：Router（并行分发）
- Router 分类分解 → 并行分发给专业 Agent → 汇总结果
- Router 本质是"无脑接线员"，不是 Supervisor
- 适合：跨多数据源并行查询
用户提问：「退货政策是什么？销售数据如何？」
Router 分解：
├── 查询1：退货政策 → 政策文档 Agent
├── 查询2：销售数据 → 数据分析 Agent
└── 合成结果 → 统一回答
性能，成本，可控性对比
场景对比
| 场景 | 推荐模式 | 说明 |
|---|---|---|
| 简单任务 | 单 Agent | Sub-Agent 有额外开销 |
| 多轮对话 | Skills / Handoffs | 有状态模式效率优势 |
| 多领域查询 | Sub-Agent / Router | 上下文隔离节省 40%+ token |
关键数据
- Anthropic 多 Agent 研究系统：性能提升 90.2%，但 token 消耗增加 15 倍
- Token 使用量占据性能波动的 80%
- 选择合适的模型带来的性能提升，往往超过单纯增加 token 预算
黄金法则
- 从单 Agent 开始 → 只在遇到明确瓶颈时才升级
- 先加工具，再加 Agent → Tools 是最小扩展单位
- 选对模型 > 堆更多 token → 升级模型效果超过翻倍预算
- 上下文隔离是核心价值 → 多 Agent 第一价值不是并行，是隔离
- Token 成本要求高价值任务 → 不是所有场景都值得多 Agent
架构演进路径
单 Agent + Tools
↓ 工具增多、prompt 臃肿
单 Agent + Skills
↓ 不同领域需要独立上下文
Supervisor + Sub-Agents
↓ 成熟系统混合架构
Router + Sub-Agent + Handoffs
升级决策树
我的任务需要多 Agent 吗？
├─ 单一领域、工具 < 5 个、上下文 < 50K tokens
│ └─→ 不需要，单 Agent + 好的 prompt
├─ 单一领域、但工具 > 10 个
│ └─→ Skills 模式
├─ 多领域、各领域需要独立上下文
│ └─→ Sub-Agents 模式
├─ 需要多步骤状态流转
│ └─→ Handoffs 模式
└─ 需要跨多个数据源并行查询
└─→ Router 模式
不适合用多 Agent 的场景
- 强耦合且高度顺序化的工作流
- 大多数难以并行拆解的编码任务
- 依赖 Agent 之间实时协调的系统
- 需要频繁来回讨论和即时调整的任务
本讲小结
Agent 的复杂度，不是靠"更聪明的模型"解决的，而是靠"更好的结构"消化的
- 最好的架构 = 恰好满足需求的最简架构
- 2026 年，Agent 已从"玩 Prompt"进入"拼工程结构"的阶段
思考题
- 回顾你最近做过的 AI Agent 项目：引入多 Agent 的动机是真正遇到瓶颈，还是"看起来更先进"？
- 你当前项目最大的瓶颈属于哪类？（上下文塞不下 / 状态难维护 / 并行 效率低 / 调试困难）
- 如果要搭建一个企业技术助手，你会选择哪种架构模式？