1. 这个实验到底在折腾什么先交代背景。我过去大半年一直在用 AI 编码代理做日常开发主力是 Codex 这一类命令行形态的工具配合 VS Code 插件一起用。用久了就撞上一个绕不开的墙上下文压缩。当一次会话的 token 累积到模型窗口上限代理会自动把前面的历史压成一段摘要然后带着这段摘要继续往下跑。问题就出在这里——压缩之后代理经常接不上。具体表现很典型它忘了刚才改过哪个文件、忘了你定的命名规范、忘了上一步为什么放弃某个方案甚至会把已经修好的 bug 又改回去。你不得不反复提醒它我们刚才说过……一来一回效率掉得厉害。这不是模型笨是压缩把连续性打断了。所以我给自己定了个小实验连续 10 天把每一次压缩后接不上的情况都记下来最后攒了 430 条公开记录。这篇就是把这 430 条记录拆开看聊聊 AI 编码代理在上下文压缩之后到底靠什么才能接得上。核心会围绕几个东西展开long_mem长期记忆层、engram记忆痕迹/记忆印迹这个概念、以及 Codex 这类代理的实际配置方式。先说清楚适合谁看。如果你只是偶尔用 AI 补全几行代码这篇对你价值有限但如果你已经把编码代理当成日常主力、会话动辄跑几小时、经常遇到它怎么又忘了的情况那这篇里的记录和结论应该能帮你省不少时间。全文不涉及任何网络访问类工具只聊代理本身的记忆机制和配置。430 条记录不是随便记的。我定了一个判定标准只有当代理在压缩发生后出现了可复现的上下文丢失并且这个丢失直接导致了错误操作或返工才算一条有效记录。纯粹感觉它变笨了这种主观判断一律不计。这样筛下来数据才有参考价值。2. 上下文压缩为什么会断片2.1 压缩的本质是有损摘要要理解断片得先理解压缩干了什么。模型的上下文窗口是有限的比如常见的 128K、200K token。当对话历史逼近这个上限代理不能直接把最老的消息删掉——那样会丢掉关键信息。于是它采用摘要压缩把前面一大段历史交给模型让它生成一段浓缩的摘要用这段摘要替换掉原始历史。关键点在于摘要是模型生成的是有损的。它不可能保留所有细节只能保留它认为重要的部分。而模型判断什么重要的标准和实际编码任务里什么重要的标准经常对不上。比如你随口说的一句这个项目用 pnpm 不用 npm模型可能觉得是琐碎信息给压掉了但后面它就会用 npm 装依赖直接翻车。我在记录里统计过430 条里有接近四成约 170 条的断片根源都是约束类信息被压缩丢弃。约束类信息包括包管理器选择、代码风格、目录结构约定、禁止使用的 API、必须兼容的版本等等。这些东西单看都很小但一旦丢失返工成本极高。2.2 三种典型的断片模式把 430 条记录归类之后断片基本落在三种模式里我给它起了名字方便记忆。第一种叫约束遗忘。就是上面说的压缩把项目约束丢了。典型场景你要求所有网络请求走统一的封装层压缩后代理直接裸调 fetch。这种占比最高。第二种叫进度错位。代理忘了任务进行到哪一步。比如它已经改完了 A 文件压缩后以为还没改又改一遍或者跳过了 B 文件直接去做 C。这种在长任务里特别常见占比大概三成。第三种叫决策失忆。代理忘了之前为什么排除某个方案。比如你们讨论过不用 Redis 因为部署环境不支持压缩后它又建议上 Redis。这种最气人因为等于把已经吵过的架再吵一遍。提示这三种模式不是互斥的很多断片是叠加的。比如约束遗忘往往连带进度错位因为约束丢了之后代理对当前状态的判断也跟着歪了。2.3 为什么单纯加大窗口治标不治本有人会说那就用更大窗口的模型不就行了我试过确实能推迟压缩发生的时间但治标不治本。原因有两个。一是成本。窗口越大每次请求的 token 消耗越高长会话下费用涨得很快。而且很多代理工具对超长上下文有额外限制不是你想用多大就多大。二是注意力稀释。就算窗口够大不压缩历史越长模型对早期信息的注意力越弱。这是注意力机制本身的特性不是 bug。所以哪怕不压缩跑到后面它照样会忘记开头说的话。压缩只是把这个过程提前、加剧了。所以真正的解法不是别压缩而是在压缩之外建一层不依赖上下文的记忆。这就是 long_mem 和 engram 要解决的问题。3. long_mem 与 engram给代理装一个外挂记忆3.1 long_mem 是什么解决什么问题long_mem 直译就是长期记忆。它的核心思路很简单把不该丢的信息从易失的上下文里挪到一个持久化的存储里需要的时候再取回来。打个比方。上下文窗口像你的工作台只能摊开有限的东西long_mem 像你的抽屉东西放进去不会因为工作台清理就消失。压缩发生时工作台被清空重排但抽屉里的东西还在代理需要时可以拉开抽屉找。具体到实现long_mem 通常是一个结构化的存储可能是一个本地文件、一个轻量数据库或者一个向量库。存的内容一般分几类项目约束、任务进度、关键决策、以及用户偏好。每类信息的更新时机和读取时机都不一样这个后面细说。我在实验里用的 long_mem 是一个本地 JSON 加向量检索的混合方案。JSON 存结构化的硬约束比如包管理器、目录约定向量库存语义化的软信息比如用户倾向于函数式写法。为什么混合因为硬约束需要精确命中向量检索会有误差软信息需要语义匹配纯关键词又太死板。3.2 engram 这个概念怎么理解engram 原本是神经科学里的词指记忆在神经系统中留下的物理痕迹。借用到 AI 代理语境里我把它理解为一次具体交互留下的、可被后续检索的记忆单元。和 long_mem 的区别在于粒度。long_mem 更像一个分类仓库engram 更像一条条独立的记忆碎片。每条 engram 记录一次事件什么时候、发生了什么、结论是什么。比如第 3 天用户明确要求所有日志用结构化格式理由是方便后续检索——这就是一条 engram。为什么需要 engram 这种细粒度因为很多断片不是因为丢了大类信息而是丢了某次具体交互的结论。约束遗忘里有一部分就是这种情况约束本身在 long_mem 里有但为什么定这个约束的上下文没了代理就会质疑甚至违反它。engram 补的就是这层为什么。3.3 两者怎么配合我的方案里long_mem 和 engram 是分工的。long_mem 负责当前有效状态engram 负责历史演变过程。代理每次开始新任务前先读 long_mem 拿到当前约束和进度遇到需要判断为什么这样的时候再去 engram 里检索相关历史。这个配合有个好处压缩只影响上下文不影响这两个存储。压缩发生后代理的上下文被清空重排但它启动时会自动加载 long_mem需要时检索 engram连续性就接上了。维度long_memengram粒度分类聚合单条事件内容当前有效约束、进度、偏好历史交互与决策过程更新时机约束变化时覆盖更新每次关键交互追加读取时机每次任务启动需要追溯原因时存储形式结构化 向量混合追加式日志 向量索引注意engram 是追加式的只增不改。这样能保留完整演变过程但要注意定期归档否则检索会越来越慢。我一般每 500 条做一次归档把过期的合并成摘要。4. 实操把记忆层接进 Codex 工作流4.1 环境与前置准备这部分讲具体怎么落地。前提是你已经在用 Codex 这类命令行编码代理并且能改它的配置。不同版本配置项名称可能不同我按通用思路讲你对照自己的版本调整。先准备存储目录。我在项目根目录下建了一个.agent-memory文件夹里面分三个文件constraints.json存硬约束progress.json存任务进度engram.jsonl存事件日志。用 JSONL 是因为追加方便一行一条不会因为写入中断损坏整个文件。mkdir -p .agent-memory touch .agent-memory/constraints.json touch .agent-memory/progress.json touch .agent-memory/engram.jsonl然后把这些文件加进.gitignore。为什么不提交因为记忆里可能包含你的个人偏好和临时决策提交上去会污染仓库也可能泄露一些不该公开的上下文。这个坑我踩过早期把记忆文件提交了结果同事拉下来一脸懵。4.2 约束的写入与读取约束的写入时机很关键。我的做法是只在用户明确表达约束时写入不自动推断。为什么因为自动推断容易误判把一次性的临时要求当成长期约束反而添乱。写入格式我定成这样{ package_manager: pnpm, code_style: functional, forbidden_apis: [eval, innerHTML], target_runtime: node20, updated_at: 2025-01-15T10:30:00Z }读取时机是每次任务启动时。代理开始一个新任务第一件事就是读这个文件把约束注入到系统提示里。这样即使上下文被压缩过约束依然在。这里有个细节注入的时候要明确标注这是持久约束而不是普通上下文。我试过不标注结果代理把它当成用户刚才说的话压缩时又给压掉了。标注之后代理会把它当成系统级信息优先级更高。4.3 进度的更新策略进度更新比约束复杂因为它变化频繁。我的策略是按里程碑更新不按每一步更新。比如一个任务分五个阶段每完成一个阶段更新一次而不是每改一个文件就更新。为什么因为更新太频繁写入开销大而且进度文件会变得很碎读取时反而难判断当前状态。按里程碑更新粒度刚好。进度文件长这样{ task_id: refactor-auth, current_stage: stage-3, completed: [stage-1, stage-2], next_action: migrate session storage, blockers: [need to confirm token expiry policy], updated_at: 2025-01-15T14:20:00Z }blockers这个字段特别有用。它记录当前卡住的地方压缩后代理一看就知道哦我卡在这不会重复尝试已经失败的路子。4.4 engram 的检索时机engram 不是每次都读那样太慢。我的触发条件是当代理需要做决策且 long_mem 里没有直接答案时才去检索 engram。检索用向量相似度取 top 3 相关记录注入上下文。为什么只取 3 条因为取太多会挤占上下文反而触发压缩。3 条是个平衡点实测够用。def retrieve_engram(query, top_k3): query_vec embed(query) scored [(cosine(query_vec, e.vec), e) for e in engram_store] scored.sort(reverseTrue) return [e for _, e in scored[:top_k]]提示embedding 模型建议用轻量的本地模型别用大模型 API。因为检索是高频操作走 API 延迟高、成本也高。本地小模型精度够用速度还快。5. 430 条记录里踩出来的坑5.1 记忆污染写进去的错信息比丢信息更可怕实验早期我犯过一个错让代理自动往 long_mem 里写约束。结果它把一次性的临时要求这次先用 npm 装一下写成了长期约束后面所有任务都用 npm跟项目实际用的 pnpm 冲突。这种叫记忆污染比断片还麻烦因为断片是丢信息污染是错信息错信息会持续误导。解决办法是写入必须显式确认。代理可以建议写入但最终要用户点头。我后来改成代理检测到可能的约束先问一句要把这条记为长期约束吗确认了才写。多一步交互但避免了污染。5.2 检索噪音相关不等于有用engram 检索用向量相似度但语义相似不等于对当前任务有用。我遇到过检索出来一堆看起来相关但实际没用的记录反而干扰了代理判断。改进办法是加一层时间衰减。越近的记录权重越高越老的越低。因为编码任务里近期决策通常比远期决策更相关。衰减系数我用的 0.95也就是每过一天权重乘 0.95。def score_with_decay(similarity, days_ago, decay0.95): return similarity * (decay ** days_ago)这个改动之后检索质量明显提升。430 条记录里检索噪音导致的误判从早期的十几条降到了个位数。5.3 常见问题速查表把实验里反复出现的问题整理成表方便对照排查。现象可能原因排查方向解决方式压缩后代理违反约束约束未注入或注入位置不对检查任务启动时是否读 long_mem把约束标注为系统级信息代理重复已完成的工作进度未更新或更新滞后检查 progress.json 的 updated_at按里程碑及时更新进度代理建议已排除的方案engram 未检索或检索不到检查检索触发条件放宽触发条件加时间衰减记忆文件越来越大engram 只增不归档检查文件行数每 500 条归档合并代理质疑已有约束缺为什么的上下文检查 engram 是否有对应记录补录决策原因5.4 一个容易被忽略的点压缩后的首次交互实验里有个发现压缩发生后的第一次交互是最容易断片的时刻。因为代理刚被清空上下文还没重新加载记忆。如果这时候你直接给它一个复杂任务它大概率会出错。我的应对是压缩发生后先给一个轻量确认交互比如确认一下当前任务状态让代理有机会加载 long_mem 和检索 engram然后再派重活。这个习惯养成之后断片率明显下降。6. 十天实验下来我的几点真实体会先说数据。430 条记录里引入 long_mem 和 engram 之前平均每天断片 60 多条引入之后降到每天 10 条左右。剩下的 10 条里大部分是检索噪音和记忆污染导致的纯丢信息的断片基本消失了。这个改善幅度超出我预期。但也不是没有代价。记忆层本身要维护写入要确认归档要定期做这些都是额外工作量。我的判断是如果你的会话经常跑超过一小时或者任务跨多天这套东西值得上如果只是短平快的补全没必要反而添乱。还有个体会是关于 engram 的。一开始我觉得它可有可无long_mem 够用了。但实验到第五天左右我发现很多断片不是丢约束而是丢为什么定这个约束。补上 engram 之后代理不再质疑已有决策返工明显减少。所以如果你只上一个先上 long_mem如果两个都上engram 的价值会在长任务里慢慢显现。最后分享一个小技巧。我在 engram 里专门留了一类记录叫**用户纠正**。每次我纠正代理的错误就记一条错在哪、正确是什么、为什么。这类记录在后续检索里命中率特别高因为代理犯的错往往有重复性。攒了几天之后代理自己就能避开大部分之前犯过的错。这个比单纯写约束管用因为约束是应该怎样纠正是别怎样后者对模型来说更具体、更好执行。这套方案我还在继续迭代下一步想试试把 engram 按任务类型分库减少跨任务的检索噪音。等有新结果再聊。
