多智能体

多智能体系统协调专门的组件来处理复杂的工作流。然而，并非每个复杂任务都需要这种方法——一个配备了正确（有时是动态的）工具和提示词的单个智能体通常可以取得类似的结果。

如需内置的多智能体支持，请使用 Deep Agents：一个构建在 LangChain 之上的高级框架，内置子智能体、技能、规划、虚拟文件系统和上下文管理。

为什么需要多智能体？

当开发者说他们需要”多智能体”时，他们通常在寻找以下一个或多个能力：

• 上下文管理：在不超出模型上下文窗口的情况下提供专业知识。如果上下文是无限的且延迟为零，你可以将所有知识放入一个提示词中——但既然不是，你就需要有选择地呈现相关信息的模式。
• 分布式开发：允许不同团队独立开发和维护功能，以清晰的边界将它们组合成更大的系统。
• 并行化：为子任务生成专门的工作者并并发执行，以获得更快的结果。

当单个智能体拥有太多工具且难以判断使用哪个时，当任务需要包含大量上下文的专业知识（长提示词和领域特定工具）时，或者当你需要强制执行仅在满足特定条件后才解锁能力的顺序约束时，多智能体模式尤其有价值。

多智能体设计的核心是**上下文工程**——决定每个智能体看到什么信息。你的系统质量取决于确保每个智能体能够访问其任务所需的正确数据。

模式

以下是构建多智能体系统的主要模式，每种模式适用于不同的用例：

模式	工作原理
子智能体	主智能体将子智能体作为工具进行协调。所有路由都通过主智能体，由其决定何时以及如何调用每个子智能体。
交接	行为基于状态动态变化。工具调用更新状态变量以触发路由或配置变更，切换智能体或调整当前智能体的工具和提示词。
技能	按需加载的专业提示词和知识。单个智能体保持控制，同时根据需要从技能中加载上下文。
路由器	路由步骤对输入进行分类并将其定向到一个或多个专业智能体。结果被综合成组合响应。
自定义工作流	使用 LangGraph 构建定制的执行流程，混合确定性逻辑和智能体行为。将其他模式作为工作流中的节点嵌入。

选择模式

使用此表将你的需求与正确的模式匹配：

模式	分布式开发	并行化	多跳	与用户直接交互
子智能体	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐
交接	-	-	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
技能	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
路由器	⭐⭐⭐	⭐⭐⭐⭐⭐	-	⭐⭐⭐

• 分布式开发：不同团队能否独立维护组件？
• 并行化：多个智能体能否并发执行？
• 多跳：该模式是否支持按顺序调用多个子智能体？
• 与用户直接交互：子智能体能否直接与用户对话？

你可以混合使用模式！例如，子智能体架构可以调用工具来调用自定义工作流或路由器智能体。子智能体甚至可以使用技能模式按需加载上下文。可能性是无限的！

可视化概览

子智能体

主智能体将子智能体作为工具进行协调。所有路由都通过主智能体。

交接

智能体通过工具调用将控制权转移给彼此。每个智能体都可以交接给其他智能体或直接响应用户。

技能

单个智能体在保持控制的同时按需加载专业提示词和知识。

路由器

路由步骤对输入进行分类并将其定向到专业智能体。结果被综合。

使用 LangSmith 追踪跨智能体的完整协调流程。按照追踪快速入门进行设置。

性能比较

不同的模式具有不同的性能特征。理解这些权衡有助于你根据延迟和成本需求选择正确的模式。

关键指标：

• 模型调用次数：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）→ 咖啡智能体调用 buy_coffee（2）→ 咖啡智能体响应（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

选择模式：

优化目标	子智能体	交接	技能	路由器
单次请求		✅	✅	✅
重复请求		✅	✅
并行执行	✅			✅
大上下文领域	✅			✅
简单聚焦的任务			✅

---

将这些文档连接到 Claude、VSCode 等工具，通过 MCP 获取实时答案。

在 GitHub 上编辑此页面或提交问题。