1. 先搞清楚LangChain 和 LangGraph 到底谁是谁说实话这两名字放一起十个人里有八个——包括我自己刚接触的时候——会以为 LangGraph 是 LangChain 的某个插件或者升级版。实际用下来你会发现它俩确实出自同一个团队但设计哲学几乎隔了一代人。网上铺天盖地对比 langchain 和 langgraph 哪个好但如果只看表面 API 差异很容易陷入学 A 还是学 B的死胡同。我先把这俩的定位掰开说清楚后面再给学习路线大家好按自己的阶段对号入座。1.1 LangChain围绕链的生态全家桶LangChain 是 2022 年底由 Harrison Chase 发起的开源项目它解决的问题非常直接当时调用各家大模型 API 写应用每个工程师都在重复造轮子——封装 prompt、拼接模型调用、解析输出、做记忆、接检索。LangChain 把这些琐碎能力抽象成 Model、Prompt、Chain、Memory、Retriever、Tool、Agent 这些积木并且用 LCELLangChain Expression Language把积木串成管道。风头最盛的时候Github 上 star 涨得比大多数知名框架都猛。注意这里的核心抽象是 Chain。链是什么就是取文档 - 拼 prompt - 调模型 - 解析结果这类步骤按顺序执行。后来官方又加了 AgentExecutor 来处理带循环的 Agent但底层依然像个黑盒调度器你没法在中途插一手也没法精确控制它什么时候停。早期这问题不致命因为大家做的多是单轮 RAG、简单问答链式结构完全够用。在我前几个项目里LangChain 最舒服的地方是生态。几百个第三方集成、成熟的文档加载器、现成的文本拆分器、各种向量库适配第一版 RAG 真的可以一个周末跑通。这是它的核心价值把高频模式标准化让人快速上路而不是让你从零设计一套编排系统。1.2 LangGraph把流程控制权交还给开发者LangGraph 是同一个团队在 2024 年初开出来的新项目。它的核心思路转变很大别再给我一个封装好的 Agent 黑盒给我一张图我来画节点和边。这张图的节点就是你要执行的函数边就是节点之间的跳转关系。和 LangChain 最大的差异有两个。第一图允许有环也就是说支持 Agent 那种反复思考、调用工具、观察结果、再思考的循环而不是一条道走到黑。第二它有一个显式的 State状态概念每个节点可以读取和更新公共状态执行结果会被持久化到检查点Checkpoint里。LangGraph 底层借鉴了 Google Pregel 的 BSP 模型整个图的执行被包装成超步superstep之间的消息传递每一步结束都可以落盘快照。我第一次接触 LangGraph 的真实感受是这不是 Agent 框架这是个流程编排框架只是碰巧特别适合写 Agent。它给的抽象层级更低你得多写不少胶水代码——定义状态、写条件函数、挂检查点——但换来的是对流程的绝对掌控。1.3 两者是替代关系还是上下级关系先说结论LangGraph 不是要替代 LangChain而是 LangChain 团队基于 LangGraph 的图能力重新设计了 Agent 层的实现。这是一条很重要的信息线。官方在 2024 年下半年逐步把基于 AgentExecutor 的旧 Agent 实现标记为 Legacy过时新 Agent 建议走 LangGraph 的 create_react_agent 这类新接口。但 LangChain 里的模型封装、Prompt 模板、输出解析器、文档加载器、向量库集成这些基础设施原样保留LangGraph 节点内部完全可以继续用 LangChain 组件。所以现在去看官方文档会发现它俩经常混着出现LangGraph 负责编排与控制流LangChain 负责模型交互与生态集成。学习的时候千万别把它们当二选一正确姿势是先会用 LangChain 做积木再用 LangGraph 搭骨架。2. 技术本质对比线性执行与图状态机的分水岭2.1 执行模型DAG 与循环图的根本差异LangChain 的 Chain 本质是有向无环图DAG。意思是步骤可以分叉、可以并行但不能回头。RAG 流程里检索 - 生成就是典型的 DAG但一个真正的 Agent 需要循环比如调用工具 - 观察结果 - 决定是否再调用这时候 DAG 就卡住了。带循环也不是完全没法做AgentExecutor 就是硬塞出来的方案但问题在于你没法控制循环的退出条件、没法在中间暂停、也没法观测整个执行过程。LangGraph 直接把这个能力做成了一等公民你定义节点定义边的条件函数图引擎自己决定下一步往哪走。打个比方LangChain 像流水线工件从一端进去经过固定工位加工从另一端出来LangGraph 像状态机每个状态节点根据输入条件和当前状态决定迁移到哪个后续状态可以反复循环直到满足终止条件。前者为流程确定的场景准备后者为流程需要运行时决策的场景准备。2.2 状态管理隐式传递与显式 State这是两者使用体验上最大的差异也是新手最容易懵的地方。LangChain 里数据在步骤间怎么传靠 Chain 内部的输入输出字典隐式传递你不需要也不能直接管理它。LCEL 虽然定义了输入输出的 schema但每一步内部发生了什么你很难干预。想拿到中间结果得靠各种回调钩子调试体验相当绕。LangGraph 里的核心抽象是 State。你可以把它理解成一张所有人共享的白板。每个节点函数接收整个 State返回值会被合并回 State注意是合并不是整体覆盖顶层 key 默认做浅合并。这样每个节点都能读到前序节点写入的数据也能写入自己的部分数据。如果某个 key 需要特殊合并逻辑比如消息列表要追加而不是覆盖就得给这个 key 挂一个 reducer 函数。这种设计带来的直接好处是可控性。我可以在任何节点里打印 State 确认内容可以在边函数里根据 State 决定分支还可以让多个节点并行读写同一份 State。坏处也很明显如果你往 State 里塞了文档全文或者大段中间结果每轮执行都会产生序列化和传输开销性能会肉眼可见地下降。这块后面实操部分细讲。2.3 持久化、断点续跑与人机协同LangGraph 另一个让 LangChain 望尘莫及的能力是 Checkpoint。简单说每执行完一个节点系统就把当前 State 完整保存一份快照。这带来三个实际价值第一程序崩溃了可以从最近的快照恢复第二能拿到完整执行轨迹随时回放任意一步的状态官方叫 Time Travel第三支持 Human-in-the-loop流程跑到某个节点先停下来等人工确认后再继续。这一点在真实业务里太重要了。我做过的客服工单系统要求 AI 给出处置建议后必须人工审核才能发出去。用 LangChain 写这个暂停逻辑相当痛苦要在 Chain 外面包一层状态机来记录当前执行到哪一步用 LangGraph 只需要定义一个 interrupt 节点图会在那里停住等外部调用 resume 后继续往下跑。2.4 选型判断什么场景用哪个结合我的实践给一个不算严谨但很实用的判断标准如果你的流程画出来是一根直线或者一棵树分支不需要回跳用 LangChain 就够了别给自己找复杂度。如果你的流程画出来有循环箭头或者需要中途暂停、回退、多重条件路由直接上 LangGraph。具体场景对应简单问答、文档解析流水线、单轮 RAGLangChain 更省事多工具调用 Agent、多 Agent 协作比如一个 Supervisor 管几个 Worker、需要人工审批流的后台系统、长时间运行且需要断点续跑的任务LangGraph 是更稳的选择。记住一个原则能用直线表达的需求就别用状态机。3. 站在现在的视角看框架选型LangChain、Dify、CrewAI 怎么挑网上问得最多的就是agent框架如 LangChain、Dify、CrewAI 等哪个好。我先把一个前提说清楚没有最好的只有最匹配你团队的。问这个问题之前先搞清楚自己是开发者、产品经理还是只想快速验证 idea。3.1 Dify面向业务交付的低代码平台Dify 这一类还包括 FastGPT、扣子是平台型产品核心卖点是可视化编排、内置 RAG 管道、知识库管理、模型统一接入和 API 发布。你不太需要写代码拖拽节点就能搭出一个聊天应用。它的优势是交付效率极高尤其适合非纯技术团队和 ToB 演示项目。团队里如果没人能长期维护代码Dify 是现实选择。劣势是对复杂控制流的支持有限你只能在它给的可视化节点范围内发挥遇到需要精细状态控制的场景会很别扭。比如你要在某个节点做循环直到满足条件或者依赖外部系统的回调再做决策平台方案往往会卡住。3.2 CrewAI轻量多智能体协作CrewAI 是另一个红极一时的开源框架主打角色扮演式多 Agent 协作你把任务拆给不同角色的 Agent它们按你定义的 Process 顺序或层级协作。上手确实比 LangGraph 简单API 设计直觉化适合快速搭一个多 Agent 演示。但它的抽象层比较厚复杂分支、循环、持久化这些深度控制上不如 LangGraph。我自己的判断是CrewAI 适合中等复杂度的多角色场景想快速出活可以尝试一旦业务进入生产环境要精细控制状态、要做人工兜底、要审计每一步它就显得力不从心。3.3 我的选型建议与对比速览如果你是会写 Python 或 TypeScript 的开发者并且要做能上生产的应用我的建议很直接主学 LangChain LangGraph。理由有三个。第一生态存量最大。遇到模型封装、Prompt 优化、输出解析、RAG 全套组件LangChain 集成基本覆盖你不需要到处找第三方库。第二LangChain 团队是当前 Agent 编排领域迭代最激进的一波LangGraph 的新特性几乎按生产需求打磨。第三学习曲线是通用的你理解图状态机之后再去看别的框架源码套路都一样不会被某个平台锁死。维度LangChain LangGraphDifyCrewAI定位开发框架低代码平台轻量多 Agent 框架上手门槛高需要写代码低中控制流能力最强图 状态机一般中等深度定制灵活受限中等适合人群应用开发者产品/交付团队Demo 与中轻量场景4. 学习路线从零到 LangGraph 实战的正确顺序这块是标题里的核心。我见过太多人一上来就啃 LangGraph结果被 State、节点、边、Checkpointer 绕晕回头抱怨文档难。其实问题不在文档在于跳跃式学习跳过了前置知识。我给出一条自己验证过有效的路线每一步都建议配一个小项目。4.1 阶段一打好 LLM 应用基础不碰框架也能干活先说硬门槛Python 3.10、类型注解、async/await、装饰器、Pydantic 模型、环境变量管理这些是基本功。然后是 LLM 应用三件套Prompt 工程、函数调用Tool Calling、RAG 基础。函数调用这块特别强调一下它是现代 Agent 的地基。你要理解模型输出结构化 JSON - 映射到函数签名 - 执行函数 - 把结果回传给模型这件事。LangChain 里的 tool 装饰器、StructuredOutput 都是建立在这个机制上LangGraph 的 ToolNode 也是。这个阶段不需要碰框架用原生 API 写一个能调用天气查询工具的脚本跑通上述循环你就完成了最重要的认知建设。很多人跳过这步直接学框架结果遇到问题分不清是框架的锅还是模型调用的锅排查起来非常痛苦。4.2 阶段二用 LangChain 完成第一版 RAG第二阶段才引入 LangChain目标是把一个完整的 RAG 流程跑起来文档加载、切片、向量化、存储、检索、拼 Prompt、生成全流程用 LCEL 串成一条链。代码很短核心大概长这样from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser prompt ChatPromptTemplate.from_template(基于以下内容回答问题\n{context}\n问题{question}) llm ChatOpenAI(modelgpt-4o-mini) chain prompt | llm | StrOutputParser()为什么要先走一遍 RAG因为 RAG 覆盖了 LangChain 绝大部分核心组件而且流程线性非常适合建立对生态的直觉。我当时从零写 PDF 问答机器人踩完分块大小、向量库选型、召回阈值调整的坑之后才真正理解这些组件存在的意义。此阶段要熟练掌握ChatPromptTemplate、StrOutputParser、文档加载器、RecursiveCharacterTextSplitter、Chroma/FAISS、以及 LCEL 的管道操作符。另外提醒一点中文资料里 langchain 教程鱼龙混杂版本迭代太快很多博客代码已经跑不通了。我的建议是以官方文档为主第三方教程只用来理解思路跑不通时优先查官方 API 变更日志。4.3 阶段三用 LangGraph 重构复杂流程第三阶段是转折点。把第二阶段那个 RAG 链或者随便一个多步骤 Agent用 LangGraph 重写一遍。先定义 State再建图、加节点、连边跑通第一版有向无环的图。一个最简骨架from typing import TypedDict from langgraph.graph import StateGraph, END class State(TypedDict): query: str answer: str def retrieve(state: State) - dict: return {answer: f处理查询: {state[query]}} graph StateGraph(State) graph.add_node(retrieve, retrieve) graph.add_edge(retrieve, END) app graph.compile() result app.invoke({query: langchain是什么})跑通之后再做三件事逼自己深入第一加上循环让 Agent 能反复调用工具直到完成任务或达到最大轮数第二接入 Checkpointer体验断点续跑和时间旅行第三加一个 human-in-the-loop 节点模拟人工审核场景。做完这三件事LangGraph 的核心概念基本吃透了。剩下的是按需看官方示例多 Agent Supervisor、并行分支、动态建节点这些进阶模式。4.4 阶段四工程化与生产落地最后是大多数教程不讲、但生产必须面对的部分把图包装成可服务的 API 暴露给 FastAPI配置持久化存储从内存切到 PostgreSQL 或 SQLite用事件流接口做流式输出接入 LangSmith 做全链路追踪设计幂等的重试逻辑。这阶段我有一个强烈的工程建议别把业务逻辑塞进单个节点太多。节点的粒度应该是不可拆分的动作单位如果你发现一个节点里又查库又调模型又发通知说明图设计已经腐化了后期排查会痛不欲生。好的图设计每个节点只做一件事边函数只做路由决策。5. LangGraph 实操要点与踩坑实录5.1 状态设计的第一性原则LangGraph 里 State 怎么定义直接决定你的代码能长多大。我的经验就三条。第一State 里只放需要跨节点共享的数据局部变量放函数内部别什么都往 State 里塞。第二优先用 TypedDict 或 Pydantic 定义 State schema让 key 有约束Pydantic 版本还能做校验。第三能存引用就存引用比如数据库 id、消息 id别存对象全文。我踩过一个很实际的坑在 State 里保存了整个检索出来的文档列表结果每个节点执行完都要把几十 KB 内容序列化一遍慢得离谱。改成只保存 doc_id 列表需要时再查性能立刻回来一大截。这个教训让我养成了习惯——每次往 State 加字段前先问自己这个数据真的需要给别的节点用吗5.2 节点与边的常见误区节点函数签名是state - dict返回的字典会被合并进 State。这里有几个常见误区。第一忘记 State 合并是浅合并如果某个 key 需要追加式更新比如消息列表必须为它定义 reducer否则后一个节点会覆盖前一个节点的写入。第二想在节点内部用 Python 多线程并行跑多个独立任务这是典型的错误姿势应该拆成多个节点然后建平行边让图引擎自己调度这样还能获得断点恢复的能力。第三条件边函数返回值和节点名不一致运行时一脸懵这类问题其实不难排查报错栈会给出具体信息耐心看就行。5.3 排查经验速查表整理一张我实际用过的速查表按频率排序症状常见原因处理方式执行到一半报 RecursionLimit 超限循环缺少终止条件检查条件边返回值给最大轮数限制执行结果与预期不符State 里 key 被后续节点覆盖逐节点打印返回字典核对合并逻辑内存占用持续上涨State 中存了大量中间数据精简 State schema改存引用并发执行时数据错乱多个节点同时写同一个 key拆 key 或定义 reducer 合并规则断点续跑后状态丢失用了 MemorySaver重启即清空生产环境换 PostgreSQL/SQLite 持久化5.4 几个压箱底的小技巧最后分享几个文档里不会明说的点。调试时给图上加一个观察节点里面只写一句print(state)跑完删掉比开着日志四处找快很多。条件边函数里尽量只读需要的 key别做复杂计算或 IO因为它会被频繁调用容易成为性能瓶颈。LangGraph 的流式输出接口早期叫 stream_mode后来演进成事件流 API如果你在网上抄到旧代码报属性不存在多半是版本问题直接升级到新版再对照官方 demo。另外一个心态层面的建议LangGraph 的抽象层级比 LangChain 低所以前期你会觉得写得好麻烦。这时候别急着退缩。我当时也是先学 LangChain用顺手之后对 LangGraph 相当抗拒觉得是官方故意把简单的东西变复杂。直到接手一个必须带人工审核、超时重试、多路分支的业务系统用 LangGraph 把流程画成图那一刻我才意识到这种麻烦其实是自由。如果你的业务还停留在原型阶段LangChain 完全够用一旦想构建真正复杂的 Agent 系统越早把状态机的思维方式吃透后面省的时间就越多。学习路线的核心就一句话先学会造轮子LangChain 组件再学会画图纸LangGraph 编排别跳级。