AI编码代理上下文压缩后失忆怎么办？430条记录揭示long_mem与engram解法

1. 这个实验到底在折腾什么

先说结论：这个实验的核心命题只有一个——当 AI 编码代理的上下文被压缩之后，它还能不能"接得上"之前的工作。听起来像是一句废话，但你只要真正用过 Codex、Claude Code 这类编码代理跑过长任务，就知道这个问题有多要命。

我自己的体感是这样的：你让一个编码代理去改一个中型项目，前 20 分钟它思路清晰、文件定位准确、改动也合理。但对话一长，上下文窗口塞满了，系统触发压缩，把前面几十轮对话揉成一段摘要。压缩完之后你再让它继续干活，它经常会做出一些让你血压升高的事情——比如重新去读一个它十分钟前已经读过的文件，比如把之前定好的接口命名规则忘得一干二净，比如对着一个已经改好的函数再改一遍，改出个语法错误。

这个实验就是冲着这个痛点去的。作者用了 10 天时间，跑了 430 条公开记录，专门观察"上下文压缩"这个动作发生的前后，编码代理的行为到底发生了什么变化，以及有没有办法让它"接得上"。

关键词里的long_mem和engram是两个值得注意的方向。long_mem 顾名思义是长时记忆机制，engram 这个词来自神经科学，指的是记忆的物理痕迹，在这里大概率是指一种把关键信息"刻"下来、压缩后还能被检索回来的记忆结构。而Codex是这次实验的主要载体，也就是那个被反复压缩、反复考验的编码代理。

适合谁看？三类人。第一类是把 Codex 当日常生产力工具、跑过长时间任务的开发者；第二类是在做 AI 代理记忆机制、上下文管理的工程同学；第三类是被"压缩之后代理变傻"这个问题折磨过、想找一套可复现观察方法的人。如果你只是偶尔让 AI 补个函数，这个实验对你意义不大；但只要你让代理连续工作超过半小时，下面这些内容你迟早会撞上。

2. 为什么"上下文压缩"是编码代理的生死线

2.1 压缩不是优化，是被迫的取舍

很多人对上下文压缩有个误解，觉得它是个"锦上添花"的功能。不是的。它是被物理限制逼出来的必然选择。

编码代理的工作方式和聊天机器人完全不同。聊天机器人一轮对话可能就几百 token，而编码代理干一件事，动辄要读文件、跑命令、看报错、再读文件、再改代码。一个中等复杂度的任务，比如"给这个模块加上参数校验并补测试"，代理可能要读 15 个文件、执行 8 次命令、产生 30 轮工具调用记录。这些内容全部堆在上下文里，几万 token 起步，稍微大一点的项目直接冲到十几万。

而模型的上下文窗口是有上限的。到了上限，只有两条路：要么直接截断，把最早的内容扔掉；要么压缩，把历史揉成摘要。截断的后果是灾难性的——代理会彻底忘记任务目标，开始胡言乱语。所以主流方案都选压缩。

但压缩本身是有损的。它把"我读过user_service.py第 45 行有个validate_email函数，签名是def validate_email(email: str) -> bool"这种精确信息，压成了"代理检查了用户服务模块的校验逻辑"。精确的路径、行号、签名、变量名，全没了。

2.2 编码任务对"精确记忆"的依赖远超想象

这就是问题的核心。编码任务和写文章不一样。写文章，你记住"我要表达一个关于成长的感悟"就够了，具体措辞可以重新组织。但编码任务里，"把validate_email的返回值从bool改成tuple[bool, str]"这种指令，一旦丢失了函数名和类型信息，代理就彻底抓瞎。

我踩过的一个典型坑：让代理重构一个数据处理管道，前面它已经确认了三个函数的调用顺序是 A→B→C。压缩之后，它开始按 A→C→B 的顺序改，理由是"这样看起来更符合数据流向"。结果整个管道跑不通，报了一堆类型错误。它不是在瞎改，它是真的"忘了"之前确认过的顺序。

