你让一个 Agent 去抓数据、分析文档、调用工具，再生成报告。它已经跑了 30 分钟，前面十几步成功了，这时服务器宕机。机器恢复后，问题来了：要不要从头再跑？
如果答案永远是"重来"，长任务几乎注定不可靠。真正需要解决的，是 Agent 能不能在故障后知道自己"做到哪了、哪些结果可信、下一步该做什么"。这就是 Checkpoint 的价值。
长任务真正怕的，不是失败，而是失忆
短请求失败，重试通常没什么成本。但 Agent 任务往往是有状态的：它会搜索、调用 API、写文件、修改数据库，还会根据前一步输出决定下一步。
所以，失败后"从头执行"不只是慢，还可能出错。
假设 Agent 已经给 20 个客户发送了通知，随后服务器崩溃。如果恢复后从第一步重新执行，它可能再次发送 20 次。
一个可恢复的 Agent 系统必须回答三个问题：哪些步骤已经完成？完成结果是否仍然有效？哪些操作可以安全重试？
Checkpoint 解决"记住做到哪"，幂等性、事务和重试策略解决"重复执行会不会出事"。这几件事要一起设计。
Checkpoint 保存的不是日志，而是"可继续执行的状态"
很多人第一次做 Checkpoint，会想到"把每一步日志都存下来"。日志的目标是排查问题，Checkpoint 的目标是恢复任务。
Checkpoint 至少要保存四类信息。
第一类是任务位置，比如当前工作流节点、已完成步骤、下一步入口。没有它，系统只能知道"发生过什么"，却不知道"从哪里接着跑"。
第二类是关键中间结果，比如文档 ID、结构化数据、已经校验过的计划。内容太大时，可以只保存对象地址、版本号或结果引用。
第三类是外部副作用记录，比如邮件是否已发、订单是否已创建、数据库是否已更新。最好同时保存幂等键、外部资源 ID 和执行状态。
第四类是执行上下文，包括配置版本、工具参数、输入版本，以及必要的上下文摘要。否则恢复后即使从同一步开始，也可能因为环境变化得到不同结果。
把 Checkpoint 理解成登山营地：不是记录沿途看到了什么，而是保证出事后能从这里继续。
每一步都 Checkpoint，并不总是划算
既然 Checkpoint 能救命，是不是每执行一步都保存一次最安全？
不一定。
如果 Agent 有几百个细粒度步骤，每一步都同步写数据库，时间会耗在序列化、网络 IO、数据库写入和一致性确认上。
保存过于频繁，还会增加状态复杂度。一个步骤同时更新多个外部系统时，可能出现"半完成"状态：数据库写成功了，文件还没写完，状态却已标记完成。恢复时更难判断。
所以，Checkpoint 的粒度不应等于"代码执行一步"，而应接近"业务上完成了一个可恢复单元"。
连续几次只读搜索，成本低、没有副作用，可以不必每次保存；一轮昂贵分析已经得到可复用结果，就值得保存。发送邮件、创建订单、修改生产数据时，则应围绕动作前后保留足够状态，确保重试不会重复执行。
什么时候该保存？看成本、风险和边界
判断 Checkpoint 频率，可以看三件事：重做成本、重复风险、是否跨过了清晰边界。
如果前面的计算只用了几秒，重做很便宜，就没必要频繁持久化。如果某一步跑了十分钟推理，或调用了昂贵 API，保存结果通常值得。
如果某一步会产生外部副作用，优先级更高。发送消息、支付、创建资源、更新数据库，都应配合幂等设计。理想状态是，即使恢复逻辑判断错了，再执行一次也不会造成重复结果。
边界则帮助控制复杂度。一个子任务完成、一批数据处理完成、一轮规划结束、一个人工审批节点结束，都是自然的 Checkpoint 点。
工程上可以采用混合策略：关键节点强制保存，同时按时间或处理批次做周期性 Checkpoint。既避免丢失太多进度，也不会让每一步都承担持久化成本。
恢复时，不要只问"从第几步继续"
可靠的恢复流程，不应该简单读取 step=17，然后直接执行第 18 步。
系统应先校验 Checkpoint 是否完整，再确认依赖资源是否仍然存在，接着判断上一步是否已经产生副作用。某个动作状态不确定时，应去外部系统查询，而不是仅凭本地记录猜测。
还要区分"可重试失败"和"逻辑失败"。网络超时、机器重启可以自动恢复；输入不合法、权限不足、业务规则冲突，反复重试没有意义，应进入人工处理或失败分支。
成熟的 Agent 运行时更像工作流引擎：任务被拆成可识别、可重试、可验证、可恢复的执行单元。
最好的 Checkpoint，是让失败成为正常流程的一部分
Agent 跑 30 分钟后服务器宕机，不应该默认从头开始，也不应该机械地"从断点继续"。更稳妥的做法，是从最近一个可信 Checkpoint 恢复，再对后续动作做状态校验和幂等重试。
如果你正在设计 Agent，可以先把流程中的步骤分成三类：可随时重做、计算昂贵、带外部副作用。前者少存，第二类在结果产出后存，第三类围绕动作边界重点存。
Checkpoint 的目标不是"记录得越多越好"，而是在可接受的性能成本下，把一次宕机造成的损失限制在一个很小、可判断、可恢复的范围内。