一文讲透 LangChain 与 LangGraph 的本质区别

在 AI 应用开发领域，LangChain 和 LangGraph 是两个常被提及的框架。然而，许多开发者对它们的理解仅停留在表面，甚至将 LangGraph 简单地视为“更高级的 LangChain”。这种认知偏差背后，隐藏着一个更为根本的问题：我们做的究竟是一个简单的 LLM 应用，还是一个真正能够上线、能够回退、能够恢复的 Agent 系统？

从「链」到「图」的思维跨越

LangChain 的核心价值在于「快速编排」。它将 Prompt、LLM、Retriever、Tools 等能力快速串联，帮助开发者先把业务闭环跑通。一个经典的 RAG 流程——用户提问、检索知识库、拼接上下文、调用模型、返回答案——在 LangChain 中实现得极为顺畅。它本质上是一个大模型应用组件层，专注于解决「能力如何接起来」的问题。

LangGraph：Agent 系统的运行层

然而，当项目复杂度升级后，问题就来了。一旦流程中出现分支、回退、人工审核，你需要面对的就不是一条「链」，而是一张「图」。代码开始出现大量 if-else 嵌套、状态变量横飞、重试逻辑层层叠加。此时，LangChain 的局限暴露无遗——它擅长的是「能力拼装」，而非「流程治理」。

何时选择何种框架？

LangGraph 的核心定位是一个 Agent 工作流运行层。它不关心「要调用什么」，而是关心「当前执行到哪一步了」、「下一步该去哪里」、「失败了是结束、重试还是回退」、「是否需要暂停等待人工介入」、「程序中断后如何恢复」。这意味着 LangGraph 处理的不再是调用链拼装问题，而是复杂 Agent 系统的执行控制问题。

判断标准不是项目规模大小，而是问题的本质：简单项目用 LangChain 快速搭建功能；复杂项目当流程需要分支、循环、回退、状态持久化、多 Agent 协作时，就应该上 LangGraph。实际工程中，最成熟的模式是「LangChain + LangGraph」组合使用：用 LangChain 管模型调用、Prompt、Retriever、Tools 等能力组件；用 LangGraph 管节点流转、状态管理、分支控制、恢复机制。

如有侵权，请联系删除。