LangGraph 与 LangChain 深度对比：多智能体开发的框架选择指南

目标读者

有 一定 Python 编程基础、熟悉 LangChain 核心概念（如 Prompt Template、LLM、Tool、Chain）、曾尝试过开发单智能体或简单线性/条件性 Chain，但面对复杂多轮对话、有状态任务调度、多智能体协作等非线性流程感到力不从心、正在为生产级多智能体系统选型或想从底层原理理解两者本质差异的 全栈/后端/AI应用开发者。

引言

痛点引入

你是否有过这样的经历：
用 LangChain 的 SequentialChain 搭了个简单的“问答+搜索”机器人，能正常跑通；但当你想让机器人记住上一轮的上下文、自己判断要不要调用工具、根据工具返回结果循环修改回答直到满意，甚至加入几个不同角色的智能体（比如代码生成者、代码审查者、测试者）协作解决问题时，你发现 LangChain 原来的 Chain 体系越来越不够用了——ConversationChain 的状态管理依赖 Memory，耦合度高；ConditionalChain 只能做简单的分支选择，无法实现真正的循环；多智能体的话，要么用复杂的 Chain 嵌套，要么自己手写线程/协程调度，代码越写越乱，调试起来一头雾水？

或者，你最近听说 LangGraph 是 LangChain 官方推出的“下一代编排框架”，专门解决复杂有状态流程的问题，但你不知道它和 LangChain 到底是什么关系——是替代？是补充？还是“旧瓶装新酒”？你在犹豫：要不要把现有的 LangChain 项目都迁移到 LangGraph？还是两者结合使用？

文章内容概述

本文将带你从 底层原理、核心概念、架构设计、代码实现、适用场景、性能优化、未来趋势 7个维度，对 LangChain 和 LangGraph 进行全方位、无死角的深度对比。我们不会只停留在“LangChain 适合线性流程，LangGraph 适合非线性流程”这种浅尝辄止的结论上，而是会：

1. 从软件工程和状态机理论的角度，解释为什么 LangChain 会面临瓶颈；
2. 拆解 LangGraph 的节点（Node）、边（Edge）、状态（State） 三大核心要素，对比 LangChain 的 Chain/Memory 体系；
3. 用同一个实际场景（“代码生成-审查-测试-修复”多智能体协作），分别用 LangChain（传统 Chain + Agent 嵌套）和 LangGraph 实现完整代码，对比两者的代码复杂度、可读性、可维护性、可扩展性；
4. 分析两者的边界与外延——什么时候用 LangChain，什么时候用 LangGraph，什么时候两者结合最好；
5. 给出生产级开发的最佳实践，以及对两者未来发展趋势的预判。

读者收益

读完本文，你将：

1. 彻底理解 LangChain 和 LangGraph 的本质差异，不再被官方文档的概念混淆；
2. 独立判断 你的项目应该用 LangChain、LangGraph，还是两者结合；
3. 掌握 LangGraph 的核心开发流程，能快速上手搭建有状态的复杂多智能体系统；
4. 规避 传统 LangChain 开发中的常见坑（如 Memory 耦合、循环缺失、多智能体调度混乱）；
5. 了解 生产级多智能体系统的架构设计思路和性能优化方法。

准备工作

在开始阅读之前，你需要准备以下内容：

技术栈/知识

1. Python 3.10+：LangChain 和 LangGraph 都要求 Python 3.10 及以上版本（主要是为了支持 Pydantic v2 和异步编程的更好体验）；
2. LangChain 核心概念：至少要熟悉 Prompt Template、LLM（如 OpenAI GPT-4o、Claude 3.5 Sonnet）、Tool、Chain、Agent（如 ZeroShotAgent、ReActAgent）、Memory（如 ConversationBufferMemory）这些基础概念；
3. 状态机理论（可选但推荐）：了解有限状态机（FSM）、扩展有限状态机（EFSM）的基本概念，能帮助你更快理解 LangGraph 的设计思路；
4. 异步编程（可选但推荐）：LangChain 和 LangGraph 都支持异步调用，生产级应用中通常会用到异步编程来提高性能。

环境/工具

