LangChain多智能体系统构建全攻略（非常详细），官方揭秘4种模式，从入门到精通，收藏这一篇就够了！

前言

许多智能体任务最好由具有精心设计工具的单个智能体来处理。你应该从这里开始——单个智能体更简单，易于构建、推理和调试。但随着应用程序规模的扩大，团队面临着一个共同的挑战：他们希望将不断扩展的智能体能力组合成一个统一的界面。随着他们想要组合的功能数量增长，会出现两个主要约束：

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

分布式开发：不同的团队独立开发和维护每个功能，具有明确的边界和所有权。单个庞大的智能体提示很难跨团队边界进行管理。

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

最近的研究表明，多智能体系统在这些情况下表现更好。在 Anthropic 的多智能体研究系统中，以 Claude Opus 4 作为主智能体、Claude Sonnet 4 作为子智能体的多智能体架构，在内部研究评估中比单智能体 Claude Opus 4 高出 90.2%。该架构将工作分配到具有独立上下文窗口的智能体中，实现了单个智能体无法实现的并行推理能力。

多智能体架构

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

子智能体（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 提供了开箱即用的实现，结合子智能体和技能进行复杂的任务规划。

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

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】