所以这个实验要回答的，本质上是一个记忆保真度的问题：压缩之后，哪些信息必须保住，哪些可以丢，怎么保。

2.3 long_mem 和 engram 想解决的是什么

long_mem 的思路是给代理外挂一个持久化的记忆层。不是把所有历史都塞回上下文，而是把关键事实抽出来，存到一个可以被检索的地方。压缩发生时，上下文里的对话历史可以丢，但记忆层里的"事实条目"不动。代理需要的时候，按需检索回来。

engram 更进一步，它强调的是"记忆痕迹"的稳定性。你可以理解成：不是简单存一条"函数签名是 X"，而是存一条带上下文、带关联、带置信度的记忆痕迹。当代理再次遇到相关代码时，这条痕迹会被激活，帮它恢复判断。

这两个方向在实验里是怎么落地的，后面会细说。这里先建立一个认知：上下文压缩的解法，不在于"压得更狠"或者"压得更少"，而在于"压的时候把该留的留下来，并且留在一个压缩之后还能找回来的地方"。

3. 430 条记录是怎么跑出来的

3.1 实验设计的基本框架

10 天、430 条公开记录，这个体量不算特别大，但胜在持续和真实。作者没有搞那种一次性的、精心设计的对照实验，而是把观察嵌进了日常的真实编码任务里。这一点很重要，因为实验室环境下的压缩行为和真实长任务里的压缩行为，差别巨大。

实验的基本框架我推测是这样的：选定一批有代表性的编码任务，覆盖不同的复杂度——从单文件小改到跨模块重构都有。每个任务让 Codex 连续执行，人为或自然地触发上下文压缩，然后在压缩前后分别记录代理的行为。记录的内容包括：它读了哪些文件、执行了哪些命令、改动了哪些代码、有没有重复劳动、有没有丢失关键约束。

430 条记录，平均下来一天 43 条。考虑到有些任务会产生多条记录，这个节奏是合理的，说明作者是真的在持续跑任务，而不是批量生成数据。

3.2 记录里到底记了什么

这是整个实验最有价值的部分。如果只是记"压缩后代理变笨了"，那没什么意义。真正有用的是记下具体丢了什么、怎么丢的、丢了之后代理做了什么错误决策。

从公开记录的模式看，作者关注的信息维度大概有这么几类：

这五类信息里，任务约束和决策依据是压缩的重灾区。因为它们往往是隐性的，散落在对话的各个角落，不像文件路径那样显眼。压缩算法很容易把它们当成"冗余信息"揉掉。

3.3 为什么选 Codex 作为载体

Codex 作为编码代理，有几个特点让它特别适合做这个实验。第一，它的工具调用非常频繁，读文件、跑命令、改代码，每一步都产生大量上下文，压缩触发得早、触发得频繁。第二，它的行为可观测性强，每一步操作都有明确的输入输出，方便记录。第三，它是真实在用的工具，不是玩具，实验结果有实际参考价值。

热词里那一堆关于 Codex 安装、配置、登录的问题，其实侧面说明了它的用户基数。一个工具用的人多，它的问题才有普遍性。这个实验选 Codex，选的是"最大公约数"。

4. 压缩之后，代理到底丢了什么

4.1 三类最典型的"失忆"现场

把 430 条记录里的问题归类，最典型的是三种。

第一种：重复读取。压缩后代理重新去读一个已经读过的文件，而且往往读的是同一个文件的不同部分，因为它不记得自己读过哪一段了。这种问题最直观，也最浪费 token。我见过最夸张的一次，代理在压缩后连续读了同一个配置文件四次，每次读的角度还不一样。

第二种：约束漂移。之前明确说好的"所有新函数必须加类型注解""不要动legacy/目录下的文件"，压缩后代理开始违反。它不是故意违规，是真的不记得有这条约束了。约束漂移是最危险的，因为它产生的代码看起来没问题，但违反了项目规范，review 的时候才发现。

