在 AI 编码代理中重建 1982 年 64KB PDP-11 Unix（init.d、fork/wait 与覆盖机制），以挺过 200k-token 上下文压缩

回到 1982 年，在一台仅有 64KB 内存、运行 BSD Unix 的 PDP-11 上，常驻内核被硬性限制在 48KB 以内，因为内核和正在运行的用户进程必须共享同一块 64KB 地址空间。为了在不耗尽内存的前提下构建任何像样的东西，Unix 依赖三个技巧：fork 出短命的子编译器进程，使其在退出码 0 时释放内存；额外的内核子系统通过覆盖（overlay）方式分页载入；以及 /etc/init.d 将启动状态拆分为按字典序编号的文件（00 到 99），而不是依赖一个脆弱的大脚本。在过去几个月、横跨 151 个工单的实践中，我意识到 LLM 上下文窗口面临着完全相同的统一内存问题。当一个复杂会话达到 230,000 个 token、IDE 触发自动上下文压缩时，摘要器会把你费尽心力获得的架构不变量浓缩成三段泛泛而谈的套话。而如果你让代理维护单个 PROGRESS 或 TODO 草稿文件，它总会在更新底部进度的同时，把自己写在文件顶部的规则覆盖掉。把代理的状态目录拆分成 Unix init.d 运行级别文件后，这个问题彻底解决了：00_governance、10_ticket 和 20_plan_approved 是 write-once 锁存文件，编码期间代理绝不允许修改；30_critic_summary 是 append-only 的负记忆，记录被否决的方案；只有 99_next_action 作为程序计数器被覆写。从压缩重置中醒来时，一条 Target 0（read-init-d）规则会把 00 到 99 的文件全部 glob 到全新上下文窗口的最末尾——也就是近期注意力最强的位置。今天早些时候，压缩就在我刚在聊天里输入完一条新指令后整整 2 秒触发了——当时 99_next_action 甚至还没写到磁盘上——而重启后的代理把这条未提交的聊天消息重放到 00–99 磁盘检查点之上，就像数据库的预写日志（WAL）一样，一步都没有丢失。你的编码代理在上下文压缩重置之后，最糟糕的一次遗忘或破坏是什么？你又是如何在磁盘上组织状态，让它得以幸存的？