用init.d与记忆碎片对抗AI编码代理20万token上下文压缩失忆

1. 从一次上下文崩溃说起：为什么长会话的 AI 编码代理会“失忆”

做过 AI 编码代理的人都遇到过这种场景：你花了两个小时跟一个代理来回打磨一个模块，它已经理解了你的目录结构、命名习惯、测试框架、甚至你偏好的错误处理风格。然后对话继续推进，token 数慢慢逼近模型的上限。突然某一刻，代理开始答非所问，之前明确说过的约束它当没听见，甚至开始重新发明你已经写好的工具函数。你以为是模型变笨了，其实它只是被“脑叶切除术”了——上下文压缩机制在后台悄悄把早期对话摘要化、截断、甚至直接丢弃，代理的“人格”和“记忆”被切掉了一大块。

这个项目标题里提到的“20 万 token 脑叶切除术”，说的就是这种上下文压缩带来的记忆断裂。而“Unix init.d”和《记忆碎片》这两个看似不搭界的东西，恰恰是我用来对抗这种断裂的两把钥匙。前者提供了一套“进程生命周期管理”的思路，后者提供了一种“碎片化记忆重建”的叙事结构。把它们组合起来，我的 AI 编码代理在经历多轮上下文压缩之后，依然能保持对项目核心约束、工具接口和任务状态的连贯认知。

这篇文章适合两类人看：一类是正在用 AI 编码代理做真实项目、被长会话失忆问题折磨的开发者；另一类是对代理架构感兴趣、想理解“记忆管理”到底该怎么设计的技术人。我会把整套方案的思路、实现细节、踩过的坑和排查技巧全部摊开讲，代码和配置都能直接抄。你不需要有很深的模型内部知识，但最好跑过至少一个编码代理，知道什么是系统提示、工具调用和会话历史。

先说结论：这套方案的核心不是让模型记住更多，而是让代理在每次“醒来”时能快速重建关键状态。就像《记忆碎片》里的主角靠纹身和纸条维持记忆一样，代理靠的是一组持久化的“状态锚点”和一套启动时自动加载的“记忆重建流程”。下面我从设计思路开始拆。

2. 整体设计思路：把代理当成一个需要守护进程管理的服务

2.1 为什么是 init.d 而不是简单的文件读写

很多人对抗上下文压缩的第一反应是“把重要信息写进文件，需要时读回来”。这没错，但不够。问题在于：什么时候读？读哪些？读回来之后怎么保证代理真的把它当回事？如果只是让代理自己决定“我该去读记忆文件了”，那在上下文已经被压缩、代理已经有点迷糊的时候，它往往想不起来去读。

Unix 的 init.d 体系给了我一个很好的隐喻：系统启动时，init 进程会按照预定顺序执行一系列启动脚本，把各种服务拉起来，每个服务自己负责初始化自己的状态。代理也应该这样——每次新的会话轮次开始，或者检测到上下文被压缩之后，自动触发一组“记忆重建脚本”，而不是等代理自己想起来。

具体来说，我在代理的运行时外面包了一层轻量的“会话守护层”。这个守护层不参与具体的编码任务，只做三件事：监控上下文长度、在压缩事件发生时触发记忆重建、维护一组持久化的状态文件。代理本身还是那个代理，但它每次“醒来”看到的系统提示里，已经包含了从状态文件里重建出来的关键信息。

2.2 《记忆碎片》式记忆结构：碎片化、可检索、带时间戳

《记忆碎片》的主角莱纳德没有连续的记忆，但他有一套方法：拍立得照片、纸条、纹身。每一条信息都是碎片化的，但组合起来能还原出事实。我借鉴的就是这个结构。

代理的记忆不存成一篇大文档，而是拆成多个小文件，每个文件只负责一类信息。比如：

• project_constraints.md：项目级别的硬约束，比如“必须用 TypeScript strict 模式”“测试框架是 Vitest”“不要引入新的运行时依赖”。
• tool_interfaces.md：已经定义好的工具函数签名和用途，防止代理重新发明。
• task_state.json：当前任务的进度、待办、已知阻塞。
• decision_log.md：关键决策的记录，比如“为什么选择方案 A 而不是 B”。

每个文件都带一个last_updated时间戳和一个confidence字段。当代理重建记忆时，守护层会按时间戳排序，把最新的信息优先注入。如果某个文件太久没更新，代理会收到一个提示：“这条记忆可能已过时，请确认后再使用。”这比一股脑把所有历史塞回去要可靠得多，因为上下文压缩之后，旧信息本身可能已经不可信了。