第三种：方案回退。之前已经讨论并否决了一个方案，压缩后代理又把它捡起来，还振振有词地论证这个方案的好处。这种问题最让人哭笑不得，因为代理的论证逻辑本身可能是对的，只是它忘了这个方案已经被否决过。

4.2 为什么摘要式压缩特别容易丢约束

这里要讲一点原理。主流的上下文压缩用的是摘要式方法：把一段对话喂给模型，让它生成一段简短摘要。问题在于，摘要模型不知道哪些信息对后续任务重要。

对摘要模型来说，"用户要求所有函数加类型注解"和"用户说这个模块看起来挺复杂的"，在信息量上可能差不多，都是"用户表达了一个观点"。但实际上前者是硬约束，后者是闲聊。摘要模型没有这个区分能力，它按"信息密度"和"语言流畅度"来压缩，结果就是把硬约束和闲聊一起揉掉了。

更麻烦的是，约束往往是否定式的——"不要做 X"。而摘要模型天然倾向于保留肯定式信息，因为否定式信息在语言上更"轻"。你试试让模型摘要一段话，它大概率会保留"我们要做 A、B、C"，而丢掉"我们不做 D"。但编码任务里，"不做 D"往往比"做 A"更重要。

4.3 一个具体的失忆案例拆解

拿记录里一个典型场景来说。任务是给一个 API 模块加限流。

压缩前，代理已经确认了：限流用令牌桶算法、桶大小 100、补充速率每秒 10 个、超限返回 429、限流 key 用用户 ID 而不是 IP。这五条信息散在大概 8 轮对话里。

压缩后，代理开始写代码。它写出来的限流逻辑，桶大小变成了 50，补充速率变成了每秒 5 个，超限返回的是 503，key 用的是 IP。五条信息，错了四条。

为什么会这样？因为压缩摘要大概写成了"代理设计了 API 限流方案，采用令牌桶算法，处理超限请求"。算法保住了，因为它是"核心概念"；具体参数全丢了，因为摘要把它们当成了"细节"。

这个案例说明一个关键点：对编码任务来说，参数就是核心，不是细节。桶大小 100 和 50，在摘要模型眼里是细节差异，在代码里是行为差异。

5. long_mem 和 engram 的落地思路

5.1 long_mem：把事实从对话里抽出来

long_mem 的核心动作是"抽取"。它不依赖摘要模型去判断什么重要，而是用一套规则或专门的抽取模型，把对话里的结构化事实抽出来，单独存。

什么叫结构化事实？就是那些可以写成"主语-谓语-宾语"或者"键-值"形式的信息。比如：

• 约束：{类型: 命名规范, 内容: 新函数必须加类型注解, 作用域: 全局}
• 参数：{对象: 令牌桶, 属性: 大小, 值: 100}
• 决策：{对象: 限流key, 选择: 用户ID, 否决: IP, 原因: 用户可能换IP}
• 进度：{任务: API限流, 当前步骤: 写核心逻辑, 下一步: 写测试}

这些事实存进 long_mem 之后，压缩发生时它们不受影响。代理需要的时候，按当前任务上下文去检索。检索回来的不是一大段对话，而是几条精确的事实。

这个思路的好处是保真度高。参数就是参数，不会被揉成"一些配置"。坏处是抽取有成本，而且抽取规则要设计得好，否则会漏。漏了一条关键约束，等于没做。

5.2 engram：让记忆带"激活"能力

engram 的思路更接近生物记忆。它不只是存事实，还存事实之间的关联和激活条件。

打个比方。long_mem 像是一个笔记本，你记了"令牌桶大小 100"，需要的时候翻到这一页。engram 像是一个联想网络，你记的不只是"令牌桶大小 100"，还有"这条记忆和'限流'相关、和'API模块'相关、和'性能优化'相关"。当代理再次处理限流相关代码时，这条记忆会被自动激活，不需要显式检索。

这个机制解决的是"代理不知道自己该回忆什么"的问题。很多时候代理不是找不到记忆，是压根没想到要去查。engram 的激活机制让记忆主动浮现，降低了"忘记查"的概率。

