LangGraph 总览

LangGraph 不是把流程图画得更花，而是把“带状态的多步骤 AI 任务”变成可以定义、执行、中断和恢复的图结构。如果 LangChain 更像把一条链接起来，LangGraph 更像在问：这条链什么时候该分叉、什么时候该回退、状态该记在哪里。

很多人第一次看到 LangGraph，会把它理解成“Agent 版工作流框架”。这个说法只对了一半。它确实能表达流程，但它真正有价值的地方，是让系统在保留工程约束的前提下，把一部分下一步决策交给状态和模型。

为什么只有 LangChain 还不够

当你的 AI 功能只是“检索一下，再回答一下”，普通链路就够了。LangGraph 通常出现在下面这些情况：

• 任务不是一步做完，而是要多轮推进。
• 中间结果会影响下一步走向。
• 你需要保留状态，允许中断、恢复或人工接管。
• 同一目标下，系统可能进入不同分支，而不是固定路线。

也就是说，LangGraph 解决的不是“能不能连起来”，而是“连起来之后怎么继续跑”。

它真正管理的是什么

LangGraph 的名字里有 Graph，但重点不在图，而在状态。

从工程角度看，它真正接住的是这三件事：

• State：当前任务已经知道什么、做到哪一步。
• Node：每一步对状态做什么处理。
• Edge：下一步往哪里走，什么时候结束，什么时候换分支。

如果没有状态设计，节点再多也只是把复杂逻辑拆碎；如果状态设计清楚，图本身反而可以很简单。

一个最小状态图长什么样

一个最小的 LangGraph 思路，大概会像这样：

接收任务
  -> 分析当前上下文
  -> 决定是直接回答、检索知识还是调用工具
  -> 根据执行结果更新状态
  -> 判断是否继续
  -> 结束

这和固定 Workflow 的差异在于：下一步不是预先写死的唯一节点，而是根据当前状态和结果决定的。你可以把它理解为“有约束的动态分支”，而不是“随便让模型乱跑”。

什么时候它值得上场

以 Way To Agent 当前知识库路线为例，现在之所以只把 LangGraph 作为后续阅读，而不是一上来就拿它做主角，是因为当前读者先要理解 Agent 为什么需要状态和动态决策。等这些边界站稳之后，再看 LangGraph 会更容易判断它到底解决了什么。

真正值得引入 LangGraph 的场景，通常有这些特征：

• 你已经明确存在多步骤任务，而不是想象中可能会有。
• 你需要把状态作为一等对象管理。
• 你需要条件分支、中断恢复或人工接管。
• 你不满足于“把几个节点串起来”，而是要管理任务推进过程。

如果这些特征都还没出现，先用普通链路或简单 Workflow 往往更稳。

最容易画复杂的地方

LangGraph 很容易被用坏。最常见的问题不是不会用，而是太早把图画复杂：

• 节点拆得过细，结果没人看得懂状态是怎么变的。
• 分支太多，最后排查时只剩“可能是某条边出了问题”。
• 把本该由后端确定的业务规则交给图里的节点临场判断。
• 还没确认任务真需要动态决策，就先上图结构。

图不是价值本身。能把状态、分支和停止条件说明白，才是价值。

什么时候后面有必要换

当前只需要把 LangGraph 当成一个例子，理解“为什么在有状态、多步骤、动态分支的场景里，会需要这样一层框架”。等后面你真的遇到下面这些问题，再考虑是否要进一步深入它、替换掉更简单的实现：

• 现有链路已经开始堆满条件判断和临时状态。
• 单纯靠函数调用顺序已经很难描述任务推进。
• 你需要明确的恢复点、人工介入点和状态持久化。
• 你想评估每一步决策，而不是只看最终答案。

这时再回头看 LangGraph，你会更清楚它是在替你接住复杂度，而不是单纯增加一个新名词。

一句话先记住

LangGraph 的重点不是图，而是让多步骤 Agent 的状态和分支有了清晰的工程落点。

继续阅读

• 06-agent/001-what-is-agent.md：如果 Agent 与 Workflow 的边界还没站稳，先回去把定义读清楚。
• 06-agent/002-function-calling.md：再看图里的节点怎样真正落到工具调用契约。
• 09-ai-agent-engineering/001-ai-engineering-overview.md：最后看一个多步骤 Agent 为什么必须补齐日志、成本、评估和安全。