多智能体

多智能体系统协调专业化的组件来处理复杂工作流。然而，并非每个复杂任务都需要这种方法——一个拥有合适（有时是动态的）工具和提示词的单一智能体通常也能达到类似的效果。

如需内置的多智能体支持，请使用 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 上编辑此页面或提交 issue。