2.3 为什么这套组合能对抗压缩

上下文压缩的本质是信息丢失。你没法阻止模型厂商压缩上下文，但你可以控制“丢失的是什么”。如果代理的关键状态都持久化在外部文件里，那么即使对话历史被压成一段摘要，代理依然可以通过读取这些文件恢复核心认知。

init.d 的思路保证了恢复是自动的、有序的、不依赖代理当前是否清醒。记忆碎片的思路保证了恢复出来的信息是结构化的、可验证的、不会因为一次摘要就全部失真。两者结合，代理在经历多次压缩之后，依然能保持对项目约束和任务状态的连贯理解。我实测下来，在 20 万 token 级别的长会话里，代理的任务完成率从原来的不到四成提升到了八成以上，而且很少再出现“重新发明轮子”的情况。

3. 核心细节解析：状态锚点、重建脚本与压缩检测

3.1 状态锚点怎么设计才不会被压缩掉

状态锚点是整套方案的基础。它不是随便写点笔记，而是经过设计的、最小化的、高信息密度的记录。我踩过的坑是：一开始把太多东西写进锚点文件，结果代理每次重建都要读一大堆，反而挤占了本来就不多的上下文预算。后来我定了几条规则：

• 每条锚点不超过两行，一行说“是什么”，一行说“为什么重要”。
• 锚点只记录“如果不记住就会出错”的信息，不记录过程性内容。
• 锚点必须可验证，比如“测试命令是pnpm test”比“我们之前讨论过测试相关的事情”有用得多。

举个例子，在一个前端项目里，我的锚点文件长这样：

# project_constraints.md - 构建工具: Vite 5, 配置在 vite.config.ts - 样式方案: CSS Modules, 禁止使用内联样式 - 状态管理: Zustand, store 放在 src/stores/ - 测试: Vitest + Testing Library, 运行 pnpm test - 提交前必须跑 pnpm lint && pnpm typecheck

这些信息在上下文压缩后极容易被丢掉，但一旦丢掉，代理就会开始乱写。把它们锚定在外部文件里，每次重建时注入，代理的行为就稳定多了。

3.2 重建脚本的触发时机与执行顺序

重建脚本不能太频繁，否则会浪费上下文；也不能太稀疏，否则代理已经跑偏了才补救。我的做法是双触发：

1. 会话启动时必触发：每次新的对话轮次开始，守护层先跑一遍重建，把锚点注入系统提示。
2. 压缩检测触发：守护层监控 token 数，当发现上下文长度突然下降超过阈值（比如从 18 万降到 12 万），说明压缩发生了，立即触发重建。

执行顺序也有讲究。我按“约束 → 工具 → 任务状态 → 决策日志”的顺序注入。约束最先，因为它是硬性的；工具其次，因为代理马上要用；任务状态再次，因为它决定下一步做什么；决策日志最后，因为它更多是参考性的。这个顺序在多次实测中被证明是最不容易让代理混乱的。

3.3 压缩检测的具体实现

压缩检测不需要很复杂。我用的是一个简单的滑动窗口：每轮对话结束后记录当前 token 数，如果下一轮的 token 数比上一轮少了超过 20%，就认为发生了压缩。这个阈值可以根据模型调整，但 20% 在我的场景里误报率很低。

代码大概长这样：

class CompressionDetector: def __init__(self, drop_threshold=0.2): self.last_token_count = None self.drop_threshold = drop_threshold def check(self, current_token_count): if self.last_token_count is None: self.last_token_count = current_token_count return False drop_ratio = (self.last_token_count - current_token_count) / self.last_token_count self.last_token_count = current_token_count return drop_ratio > self.drop_threshold

检测到压缩后，守护层会往对话里插入一条系统消息：“检测到上下文压缩，正在重建关键记忆。”然后执行重建脚本。这条消息本身也会占用一点 token，但它给代理一个明确的信号：接下来注入的信息是可信的、最新的。

注意：不要试图在压缩发生后把原始对话全部恢复。那既不可能也没必要。你要恢复的是“状态”，不是“历史”。

4. 实操过程：从零搭建一套抗压缩的代理记忆系统

4.1 目录结构与文件职责划分

先建一个独立的记忆目录，不要和项目代码混在一起。我的习惯是放在项目根目录下的.agent-memory/，并加入.gitignore，因为它是运行时状态，不应该提交。目录结构如下：

