Checkpoint与恢复

保存可继续执行的状态及其版本，支持失败后继续。

Checkpoint保存的是能够继续执行的状态，而非某段聊天的备份。LangGraph的公开模型包含channel值、版本和各节点已见版本；runner将成功写入、错误、中断和取消分别提交。这使运行时能够知道下一步该执行什么，但不会自动让外部系统中的副作用变成exactly-once。

持久化后端必须与部署匹配。内存saver适合本地实验，进程重启后状态消失；数据库saver则有迁移、连接、清理与增长成本。业务Task、图thread和checkpoint namespace需要明确对应，不能把用户可提交的thread_id当访问凭证。恢复一个状态前，先验证主体仍有权继续。

每个工具边界应记已请求、已提交、已确认或结果未知。模型推理可以在失败后重新调用，但已提交的关键业务决定不能恢复时随意重生。工具成功后checkpoint失败的空隙，应通过稳定操作ID和外部read-back弥合。审批恢复还要检查批准参数、资源版本和有效期。

恢复保证需要用故障注入证明：杀进程、丢回调、重复投递、数据库暂时失联和部署升级。检查成功节点是否不必要重做，未知动作是否进入对账，取消是否阻止新增工作。checkpoint保留和压缩也要有策略；无限保存完整状态会增加延迟与费用。能够“继续聊天”，不能代替这些恢复验收。

部署升级时还需检验旧检查点能否由新代码读取。状态字段改名、工具结果schema变化或节点拆分，都可能破坏恢复。可以保留旧运行版本完成在途任务，或提供显式迁移与回退；不能因为新版本构建成功就删除旧运行镜像。恢复能力本身应作为发布验收对象。

恢复测试应留下外部状态对照和事件边界证据，不能只凭进程重新启动或页面重新打开来宣称通过。

实践重点：检查点包含图状态、已提交结果和待执行边界；明确持久化后端。

验证抓手：在调用前后、结果保存前后kill worker并核对外部结果。

常见误区：有聊天历史就声称可恢复，或恢复时重复不可逆动作。

LangGraph：Checkpoint模型源码；LangGraph：Runner提交源码。