1. 从两个名字说起为什么总有人把 LangChain 和 LangGraph 搞混刚接触大模型应用开发那阵子我也被这两个名字绕进去过。项目里同事说“用 LangChain 搭个链路”转头另一个同事又说“这个场景得上 LangGraph”听起来像是同一套东西的两个版本实际上它们解决的是完全不同层面的问题。LangChain 是一套用于构建大模型应用的基础组件库LangGraph 则是构建有状态、可循环、多角色协作智能体流程的编排框架。一个偏“零件和胶水”一个偏“流程和状态机”。你把它们理解成“乐高积木”和“用积木搭出来的可循环运转的流水线”基本就抓住核心了。这篇文章想解决的问题很具体帮你搞清楚这两个东西各自是什么、边界在哪、什么时候该用哪个、以及从零到能上手做 Agent 应用的学习路线怎么排。适合三类人看——刚入门大模型应用开发、被各种框架名词绕晕的新手已经用过 LangChain 但遇到多轮循环、状态管理就卡壳的中级开发者还有在选型阶段纠结“到底要不要上 LangGraph”的技术负责人。我会把选型逻辑、核心概念、实操步骤、踩坑经验都摊开讲尽量让你看完就能动手。先说结论性的判断后面再展开如果你的需求是单轮或简单多轮的“输入-处理-输出”链路LangChain 足够一旦涉及循环、条件分支、多智能体协作、需要跨步骤记住状态LangGraph 才是正解。两者不是替代关系LangGraph 底层大量复用了 LangChain 的组件它们是叠加使用的关系。很多人误以为“学了 LangGraph 就不用学 LangChain”这是典型的认知误区后面我会专门拆解。2. 核心概念拆解LangChain 到底在解决什么问题2.1 LangChain 的本质是一套“标准化接口 可组合组件”大模型本身只是一个“文本进、文本出”的黑盒。你要做一个真实可用的应用中间必然要接提示词模板、外部知识检索、工具调用、输出解析、记忆管理。LangChain 的价值就在于它把这些环节都抽象成了统一的接口让你可以像搭积木一样拼起来。我举个最直观的例子。没有 LangChain 的时候你调用一次模型并解析结构化输出代码大概是这样手动拼 prompt 字符串、手动发请求、手动用正则或 json.loads 解析返回、手动处理异常。每一步都要自己写换个模型还得改一遍。有了 LangChain这些变成PromptTemplate、ChatModel、OutputParser几个对象链式组合即可换模型只改一行初始化。它的核心组件大致分这几类我按实际使用频率排Model I/O统一各家模型的调用方式Chat 模型、补全模型、Embedding 模型都归这里。Prompts提示词模板支持变量注入、少样本示例、消息角色区分。Chains把多个组件串成一条执行链最经典的就是LLMChain。Retrieval文档加载、切分、向量化、检索RAG 应用的地基。Memory对话历史管理让模型“记得”之前说过什么。Agents让模型自己决定调用哪个工具是早期 Agent 的实现方式。Tools把外部函数、API 包装成模型可调用的工具。2.2 LangChain 的“链式思维”及其天花板LangChain 最核心的思维模型是DAG有向无环图式的链。你定义好 A 到 B 到 C 的顺序数据顺着流下去跑完就结束。这种模式对绝大多数场景够用问答、摘要、翻译、简单的 RAG、单轮工具调用都能覆盖。但问题也恰恰出在“无环”这两个字上。真实的智能体场景经常需要循环模型调用工具拿到结果后发现不够再调用一次或者根据中间结果决定走哪条分支或者多个角色来回讨论几轮才得出结论。这些在纯 LangChain 的 Chain 体系里表达起来非常别扭早期大家用AgentExecutor硬凑但它的循环逻辑是黑盒的你很难精细控制“什么时候停、走哪条路、状态怎么存”。我自己踩过的坑做一个需要“检索-判断-再检索”的问答机器人用 LangChain 的 Agent 写出来调试时完全不知道它内部循环了几次、每次为什么做那个决策日志一团乱。这就是 LangChain 在复杂流程编排上的天花板——它擅长线性组合不擅长带状态的循环图。2.3 LangGraph 的本质是把流程显式建模成“状态图”LangGraph 的思路完全不同。它让你把整个应用显式地画成一张图节点Node是执行单元边Edge是流转方向状态State在节点之间传递和累积。最关键的是它天然支持环——你可以从节点 A 走到 B再从 B 回到 A直到某个条件满足才退出。这个模型和现实中的智能体工作方式高度吻合。一个 ReAct 风格的 Agent本质就是“思考-行动-观察”的循环想一步、调个工具、看结果、再想。用 LangGraph 表达就是三个节点加一条回边清清楚楚。而且因为状态是显式定义的你随时能打印出“当前处于哪一步、状态里有什么”调试体验比黑盒 Agent 好太多。我用一个生活类比帮你记住区别LangChain 像一条传送带原料从一头进成品从另一头出中间工序固定LangGraph 像一张地铁线路图有换乘、有环线、有根据情况选择不同路径的岔口而且每一站都记录着乘客状态的信息。传送带能干的活线路图都能干但线路图能干的复杂调度传送带干不了。3. 关键差异对照一张表看清选型边界光讲概念容易飘我直接上一张对照表把两个框架在几个关键维度上的差异列清楚。这张表是我自己在做技术选型时反复参考的建议你收藏。对比维度LangChainLangGraph核心抽象Chain链、组件Graph图、State状态流程结构以 DAG 为主线性或分支支持环、条件跳转、动态路由状态管理Memory 组件偏对话历史显式 State跨节点累积与更新循环支持弱靠 AgentExecutor 黑盒实现原生支持循环逻辑完全可控多智能体协作支持有限需自行拼装原生支持多节点多角色天然适配调试体验链路长时较难追踪状态可打印每步可观测学习曲线平缓组件多但概念简单稍陡需理解图与状态机思维典型场景RAG、问答、摘要、单轮工具调用复杂 Agent、多轮决策、多角色协作与对方关系提供底层组件复用 LangChain 组件做编排从表里能看出一个关键点LangGraph 不是 LangChain 的升级版而是它的补充层。LangGraph 里的节点内部你照样可以用 LangChain 的 PromptTemplate、ChatModel、Retriever。所以正确的学习顺序是先 LangChain 打底再 LangGraph 进阶而不是二选一。再补充一个容易被忽略的差异可控性。LangChain 的 Agent 在循环时你很难插入“人工审核”这种环节而 LangGraph 可以在任意节点前中断等人工确认后再继续这在需要审批的业务流里非常关键。我做过一个合同审核的 Agent就是靠 LangGraph 的断点能力在“生成审核意见”节点前暂停让人工过一眼再放行。4. 学习路线怎么排从零到能独立做 Agent 应用4.1 第一阶段Python 与异步基础约 1-2 周别跳过这步。LangChain 和 LangGraph 都是 Python 生态的产物而且大量用到异步、装饰器、类型注解。如果你 Python 只会写脚本遇到async/await、TypedDict、装饰器tool会一脸懵。这个阶段的目标很明确能读懂带类型注解的类、能写简单的异步函数、理解字典和列表推导。不需要学到多深够用就行。我建议直接拿 LangChain 的官方示例代码当阅读材料边读边查不懂的语法比啃语法书效率高得多。4.2 第二阶段LangChain 核心组件实操约 2-3 周这个阶段不要贪多按“模型调用 → 提示词模板 → 输出解析 → 链 → 检索 → 记忆”的顺序逐个击破。每个组件都动手写一个最小可运行示例别只看文档。我给你一个实操清单照着做一遍基本就通了用 ChatModel 调一次模型打印返回对象的结构看清楚content、usage这些字段。写一个 PromptTemplate注入变量观察最终拼出的 prompt 长什么样。接一个 OutputParser把模型输出解析成结构化数据故意喂个格式错误看它怎么报错。把上面三步串成一条 Chain跑通。加载一个本地文档切分、向量化、检索做一个最小 RAG。加 Memory做多轮对话观察历史是怎么被塞进 prompt 的。这个阶段的核心是建立“组件可组合”的直觉。等你看到任何需求脑子里能自动拆成“提示词模型解析检索”的组合就算过关了。4.3 第三阶段LangGraph 状态图思维约 2-3 周这是真正的分水岭。前两个阶段是“用工具”这个阶段是“设计流程”。我建议按下面的顺序推进先理解三个核心概念State状态、Node节点、Edge边。State 通常用一个 TypedDict 定义里面放所有需要在节点间传递的数据Node 是一个函数接收 State 返回 State 的更新Edge 决定下一个走哪个节点。然后动手实现一个最简单的循环图一个“计数器”节点每次给状态里的数字加一当数字小于 5 时回到自己等于 5 时结束。这个玩具例子能帮你彻底搞懂“环”是怎么转起来的。接着实现一个 ReAct Agent三个节点分别是“模型思考”“工具执行”“判断是否结束”用条件边控制循环。做完这个你就掌握了 LangGraph 最核心的用法。最后挑战多智能体定义两个角色节点一个“研究员”负责检索一个“写手”负责成文中间加一个“审核”节点决定是否打回重写。这个练完复杂 Agent 的编排你就有底了。4.4 第四阶段工程化与实战持续到这一步重点从“能跑”转向“跑得稳、跑得省、跑得可观测”。要关注的东西包括流式输出、错误重试、超时控制、Token 成本统计、LangSmith 之类的追踪工具、以及把应用部署成 API 服务。我个人的经验是工程化阶段踩的坑比学习阶段多得多。比如流式输出和结构化解析经常打架比如循环没设上限导致无限调用烧钱比如状态里塞了不可序列化的对象导致断点恢复失败。这些后面会专门讲。5. 实操演示用 LangGraph 搭一个带循环的检索问答 Agent光说路线不够我直接带你走一遍核心实现。这个例子是一个“检索-判断-再检索”的问答 Agent正好能体现 LangGraph 相对 LangChain 的优势。5.1 状态定义与节点设计先定义状态。这里我用 TypedDict把问题、检索到的文档、当前答案、循环次数都放进去from typing import TypedDict, List class AgentState(TypedDict): question: str documents: List[str] answer: str loop_count: int为什么要把loop_count放进状态因为循环必须有终止条件否则模型可能一直觉得“信息不够”而无限检索。这是新手最容易忽略的点我见过有人跑测试把额度烧光的。节点设计三个retrieve负责检索generate负责生成答案should_continue是一个条件判断函数决定是回到检索还是结束。5.2 条件边与循环控制条件边是 LangGraph 的灵魂。它的写法是给add_conditional_edges传一个判断函数函数返回下一个节点的名字def should_continue(state: AgentState) - str: if state[loop_count] 3: return end if 信息不足 in state[answer]: return retrieve return end这段逻辑的意思是最多循环 3 次如果模型说信息不足就再检索一轮否则结束。把终止条件写死在代码里而不是交给模型判断是控制成本和避免死循环的关键。模型可以建议“要不要再查”但最终拍板的是你的代码。5.3 组装图并运行组装部分就是把节点和边连起来from langgraph.graph import StateGraph, END graph StateGraph(AgentState) graph.add_node(retrieve, retrieve_node) graph.add_node(generate, generate_node) graph.set_entry_point(retrieve) graph.add_edge(retrieve, generate) graph.add_conditional_edges(generate, should_continue, { retrieve: retrieve, end: END }) app graph.compile()跑起来就是app.invoke({question: ..., loop_count: 0})。整个过程你能清楚地看到状态怎么流转、循环了几次、每次检索到了什么。这种透明度是 LangChain 黑盒 Agent 给不了的。5.4 参数选择与成本考量几个我实测下来比较稳的参数建议循环上限设 3 到 5 次再多基本是模型在无效打转检索返回的文档数控制在 3 到 5 篇太多会撑爆上下文还稀释相关性如果用了大模型做判断尽量换成小模型或规则判断能省不少钱。注意状态里不要放模型客户端、数据库连接这类不可序列化的对象。LangGraph 支持断点恢复靠的就是状态可序列化塞了这些东西断点功能直接失效。6. 常见问题与避坑经验实录6.1 高频问题速查表问题现象可能原因解决思路循环停不下来没有硬性终止条件在状态里加计数器代码层强制退出状态更新丢失节点返回的不是完整更新确认返回 dict 的键与 State 定义一致断点恢复失败状态含不可序列化对象只存基础类型外部资源用时再建流式输出乱序与结构化解析冲突流式阶段只输出文本解析放最后多智能体互相等待边没定义清楚明确每个节点的出口和条件Token 消耗异常高历史或文档全量塞入做截断、摘要或相关性过滤6.2 我踩过的三个真实坑第一个坑把 LangGraph 当 LangChain 用。刚开始我试图用 LangGraph 重写一个简单的单轮问答结果发现代码量比 LangChain 还多纯属杀鸡用牛刀。后来才明白简单链路就用 LangChain别为了用新框架而用新框架。选型要看流程复杂度不是看框架新不新。第二个坑状态设计太随意。我一开始把所有中间变量都往 State 里塞结果状态越来越臃肿节点之间耦合严重改一个字段牵动全身。后来学乖了State 只放真正需要跨节点传递的数据节点内部的临时变量就地消化不往外抛。第三个坑忽视可观测性。早期调试全靠 print循环一多就晕。后来接入了追踪工具每一步的输入输出、耗时、Token 消耗都可视化排查效率提升一大截。复杂 Agent 一定要配可观测工具这是刚需不是锦上添花。6.3 关于框架选型的额外建议市面上 Agent 框架不止这两个还有 Dify、CrewAI 等。我的判断逻辑是要低代码快速搭原型看 Dify 这类平台要做多角色协作且角色定义清晰CrewAI 上手快要做精细可控、带复杂状态和循环的生产级流程LangGraph 更合适。LangChain 则是所有这些的地基值得先打牢。别陷入“哪个框架最好”的争论它们解决的是不同层次的问题。真正重要的是你脑子里有没有“状态、节点、边、循环、终止条件”这套流程思维框架只是表达工具。7. 学习资源与进阶方向7.1 官方文档的正确打开方式官方文档永远是第一手资料但很多人读法不对。我的建议是不要从头读到尾而是带着具体问题去查。比如你想知道怎么做条件边直接搜conditional_edges看示例代码跑通再回头看概念解释。文档里的概念部分适合在你已经跑通示例后回头理解顺序反了会很痛苦。另外官方仓库的examples目录比文档还值钱里面全是可运行的完整项目。我学 LangGraph 多智能体那部分就是照着示例改出来的。7.2 从 Demo 到生产的进阶清单能跑通 Demo 和能上生产是两码事。如果你想让自己的 Agent 真正可用下面这些迟早要补流式输出用户体验的关键首字延迟能降一大截。错误处理与重试模型调用会失败工具会超时必须有兜底。成本控制Token 统计、缓存、小模型分流。可观测性追踪每一步出问题能定位。评测体系怎么判断你的 Agent 变好了还是变差了需要一套评测集。安全与权限工具调用的边界、敏感操作的审批。这些内容任何一个展开都能写一整篇我这里只点出来让你知道学习路线不止于“会用框架”。7.3 一个持续受益的习惯最后分享一个我坚持了很久的习惯每学一个新概念就用最小代码验证一遍并写下“它解决了什么问题、什么时候不该用它”。前者帮你理解后者帮你选型。很多人只记“怎么用”不记“什么时候不用”结果一到真实项目就选错工具。LangChain 和 LangGraph 的边界就是靠这种反复验证刻进脑子里的。这套路线我自己走过一遍也带过几个新人走基本两到三个月能从零到独立做中等复杂度的 Agent 应用。快慢因人而异但顺序别乱——先组件后编排先线性后循环先能跑后跑稳这个节奏踩对了少走很多弯路。 LangChain与LangGraph选型指南：从组件到状态图，构建复杂Agent应用
1. 从两个名字说起为什么总有人把 LangChain 和 LangGraph 搞混刚接触大模型应用开发那阵子我也被这两个名字绕进去过。项目里同事说“用 LangChain 搭个链路”转头另一个同事又说“这个场景得上 LangGraph”听起来像是同一套东西的两个版本实际上它们解决的是完全不同层面的问题。LangChain 是一套用于构建大模型应用的基础组件库LangGraph 则是构建有状态、可循环、多角色协作智能体流程的编排框架。一个偏“零件和胶水”一个偏“流程和状态机”。你把它们理解成“乐高积木”和“用积木搭出来的可循环运转的流水线”基本就抓住核心了。这篇文章想解决的问题很具体帮你搞清楚这两个东西各自是什么、边界在哪、什么时候该用哪个、以及从零到能上手做 Agent 应用的学习路线怎么排。适合三类人看——刚入门大模型应用开发、被各种框架名词绕晕的新手已经用过 LangChain 但遇到多轮循环、状态管理就卡壳的中级开发者还有在选型阶段纠结“到底要不要上 LangGraph”的技术负责人。我会把选型逻辑、核心概念、实操步骤、踩坑经验都摊开讲尽量让你看完就能动手。先说结论性的判断后面再展开如果你的需求是单轮或简单多轮的“输入-处理-输出”链路LangChain 足够一旦涉及循环、条件分支、多智能体协作、需要跨步骤记住状态LangGraph 才是正解。两者不是替代关系LangGraph 底层大量复用了 LangChain 的组件它们是叠加使用的关系。很多人误以为“学了 LangGraph 就不用学 LangChain”这是典型的认知误区后面我会专门拆解。2. 核心概念拆解LangChain 到底在解决什么问题2.1 LangChain 的本质是一套“标准化接口 可组合组件”大模型本身只是一个“文本进、文本出”的黑盒。你要做一个真实可用的应用中间必然要接提示词模板、外部知识检索、工具调用、输出解析、记忆管理。LangChain 的价值就在于它把这些环节都抽象成了统一的接口让你可以像搭积木一样拼起来。我举个最直观的例子。没有 LangChain 的时候你调用一次模型并解析结构化输出代码大概是这样手动拼 prompt 字符串、手动发请求、手动用正则或 json.loads 解析返回、手动处理异常。每一步都要自己写换个模型还得改一遍。有了 LangChain这些变成PromptTemplate、ChatModel、OutputParser几个对象链式组合即可换模型只改一行初始化。它的核心组件大致分这几类我按实际使用频率排Model I/O统一各家模型的调用方式Chat 模型、补全模型、Embedding 模型都归这里。Prompts提示词模板支持变量注入、少样本示例、消息角色区分。Chains把多个组件串成一条执行链最经典的就是LLMChain。Retrieval文档加载、切分、向量化、检索RAG 应用的地基。Memory对话历史管理让模型“记得”之前说过什么。Agents让模型自己决定调用哪个工具是早期 Agent 的实现方式。Tools把外部函数、API 包装成模型可调用的工具。2.2 LangChain 的“链式思维”及其天花板LangChain 最核心的思维模型是DAG有向无环图式的链。你定义好 A 到 B 到 C 的顺序数据顺着流下去跑完就结束。这种模式对绝大多数场景够用问答、摘要、翻译、简单的 RAG、单轮工具调用都能覆盖。但问题也恰恰出在“无环”这两个字上。真实的智能体场景经常需要循环模型调用工具拿到结果后发现不够再调用一次或者根据中间结果决定走哪条分支或者多个角色来回讨论几轮才得出结论。这些在纯 LangChain 的 Chain 体系里表达起来非常别扭早期大家用AgentExecutor硬凑但它的循环逻辑是黑盒的你很难精细控制“什么时候停、走哪条路、状态怎么存”。我自己踩过的坑做一个需要“检索-判断-再检索”的问答机器人用 LangChain 的 Agent 写出来调试时完全不知道它内部循环了几次、每次为什么做那个决策日志一团乱。这就是 LangChain 在复杂流程编排上的天花板——它擅长线性组合不擅长带状态的循环图。2.3 LangGraph 的本质是把流程显式建模成“状态图”LangGraph 的思路完全不同。它让你把整个应用显式地画成一张图节点Node是执行单元边Edge是流转方向状态State在节点之间传递和累积。最关键的是它天然支持环——你可以从节点 A 走到 B再从 B 回到 A直到某个条件满足才退出。这个模型和现实中的智能体工作方式高度吻合。一个 ReAct 风格的 Agent本质就是“思考-行动-观察”的循环想一步、调个工具、看结果、再想。用 LangGraph 表达就是三个节点加一条回边清清楚楚。而且因为状态是显式定义的你随时能打印出“当前处于哪一步、状态里有什么”调试体验比黑盒 Agent 好太多。我用一个生活类比帮你记住区别LangChain 像一条传送带原料从一头进成品从另一头出中间工序固定LangGraph 像一张地铁线路图有换乘、有环线、有根据情况选择不同路径的岔口而且每一站都记录着乘客状态的信息。传送带能干的活线路图都能干但线路图能干的复杂调度传送带干不了。3. 关键差异对照一张表看清选型边界光讲概念容易飘我直接上一张对照表把两个框架在几个关键维度上的差异列清楚。这张表是我自己在做技术选型时反复参考的建议你收藏。对比维度LangChainLangGraph核心抽象Chain链、组件Graph图、State状态流程结构以 DAG 为主线性或分支支持环、条件跳转、动态路由状态管理Memory 组件偏对话历史显式 State跨节点累积与更新循环支持弱靠 AgentExecutor 黑盒实现原生支持循环逻辑完全可控多智能体协作支持有限需自行拼装原生支持多节点多角色天然适配调试体验链路长时较难追踪状态可打印每步可观测学习曲线平缓组件多但概念简单稍陡需理解图与状态机思维典型场景RAG、问答、摘要、单轮工具调用复杂 Agent、多轮决策、多角色协作与对方关系提供底层组件复用 LangChain 组件做编排从表里能看出一个关键点LangGraph 不是 LangChain 的升级版而是它的补充层。LangGraph 里的节点内部你照样可以用 LangChain 的 PromptTemplate、ChatModel、Retriever。所以正确的学习顺序是先 LangChain 打底再 LangGraph 进阶而不是二选一。再补充一个容易被忽略的差异可控性。LangChain 的 Agent 在循环时你很难插入“人工审核”这种环节而 LangGraph 可以在任意节点前中断等人工确认后再继续这在需要审批的业务流里非常关键。我做过一个合同审核的 Agent就是靠 LangGraph 的断点能力在“生成审核意见”节点前暂停让人工过一眼再放行。4. 学习路线怎么排从零到能独立做 Agent 应用4.1 第一阶段Python 与异步基础约 1-2 周别跳过这步。LangChain 和 LangGraph 都是 Python 生态的产物而且大量用到异步、装饰器、类型注解。如果你 Python 只会写脚本遇到async/await、TypedDict、装饰器tool会一脸懵。这个阶段的目标很明确能读懂带类型注解的类、能写简单的异步函数、理解字典和列表推导。不需要学到多深够用就行。我建议直接拿 LangChain 的官方示例代码当阅读材料边读边查不懂的语法比啃语法书效率高得多。4.2 第二阶段LangChain 核心组件实操约 2-3 周这个阶段不要贪多按“模型调用 → 提示词模板 → 输出解析 → 链 → 检索 → 记忆”的顺序逐个击破。每个组件都动手写一个最小可运行示例别只看文档。我给你一个实操清单照着做一遍基本就通了用 ChatModel 调一次模型打印返回对象的结构看清楚content、usage这些字段。写一个 PromptTemplate注入变量观察最终拼出的 prompt 长什么样。接一个 OutputParser把模型输出解析成结构化数据故意喂个格式错误看它怎么报错。把上面三步串成一条 Chain跑通。加载一个本地文档切分、向量化、检索做一个最小 RAG。加 Memory做多轮对话观察历史是怎么被塞进 prompt 的。这个阶段的核心是建立“组件可组合”的直觉。等你看到任何需求脑子里能自动拆成“提示词模型解析检索”的组合就算过关了。4.3 第三阶段LangGraph 状态图思维约 2-3 周这是真正的分水岭。前两个阶段是“用工具”这个阶段是“设计流程”。我建议按下面的顺序推进先理解三个核心概念State状态、Node节点、Edge边。State 通常用一个 TypedDict 定义里面放所有需要在节点间传递的数据Node 是一个函数接收 State 返回 State 的更新Edge 决定下一个走哪个节点。然后动手实现一个最简单的循环图一个“计数器”节点每次给状态里的数字加一当数字小于 5 时回到自己等于 5 时结束。这个玩具例子能帮你彻底搞懂“环”是怎么转起来的。接着实现一个 ReAct Agent三个节点分别是“模型思考”“工具执行”“判断是否结束”用条件边控制循环。做完这个你就掌握了 LangGraph 最核心的用法。最后挑战多智能体定义两个角色节点一个“研究员”负责检索一个“写手”负责成文中间加一个“审核”节点决定是否打回重写。这个练完复杂 Agent 的编排你就有底了。4.4 第四阶段工程化与实战持续到这一步重点从“能跑”转向“跑得稳、跑得省、跑得可观测”。要关注的东西包括流式输出、错误重试、超时控制、Token 成本统计、LangSmith 之类的追踪工具、以及把应用部署成 API 服务。我个人的经验是工程化阶段踩的坑比学习阶段多得多。比如流式输出和结构化解析经常打架比如循环没设上限导致无限调用烧钱比如状态里塞了不可序列化的对象导致断点恢复失败。这些后面会专门讲。5. 实操演示用 LangGraph 搭一个带循环的检索问答 Agent光说路线不够我直接带你走一遍核心实现。这个例子是一个“检索-判断-再检索”的问答 Agent正好能体现 LangGraph 相对 LangChain 的优势。5.1 状态定义与节点设计先定义状态。这里我用 TypedDict把问题、检索到的文档、当前答案、循环次数都放进去from typing import TypedDict, List class AgentState(TypedDict): question: str documents: List[str] answer: str loop_count: int为什么要把loop_count放进状态因为循环必须有终止条件否则模型可能一直觉得“信息不够”而无限检索。这是新手最容易忽略的点我见过有人跑测试把额度烧光的。节点设计三个retrieve负责检索generate负责生成答案should_continue是一个条件判断函数决定是回到检索还是结束。5.2 条件边与循环控制条件边是 LangGraph 的灵魂。它的写法是给add_conditional_edges传一个判断函数函数返回下一个节点的名字def should_continue(state: AgentState) - str: if state[loop_count] 3: return end if 信息不足 in state[answer]: return retrieve return end这段逻辑的意思是最多循环 3 次如果模型说信息不足就再检索一轮否则结束。把终止条件写死在代码里而不是交给模型判断是控制成本和避免死循环的关键。模型可以建议“要不要再查”但最终拍板的是你的代码。5.3 组装图并运行组装部分就是把节点和边连起来from langgraph.graph import StateGraph, END graph StateGraph(AgentState) graph.add_node(retrieve, retrieve_node) graph.add_node(generate, generate_node) graph.set_entry_point(retrieve) graph.add_edge(retrieve, generate) graph.add_conditional_edges(generate, should_continue, { retrieve: retrieve, end: END }) app graph.compile()跑起来就是app.invoke({question: ..., loop_count: 0})。整个过程你能清楚地看到状态怎么流转、循环了几次、每次检索到了什么。这种透明度是 LangChain 黑盒 Agent 给不了的。5.4 参数选择与成本考量几个我实测下来比较稳的参数建议循环上限设 3 到 5 次再多基本是模型在无效打转检索返回的文档数控制在 3 到 5 篇太多会撑爆上下文还稀释相关性如果用了大模型做判断尽量换成小模型或规则判断能省不少钱。注意状态里不要放模型客户端、数据库连接这类不可序列化的对象。LangGraph 支持断点恢复靠的就是状态可序列化塞了这些东西断点功能直接失效。6. 常见问题与避坑经验实录6.1 高频问题速查表问题现象可能原因解决思路循环停不下来没有硬性终止条件在状态里加计数器代码层强制退出状态更新丢失节点返回的不是完整更新确认返回 dict 的键与 State 定义一致断点恢复失败状态含不可序列化对象只存基础类型外部资源用时再建流式输出乱序与结构化解析冲突流式阶段只输出文本解析放最后多智能体互相等待边没定义清楚明确每个节点的出口和条件Token 消耗异常高历史或文档全量塞入做截断、摘要或相关性过滤6.2 我踩过的三个真实坑第一个坑把 LangGraph 当 LangChain 用。刚开始我试图用 LangGraph 重写一个简单的单轮问答结果发现代码量比 LangChain 还多纯属杀鸡用牛刀。后来才明白简单链路就用 LangChain别为了用新框架而用新框架。选型要看流程复杂度不是看框架新不新。第二个坑状态设计太随意。我一开始把所有中间变量都往 State 里塞结果状态越来越臃肿节点之间耦合严重改一个字段牵动全身。后来学乖了State 只放真正需要跨节点传递的数据节点内部的临时变量就地消化不往外抛。第三个坑忽视可观测性。早期调试全靠 print循环一多就晕。后来接入了追踪工具每一步的输入输出、耗时、Token 消耗都可视化排查效率提升一大截。复杂 Agent 一定要配可观测工具这是刚需不是锦上添花。6.3 关于框架选型的额外建议市面上 Agent 框架不止这两个还有 Dify、CrewAI 等。我的判断逻辑是要低代码快速搭原型看 Dify 这类平台要做多角色协作且角色定义清晰CrewAI 上手快要做精细可控、带复杂状态和循环的生产级流程LangGraph 更合适。LangChain 则是所有这些的地基值得先打牢。别陷入“哪个框架最好”的争论它们解决的是不同层次的问题。真正重要的是你脑子里有没有“状态、节点、边、循环、终止条件”这套流程思维框架只是表达工具。7. 学习资源与进阶方向7.1 官方文档的正确打开方式官方文档永远是第一手资料但很多人读法不对。我的建议是不要从头读到尾而是带着具体问题去查。比如你想知道怎么做条件边直接搜conditional_edges看示例代码跑通再回头看概念解释。文档里的概念部分适合在你已经跑通示例后回头理解顺序反了会很痛苦。另外官方仓库的examples目录比文档还值钱里面全是可运行的完整项目。我学 LangGraph 多智能体那部分就是照着示例改出来的。7.2 从 Demo 到生产的进阶清单能跑通 Demo 和能上生产是两码事。如果你想让自己的 Agent 真正可用下面这些迟早要补流式输出用户体验的关键首字延迟能降一大截。错误处理与重试模型调用会失败工具会超时必须有兜底。成本控制Token 统计、缓存、小模型分流。可观测性追踪每一步出问题能定位。评测体系怎么判断你的 Agent 变好了还是变差了需要一套评测集。安全与权限工具调用的边界、敏感操作的审批。这些内容任何一个展开都能写一整篇我这里只点出来让你知道学习路线不止于“会用框架”。7.3 一个持续受益的习惯最后分享一个我坚持了很久的习惯每学一个新概念就用最小代码验证一遍并写下“它解决了什么问题、什么时候不该用它”。前者帮你理解后者帮你选型。很多人只记“怎么用”不记“什么时候不用”结果一到真实项目就选错工具。LangChain 和 LangGraph 的边界就是靠这种反复验证刻进脑子里的。这套路线我自己走过一遍也带过几个新人走基本两到三个月能从零到独立做中等复杂度的 Agent 应用。快慢因人而异但顺序别乱——先组件后编排先线性后循环先能跑后跑稳这个节奏踩对了少走很多弯路。