1. 已安装 Python 3.10+ 和 pip/uv：推荐使用 uv（一个快速的 Python 包管理器和项目管理工具）来管理依赖，速度比 pip 快很多；
2. 一个 OpenAI API Key：或者 Claude API Key、其他兼容 OpenAI 接口的 API Key（如本地部署的 Ollama）；
3. 一个 Python IDE：如 PyCharm、VS Code（推荐安装 Python 插件和 LangChain 插件）；
4. （可选）LangSmith：LangChain 官方推出的调试和监控平台，能帮助你可视化 Chain/Graph 的执行流程，调试起来非常方便（免费版足够个人开发使用）。

核心内容一：从软件工程和状态机理论看框架的本质

在对比 LangChain 和 LangGraph 之前，我们先跳开 AI 应用开发的具体场景，从软件工程和状态机理论这两个更底层的角度，思考：一个优秀的“流程编排框架”应该具备哪些核心能力？ 为什么 LangChain 原来的 Chain 体系无法满足复杂场景的需求？

1.1 核心概念：流程编排框架的本质

核心概念定义

流程编排框架（Orchestration Framework）：是一种用于定义、管理、监控复杂业务/任务流程的软件工具。它的核心作用是将多个独立的“执行单元”（如函数、API调用、LLM推理、工具调用）按照一定的逻辑规则组合起来，形成一个完整的“流程”，并负责处理流程中的状态管理、错误恢复、分支选择、循环调度、并发控制等问题。

流程编排框架的核心能力（软件工程视角）

从软件工程的角度，一个优秀的流程编排框架至少应该具备以下 6 大核心能力：

1.2 问题背景：传统 LangChain 开发的痛点

LangChain 是 2022 年底推出的，它的核心目标是降低 AI 应用开发的门槛——通过封装 LLM、Tool、Memory 等组件，让开发者不需要懂太多底层的 AI 技术，就能快速搭建一个单智能体或简单的 Chain 应用。

在 LangChain 推出的初期，这个目标确实实现了——很多开发者用 LangChain 快速搭建了“问答机器人”、“文档检索系统”、“代码生成助手”等应用。但随着 AI 应用的发展，开发者的需求越来越复杂——从“单轮对话”到“多轮对话”，从“线性流程”到“非线性流程（循环、分支、并发）”，从“单智能体”到“多智能体协作”。这时候，传统 LangChain 开发的痛点就逐渐暴露出来了：

问题描述一：Memory 耦合度高，状态管理混乱

传统 LangChain 的状态管理依赖 Memory 组件，比如 ConversationBufferMemory、ConversationSummaryMemory、ConversationBufferWindowMemory。这些 Memory 组件的问题在于：

1. 状态管理是隐式的：状态（如历史对话）藏在 Memory 组件的属性里，你无法直接看到或修改整个流程的状态——比如你想查看当前流程执行到哪一步了，或者想修改某个中间步骤的输出，很难做到；
2. Memory 与 Chain/Agent 强耦合：Memory 通常是作为 Chain/Agent 的初始化参数传入的，这意味着 Memory 只能被一个 Chain/Agent 使用——如果你的流程需要多个 Chain/Agent 共享状态（比如多智能体协作场景），你必须自己手写状态共享的逻辑，很容易出错；
3. 状态持久化困难：虽然 LangChain 提供了一些 Memory 持久化的工具（如 RedisChatMessageHistory），但这些工具只能持久化“历史对话”，无法持久化整个流程的状态（如当前执行到哪一步了、某个工具的调用结果）——如果流程中断了（比如服务器重启了），你很难恢复到中断前的状态。

问题描述二：Chain 体系只能支持线性/简单分支流程，无法实现真正的循环

传统 LangChain 的 Chain 体系（如 SequentialChain、LLMChain、ConditionalChain）的核心问题在于：它是基于“函数组合”的思想设计的，而不是基于“状态机”的思想设计的。

函数组合的特点是：输入→处理→输出，输出是下一个函数的输入，流程是单向的、线性的。虽然 LangChain 推出了 ConditionalChain 来支持简单的分支选择，但它无法实现真正的循环——比如你想让机器人“先调用搜索工具，根据搜索结果生成回答，如果不满意就再调用搜索工具，直到满意为止”，用传统的 Chain 体系是很难做到的（你可能需要用递归，但递归在 Python 中有深度限制，而且调试起来非常困难）。

问题描述三：多智能体调度混乱，代码复杂度高

传统 LangChain 的多智能体开发主要有两种方式：

