1. 这个实验到底在折腾什么先把这个标题拆开看。上下文压缩指的是 AI 编码代理在长会话里因为上下文窗口有限不得不把历史对话、代码片段、工具调用记录做摘要或截断腾出空间继续干活。AI 编码代理就是像 Codex 这类能自己读文件、改代码、跑命令的智能体。问题就出在这两者的交界处压缩之后代理还记得自己刚才在干什么吗还能接上之前的思路吗我花了 10 天时间用 430 条公开可查的记录专门测了这件事。记录的形式是每次会话的输入输出快照、压缩触发点、压缩后的行为日志以及代理在压缩后重新执行任务的成功率。之所以要公开记录是因为这类问题太容易被感觉还行糊弄过去——你问它刚才改到哪了它答得头头是道但一让它继续写代码就开始重复劳动或者改错文件。这个实验适合谁看如果你正在用 Codex 或者类似的编码代理做长周期任务比如重构一个模块、修一串关联 bug、或者让代理自己迭代一个功能那你一定会撞上上下文压缩。如果你只是让它写个单文件函数那压缩基本不会触发这篇可以当背景知识看。关键词里的long_mem和engram前者是长记忆机制的泛指后者是我在实验里用来标记压缩后残留记忆痕迹的一个内部叫法不是某个具体产品名后面会展开讲。先说结论方向压缩本身不是问题问题是压缩的时机和粒度。代理接不上往往不是因为忘了而是因为记得的东西被压成了错误的抽象。下面我把这 10 天的设计、踩坑和可复现的操作拆开讲。2. 实验设计与核心思路拆解2.1 为什么不用现成的 benchmark市面上有不少测长上下文记忆的基准但大多测的是大海捞针——在一大段文本里找一个事实。编码代理的场景完全不是这样。它需要的是程序性记忆我改过哪个文件、改到第几行、下一步该跑什么命令、之前哪个方案被否决了。这些信息在压缩时如果被摘要成用户要求优化代码那就全丢了。所以我没直接用现成基准而是自己设计了一套任务流。核心思路是让代理做一个有状态的多步任务每一步都依赖前一步的具体产物然后在中间强制触发压缩看它下一步能不能接上。任务流长这样读取一个包含 5 个文件的迷你项目理解模块依赖。修改其中一个文件的函数签名。找出所有调用点并同步修改。跑测试根据报错修一个边界条件。最后生成一份变更说明。这五步里第 3 步和第 4 步强依赖第 2 步的具体改动。如果压缩把改了哪个函数、改成什么签名弄丢了第 3 步就会瞎找第 4 步就会修错地方。2.2 压缩触发点的控制Codex 这类代理的上下文压缩通常是自动的接近窗口上限时触发。为了做对照我在实验里用了两种方式一种是自然触发就是让它自己跑到压缩另一种是手动注入压缩在指定步骤后强制做一次摘要模拟极端情况。手动注入的好处是可控。我可以在第 2 步刚改完函数签名后立刻压缩然后看第 3 步的表现。自然触发则更接近真实使用但触发点飘忽需要多跑几次取统计。430 条记录里大约 6 成是自然触发4 成是手动注入。这里有个关键设计我记录了每次压缩前后的上下文快照。压缩前是完整的消息列表压缩后是代理实际拿到的摘要加残留消息。对比这两者就能看出哪些信息被丢了、哪些被扭曲了。这个对比是后面所有分析的基石。2.3 long_mem 和 engram 在实验里的角色long_mem 我把它理解成代理的外部记忆层比如把关键状态写到一个文件里压缩后重新读回来。engram 则是内部残留指压缩后还留在上下文里的那些碎片可能是一句没头没尾的注释也可能是一个文件名。实验里我分别测了三种配置纯压缩不借助任何外部记忆。压缩加 long_mem每步关键状态写文件。压缩加 engram 强化在压缩前刻意把关键信息放在容易被保留的位置。结果后面细说但先给个方向long_mem 最稳engram 强化最取巧但也最容易翻车纯压缩在短任务里凑合长任务必崩。3. 核心细节解析与实操要点3.1 压缩到底压掉了什么要理解代理为什么接不上得先看压缩的输出长什么样。我抓了一段典型的压缩后摘要大意是用户要求修改项目中的函数并修复测试。已读取文件进行了修改测试通过。就这么一句。原来上下文里有具体的函数名、行号、报错信息、试过的错误方案全没了。代理拿到这句摘要下一步要继续修改它只能重新读文件。重新读不是不行但代价是它可能读到已经改过的版本然后误以为没改再改一遍。或者它读到调用点但不知道签名已经变了按旧签名去改直接编译不过。注意压缩摘要的质量和压缩时的提示词强相关。默认摘要往往偏向用户意图而不是程序状态。这是很多代理接不上的根因。我在实验里试过手动改压缩提示词让它优先保留文件路径、函数名、行号、命令、报错。改完之后接续成功率从大概三成提到了六成多。这个改动不需要动代理本身只是调整摘要的生成指令性价比很高。3.2 关键状态该写什么、写在哪long_mem 的实操核心是每完成一个原子步骤就把状态落盘。原子步骤的定义是一个可以被独立验证的改动。比如把parse_config的返回值从 dict 改成 dataclass是一个原子步骤重构配置模块不是。落盘的内容我固定成几个字段step_id步骤编号单调递增。files_touched这一步改了哪些文件带行号范围。symbols_changed改了哪些函数、类、变量旧签名和新签名。commands_run跑了什么命令结果摘要。next_action下一步该干什么一句话。blocked_by如果有阻塞卡在哪。写在哪也有讲究。我试过写在项目根目录的.agent_state.json也试过写在代理的工作目录外。写在项目内的问题是代理可能把它当成待修改的文件写在项目外的问题是代理重新启动后找不到。最后我固定在项目根目录但在代理的忽略列表里加上它避免被误改。3.3 engram 强化的取巧与风险engram 强化的思路是既然压缩会丢信息那就在压缩前把关键信息放到容易被保留的位置。实验里我发现压缩摘要对最近几条消息和被反复提及的实体保留得更好。所以我在压缩前会做一件事把关键状态用一句话重复一遍放在最后一条消息里。比如在改完函数签名后我让代理自己输出一句当前状态parse_config已改为返回Configdataclass调用点在main.py:42和utils.py:17下一步同步修改调用点。这句话在压缩时大概率会被保留因为它又短又具体。但这招有风险。如果代理在重复时自己记错了错误信息会被强化。我遇到过两次代理把行号记错压缩后按错行号去改改到了无关代码。所以 engram 强化必须配合验证重复之后让代理再读一次文件确认行号。多这一步错误率降了很多。4. 实操过程与核心环节实现4.1 环境准备与代理配置实验用的是 Codex 的 CLI 形态跑在本地。配置上主要改三处上下文窗口大小、压缩触发阈值、摘要提示词。窗口大小我设成中等偏小目的是让压缩更容易触发加快实验节奏。触发阈值设成窗口的 80%留一点余量给摘要本身。摘要提示词是重点。默认的摘要指令偏向对话总结我换成了面向程序状态的版本核心要求是保留所有文件路径、函数名、行号、命令和报错原文不要做抽象归纳。这个改动在配置文件里就能完成不需要改代理源码。提示如果你用的是桌面版或插件版摘要提示词可能不暴露。那就退而求其次用 long_mem 落盘来补效果差一些但也能用。4.2 任务流的逐步执行与记录每一步我都用脚本记录四样东西代理的完整输出、当前上下文的消息数、是否触发压缩、压缩后的摘要原文。记录格式是 JSON Lines一行一条方便后面统计。430 条记录就是这么攒出来的。执行第 2 步改函数签名时我特意让改动跨两个文件制造依赖。改完后立刻手动压缩然后让代理执行第 3 步。第一次跑代理重新读了两个文件然后改了其中一个调用点漏了另一个。检查日志发现压缩摘要里只提了修改了配置相关函数没提具体是哪个函数、改成了什么。代理只能靠重新读文件猜猜漏了。加上 long_mem 落盘后同样场景代理在第 3 步开始前先读了.agent_state.json拿到了函数名和新签名然后精准定位两个调用点一次改对。这个对比很直观压缩丢的是程序状态long_mem 补的也是程序状态对症下药。4.3 参数选择与计算过程窗口大小和触发阈值不是随便设的。我按任务流的平均 token 消耗来算。五步任务每步平均产生 800 到 1200 token 的对话和工具输出加上初始读文件的 3000 token 左右全程大概 8000 token。如果窗口设 16000压缩基本不触发测不出问题。设 8000压缩会在第 3 步或第 4 步触发正好卡在依赖最强的位置。所以我最终把窗口设在 8000 到 10000 之间触发阈值 80%也就是 6400 到 8000 token 时压缩。这个计算逻辑可以迁移你先估自己任务的全程 token 量然后把窗口设成略小于全程让压缩在任务中段触发。这样测出来的接续问题最真实。4.4 数据统计与结果呈现430 条记录按配置分三组。纯压缩组接续成功率大概 31%。long_mem 组成功率 78%。engram 强化组成功率 62%但错误类型更危险因为它会自信地改错地方。成功率的口径是下一步操作是否与预期一致且没有引入新错误。还有个有意思的发现压缩触发得越晚接续成功率越高。因为晚触发意味着更多信息已经被代理消化进了当前动作即使压缩丢了代理靠惯性也能接上。但这不可控不能依赖。5. 常见问题与排查技巧实录5.1 代理压缩后重复劳动怎么排查重复劳动是最常见的症状代理重新读已经读过的文件重新改已经改过的代码。排查第一步是看压缩摘要里有没有已完成的明确标记。如果没有代理会默认自己还没做。解决办法是在 long_mem 里加一个completed_steps列表压缩后代理先读这个列表跳过已完成步骤。5.2 代理改错文件或改错行怎么办这通常是 engram 强化记错或者压缩摘要扭曲了行号。排查时对比压缩前的上下文快照和压缩后的摘要看行号是否一致。如果不一致说明摘要在归纳时算错了。解决办法是压缩前让代理重新读一次文件确认行号或者干脆不在摘要里放行号只放函数名让代理自己定位。5.3 压缩后代理失忆但嘴硬怎么处理有些代理会声称自己记得但行为上明显接不上。这种情况不要跟它辩论直接让它读 long_mem 文件。读完之后它就有了具体状态行为会立刻正常。我试过跟它解释你刚才改过这个函数它反而会顺着你的话编越编越乱。用文件说话最稳。5.4 常见问题速查表症状可能原因排查动作解决手段重复读文件摘要没标已完成看摘要有无 completed 标记long_mem 加 completed_steps改错行号engram 记错或摘要算错对比压缩前后行号压缩前重读文件确认漏改调用点摘要丢了函数名和签名看摘要有无符号信息摘要提示词要求保留符号自信改错engram 强化了错误信息看重复语句是否准确重复后加验证步骤接不上思路摘要过于抽象看摘要是否只有意图换面向程序状态的摘要提示词注意排查时优先看压缩摘要它是所有问题的源头。摘要对了后面基本不会错摘要错了后面怎么补都别扭。6. 我在这 10 天里踩过的坑和留下的技巧第一个坑是太信任默认摘要。前三天我用的都是默认配置接续成功率低得离谱我还以为是代理本身不行。后来把摘要原文打出来看才发现它把关键信息全归纳没了。这个坑的教训是压缩摘要必须可观测看不到摘要就没法调。第二个坑是 long_mem 写得太啰嗦。一开始我把每一步的完整输出都写进去结果文件越来越大代理读它也要花上下文反而挤占了干活的空间。后来改成只写结构化字段每个字段一句话文件控制在几十行以内效果好很多。第三个坑是 engram 强化用过头。有几次我让代理反复重复状态结果它把重复当成了任务本身开始输出一堆状态描述而不干活。后来限制成压缩前只重复一次且必须紧跟着下一步动作。留下的技巧里最有用的是压缩前快照。每次压缩前把完整上下文存一份出问题时对比摘要能快速定位是丢了还是扭曲了。这个习惯让我排查效率高了很多。另一个是任务流原子化把大任务拆成可独立验证的小步每步落盘压缩的影响就被限制在单步内不会连锁崩。这套东西后续还能扩展。比如把 long_mem 做成跨会话的代理重启后也能接上或者把摘要提示词做成模板按任务类型切换。我还在试的是让代理自己判断什么时候该落盘而不是我手动触发这样更接近真实使用。目前看代理自己判断的准确率大概七成还有提升空间但方向是对的。