⚡ TL;DR——30秒速览
标准LLM链、RAG管道和简单代理使用LangChain。当需要具有持久状态的复杂多步骤代理、分支逻辑、人在回路或多代理协调时，使用LangGraph。大多数严肃的代理应用应从LangChain开始，当需要状态编排时再升级到LangGraph。两者配合使用效果最佳。
快速对比
| 特性 | LangChain | LangGraph |
|---|---|---|
| 用途 | 通用LLM应用框架 | 有状态代理工作流 |
| 架构 | 链、LCEL管道 | 图节点+边+状态 |
| 状态管理 | 有限（会话级） | 一等持久状态 |
| 人在回路 | 基本中断支持 | 原生断点+恢复 |
| 多智能体 | 基本代理路由 | 完整的主管/子图模式 |
| 学习曲线 | 适中 | 较陡（图心智模型） |
| 成熟度 | 成熟、稳定的API | 较新，快速演进 |
什么是 LangChain？
使用多个数据源构建RAG管道需要编排retrievers、memory和LLM调用——LangChain的141k+ GitHub stars反映了其chain abstraction如何优雅地处理这种复杂性。与LlamaIndex以document-centric的focus不同，LangChain在agent workflows和multi-step reasoning方面表现更为出色。若需要minimal dependencies或对简单completions的latency低于100ms，可以跳过它。
——中国吧AI Tools Hub编辑团队关于LangChain
什么是LangGraph？
构建具有多个决策点的客服代理需要LangGraph的基于图的架构，以优雅地处理分支逻辑和循环，避免回调地狱。与LangChain的顺序链不同，LangGraph的3.7万+星项目使状态管理变得显式和可视化。如果需要实时流式响应则跳过它——其有状态特性会带来额外延迟，不适合低延迟应用。
— 中国吧AI工具编辑部关于LangGraph
何时选择各自
如果…选LangChain
选择LangGraph如果…
学习曲线与开发者体验
LangChain的LCEL（LangChain Expression Language）管道语法对熟悉函数组合或Unix管道的开发者很友好。大多数开发者几小时内就能掌握基本链的使用。LangGraph引入了一种基于图的思维模型，需要理解节点、边和状态转换——更复杂，但对于复杂工作流更加强大。LangChain广泛的文档和社区示例加速了上手过程。LangGraph更高的学习曲线被其优越的调试能力所弥补：你可以将执行过程可视化为DAG，使多步逻辑一目了然。团队如果熟悉工作流编排工具（Airflow、Temporal），会觉得LangGraph的概念很自然。快速原型开发时LangChain胜出；对于生产级智能体系统，LangGraph的前期学习投入会通过降低维护时的认知负担而获得回报。
状态管理与持久化
LangChain隐式处理状态——值在链的步骤间流动，但缺乏正式结构。会话数据存在于内存或外部缓存中；管理复杂的多轮对话需要手动跟踪。LangGraph将状态作为一等公民：每个节点接收显式的状态字典并返回状态变更，确保确定性和可复现的工作流。这种设计实现了天然的分段检查点功能——可以在任意节点暂停执行、检查状态、然后恢复。LangGraph开箱即用即可与外部数据库集成实现持久化。对于简单的问答系统，LangChain的隐式状态就够了。但对于处理多日工单的客户支持智能体、需要审计追踪的金融系统、或需要回滚的多智能体协商场景，LangGraph的显式状态模型是不可妥协的。LangGraph的方式消除了一整类与状态相关的bug。
生产就绪与企业级规模
LangChain在生产环境中已验证超过两年的稳定性，拥有成熟的API、完善错误处理，以及得到资金支持的公司的支持。其集成生态（300+ LLM提供商、向量数据库、SQL数据库）使其成为企业RAG和简单智能体部署的默认选择。LangGraph可投入生产但更为年轻；随着框架基于用户反馈不断演进，仍存在破坏性变更的可能。LangGraph在复杂需求方面表现出色：通过中断内置人在回路，通过子图实现多智能体编排，以及支持分布式追踪的遥测。在简单应用上标准化使用LangChain的组织可以逐步采用LangGraph用于智能体子系统——它们可以无缝互操作。对于既需要简洁又需要复杂性的关键任务系统，这种混合方式是行业标准做法。