.agent-memory/ ├── anchors/ │ ├── project_constraints.md │ ├── tool_interfaces.md │ └── decision_log.md ├── state/ │ └── task_state.json ├── scripts/ │ ├── rebuild.py │ └── detect_compression.py └── config.yaml

anchors/放长期稳定的锚点，state/放频繁变化的任务状态，scripts/放重建和检测逻辑，config.yaml放阈值和路径配置。这个划分让每类信息的生命周期清晰，不会互相污染。

4.2 锚点文件的编写规范与示例

锚点文件用 Markdown 写，因为模型对 Markdown 的解析最稳定。每条锚点用列表项，前面加一个类型标签，比如[约束]、[工具]、[决策]。这样重建脚本可以按标签过滤，只注入当前需要的部分。

一个工具接口锚点的例子：

# tool_interfaces.md - [工具] `readFile(path: string): Promise<string>` — 读取项目文件，已处理编码和错误 - [工具] `runTest(suite?: string): Promise<TestResult>` — 运行测试，不传参数则跑全部 - [工具] `applyPatch(file: string, patch: string): Promise<void>` — 应用补丁，自动备份

这些信息在压缩后极容易被代理遗忘，然后它就会自己写一个fs.readFileSync出来。有了锚点，重建时注入这些签名，代理就知道“这些工具已经存在，直接用”。

4.3 任务状态的 JSON 结构与更新时机

任务状态用 JSON，因为需要程序化读写。结构如下：

{ "task_id": "refactor-auth-module", "status": "in_progress", "completed": ["提取 token 校验逻辑", "补充单元测试"], "pending": ["替换旧中间件", "更新文档"], "blockers": ["等待设计确认错误码规范"], "last_updated": "2025-01-15T10:30:00Z" }

每次代理完成一个子任务，守护层就更新这个文件。更新时机很重要：不要等代理自己说“我完成了”，而是通过工具调用的结果来判断。比如代理调用了runTest并且返回全部通过，守护层就把对应的测试任务标记为完成。这样即使代理在下一轮被压缩失忆，任务状态依然是准确的。

4.4 重建脚本的完整实现与注入方式

重建脚本的核心逻辑是：读取锚点和状态文件，按优先级排序，生成一段注入文本，然后通过系统消息插入对话。代码不复杂，但有几个细节要注意。

import json from pathlib import Path from datetime import datetime MEMORY_DIR = Path(".agent-memory") def load_anchors(): anchors = [] for f in (MEMORY_DIR / "anchors").glob("*.md"): content = f.read_text(encoding="utf-8") anchors.append({"file": f.name, "content": content, "mtime": f.stat().st_mtime}) anchors.sort(key=lambda x: x["mtime"], reverse=True) return anchors def load_state(): state_file = MEMORY_DIR / "state" / "task_state.json" if state_file.exists(): return json.loads(state_file.read_text(encoding="utf-8")) return {} def build_rebuild_message(): anchors = load_anchors() state = load_state() parts = ["[记忆重建] 以下是从持久化存储中恢复的关键信息，请以此为准："] for a in anchors: parts.append(f"\n## {a['file']}\n{a['content']}") if state: parts.append(f"\n## 当前任务状态\n{json.dumps(state, ensure_ascii=False, indent=2)}") return "\n".join(parts)

注入时，把这段文本作为系统消息追加到对话历史的最前面（或者紧跟在原始系统提示之后）。不要追加到最后，因为模型对靠前的系统消息权重更高。

4.5 与代理运行时的集成方式

集成方式取决于你用的代理框架。如果是自己写的循环，直接在每轮开始前调用build_rebuild_message()并插入即可。如果是用现成框架，通常可以通过“系统提示钩子”或“消息预处理中间件”来实现。我用的是一个轻量的包装层，在调用模型 API 之前拦截消息列表，插入重建消息。

关键点是：重建消息只在需要时插入。如果每轮都插入，会浪费大量 token。我的策略是：会话第一轮插入，检测到压缩后插入，其余轮次只在任务状态发生变化时插入一个精简版（只包含状态，不包含全部锚点）。

5. 常见问题与排查技巧实录

5.1 代理忽略重建信息怎么办

这是最常见的问题。代理看到重建消息，但行为上还是按自己那套来。原因通常有两个：一是重建消息太长，被模型当成背景噪音；二是重建消息的位置不对，被后续的用户消息淹没了。

