1. 这个实验到底在折腾什么先把背景交代清楚。AI 编码代理AI Coding Agent这类工具比如 Codex 这类命令行形态的编码助手本质上是把大模型塞进一个能读写文件、执行命令、跑测试的循环里。它跟你聊天不一样它要在一个会话里连续做几十甚至上百步操作读文件、改代码、跑测试、看报错、再改。问题就出在这里——模型的上下文窗口是有限的。你让它干一个稍微大点的活比如重构一个模块、修一个跨文件的 bug它读进来的文件内容、命令输出、历史对话会迅速把上下文塞满。塞满之后怎么办绝大多数工具的做法是上下文压缩context compaction把前面的历史总结成一段短摘要丢掉原始细节腾出空间继续干活。这个思路听起来合理但实际用起来你会发现一个很别扭的现象压缩之后代理好像失忆了。它忘了自己刚才改了哪个文件、为什么这么改、之前试过什么方案失败了。于是它开始重复劳动或者做出跟前面决策矛盾的操作。这个实验就是冲着这个问题去的——上下文压缩之后AI 编码代理怎么接得上实验周期 10 天累计 430 条公开记录。这个量级不算大但足够看出一些规律。我把它拆成几个层面来讲为什么会断片、断片的具体表现、有哪些接续策略、每种策略的实测效果以及我自己在复现过程中踩到的坑。适合谁看如果你正在用或者准备用 Codex 这类编码代理做实际项目尤其是那种单次任务超过二三十步的活这篇内容对你有直接参考价值。如果你只是拿它写写小函数可能感受不深但了解一下机制也没坏处。关键词里出现了 long_mem 和 engram这两个是实验里涉及的长记忆机制方向。long_mem 顾名思义是长时记忆engram 这个词借用了神经科学里记忆痕迹的概念指的是把关键信息以某种持久化形式存下来供后续会话或压缩后的会话调用。这两个是解决接不上问题的核心抓手后面会展开。2. 上下文压缩为什么会造成断片2.1 压缩的本质是有损摘要要理解断片先得理解压缩干了什么。假设代理已经跑了 40 步上下文里堆了这些东西用户最初的指令把这个模块的同步 IO 改成异步它读过的 8 个文件的完整内容它执行的 15 条命令及其输出它做过的 6 次文件修改中间几次失败的尝试和报错压缩的时候工具会调用模型把这些内容总结成一段几百字的摘要。摘要里通常保留目标是什么大致做了什么当前状态如何但会丢掉大量细节具体改了哪一行、某个报错的确切信息、某个文件里那个关键的变量名。这就像你让一个同事接手你干到一半的活你只给他留了张便利贴在改登录模块改成异步了还没测完。他拿到这张纸条能接着干吗勉强能但大概率会重新读一遍代码甚至重新踩一遍你已经踩过的坑。2.2 断片的三种典型表现430 条记录里压缩后的异常行为大致能归成三类我按出现频率排表现类型具体现象占比实验记录粗估重复劳动重新读取已读过的文件、重新执行已跑过的命令最高决策矛盾推翻自己之前的修改或采用与之前冲突的方案中等目标漂移逐渐偏离原始任务开始做无关的优化较低但危害大重复劳动最好理解也最容易被忽略——因为它不报错只是慢。代理压缩后忘了自己读过某个文件又读一遍token 和时间都浪费了。决策矛盾更麻烦比如它之前决定用方案 A 因为方案 B 有兼容性问题压缩后忘了又切回方案 B结果引入 bug。目标漂移最隐蔽代理干着干着开始顺手重构别的代码最后交付的东西跟你要的偏了。2.3 为什么单纯加大窗口不是答案有人会说那就用大窗口模型别压缩不就行了。实测下来这条路走不通原因有两个。第一窗口再大也有上限而且成本和延迟随上下文长度非线性增长。一个任务跑到 100 步以上再大的窗口也会满。第二就算窗口够大长上下文本身会带来注意力稀释——模型在超长上下文里对中间部分的关注度下降这跟压缩造成的丢失是两码事但结果类似都是记不住关键细节。所以压缩是绕不开的问题不是要不要压缩而是压缩之后怎么把关键信息接回来。这就是 long_mem 和 engram 这类机制要解决的事。3. 接续策略的四种思路与实测对比实验里试了不止四种但能形成清晰对比、有复现价值的主要是下面这四类。我按实现成本从低到高排。3.1 策略一结构化摘要模板最朴素的做法是约束压缩时生成的摘要格式。不让模型自由发挥写一段话而是强制它按固定字段填任务目标: ... 已完成: ... 当前文件状态: ... 关键决策及原因: ... 待办: ... 已知坑: ...这个模板的关键在于关键决策及原因和已知坑两栏。普通摘要往往只记做了什么不记为什么和什么不行。而代理断片最致命的恰恰是丢了这两类信息。实测效果重复劳动明显减少因为已完成栏让它知道自己读过哪些文件。但决策矛盾只改善了一部分因为摘要终究是摘要字段填得再全细节还是会丢。这个策略胜在零额外依赖改个 prompt 就能上适合作为基线。3.2 策略二外部记忆文件long_mem 思路这是 long_mem 方向的核心做法不把记忆塞进上下文而是写到外部文件里需要时再读回来。具体操作是让代理在干活过程中维护一个MEMORY.md或者.agent/memory.json每完成一个关键步骤就追加一条记录改了什么文件、为什么改、验证结果如何。压缩发生时上下文里的历史被丢掉但外部文件还在。压缩后代理被指示先读这个记忆文件把状态接回来。这个思路的好处是记忆不受上下文窗口限制理论上可以无限长。坏处是它依赖代理自觉去写和读如果它忘了写或者压缩后忘了读机制就失效了。实验里为了降低这种依赖把写记忆和读记忆做成了工具调用在流程里强制插入而不是靠模型自觉。3.3 策略三engram 式关键片段锚定engram 这个思路更精细一点。它不记录全部历史而是识别出记忆痕迹——那些对后续决策有决定性影响的片段把它们原样保留而不是摘要。哪些算关键片段实验里总结了几类用户原始指令的原文不能摘要一摘要就变味失败的尝试及其报错原文防止重蹈覆辙接口签名、数据结构定义这类契约信息当前正在编辑的文件的完整内容这些片段被锚定在上下文里压缩时跳过它们。剩下的可压缩部分再摘要。这样上下文里始终保留着一小撮高价值原文接续时就有据可依。实测下来这个策略对决策矛盾的改善最明显因为失败原因和契约信息都是原文保留的。代价是它占用的上下文比纯摘要多压缩频率会略高。3.4 策略四分层记忆 检索召回最复杂的一种把记忆分成三层工作层当前正在处理的文件、最近的命令输出全量保留会话层本次会话的结构化摘要压缩时生成长期层跨会话的项目知识持久化存储按需检索压缩后代理先从会话层恢复本次任务状态再根据当前操作从长期层检索相关历史。检索用简单的关键词匹配或向量相似度都行实验里用的是关键词加文件路径匹配够用。这个策略效果最好但实现成本也最高需要一套检索逻辑和存储管理。适合把它做成团队内部工具的场景。3.5 四种策略横向对比策略实现成本重复劳动改善决策矛盾改善目标漂移改善适用场景结构化摘要模板极低明显部分弱快速上手、个人使用外部记忆文件低明显明显中等单会话长任务engram 锚定中明显最明显中等决策密集任务分层记忆检索高明显明显明显跨会话、团队协作实验里最终采用的是结构化摘要 engram 锚定的组合因为它在成本和效果之间平衡得最好。外部记忆文件作为补充分层检索只在跨会话场景才启用。4. 实操把接续机制搭起来这一节讲具体怎么落地。我按实验里的配置复现了一遍把关键步骤和参数记下来。4.1 环境与工具准备实验用的是 Codex 这类命令行编码代理。安装和配置这块网上教程很多但有几个点容易卡住我列一下。安装完成后配置文件通常在用户目录下的隐藏文件夹里。配置项里有个常见的报错是codex is ignoring 1 unrecognized configuration setting意思是配置文件里有个它不认识的字段被忽略了。这不影响运行但说明你的配置项名字写错了或者版本不匹配建议对照当前版本的文档核对字段名。另一个高频问题是模型不支持报错类似the gpt-5.6-sol model is not supported when using codex with a...。这通常是模型名写错或者该模型没有开放给当前接口。解决办法是换成配置里明确支持的模型名别自己臆造。提示配置改动后建议先用一个最小任务跑通比如让它读一个文件并总结确认代理能正常启动和调用工具再去跑长任务。长任务跑到一半发现配置有问题排查成本高得多。4.2 结构化摘要模板的落地在代理的系统提示或项目级指令文件里加入压缩摘要的格式约束。核心是让它在生成摘要时按固定字段输出。我用的模板大致是这样## 任务状态摘要 - 原始目标: 用户最初要求的原文不要改写 - 已完成步骤: 逐条列出含文件名 - 当前编辑文件: 路径 当前状态 - 关键决策: 决策内容 原因 - 失败尝试: 尝试内容 报错原文 - 待办事项: 下一步计划注意原始目标这一栏要求保留原文。这是 engram 思路的体现——用户指令一旦被摘要改写很容易丢失约束条件比如不要引入新依赖这种要求摘要时经常被漏掉。4.3 engram 锚定片段的识别规则哪些内容必须原样保留、不参与压缩需要一套明确规则否则模型自己判断会不稳定。实验里用的规则用户消息的原文全部保留最近一次失败的完整报错保留当前编辑文件的完整内容保留接口定义、类型声明、配置文件的关键段落保留其余历史可压缩这套规则可以直接写进代理的指令里。实测下来规则越具体模型执行越稳定。模糊的保留重要信息这种说法基本没用模型对重要的判断跟你不一致。4.4 外部记忆文件的读写时机如果采用外部记忆文件关键是确定什么时候写、什么时候读。实验里的做法写每完成一个原子步骤一次文件修改 一次验证后追加一条读每次压缩发生后强制读一次清理任务结束时归档不删除供跨会话检索记忆文件的格式用 JSON Lines 比较方便一行一条追加写入不用重写整个文件{ts: day3-1420, action: edit, file: src/auth.js, reason: 改同步为异步, result: 测试通过} {ts: day3-1435, action: fail, cmd: npm test, error: timeout in auth.spec.js:42}这种格式的好处是机器好解析人也好读。压缩后代理读这个文件几行就能把状态接回来。4.5 参数与阈值的选择压缩什么时候触发这个阈值要调。设得太早压缩频繁接续开销大设得太晚上下文快满了才压缩容易触发失败。实验里用的经验值是当上下文使用率达到70% 到 75%时触发压缩。留出 25% 左右的空间给压缩后的接续操作和后续几步。这个值不是死的任务越复杂、单步输出越大越应该提前压缩。另外engram 锚定片段的总长度要设上限否则锚定太多等于没压缩。实验里控制在上下文窗口的20% 以内。超了就按优先级砍优先级从高到低用户原文 当前文件 失败报错 契约信息。5. 常见问题与排查实录这部分是实验记录里最有价值的部分都是实际跑出来的问题。5.1 压缩后代理假装记得一个很隐蔽的现象压缩后你问代理你刚才改了什么它能答上来但答的是摘要里的内容不是真实细节。比如摘要写修改了认证逻辑它就说我修改了认证逻辑但你追问改的哪个函数它就编一个。这种假装记得比明确说我忘了更危险因为它会基于错误记忆继续操作。排查方法压缩后让它复述当前编辑文件的具体内容或者让它指出某个关键函数的位置。如果答得含糊或者跟实际不符说明接续没成功需要手动干预把关键信息重新喂给它。5.2 记忆文件写入失败或重复外部记忆文件偶尔会出现写入失败尤其是在代理同时操作多个文件的时候。还有一种情况是重复写入同一步骤记了两遍导致读回来时状态混乱。解决办法是给记忆写入加一个简单的去重写入前检查最后一条记录如果 action 和 file 都相同且时间接近就跳过。这个逻辑可以放在工具层做不用依赖模型判断。5.3 锚定片段挤占过多空间engram 锚定用久了锚定片段会越积越多因为当前文件会变旧文件如果没及时释放就一直占着。实验里踩过这个坑跑到后面上下文里全是历史文件内容压缩等于没压。规则是锚定片段要跟着当前编辑文件走切换文件时释放旧的。失败报错也是同一个错误解决后就释放不用一直留着。5.4 常见问题速查表问题现象可能原因处理方式压缩后重复读同一文件摘要未记录已读文件检查摘要模板已完成栏决策前后矛盾关键决策原因丢失启用 engram 锚定决策记录代理答非所问、编造细节接续失败基于摘要臆测手动重喂关键信息记忆文件读回状态混乱重复写入或写入失败加去重逻辑校验写入压缩后上下文仍很满锚定片段未释放检查锚定释放规则配置报 unrecognized setting字段名错误或版本不符对照版本文档核对模型不支持报错模型名错误或未开放换用配置支持的模型名5.5 几条踩坑心得第一别指望模型自觉。所有应该写记忆应该读记忆的环节都要做成流程里的强制步骤靠提示词约束的可靠性远不如靠工具调用约束。第二摘要模板的字段宁少勿多。字段太多模型填的时候会敷衍反而丢信息。实验里从最初的 9 个字段砍到 6 个效果反而更好。第三压缩阈值要按任务类型调。纯代码修改类任务可以晚点压因为输出相对规整涉及大量命令输出和报错的任务要早点压因为这类内容占空间快。第四测试接续机制本身要用长任务。短任务根本触发不了压缩你测不出问题。实验里专门构造了一个需要 50 步以上的重构任务来验证。6. 这套机制还能怎么扩展实验结束后我一直在想这套接续机制的价值不止于单个代理会话。几个可以往下走的方向一是跨会话记忆。现在记忆文件是会话级的任务结束就归档了。如果把它做成项目级的长期记忆下次开新会话时先加载代理就能记得这个项目之前发生过什么。这对长期维护同一个代码库的场景很有用。二是多代理共享记忆。如果同时跑多个代理处理不同模块让它们共享一份记忆文件就能避免互相踩脚。比如代理 A 改了接口代理 B 通过记忆文件知道这个变更就不会按旧接口写代码。三是记忆的自动清理与压缩。记忆文件长期积累也会变大需要一套归档和摘要机制把久远的、不再相关的记录压缩掉只留关键决策和契约信息。engram 锚定的规则也可以更智能。现在是人工定规则未来可以根据这条信息后续被引用了几次来动态判断重要性被引用多的自动升级为锚定片段。我个人在实际复现中的体会是这套东西的核心不在于技术多复杂而在于把记忆这件事从模型的隐式行为变成显式的、可检查的流程。模型记不记得住你控制不了但记忆文件写没写、锚定片段留没留你能控制。把不可控的东西变成可控的这才是接续机制真正的价值所在。