LangGraph 与多步骤流程

要点

  • 前面几篇我们一直在讲单 Agent
  • 很多人第一次看到 LangGraph，会下意识把它理解成「Agent 的进阶版本」
  • 假设我们把刚才那条消息拆得更细一些，系统内部可以是下面这条流程
  • 新手第一次接触 LangGraph，最容易觉得抽象的词通常是 state
  • Node 就是流程里的一个步骤

内容

1. 先从一个会变长的流程开始

前面几篇我们一直在讲单 Agent。单 Agent 最适合处理的是一轮请求里能收束的问题：收到输入，决定要不要查工具，拿到结果，生成回复。

但真实项目继续往后做，流程很快就会变长。

还是用「AI 电子伴侣」的场景。假设用户发来一条消息：

NOTE

我昨天和妈妈吵架了，心情很差。你帮我看看明天下午有没有空，我想去医院做个检查。

这条消息已经不是简单的聊天了。系统内部很可能要经过下面几步：

  1. 先判断有没有安全风险
  2. 再判断用户现在的情绪状态
  3. 判断这条消息里有没有日程或提醒需求
  4. 如果有，就去查日历
  5. 再决定最后是安抚用户、给出建议，还是继续追问

如果把这些步骤都塞进一个 Agent 的 Prompt 里，当然也能写。但流程开始变长后，真正难的地方已经不是「模型能不能回答」，而是：

  • 这一步之后应该去哪里
  • 中间结果要不要保留
  • 某一步失败后从哪继续
  • 哪些步骤必须执行，哪些步骤可以跳过

这时候开始接手的，就不是 LangChain 的单 Agent 封装，而是 LangGraph 的工作流和运行时能力。

2. LangGraph 先解决的不是模型，而是流程

很多人第一次看到 LangGraph，会下意识把它理解成「Agent 的进阶版本」。这个理解不算全错，但不够准确。

更准确的说法是：

LangGraph 先解决的是流程编排问题，然后才是多 Agent 问题。

在刚才那条消息里，系统要不要先做安全检查，要不要做情绪分析，要不要走日历查询，这些都属于流程问题。

如果只靠一个普通函数把所有步骤串起来，代码大概会慢慢变成这样：

  • 先写一个 if
  • 再接一个 if
  • 中间再塞一个工具调用
  • 如果失败就再加一个分支

一开始还行，步骤一多，代码会越来越像一条绕来绕去的线。

LangGraph 做的事，就是把这种「绕来绕去的线」整理成一个明确的图结构。每个步骤是一个节点，步骤之间怎么走，是边。

所以从职责上看，LangGraph 更像是在做下面这些事：

  • 组织流程
  • 保存状态
  • 处理分支
  • 处理回跳
  • 让多个节点稳定协作

3. 用一个日程请求看 LangGraph 的作用

假设我们把刚才那条消息拆得更细一些，系统内部可以是下面这条流程：

  1. safety_check：看这条消息是否需要特殊处理
  2. emotion_check：判断当前情绪状态
  3. intent_router：判断是不是日程相关请求
  4. calendar_lookup：去外部系统查时间
  5. reply_generator：生成最终回复

如果用图来画，大致像这样：

Drawing canvas 图里最重要的不是节点名字，而是这几个事实：

  • 请求不是一步完成的
  • 有些步骤是固定会走的
  • 有些步骤只有满足条件才会走
  • 中间会不断产生新信息
  • 最后才汇总成回复

这就是 LangGraph 的典型使用场景。

它处理的不是「模型怎么生成一句话」，而是「一整条流程怎样稳定往前走」。

4. LangGraph 里的 State 到底在解决什么

新手第一次接触 LangGraph，最容易觉得抽象的词通常是 state。

其实把它放回业务场景里就很容易理解。

在刚才那条请求里，系统跑到一半时，内部已经有很多信息了：

  • 用户原始输入
  • 安全检查结果
  • 情绪判断结果
  • 路由判断结果
  • 日历查询结果

这些信息如果只是散落在几个局部变量里，一旦流程复杂起来，很快就会乱。你会开始搞不清：

  • 哪个结果是上一阶段产出的
  • 哪个字段还有效
  • 下一步到底能读哪些数据

LangGraph 的 state 做的，就是把这些中间信息收拢成一份明确的数据对象，让后面的节点继续往下读。