1. Agent 嵌套：把一个 Agent 作为另一个 Agent 的 Tool；
2. Chain 嵌套 Agent：把多个 Agent 放在一个 Chain 里，用 SequentialChain 或 ConditionalChain 调度。

这两种方式的问题都在于：多智能体的调度逻辑藏在嵌套的 Chain/Agent 里，非常混乱——比如你想让“代码生成者”生成代码，然后让“代码审查者”审查代码，如果审查通过就让“测试者”测试代码，如果测试通过就结束，如果审查或测试不通过就让“代码生成者”重新生成代码，用传统的 LangChain 方式实现的话，代码会非常复杂，嵌套层数很深，没人能看懂，也很难维护和扩展。

问题描述四：调试与监控困难

虽然 LangChain 推出了 LangSmith 来帮助开发者调试和监控 Chain/Agent 的执行过程，但传统 LangChain 的 Chain 体系在 LangSmith 中的可视化效果并不理想——尤其是嵌套的 Chain/Agent，执行流程是“线性展开”的，你无法直观地看到流程的逻辑（如分支、循环）。而且，因为状态管理是隐式的，你也无法直观地看到整个流程的状态变化。

1.3 问题解决：状态机理论——LangGraph 的设计灵感

为了解决传统 LangChain 开发的这些痛点，LangChain 官方在 2024 年初推出了 LangGraph——一个专门用于有状态、非线性、多智能体流程编排的框架。LangGraph 的设计灵感主要来自于扩展有限状态机（EFSM）。

核心概念：有限状态机（FSM）与扩展有限状态机（EFSM）

有限状态机（FSM）

有限状态机（Finite State Machine, FSM）：是一种数学模型，用于描述系统的状态变化。它由以下 5 个核心要素组成：

1. 有限的状态集合（S）：系统可能处于的所有状态的集合；
2. 初始状态（S₀）：系统启动时的状态；
3. 有限的输入集合（I）：系统可能接收到的所有输入的集合；
4. 状态转移函数（δ）：定义了系统在某个状态下接收到某个输入后，会转移到哪个新状态；
5. 有限的终止状态集合（F）：系统执行结束时的状态集合（可以为空，比如一个无限循环的系统）。

FSM 的特点是：状态是离散的、有限的，状态转移是确定的。比如一个“自动售货机”就是一个典型的 FSM：

• 状态集合 S = {“待机”、“已投币”、“已选择商品”、“出货中”}；
• 初始状态 S₀ = “待机”；
• 输入集合 I = {“投币”、“选择商品”、“取消”、“出货完成”}；
• 状态转移函数 δ：比如在“待机”状态下接收到“投币”输入，会转移到“已投币”状态；在“已投币”状态下接收到“选择商品”输入，会转移到“已选择商品”状态；
• 终止状态集合 F = {“出货中” → “出货完成” → “待机”}（其实自动售货机没有真正的终止状态，它会一直循环下去）。

扩展有限状态机（EFSM）

扩展有限状态机（Extended Finite State Machine, EFSM）：是 FSM 的扩展版本，它在 FSM 的基础上增加了以下 3 个核心要素：

1. 变量集合（V）：系统的所有变量的集合（比如自动售货机的“已投币金额”、“商品库存”）；
2. 条件表达式（C）：状态转移函数的条件——只有当条件表达式为真时，状态转移才会发生；
3. 动作集合（A）：状态转移时执行的动作（比如自动售货机的“更新已投币金额”、“减少商品库存”、“找零”）。

EFSM 的特点是：状态转移不仅取决于当前状态和输入，还取决于变量的值；状态转移时可以修改变量的值。EFSM 比 FSM 强大得多，它可以描述更复杂的系统——比如一个“多智能体协作系统”就是一个典型的 EFSM。

LangGraph 的核心设计思路

LangGraph 的核心设计思路就是用 EFSM 来描述流程——它把 EFSM 的核心要素映射成了 LangGraph 的核心概念：

看到这里，你应该已经明白了：LangGraph 本质上就是一个“用 Python 实现的 EFSM 编排框架”——它把复杂的流程逻辑转换成了“节点+边+状态”的组合，非常直观、易读、易维护。

1.4 边界与外延：流程编排框架的分类

为了更好地理解 LangChain 和 LangGraph 的定位，我们可以把流程编排框架按照“流程复杂度”和“状态管理方式”分为以下 4 类：

从这个分类表格中，我们可以清楚地看到 LangChain 和 LangGraph 的定位：

