在多代理系统领域的众多框架中，LangGraph 是作为编排代理交互和简化复杂工作流程的强大底层工具而脱颖而出。 一个关键方面是它能够促进代理主管的角色，代理主管是负责在代理团队之间管理和委派任务的关键实体。但是，LangGraph 是处理多代理工作流程的最佳选择吗？大家将能够通过本节课程的学习和实践得到一个清晰的认知。

  在具体介绍Supervisor架构之前，我们先来看一个以Supervisor为基础架构构建而成的一个最具代表性的工具：就是微软刚刚发布的Magentic-One多代理系统。

  Magentic-One 是 Microsoft 推出的一种新的通用多代理系统， 同时也是一个基于多智能体 AI 的解决方案。在Magentic-One系统中允许多个 AI 代理协同工作，每个代理都充当其领域的“专家”去完成特定的功能，例如在软件开发过程中，一个代理会编写文档，另一个代理会审查代码，第三个代理执行质量测试等，通过这种方式实现协同效应，加速流程并改善结果，从而解决高度复杂的问题和任务。

  本节课我们将围绕 LangGraph 框架中的多智能体系统Multi-Agent Systems展开学习和应用的实践。

  Agent到底应该如何去定义？ 什么样的应用程序能算的上一个Agent？ 到现在仍然没有特别一个明确的说法和界定。有的人认为只要应用程序中集成了能够处理全领域知识查询的大模型，它就可被视为一个Agent，而更多的一部人则认为这还远不够，他们会觉得只有当一个应用程序能像人类一样思考并自主处理复杂任务时，才真正符合 Agent 的标准。大家应该都听过这样一种观点：大模型的发展使得人工通用智能（AGI）在未来成为现实的可能性也越来越大。在这个过程中，基础的Agent扮演关键角色。那么，什么样的Agent最符合未来的发展趋势呢？

  我们来看看大模型行业巨头OpenAI对AI Agent的理解。

  在2024年7月初，OpenAI 的领导层在全体内部员工会议上的分享中，定义了 AI 的五个不同阶段，共同去努力实现构建通用人工智能的最终目标。这五个阶段涵盖了从基本的聊天机器人到能够完成整个组织工作的高级系统，而第五个阶段所需要具备的能力就是可以构造出一种智能且能够执行与人类相同的所有工作的 AI 。各个阶段如下所示：

  AI Agent技术的应用，其核心目标是赋予应用程序自主和循环处理复杂任务的能力。得益于当前大模型的强大能力以及比较成熟的开发框架，这类应用已经能够在现阶段实际落地并被广泛应用。我们基于LangGraph展开讨论，到目前为止，我们已经介绍了其核心功能组件，每个组件在应用中发挥着不同的作用，具体包括：

1. 节点、边和状态模式：用于搭建图结构的具体方法，应用程序的核心骨架。
2. Router Agent 和 Tool Calling Agent 架构：实现任务路由和工具调用的逻辑，是一切复杂Agent架构的底层支撑。
3. ReAct自主循环代理：实现自主决策和交互的代理系统，支持复杂任务的执行。
4. 基于 checkpointer 的短期记忆管理：实现动态的、上下文相关的短期记忆，应对任务中的即时信息需求。
5. 基于 store 的长期记忆管理：提供持久化的长期记忆支持，便于系统根据反馈自主迭代学习和信息积累。

  我们已经探索了使用基础图结构来实现大模型交互，并逐步引入了各种代理架构，以构建能够处理更复杂逻辑的图结构。随着节点和功能的不断增加，构建出来的应用程序也具备了处理更复杂问题的能力。但是，不论是简单还是复杂的图，一个明显的限制是：之前课程中的所有实现都只能执行单一任务。也就是说，一旦图被编译并根据用户的输入运行以后，它虽然可以按照既定的图流程输出结果，但在下一次交互时，这个图将无法记住之前的对话内容。我们可以通过以下代码进行测试，观察这一现象：

  下面的代码中实现的是一个最简单、最基础的基于LangGraph构建的图：

• 之前介绍的 Router Agent 和 Tool Calling Agent，我们通过两个实际的案例证明了随着任务需求的复杂性增加，代理架构中对中间流程的控制自由度也必须相应提高。之所以要从 Router Agent 调整到 Tool Calling Agent 架构的原因在于，当路由分支中的节点涉及多个工具时，需要Agent可以根据用户的实际输入灵活选择工具，这一需求是 Router Agent 无法满足的。然而，Tool Calling Agent 的局限性又在于：虽然它可以自主选择工具，但在其架构中，每次仅能执行一次函数调用（无论是单个外部函数还是多个外部函数）。因此，当任务需要依次执行 A 工具、B 工具和 C 工具时，它无法支持这种自主控制的过程。因此，面对这种更复杂的需求，就需要引入了 Full Autonomous（自治循环代理）架构，即如下图所示：

• 在掌握了LangGraph的State状态定义模式后，我们就可以围绕LangGraph的State进入更高级的功能开发和探索阶段。
• 我们首先要探讨的是LangGraph中的代理架构，即在LangGraph框架下都能够通过哪些代理模型来构建应用。我们希望AI Agent程序带来的是更多的智能化，意味着我们希望仅仅输入一个需求，而无需关心处理过程的具体细节。随着应用变得越来越复杂，也自然而然要求基于大模型构建的系统能够具体更多的控制权限，从而才能解决更复杂的问题。
• 基于不同的需求场景，衍生出许多不同类型的代理架构，来赋予大模型不同级别的控制权，如下图所示：

