长任务 agent 跑到大半个钟头挂掉，多半不是模型变笨，是状态长错了地方——它埋在对话历史里，对话一断，前面就白干。这周好几篇东西都在往同一个方向使劲：把状态从上下文剥出来，落成文件、落成 git 记录、落成能回滚的东西。方向我认，但先泼盆冷水：什么都存，死得比不存还快。问题不是存多少，是 checkpoint 放哪。
把状态写成文件，方向我认
Agent memory as a file format 这帖我读得挺有共鸣。作者主张把 agent 的记忆当成显式文件格式，而不是埋在上下文里。按我的理解，对话历史里混着两类东西：「发生过的事实」和「模型当时怎么想的」。前者是恢复时必需的，后者大部分时候是噪音。事实落成文件之后，agent 每一步做了什么就能被 diff 出来；恢复的时候读文件就行，不用祈祷模型把半小时前的决定再"回忆"一遍。
这个思路已经有人做出东西了。OKF Agent Memory 走的就是 git-native 持久记忆——模型的工作状态直接和仓库绑定，commit 历史就是它干过什么的审计记录。
但小心一点：普通文件本身也只是一堆字节。写一半断电、两份文件互相矛盾，状态照样丢。所以光有"把状态写成文件"的自觉还不够，得有一个真正的状态层，保证写入是原子的、变动是可见的。
全量 checkpoint 比崩溃贵一倍
老实说，我最开始想的也是全量存档：每步推理都记下来，挂掉就从最近的地方续上。这个直觉在短任务里没问题，放到长任务就变味了——思考步骤如果每一步都持久化，状态层的写入频率会追上模型的 token 速度。快照之间只隔几秒，一致性校验的复杂度立刻爆表。等你想给恢复写测试，每个快照都要能恢复、每份恢复都要一致，这套系统会比 agent 要干的活本身还难维护。
还有个更深的问题，agent 快照和虚拟机快照不是一回事。虚拟机可以把内存、网卡状态、打开的文件全冻住；agent 的上下文是模型生成的，它手里还握着外部世界的 handle——一个发出去了没回执的请求、一个创建到一半的工单。内部状态存下来了，外部世界可不会等你。恢复的时候你以为自己在续跑，其实外部状态已经变了。
所以"可靠"的全量落盘是个幻觉。你只是把"会崩溃"的问题，换成了"恢复后不一致"的问题。
Checkpoint 只放在副作用旁边
那什么东西值得存？我的工程判断是：只 checkpoint 有副作用的调用。区分其实很简单——只有会改变外部世界的动作要记。读一个文件不改变世界，写一个文件改变；搜一次网页不改变，下单改变。推理过程随便丢，重跑一遍顶多多烧几分钟 token；产生过外部影响的动作丢了，就得从头摸索，更糟的是重复执行一遍，把副作用施加两次。
具体落地，我的倾向是：有副作用的工具调用发起前先记 intent，返回后再记 outcome，两条记录之间做幂等控制。这样重放的时候，挂在半路的动作能被认出来，不会重复执行。账记好之后，恢复就走重放路线：挑最近的 checkpoint 还原外部状态，然后给模型一份简短摘要让它重新规划——别把旧上下文原样灌回去，模型会开始复读旧分析，而工具返回早就过期了。
这周 Meta 安全研究员的 agent 误删了她的邮件 是个很好的反面教材：删除没有回滚语义，checkpoint 就算建在删除动作之前，恢复也只是把删除重放一遍。所以 checkpoint 只解决一半问题，另一半是副作用本身要可回滚、可幂等。这两条性质缺一条，存多少都没用。
Git 当状态层，被低估了
最后说点看得见的东西。DoltLite 发布，两千个 agent PR 堆出来的 SQLite + Git。我关注的重点不是 SQLite，而是"两千个 agent 提交"这个数字能成立的前提：状态管理得当的 agent，它们的工作成果是可以 merge、review、reset 的。OKF 的 Agent Memory 也选 git，思路相通——把 agent 的活动当作一段持续演进的文件树，commit 就是 checkpoint，checkout 就是恢复。
git 被低估了作为 agent 状态层的价值。它是工程师最熟的回滚工具，自带审计链，有人类可读的 diff。把断点续跑做成"每次副作用提交一次，挂了就 checkout"，听起来没什么新意，但比起设计一个崭新的状态存储，这条路可靠得多。
按我现在看，断点续跑的本质就是给副作用记账。账记在哪、怎么记，决定了崩溃的时候是花十秒钟 checkout，还是跪着把大半个钟头重跑一遍。也许过几个月回头看这判断会显得太朴素——但朴素的事往往先被验证。