LangGraph 和 LangChain 有什么区别？

上一篇文章里我们讨论了 LangGraph 是什么以及为什么 Agent 需要图结构。一个重要结论是LangGraph 解决的不是“让模型更聪明”而是让复杂 Agent Workflow 更可控。它用 State、Node、Edge 把状态、步骤、分支和循环显式组织起来。但很多人接触 LangGraph 时都会立刻产生一个问题既然已经有 LangChain为什么还需要 LangGraphLangGraph 是不是 LangChain 的替代品这篇文章就讨论这个问题。结论先说在前面LangChain 和 LangGraph 不是简单替代关系。LangChain 更像 AI 应用开发里的组件和链式调用工具箱。LangGraph 更像有状态 Agent Workflow 的流程编排框架。它们关注的问题不同但在真实项目里经常会一起使用。LangChain 主要解决什么问题LangChain 更早被大家熟悉原因很简单它把很多 LLM 应用常用能力封装成了组件。比如模型调用 Prompt 模板 Output Parser Retriever Document Loader Text Splitter Tool Chain Agent如果你要做一个基础 AI 应用LangChain 能帮你快速把这些组件串起来。比如一个简单 RAG加载文档 ↓ 切分文档 ↓ 向量化 ↓ Retriever 检索 ↓ Prompt 组装 ↓ LLM 生成答案这个流程里LangChain 的价值很明显。它提供了大量现成组件让你不用从零封装模型、检索器、提示词和输出解析。所以 LangChain 更像是AI 应用组件层它关注的是“有哪些能力可以拿来组合”。LangGraph 主要解决什么问题LangGraph 关注的问题更偏流程控制。当你的 AI 应用开始变成一个复杂 Agent 时问题就不只是“有没有组件”。而是下一步该执行哪个节点 状态应该怎么保存 什么时候调用工具 工具失败怎么处理 什么时候循环 什么时候结束 人工介入后怎么恢复 多个 Agent 怎么协作这些问题不是单个组件能解决的。它们属于流程编排问题。LangGraph 用图结构来表达这些流程。比如用户输入 ↓ 意图判断 ├─ 普通问答 ├─ 知识检索 ├─ 工具调用 └─ 人工介入每条路径都可以根据 State 动态决定。如果工具调用失败可以回到某个节点重试。如果结果不足可以继续检索。如果风险较高可以进入人工确认。所以 LangGraph 更像是Agent Workflow 编排层它关注的是“复杂流程如何可控地运行”。两者最大的区别组件 vs 流程可以用一句话区分LangChain 更关注组件组合。LangGraph 更关注状态流程。LangChain 里你经常会想我用哪个模型 我用哪个 Retriever 我用哪个 Prompt 我怎么解析输出 我怎么把几个步骤串起来LangGraph 里你经常会想我的 State 长什么样 有哪些 Node Node 之间怎么连 什么条件下走哪条边 循环什么时候停止 中断后怎么恢复这两个思考角度不一样。前者偏能力拼装。后者偏流程控制。Chain 和 Graph 的区别LangChain 里的 Chain 通常适合线性流程。比如A ↓ B ↓ C这种流程很清楚。适合固定步骤。但 Agent Workflow 经常是A ↓ 判断状态 ├─ B ├─ C └─ 回到 A这时 Graph 更自然。比如一个研究助手接收问题 ↓ 规划任务 ↓ 检索资料 ↓ 判断资料是否足够 ├─ 不足继续检索 └─ 足够生成报告这里有循环。如果用普通 Chain会很快变得绕。如果用 Graph流程结构更清楚。LangGraph 不是为了替代所有 Chain一个常见误区是看到 LangGraph 更适合复杂流程就觉得所有项目都应该改成 LangGraph。没必要。如果你的任务只是输入文本 ↓ 调用模型 ↓ 输出结果或者检索 ↓ 生成简单 Chain 就很好。复杂工具不应该用来解决简单问题。LangGraph 更适合这些情况流程会分支 流程会循环 需要保存状态 需要中途暂停 需要人工确认 需要多工具协作 需要多 Agent 协作 需要清晰追踪每一步如果没有这些需求强行上 LangGraph 只会增加理解成本。LangChain 组件可以放进 LangGraphLangGraph 并不是要抛弃 LangChain 的组件。很多时候你仍然会在 LangGraph 的节点里使用 LangChain 组件。比如一个 Node 里调用 Chat Model 一个 Node 里调用 Retriever 一个 Node 里使用 Prompt Template 一个 Node 里执行 Tool 一个 Node 里解析结构化输出也就是说LangGraph 可以负责流程骨架。LangChain 可以负责具体能力。一个简单例子LangGraph 决定先检索还是先追问用户 LangChain 负责实际检索和模型调用这种组合在真实项目里很常见。为什么 Agent 更需要 LangGraph传统 Agent 经常有一个问题所有决策都交给模型过程不够可控。比如模型决定要不要调用工具 调用哪个工具 工具结果够不够 要不要继续调用 什么时候结束这种方式灵活但也容易失控。LangGraph 的思路是把一部分流程显式化。例如先由 LLM 判断意图 再根据意图路由到不同节点 工具调用必须经过 Tool Node 工具失败进入 Error Handler 高风险操作进入 Human Review 达到最大步数直接结束这样并不是削弱 Agent。而是让 Agent 的行为边界更清楚。企业级应用里清楚比炫更重要。一个工程化对比如果用后端系统类比LangChain 有点像一组服务能力和 SDK。它提供各种功能模块。LangGraph 更像流程引擎或状态机。它负责让这些功能按照规则运行。比如一个订单系统里支付服务 库存服务 物流服务 通知服务这些是组件。但完整订单流程还需要创建订单 支付成功 扣减库存 发货 失败回滚 人工审核这就是流程。AI 应用也是一样。模型、Prompt、Retriever、Tool 是组件。Agent Workflow 是流程。LangGraph 更关注后者。项目里怎么选择可以用一个简单判断标准。如果你的项目核心是调用模型 拼 Prompt 接 Retriever 解析输出优先考虑 LangChain 或更轻量封装。如果你的项目核心是多步骤 Agent 动态路由 循环执行 工具协作 人工介入 流程恢复 多 Agent 管理LangGraph 会更合适。如果项目既需要组件能力又需要复杂流程就把两者组合起来。不要纠结谁替代谁。更重要的是清楚当前问题属于哪一层。常见误区第一个误区是认为 LangGraph 是 LangChain 的升级版。它不是简单升级而是关注点不同。第二个误区是认为用了 LangGraph 就不需要 LangChain 组件。实际项目里两者可以一起使用。第三个误区是所有 Agent 都上图结构。简单任务不需要复杂编排。第四个误区是只看 API不看流程边界。LangGraph 的关键不是某个函数怎么写而是 State、Node、Edge 怎么设计。第五个误区是把流程控制全部交给模型。企业级 Agent 需要明确的工程边界。总结LangChain 和 LangGraph 不是谁取代谁。LangChain 更像 AI 应用组件层帮助你连接模型、Prompt、Retriever、Tool 和 Parser。LangGraph 更像 Agent Workflow 编排层帮助你管理状态、节点、边、分支、循环和恢复。简单流程可以用 Chain。复杂 Agent 更适合用 Graph。真实项目里两者经常组合使用用 LangGraph 组织流程用 LangChain 组件完成具体能力。下一篇文章可以继续讨论从 Chain 到 Graph 的变化。因为只有理解线性流程为什么不够才能真正理解 LangGraph 的价值。