• 在上一小节中我们通过比较LangChain中构建AI Agent的底层设计解释了LangGraph在应对复杂AI Agent开发场景中的明显优势。在LangGraph框架中，不论构建的代理简单或复杂，其本质都是通过节点（Node）和边（Edge）的有机组合来形成一个完整的图（Graph）。这种构建方式所形成的工作流逻辑十分清晰：每个节点在完成其任务后，都会通过边来指示下一个工作步骤，从而赋予整个应用系统更高的灵活性和可扩展性。掌握三个核心组件——状态（State）、节点（Node）和边（Edge），并了解如何使用这些基本元素构建完整的图形结构是学习和应用LangGraph框架重要且最基础的一步。通过深入理解这些关键组件足够支撑我们去设计并实现更加复杂且功能丰富的基于LangGraph的AI Agent应用程序。
• 在AI Agent应用程序的设计中，场景的复杂性直接决定了构建图的复杂度。例如，最简单的场景可能仅涉及一个大模型的问答流程，形式为：START -> Node -> END（其中大模型的交互逻辑被封装在Node中）。而更复杂的场景则可能涉及多个AI Agent的协同工作，包括多个分支和循环的构成。无论是简单还是复杂的图，LangGraph的价值永远不在于如何去定义节点，如何去定义边，而是在于如何有效管理各个节点的输入和输出，以保持图的持续运行状态。LangGraph的底层图算法采用消息传递机制来定义和执行这些图中的交互流程，其中状态（State）组件扮演着关键的载体角色，负责在图的各个节点之间传递信息。这也就意味着，LangGraph框架的核心在于State的有效使用和掌握。在复杂的应用中，State组件需要存储和管理的信息量会显著增加。核心功能如工具使用、记忆能力和人机交互等，都依赖State来实现和维护。所以，接下来我们对LangGragh框架的探索，都将紧密围绕State的实现和应用机制展开，这包括LangGraph内置封装好的工具/方法的使用，以及我们自定义构建功能时的实现方法。
• 因此，对于LangGraph的底层图算法是利用消息传递机制来定义程序的运行这一结论，在本节课中，我们将详细探讨消息（Messages）是如何通过State进行传递的，其中包含了什么传递模式和内容。

1、LangGraph底层原理介绍

• 与仅限于使用GPT系列模型的Assistant API框架不同，LangGraph是一个适用范围更广的AI Agent开发框架。在大模型的支持方面，LangGraph不仅支持GPT系列，还兼容其他多种在线或开源模型，例如 glm4、llama3和Qwen等，可以说热门的大模型均可以接入到该框架中进行AI Agent应用程序的开发。而关于大模型的接入方式，我们既可以通过传统的openai api等原生方式将大模型集成到LangGraph构建的AI Agent流程中，也可以利用ollma、vllm等大模型推理加速库，实现更加便捷和高效的集成。除此之外，在AI Agent的构建范式上，LangGraph不仅提供了预配置的ReAct代理机制，还支持更多自定义的如Planning策略的接入，以满足不同应用场景的需求。

• 从这三大方面来看，LangGraph的高度自主性和开放性确实让它在功能和灵活性上相较于Assistant API具有明显的优势。但需要注意的是，这种自主性和可扩展性也带来了更高的复杂性和开发要求。使用LangGraph意味着开发者需要进行较多的自主开发工作。此外，LangGraph框架的底层架构复杂非常复杂，这直接导致了LangGraph的学习和使用门槛相对较高。并且，经过我们长时间的探索和实践会明显发现，即使是经过多轮的尝试和优化，使用LangGraph构建的AI Agent应用程序的效果也很难超过用Assistant API几行代码就能实现的效果。所以，我们要想掌握和应用LangGraph，势必要投入更多的时间和精力。这是大家在开始学习前必须做好的心理准备。

1、DeepAgents框架定位与核心价值

1.1 什么是DeepAgents？

DeepAgents（代码库名为 deepagents）是一个基于 LangChain 和 LangGraph 构建的企业级高级智能体框架。它建立在 LangGraph（底层运行时）和 LangChain（工具/模型层）之上，是一个高阶的Agent Harness（智能体装备/套件）。

• 定位：它旨在简化长运行自主智能体 (Long-running Autonomous Agents) 的开发过程，通过内置的最佳实践和中间件，解决复杂任务中的规划、记忆、工具使用和环境交互问题。

• 核心理念：如果说 LangChain 提供了积木，LangGraph 提供了地基，那么 DeepAgents 就是一套成品级的框架。它预设了最佳实践（规划、文件系统、子智能体），让你能快速构建类似 “OpenAI Deep Research” 或 “Claude Code” 的应用。

• 论文地址：https://arxiv.org/pdf/2510.21618

  DeepAgents 开源地址：https://github.com/langchain-ai/deepagents

1、Native RAG基础流程介绍

1.1 RAG基础概念

RAG = Retrieval（检索） + Augmented（增强） + Generation（生成）

  RAG即检索增强生成，为LLM提供了从某些数据源检索到的信息，并基于此修正生成的答案。RAG 基本上是Search + LLM 提示，可以通过大模型回答查询，并将搜索所找到的信息作为大模型的上下文。查询和检索到的上下文都会被注入到发送到 LLM 的提示语中。

  一个简单完整的RAG系统如下图：用户进行了提问，提出的问题会先去知识库里进行检索答案，检索到相似度最高的前n个答案，然后和用户的提问一起放入到Prompt里，交给大语言模型，大语言模型根据用户的提问和给出检索的知识来进行整理总结，最终输出返回给用户结果。