“LangChain和LangGraph到底有什么区别”“我要学Agent开发应该先学哪个”“为什么网上教程一大堆我照着写还是云里雾里”——这差不多是我被问到最多的几个问题。每次在社区里看到类似的讨论最后几乎都会归结到同一个点上很多人把LangChain和LangGraph当成两个打架的框架其实它们根本不是同一个维度的东西。这篇文章我想根据自己的实际使用经验把这两个项目的关系、边界、选型思路以及一条我觉得比较靠谱的学习路线完整拆开来讲。1. 先搞清楚一个反直觉的事实LangGraph是LangChain团队自己出的不是竞品很多刚接触的朋友会有一个误区LangChain是一个框架LangGraph是另一个框架我要二选一。这个认知是错的而且错得比较关键因为它会直接影响你后续的学习方向。LangGraph本质上是由LangChain团队在2024年初推出的一个低层编排引擎它的定位不是替代LangChain而是解决LangChain在复杂Agent场景下的短板。LangChain的早期设计核心是Chain——也就是把多个组件像管道一样串起来每个环节调一次LLM或工具按顺序走完。这种模式在简单的“检索后生成”“模板问答”场景下挺好用。但一旦你面对的是“模型需要自己决定下一步干什么、可能反复调工具、甚至需要自我纠错”的Agent任务Chain的线性结构就捉襟见肘了。LangGraph就是冲这个问题来的。它把整个应用建模成一张图节点代表你要执行的步骤调LLM、调工具、发消息边代表状态流转节点之间可以有条件跳转也因此天然支持循环——这恰恰是Agent“自主决策”需要的核心能力。所以准确的说法是LangChain是一个组件库LangGraph是构建在LangChain生态之上的编排引擎。它们更像是“素材超市”和“厨房”的关系。从官方设计意图来看LangChain核心库负责提供模型封装、工具接入、记忆管理这些“积木”LangGraph负责用这些积木搭出能处理复杂流程的应用。这个定位差异也直接决定了学习路径的先后顺序。如果一上来就直奔LangGraph你会发现里面对话模型、工具调用的很多抽象仍然来自LangChain生态缺乏基础概念的话学起来会很吃力。反过来只学LangChain不学LangGraph你的应用在Agent阶段基本就卡死了。2. 从代码层面看差异线性Chain与图状态机的本质区别光说概念容易虚我直接用两段伪代码来说明它们在编程模型上的本质区别这也是理解两个项目差异最重要、也最绕不过去的一环。2.1 传统LangChain的Chain模式线性流水线LangChain里最典型的LCEL写法是这样的prompt ChatPromptTemplate.from_template( 用{language}写一段{code}的示例代码 ) chain prompt | llm | StrOutputParser() result chain.invoke({language: Python, code: 快排})注意这里用的是|管道符它的执行路径是固定的、单向的。输入进去以后先走prompt模板再调用LLM最后解析输出。你没法在中间让LLM决定“我不直接答先查个工具”更没法在输出结果后让流程重新跑回来修正。这就是为什么同样用LangChain老手写chain.invoke()和应用级多轮逻辑时会明显感觉“使不上劲”——核心原因是执行图在定义时就写死了。2.2 LangGraph的StateGraph模式节点-边-状态LangGraph的核心抽象是三类东西State状态贯穿整个执行的上下文容器可以是TypedDict、Pydantic模型或dataclass。每个节点运行结束后返回的dict会被增量更新到State里。Node节点一个普通的Python函数或可调用对象。入参是当前的State返回值是状态更新片段。Edge边决定流转方向。分为普通边和条件边条件边对应一条类似route的函数根据当前State返回值分支指向不同节点。一个典型的工作流是Agent节点 → 判断是否有工具调用 → 有则进入执行工具节点并回到Agent无则结束。用代码表示大概是下面这样from langgraph.graph import StateGraph, END graph StateGraph(AgentState) graph.add_node(agent, call_agent) graph.add_node(tools, run_tool) graph.set_entry_point(agent) graph.add_conditional_edge( agent, should_continue, {continue: tools, end: END} ) graph.add_edge(tools, agent) app graph.compile()这里的执行路径不是预先写死的而是运行时由模型输出决定。Agent每轮先判断有没有工具调用的需求有就派发工具执行完把结果写回状态再交给Agent继续判断——这一步天然拥抱了“循环”。而传统Chain模式里无论如何都表达不出这种自我循环结构。2.3 一个小类比做菜的流程差异可以把Chain理解成“按菜谱一步步做中间不能改”步骤是提前定好的出错了只能从头再来。把LangGraph理解成“一个厨师掌勺的厨房”厨师Agent节点自己看情况觉得菜淡了就取盐工具调用尝完不够再添直到满意上菜END。这里“按需循环”的能力正是Agent应用和对话机器人之间真正的分水岭。3. 现在的LangChain定位更像个生态底座——理解和记忆组件依然靠它聊完代码差异再聊一个更实际的问题学LangChain还有没有价值它会不会被LangGraph取代答案是LangChain死不了而且你根本绕不开它。首先是模型接入统一。LangChain的ChatOpenAI、ChatAnthropic等封装把不同厂商的API差异抹平了。你写代码时换一个类名或环境变量就能从OpenAI切换到通义千问或本地Ollama部署的模型这在多模型对比测试阶段特别省事儿。其次是工具封装。LangChain的tool装饰器可以把任意Python函数快速包装成LLM可调用的工具包括注入description、参数schema自动生成、异常处理。相比你手写Function Calling协议它省掉的不是一点半点。再者是记忆抽象。虽然它在复杂会话历史场景下能力有限后面细讲但简单场景下开箱即用的体验还是不错。当然LangChain这些组件层的能力本身也正在快速变化。官方已经明确把LangChain核心库定位成“构建块”更复杂的编排交给LangGraph。所以我的建议是LangChain要学但不用钻太深。掌握到“能封装模型、能画链、能用工具和记忆的API”这一层就够进入LangGraph学习阶段了。死磕LangChain的内部实现细节反而会浪费大量时间。从生态格局来看LangGraph这几年上升势头明显。官方文档里Agent类示例几乎全用LangGraph实现langgraph.prebuilt这种高阶封装把通用的Agent工具执行循环做了模板化加上LangSmith的集成生产级项目里用它做流程可视化和排查已经非常顺手。所以学完基础组件之后把主战场转移到LangGraph是值得的。4. 为什么很多人学LangChain学得“很碎”一个容易被忽视的学习坑我观察到很多初学者有一个共同的烦恼LangChain教程看了一大堆代码也能跑但感觉学到的东西是碎片的——这个类会用了换个场景又不会了。这个问题跟个人悟性关系不大根源在LangChain本身。**官方文档是典型的结构优秀但解构较难。**每个功能模块薅出来都很漂亮但很少有人给出一条“项目视角”的学习主线。官方教程偏概念演示每个示例都是孤立的中文社区的翻译质量参差不齐大量术语在不同的文章里叫法都不一样而且版本迭代太快第三方教程很多还停留在旧版本API甚至已废弃接口。很多人学着学着就跟不上。我踩过的坑可以给后来人参考别背API。很多朋友抱着“把所有模块过一遍”的心态啃文档结果就是“这个类我见过、那个函数我有印象”真正动手时什么都调不出来。不要跳过理解再照抄。学LangChain最忌讳一个报错跟着改一处改完下一处又报错整场下来只是在“修爆错”没有建立任何“调用链”的思维方式。版本要锁固定。LangChain和LangGraph都迭代得很快我看到太多次因为版本差异导致示例代码跑不通、还怀疑是自己配置有问题。固定一个较新的稳定版本遇到问题至少能保证参考文档和代码一致。这里给出一个判断标准如果你能熟练完成“加载模型→写模板→接一个检索向量库→串成链→加上记忆→封装成API”这一整套流程LangChain的基础就算过关了不用再继续深挖。5. 现在的LangGraph究竟比LangChain多解决了什么——Agent落地视角学完了基础组件为什么还要专门去学LangGraph我结合实际开发的经验从Agent落地最关注的几个能力来拆。**循环与条件控制。**这是LangGraph的看家本领。Agent常常需要“调工具→看结果→再决定→再调工具”这种本质上的循环在Chain里需要自己写while循环逻辑才能勉强拼出来而且状态混乱、错误处理困难。LangGraph把循环显式建模进图结构里节点之间怎么跳、什么时候停一眼看得很清楚。**状态管理的规范化。**多轮Agent的运行需要一个能持续写的上下文。LangGraph的状态机制允许每个节点把结果增量写回共享状态而且支持对状态字段的读写约束。我最早用Chain做Agent时对话历史、中间变量全靠一个Dict手写维护跑到后面根本不敢改代码换成LangGraph之后State就是函数签名类型检查和后续维护都轻松太多。**图结构的人机可读性。**图就是数据。你定义了一个图就能用配套工具看到当前跑到哪个节点、下一步去哪里。这种可观测性对调试至关重要。尤其是多Agent协作Supervisor、Swarm之类的复杂结构用“图”的心智模型去管理明显比控制流嵌套要清晰。**可扩展的运行时机制。**LangGraph支持checkpoint持久化、时间旅行、人工干预节点。比如在关键审批环节插入一个interrupt程序会暂停等待管理员确认确认后再继续执行。这在真实业务场景中太常用了但Chain做起来要么自己硬编码成套状态机要么就得绕远路。这里说句公道话**不是所有项目都需要LangGraph。**如果只是单轮问答、文档问答、固定顺序的任务流直接上LangChain是更轻的选择但只要是“让模型自己决定步骤、处理多轮工具调用、流程里有分支和循环”LangGraph就是更趁手的工具。6. 实际上手LangGraph我建议的第一周学习路径讲了这么多区别下面直接给一条实战路径。我假设你已经掌握了LangChain基础能写简单的检索问答链。具体节奏可以参考第1-2天跑通LangGraph官网的快速入门。核心目标是理解State、Node、Edge、条件边这套基本概念。不用急着看复杂示例就照着万用模板做一个最简的“输入-处理-输出”图谱跑起来看输出。重点留意StateGraph的State定义方式和add_conditional_edge的分支逻辑把基础打实。第3-4天复刻一个带工具调用的Agent。用langgraph.prebuilt的create_react_agent或ToolNode让Agent能调外部工具。建议用一个非常简单的工具函数入手比如获取当前时间、或做个数学计算观察Agent如何自主决定先调工具再回答。这个过程会真正帮你建立“模型决策→图执行”的心智模型。第5-6天加记忆和人工干预。给Agent加上MemorySaver或SqliteSaver验证它在多轮对话里能记住上下文再加一个需要人工审批的工作流理解interrupt机制以及update_state的用法。这两块都是生产级应用里高频遇到的点提前练会省很多事。第7天做一个小型串联项目。我自己比较推荐的是一个“CSDN博客智能助手”类型的练手项目输入一个问题Agent先判断是否需要搜索资料需要就调搜索插件然后综合上下文生成回答。跑完这个小项目你对“什么时候需要上LangGraph”“图的边界怎么划”会有一个感性的判断。下面是学习阶段和主要参考来源的对照表方便你安排自己的节奏阶段核心目标主要学习来源完成后你的状态基础期1-2周掌握LangChain组件用法官方文档、经典实例能独立搭检索问答链进阶期2-3周掌握LangGraph状态图核心概念官方教程搭配边学边调试能画出简单的Agent图实战期3-4周完成带工具/记忆/人工干预的Agent官方示例加真实项目里练能独立重构生产级Agent流程7. 关于Agent框架选型的真心话LangGraph、Dify、CrewAI怎么选标题相关的热搜里有人问到LangGraph、Dify、CrewAI这三家怎么选这里简单说说我的判断。**LangGraph适合自己掌控力强、要深度定制的开发者。**如果你在做复杂Agent系统比如多角色协作、动态规划、流程随时间演进LangGraph的图模型给了你近乎无限的表达能力代价是代码量会多一些。**Dify是典型的可视化应用平台。**适合非技术人员或项目需要快速交付原型的团队。它把RAG、工作流、Agent编排全部封装进可拖拽的界面里部署也方便。但它的短板也很明显灵活性有限。一旦遇到平台没有覆盖的定制需求比如复杂的状态仲裁逻辑、细粒度控制你几乎只能等平台更新或者绕过平台直接调用其底层API——到那一步你还不如直接学LangGraph。CrewAI主打“角色分工”。它把Agent定义为有role、goal、backstory的角色多个角色组成一个Crew去执行任务。上手直观尤其适合做内容生成、多步协作这类场景。但相对LangGraph它的底层控制力和生态成熟度还有明显差距遇到需要精细控制流程时容易碰壁。综合来看我的个人经验是**长期来看LangGraph的投入产出比最高。**Dify适合快速出活和业务侧人员使用CrewAI上手舒适但如果你把Agent作为技术核心竞争力来对待LangGraph的底子最值。8. 给Agent开发学习路线的一个整体建议和后续进阶思路站在更宏观的视角Agent开发不只是LangGraph一个框架的事它是一整套技能的叠加。我给一个整体结构供你参考**第一步掌握Prompt Engineering和Function Calling。**这是Agent能“自主决策”的前提理解模型如何把意图变成工具调用是编排一切后续逻辑的地基。第二步学一个组件事务封装框架。LangChain是最合适的起点重点放在模型封装、工具、记忆三块别陷进细节里。第三步系统学LangGraph。从状态图基础到ToolNode、再到多Agent协作按官方文档的例子逐步推进。第四步学习可观测性和评估。接入LangSmith这类工具学会在出现问题时读轨迹、看参数、定位错误回路。第五步补充工程化能力。并发、限流、缓存、容器化、流式输出、权限控制这些才是把Agent从Demo推向生产的关键。再往后进阶的方向非常丰富比如用LangGraph适配更多国产大模型、把图结构做成可配置的业务层Flow、用人类反馈微调Agent决策路线都是值得投入的方向。我自己还在摸索的是在LangGraph里接多模态输入和更复杂的状态仲裁逻辑踩坑不少但收益也明显。最后说点我个人的体会。框架本身只是工具真正决定上限的是你对“Agent到底该怎么和业务融合”的理解。初学时不要试图把所有API背一遍围绕一个完整的项目去推着学状态管理、工具定义、图流转这些知识自然会串起来。LangChain会迭代LangGraph也会迭代但State Node Edge这套建模思路往后很多新的Agent工具里你都会再见到它——把这套思维能力吃透才是这个阶段最有价值的成果。