LangChain多智能体架构选型指南：四种模式+性能对比，从单智能体到多智能体的升级路径

在智能体应用开发领域，LangChain团队给出了一个核心原则：优先从单智能体 + 工具 + 提示词的组合方案入手。单智能体架构不仅更易于构建、推理和调试，还能满足大多数常规任务需求。但随着应用规模扩大，当开发者需要整合多领域能力、跨团队协作维护功能，或是处理复杂任务时，多智能体架构就会成为突破瓶颈的关键选择。

在这篇文章中，LangChain团队将探讨何时需要多智能体架构、我们观察到的四种主要模式，以及 LangChain 如何帮助您有效地构建多智能体系统。

许多智能体任务最好由具有精心设计工具的单智能体处理。您应该从这里开始——单智能体更易于构建、推理和调试。但随着应用规模扩大，团队面临一个共同挑战：他们拥有广泛的智能体能力，希望将其组合成一个统一的接口。随着要组合的功能数量增加，两个主要约束随之出现：

上下文管理：每个功能的专门知识无法舒适地放入单个提示中。如果上下文窗口无限且延迟为零，您可以预先包含所有相关信息。但实际上，您需要策略来在智能体工作时选择性展示信息。

分布式开发：不同团队独立开发和维护每个功能，具有清晰的边界和所有权。单一的、庞大的智能体提示在团队边界间变得难以管理。

当您管理广泛的领域知识、跨团队协调或处理真正复杂的任务时，这些约束变得至关重要。在这些情况下，多智能体架构可能成为正确的选择。

最近的研究展示了多智能体系统在这些情况下如何表现更优。在 Anthropic 的多智能体研究系统中，使用 Claude Opus 4 作为主智能体、Claude Sonnet 4 作为子智能体的多智能体架构，在内部研究评估中表现优于单智能体 Claude Opus 4 达 90.2%。该架构跨具有独立上下文窗口的智能体分配工作的能力，实现了单智能体无法完成的并行推理。

多智能体架构

四种架构模式构成了大多数多智能体应用的基础：子智能体、技能、交接和路由器。每种模式对任务协调、状态管理和顺序解锁采用不同的方法。下面我们概述了一个框架，用于选择最能解决您最关键约束的架构。

子智能体（Subagents）：集中式编排

在子智能体模式中，一个监督智能体通过将专用子智能体作为工具调用来协调它们。主智能体维护对话上下文，而子智能体保持无状态，提供强大的上下文隔离。

工作原理：主智能体决定调用哪些子智能体、提供什么输入以及如何组合结果。子智能体不记得过去的交互。这种架构提供集中控制，所有路由都通过主智能体，主智能体可以并行调用多个子智能体。

最适合：具有多个不同领域且需要集中式工作流控制、子智能体无需直接与用户对话的应用。示例包括协调日历、电子邮件和 CRM 操作的私人助理，或委托给专业领域专家的研究系统。

关键权衡：每次交互增加一次额外的模型调用，因为结果必须流回主智能体。这种开销提供了集中控制和上下文隔离，但付出了延迟和令牌的代价。

对于希望以最少设置使用此模式的开发者，Deep Agents 提供了一个开箱即用的实现，只需几行代码即可添加子智能体。

技能（Skills）：渐进式信息揭露

在技能模式中，智能体按需加载专门的提示和知识。可将其视为智能体能力的渐进式信息揭露。

虽然技能架构在技术上使用单个智能体，但它通过使该智能体动态采用专门的角色，与多智能体系统具有相似特征。这种方法提供了与多智能体模式类似的优势——如分布式开发和细粒度上下文控制——但通过更轻量级的、提示驱动的方法，而不是管理多个智能体实例。因此，也许有争议地，我们认为技能是一种准多智能体架构。

工作原理：技能主要是打包为包含指令、脚本和资源的目录的提示驱动专业化。启动时，智能体仅知道技能名称和描述。当技能变得相关时，智能体加载其完整上下文。技能内的附加文件提供第三层细节，智能体仅在需要时发现。

