803 字
4 分钟
-
-
增量检查点：长工作流可靠性的下一步
一个 20 步的工作流在第 18 步挂了。你是重跑全部 20 步，还是从第 18 步恢复？答案取决于你的检查点策略。
问题
长工作流（10+ 步骤、跨越数分钟到数小时）面临的核心可靠性问题：
- 中断后恢复成本高 —— 如果只保存最终状态，中间失败就得从头来
- 全量快照开销大 —— 每步都保存完整 state（可能包含长文本、大文件引用），存储和序列化成本线性增长
- 节点失败影响全局 —— 一个节点超时或报错，没有隔离机制，整条链路阻塞
DeltaChannel 范式
LangGraph v1.2 alpha 引入的 DeltaChannel 是一种新的 state channel 类型：
不再每步保存完整状态，而是只存储相对于上一个检查点的变更增量（delta）。
恢复时，从最近的完整快照开始，依次 apply 后续的 delta，重建到中断点的状态。
Checkpoint 0 (full) → Δ1 → Δ2 → Δ3 → Checkpoint 4 (full) → Δ5 → Δ6 → ...周期性做一次全量快照（compaction），避免 delta 链过长。
优势
- 存储开销降低 5-10x —— 大多数步骤只修改 state 的小部分
- 序列化速度提升 —— 只序列化变更字段
- 恢复仍然快 —— 只需找最近的全量快照 + apply 少量 delta
配套：节点级超时和 Saga 补偿
DeltaChannel 解决存储问题，但可靠性还需要两个配套机制：
Per-node Timeout
node_config: run_timeout: 60s # 执行超时 idle_timeout: 30s # 无输出超时每个节点独立超时，不再是工作流整体一个超时。API 调用节点给 30 秒，代码生成节点给 5 分钟——按需分配。
Node-level Error Handler（Saga 补偿）
当节点失败时，不是直接抛出终止整个工作流，而是触发该节点的补偿逻辑：
- 文件写入节点失败 → 清理已写入的部分文件
- API 调用节点失败 → 标记为降级，跳过非必须步骤
- 数据库操作失败 → 回滚事务
这是分布式系统中 Saga pattern 在 agent 工作流中的应用。
对工作流引擎的启示
如果你在构建多步骤的 agent 工作流系统：
- 别只存最终结果 —— 至少在每个节点完成后持久化一次 state
- 增量优于全量 —— 大部分节点只修改 state 的 1-2 个字段，全量序列化是浪费
- 超时是节点级的 —— 不同操作的合理超时差异巨大
- 补偿优于重试 —— 有些操作不可重试（已发送的消息、已提交的表单），需要正向补偿
Graceful Shutdown
另一个细节：当系统需要停止一个正在运行的工作流时（部署更新、资源回收），不是直接 kill，而是：
- 发送停止信号
- 等待当前节点完成
- 保存检查点
- 释放资源
下次启动时从检查点恢复，而不是重跑。
这对于运行时间长（几小时）的 agent 工作流尤其重要——你不希望一次部署导致所有正在执行的任务从头开始。
参考
- LangGraph v1.2.0 alpha release notes
- Saga Pattern in Distributed Systems