系列：ToyAgent 智能体知识库 16/26

工作流状态机：LangGraph 式确定性编排

一句话核心：ReAct 是模型说了算，工作流是流程说了算——节点 + 条件边 + 共享状态，是可控性与灵活性之间的平衡点。

为什么需要

ReAct 把流程决定权完全交给模型：灵活，但业务方睡不着觉。模型今天绕路、明天发散，同一个问题走十条不同路径，审计与合规无从谈起。客服工单、审批流、风控流程这类场景，要求每次都走一样的骨架——这就是工作流状态机的地盘。

用 LangGraph 的术语说，图编排有三要素：

要素	含义	客服示例
节点 Node	一段能力（模型调用 / 工具 / 纯逻辑函数）	classify / tool / faq / polish
边 Edge	固定流转 + 条件路由	classify --next--> tool 或 faq
状态 State	节点之间共享的数据通道	`Map<String,Object> state`

核心机制

// State：在节点之间流转的共享状态，显式、可序列化
Map<String, Object> state = new LinkedHashMap<>();
state.put("input", input);

// 固定入口：先分类
runNode("classify", state);

// 条件边：按分类结果决定下一个节点
String next = (String) state.get("next");
runNode(next, state);          // "tool" 或 "faq"

// 汇合点：不管走哪条路，统一润色后结束
runNode("polish", state);

执行路径：

classify → (条件边) → tool / faq → polish → END

关键在条件边的判定逻辑是你写的代码，不是模型——模型只负责节点内部那一小步（比如"这个投诉是技术问题还是售后问题"），而"技术问题必须走 tool 节点"是流程定死的。

Checkpoint 与中断恢复

LangGraph 的招牌能力：每个节点执行后把 State 落盘（Checkpoint）。由此派生三个能力：

流程任意位置可暂停，人工审批后继续（Human-in-the-loop）；
失败后从最近检查点重放，不用从头跑；
状态可序列化，能跨进程、跨天恢复。

纯 ReAct 几乎做不到这些——因为 ReAct 的状态埋在对话历史里，而状态机的状态是显式的 Map，序列化即存档。

stateDiagram-v2
    [*] --> classify
    classify --> tool: 条件边 next 等于 tool
    classify --> faq: 条件边 next 等于 faq
    tool --> polish
    faq --> polish
    polish --> [*]
    tool --> checkpoint3: 退款接口超时中断
    state checkpoint3 {
        [*] --> 恢复执行tool
    }
    checkpoint3 --> tool: 从 Checkpoint 重放续跑
    note right of classify
        每个节点执行后 State 落盘
        支持暂停恢复与失败重放
    end note

客服工单状态机：classify 后由条件边（判定代码而非模型）分流到 tool 或 faq，汇合到 polish 收尾；tool 节点中途失败可从最近 Checkpoint 恢复，不必从头重跑。

举例

一条客服工单流的状态流转：

用户：我买的键盘第三天就坏了一个键，要求退款

[节点 classify] state = { input: "...", next: "tool" }   # 判定为售后问题
[条件边] next == "tool" → 进入处理节点
[节点 tool] 内部跑 ReAct：查订单 → 查保修策略 → 计算是否符合退款条件
           state 增量 = { order: "A1024", refundable: true }
[节点 polish] 汇总 state，生成最终回复
→ END

─── 中断恢复场景 ───

[节点 tool] 执行到一半，退款接口超时 → 状态机把当前 state 落盘（Checkpoint#3）
30 分钟后重试：从 Checkpoint#3 恢复，订单信息还在 state 里，不用重新分类、重新查单

再举一个混合范式（生产主流）的场景：

客服工单流：宏观可控、微观灵活

classify（确定性节点）
   ↓
handle（处理节点：内部跑 ReAct，自由决定调哪些工具、调几轮）
   ↓
compliance（合规节点：输出必须过敏感词检查，确定性）
   ↓
END

业务方要的确定性在"骨架"上（分类必过、合规必查），
模型要的灵活性在"节点内部"（怎么查订单它自己定）。两层各取所需。

面试考点

ReAct 和工作流编排怎么选？ 看可控性要求：探索型任务（研究、写作）用 ReAct；合规型流程（审批、工单、风控）用状态机。生产主流是混合：工作流管骨架，节点内部跑 ReAct。
为什么状态机的状态可以中断恢复而 ReAct 很难？ 状态机的状态是显式可序列化的 Map；ReAct 的状态隐式埋在消息历史里，压缩、裁剪后语义会漂移，落盘恢复成本高。
条件边和让模型自己路由的区别是什么？ 条件边的判定代码固定、可测试、可审计；模型路由灵活但每次可能给出不同选择，无法通过等价类测试保证合规。

生产化路径

Checkpoint 后端换真实存储（Redis / DB），支持多实例恢复。
节点粒度设计：一个节点一个失败语义，重试才不会误伤相邻节点。
状态 Schema 版本化：流程迭代后，旧 Checkpoint 要能兼容或明确作废。
引擎选型：LangGraph、Temporal、Camunda 各有取舍——轻量编排用前者，长周期人工流程用后者。