从工程实现角度，engram 大概率用了向量检索加关联图谱的组合。事实存成向量，关联存成图，检索时两者结合。这套东西在 RAG 领域有成熟实践，搬到编码代理的记忆管理上是自然的延伸。

5.3 两套思路的取舍

long_mem 和 engram 不是互斥的，实验里很可能是配合使用。long_mem 负责"存得准"，engram 负责"找得到"。

如果只能选一个，我的建议是：任务约束多、规范严格的项目，优先 long_mem，因为约束丢失的代价最大，必须保证存准。任务探索性强、方案反复调整的项目，优先 engram，因为需要记忆主动浮现来避免方案回退。

实际落地时，两套机制的存储层可以共用，区别在于检索策略。long_mem 用精确匹配加关键词检索，engram 用向量相似度加关联扩散。这个组合在实验记录里应该是被验证过的。

6. 实操：怎么让压缩后的代理接得上

6.1 第一步：把约束显式化

这是最容易被忽略、但收益最大的一步。不要指望代理自己记住约束，你要主动把约束写成一个显式的、结构化的东西，放在一个压缩不会碰的地方。

具体做法：在项目根目录建一个AGENT_CONSTRAINTS.md或者类似的约定文件，把所有硬约束列进去。格式要简单直接：

## 命名规范 - 新函数必须加完整类型注解 - 私有方法以 _ 开头 - 常量全大写 ## 禁止改动 - legacy/ 目录下所有文件 - 任何 .env 文件 ## 接口约定 - 所有 API 返回统一用 {code, data, message} 结构 - 错误码从 1000 开始

然后在任务开始时，明确告诉代理："每次开始新步骤前，先读一遍AGENT_CONSTRAINTS.md。" 这样即使上下文被压缩，约束文件还在磁盘上，代理随时能重新加载。

注意：约束文件不要写太长。超过 50 条约束，代理读起来也费劲，而且容易漏。只放真正硬性的、违反会出问题的约束。软性偏好放在别处。

6.2 第二步：用"进度锚点"对抗失忆

压缩后代理最容易卡在"我进行到哪了"。解法是主动维护一个进度锚点文件，比如TASK_PROGRESS.md，每完成一个关键步骤就更新一次。

## 当前任务：API 限流 ### 已完成 - [x] 确认限流算法：令牌桶 - [x] 确认参数：桶大小 100，补充速率 10/s - [x] 确认超限响应：429 - [x] 确认限流 key：用户 ID ### 进行中 - [ ] 写核心限流逻辑 ### 待办 - [ ] 写单元测试 - [ ] 更新 API 文档

这个文件的作用是：压缩后代理只要读一遍，就能恢复任务状态。它比对话历史可靠得多，因为它是结构化的、精确的、不会被摘要揉掉的。

我自己的经验是，进度锚点要写得"可执行"。不要写"处理限流逻辑"，要写"在middleware/rate_limit.py里实现TokenBucket类，包含acquire()方法"。越具体，压缩后恢复得越准。

6.3 第三步：关键决策留痕

方案选型、参数确定这类决策，一定要留痕。留痕的方式可以是在进度文件里加一个"决策记录"区块，也可以是单独的DECISIONS.md。

## 决策记录 ### 2024-XX-XX 限流 key 选择 - 选择：用户 ID - 否决：IP 地址 - 原因：用户可能切换网络，IP 不稳定；用户 ID 更准确 - 影响：需要在认证中间件里注入 user_id

这条记录的价值在于，压缩后代理如果又想用 IP，它读到这条记录就会知道"哦，这个已经被否决过了"。没有这条记录，它就会重新论证一遍，浪费 token 还可能得出不同结论。

6.4 第四步：配置压缩策略

如果你用的工具支持配置压缩行为，一定要调。默认的压缩策略通常是最激进的，因为它优先保证不超窗口。但对编码任务来说，激进压缩的代价太大。

能调的参数一般有这几个：

