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

为何需要多智能体？

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

• 上下文管理：提供专业知识，同时避免超出模型的上下文窗口限制。如果上下文无限且延迟为零，你可以将所有知识都塞进一个提示中——但现实并非如此，因此你需要模式来有选择地呈现相关信息。
• 分布式开发：允许不同团队独立开发和维护功能，并将它们组合成一个具有清晰边界的更大系统。
• 并行化：为子任务生成专门的执行者，并让它们并发执行以获得更快的结果。

当单个智能体拥有过多工具且在选择使用哪个工具时决策不佳时，当任务需要具有大量上下文（长提示和领域特定工具）的专业知识时，或者当你需要强制执行顺序约束（即只有在满足特定条件后才能解锁某些能力）时，多智能体模式尤其有价值。

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

模式

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

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

选择模式

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

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

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

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

可视化概览

子智能体

交接

技能

路由器

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

性能比较

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

关键指标：

• 模型调用：LLM 调用的次数。调用越多 = 延迟越高（尤其是顺序调用时）且每次请求的 API 成本越高。
• 处理的令牌数：所有调用中总的上下文窗口使用量。令牌越多 = 处理成本越高，且可能触及上下文限制。

单次请求

用户： "买咖啡"

一个专门的咖啡智能体/技能可以调用 buy_coffee 工具。

模式	模型调用	最佳适用
子智能体	4
交接	3	✅
技能	3	✅
路由器	3	✅

子智能体

交接

技能

路由器

4 次模型调用：

关键洞察： 对于单一任务，交接、技能和路由器模式最有效率（各需 3 次调用）。子智能体模式多了一次调用，因为结果需要流回主智能体——这种开销提供了集中控制。

重复请求

第 1 轮： "买咖啡" 第 2 轮： "再买一次咖啡"

用户在同一对话中重复相同的请求。

模式	第 2 轮调用	总计（两轮）	最佳适用
子智能体	4	8
Handoffs	2	5	✅
Skills	2	5	✅
Router	3	6

子智能体

交接

技能

路由器

又是 4 次调用 → 总计 8 次

• 子智能体设计上是无状态的——每次调用都遵循相同的流程
• 主智能体维护对话上下文，但子智能体每次都是重新开始
• 这提供了强大的上下文隔离，但重复了整个流程

关键洞察： 有状态模式（交接、技能）在重复请求上节省了 40-50% 的调用。子智能体保持每次请求的成本一致——这种无状态设计提供了强大的上下文隔离，但代价是重复的模型调用。

多领域

用户： "比较 Python、JavaScript 和 Rust 在 Web 开发中的应用"

每个语言智能体/技能包含约 2000 个令牌的文档。所有模式都可以进行并行工具调用。

模式	模型调用	总令牌数	最佳适用
子智能体	5	~9K	✅
交接	7+	~14K+
技能	3	~15K
路由器	5	~9K	✅

子智能体

交接

技能

路由器

5 次调用，~9K 令牌

每个子智能体在隔离状态下工作，仅使用其相关上下文。总计：9K 令牌。

关键洞察： 对于多领域任务，支持并行执行的模式（子智能体、路由器）最有效率。技能模式调用次数较少，但由于上下文累积，令牌使用量很高。交接模式在这里效率低下——它必须顺序执行，并且无法利用并行工具调用来同时咨询多个领域。

总结

以下是各模式在所有三种场景下的比较：

模式	单次请求	重复请求	多领域
子智能体	4 次调用	8 次调用 (4+4)	5 次调用，9K 令牌
交接	3 次调用	5 次调用 (3+2)	7+ 次调用，14K+ 令牌
技能	3 次调用	5 次调用 (3+2)	3 次调用，15K 令牌
路由器	3 次调用	6 次调用 (3+3)	5 次调用，9K 令牌

选择模式：

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