• LangChain：属于“简单有状态流程框架”——它适合开发简单的单智能体应用或简单的线性/条件性 Chain 应用；
• LangGraph：属于“复杂非线性流程框架”——它适合开发复杂的有状态应用，尤其是非线性流程（循环、分支、并发）和多智能体协作系统；
• 两者的关系：LangGraph 是 LangChain 的补充，而不是替代——你可以在 LangGraph 的节点中使用 LangChain 的所有组件（如 Prompt Template、LLM、Tool、Chain、Memory），两者可以完美结合使用。

1.5 概念结构与核心要素组成

接下来，我们分别拆解 LangChain 和 LangGraph 的概念结构和核心要素组成，让你更直观地看到两者的差异。

1.5.1 LangChain 的概念结构与核心要素组成

LangChain 的概念结构是**“自底向上”**的——它从最底层的“模型 I/O”组件开始，逐步向上封装成“Chain”、“Agent”、“应用”。

LangChain 的核心要素组成可以分为以下 6 层：

LangChain 核心要素组成图（Mermaid 架构图）

LangChain 核心要素的详细说明

1. 第1层：模型 I/O（Model I/O）：这是 LangChain 的最底层，负责与 LLM/嵌入模型进行交互。核心组件包括：
   • Prompt Template/ChatPromptTemplate：用于生成标准化的提示词，支持变量替换；
   • LLM/ChatModel：封装了各种大语言模型的 API 调用，提供了统一的接口；
   • Embeddings：封装了各种嵌入模型的 API 调用，用于将文本转换成向量；
   • OutputParser：用于解析 LLM 的输出，将其转换成结构化的数据（如字符串、JSON、Pydantic 模型）。
2. 第2层：工具（Tool）：这一层负责与外部系统进行交互。核心组件包括：
   • Tool：最基础的工具类，封装了一个函数和它的描述（描述用于让 LLM 理解工具的用途）；
   • BuiltInTool：LangChain 内置的一些常用工具，如搜索工具（SerpAPI、Google Search）、Python 代码执行工具（PythonREPL）、计算器（Calculator）等；
   • CustomTool：开发者可以用 @tool 装饰器自定义工具；
   • Toolkit：工具集合，封装了一组相关的工具，如 GmailToolkit（用于操作 Gmail）、GitHubToolkit（用于操作 GitHub）等。
3. 第3层：记忆（Memory）：这一层负责状态管理。核心组件包括：
   • ChatMessageHistory：底层的消息存储类，负责存储和检索历史消息；
   • ConversationBufferMemory：最简单的记忆类，存储所有的历史消息；
   • ConversationSummaryMemory：存储历史消息的摘要，适合处理长对话；
   • ConversationBufferWindowMemory：存储最近 k 条历史消息，适合处理中等长度的对话；
   • ConversationEntityMemory：存储对话中的实体信息（如人名、地名、时间），适合处理需要记住特定信息的场景。
4. 第4层：链（Chain）：这一层是 LangChain 的核心之一，负责将多个组件组合成一个完整的流程。核心组件包括：
   • LLMChain：最基础的链，由 Prompt Template、LLM、OutputParser 组成；
   • SequentialChain：线性链，按顺序执行多个链，前一个链的输出是后一个链的输入；
   • ConditionalChain：条件链，根据条件选择执行不同的分支；
   • RetrievalChain：检索链，用于实现检索增强生成（RAG），先从向量数据库中检索相关的文档，然后将文档和用户的问题一起传给 LLM；
   • ConversationChain：对话链，由 LLMChain 和 Memory 组成，支持多轮对话。
5. 第5层：智能体（Agent）：这一层是 LangChain 的另一个核心，负责让 LLM 自主地规划和执行任务。核心组件包括：
   • Agent：最基础的智能体类，核心思想是“规划→执行→观察→规划→…”的循环（也就是 ReAct 框架）；
   • ToolCallingAgent：工具调用智能体，如 ReActAgent、OpenAIFunctionsAgent、ClaudeAgent 等，负责让 LLM 自主地选择和调用工具；
   • ConversationalAgent：对话智能体，如 ConversationalReActAgent，由工具调用智能体和 Memory 组成，支持多轮对话；
   • MultiAgent：多智能体，如 Agent 嵌套、Chain 嵌套 Agent，负责让多个智能体协作解决问题。
