技术 · 熟练
跑了四十步的 agent，断在第 41 步
重点不是重跑，是接着跑
长任务失败很少是因为「能力不够」，而是因为「状态丢了」——跑到第 41 步崩掉，如果只能从头再来，你付出的不只是时间，还有前面四十步已经产生过的副作用（改过的文件、发过的消息、调过的付费接口）。2026 年冒出来的一批 agent 运行时开始把检查点当默认：每完成一步就落一次可恢复快照。这一页给的是那条最容易自己搭起来的纪律：每个不可逆动作之前存一次，恢复时先核「世界状态」再继续。
方法 · 一图看懂
1
先给「长」划一条线 — 超过单次会话能盯住的长度（十几步以上 · 跨小时 · 有副作用）才值得上检查点；一两步的一次性问答上它只是额外开销
2
每个不可逆动作之前存一次 — 写文件 · 提交代码 · 发消息 · 调付费接口 · 删数据。读操作不用存，存的是「做下去就回不了头」的那一步之前
3
检查点里放四样 — ① 已完成的步骤清单 ② 当前输入（参数 / 路径 / 版本 / 会话 ID）③ 未完成的步骤 ④ 已知的坑与结论（踩过什么、试过什么不行）
4
恢复时先核「世界状态」，再继续 — 检查点记的是「我以为的状态」，恢复前必须回读实际状态（文件在不在 · 版本对不对 · 消息发没发出去），⛔ 不假设它没变
原理 · 为什么有效
agent 循环之所以难恢复，是因为它的「进度」分散在三处：写在磁盘上的产物、留在上下文里的推理、以及已经对外生效的副作用。上下文一断，第二处直接消失；而第一、三处还在。于是最常见的失败形态是「重跑一遍把文件改回去」或者「以为没做，其实已经发出去了」。检查点之所以有效，不是因为它记住了推理，而是因为它把进度压成了可核对的事实：清单 + 输入 + 未完成项 + 已知的坑。恢复动作因此从「回忆」变成「对账」——对账可以机械做，回忆不能。
适用场景
适用：多步长任务（十几步以上 / 跨小时 / 跨会话）· 任务里有不可逆动作（写盘 · 外发 · 付费调用）· 运行环境会中断（本机休眠 · 网络抖动 · 额度用尽 · 人工审批等待）· 你会隔一段时间才回来接着做的事。
⛔ 不适用：一次性的短问答 · 完全只读的检索 · 重跑一次成本极低且没有副作用的探索。
⚠️ 前提：检查点文件要写在任务自己会碰到的地方之外（别放在它正在改的那棵目录里，否则它可能把自己的状态一起改掉）。
自测 · 5 问
我最近一次长任务失败，是重跑了整条，还是从断点接着跑的？
我知道哪些动作是「做下去就回不了头」的吗？还是每个动作都当成可重试？
我的检查点里有没有写「已试过什么不行」？还是只记了「做到哪了」？
恢复之前，我有没有回读一次实际状态，还是直接假设它没变？
检查点文件放在任务会改的那棵目录里吗？（是 ⇒ 先挪出去）
怎么上手 · 验证步骤
先做最小的一步：给你的长任务加一个「状态文件」，只在三个时刻写 —— 任务开始时写目标与输入；每个不可逆动作之前写「即将做什么」；动作完成之后把它改成「已完成」。写的内容只用四行（已完成 / 当前输入 / 未完成 / 已知的坑）。恢复时按这个顺序做：先读状态文件 → 再回读实际产物（文件在不在、内容对不对）→ 对不上就停下来问，⛔ 不自动往下走。
做完之后对照三样：① 假装任务在第 41 步中断，你能不能只靠状态文件说清「现在该做什么、什么绝对不能再做一次」（说不清 ⇒ 检查点缺字段）② 恢复时有没有一次「回读实际状态」的动作（没有 ⇒ 你还是在靠记忆）③ 状态文件里有没有记「已试过什么不行」（没有 ⇒ 下一轮会把同一个坑再踩一次）。