多智能体系统协调专门的组件来处理复杂的工作流。然而，并非每个复杂任务都需要这种方法——一个配备了正确（有时是动态的）工具和提示词的单个智能体通常可以取得类似的结果。
为什么需要多智能体？
当开发者说他们需要”多智能体”时，他们通常在寻找以下一个或多个能力：
- 上下文管理：在不超出模型上下文窗口的情况下提供专业知识。如果上下文是无限的且延迟为零，你可以将所有知识放入一个提示词中——但既然不是，你就需要有选择地呈现相关信息的模式。
- 分布式开发：允许不同团队独立开发和维护功能，以清晰的边界将它们组合成更大的系统。
- 并行化：为子任务生成专门的工作者并并发执行，以获得更快的结果。
当单个智能体拥有太多工具且难以判断使用哪个时，当任务需要包含大量上下文的专业知识（长提示词和领域特定工具）时，或者当你需要强制执行仅在满足特定条件后才解锁能力的顺序约束时，多智能体模式尤其有价值。
多智能体设计的核心是**上下文工程**——决定每个智能体看到什么信息。你的系统质量取决于确保每个智能体能够访问其任务所需的正确数据。 选择模式
使用此表将你的需求与正确的模式匹配：
- 分布式开发：不同团队能否独立维护组件？
- 并行化：多个智能体能否并发执行？
- 多跳：该模式是否支持按顺序调用多个子智能体？
- 与用户直接交互：子智能体能否直接与用户对话？
你可以混合使用模式！例如，子智能体架构可以调用工具来调用自定义工作流或路由器智能体。子智能体甚至可以使用技能模式按需加载上下文。可能性是无限的！
可视化概览
主智能体将子智能体作为工具进行协调。所有路由都通过主智能体。 智能体通过工具调用将控制权转移给彼此。每个智能体都可以交接给其他智能体或直接响应用户。 单个智能体在保持控制的同时按需加载专业提示词和知识。 路由步骤对输入进行分类并将其定向到专业智能体。结果被综合。 性能比较
不同的模式具有不同的性能特征。理解这些权衡有助于你根据延迟和成本需求选择正确的模式。
关键指标：
- 模型调用次数：LLM 调用的次数。更多调用 = 更高延迟（尤其是顺序执行时）和更高的每请求 API 成本。
- 处理的 Token 数：所有调用中的总上下文窗口使用量。更多 Token = 更高的处理成本和潜在的上下文限制。
单次请求
用户： “买咖啡”
专业的咖啡智能体/技能可以调用 buy_coffee 工具。
关键洞察： 交接、技能和路由器对单一任务最高效（各 3 次调用）。子智能体多一次额外调用，因为结果需要流回主智能体——这种开销提供了集中控制。
重复请求
第 1 轮： “买咖啡”
第 2 轮： “再买一杯咖啡”
用户在同一对话中重复相同的请求。
再次 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）
- 可以通过将其包装为有状态智能体中的工具来优化
多领域
用户： “比较 Python、JavaScript 和 Rust 在 Web 开发方面的表现”
每个语言智能体/技能包含约 2000 个 Token 的文档。所有模式都可以进行并行工具调用。
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。
将这些文档连接到 Claude、VSCode 等工具，通过 MCP 获取实时答案。 