6. 第6层：应用（Application）：这一层是 LangChain 的最上层，也就是开发者最终要交付的 AI 应用，如问答机器人、文档检索系统、代码生成助手等。

1.5.2 LangGraph 的概念结构与核心要素组成

和 LangChain 不同，LangGraph 的概念结构是**“自顶向下”**的——它从最顶层的“图（Graph）”开始，逐步向下拆解成“节点（Node）”、“边（Edge）”、“状态（State）”。

LangGraph 的核心要素组成非常简洁，只有以下 4 个核心要素：

LangGraph 核心要素组成图（Mermaid 架构图）

LangGraph 核心要素的详细说明

1. 第1层：图（Graph）：这是 LangGraph 的最顶层，负责定义流程的整体结构。核心组件包括：
   • Graph：最基础的图类，不过 LangChain 官方推荐使用 StateGraph；
   • StateGraph：最常用的图类，基于状态的图——流程的所有节点共享同一个状态，节点可以读取和修改状态；
   • CompiledGraph：编译后的图类——当你定义好 StateGraph 的节点、边、状态后，需要调用 compile() 方法将其编译成 CompiledGraph，然后才能执行。
2. 第2层：节点（Node）：这是 LangGraph 的核心之一，负责执行具体的任务。核心组件包括：
   • Node：最基础的节点类，其实就是一个 Python 函数——节点函数接收一个参数（当前状态），返回一个字典或 Pydantic 模型（用于修改状态）；
   • NormalNode：普通节点，执行任意的 Python 代码（如 LLM 推理、工具调用、状态修改）；
   • ToolNode：专门用于执行工具的节点——LangChain 官方提供了 ToolNode 类，可以直接传入 LangChain 的 Tool 或 Toolkit，自动处理工具调用的逻辑；
   • Send：用于并发执行多个节点的组件——当你需要同时执行多个任务（如同时调用多个搜索工具）时，可以使用 Send 组件。
3. 第3层：边（Edge）：这是 LangGraph 的另一个核心，负责定义流程的状态转移逻辑。核心组件包括：
   • NormalEdge：普通边，无条件转移——执行完当前节点后直接转移到下一个节点；
   • ConditionalEdge：条件边，有条件转移——根据当前状态的值判断转移到哪个节点。条件边的核心是一个“路由函数”，路由函数接收当前状态作为参数，返回下一个节点的名称；
   • EntryPoint：入口节点，流程的起点——你需要用 set_entry_point() 方法设置图的入口节点；
   • END：结束节点，流程的终点——当流程转移到 END 节点时，流程就结束了。你可以用 set_finish_point() 方法设置图的结束节点，或者在路由函数中返回 END。
4. 第4层：状态（State）：这是 LangGraph 的灵魂，负责管理流程的所有变量。核心组件包括：
   • DictState：字典状态，用 Python 字典表示——最简单的状态类型，但不支持类型检查和状态合并策略；
   • PydanticState：Pydantic 状态，用 Pydantic 模型表示——推荐使用的状态类型，支持类型检查，能避免很多低级错误；
   • AnnotatedState：Annotated 状态，用 typing.Annotated 定义——最强大的状态类型，支持状态合并策略（比如多个并发节点同时修改同一个状态变量时，如何合并它们的修改结果）。LangChain 官方提供了一些常用的状态合并策略，如 add_messages()（用于合并历史消息）、add()（用于合并数值）、overwrite()（用于覆盖状态变量）。

1.6 概念之间的关系：核心属性维度对比与 ER 实体关系图

为了更直观地对比 LangChain 和 LangGraph 的核心概念，我们从状态管理方式、流程定义方式、执行控制方式、可复用性、可维护性、可扩展性、调试难度 7 个核心属性维度进行对比，并画出两者的 ER 实体关系图。

1.6.1 核心属性维度对比（Markdown 表格）

1.6.2 ER 实体关系图（Mermaid 架构图）

为了更直观地理解 LangChain 和 LangGraph 核心概念之间的关系，我们分别画出两者的 ER 实体关系图。

LangChain 核心概念 ER 实体关系图

LangGraph 核心概念 ER 实体关系图

1.7 交互关系图（Mermaid 架构图）

最后，我们分别画出 LangChain 和 LangGraph 的交互关系图，让你更直观地看到两者的执行流程。

1.7.1 LangChain 传统 ReActAgent 交互关系图