1. 为什么压缩之后接不上是个真问题先把场景说清楚。现在用 AI 编码代理写代码的人越来越多一个典型的工作流是这样的你给它一个任务它开始读文件、跑命令、改代码、看报错、再改来回几十轮。这个过程中对话历史会迅速膨胀——读进来的文件内容、命令输出、diff、报错栈全是 token。等到上下文窗口快满了系统就得做上下文压缩context compaction把前面几十轮的原始记录揉成一段摘要丢掉细节腾出空间继续干活。问题就出在这儿。压缩本身不难难的是压缩完之后代理还能不能接得上。我见过太多这样的情况压缩前它已经定位到src/parser.ts第 142 行有个边界条件写错了压缩后摘要里只剩一句正在修复解析器的问题然后它转头去读了一个完全不相干的文件或者把已经改好的代码又改回去一遍。这不是模型笨是压缩把工作状态和任务状态一起压没了。这个实验的标题里给了两个关键数字10 天、430 条公开记录。这说明它不是拍脑袋写的经验帖而是有人真的跑了一段时间、把过程记录下来了。关键词里的long_mem、engram指向的是长期记忆这条技术路线Codex则是当前最常被拿来讨论的编码代理之一。所以这篇要聊的核心就一件事上下文被压缩之后代理靠什么把断掉的线接回来。适合谁看如果你只是偶尔用 AI 补全几行代码这篇对你意义不大。但如果你在搭 agent 工作流、在调编码代理的长任务表现、或者被压缩后失忆折磨过那接下来的内容应该能对上你的痛点。我会把为什么会断断在哪怎么接这三件事拆开讲中间穿插那个 430 条记录实验里能推断出的规律以及我自己踩过的坑。先说结论方向免得你看到一半才反应过来压缩后的接续能力本质上不取决于摘要写得多好而取决于你有没有在压缩之外单独维护一份结构化的任务状态。摘要是有损的任务状态是精确的两者分工不同。把这两件事混为一谈是绝大多数压缩后接不上的根因。2. 压缩到底丢了什么三类信息的损耗差异要解决问题先得知道丢了什么。我把一次编码会话里的信息粗分成三类它们在压缩中的损耗程度完全不一样。2.1 事实性信息文件路径、函数名、行号这类信息最容易被摘要糊掉。原始记录里是src/parser.ts:142摘要里很可能变成解析器模块的某个位置。对人类来说这无所谓反正可以重新搜但对代理来说它下一步动作高度依赖精确坐标。它不知道确切位置就只能重新 grep、重新读文件一来一回又是几千 token压缩省下来的空间瞬间被吃回去。我在自己的实验里观察到一个规律压缩后第一轮动作的重复率是最能说明问题的指标。如果代理压缩后第一件事是去读一个它压缩前已经读过的文件基本可以判定这次压缩是失败的。430 条记录里凡是出现这种回头读的后续任务完成质量普遍偏低。2.2 决策性信息为什么这么做、排除了哪些方案这类信息损耗最隐蔽也最致命。压缩前代理可能已经试过方案 A 失败了转而用方案 B。摘要里如果只写正在实现功能那代理压缩后很可能又去试方案 A。这就是典型的决策失忆。决策信息的另一个麻烦是它往往不在文本里。代理排除方案 A这个结论可能是从一次失败的测试输出里推断出来的而那段输出在压缩时被当成冗余日志丢掉了。等它再看到类似的报错它不会记得这个错我见过是方案 A 的锅只会当成新问题重新排查。2.3 意图性信息用户到底想要什么这类信息在长会话里会被反复稀释。用户最初说帮我把这个接口改成支持分页中间聊了十几轮细节压缩后摘要可能只剩修改接口。代理于是开始自由发挥加了一堆用户没要的东西。意图漂移是长任务里最常见的翻车方式而且它往往在压缩之后才暴露出来。下面这张表是我根据实验记录整理的三类信息在不同压缩策略下的保留情况信息类型纯摘要压缩摘要结构化状态摘要状态关键原文锚点事实性路径/行号大量丢失基本保留完整保留决策性方案取舍几乎全丢部分保留较好保留意图性用户目标易漂移稳定稳定token 开销最低中等较高这张表想说明的是没有免费的午餐。你想让代理压缩后接得上就得在压缩之外多花一点 token 去维护状态。关键是花得值不值——我的经验是维护一份几百 token 的结构化状态能省下压缩后几千 token 的重复探索这笔账非常划算。3. long_mem 与 engram两条记忆路线的分工关键词里出现的long_mem和engram其实代表了两种不同的记忆思路很多人把它们混着用效果反而不好。我按自己的理解拆一下。3.1 long_mem跨会话的长期记忆long_mem这类机制解决的是这次会话和上次会话之间的连续性。比如你昨天让代理重构了一个模块今天接着让它加功能它应该记得昨天的重构结论。这类记忆的特点是生命周期长、更新频率低、以事实和偏好为主。它适合存什么项目约定这个仓库用 tabs 不用 spaces、架构决策状态管理统一走 store不直接改组件、用户偏好报错信息要中文。这些内容一旦写入短期内不会变压缩与否都不该影响它们。它不适合存什么当前任务的临时进度。把正在改第 3 个文件这种信息塞进 long_mem只会污染长期记忆下次会话读到一堆过期状态反而添乱。3.2 engram当前任务的记忆痕迹engram这个词本意是记忆痕迹放在这个语境里我理解它指的是当前任务内部的结构化状态快照。它和 long_mem 最大的区别是生命周期engram 随任务生、随任务灭任务结束就该清掉。它存的是那种压缩会丢、但丢了就接不上的东西当前改到哪个文件、已经验证过哪些假设、下一步计划是什么、有哪些已知的坑。这份东西不需要很长但必须精确。我自己的做法是给 engram 定一个固定 schema大概长这样{ task_goal: 给 /users 接口加分页默认每页 20, current_file: src/routes/users.ts, done: [加了 page/limit 参数解析, 改了 SQL 查询加 LIMIT], verified: [单页查询返回正确, 边界 page0 已处理], next: [补 total 字段, 加参数校验], known_issues: [ORM 的 count 查询在空表时返回 null要兜底], excluded: [不用 offset 分页数据量大时性能差] }这份状态大概 150 到 250 token压缩时原样保留、不参与摘要。实测下来只要这份东西在代理压缩后第一轮动作的准确率会明显提升。原因很简单它不需要回忆它直接读到了当前状态。3.3 两者怎么配合分工原则一句话long_mem 管这个项目一直是这样engram 管这个任务现在到哪了。压缩的时候long_mem 不动它本来就不在对话历史里engram 原样保留只有中间的原始对话被摘要替换。这样代理压缩后拿到的是长期约定 精确任务状态 有损的过程摘要。三层信息各司其职接续就稳了。注意很多人图省事把 engram 也塞进摘要里让模型自己总结。这是大忌。模型总结状态时一定会丢精度而状态恰恰是最不能丢精度的部分。状态必须由代码维护不能交给模型回忆。4. 430 条记录里反复出现的三种断线模式那个实验最有价值的地方是它把接不上这件事变成了可观察的现象。我把记录里反复出现的模式归成三类你可以对照自己的日志看看中了几条。4.1 回头读压缩后重新探索已知区域这是最高频的一种。表现是压缩后代理立刻去读一个压缩前已经读透的文件。根因通常是事实性信息丢失——摘要没保留精确路径代理只能重新找。排查方法很直接在日志里标记每次压缩的时间点看压缩后前 3 个动作里有没有读已读文件。如果有说明你的摘要对事实性信息保留不足。修法也简单在摘要模板里强制要求保留当前正在编辑的文件路径和最近一次修改的位置。4.2 方案回退重新尝试已被排除的路径这种比回头读更隐蔽因为它看起来很正常——代理在认真工作只是方向错了。表现是它开始尝试一个压缩前已经验证失败的做法。根因是决策性信息丢失。我在记录里看到过一个典型例子代理压缩前已经确认某个第三方库的版本不兼容改用内置方案了压缩后它又开始研究怎么装那个库。这种回退浪费的不只是 token还有时间而且用户如果不盯着很可能就让它一路错下去。修法是把已排除方案作为 engram 的必填字段。每次代理明确排除一个方案就写进去。压缩时这个字段原样保留。4.3 意图漂移做着做着跑偏了这种最难发现因为它不表现为卡住而表现为过度发挥。代理压缩后开始加用户没要求的功能或者把简单需求做复杂。根因是意图性信息在长对话里被稀释。防漂移的关键是把原始意图原文钉住。不是摘要是原文。用户最初那句话一字不改地放进 engram 的task_goal字段。摘要可以变原文不能变。这样代理每次压缩后都能看到用户原话是什么漂移概率大幅下降。下面这张表把三种模式和对应的修法对齐一下断线模式典型表现根因修法回头读压缩后重读已读文件事实性信息丢失摘要强制保留路径与位置方案回退重试已排除方案决策性信息丢失engram 记录 excluded 字段意图漂移加需求、做复杂意图被稀释engram 钉住用户原话5. 把接续做稳的实操配置前面讲的是原理和现象这一节讲怎么落地。我按最小可用到进阶的顺序给配置你可以按自己的场景挑。5.1 压缩触发点的选择别等到上下文快满了才压缩。我的经验是在 70% 到 80% 用量时主动压缩而不是被动等系统触发。原因有两个一是主动压缩时你还能控制保留哪些内容被动触发往往是最粗暴的截断二是留出余量给压缩后的接续动作否则刚压缩完又满了等于白压。具体阈值看模型窗口大小。窗口越大触发点可以越靠后因为你有更多空间做精细压缩。但无论如何别贴着上限跑。5.2 摘要模板的字段设计摘要不能是自由发挥的一段话得有固定字段。我用的模板大概是这样[任务摘要] 目标用户原话一字不改 当前文件精确路径 最近修改文件:行号改了什么 已完成列表每条带验证状态 待办列表 已知问题列表 已排除方案列表带排除原因关键是每个字段都要求精确不允许某个文件大概改好了这种模糊表述。模板里明确写路径必须完整行号必须给出模型才会照做。5.3 engram 的更新时机engram 不是压缩时才生成的而是每次代理完成一个可验证的动作后就更新。比如它改完一个文件、跑通一个测试、排除一个方案就立刻写进 engram。这样压缩时 engram 已经是最新的直接拿来用就行。这个边做边记的习惯是整套方案里最反直觉但最重要的一环。很多人想着等压缩时再总结状态但压缩时模型已经在忙着压缩了再让它总结状态质量一定打折。状态维护应该是常态化的不是压缩时的临时任务。5.4 压缩后的第一轮动作约束压缩完成后别让代理自由发挥。给它一个明确的接续指令先读 engram确认当前状态然后从next字段的第一项开始。这一步能极大降低回头读和方案回退的概率。我实测下来加了这一步之后压缩后第一轮动作的准确率提升非常明显。原理也简单它不需要猜该干什么engram 直接告诉它了。提示接续指令里可以加一句如果 engram 与摘要冲突以 engram 为准。因为摘要有损engram 精确冲突时信精确的。6. 几个容易踩的坑和我的处理方式最后聊几个实操里真会遇到的坑都是我自己或身边人踩过的。坑一engram 越写越长。一开始觉得多记点没坏处结果 engram 膨胀到几千 token压缩省的空间又被它吃回去了。后来我定了硬约束engram 不超过 300 token超了就砍done里的历史项只留最近几条。历史完成项对接续其实没多大用真正有用的是next和known_issues。坑二把 engram 当日志用。有人把每一步操作都写进 engram变成流水账。这违背了它的定位——它是状态快照不是操作日志。状态是现在在哪日志是怎么走到这的。压缩后代理需要的是前者。日志该丢就丢别舍不得。坑三long_mem 和 engram 混在一个存储里。我早期图省事放一起结果清理任务状态时误删了长期约定代理突然开始用 spaces 缩进排查半天才发现是记忆被清了。后来严格分开long_mem 一个存储、按项目隔离、只增不删除非明确废弃engram 一个存储、按任务隔离、任务结束即清。坑四以为换了更大的窗口就不需要这套东西。窗口再大也有满的时候而且窗口越大压缩时的信息量越大粗暴压缩的损失反而越惨。这套状态维护的思路和窗口大小无关是长任务的基本功。坑五忽略验证状态。engram 里done和verified要分开。改完不等于验证过。压缩后代理如果分不清哪些是改完但没测的很可能在错误的基础上继续叠加。把验证状态标清楚它能少走很多弯路。这套东西我用了大概两三个月最大的感受是上下文压缩本身不是问题压缩后没有精确状态可依才是问题。摘要负责压缩过程、保留大意engram 负责钉住状态、保证接续long_mem 负责跨会话的长期一致性。三者分工明确长任务才不会在压缩点翻车。那个 430 条记录的实验本质上也是在验证同一件事——接续能力是可以工程化解决的前提是你别把希望全押在摘要写得好上。