1. 为什么“上下文压缩”是 AI 编码代理绕不过去的坎先抛一个我自己的真实感受用 AI 编码代理写代码最爽的是前二十分钟最崩溃的是第四十分钟。前二十分钟它记得你所有的约定——变量命名风格、目录结构、哪个模块不能动、上次那个 bug 是怎么修的到了第四十分钟上下文窗口塞满了系统开始做上下文压缩然后你会发现它突然“失忆”了明明十分钟前刚说过的接口签名它给你换了个参数名明明强调过不要动的那张表它又给你加了个字段。这不是模型变笨了而是上下文压缩这个动作本身在丢信息。所谓上下文压缩说白了就是当对话历史、代码片段、工具调用记录加起来超过模型能吃的 token 上限时系统必须做取舍——要么把老内容摘要成一段话要么直接截断丢掉要么按优先级保留一部分。这个过程对人是透明的但对 AI 编码代理来说是致命的因为它赖以工作的“记忆”被动了手脚。我这次做的事情就是拿一个真实的编码代理工作流连续跑了10 天留下了430 条公开可查的记录专门观察一件事上下文压缩之后代理到底还能不能接得上之前的活。围绕这个目标我重点折腾了几个方向——long_mem长时记忆、engram记忆痕迹/记忆印迹的思路、以及Codex这类编码代理在压缩前后的行为差异。热搜里那一堆codex安装、codex配置、codex登录、codex cli、codex接入deepseek之类的词其实都指向同一批人正在把编码代理往自己工作流里塞的开发者。这篇文章就是写给这批人的。如果你只是偶尔让 AI 补个函数那上下文压缩对你影响不大但如果你像我一样让代理连续几小时甚至跨天去推进一个项目那“压缩后接不上”这个问题你迟早会撞上。下面我把自己这 10 天的实验设计、观察到的现象、以及最后沉淀下来的接续方案一条条摊开讲。2. 实验整体设计与思路拆解2.1 为什么要用“10 天 430 条记录”这种笨办法很多人评估编码代理喜欢跑几个 benchmark 就下结论。我不太信那套因为 benchmark 里的任务大多是“单轮、短上下文、目标明确”而真实开发是“多轮、长上下文、目标会漂移”。上下文压缩的伤害恰恰在长会话里才暴露短任务根本测不出来。所以我选了最笨但最可靠的办法固定一个真实项目让代理每天推进一部分全程记录。10 天下来积累了 430 条记录每条记录包含当轮的任务描述、代理的响应、是否触发了压缩、压缩后代理是否出现“记忆断裂”、以及我手动补了多少上下文才让它接上。这 430 条不是随便凑的数而是每天大约 40 到 50 轮交互自然累积出来的覆盖了从“写新功能”到“改 bug”到“重构”的完整周期。提示如果你也想做类似观察别一上来就追求样本量。先把“是否触发压缩”和“压缩后是否断裂”这两个字段定义清楚否则记录一堆没法分析的流水账。2.2 三个核心变量long_mem、engram、Codex实验里我主要盯三个东西它们分别对应记忆问题的三个层次。long_mem解决的是“跨会话记忆”。普通代理的上下文只在单次会话里有效会话一关就归零。long_mem 的思路是把关键信息持久化到外部存储下次会话开始时再捞回来。它的问题是捞什么、捞多少、怎么保证捞回来的不过时。engram这个词借的是神经科学的“记忆印迹”概念指的是信息被编码后留下的物理痕迹。放到代理里我把它理解成“对某段上下文的压缩表示”——不是原文而是一个能唤起原文的索引。engram 的价值在于它比摘要更轻比原文更省但前提是索引得准。Codex在这里代表的是编码代理这一类工具的执行层。热搜里codex安装、codex cli、codex配置、codex接入deepseek这些词说明很多人正在把它接到自己的环境里。我关心的不是怎么装而是装好之后它在压缩场景下的表现。2.3 方案选型背后的取舍逻辑我一开始想直接用现成的记忆框架试了两天发现不行——通用记忆框架是为“问答”设计的不是为“编码”设计的。编码场景有个特殊之处代码是有强结构依赖的。你记住了“有个函数叫 parseConfig”没用你还得记住它的签名、它被谁调用、它依赖哪个类型。摘要式记忆很容易把这些结构关系压没。所以最后我走的是“分层记忆”路线短期用原始上下文中期用 engram 式索引长期用 long_mem 持久化。三层之间靠一套明确的“提升/降级”规则衔接。这个设计的核心考量是不同时间尺度的信息压缩策略必须不同。把长期记忆和短期上下文用同一套压缩逻辑处理是很多方案失败的根本原因。3. 核心细节解析与实操要点3.1 上下文压缩到底压掉了什么要解决问题先得知道丢了什么。我把 430 条记录里所有“压缩后断裂”的案例做了归类发现丢的信息集中在四类丢失类型具体表现出现频率接口契约函数签名、参数类型、返回值结构被改写高频约束条件“不要动这张表”“必须用现有工具类”被遗忘高频决策历史为什么选方案 A 而不是 B被压缩掉中频文件路径具体改哪个文件、哪个目录记混中频你会发现这四类里没有一类是“代码本身”。代码代理写代码的能力其实没怎么退化退化的是对项目状态的记忆。这给了我一个重要启发压缩策略应该优先保护“状态类信息”而不是“内容类信息”。内容可以重新生成状态丢了就接不上了。3.2 long_mem 的落地存什么、怎么存、何时取long_mem 最容易踩的坑是“什么都存”。我第一版把每轮对话都存进去结果检索时噪音太大捞回来的十条里八条没用。后来改成只存三类决策记录每个重要选择及其理由用一句话写清“选了什么、为什么”。契约快照接口签名、数据结构定义按文件维度存。未完成事项当前进行到哪、下一步要做什么。存储格式我用的是结构化文本而不是向量库。原因很实际编码场景的检索往往是“按文件”“按模块”精确查不是语义模糊查。向量检索在这里反而容易召回不相关内容。结构化存储配合关键词索引实测命中率更高。注意long_mem 的写入时机很关键。别等会话结束才写那时候上下文可能已经被压缩过了写进去的就是残缺信息。我的做法是每完成一个“可交付小单元”就写一次。3.3 engram 式索引让压缩后的上下文能“唤起”原文engram 这一层是我觉得最有意思的部分。它的作用是当上下文被压缩成一段摘要后摘要里保留一些“钩子”这些钩子能指向 long_mem 里的完整信息。举个具体例子。压缩后摘要里可能只剩一句“已按约定完成配置模块改造”。这句话本身信息量很低但如果它带一个钩子[ref:config-contract-v3]代理就能顺着这个钩子去 long_mem 里把配置模块的完整契约捞回来。这样摘要虽然短但“接得上”。钩子的设计要点是稳定且唯一。我一开始用自然语言描述当钩子比如“那个配置相关的约定”结果检索时匹配到一堆东西。后来改成固定格式的 ID命中率立刻上来了。这跟给代码打 tag 是一个道理模糊描述永远不如精确标识。3.4 Codex 类代理在压缩前后的行为差异这部分是我观察得最细的。同一个任务在压缩前和压缩后交给代理行为差异非常明显。压缩前代理倾向于先确认再动手它会复述一遍约束确认理解无误然后开始改。压缩后代理倾向于直接动手它不再复述约束上来就改而且改的时候经常违反之前定好的规则。这不是它“不听话”而是那些规则已经不在它的上下文里了。还有一个细节压缩后代理对“否定式约束”的遗忘特别严重。“不要用 X”“禁止改 Y”这类信息比“要用 Z”更容易丢。我猜是因为否定式约束在摘要时容易被当成“次要信息”过滤掉。所以我的应对是把关键否定约束提升为钩子强制它在摘要里保留。4. 实操过程与核心环节实现4.1 环境搭建与代理接入先把基础环境说清楚不然下面的步骤没法复现。我用的是命令行形态的编码代理跑在本地开发机上项目是一个中等规模的后端服务大概两万行代码模块划分清晰适合观察。接入过程里热搜里那些codex安装、codex cli、codex配置的坑我基本都踩了一遍。总结下来几个关键点安装优先用官方渠道的安装包别图省事用第三方打包版版本对不上会导致配置项识别失败。配置配置文件里的字段名要严格对照文档多一个空格都可能触发“无法识别的配置项”警告。登录登录态失效是高频问题建议把登录态检查做成启动脚本的一部分别等跑到一半才发现掉线。模型接入如果接的是第三方模型注意模型名要写对写错会直接报“模型不支持”。# 启动前先做一次配置自检避免跑到一半才发现问题 agent-cli config check agent-cli auth status agent-cli model list这三条命令是我每天开工前的固定动作。别嫌麻烦配置问题在长会话里暴露的代价比开工前检查高得多。4.2 分层记忆的具体实现我的分层记忆是这么搭的。短期层就是代理自带的上下文不动它。中期层是一个本地索引文件每轮交互后由脚本自动更新。长期层是一个按天分文件的记录库。中期索引的更新逻辑是这样的每轮交互结束后脚本扫描这轮内容提取出“契约变更”“决策”“未完成项”三类信息生成带 ID 的条目写进索引。同时给这轮上下文打上对应的钩子 ID。这样即使后面上下文被压缩钩子还在就能反查。# 简化版的中期索引写入逻辑 def update_index(turn_content, turn_id): entries extract_entries(turn_content) # 提取契约/决策/未完成项 for e in entries: e[ref] fturn-{turn_id}-{e[type]} index_store.append(e) return [e[ref] for e in entries] # 返回钩子列表供上下文打标长期层我做了个“每日快照”把当天所有索引条目合并去重形成一份项目状态摘要。第二天开工时代理先读这份摘要再开始干活。这一步相当于给代理“恢复记忆”实测能显著降低压缩后的断裂率。4.3 压缩触发时的接续流程真正关键的是压缩触发那一刻怎么处理。我的流程分四步检测监控上下文占用率超过阈值就预警。固化在压缩发生前强制把当前关键状态写入 long_mem。打标确保压缩后的摘要里保留必要的钩子。验证压缩后让代理复述一遍当前任务和约束确认它接上了。第四步特别重要。我一开始省了这步结果代理带着错误的记忆往下跑越跑越偏。后来加了“复述验证”一旦发现它复述的约束和实际不符立刻用钩子把正确信息捞回来重新注入。提示复述验证不要问“你记得吗”要问“请复述当前任务的三个约束”。开放式提问代理容易糊弄具体提问才能暴露它到底记没记住。4.4 430 条记录里跑出来的关键数据10 天下来430 条记录里触发压缩的有 87 次其中压缩后出现明显断裂的有 31 次。加了分层记忆之后后 5 天的断裂率比前 5 天下降了大约六成。这个数字不算完美但足以说明分层记忆的方向是对的。更值得说的是断裂的分布。31 次断裂里有 22 次发生在“跨天会话”场景也就是第二天接着第一天干的时候。这说明跨会话的记忆恢复比会话内的压缩接续更难。会话内至少还有残存上下文跨天基本是从零开始全靠 long_mem 捞。5. 常见问题与排查技巧实录5.1 代理“假装记得”怎么办这是最坑的一种情况。代理不会说“我忘了”它会自信地编一个看起来合理的记忆。比如你问它“上次那个接口叫什么”它会给你编一个名字而且语气非常肯定。我的排查办法是交叉验证让它复述的同时我去 long_mem 里查实际记录对不上就立刻纠正。纠正的时候不要只说“错了”要把正确信息完整注入否则它下次还会编。5.2 压缩后约束被违反的排查约束被违反通常有两个原因要么约束没进摘要要么进了摘要但被代理忽略了。区分方法很简单看压缩后的摘要里有没有这条约束。没有就是压缩策略问题要调整钩子有但还被违反就是代理的注意力问题需要把约束提到更靠前的位置。5.3 常见问题速查表现象可能原因处理方式压缩后接口签名变了契约未进 long_mem补写契约快照加钩子跨天会话接不上未做每日快照恢复开工前先读状态摘要代理编造记忆检索无结果但未报错加交叉验证强制查库配置报错无法识别配置项拼写或版本不符对照文档逐项核对登录态中途失效长会话超时启动脚本加状态检查5.4 几个我踩过的坑第一个坑是过度依赖摘要。我一开始觉得摘要越短越好结果短到把关键约束都压没了。后来明白摘要的目标不是短是“够用”。宁可长一点也别丢关键信息。第二个坑是钩子 ID 不稳定。早期我用时间戳当 ID结果同一件事在不同轮次生成了不同 ID检索时对不上。后来改成基于内容哈希生成 ID同一件事的 ID 就稳定了。第三个坑是忘了清理过期记忆。long_mem 越存越多检索越来越慢而且会捞回过时的信息。后来加了“有效期”字段超过一定时间的决策记录自动降权。6. 关于记忆接续这件事我最后想说的跑了这 10 天我最大的体会是上下文压缩本身不是问题问题是压缩之后没有接续机制。很多人把希望寄托在“模型上下文窗口越来越大”上觉得窗口够大就不用压缩了。但真实项目里代码量、对话量、工具调用量增长得比窗口快压缩迟早会发生。真正靠谱的做法是把记忆当成一个独立的、需要主动管理的系统。long_mem 负责持久化engram 负责索引代理负责执行三者之间靠明确的规则衔接。这套东西不复杂但需要你愿意花时间把规则定清楚。如果你现在正在用编码代理推进一个长项目我的建议是从今天开始每完成一个小单元就写一条决策记录别等。等压缩发生了再补补出来的往往是残缺的。这个习惯看起来笨但它是我这 430 条记录里唯一被反复验证有效的做法。