多智能体系统协调专业化的组件来处理复杂工作流。然而，并非每个复杂任务都需要这种方法——一个拥有合适（有时是动态的）工具和提示词的单一智能体通常也能达到类似的效果。
为什么需要多智能体？
当开发者说他们需要”多智能体”时，通常是在寻找以下一种或多种能力：
- 上下文管理：提供专业知识而不让模型的上下文窗口过载。如果上下文是无限的且延迟为零，你可以把所有知识都塞进一个提示词中——但事实并非如此，所以你需要模式来选择性地呈现相关信息。
- 分布式开发：允许不同团队独立开发和维护各项能力，并以清晰的边界将它们组合成更大的系统。
- 并行化：为子任务生成专业化的工作者，并并发执行以获得更快的结果。
当单个智能体拥有太多工具而难以做出正确的选择决策时，当任务需要具有大量上下文（长提示词和特定领域工具）的专业知识时，或者当你需要强制执行只有满足特定条件后才能解锁功能的顺序约束时，多智能体模式尤其有价值。
多智能体设计的核心是**上下文工程**——决定每个智能体能看到什么信息。系统的质量取决于确保每个智能体能够访问其任务所需的正确数据。 选择模式
使用下表将你的需求与合适的模式匹配：
- 分布式开发：不同团队能否独立维护各组件？
- 并行化：多个智能体能否并发执行？
- 多跳：该模式是否支持串行调用多个子智能体？
- 直接用户交互：子智能体能否直接与用户对话？
你可以混合使用模式！例如，子智能体架构可以调用工具来触发自定义工作流或路由器智能体。子智能体甚至可以使用技能模式来按需加载上下文。可能性无穷无尽！
可视化概览
主智能体将子智能体作为工具进行协调。所有路由都经过主智能体。 智能体通过工具调用将控制权转移给彼此。每个智能体可以交接给其他智能体或直接响应用户。 单个智能体在保持控制权的同时按需加载专业提示词和知识。 一个路由步骤对输入进行分类并定向到专业智能体。结果被合成。 性能比较
不同的模式具有不同的性能特征。理解这些权衡有助于你根据延迟和成本需求选择正确的模式。
关键指标：
- 模型调用次数：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 获取实时答案。 
