主题
LangGraph 与多步骤流程
1. 先从一个会变长的请求开始
假设用户发来一条消息：
我昨天和客户吵了一架，心情很差。你帮我看看明天下午有没有空，我想安排一次复盘会议。
这条消息看起来只是一句话，但系统内部要处理的事情并不少：
- 判断有没有安全风险或敏感内容。
- 判断用户当前的情绪状态。
- 判断这条消息里是否包含日程需求。
- 如果有日程需求，去查日历。
- 最后决定是安抚用户、给出建议，还是继续追问。
如果把这些步骤都塞进一个 Agent 的 Prompt，一次模型调用也能跑。但流程一长，真正难的地方不再是「模型能不能生成回复」，而是：
- 这一步之后应该去哪一步。
- 中间结果要不要保留、怎么传递。
- 某一步失败后从哪继续。
- 哪些步骤必须执行，哪些可以跳过。
这时候，LangChain 的单 Agent 封装开始显得不够用了，LangGraph 的工作流和运行时能力正是为了解决这些问题而设计的。
2. LangGraph 先解决的不是模型，而是流程
很多人第一次看到 LangGraph，会下意识把它理解成「Agent 的进阶版本」。这个理解不算错，但不够准确。更准确的说法是：
LangGraph 先解决的是流程编排问题，然后才是多 Agent 问题。
在刚才那条消息里，系统要不要先做安全检查、要不要做情绪分析、要不要走日历查询，这些都是流程问题。如果只靠普通函数把所有步骤串起来，代码很容易变成：
- 先写一个
if - 再写一个
if - 中间塞一个工具调用
- 失败后又加一个分支
步骤一多，代码会越来越像一条绕来绕去的线。LangGraph 做的事，就是把这条线整理成一张明确的图：节点是步骤，边是流转条件。
从职责上看，LangGraph 更适合处理下面这些事：
- 组织流程顺序和分支。
- 保存和传递中间状态。
- 处理条件路由和回跳。
- 让多个节点稳定协作。
- 支持中断、恢复和人工确认。
3. 把日程请求拆成一张图
我们还是用刚才那条消息，把系统内部流程拆得更细：
| 节点 | 职责 | 可能产生的新信息 |
|---|---|---|
safety_check | 判断是否需要特殊处理 | 安全标记、风险提示 |
emotion_check | 判断当前情绪状态 | 情绪标签、安抚策略 |
intent_router | 判断是否是日程相关请求 | 意图分类、下一步路由 |
calendar_lookup | 去外部系统查时间 | 可用时间段、冲突事件 |
reply_generator | 生成最终回复 | 最终回复文本 |
这张图里最值得关注的不是节点名字，而是这几个事实：
- 请求不是一步完成的。
- 有些步骤固定会走，比如安全检查和意图路由。
- 有些步骤只在满足条件时走，比如日程意图成立时才查日历。
- 中间会不断产生新信息。
- 最后才汇总成回复。
这就是 LangGraph 的典型使用场景：它处理的不是「模型怎么生成一句话」，而是「一整条流程怎样稳定往前走」。
4. State 是中间信息的公共记事本
新手第一次接触 LangGraph，最容易觉得抽象的词通常是 state。把它放回业务场景里就很好理解。
在刚才那条请求里，系统跑到一半时，内部已经有很多信息：
- 用户原始输入
- 安全检查结果
- 情绪判断结果
- 路由判断结果
- 日历查询结果
如果这些信息只是散落在几个局部变量里，一旦流程复杂起来，很快就会乱。你会开始搞不清：哪个结果是上一阶段产出的、哪个字段还有效、下一步到底能读哪些数据。
LangGraph 的 state 做的，就是把中间信息收拢成一份明确的数据对象，让后面的节点继续往下读。可以把它理解成：
- 每个节点都在读同一份状态。
- 每个节点执行完以后，会补充或修改这份状态。
- 下一步节点看到的是更新后的结果。
这样流程走到哪一步，都不会丢上下文。很多请求不是简单的一问一答，而是会一步步累积信息：先知道用户心情差，再知道他想安排复盘，再知道明天下午有空位，最后才能生成一段既带安抚又带安排建议的回复。如果没有统一状态，这些信息很难顺畅地在各步骤之间流动。
5. Node 和 Edge 让隐式流程显式化
Node 就是流程里的一个步骤。比如：
- 做安全检查。
- 做情绪识别。
- 查日历。
- 生成回复。
每个节点只负责一件相对明确的事。
Edge 就是这一步做完以后，下一步该去哪里。比如：
- 安全检查通过后，去情绪识别。
- 如果判断出有日程需求，去查日历。
- 如果没有日程需求，直接生成回复。
node 和 edge 并不是为了把事情说复杂，而是为了把原本代码里隐含的流程显式写出来。一旦显式化，后面很多事情都会简单很多：
- 哪一步出了问题更容易定位。
- 新加一个步骤更容易插进去。
- 条件分支会更清楚。
这也是为什么 LangGraph 更适合承接复杂流程。流程一旦复杂，最怕的不是功能少，而是路线不清楚。
6. 多 Agent 只是图的一种常见形态
前一篇讲过，多 Agent 的重点是分工。到了 LangGraph 这一层，这种分工才有了更自然的落地方式。系统里不再只是一个大 Agent，而是一张流程图。图里的某些节点，完全可以换成不同的 Agent。
还是刚才那个场景，继续往下拆可以变成：
router_agent：判断当前请求属于哪类任务。memory_agent：专门负责记忆检索和记忆写入。schedule_agent：专门负责日程和提醒。reply_agent：专门负责对外回复。
这时候每个 Agent 就像流程图里的一个专职节点。所以多 Agent 并不是 LangGraph 唯一的作用，但它确实是非常常见的一种用法：
- 先有一条流程。
- 再把流程里的某些关键步骤交给不同的 Agent。
这样做的好处是职责比较清楚。路由 Agent 负责分流，记忆 Agent 负责查记忆，日程 Agent 负责写日程，最后回复 Agent 再把结果说出来。在代码和排查上，这会比一个超级大 Agent 把所有事都揽下来更好维护。
7. Checkpoint 让流程在线上跑得稳
只在本地写 demo 时，很多人感觉不到 checkpoint 的价值。因为 demo 通常只有一轮请求，跑完就结束。但真实服务上线以后，很多流程并不会一次顺顺利利走完。比如：
- 外部日历接口超时了。
- 某一步需要人工确认。
- 流程执行到一半服务重启了。
如果系统没有保存执行进度，就只能整条流程重来。LangGraph 的 checkpoint 解决的就是这个问题。它让系统可以记住：
- 当前走到哪个节点了。
- 当前状态里已经有哪些结果。
- 下一步原本准备做什么。
流程被打断以后，就不是从头再跑一遍，而是从中间接着跑。这类能力在真实场景里并不遥远，比如：
- 写日程前需要用户确认。
- 某条敏感消息需要人工审核。
- 某些外部工具调用不稳定。
这些都属于真实线上问题。LangGraph 的价值就在这里，它不是只让流程「更好看」，而是让流程在服务里更能跑得住。
8. 总结
前一篇讲的是：当问题还在单 Agent 范围内，LangChain 负责把模型、工具、上下文这些能力接起来。
这一篇讲的是：当请求处理变成一条多步骤流程以后，LangGraph 负责把流程组织清楚。
它们的分工可以这样理解：
LangChain更像在组装一个能工作的 Agent。LangGraph更像在组织一条能持续推进的流程。
当系统只有一轮请求时，你更常碰到的是模型、Prompt、工具问题。当系统变成多步骤、多分支、多节点时，你更常碰到的是流程、状态和恢复执行问题。
后面的内容会继续往实现层讲单 Agent；再往后进入 LangGraph 相关内容时，就会继续往下拆节点、状态和多 Agent 编排。
一句话总结
LangGraph 不是让 Agent 更聪明，而是让多步骤流程有清晰的路线、稳定的状态和可恢复的执行能力。