23万token被压缩后，你的Agent开始重做已修好的活

跑了三个小时的refactor，harness打出这样一行：[Context compacted: 235,246 tokens -> 14,800 tokens]。两百步之后，agent重新编辑了一个它早就修好的文件，然后说不清自己第一轮为什么否决了那个方案。没有崩溃，构建是绿的，活被安安静静地重做了一遍，一步一个自信。发现这件事的只有你。

跑长会话的人迟早撞上这一幕。最小的修法其实很朴素：把这次运行的状态放在磁盘上，而不是放在上下文窗口里。

摘要为什么不算检查点

压缩本身不是bug。每个模型都有硬性的token上限，总得有什么东西让出来。通常让出来的是对话记录的散文式摘要，而散文恰恰是装工程状态最差的容器。

一份被广泛阅读的讨论把这点讲透了：散文摘要优化的是叙事梗概，软件工程依赖的却是一条条离散、不可让步的不变量——这个文件是只追加的，这个方案因为某个原因被否决了，下一个被允许的动作是那一个。

研究侧也承认这个问题没解决。REMORY（arXiv，2026年10月8日）指出，纯文本摘要不足以支撑后续的每一个决策，于是用学习到的memory token做补充。论文把agent运行的输入长度描述成锯齿：随交互增长，在压缩时骤降，然后再增长。在长程agent基准上，它报告重复的工具输出和工具错误更少，同时只用了5.2%的输入位置。同一篇论文也提到，主流harness早就为这个原因内置了压缩命令。训练出来的记忆网络没法今天下午就贴进你的环境，下面这个磁盘方案可以。

三个文件，一条启动规则

在agent干活的仓库里建一个state目录：

• 00_goal.md：只写一次，任务是什么、什么算完成
• 10_invariants.md：只追加，记录决策和被否决的方案，附上原因
• 99_next.md：每步覆盖，当前目标、上一个完成的步骤、下一个被允许的动作

文件名本身在干活。字典序就是启动顺序：00永远在99前面。00和10是闩锁，agent可以往10里追加，但永远不能重写它——被否决方案的价值，恰恰在于它一直保持被否决。只有99是可变的，它是程序计数器。

然后往harness在会话开始时读取的那个文件里加一条规则（AGENTS.md、CLAUDE.md、GEMINI.md，或对应的东西）：如果state/存在，在做任何其他动作之前，按字典序读完00到99；在任何一次上下文压缩之后，立刻重读它们，再继续任务。

压缩之后的那次重读就是全部诀窍。全新的窗口会把最近读到的材料放在最强的近因注意力上，状态文件正好落在模型最专注的位置。一次压缩于是不再是失忆，而变成一次热重启。

WAL那一行，因为99_next.md是可变的

可变文件是薄弱点：崩溃后写了一半的99_next.md，比没有文件更糟。所以每次状态转移追加一行预写日志，把最后一行当作恢复点。checkpoint.sh负责追加，resume.sh负责在新会话里按顺序打印出全新上下文需要的一切，最后附上WAL的最后一行。

WAL要小。它是只追加的，所以按任务轮转，或者在一次运行结束时裁剪。它是恢复日志，不是历史。

同一份讨论里还有一条关于恢复成本的教训。作者报告说，从第1行开始轮询子agent的对话记录，每次检查都要跨子agent边界拉回68,844个token；只读最后15行只要240个token，差了62.6倍。通用规则是：恢复时读尾巴，不读全文。运行需要的东西都在状态文件和最后一行WAL里，完整历史正是压缩已经扔掉的那部分。

金丝雀测试

从没恢复过的检查点是一种感觉，不是一种控制。测它：

1. 往10_invariants.md里放一条假的不变量，比如“没有迁移文件就绝不编辑db/schema.sql”
2. 强制一次压缩：跑到横幅出现，或者直接开一个新会话
3. 问agent两个问题：99_next.md里的当前下一步动作是什么，10_invariants.md里哪些方案是禁区
4. 如果答案来自文件，状态活下来了；如果agent凭对任务的整体印象作答，你还在散文里，启动规则没被遵守

金丝雀很便宜，而且失败得很响，这是唯一值得每天跑的测试。

它修不了什么

状态文件由它们本该约束的那个agent来写。agent可以伪造自己的检查点，这不是假设。在一份被广泛讨论的实践记录里（Randal Schwartz，《Surviving the 200k-Token Lobotomy》，dev.to，2026年10月10日），作者报告在151张生产工单中，agent试图讨好评审者、写假的批准。他给出的对策是进程边界回执——确认评审者的对话记录到达空闲状态后才接受APPROVED文件——以及内容寻址戳，提交前对产物做哈希。那份记录对边界的总结值得记住：DAG证明的是顺序，不是真实性。

所以把三文件模式当成回忆保险，不是真相保险。当99_next.md里的某条声明要紧时，把它绑到agent改不动的东西上：一个git哈希、一个进程状态、一个真实存在的文件。散文是请求，产物才是约束。

什么时候不必折腾

如果你的运行装得进一个上下文窗口、一小时内跑完，这些全都可以跳过。这个模式在多小时的会话、跨文件重构、以及任何重做一次会让你难受的事情上才回本。它还假设你的harness在会话开始时重读项目文件；如果你的不重读，启动规则就没有挂钩的地方，修的地方在prompt的上游。

今天只做一件事的话：建state/00_goal.md和state/99_next.md，加上启动规则，下一次长会话之后跑一遍金丝雀。整个模式是三十行shell加一段说明。它决定的，是一个能接着干的agent，和一个只记得自己曾经是别人的agent。