幂等性是恢复执行的核心词。一个工具如果重复执行不会造成额外副作用，就更容易恢复。例如读文件幂等，搜索幂等，纯计算幂等。写文件如果基于相同 base hash 应用同一个 patch，也可以设计成近似幂等。发邮件、支付、删除远程资源通常不幂等。 工具定义中应声明： 这会直接影响 resume 策略。
恢复流程要保守： 1. 找到最新完整 checkpoint； 2. 校验 workspace 状态； 3. 恢复 message history 和 run state； 4. 检查最后一个 tool call 是否已完成； 5. 对不可重复工具禁止自动重放； 6. 给模型注入恢复说明； 7. 从下
为 miniagent 增加 checkpoint： 每个 step 前保存 precheckpoint； 工具执行后保存 postcheckpoint； 文件写入记录 patch 和 base hash； audit log 纳入 checkpoint； crash 后可以从最新 checkpoi
一个 checkpoint 至少包含： session id、run id、step id； message history 或其可重建引用； 当前计划和 stop condition 状态； tool call 计划、执行结果、是否有副作用； 审批记录； 文件系统变更摘要； token/cost/
目标：实现可恢复执行。 功能范围： 每轮工具执行前创建 checkpoint； 文件修改保存 patch； 支持恢复文件状态； 支持恢复 session 状态； 进程崩溃后继续 run； 恢复后不重复执行高风险工具。 适合证明： 状态管理； 可恢复执行； 可靠性工程； coding agent 长任
回滚不丢对话上下文；恢复不重复执行高风险工具；文件状态和 session 状态能对应到同一个 checkpoint；trace 可以说明恢复从哪一步开始。做到这里，runtime 才从脚本接近系统。
用户说'回滚'时，可能有三种意思： 回滚文件到某个 checkpoint； 回滚对话状态，让 Agent 忘记某段计划； 回滚外部副作用，例如撤销 API 操作。 Runtime 必须区分这三件事。文件 patch 可以回滚，对话状态可以恢复，外部副作用通常只能补偿，不能直接撤销。比如创建了 Git
第八章 Checkpoint、Resume、Rollback：8.2 patchbased checkpoint 对 coding agent 来说，文件系统状态是第一等公民。最轻量的做法是 patchbased checkpoint：每次工具执行前后记录 diff。 优点： 存储小； 容易审计；
第八章 Checkpoint、Resume、Rollback：8.3 gitbased checkpoint 另一种做法是借助 git。每个 step 或关键写入点创建临时 commit、stash、worktree 或 patch 文件。 gitbased 的优点是成熟、可审计、适合代码项目。缺点
长任务一定会中断。问题是：失败后怎么继续，而不是重来？ Agent Runtime 一旦进入真实工程任务，就会遇到长运行：改多个文件、跑多轮测试、安装依赖、查文档、等待用户确认。长运行必然遇到中断。浏览器刷新、进程崩溃、网络超时、模型失败、用户临时离开，都可能打断 run。如果没有 checkpoi