可以把它理解成：

  • 每个节点都在读同一份状态
  • 每个节点执行完以后，会补充或修改这份状态
  • 下一步节点看到的是更新后的结果

这样流程走到哪一步，都不会丢上下文。

在 AI 伴侣场景里，这一点很重要。因为很多请求不是简单的一问一答，而是会一步步累积信息：

  • 先知道用户心情差
  • 再知道他想预约检查
  • 再知道明天下午有空位
  • 最后才能生成一段既带安抚又带安排建议的回复

如果没有统一状态，这些信息很难顺畅地在各步骤之间流动。

5. Node 和 Edge

Node 就是流程里的一个步骤。

比如：

  • 做安全检查
  • 做情绪识别
  • 查日历
  • 生成回复

每个步骤都只做一件相对明确的事。

Edge 就是这一步做完以后，下一步该去哪里。

比如：

  • 安全检查通过后，去情绪识别
  • 如果判断出有日程需求，去查日历
  • 如果没有日程需求，直接生成回复

你会发现，node 和 edge 其实不是为了把事情说复杂，而是为了把原本代码里隐含的流程显式写出来。

一旦显式写出来，后面很多事情都会简单很多：

  • 哪一步出了问题更容易定位
  • 新加一个步骤更容易插进去
  • 条件分支会更清楚

这也是为什么 LangGraph 更适合承接复杂流程。因为流程一旦复杂，最怕的不是功能少，而是路线不清楚。

6. 多 Agent 只是 LangGraph 的一种常见形态

前一篇讲过，多 Agent 的重点是分工。

到了 LangGraph 这一层，这种分工终于有了更自然的落地方式。因为现在系统里已经不只是一个大 Agent，而是一张流程图。图里的某些节点，完全可以换成不同的 Agent。

还是 AI 伴侣这个场景，如果继续往下拆，可以变成：

  • router agent：判断当前请求属于哪类任务
  • memory agent：专门负责记忆检索和记忆写入
  • schedule agent：专门负责日程和提醒
  • companion agent：专门负责对外回复

这时候每个 Agent 就像流程图里的一个专职节点。

所以多 Agent 并不是 LangGraph 唯一的作用，但它确实是 LangGraph 非常常见的一种用法：

  • 先有一条流程
  • 再把流程里的某些关键步骤交给不同的 Agent

这样做的好处是，职责会比较清楚。

路由 Agent 负责分流，记忆 Agent 负责查记忆，日程 Agent 负责写日程，最后回复 Agent 再把结果说出来。

在代码和排查上，这会比一个超级大 Agent 把所有事都揽下来更好维护。

7. Checkpoint 和恢复执行，解决的是线上问题

只在本地写 demo 时，很多人感觉不到 checkpoint 的价值。因为 demo 一般只有一轮请求，跑完就结束。

但真实服务上线以后，很多流程并不会一次顺顺利利走完。

比如：

  • 外部日历接口超时了
  • 某一步需要人工确认
  • 流程执行到一半服务重启了

这时候如果系统没有保存执行进度，就只能整条流程重来。

LangGraph 的 checkpoint 解决的就是这个问题。它让系统可以记住：

  • 当前走到哪个节点了
  • 当前状态里已经有哪些结果
  • 下一步原本准备做什么

这样一来，流程被打断以后，就不是从头再跑一遍，而是从中间接着跑。

这类能力在「AI 伴侣」场景里并不是完全用不上。比如：

  • 写日程前需要用户确认
  • 某条敏感消息需要人工审核
  • 某些外部工具调用不稳定

这些都属于真实线上问题。LangGraph 的价值就在这里，它不是只让流程「更好看」，而是让流程在服务里更能跑得住。

8. 总结

前一篇讲的是：当问题还在单 Agent 范围内，LangChain 负责把模型、工具、上下文这些能力接起来。

这一篇讲的是：当请求处理变成一条多步骤流程以后，LangGraph 负责把流程组织清楚。

所以它们的分工可以这样理解：

  • LangChain 更像在组装一个能工作的 Agent
  • LangGraph 更像在组织一条能持续推进的流程

当系统只有一轮请求时，你更常碰到的是模型、Prompt、工具问题。

当系统变成多步骤、多分支、多节点时，你更常碰到的是流程、状态和恢复执行问题。

后面的 LangChain 大章会继续往实现层讲单 Agent；再往后进入 LangGraph 相关内容时，就会继续往下拆节点、状态和多 Agent 编排。