LangGraph 是什么？为什么 Agent 一复杂，很多人就从 LangChain 走向了它

LangGraph 是什么为什么 Agent 一复杂很多人就从 LangChain 走向了它昨天我们先把 LangChain 放回了它该在的位置它不是让模型更聪明而是在帮你把模型、工具、上下文和执行流程组织成一个系统。但问题也正是在这里开始出现的。因为当 Agent 不再只是线性执行几步而是开始带状态、会分支、能回流、需要反复判断时单纯“链式理解”就不太够了。这时候很多人就会继续遇到另一个名字LangGraph。前一篇我们讲了 LangChain。核心结论其实很简单它擅长把一条调用链组织起来。这对于很多 LLM 应用已经很有价值。比如调一次模型生成内容把输出交给下一步处理接一个搜索或数据库工具把多步流程串起来如果任务结构相对清楚、步骤顺序也比较稳定这种链式组织方式很自然。但问题是真正的 Agent 往往不会一直这么“线性”。它常常会出现这些情况走到某一步要先判断再决定下一步某个工具失败了要不要重试某个结果不合格要不要回去重做不同状态下要走不同分支整个系统需要记住当前进行到哪这时候你就会发现Agent 真正难的地方不只是把步骤连起来而是把状态、分支和回流也组织起来。这也是 LangGraph 出现的背景。一、先说结论LangGraph 不是在替代 LangChain而是在处理更复杂的执行结构很多人第一次看到 LangGraph会以为它是“另一个框架”甚至会问那是不是学了 LangGraph就不用看 LangChain 了这种理解不太准确。更合理的看法是LangGraph 不是在否定 LangChain而是在补足链式结构不够表达的那一部分。前面讲 LangChain 时我们强调的是“链”。链很适合表达这种结构先做 A再做 B再做 C但一旦任务变成先做 A根据 A 的结果决定去 B 还是去 C如果 B 失败回到 A 或换路径如果结果没过检查再回到上一步你就会发现线性链路已经不够自然了。这时更适合的思路不再是“一条链”而是一个由节点、状态和边组成的执行图。这就是 LangGraph 想解决的问题。二、为什么很多 Agent 一复杂就要从“链”走向“图”因为 Agent 和很多普通流程最大的区别在于它不是只执行固定顺序而是会在过程中不断判断、转向、重试和更新状态。比如一个更真实的 Agent 流程可能会这样先理解任务形成初步计划调工具拿信息检查信息够不够不够就继续查够了再产出结果结果不合格就回去重做某一步你会发现这种结构里最重要的已经不是“第几步”而是当前处于什么状态下一步该往哪里走哪些情况要回退哪些情况要终止这就是“图”比“链”更适合的地方。链更像一条路。图更像一个路网。当你的系统需要的不只是往前走而是要在不同路径之间切换时图的表达能力就会更强。三、LangGraph 最适合理解成什么如果用一句尽量不绕的话来解释我会建议你把 LangGraph 理解成一个用图结构来组织 Agent 执行过程的框架。这里有三个关键词。1. 节点你可以把一个节点理解成系统里的某个动作或处理单元。比如分析任务生成计划调用搜索检查结果输出答案2. 边边代表节点之间怎么连接也就是从这一步之后系统可以走向哪一步。它可以是固定连接也可以是带条件的连接。3. 状态这是最关键的一层。因为很多 Agent 的核心不只是“做了什么”而是“当前知道了什么、确认了什么、还缺什么”。状态决定了系统接下来应该往哪走。所以如果说 LangChain 更容易让人想到“把步骤串起来”那 LangGraph 更强调的是把执行路径和状态流转一起组织起来。四、LangGraph 为什么特别适合 Agent因为 Agent 本身就天然带有几类图结构特征。1. 它经常需要条件分支不是所有任务都会走一样的路径。例如信息足够就直接生成结果信息不够就继续搜索工具失败就改走备用路径如果没有分支能力系统就很容易被写成一堆硬编码判断后面越来越乱。2. 它经常需要回流和重试真实任务不会永远一次成功。一个结果没过检查常常要回到前一步重做。一个工具失败也可能要重试或换工具。这种“往回走”的能力本来就是很多 Agent 稳定性的关键。3. 它经常依赖中间状态前面做过什么、确认了什么、还缺哪些信息这些都会影响下一步。所以 Agent 不是只靠当前输入做决定而是要靠持续演进的状态做决定。4. 它更适合做长期可维护的流程设计当系统逐渐变复杂时很多问题不是“能不能跑”而是能不能看懂能不能改出问题时能不能定位图结构在这里的价值不只是更强大也更容易把系统结构显性化。五、它和 LangChain 的关系最容易误解在哪里最容易误解的一点是把它们理解成互斥关系。好像用了 LangGraph就不需要 LangChain或者学 LangChain 就等于没必要再看 LangGraph。其实更现实的理解是LangChain 更像通用的组件和编排基础LangGraph 更像在更复杂 Agent 场景下提供状态化图式执行能力换句话说LangGraph 解决的是更靠近“Agent 运行机制”的那一层问题。所以它们不是简单替代关系而更像是复杂度提升后的自然延伸。如果你昨天那篇已经理解了 LangChain 在做“搭骨架”的事那今天这篇可以把 LangGraph 理解成当骨架开始不再只是直线而变成带分支和回流的结构时需要更适合的组织方式。六、为什么很多人会说LangGraph 更像真正的 Agent 框架这句话有一定道理但也容易被说得太绝对。大家会有这种感受主要是因为它更贴近 Agent 的几个核心特征有状态有分支有循环有回流有更明确的运行路径这些东西在更高级的 Agent 系统里非常常见。所以很多人会觉得到了这一步系统终于不只是“把几次调用串起来”而是开始更像一个真正会运行的执行体。但这并不意味着它就天然更高级、更万能。框架再合适也只是表达结构的工具。真正决定系统好不好用的仍然是任务设计得对不对状态定义得清不清楚分支条件合不合理检查和回退机制有没有做好也就是说LangGraph 更像真正 Agent 框架不是因为名字更酷而是因为它更适合表达 Agent 的运行结构。七、什么情况下你才真的需要 LangGraph不是所有项目一上来都需要它。如果你现在做的是这种场景单轮问答简单内容生成线性流程处理一两步工具调用那用更简单的方式往往就够了。但如果你开始遇到下面这些问题LangGraph 的价值就会明显上来1. 流程不再是线性的只要你开始有多个分支路径就已经不再适合只用单条链去硬扛。2. 系统要根据中间结果动态转向不是预先写死每一步而是要根据执行中的状态判断下一步去哪。3. 任务里有明显的回流机制结果不合格要回退、工具失败要重试、信息不足要继续补这些都更适合图结构表达。4. 你开始在意系统的可观察、可调试、可维护图结构的一个重要好处是更容易把系统路径显性化。这对排查问题、解释失败、优化流程都很重要。八、如果只记住一句话应该记住什么如果今天你只想记住一句最关键的话我会建议你记这个LangChain 更适合把步骤串起来LangGraph 更适合把带状态、可分支、可回流的 Agent 运行过程组织起来。这就是它们最核心的区别。也是为什么很多人会从 LangChain 自然走到 LangGraph。不是因为前者错了而是因为系统复杂度变了。一旦复杂度变了组织方式也必须跟着升级。九、怎么学 LangGraph才不会一上来又学乱一个更稳的学习顺序是第一步先别急着看 API先看它在解决什么结构问题你先问自己我的任务有没有状态有没有分支有没有回流有没有中间检查和重试如果这些问题开始出现你就能明白它为什么存在。第二步把它和前面讲过的 Agent 能力连起来前面讲过的规划、记忆、评估、调试其实都和 LangGraph 很相关。因为图结构不是为了“画得好看”而是为了更清楚地承载这些能力规划决定可能路径记忆和状态决定当前处境检查决定是否回流调试决定你能不能看懂系统卡在哪第三步把它理解为一种更适合复杂 Agent 的工程表达方式不要把它学成一个新的名词集合。真正重要的是理解为什么当 Agent 从线性流程走向状态化执行时图结构会变得更自然。如果说昨天那篇是在回答怎么把 Agent 的调用链搭起来。那今天这篇就在回答当 Agent 不再只是直线往前跑而是开始分支、回流、带状态运行时应该怎么把它组织起来。这也是 LangGraph 最值得理解的地方。后面如果继续往下讲再往下一步就可以自然进入另一个问题当 Agent 不只是一个执行体而开始变成多个角色协作时为什么大家又会继续看到 AutoGen 和 CrewAI因为那时候问题就不再只是“单个 Agent 怎么跑”而是“多个 Agent 怎么配合”。 完整学习路径GitHub 搜索agent-learning-path