外观
多智能体系统协调专门组件以应对复杂工作流。然而，并非每个复杂任务都需要这种方法——一个配备了合适的（有时是动态的）工具和提示词的单一智能体往往也能达到类似的效果。
TIP
如需内置的多智能体支持，请使用 Deep Agents：一个构建在 LangChain 之上的更高级框架，自带 子智能体、技能、规划、虚拟文件系统和上下文管理。
为什么需要多智能体？
当开发者说他们需要"多智能体"时，他们通常是在寻求以下一种或多种能力：
- 上下文管理：在不淹没模型上下文窗口的情况下提供专业化知识。如果上下文无限、延迟为零，你可以把所有知识塞进单个提示词——但现实并非如此，所以你需要有选择性地呈现相关信息的模式。
- 分布式开发：让不同团队独立开发和维护能力，并以清晰的边界将其组合成更大的系统。
- 并行化：为子任务生成专门的 worker 并并发执行，以更快获得结果。
当单个智能体拥有太多 工具 而无法判断该用哪个、任务需要具备大量上下文的专业知识（长提示词和领域专用工具）、或者你需要强制施加仅在特定条件满足后才解锁能力的顺序约束时，多智能体模式尤为有价值。
TIP
多智能体设计的核心是 上下文工程——决定每个智能体看到什么信息。你系统的质量取决于确保每个智能体都能为其任务访问到正确的数据。
模式
以下是构建多智能体系统的主要模式，每种模式适用于不同的用例：
| 模式 | 工作原理 |
|---|---|
| 子智能体 | 主智能体将子智能体作为工具进行协调。所有路由都经由主智能体，由它决定何时以及如何调用每个子智能体。 |
| 交接 | 行为基于状态动态变化。工具调用更新状态变量，触发路由或配置更改，从而切换智能体或调整当前智能体的工具与提示词。 |
| 技能 | 按需加载的专业提示词和知识。单个智能体保持控制权，同时在需要时从技能中加载上下文。 |
| 路由器 | 路由步骤对输入进行分类，并将其定向到一个或多个专门的智能体。结果被综合成组合响应。 |
| 自定义工作流 | 使用 LangGraph 构建定制执行流程，混合确定性逻辑和智能体行为。将其他模式作为节点嵌入你的工作流。 |
选择模式
使用此表格将你的需求与合适的模式匹配：
| 模式 | 分布式开发 | 并行化 | 多跳 | 直接与用户交互 |
|---|---|---|---|---|
| 子智能体 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐ |
| 交接 | - | - | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 技能 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 路由器 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | - | ⭐⭐⭐ |
- 分布式开发：不同团队能否独立维护组件？
- 并行化：多个智能体能否并发执行？
- 多跳：该模式是否支持按顺序调用多个子智能体？
- 直接与用户交互：子智能体能否直接与用户对话？
TIP
你可以混合使用各种模式！例如，子智能体架构可以调用那些会触发自定义工作流或路由器智能体的工具。子智能体甚至可以使用技能模式来按需加载上下文。可能性无穷无尽！
可视化概览
子智能体
主智能体将子智能体作为工具进行协调。所有路由都经由主智能体。
交接
智能体通过工具调用相互转移控制权。每个智能体都可以交接给其他智能体，或直接回应用户。
技能
单个智能体在保持控制权的同时按需加载专业提示词和知识。
路由器
路由步骤对输入进行分类并将其定向到专门的智能体。结果被综合。
性能对比
不同的模式具有不同的性能特征。理解这些权衡有助于你根据自己的延迟和成本要求选择合适的模式。
关键指标：
- 模型调用次数：LLM 调用次数。调用越多 = 延迟越高（尤其是顺序调用时）且每次请求的 API 成本越高。
- 处理的 token 数：所有调用中 上下文窗口 的总用量。token 越多 = 处理成本越高，且可能触及上下文限制。
单次请求
用户： "买咖啡"
一个专门的咖啡智能体/技能可以调用 buy_coffee 工具。
| 模式 | 模型调用次数 | 最适用 |
|---|---|---|
| 子智能体 | 4 | |
| 交接 | 3 | ✅ |
| 技能 | 3 | ✅ |
| 路由器 | 3 | ✅ |
子智能体
**4 次模型调用：**
交接
**3 次模型调用：**
技能
**3 次模型调用：**
路由器
**3 次模型调用：**
关键洞察： 交接、技能和路由器对于单一任务最为高效（各需 3 次调用）。子智能体模式多出一次调用，因为结果要流经主智能体——这种开销带来了集中化控制。
重复请求
第 1 轮： "买咖啡" 第 2 轮： "再买一杯咖啡"
用户在同一会话中重复相同请求。
| 模式 | 第 2 轮调用次数 | 总计（两轮） | 最适用 |
|---|---|---|---|
| 子智能体 | 4 | 8 | |
| 交接 | 2 | 5 | ✅ |
| 技能 | 2 | 5 | ✅ |
| 路由器 | 3 | 6 |
子智能体
**再次 4 次调用 → 总计 8 次**
- 子智能体**天然无状态**——每次调用都遵循相同的流程
- 主智能体维护对话上下文，但子智能体每次都从头开始
- 这提供了强大的上下文隔离，但会重复整个流程
交接
**2 次调用 → 总计 5 次**
- 咖啡智能体在第 1 轮后**仍然活跃**（状态持续存在）
- 无需交接——智能体直接调用 `buy_coffee` 工具（第 1 次调用）
- 智能体回应用户（第 2 次调用）
- **通过跳过交接节省了 1 次调用**
技能
**2 次调用 → 总计 5 次**
- 技能上下文**已加载**到对话历史中
- 无需重新加载——智能体直接调用 `buy_coffee` 工具（第 1 次调用）
- 智能体回应用户（第 2 次调用）
- **通过复用已加载的技能节省了 1 次调用**
路由器
**再次 3 次调用 → 总计 6 次**
- 路由器是**无状态的**——每次请求都需要一次 LLM 路由调用
- 第 2 轮：路由器 LLM 调用（1）→ Milk 智能体调用 buy_coffee（2）→ Milk 智能体响应（3）
- 可以通过将其包装为有状态智能体中的工具来优化
关键洞察： 有状态模式（交接、技能）在重复请求上节省 40-50% 的调用。子智能体保持每次请求成本一致——这种无状态设计提供了强大的上下文隔离，但代价是重复的模型调用。
多领域
用户： "比较 Python、JavaScript 和 Rust 用于 Web 开发"
每种语言的智能体/技能包含约 2000 token 的文档。所有模式都可以进行并行工具调用。
| 模式 | 模型调用次数 | token 总数 | 最适用 |
|---|---|---|---|
| 子智能体 | 5 | ~9K | ✅ |
| 交接 | 7+ | ~14K+ | |
| 技能 | 3 | ~15K | |
| 路由器 | 5 | ~9K | ✅ |
子智能体
**5 次调用，约 9K token**
每个子智能体在**隔离环境**中运行，只包含其相关的上下文。总计：**9K token**。
交接
**7+ 次调用，约 14K+ token**
交接**按顺序执行**——无法并行研究三种语言。不断增长的对话历史增加了开销。总计：**约 14K+ token**。
技能
**3 次调用，约 15K token**
加载之后，**每次后续调用都会处理全部 6K token 的技能文档**。子智能体模式由于上下文隔离，总体处理的 token 减少了 67%。总计：**15K token**。
路由器
**5 次调用，约 9K token**
路由器使用** LLM 进行路由**，然后并行调用智能体。与子智能体类似，但多了显式的路由步骤。总计：**9K token**。
关键洞察： 对于多领域任务，支持并行执行的模式（子智能体、路由器）最为高效。技能模式调用次数较少，但由于上下文累积而 token 用量较高。交接模式在这里效率低下——它必须顺序执行，无法利用并行工具调用来同时咨询多个领域。
总结
以下是三种场景下各模式的对比：
| 模式 | 单次请求 | 重复请求 | 多领域 |
|---|---|---|---|
| 子智能体 | 4 次调用 | 8 次调用（4+4） | 5 次调用，9K token |
| 交接 | 3 次调用 | 5 次调用（3+2） | 7+ 次调用，14K+ token |
| 技能 | 3 次调用 | 5 次调用（3+2） | 3 次调用，15K token |
| 路由器 | 3 次调用 | 6 次调用（3+3） | 5 次调用，9K token |
选择模式：
| 优化目标 | 子智能体 | 交接 | 技能 | 路由器 |
|---|---|---|---|---|
| 单次请求 | ✅ | ✅ | ✅ | |
| 重复请求 | ✅ | ✅ | ||
| 并行执行 | ✅ | ✅ | ||
| 大上下文领域 | ✅ | ✅ | ||
| 简单、聚焦的任务 | ✅ |