• 压缩触发阈值：默认可能是窗口的 80%，可以调到 90%，让更多内容留在上下文里。
• 保留最近 N 轮：确保最近几轮对话不被压缩，因为最近的内容通常和当前任务最相关。
• 压缩粒度：有些工具支持按"任务阶段"压缩，而不是按"对话轮数"压缩。按阶段压缩更合理，因为一个阶段内的信息关联性强。

如果工具不支持配置，那就只能靠前面的显式化手段来兜底。这也是为什么我一直强调约束文件和进度文件的重要性——它们是压缩策略不可控时的最后防线。

7. 常见问题与排查技巧

7.1 代理压缩后开始重复劳动怎么办

这是最常见的问题。排查思路是：先看它重复的是什么。如果重复读文件，说明文件状态记忆丢了；如果重复改代码，说明改动记录丢了；如果重复论证方案，说明决策记录丢了。

对应的解法：文件状态用进度文件记录，改动记录用 git 的 staged 状态辅助（让代理每次改完git add，这样git status就能看到已改文件），决策记录用DECISIONS.md。

一个实操技巧：让代理在每次压缩后，先执行一次git status和git diff --stat，用 git 的状态来恢复"我改了什么"的记忆。git 是外部状态，不受上下文压缩影响，非常可靠。

7.2 约束漂移怎么提前发现

约束漂移的麻烦在于它不报错。代码能跑，测试能过，但违反了规范。等 review 的时候才发现，返工成本高。

提前发现的办法是加一道"约束自检"。在代理完成一个阶段后，让它对照约束文件逐条检查自己的产出。比如："请对照AGENT_CONSTRAINTS.md，检查你刚才写的代码是否违反了任何约束，逐条说明。"

这个自检动作本身也会消耗 token，但比返工便宜。而且自检的结果可以写进进度文件，作为下一阶段的参考。

7.3 压缩后代理"重新连接"失败怎么处理

热词里有"codex正在重新连接"这种问题，说明连接稳定性也是实际使用中的痛点。如果压缩后代理出现明显的逻辑断裂，比如答非所问、上下文完全对不上，那可能不只是压缩的问题，而是会话状态本身出了问题。

处理顺序：先确认是不是压缩导致的（看压缩日志），如果是，用进度文件和约束文件重新"喂"一遍状态；如果不是，检查会话配置和网络连接。有时候重新开一个会话，把进度文件和约束文件作为初始输入，比在旧会话里挣扎更高效。

7.4 问题速查表

8. 我自己的几点实操体会

跑过一段时间这类长任务之后，我最大的体会是：不要和压缩对抗，要和它配合。

很多人第一反应是"我要让压缩别发生"，于是拼命精简对话、减少工具调用。但这是本末倒置。压缩是必然的，任务复杂度上去了，上下文一定会满。与其想着怎么不压缩，不如想着压缩之后怎么快速恢复。

第二个体会是：外部状态比上下文可靠。git 状态、进度文件、约束文件，这些东西存在磁盘上，压缩碰不到。代理的上下文是易失的，磁盘是持久的。把关键信息往磁盘上放，是性价比最高的做法。

第三个体会是：约束要少而硬。我一开始恨不得把所有规范都写进约束文件，结果代理读起来费劲，还经常漏。后来精简到只留真正硬性的十几条，效果好很多。软性偏好靠 code review 兜底，不要指望代理全记住。

最后一个技巧：如果你发现某个任务特别容易在压缩后出问题，可以把它拆成几个小任务，每个小任务单独跑。小任务的上下文不容易满，压缩触发得晚，出问题的概率就低。拆任务的成本，往往比修复压缩后遗症的成本低。

这个实验最打动我的地方，是它没有停留在"压缩有问题"的抱怨上，而是真的去记录了 430 条，去观察规律，去尝试 long_mem 和 engram 这样的解法。编码代理的记忆管理，现在还是个很早期的领域，很多问题没有标准答案。但只要有这样持续观察、持续记录的人在，答案会慢慢浮出来。