1. 上下文压缩这件事为什么编码代理最容易翻车先把场景摆出来。你让一个 AI 编码代理去改一个中型项目它得先读文件、看依赖、翻历史提交、理解模块之间的调用关系。这些内容全塞进上下文窗口很快就撑满了。撑满之后有两条路要么截断要么压缩。截断简单粗暴直接丢掉最早的内容压缩则聪明一点把旧内容总结成一段更短的摘要腾出空间给新内容。问题就出在压缩这一步。普通的对话场景里压缩丢点细节无所谓反正用户下一句会补充。但编码代理不一样它依赖的是精确的符号信息函数名、变量名、文件路径、类型定义、导入关系。你把parseConfig压缩成一个解析配置的函数代理再想调用它的时候就抓瞎了。更麻烦的是压缩往往是有损的、不可逆的一旦关键约束被抹掉代理后面生成的代码就会基于错误的假设往下走越走越偏。我见过太多这样的案例代理前 20 轮表现完美第 21 轮突然开始引用一个根本不存在的函数或者把已经改过的接口又改回去。表面看是模型变笨了实际上是上下文压缩把它的记忆搞乱了。这个项目标题里提到的10 天、430 条公开记录本质上就是在系统性地观察这件事压缩之后代理到底还能不能接得上这里要先厘清一个概念。所谓接得上包含三层含义。第一层是事实接续代理还记得之前做过什么、改过哪些文件。第二层是约束接续代理还记得项目里的硬性规则比如某个模块不能引入新依赖、某个接口签名不能变。第三层是意图接续代理还记得用户最初的目标是什么不会在中途跑偏。上下文压缩对这三层的破坏程度是不一样的事实最容易丢约束次之意图相对顽强但也扛不住反复压缩。关键词里出现的 long_mem 和 engram其实指向的就是解决思路的两大流派。long_mem 走的是外部记忆库路线把重要信息存到上下文之外需要时再检索回来engram 更偏向把记忆做成一种可寻址的结构类似给代理装一个记忆索引。这两条路各有取舍后面会展开讲。而 Codex 作为编码代理的代表性工具它的上下文管理策略直接决定了实验的观察对象。提示判断一个编码代理是否接得上不要只看它单轮输出对不对要看它在压缩发生后的第 3 到第 5 轮是否还能保持一致性。压缩的破坏往往是延迟显现的。2. 430 条记录是怎么攒出来的实验设计与观察维度2.1 为什么是 10 天而不是 10 小时10 天这个周期不是随便定的。编码代理的上下文问题有个特点短会话里几乎看不出来。你跑一个 10 轮的小任务上下文根本没到压缩阈值一切正常。只有把任务拉长到几十轮、上百轮压缩被触发多次之后问题才会暴露。10 天的时间跨度意味着实验覆盖了不同规模的任务、不同类型的压缩触发点也覆盖了代理在多次压缩叠加后的表现。430 条公开记录平均下来每天 43 条。这个密度说明记录的不是最终结果而是过程性观察。每条记录大概包含当前轮次、上下文占用比例、是否触发了压缩、压缩前后的关键信息对比、代理本轮输出的正确性判断。这种颗粒度的记录才能支撑后面做归因分析。2.2 观察维度不能只看对错如果只用这轮输出对不对来打分会漏掉大量信息。一个代理可能这轮输出是对的但它依据的是已经被压缩扭曲的记忆下一轮就会错。所以实验的观察维度至少要拆成四层观察维度具体指标为什么重要事实一致性引用的文件/函数是否真实存在最容易被压缩破坏约束遵守度是否违反项目硬性规则破坏后修复成本高意图偏移度是否偏离原始目标反映长期记忆质量恢复能力被纠正后能否回到正轨衡量代理的鲁棒性这四个维度里恢复能力是最容易被忽略但最有价值的。有些代理压缩后确实会犯错但你一提醒它就能改回来有些则一错到底怎么纠正都没用。后者说明它的记忆结构已经被彻底打乱不是忘了而是记错了。2.3 记录方式决定了你能发现什么430 条记录如果只是流水账价值有限。真正有用的是结构化记录每条记录都标注了压缩发生的位置、压缩策略、被压缩掉的内容类型。这样你才能回答哪种内容被压缩后最容易导致代理翻车这种问题。我的经验是被压缩内容按危险程度排序大概是类型定义和接口签名 跨文件的调用关系 具体的业务规则 一般的实现细节。类型定义一旦丢失代理就会凭空捏造字段调用关系丢失代理就会重复实现已有功能业务规则丢失代理就会写出技术上正确但业务上错误的代码。3. long_mem 与 engram两条记忆路线的真实取舍3.1 long_mem 的本质是外挂硬盘long_mem 的思路很直白既然上下文窗口装不下那就把记忆存到外面去。代理在运行过程中把关键信息写进一个外部存储需要的时候再查回来。这就像给电脑加了一块外挂硬盘内存不够就往硬盘上放。这条路线的优点是容量几乎无限而且记忆可以跨会话持久化。今天没做完的任务明天接着做代理还能记得之前的进展。但缺点也很明显检索质量决定一切。如果检索回来的内容不相关或者漏掉了关键信息代理照样翻车。而且检索本身要消耗时间和 token频繁检索会拖慢整体速度。实操中long_mem 最容易踩的坑是存了但没存对。很多实现只存了结论没存结论的上下文。比如存了用户要求用 A 方案但没存为什么排除 B 方案。等代理下次检索到这条记忆时它可能会重新考虑 B 方案因为它不知道 B 已经被否决过了。3.2 engram 更像记忆索引engram 这个词本身有记忆痕迹的意思它的思路不是简单存储而是建立一种可寻址的记忆结构。你可以理解为给每条记忆打上标签和关联让代理能顺着线索找到相关内容。这比 long_mem 的关键词检索要精细但也更复杂。engram 的核心难点在于关联的建立和维护。一条记忆和哪些其他记忆相关这个关系是静态的还是动态的如果关联建错了代理会顺着错误的线索越走越远。我实测下来engram 在结构化程度高的项目里表现很好因为模块之间的依赖关系本身就清晰但在那种祖传代码式的项目里关联关系一团乱麻engram 反而容易帮倒忙。3.3 两条路线不是二选一实际项目里long_mem 和 engram 往往是配合使用的。long_mem 负责存得住engram 负责找得准。先用 long_mem 把信息持久化再用 engram 的结构去组织检索路径。这个组合的关键在于写入策略什么信息值得存什么信息存了反而添乱。我的判断标准是能被验证的信息才值得存。比如文件 X 的第 42 行定义了函数 Y这种可验证的事实存了有用而用户可能想要 Z这种推测存了就是噪音。430 条记录里相当一部分翻车案例都源于存了太多未经验证的推测。4. Codex 类代理的上下文管理从机制到实操4.1 压缩触发点在哪里Codex 这类编码代理上下文管理通常有几个关键阈值。第一个是软阈值达到这个比例时开始预警可能会主动做一次轻量压缩。第二个是硬阈值超过就必须压缩否则新内容进不来。第三个是紧急阈值这时候压缩会很激进可能直接丢掉整段历史。理解这三个阈值的区别很重要。软阈值下的压缩通常比较温和只压缩最老的内容紧急阈值下的压缩则可能把最近几轮也一起压了导致代理刚做的事就忘了。430 条记录里最严重的翻车基本都发生在紧急压缩之后。4.2 压缩策略的选择逻辑常见的压缩策略有三种摘要式、抽取式、丢弃式。摘要式用模型把旧内容重写成短摘要抽取式只保留关键句丢弃式直接删。三者的信息损失程度依次递增但计算成本依次递减。策略信息保留计算成本适用场景摘要式高高关键任务、约束多的项目抽取式中中一般开发任务丢弃式低低探索性、可重来的任务选择策略时不能只看成本。一个约束密集的项目用丢弃式压缩省下的那点算力远不够弥补后面返工的代价。我的建议是任务越接近生产环境越要用保守的压缩策略。4.3 让代理接得上的三个实操动作第一个动作是显式锚点。在关键节点让代理主动记录一条锚点信息比如当前已完成 X下一步要做 Y约束是 Z。这条锚点要写得足够具体压缩时优先保留。这相当于给代理的记忆打了个桩。第二个动作是压缩后自检。每次压缩发生后让代理复述一遍当前的任务状态和关键约束。如果复述有偏差立刻纠正。这个动作成本很低但能拦住大量延迟性错误。第三个动作是分段提交。不要等整个任务做完再验证每完成一个可独立验证的小段就提交一次。这样即使后面压缩出了问题前面的成果也是安全的回滚成本低。注意压缩后自检这个动作一定要在压缩发生的下一轮就做不能拖。拖得越久错误记忆被引用的次数越多纠正成本越高。5. 那些记录里反复出现的翻车模式5.1 函数签名漂移这是最高频的问题。代理在压缩前明明知道createUser(name, email, role)这个签名压缩后变成了createUser(name, email)然后它就开始用两个参数去调用编译直接报错。更隐蔽的是它可能自己补了一个默认参数代码能跑但行为错了。根因在于签名这种信息高度依赖精确符号摘要式压缩很容易把它模糊化。解决办法是在压缩策略里给函数签名、类型定义这类内容打上不可压缩标记原样保留。5.2 重复实现代理压缩后忘了某个功能已经实现过于是又写了一遍。这在大型项目里特别常见因为功能分散在多个文件压缩时很容易丢掉这个功能在哪的索引。结果就是代码库里出现两个功能重叠的函数后面维护的人一脸懵。这个问题的预防手段是维护一份功能清单放在上下文里相对固定的位置压缩时优先保留。清单不需要详细只要记录功能名 - 所在文件就够了。5.3 约束遗忘导致的连锁错误最典型的是不要引入新依赖这条约束被压缩掉。代理为了图方便引入了一个新库然后基于这个库写了一堆代码。等你发现的时候要么接受新依赖要么大改。这类错误的修复成本极高因为它污染的不只是一处代码。约束类信息应该单独管理不参与常规压缩。可以把它放在系统提示的固定区域或者用 long_mem 持久化每次关键操作前检索一次。5.4 意图漂移代理做着做着目标从修复登录 bug变成了重构登录模块。这不是它故意的而是压缩过程中原始意图被稀释了。每压缩一次意图就模糊一点几轮下来就面目全非。对抗意图漂移的办法是意图复述。每隔几轮让代理用一句话复述当前目标和最初的目标对比。一旦发现偏移立刻拉回来。6. 把实验结论落到日常开发里6.1 任务拆分比压缩策略更重要与其纠结怎么压缩不如从源头减少压缩的需求。把大任务拆成小任务每个小任务在上下文还没撑满时就完成并提交。这样压缩根本不会被触发问题自然消失。430 条记录里那些接得上表现好的案例绝大多数都是任务拆分做得细的。拆分的粒度怎么定我的经验是一个任务如果预计超过 30 轮对话就该拆。30 轮是个经验值具体还要看每轮的信息密度。信息密度高的任务可能 15 轮就该拆。6.2 给代理一份项目宪法所谓项目宪法就是一份简短但硬性的规则清单放在上下文最稳定的位置。内容包括技术栈约束、代码风格、禁止事项、关键接口签名。这份宪法不参与压缩每次会话开始都重新注入。宪法要短最好控制在一屏以内。太长了反而会被压缩机制盯上。只放那些违反了就会出大问题的规则一般的风格偏好可以不放。6.3 建立压缩日志每次压缩发生时记录下压缩了什么、保留了什么。这份日志平时不看但一旦代理出现诡异行为它就是排查的第一手资料。你可以快速定位到哦原来是那次压缩把接口定义弄丢了。日志不用很复杂一个简单的表格就够时间、触发原因、压缩策略、丢失的关键信息、后续是否出问题。坚持记一段时间你就能总结出自己项目里最不能丢的信息类型。6.4 人工介入的时机不要指望代理完全自主地处理压缩问题。有些节点必须人工介入任务目标变更时、发现代理开始重复劳动时、连续两轮输出出现事实错误时。这些信号出现说明记忆已经不可靠了继续让它自主跑只会越跑越偏。介入的方式不是直接改代码而是重置记忆。把当前的真实状态、关键约束、下一步目标重新明确地告诉代理相当于给它做一次记忆校准。这比在错误的记忆上修修补补有效得多。7. 我在这 10 天里踩过的几个坑第一个坑是过度信任摘要。一开始我觉得摘要式压缩很智能就放任它压。结果发现摘要会把这个函数返回 null 表示失败这种关键语义压成这个函数返回结果语义完全变了。后来我给摘要加了约束涉及返回值语义、异常行为、边界条件的内容必须原样保留。第二个坑是锚点写得太笼统。我一开始让代理记正在处理用户模块这种锚点等于没记。后来改成正在给 UserService 的 updateProfile 方法加邮箱格式校验约束是不能改方法签名效果立竿见影。第三个坑是忽略检索延迟。用 long_mem 的时候我没考虑检索本身要花时间。高频检索把整体速度拖慢了一倍多。后来改成批量检索加缓存才把速度拉回来。这个教训是外部记忆不是免费的检索成本要算进整体预算。第四个坑是在错误的层级做压缩。我一开始按轮次压缩把最早的几轮直接压掉。但最早的几轮往往包含任务定义和初始约束压掉它们等于把地基抽了。后来改成按信息类型压缩优先压掉过程性的调试信息保留定义和约束问题少了很多。8. 关于长期记忆一个还没解决的问题long_mem 和 engram 能解决存和找的问题但解决不了更新的问题。项目在演进旧的记忆会过时。比如某个接口三个月前改了签名但 long_mem 里还存着旧签名代理检索到旧的就用错了。engram 的关联结构也一样关联关系会随着代码重构而失效。目前的处理办法是定期清理加版本标记。给每条记忆打上时间戳和版本号检索时优先用最新的。但这只是缓解不是根治。真正理想的状态是记忆能跟着代码自动更新代码改了相关记忆自动失效或刷新。这个方向目前还在探索没有成熟的方案。我在实操中的做法是关键记忆手动维护非关键记忆定期清理。关键的就是那些错了会出大问题的比如接口签名、核心约束这些手动更新确保准确。非关键的比如调试过程、临时决策定期清掉避免积累噪音。这个策略不优雅但管用。回到标题里的那个问题上下文压缩之后AI 编码代理怎么接得上我的答案是靠的不是某一个神奇的技术而是一整套记忆管理习惯。压缩策略要选对锚点要打准自检要及时任务要拆细人工介入要果断。这五件事做到位代理在压缩后接不上的概率会大幅下降。430 条记录看下来那些表现稳定的案例没有一个是靠单一技巧撑住的都是这套组合拳打得好。 
长河君 · 2026/10/28 5:32:13 · 阅读 1.2k 上下文压缩后AI编码代理如何接得上？10天430条记录揭示长期记忆管理策略
1. 上下文压缩这件事为什么编码代理最容易翻车先把场景摆出来。你让一个 AI 编码代理去改一个中型项目它得先读文件、看依赖、翻历史提交、理解模块之间的调用关系。这些内容全塞进上下文窗口很快就撑满了。撑满之后有两条路要么截断要么压缩。截断简单粗暴直接丢掉最早的内容压缩则聪明一点把旧内容总结成一段更短的摘要腾出空间给新内容。问题就出在压缩这一步。普通的对话场景里压缩丢点细节无所谓反正用户下一句会补充。但编码代理不一样它依赖的是精确的符号信息函数名、变量名、文件路径、类型定义、导入关系。你把parseConfig压缩成一个解析配置的函数代理再想调用它的时候就抓瞎了。更麻烦的是压缩往往是有损的、不可逆的一旦关键约束被抹掉代理后面生成的代码就会基于错误的假设往下走越走越偏。我见过太多这样的案例代理前 20 轮表现完美第 21 轮突然开始引用一个根本不存在的函数或者把已经改过的接口又改回去。表面看是模型变笨了实际上是上下文压缩把它的记忆搞乱了。这个项目标题里提到的10 天、430 条公开记录本质上就是在系统性地观察这件事压缩之后代理到底还能不能接得上这里要先厘清一个概念。所谓接得上包含三层含义。第一层是事实接续代理还记得之前做过什么、改过哪些文件。第二层是约束接续代理还记得项目里的硬性规则比如某个模块不能引入新依赖、某个接口签名不能变。第三层是意图接续代理还记得用户最初的目标是什么不会在中途跑偏。上下文压缩对这三层的破坏程度是不一样的事实最容易丢约束次之意图相对顽强但也扛不住反复压缩。关键词里出现的 long_mem 和 engram其实指向的就是解决思路的两大流派。long_mem 走的是外部记忆库路线把重要信息存到上下文之外需要时再检索回来engram 更偏向把记忆做成一种可寻址的结构类似给代理装一个记忆索引。这两条路各有取舍后面会展开讲。而 Codex 作为编码代理的代表性工具它的上下文管理策略直接决定了实验的观察对象。提示判断一个编码代理是否接得上不要只看它单轮输出对不对要看它在压缩发生后的第 3 到第 5 轮是否还能保持一致性。压缩的破坏往往是延迟显现的。2. 430 条记录是怎么攒出来的实验设计与观察维度2.1 为什么是 10 天而不是 10 小时10 天这个周期不是随便定的。编码代理的上下文问题有个特点短会话里几乎看不出来。你跑一个 10 轮的小任务上下文根本没到压缩阈值一切正常。只有把任务拉长到几十轮、上百轮压缩被触发多次之后问题才会暴露。10 天的时间跨度意味着实验覆盖了不同规模的任务、不同类型的压缩触发点也覆盖了代理在多次压缩叠加后的表现。430 条公开记录平均下来每天 43 条。这个密度说明记录的不是最终结果而是过程性观察。每条记录大概包含当前轮次、上下文占用比例、是否触发了压缩、压缩前后的关键信息对比、代理本轮输出的正确性判断。这种颗粒度的记录才能支撑后面做归因分析。2.2 观察维度不能只看对错如果只用这轮输出对不对来打分会漏掉大量信息。一个代理可能这轮输出是对的但它依据的是已经被压缩扭曲的记忆下一轮就会错。所以实验的观察维度至少要拆成四层观察维度具体指标为什么重要事实一致性引用的文件/函数是否真实存在最容易被压缩破坏约束遵守度是否违反项目硬性规则破坏后修复成本高意图偏移度是否偏离原始目标反映长期记忆质量恢复能力被纠正后能否回到正轨衡量代理的鲁棒性这四个维度里恢复能力是最容易被忽略但最有价值的。有些代理压缩后确实会犯错但你一提醒它就能改回来有些则一错到底怎么纠正都没用。后者说明它的记忆结构已经被彻底打乱不是忘了而是记错了。2.3 记录方式决定了你能发现什么430 条记录如果只是流水账价值有限。真正有用的是结构化记录每条记录都标注了压缩发生的位置、压缩策略、被压缩掉的内容类型。这样你才能回答哪种内容被压缩后最容易导致代理翻车这种问题。我的经验是被压缩内容按危险程度排序大概是类型定义和接口签名 跨文件的调用关系 具体的业务规则 一般的实现细节。类型定义一旦丢失代理就会凭空捏造字段调用关系丢失代理就会重复实现已有功能业务规则丢失代理就会写出技术上正确但业务上错误的代码。3. long_mem 与 engram两条记忆路线的真实取舍3.1 long_mem 的本质是外挂硬盘long_mem 的思路很直白既然上下文窗口装不下那就把记忆存到外面去。代理在运行过程中把关键信息写进一个外部存储需要的时候再查回来。这就像给电脑加了一块外挂硬盘内存不够就往硬盘上放。这条路线的优点是容量几乎无限而且记忆可以跨会话持久化。今天没做完的任务明天接着做代理还能记得之前的进展。但缺点也很明显检索质量决定一切。如果检索回来的内容不相关或者漏掉了关键信息代理照样翻车。而且检索本身要消耗时间和 token频繁检索会拖慢整体速度。实操中long_mem 最容易踩的坑是存了但没存对。很多实现只存了结论没存结论的上下文。比如存了用户要求用 A 方案但没存为什么排除 B 方案。等代理下次检索到这条记忆时它可能会重新考虑 B 方案因为它不知道 B 已经被否决过了。3.2 engram 更像记忆索引engram 这个词本身有记忆痕迹的意思它的思路不是简单存储而是建立一种可寻址的记忆结构。你可以理解为给每条记忆打上标签和关联让代理能顺着线索找到相关内容。这比 long_mem 的关键词检索要精细但也更复杂。engram 的核心难点在于关联的建立和维护。一条记忆和哪些其他记忆相关这个关系是静态的还是动态的如果关联建错了代理会顺着错误的线索越走越远。我实测下来engram 在结构化程度高的项目里表现很好因为模块之间的依赖关系本身就清晰但在那种祖传代码式的项目里关联关系一团乱麻engram 反而容易帮倒忙。3.3 两条路线不是二选一实际项目里long_mem 和 engram 往往是配合使用的。long_mem 负责存得住engram 负责找得准。先用 long_mem 把信息持久化再用 engram 的结构去组织检索路径。这个组合的关键在于写入策略什么信息值得存什么信息存了反而添乱。我的判断标准是能被验证的信息才值得存。比如文件 X 的第 42 行定义了函数 Y这种可验证的事实存了有用而用户可能想要 Z这种推测存了就是噪音。430 条记录里相当一部分翻车案例都源于存了太多未经验证的推测。4. Codex 类代理的上下文管理从机制到实操4.1 压缩触发点在哪里Codex 这类编码代理上下文管理通常有几个关键阈值。第一个是软阈值达到这个比例时开始预警可能会主动做一次轻量压缩。第二个是硬阈值超过就必须压缩否则新内容进不来。第三个是紧急阈值这时候压缩会很激进可能直接丢掉整段历史。理解这三个阈值的区别很重要。软阈值下的压缩通常比较温和只压缩最老的内容紧急阈值下的压缩则可能把最近几轮也一起压了导致代理刚做的事就忘了。430 条记录里最严重的翻车基本都发生在紧急压缩之后。4.2 压缩策略的选择逻辑常见的压缩策略有三种摘要式、抽取式、丢弃式。摘要式用模型把旧内容重写成短摘要抽取式只保留关键句丢弃式直接删。三者的信息损失程度依次递增但计算成本依次递减。策略信息保留计算成本适用场景摘要式高高关键任务、约束多的项目抽取式中中一般开发任务丢弃式低低探索性、可重来的任务选择策略时不能只看成本。一个约束密集的项目用丢弃式压缩省下的那点算力远不够弥补后面返工的代价。我的建议是任务越接近生产环境越要用保守的压缩策略。4.3 让代理接得上的三个实操动作第一个动作是显式锚点。在关键节点让代理主动记录一条锚点信息比如当前已完成 X下一步要做 Y约束是 Z。这条锚点要写得足够具体压缩时优先保留。这相当于给代理的记忆打了个桩。第二个动作是压缩后自检。每次压缩发生后让代理复述一遍当前的任务状态和关键约束。如果复述有偏差立刻纠正。这个动作成本很低但能拦住大量延迟性错误。第三个动作是分段提交。不要等整个任务做完再验证每完成一个可独立验证的小段就提交一次。这样即使后面压缩出了问题前面的成果也是安全的回滚成本低。注意压缩后自检这个动作一定要在压缩发生的下一轮就做不能拖。拖得越久错误记忆被引用的次数越多纠正成本越高。5. 那些记录里反复出现的翻车模式5.1 函数签名漂移这是最高频的问题。代理在压缩前明明知道createUser(name, email, role)这个签名压缩后变成了createUser(name, email)然后它就开始用两个参数去调用编译直接报错。更隐蔽的是它可能自己补了一个默认参数代码能跑但行为错了。根因在于签名这种信息高度依赖精确符号摘要式压缩很容易把它模糊化。解决办法是在压缩策略里给函数签名、类型定义这类内容打上不可压缩标记原样保留。5.2 重复实现代理压缩后忘了某个功能已经实现过于是又写了一遍。这在大型项目里特别常见因为功能分散在多个文件压缩时很容易丢掉这个功能在哪的索引。结果就是代码库里出现两个功能重叠的函数后面维护的人一脸懵。这个问题的预防手段是维护一份功能清单放在上下文里相对固定的位置压缩时优先保留。清单不需要详细只要记录功能名 - 所在文件就够了。5.3 约束遗忘导致的连锁错误最典型的是不要引入新依赖这条约束被压缩掉。代理为了图方便引入了一个新库然后基于这个库写了一堆代码。等你发现的时候要么接受新依赖要么大改。这类错误的修复成本极高因为它污染的不只是一处代码。约束类信息应该单独管理不参与常规压缩。可以把它放在系统提示的固定区域或者用 long_mem 持久化每次关键操作前检索一次。5.4 意图漂移代理做着做着目标从修复登录 bug变成了重构登录模块。这不是它故意的而是压缩过程中原始意图被稀释了。每压缩一次意图就模糊一点几轮下来就面目全非。对抗意图漂移的办法是意图复述。每隔几轮让代理用一句话复述当前目标和最初的目标对比。一旦发现偏移立刻拉回来。6. 把实验结论落到日常开发里6.1 任务拆分比压缩策略更重要与其纠结怎么压缩不如从源头减少压缩的需求。把大任务拆成小任务每个小任务在上下文还没撑满时就完成并提交。这样压缩根本不会被触发问题自然消失。430 条记录里那些接得上表现好的案例绝大多数都是任务拆分做得细的。拆分的粒度怎么定我的经验是一个任务如果预计超过 30 轮对话就该拆。30 轮是个经验值具体还要看每轮的信息密度。信息密度高的任务可能 15 轮就该拆。6.2 给代理一份项目宪法所谓项目宪法就是一份简短但硬性的规则清单放在上下文最稳定的位置。内容包括技术栈约束、代码风格、禁止事项、关键接口签名。这份宪法不参与压缩每次会话开始都重新注入。宪法要短最好控制在一屏以内。太长了反而会被压缩机制盯上。只放那些违反了就会出大问题的规则一般的风格偏好可以不放。6.3 建立压缩日志每次压缩发生时记录下压缩了什么、保留了什么。这份日志平时不看但一旦代理出现诡异行为它就是排查的第一手资料。你可以快速定位到哦原来是那次压缩把接口定义弄丢了。日志不用很复杂一个简单的表格就够时间、触发原因、压缩策略、丢失的关键信息、后续是否出问题。坚持记一段时间你就能总结出自己项目里最不能丢的信息类型。6.4 人工介入的时机不要指望代理完全自主地处理压缩问题。有些节点必须人工介入任务目标变更时、发现代理开始重复劳动时、连续两轮输出出现事实错误时。这些信号出现说明记忆已经不可靠了继续让它自主跑只会越跑越偏。介入的方式不是直接改代码而是重置记忆。把当前的真实状态、关键约束、下一步目标重新明确地告诉代理相当于给它做一次记忆校准。这比在错误的记忆上修修补补有效得多。7. 我在这 10 天里踩过的几个坑第一个坑是过度信任摘要。一开始我觉得摘要式压缩很智能就放任它压。结果发现摘要会把这个函数返回 null 表示失败这种关键语义压成这个函数返回结果语义完全变了。后来我给摘要加了约束涉及返回值语义、异常行为、边界条件的内容必须原样保留。第二个坑是锚点写得太笼统。我一开始让代理记正在处理用户模块这种锚点等于没记。后来改成正在给 UserService 的 updateProfile 方法加邮箱格式校验约束是不能改方法签名效果立竿见影。第三个坑是忽略检索延迟。用 long_mem 的时候我没考虑检索本身要花时间。高频检索把整体速度拖慢了一倍多。后来改成批量检索加缓存才把速度拉回来。这个教训是外部记忆不是免费的检索成本要算进整体预算。第四个坑是在错误的层级做压缩。我一开始按轮次压缩把最早的几轮直接压掉。但最早的几轮往往包含任务定义和初始约束压掉它们等于把地基抽了。后来改成按信息类型压缩优先压掉过程性的调试信息保留定义和约束问题少了很多。8. 关于长期记忆一个还没解决的问题long_mem 和 engram 能解决存和找的问题但解决不了更新的问题。项目在演进旧的记忆会过时。比如某个接口三个月前改了签名但 long_mem 里还存着旧签名代理检索到旧的就用错了。engram 的关联结构也一样关联关系会随着代码重构而失效。目前的处理办法是定期清理加版本标记。给每条记忆打上时间戳和版本号检索时优先用最新的。但这只是缓解不是根治。真正理想的状态是记忆能跟着代码自动更新代码改了相关记忆自动失效或刷新。这个方向目前还在探索没有成熟的方案。我在实操中的做法是关键记忆手动维护非关键记忆定期清理。关键的就是那些错了会出大问题的比如接口签名、核心约束这些手动更新确保准确。非关键的比如调试过程、临时决策定期清掉避免积累噪音。这个策略不优雅但管用。回到标题里的那个问题上下文压缩之后AI 编码代理怎么接得上我的答案是靠的不是某一个神奇的技术而是一整套记忆管理习惯。压缩策略要选对锚点要打准自检要及时任务要拆细人工介入要果断。这五件事做到位代理在压缩后接不上的概率会大幅下降。430 条记录看下来那些表现稳定的案例没有一个是靠单一技巧撑住的都是这套组合拳打得好。