LangGraph

把下一步写成可检查的规则#

LangGraph 用状态保存当前任务的信息，用节点完成一步工作，用边决定接下来运行哪个节点。节点既可以调用模型，也可以执行普通代码，因此图里可以同时存在确定规则和模型决策。1 2

教学情境：收到退款请求，先检查订单，再生成处理建议，超过金额阈值就等待人工审批，批准后执行退款。图表达的是“谁决定下一步”，不是模型内部的神经网络，也不是保存实体关系的知识图谱。

状态保存不等于操作只发生一次#

检查点保存某个线程的图状态；store 可保存跨线程的应用数据。内存保存器适合演示，但进程重启后会丢失内容，需要恢复能力时应选择持久化实现，并正确隔离线程标识。3

interrupt 允许暂停等待外部输入。恢复时，包含中断的节点会从头运行，暂停之前的代码可能再次执行。如果那段代码发邮件或扣款，就必须考虑重复副作用。4

本站建议把审批放在副作用之前，并在业务服务层使用幂等键检查重复请求。只拆分节点仍不能替代业务去重；也不能把整个外部系统的事务责任交给检查点。

最小判断#

先画出节点、每一步读写的字段，以及成功、失败、等待三种去向。若只有顺序的三步，普通工作流可能已足够；如果需要分支、长时间等待和恢复，再评估图编排带来的收益。

多个节点可能更新同一字段时，应明确是覆盖、追加还是自定义合并。LangGraph 用 reducer 定义状态字段如何接收更新，不能依赖碰巧的执行顺序。2

动手验证#

下面是本站的纸面故障演练，不需要模型密钥，也不是已执行的 LangGraph 示例。

1. 给一张教学订单分配固定任务标识，画出“校验 → 审批 → 执行 → 完成”。
2. 在审批前、审批后、执行成功但记录未写入时，分别假设进程退出。
3. 写出每次恢复会读取什么、重跑什么、凭什么避免重复执行。
4. 另开一个用户的任务，检查两者是否能意外读取同一状态。

验收标准：每个断点都有可解释的恢复策略；不能恢复或无法去重的位置必须明确标出。带着这份清单再实现框架，才能判断持久化与护栏是否真正生效。