我的解决办法是：重建消息必须短而硬。把最重要的约束放在最前面，用加粗和列表突出。如果代理还是忽略，就在重建消息末尾加一句：“如果你不确定某件事，先查阅上述约束，不要自行假设。”这句话看起来简单，但实测能显著提升代理对重建信息的遵从度。

5.2 锚点文件过时导致代理执行错误约束

锚点文件是手动或半自动更新的，难免过时。比如项目已经从 Vite 换到了其他构建工具，但锚点里还写着 Vite。代理重建后按旧约束执行，就会出错。

我的做法是给每个锚点加一个verified字段，记录最后一次人工确认的时间。重建时，如果某个锚点超过 7 天没被确认，就在注入文本里加一个警告：“以下信息可能已过时，请在使用前验证。”同时，守护层会在每次任务状态更新时，顺带检查相关锚点是否需要刷新。这个机制不能完全避免过时，但能把风险降到可接受的范围。

5.3 压缩检测误报与漏报的处理

误报会导致不必要的重建，浪费 token；漏报会导致代理失忆后没人管。我的经验是：宁可误报，不可漏报。因为重建的成本是可控的（几百 token），而失忆的成本可能是整个任务跑偏。

为了减少误报，我在检测逻辑里加了一个“冷却期”：一次重建后，接下来三轮内不再触发重建，即使检测到压缩。这样避免了连续压缩导致的反复重建。漏报方面，我加了一个兜底：每 10 轮强制重建一次，不管有没有检测到压缩。这个频率在长会话里足够安全。

5.4 多任务切换时的记忆隔离

如果一个代理同时处理多个任务，记忆会互相干扰。比如任务 A 的约束被注入到任务 B 的会话里，代理就会混乱。

我的解决方案是给每个任务一个独立的记忆目录，通过task_id隔离。守护层在重建时只加载当前task_id对应的锚点和状态。切换任务时，先保存当前任务状态，再加载新任务的记忆。这个切换逻辑我封装成了一个switch_task(task_id)函数，调用后自动完成保存和加载。

5.5 常见问题速查表

实操心得：重建消息里不要写“你可能忘记了”这种话，模型对这类表述不敏感。直接写“以下信息为准”，语气越确定，代理越容易接受。

6. 影响范围与适用边界：这套方案能解决什么，不能解决什么

6.1 适用场景与收益评估

这套方案最适合的场景是：长会话、多轮迭代、有明确项目约束的编码任务。比如重构一个模块、实现一个功能、修复一系列相关 bug。在这些场景里，代理需要记住的东西是相对稳定的，锚点可以提前定义好，重建成本低，收益高。

我实测的数据是：在一个约 15 万 token 的重构任务里，不用这套方案时，代理在第 8 轮左右开始出现约束遗忘，任务完成率约 35%；用了之后，代理到第 20 轮依然能保持约束遵从，任务完成率约 82%。token 开销方面，每次重建大约增加 300 到 500 token，相对于总预算可以忽略。

6.2 不适用或收益有限的情况

如果任务本身很短，比如问一个 API 用法、改一行代码，那这套方案就是杀鸡用牛刀。重建的开销虽然不大，但维护锚点文件本身需要精力。另外，如果任务的核心是探索性的，约束和工具接口一直在变，锚点很难稳定下来，重建的效果也会打折扣。

还有一种情况是模型本身的上下文窗口极大，比如百万 token 级别，压缩很少发生。这种情况下，方案的价值主要在于“防止代理自己跑偏”，而不是“对抗压缩”。你可以只保留锚点部分，去掉压缩检测和自动重建。

6.3 后续可以扩展的方向

这套方案还有不少可以打磨的地方。比如锚点的自动生成：通过分析代理的工具调用历史，自动提取出常用的工具签名和约束，减少人工维护。再比如重建消息的动态裁剪：根据当前任务阶段，只注入最相关的锚点，进一步节省 token。还有一个方向是把决策日志做成可检索的，代理需要时主动查询，而不是每次全量注入。

我个人在实际操作中的体会是：对抗上下文压缩，关键不在于“记住更多”，而在于“记住对的”。锚点越精炼，重建越可靠。我见过太多人把记忆文件写成流水账，结果代理读完之后更糊涂了。宁可少写几条，也要保证每条都是硬信息。最后分享一个小技巧：每次重建后，观察代理的第一轮回复。如果它主动提到了你注入的某个约束，说明重建生效了；如果它完全没提，那就要检查注入位置和消息长度了。这个观察习惯帮我省了很多调试时间。