最适合：具有许多可能专业化的单智能体、不需要在能力之间强制执行约束的情况，或不同团队维护不同技能的团队分布。常见示例包括编码智能体或创意助手。

关键权衡：随着技能加载，上下文在对话历史中累积，这可能导致后续调用时的令牌膨胀。然而，该模式提供了简单性，并贯穿始终实现直接用户交互。

交接（Handoffs）：状态驱动的转换

在交接模式中，主动智能体根据对话上下文动态变化。每个智能体都有能力通过工具调用转移到其他智能体。

工作原理：当智能体调用交接工具时，它会更新决定下一个激活智能体的状态。这可能意味着切换到不同的智能体，或更改当前智能体的系统提示和可用工具。状态在对话轮次中保持，实现顺序工作流。

最适合：分阶段收集信息的客户支持流程、多阶段对话体验，或任何需要顺序约束且能力仅在满足先决条件后解锁的场景。

关键权衡：比其他模式更具状态性，需要仔细的状态管理。然而，这实现了流畅的多轮对话，上下文在阶段之间自然延续。

路由器（Router）：并行分派与合成

在路由器模式中，路由步骤对输入进行分类，并将其定向到专门的智能体，并行执行查询并合成结果。

工作原理：路由器分解查询，并行调用零个或多个专门的智能体，并将结果合成为连贯的响应。路由器通常是无状态的，独立处理每个请求。

最适合：具有不同垂直领域（独立知识领域）的应用、需要跨多个源并行查询的场景，或需要从多个智能体合成结果的情况。示例包括企业知识库和多垂直领域客户支持助手。

关键权衡：无状态设计意味着每个请求的性能一致，但如果需要对话历史记录，则存在重复的路由开销。可以通过将路由器包装在状态化对话智能体内的工具中来缓解。

将需求与模式匹配

在实施多智能体系统之前，请考虑您的需求是否与以下四种模式之一相符：

下表显示了每种模式如何支持常见的多智能体需求：

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

性能特征

架构选择直接影响延迟、成本和用户体验。我们分析了三种代表性场景，以了解不同模式在真实条件下的表现。

注意：您可以在我们新的多智能体性能文档中找到完整的性能细分（每个架构都有 Mermaid 图）。

场景 1：单次请求

用户提出单一请求："买咖啡"。一个专门的智能体可以调用 buy_coffee 工具。

关键洞见：对于单一任务，交接、技能和路由器最有效（各 3 次调用）。子智能体增加了一次额外调用，因为结果流回主智能体。这种开销提供了集中控制，如下所示。

场景 2：重复请求

用户在对话中提出相同请求两次：

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

关键洞见：状态化模式（交接、技能）通过维护上下文，在重复请求上节省了 40-50% 的调用。子智能体通过无状态设计保持每次请求的成本一致，以重复的模型调用为代价提供强大的上下文隔离。

场景 3：多领域查询

用户询问："比较 Python、JavaScript 和 Rust 在 Web 开发中的应用。" 每个语言智能体包含大约 2000 个令牌的文档。所有模式都可以进行并行工具调用。

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

在此场景中，由于上下文隔离，子智能体处理的总令牌数比技能少 67%。每个子智能体仅使用相关上下文工作，避免了将多个技能加载到单个对话中时累积的令牌膨胀。

性能总结

最佳模式取决于您的工作负载特征：

开始使用

多智能体系统协调专门的组件来处理复杂的工作流。当您确实需要多智能体能力时，请根据上述决策框架匹配您的需求。对于希望快速开始的团队，Deep Agents 提供了一个结合子智能体和技能以进行复杂任务规划的开箱即用实现。

然而，在许多情况下，更简单的架构往往就足够了。从单智能体和良好的提示工程开始。在添加智能体之前先添加工具。只有当您遇到明确的限制时，才升级到多智能体模式。（来源）