AI编码代理上下文压缩失忆难题：用init.d与记忆碎片思路构建持久化记忆

1. 当上下文被压缩代理为什么会“失忆”做过 AI 编码代理的人都遇到过一个很具体的场景你花了两小时把项目背景、目录结构、编码规范、历史踩坑记录一点点喂给代理它终于能稳定地帮你改代码了。然后对话继续推进token 数一路涨到十几万系统触发上下文压缩把前面的内容摘要成一小段。下一秒代理开始胡言乱语——它忘了项目用的是哪个测试框架忘了某个模块不能动甚至把之前明确否定的方案又提了一遍。这个现象我把它叫做“脑叶切除术”。上下文压缩本意是好的它要在有限的窗口里塞进尽可能多的信息但代价是把那些看起来“冗余”、实际上承载着关键约束的细节给切掉了。代理的短期记忆被重置而它自己并不知道自己被重置了。标题里提到的两个东西一个是 Unix 的 init.d一个是电影《记忆碎片》。这两个看似毫不相干的概念恰好对应了解决这个问题的两条思路init.d 代表“进程启动时自动加载的持久化配置”《记忆碎片》代表“主角靠纹身和纸条对抗失忆”。把这两者结合起来就能让 AI 编码代理在上下文被反复压缩的情况下依然保持对核心约束的记忆。这篇文章适合两类人看一类是正在用 AI 代理做实际项目、被上下文丢失折磨过的开发者另一类是想理解“代理记忆管理”这个问题的技术爱好者。我会把整套方案的思路、实现细节、踩过的坑都摊开讲代码和配置都能直接抄。2. 问题拆解上下文压缩到底切掉了什么2.1 压缩不是删除是“有损摘要”很多人以为上下文压缩就是把旧消息删掉其实不是。主流实现通常是让模型对早期对话做一次摘要用几百 token 概括几千 token 的内容。问题就出在这个“概括”上。摘要模型判断什么是重点依据的是“这段内容在语义上是否重要”而不是“这段内容对当前任务是否关键”。举个例子你在对话早期说过一句“这个项目的数据库迁移脚本必须手动执行不能放进 CI”这句话在语义上平平无奇摘要时很容易被合并成“讨论了数据库相关事项”。但对代理来说这条约束一旦丢失它下次就可能自动帮你跑迁移直接把生产库搞乱。我实测过几次压缩后丢失的信息大致集中在三类否定性约束“不要做 X”、环境特定的配置路径、端口、密钥位置、以及历史决策的原因“当初为什么选 A 不选 B”。这三类恰好都是代理执行任务时最需要的。2.2 代理的“失忆”和人的失忆不一样人的失忆是记忆没了但知道自己忘了。代理的问题是它不知道自己忘了。压缩之后代理拿到的是一份“看起来完整”的上下文它会理所当然地认为自己掌握了全部信息然后基于残缺的信息自信地做决策。这就像《记忆碎片》里的主角他每隔一段时间记忆就重置但他学会了用拍立得照片和纹身把关键信息固化下来。每次“醒来”他先看纹身再看照片就能恢复行动能力。我们要给代理做的就是同一件事把关键约束从易失的对话上下文里搬到不易失的外部存储里并且在每次任务开始前强制加载。2.3 为什么不能简单地把窗口开大有人会说那就用更大窗口的模型不就行了。这个思路有两个问题。第一窗口再大也有上限20 万 token 听起来很多但一个中等规模项目的完整上下文加上多轮对话很容易就顶到天花板。第二就算窗口够大长上下文本身也会带来注意力稀释的问题模型对中间部分的关注度会下降这在业界已经有不少讨论。所以正确的方向不是“避免压缩”而是“让压缩变得无害”。核心思路是把代理真正需要长期记住的东西从对话流里剥离出来放到一个压缩碰不到的地方。3. 核心思路用 init.d 的思路给代理做“纹身”3.1 init.d 给我们的启发Unix 系统启动时init 进程会按顺序执行 /etc/init.d/ 目录下的脚本把各种服务拉起来。这些脚本的特点是它们是文件持久存在于磁盘上每次启动都会被读取执行不依赖任何“上一次运行时的内存状态”。把这个模式搬到 AI 代理上就是不要让代理依赖对话历史来记住约束而是把约束写成文件在每次任务开始时读取。对话可以被压缩、被清空、甚至换一个全新的会话只要这些文件还在代理就能恢复到“知道所有关键约束”的状态。3.2 《记忆碎片》给我们的启发电影里主角的纹身有几个特点极简、只记最关键的、按重要性排列。他不会把每天吃了什么纹在身上只纹“不要相信某某”这种生死攸关的信息。对应到代理的持久化记忆就是不要试图把所有对话都存下来那样等于没存。要提炼出真正关键的、跨会话不变的约束用最紧凑的形式写下来。一份好的“代理纹身”应该控制在几百 token 以内这样每次加载的成本极低而且不会挤占正常任务的上下文空间。3.3 整体架构我把这套方案分成三层层级作用存储位置生命周期纹身层跨会话不变的硬约束项目根目录的固定文件永久照片层当前任务的进度和决策任务专属的进度文件单任务对话层正常的交互上下文模型上下文窗口易失纹身层是核心它解决“代理忘了项目基本规则”的问题。照片层解决“代理忘了这个任务做到哪了”的问题。对话层就是正常干活的地方被压缩了也无所谓因为关键信息都在前两层。4. 实操把约束写成代理能读懂的“纹身”4.1 纹身文件该放哪、叫什么我习惯在项目根目录建一个.agent/目录里面放几个固定文件。为什么不直接放根目录因为根目录容易被各种工具扫描放子目录更干净也方便加进版本控制。.agent/ constraints.md # 硬约束代理绝对不能违反的 context.md # 项目背景代理需要知道的基本信息 decisions.md # 历史决策记录为什么这么做 progress/ # 每个任务的进度文件 task-001.mdconstraints.md是最重要的它对应“纹身”。context.md和decisions.md对应“照片”信息量大一些但也是持久化的。progress/目录下的文件是任务级的做完一个任务可以归档。4.2 constraints.md 怎么写才有效这份文件的目标是让代理在 30 秒内读完并记住所有红线。写法上有几个要点。第一用祈使句不要用描述句。写“禁止修改config/prod.yaml”不要写“config/prod.yaml是一个生产环境配置文件”。前者是命令后者是信息代理对命令的执行率明显更高。第二每条约束单独一行前面加编号。编号让代理在引用时能精确指代比如“根据约束 3我不能这么做”。第三把最危险的约束放最前面。代理读文件也是从头读的虽然理论上都会读但前面的内容权重更高。一个实际的例子# 硬约束 1. 禁止修改 config/prod.yaml 和 config/staging.yaml 2. 禁止在测试中使用真实数据库必须用 test/fixtures 下的 mock 3. 所有新增 API 必须带 rate limit 装饰器 4. 禁止删除 migrations/ 下的任何文件只能新增 5. 提交前必须跑 make lintlint 不过不许提交 6. 涉及金额计算的代码必须用 decimal禁止用 float这六条加起来不到 200 token但每一条都是踩过坑才写上去的。第 6 条就是有一次代理用 float 算金额测试数据碰巧没暴露精度问题上线后对账差了三分钱查了一下午。4.3 怎么让代理每次都读这些文件光有文件不够得让代理在每次任务开始时主动加载。有两种做法。一种是在系统提示词里写死“每次开始新任务前先读取.agent/constraints.md和.agent/context.md”。这种做法简单但依赖代理听话。更可靠的做法是做一个包装脚本代理的所有操作都通过这个脚本走脚本在调用模型之前自动把纹身文件的内容拼进提示词。这样即使代理“想偷懒”也绕不过去。import pathlib def build_system_prompt(project_root: str) - str: agent_dir pathlib.Path(project_root) / .agent parts [] for name in [constraints.md, context.md, decisions.md]: f agent_dir / name if f.exists(): parts.append(f## {name}\n\n{f.read_text(encodingutf-8)}) return \n\n.join(parts)这个函数每次构建提示词时都重新读文件所以你在文件里改了约束下一个任务立刻生效不需要重启任何东西。这就是 init.d 的精髓配置在磁盘上启动时读取改了下次启动就生效。4.4 照片层任务进度文件怎么维护纹身层解决的是“跨会话不变的约束”但一个具体任务做到一半被压缩了代理还需要知道“这个任务做到哪了”。这就是进度文件的作用。我让代理在开始一个任务时先在.agent/progress/下建一个文件格式固定# 任务给用户模块加导出功能 ## 目标 支持把用户列表导出为 CSV 和 Excel ## 已完成 - [x] 设计导出接口签名 - [x] 实现 CSV 导出 ## 进行中 - [ ] 实现 Excel 导出用了 openpyxl卡在样式设置 ## 待办 - [ ] 写测试 - [ ] 更新 API 文档 ## 关键决策 - 选择 openpyxl 而不是 xlsxwriter因为需要读取现有模板每次代理完成一个子步骤就更新这个文件。上下文被压缩后代理只要重新读这个文件就能立刻恢复状态。这个文件本身也是持久的不随对话消失。5. 让压缩“无害”的关键细节5.1 压缩触发时主动做一次“记忆固化”被动等待代理去读文件不如在压缩发生前主动固化一次。大多数代理框架都提供了压缩事件的钩子可以在压缩前插入一段逻辑把当前对话里的关键信息提炼出来追加到进度文件或决策文件里。具体做法是在压缩钩子里调用一次模型提示词大概是“以下是即将被压缩的对话请提取其中所有否定性约束、环境配置、以及做出的决策用简洁的列表输出。”然后把输出追加到.agent/decisions.md。这一步的成本很低一次调用几百 token但能极大降低信息丢失的概率。我实测下来加了这一步之后压缩导致的“代理犯傻”次数下降了大概七成。5.2 纹身文件要定期“瘦身”纹身文件不是越大越好。如果 constraints.md 涨到几千 token每次加载都会挤占正常任务的上下文而且代理对长列表的遵守率会下降。我的做法是每个月过一遍 constraints.md把已经通过其他机制保证的约束删掉。比如某条约束“禁止用 float 算金额”如果项目里已经加了 lint 规则自动检查那这条就可以从纹身文件里移除因为 lint 会兜底。这就像《记忆碎片》里主角不会把所有事都纹上只纹最关键的。纹身太多反而看不清。5.3 用“引用”代替“复制”有时候约束很长比如一段完整的 API 规范。这时候不要在纹身文件里复制全文而是写一个引用“API 规范见 docs/api-spec.md所有新增接口必须符合该规范。”代理看到引用会在需要时去读那个文件。这样纹身文件保持精简详细信息放在该放的地方。这个思路和 init.d 里脚本引用外部配置文件是一样的。6. 常见问题与排查技巧6.1 代理读了纹身文件但还是违反约束先检查文件格式。如果 constraints.md 里混了大量描述性文字代理可能会把约束当成“背景信息”而不是“命令”。解决办法是把约束和背景分开constraints.md 里只放祈使句。再检查加载时机。如果纹身文件是在对话中途才加载的代理可能已经基于旧上下文做了决策。确保它在每次任务开始时加载而不是中途补。6.2 进度文件更新不及时这是最常见的问题。代理干着干着就忘了更新进度文件等压缩发生时才想起来但信息已经丢了。我的解决办法是在包装脚本里加一个检查每次代理调用工具比如写文件、跑命令之后检查进度文件的修改时间如果超过一定轮次没更新就在下一次提示词里加一句提醒。这个机制有点像定时提醒但触发条件是“操作次数”而不是“时间”。6.3 多个任务并行时进度文件冲突如果一个代理同时处理多个任务进度文件要按任务分开不能共用一个。我在.agent/progress/下用任务 ID 命名文件代理在开始任务时生成一个 ID后续所有进度都写到对应文件。如果多个代理实例并行还要考虑文件锁的问题。简单做法是每个实例用独立的进度目录最后再合并。复杂做法是加文件锁但一般项目用不上。6.4 压缩后代理“假装”记得有时候代理会表现得很自信说“根据之前的讨论我们应该……”但实际上它已经忘了。这种“假装记得”比直接说“我忘了”更危险。识别方法是让它复述关键约束。在任务开始前让它先输出一遍 constraints.md 的内容摘要。如果摘要和文件对不上说明它没真正加载。这个检查可以做成自动的摘要不匹配就重新加载。6.5 速查表现象可能原因排查方向代理违反硬约束纹身文件格式不对或未加载检查文件是否为祈使句、加载时机是否正确压缩后状态丢失进度文件未及时更新检查更新触发机制、增加操作后提醒代理假装记得上下文残留导致误判要求复述关键约束、做一致性校验纹身文件失效文件过大导致遵守率下降定期瘦身、用引用代替复制多任务混乱进度文件未隔离按任务 ID 分文件、并行时用独立目录7. 我在实际项目里踩过的几个坑第一个坑是纹身文件写得太“温柔”。早期我写的是“建议不要修改生产配置”结果代理该改还是改。改成“禁止修改”之后遵守率立刻上来了。措辞的强硬程度直接影响执行率这点和跟人沟通是一样的。第二个坑是进度文件写得太细。一开始我让代理把每一步操作都记下来结果文件迅速膨胀到几千行代理读它比读对话还费劲。后来改成只记“目标、已完成、进行中、待办、关键决策”五个部分每个部分控制在几行效果好很多。第三个坑是忘了给纹身文件加版本控制。有一次我改了 constraints.md但没提交换了个环境跑代理它读的是旧版本行为不一致排查了半天才发现是文件没同步。现在.agent/目录是强制纳入版本控制的。第四个坑是过度依赖自动固化。压缩钩子里的提炼调用偶尔会漏掉关键信息尤其是那些表述比较隐晦的约束。所以我现在是自动固化加人工抽查每周过一遍 decisions.md看有没有漏掉的。这套方案跑了大半年代理在长任务里的稳定性明显提升。最直观的感受是以前一个任务做到后半段经常要重新解释背景现在基本不需要了。上下文压缩依然会发生但它不再是一次“脑叶切除术”而更像是一次普通的换页——代理看一眼纹身继续干活。