智能体长任务的检查点设计：跑一半断了也能接着干

做长任务的 Agent 最怕的不是慢，而是断。一次工具调用超时、一次上下文溢出、一次会话刷新，前面跑了半小时的进度就可能全部作废。检查点就是给长任务留的“存档点”，让它断了也能从最近的存档接着干，而不是从头再来。

第一个习惯：把任务拆成可恢复的步骤。不要让 Agent 一口气跑完十步，而是每完成一步就写一条结构化记录：这一步做了什么、产出了什么文件、下一步的输入是什么。记录要落在磁盘或数据库里，而不是只留在对话上下文中。上下文会丢，文件不会丢。

第二个习惯：检查点要包含“如何验证”。只写“已完成数据清洗”是不够的，检查点里还要写验证方法：行数多少、关键字段是否为空、输出文件路径在哪里。下次恢复时先跑验证，通过了才继续，不通过就重做这一步。这样可以避免带着脏数据往下走。

第三个习惯：定期存档，而不是只在结束时存档。长任务里每隔几步就存一次，哪怕这一步看起来微不足道。存档成本很低，重跑成本很高。我的做法是每完成一个有外部副作用的步骤就立即存档，比如调完接口、写完文件、发完请求之后。

第四个习惯：恢复时先读档再动手。很多 Agent 恢复后凭记忆接着干，结果和存档里的状态对不上。正确顺序是先读检查点，确认当前进度和待办，然后再执行下一步。读档这一步不要省，它是防止重复劳动的关键。第五个习惯：给检查点设过期与清理规则。检查点不是越多越好，过期数据会误导恢复。做法是给每个检查点打时间戳，任务完成后归档一份、删除中间过程，失败重试时只保留最近三次的检查点。检查点设计本质上是把“一次跑完”的幻想换成“随时可断、随时可续”的工程习惯。Agent 的能力边界很多时候不是模型决定的，而是任务结构决定的。先把任务做成可恢复的，Agent 才能真正跑长任务。