第一次运行已经收集订单资料并写好报告，第二次运行却重新收集，甚至覆盖了人工修正。问题不一定是模型“记性差”，也可能是系统没有把已完成工作变成可靠状态。
长任务会跨越模型上下文、进程生命周期和业务资料版本。恢复需要回答三个问题：任务现在应该做什么，环境实际上完成了什么，当前还允许做什么。聊天记录只能覆盖其中一部分。
计划与进度应该分别保存
计划描述要做的工作，例如读取订单、核对政策、生成报告、验证、导出。进度记录这些步骤哪些已完成、依赖哪些输入、留下哪些证据。
“已生成报告”太模糊。更有用的记录是“根据订单版本 12 和政策 P7-v2 生成候选 H1，事实校验失败于状态字段，尚未导出”。下一轮据此知道应该修复状态，而不是重新猜测全过程。
计划是可调整的：新增用户要求可能增加一项附录。但完成条件不能被 Agent 为了省事偷偷降低。任务条目应该链接具体要求和验收证据，修改要求本身需要与用户授权范围一致。
第一次运行和后续运行需要不同准备
首次运行要建立工作区、固定输入和完成契约。后续运行要先读取进度与环境现状，判断是否能安全继续。如果每次都执行初始化，就可能覆盖已有成果；如果完全跳过检查，又可能在损坏环境上继续工作。
Anthropic 的长任务实践用初始化、逐步推进和交接记录应对多上下文任务。它提供了有用的工作组织思路，但并不意味着所有 Agent 都必须采用相同的文件名或 Git 流程。原文
本系列报告示例每次只推进一个可验证阶段。计划和进度由控制器保存；模型看到的是必要投影，不需要重复加载全部失败日志。
四种状态对象为什么不能混为一谈
Checkpoint 保存执行位置与恢复所需状态；Snapshot 可以保存某个时刻的状态投影和外部引用；事件日志记录发生过的变化；工作区保存文件字节。不同框架对这些词的命名可能重叠，关键是查看实际保存的内容。
例如一个 Snapshot 记录事件游标 18、阶段 verify、输入 hash S、候选 hash H、Harness 版本 V。恢复时读取游标后的事件，可以补上后来发生的变化。但这要求系统实际采用并维护事件日志，不能只建一个 JSON 字段就声称实现事件溯源。
快照通常不包含正在运行的进程、网络连接或远端操作的真实状态。即使文件存在，也需要核对版本；即使审批记录存在，也需要重新检查是否过期。
看一个最容易出错的时间窗口
t1 写入 report.json，内容 hash 为 H1
t2 进程崩溃
t3 原计划要保存的 checkpoint 尚未写入
t4 新进程读取旧 checkpoint，阶段仍是 generate如果恢复逻辑机械地重放 generate，会覆盖 H1。更合理的处理是检查候选文件是否存在、是否属于当前输入，重新验证后决定继续还是重建。
对于本地纯生成，这可能只是重复计算；对于发送邮件、退款或上传，重放可能产生重复副作用。因此外部动作需要稳定 operation ID 和权威回执查询。工具响应超时不代表外部动作失败，应先核对未知状态，详见工具失败与幂等。
配套程序将文件和状态分开保存，并在恢复时重新读取、验证候选，明确没有多文件事务。这比用内存标志声称“崩溃后一定不重复”更符合实际边界。
两个 Worker 同时恢复怎么办
单机演示可以约定只启动一个进程。生产中，旧 Worker 卡住后新 Worker 接管，旧 Worker 又恢复，就可能双写。租约控制一段时间内的任务所有权，但仅靠到期时间不能阻止旧 Worker 继续操作。
fencing token 是递增的所有权编号。新 Worker 获得编号 42，存储拒绝旧编号 41 的写入，才形成对旧执行者的实际隔离。如果下游服务不检查编号，发出 token 并不会自动防止重复动作。
这一机制属于 Runtime 与存储协作。本篇解释为什么需要，生产设计篇说明接口，完整分布式执行实现留给 Runtime 系列，避免把恢复文章变成队列框架教程。
恢复顺序要同时关注事实与权限
先取得有效任务所有权，再加载执行记录和文件引用，核对输入、产物及策略版本；查询未知外部操作；重新检查权限与审批；最后构造必要上下文并继续。不存在一条适用于所有后端的原子恢复命令。
模型版本或 Skill 更新后，也不能静默把旧状态交给新逻辑。可以固定旧版本完成任务，或执行显式迁移并重新验证。长期无法运行旧版本时，应清楚记录恢复边界，而不是把失败归因于模型。
压缩摘要帮助模型理解过去，但不能替代这些状态对象。摘要漏掉“上传已成功”，不应该导致重复上传；任务账本与外部回执才是依据。
完整实战提供暂停后恢复的标准库示例，不调用模型、不启动 Worker 平台。它保留状态文件，便于读者手动查看每个阶段发生了什么。