LangChain vs. LangGraph：如何选择正确的框架

当你着手构建基于大语言模型的应用时，LangChain 和 LangGraph 这两个开源框架几乎一定会出现在你的视野里。它们同属一个生态，看起来很相似，甚至常被外界当作竞争对手来讨论。但真正有价值的问题不是"哪个更好"，而是"什么情况下该用哪一个"。答案取决于你要构建的应用形态。

本文基于 IBM Technology 的视频内容整理，通过具体示例和维度对比，帮你厘清两者的定位差异，并给出可操作的选型建议。

核心定位：抽象层 vs. 工作流引擎

LangChain 是更早、更庞大的那个生态。它的核心作用是把 LLM 调用串联成链——执行一系列函数来完成一个流程。它提供的是抽象层，负责把各种 LLM 操作连接起来，而不是充当工作流引擎。你可以把它理解为整个生态的基础层。

LangGraph 则是 LangChain 生态内的一个专门库，为有状态的多智能体系统而生，处理复杂的非线性工作流。它把流程建模为图：节点代表动作，边代表动作之间的转移，再加上一个贯穿全局的状态组件。

两者共享同一个生态基础，这正是选择时容易混淆的根源。但它们的出发点和解决的问题并不相同。

用一个例子理解 LangChain

假设你要做一个应用，需要按顺序完成三件事：从网站抓取数据、对数据做摘要、再用摘要回答用户问题。流程是"抓取 → 摘要 → 回答"。

LangChain 把这个流程拆成可复用组件：

• 抓取：文档加载器（document loader）从各类数据源获取内容；如果文档太大，文本分割器（text splitter）会把文本切成语义完整的小块。
• 摘要：一条链（chain）编排摘要过程，其中可以包含提示词（prompt）组件来指示 LLM 执行摘要，以及 LLM 组件把请求发给所选的大模型。
• 回答：第二条链生成答案，可能包含记忆（memory）组件来存储对话历史和上下文，再加上提示词和 LLM 组件。

值得留意的是模块化设计带来的灵活性：摘要环节和回答环节完全可以使用不同的大语言模型，整个流程不强制你绑定单一模型。这正是 LangChain 的价值——用高层可复用组件组合出复杂流程，而不必每个步骤都从零手写。

用一个例子理解 LangGraph

LangGraph 适合的场景是任务管理助手这类有状态、多分支的智能体。流程从处理用户输入开始，然后分支到添加任务、完成任务、汇总任务等动作。

LangGraph 用图结构来建模：

• 节点代表动作，添加任务、完成任务、汇总各是一个节点。
• 边代表这些动作之间的转移。
• 处理输入节点是中心节点，用户输入到达这里，它用 LLM 组件理解用户意图，再路由到对应的动作节点。

另一个中心组件是状态。状态组件在所有交互中维护任务列表：添加任务节点往状态里加新任务，完成任务节点把任务标记为完成，汇总节点用 LLM 生成当前任务的概览。

由于所有节点都能访问和修改状态，这个助手能实现上下文感知的有状态交互。图结构让助手能以任意顺序处理各类请求，并在动作完成后总是回到处理输入节点。最终得到的是一个灵活、有状态、能在长时间交互中维持上下文的智能体。

逐维度对比：真正的分水岭在哪里

两者的差异不是一张功能对照表能概括的，而是由核心定位的不同衍生出一系列权衡。

结构与执行方式

LangChain 采用链式结构，本质上是一个有向无环图（DAG）——任务按特定顺序执行，永远向前推进。你可以从任务一开始，分支到任务二和任务三，再汇合到中心任务四。当你知道确切的步骤顺序时，这种方式非常合适。

LangGraph 的图结构允许循环，也允许回到之前的状态。状态 A 可以与状态 B、C 之间来回移动。对于下一步取决于变化条件或用户输入的交互式系统，这一点至关重要。

有向无环图（DAG） 是图论中的基本概念：由节点和有方向的边组成，且不存在任何一条从某节点出发、沿边的方向最终又回到该节点的路径。在数据处理和编排系统中，DAG 常被用作执行模型的约束——它保证了任务之间不存在循环依赖，因此可以推导出确定的拓扑执行顺序，每个任务只在其所有前置任务完成后执行一次。这正是 LangChain 链式结构的行为特征：流程只能向前推进，不能回退。反过来，一旦允许图中出现环（即形成循环），执行顺序就不再由拓扑排序唯一确定，而必须依赖运行时状态来决定下一步走哪条边，这正是 LangGraph 图结构能力的基础。

循环（cycle） 在状态机语境下指的是控制流回到已访问过的节点。对于交互式智能体而言，循环是不可或缺的：用户提出新请求时，流程必须从动作节点返回到输入处理节点，重新理解意图再路由。LangGraph 的图刻意保留了这一能力，代价是开发者需要显式管理状态转移的终止条件，避免陷入无限循环。

组件构成

LangChain 使用记忆、提示词组件、LLM 组件和智能体组件，由智能体在各组件之间形成链。LangGraph 使用节点、边和状态，它们都是图的一部分。

状态管理——最清晰的分界线

LangChain 的状态管理相对有限。它能在链中来回传递信息，但不容易在多次运行之间维持持久状态；其记忆组件能在交互之间保留一些状态。LangGraph 则把状态作为核心组件，所有节点都能访问和修改，从而支持更复杂、上下文感知的行为。这是两者最本质的区别。

LangChain 中的记忆（memory） 组件通常以对话缓冲区、摘要或向量化存储的形式存在，作用是在单条链或单个会话内把历史上下文注入提示词。它的局限在于作用范围：记忆依附于具体的链实例，跨进程、跨多次独立运行的状态持久化并不属于其设计目标。而 LangGraph 的状态是一个贯穿整张图、可被序列化的共享对象，每个节点在执行时都会收到当前状态并返回状态更新，框架负责合并这些更新并在节点间传递。这种设计使状态天然支持检查点（checkpoint）机制，从而能够中断、恢复和回放长时运行的工作流。理解这一区别有助于判断：需要复用历史但流程固定时用 memory 即可，需要让状态驱动分支与路由时才需要 LangGraph。

适用场景

LangChain 擅长顺序任务，比如抓取数据、处理、输出结果的流程；它的智能体功能能在一定程度上处理非顺序任务。LangGraph 的强项是复杂得多的场景：需要持续交互和适应的系统，比如要在长对话中维持上下文、处理各种类型请求的虚拟助手。

选型建议：看工作流形态，而非框架优劣

决策的关键在于你的工作流如何运转，而不是哪个框架更"好"。

当工作是直接的链式流程时，选 LangChain。 你知道确切的步骤顺序，任务按序推进、一路向前，检索、处理、输出的流程就是典型例子。模块化组件还允许你在不同步骤间切换模型。

当工作流是有状态、多智能体、非线性时，选 LangGraph。 下一步取决于变化的条件或用户输入，上下文需要在长时间交互中持续存在，这时候图结构的循环能力和核心状态组件就派上用场。

两者是互补而非互斥的。 LangGraph 就住在 LangChain 生态里，所以真正的选择往往是分层：用 LangChain 做链式编排和组件复用，当工作流需要循环、持久状态和多智能体时，再把 LangGraph 叠加上去。

与其纠结站队，不如从 LangChain 开始，当你的流程超出直线形态时再引入 LangGraph。这种渐进式路径既降低了起步成本，也为未来的复杂度预留了空间。