LangChain vs. LangGraph：两者的核心区别与协同开发指南

在 LLM 应用开发中，许多开发者在接触到 LangChain 和 LangGraph 时都会产生疑问：它们是竞争关系吗？LangGraph 是 LangChain 的升级替代版吗？我该选择哪一个？

简单来说，LangGraph 不是 LangChain 的替代品，而是它的超集与能力延伸。本文将从核心定位、技术架构和适用场景三个维度，为您彻底厘清两者的区别以及如何协同使用它们。

一、 核心定位对比

要理解两者的区别，最直观的方法是看它们的核心设计思想：

二、 核心技术区别深剖

1. 控制流拓扑结构：线性 vs. 循环

• LangChain 建立在 LCEL（LangChain Expression Language）之上，其核心是构建一个单向无环图 (DAG)。数据从一个组件进入，经过处理后传给下一个组件，直至结束。一旦流程中出现“如果报错就返回上一步重试”或“多轮反思纠错”等循环逻辑，LCEL 就会显得非常臃肿。
• LangGraph 允许您定义包含循环（Cycles）的图结构。你可以定义一个“Agent 思考”节点和一个“工具执行”节点，并在它们之间连上双向的边，使数据可以在两个节点间无限次循环，直至满足终止条件。

2. 状态管理方式：局部传递 vs. 全局状态机

• LangChain 中，组件之间的参数传递大多是局部的、线性的。每个步骤接收上一步的输出并产生新的输入，缺乏一个集中式的、可预测的全局状态。
• LangGraph 引入了全局 State（状态）的概念。图中的所有节点都共享同一个全局状态（通常定义为 TypedDict 或 Pydantic 模型）。任何节点都可以更新该状态，且更新方式是可预测和受控的（通过 Reducer 函数合并）。这类似于前端开发中 Redux/Vuex 的状态管理模式。

3. 人机交互（Human-in-the-Loop）支持

• LangChain 缺乏原生的任务暂停与恢复机制，如果需要在中间步骤引入人工审批（比如“发送邮件前确认”），开发者必须自己实现繁琐的拦截和状态恢复逻辑。
• LangGraph 从底层就设计了中断（Breakpoints）和持久化（Persistence）。你可以让图运行到某个节点时自动暂停，将当前状态存入数据库，等待人类通过 API 或 UI 确认后再一键恢复运行。

三、 它们是怎样协同工作的？

LangGraph 并不是要推翻 LangChain，而是站在后者的肩膀上。

在实际开发中，您的技术栈通常是： 1. 使用 LangChain 来处理底层组件的具体逻辑： * 用 ChatOpenAI / ChatOllama 调用模型。 * 用 PromptTemplate 定义提示词。 * 用 StructuredTool 将 Python 函数封装为 Agent 可以调用的工具。 * 用 StrOutputParser 解析模型输出。 2. 使用 LangGraph 来作为骨架，组织这些组件的执行顺序： * 将上述写好的 LangChain 链（Runnables）封装进 LangGraph 的 Nodes（节点） 中。 * 用 LangGraph 的 Edges（边） 编排它们的业务逻辑与流转条件。

四、 选型决策：我该用哪个？

💡 什么时候只用 LangChain？

• 工作流是线性的：例如 RAG 系统（读取文档 -> 检索向量 -> 生成回答），或者简单的顺序管道（翻译 -> 润色 -> 格式化输出）。
• 快速开发原型：业务逻辑简单，不需要复杂的自我反思或多步骤回滚。

💡 什么时候必须引入 LangGraph？

• 工作流包含循环与自我修正：例如 Coding Agent（写代码 -> 运行测试 -> 报错则将报错信息喂回 LLM 重写 -> 重新测试）。
• 需要构建多智能体系统（Multi-Agent System）：例如一个“规划 Agent”将任务分配给“研究 Agent”和“写作 Agent”，多个 Agent 之间需要频繁传递任务和共享状态。
• 需要人机协同交互：应用需要等待用户授权，或需要支持“时间旅行”（回滚到历史某一步骤修改输入并重新运行）。

五、 总结

LangChain 解决了 “如何让 LLM 方便地连接各种组件” 的问题，而 LangGraph 解决了 “如何在复杂的、非线性的、需要状态记忆的场景下调度这些组件” 的问题。两者相辅相成，共同构成了现代 LLM Agent 开发的完整技术版图。