Pi-Math 项目。47 小时的 marathon session，6 个 UI 模块迁移，12 个 tick 的 OPC loop。$364 的 token 成本。
跑到第 8 个 tick 的时候，review agent 突然提了一个 finding：「这个函数的错误处理不完整。」
问题是——第 3 个 tick 已经修过这个问题了。完全一样的 bug，完全一样的修法。
AI 忘了。
五百页小说压缩成两页
（EP06 用过类似的比喻——五百页论文压成两页来讲成本。这次换成小说，因为重点不同：论文丢的是数据，小说丢的是伏笔。）
想象你在读一本五百页的小说。你读了三百页，记住了所有角色、所有情节线、所有伏笔。
然后有人走过来，把你读过的三百页拿走，递给你一份两页的摘要：「主角叫张三。他在寻找一个宝藏。他的朋友死了。」
你继续读第三百零一页。你知道主角叫张三，你知道有一个宝藏，你知道有人死了。但你不记得——张三在第 47 页拒绝了一条近路，因为那条路经过一个他不想面对的地方。你不记得他朋友死前留了一句话，那句话的真正含义要到第 400 页才会揭晓。
这就是 context compaction（上下文压缩）。
AI 的工作记忆（context window）是有限的。当对话变得太长，系统会自动压缩——把前面的内容总结成一个摘要，腾出空间给新内容。信息的梗概保留了，但决策的原因丢了。
在 Pi-Math 的 2170 分钟 session 里，context 被压缩了多次。每次压缩之后，AI 的 review 质量都会明显下降——不是因为它变笨了，而是因为它丢失了「我之前已经检查过这个问题」的记忆。
三种不 work 的方案
发现问题之后，我尝试了三种方案。
方案一：加大 context window。 理论上，如果 context 足够大，就不需要压缩。但 context window 有物理上限（当时是 200K token），而且越大越贵、越慢。一个 47 小时的 session 产生的信息量远超任何 context window。这不是解法，是拖延。
方案二：在 prompt 里重复关键信息。 每个 tick 开始时，把之前所有 tick 的 summary 塞进 prompt。问题：summary 本身就在增长。到第 12 个 tick，summary 占了 context 的 40%，留给实际工作的空间反而更小了。
方案三：让 AI 自己维护记忆。 要求 AI 在每个 tick 结束时写一份「这个 tick 我学到了什么」的笔记。问题：这些笔记是 AI 生成的，它们也会随着 context compaction 被压缩掉。用 AI 来解决 AI 的记忆问题，就像用遗忘来治疗遗忘。
机械桥梁
最终 work 的方案不靠 AI 的记忆，靠文件系统。
OPC 设计了一个 checkpoint 机制：每个 tick 结束时，把关键状态写进文件。不是 AI 自己决定写什么——是 harness 代码强制要求写什么。tick-N-summary.md 包含：
- 这个 tick 做了什么（代码变更 + 测试结果）
- 发现了哪些问题（带具体的 file:line 引用）
- 哪些问题已修、哪些待修
- 下一个 tick 应该关注什么
下一个 tick 启动时，harness 把最近 3 个 tick 的 summary 文件注入到 system prompt 里。不管 context 怎么压缩，这些文件在文件系统上是物理存在的——压缩不掉。
这就像日记。不管你的记忆多差，只要你昨天写了日记，今天就能翻开看到「昨天我修了一个 error handling 的 bug，具体在 src/lib/parser.ts:47」。日记不靠你的大脑存储——它在纸上。
更深层的设计是两个 hook：PreCompact 和 PostCompact。
PreCompact 在 context 即将被压缩之前触发。它的职责是把当前最重要的信息抽取出来，写进文件——比如「当前正在修 bug #23」「已经尝试过方案 A 和 B，都失败了」「下一步应该试方案 C」。
PostCompact 在 context 压缩完成之后触发。它的职责是把 PreCompact 保存的文件注入回新的 context。AI 看到的第一条消息就是「你之前在修 bug #23，方案 A 和 B 失败了，下一步试方案 C」。
PreCompact 写入，PostCompact 读出。文件系统是桥梁。AI 的记忆断了没关系——桥还在。
文件系统 > AI 记忆
这个解决方案揭示了一个更一般的原则：在 agent 系统里，文件系统是唯一可靠的长期记忆。
AI 的 context 是临时的——它会被压缩、被截断、被清空。Git 是半持久的——它记录了什么变了，但不记录为什么变。只有文件系统上显式写入的状态文件是完全可控的——你写什么它存什么，你不删它不消失。
OPC 的 .harness/ 目录就是这个理念的体现。flow-state.json 记录当前在哪个节点。progress.md 记录每个节点的叙事。acceptance-criteria.md 记录验收标准。这些文件不在 AI 的 context 里——它们在磁盘上。每次 tick 开始时才被读入。
在更大规模、更长周期的项目里，这个机制被反复验证。每次 context 压缩之后，AI 都能从文件系统恢复状态继续工作。决策的细节可能丢了，但方向和进度不会丢。
不完美吗？当然。「为什么选了这个架构而不是那个」这种决策 rationale 很难用结构化文件保存。但对于「我在做什么、做到哪了、下一步是什么」这些执行层面的信息，文件系统足够可靠。
AI 的记忆像 RAM——快但易失。文件系统像硬盘——慢但持久。工程上的正确做法和计算机架构一样：把重要的东西写进硬盘。
硅基团队 S1: AI 能写代码，凭什么信它？ ← S1E07: 当工具开始检查自己 | S1E09: 不让 AI 变好，让坏后果变小 →