上下文压缩之后AI 编码代理怎么接得上一个 10 天、430 条公开记录的实验这事得从一次惨痛的经历说起。前阵子我接手了一个中型项目的迭代代码库不大但跨模块调用极多光是核心服务的依赖链就有六七层。为了提速我把一个 AI 编码代理接到了主仓库里让它帮我改一个横跨三四个模块的特性分支。一开始很顺代理能准确找到文件能理解我给的上下文改动质量也说得过去。但跑了两三个小时后问题开始冒出来它开始忘事。明明几分钟前刚确认过的变量命名转头就用了另一个版本明明已经查过某个接口的返回值结构它还是按旧签名去写调用代码。这根本不是模型能力的问题而是上下文被压没了。于是我把目光放到了“上下文压缩”这个方向上。花了 10 天时间跑了 430 条公开记录做了不少折腾。这篇文章就把这次实验的完整过程、踩过的坑、以及最终怎么让代理“接得上”的经验全部摊开来讲。1. 为什么上下文压缩会“掐断”编码代理的思路先说清楚上下文压缩到底在压缩什么。大语言模型的输入窗口是有限资源编码代理在和开发者对话、读文件、跑命令的过程中会把大量历史信息塞进上下文窗口。当内容超过模型的最大长度时常见的处理方式有两种要么强行截断把最早的内容丢掉要么做摘要压缩把冗长的历史对话和文件内容浓缩成简短的摘要。这两种方式本质上都是在“丢信息”。对于普通聊天场景丢掉几轮闲聊无关痛痒。但编码代理不一样它本质上是一个需要“跨步骤记忆”的智能体。改一个功能往往要经历“读文件 - 理解逻辑 - 生成改动 - 运行测试 - 修复报错”这个闭环每一步都依赖前面环节留下的关键细节。上下文一旦被压缩前面那个循环里的关键信息就可能丢失代理就会出现我在开头说的那种“失忆”行为。这里有个很容易被忽略的细节上下文压缩不是均匀丢信息而是基于摘要算法做取舍。目前多数实现会按 token 的重要性打分或者按对话轮次的时间远近做保留。但“算法认为重要”和“编码任务真正需要”往往是两码事。比如代理在第五轮对话里刚刚读取过一个配置文件的完整内容这个内容在第八轮的改动中要作为参考基准可压缩器可能觉得这个文件“只是被读了一下没有修改动作”就把它压成一句“用户提到了配置文件”关键字段全部蒸发。等到代理需要靠这个基准去写新代码时就只能靠猜。我这次实验的初衷就是想搞清楚当压缩发生后代理的“断链”到底是断在了哪几个关键环节以及有没有办法在压缩发生之前或之后把链条重新接上。1.1 实验目标和观测对象我给自己定的目标是回答三个问题第一上下文压缩发生后代理的错误率到底提升了多少第二哪些类型的任务最容易在压缩后翻车第三有没有可行的办法让代理在压缩之后依然保持足够的“任务连续性”。观测对象是一个开源的编码代理框架模型后端接了两种不同的模型配置一种是 32k 上下文窗口另一种是 128k。这样可以对比不同窗口范围下同样的压缩策略产生的不同影响。公开记录指的是代理运行时的对话日志、操作日志、token 消耗记录共 430 条全部来自这 10 天里我在本地和一台云服务器上跑的不同任务。实验任务分成三类第一类是“单文件小改动”比如修一个函数、改一个日志级别第二类是“跨文件中型重构”比如把一个工具函数从 A 模块迁移到 B 模块并更新所有调用方第三类是“跨服务链路排查”比如模拟新加入一个微服务调用要求代理找出所有需要修改的接口定义和调用点。分类的意义在于不同任务类型对上下文延续性的依赖程度完全不同。单文件改动可能只需要最近两轮对话的信息跨文件重构需要“文件地图 多个文件的局部内容 改动历史”跨服务链路排查则需要更长时间跨度的全局认识。我预期压缩对第三类任务的破坏力最大实验数据也基本证实了这一点。1.2 实验环境和记录方式实验环境分两套本地是一台 MacBook ProM 系列芯片32GB 内存云服务器是一台 4 核 8G 的 Linux 实例。代理工具跑在 Docker 里工作目录分别挂载了两个测试仓库一个是我自己的个人项目约 2 万行代码另一个是公开的模拟仓库特意准备了一些跨模块调用关系复杂的结构。记录方式是代理自带的会话日志加上我写的一个小脚本定时抓取 token 消耗和上下文窗口占用率。每次任务跑完我会手动打一个标签成功、失败、部分成功。部分成功指的是代理最终完成了任务但中间出现了明显的“忘记前文”行为比如重复读取同一个文件、重复确认同一个问题、或者生成了与之前操作矛盾的代码。430 条公开记录就是这么一条条攒下来的。后面所有数据和分析都来自这 430 条记录我不做任何理论推导只说实测结果。2. 实验观察压缩之后代理到底哪里“断链”了这 10 天跑下来最直观的感受是压缩对代理的影响不是“能力下降”而是“思路中断”。模型本身还是那个模型该会的还是会但它在错误的时间点失去了关键信息于是做出了错误的下游决策。我把断链现象归纳成了三类每一类都有典型的日志表现和后果。2.1 第一类断链文件级失忆这是最常见的一类占比大概在 45% 左右。表现是代理前几轮刚看过某个文件的核心逻辑但在压缩之后当它需要基于这个文件内容做修改时它不再引用文件里的真实内容而是基于自己的“想象”去写代码。举个例子有次我让它重构一个订单状态机的转换函数。前几轮它完整读取了order_state.py还总结了状态转换的合法路径。上下文压缩之后我让它把“待支付”状态增加一个超时自动取消的逻辑。它生成的代码居然是直接在Order类里加了一个cancel()方法完全没有考虑原有状态机的转换限制。后来我查日志发现压缩时那个“状态转换合法性总结”被丢弃了代理只记得“要加取消逻辑”但不记得“取消逻辑必须遵循状态机的转换规则”。文件级失忆的根源是压缩器在摘要代码文件时往往会保留“结构大纲”而丢失“细节约束”。结构大纲是文件名、类名、函数名这种骨架信息细节约束是函数内部的状态判断、异常处理分支、边界条件。对编码任务来说细节约束恰恰是命门。应对这个问题的思路我后面会详细讲核心结论是不要让代理依赖“压缩后的记忆”去操作文件而是要让它在关键动作之前重新读取原始文件。2.2 第二类断链指令级遗忘指令级遗忘指的是代理忘记了开发者明确下达的操作要求。这种断链在日志里表现得非常明显开发者说“不要修改测试文件”几轮之后代理还是动了test_开头的文件开发者说“使用 Python 3.11 的语法”压缩之后代理生成了 3.10 之前才支持的TypedDict写法。我统计了一下指令级遗忘在压缩后的任务里出现率约为 30%。它和文件级失忆的区别在于文件级失忆是“代理不知道文件内容”指令级遗忘是“代理不知道你想让它怎么干活”。这个现象的成因比较微妙。在长对话中早期用户指令会被压成摘要。摘要压缩的效果取决于压缩器对指令语意的理解——如果它只保留了“关键词”而丢失了“约束条件”那么代理在执行时就只记得“要改”不记得“不能怎么改”。比如“用 httpx 替换 requests保留原有超时配置”这种指令压缩后很可能变成“替换 HTTP 库”超时配置这个约束就丢了。我这里也发现了一个有意思的规律如果指令中包含了否定词“不要”“禁止”“避免”压缩后丢失的概率会显著升高。可能是压缩器在做信息取舍时倾向于保留肯定语义的动作而对否定性的约束不敏感。2.3 第三类断链策略级漂移策略级漂移是三者中最隐蔽的也是让代理整体输出质量断崖式下跌的元凶。它的表现是代理在前几轮已经确定了一套实施方案比如“先重构数据访问层再改业务逻辑层”但压缩之后它在后续操作中逐步偏离这个方案甚至走到了完全相反的方向。我印象最深的一次是跨文件重构任务。代理在任务初期明确说“为了降低风险先新增一个兼容层再逐步迁移调用方”。这个策略在上下文完整时执行得很好。但压缩发生后代理开始直接修改原有调用方代码完全跳过了兼容层方案造成了一系列连锁编译错误。日志显示它其实已经不记得自己定过“先加兼容层”这个策略了——压缩把早期会话里的“策略声明”压成了一句“已完成部分重构工作”。为什么策略级漂移破坏力最大因为它的影响是全局性的。文件级失忆最多影响一个文件的改动质量指令级遗忘可能导致局部行为偏离但策略级漂移会让整个任务的执行路径彻底改变后续所有步骤都建立在一个错误的地基上。从 430 条记录来看三种断链的出现概率大约是文件级失忆 45%指令级遗忘 30%策略级漂移 25%。注意这个数字不是互斥的很多任务会同时出现多种断链。但有一点很明确上下文压缩后代理的错误率从不压缩时的约 12% 飙升到了约 35%翻了三倍。3. 怎么让压缩后的代理“接得上”三条经过实测的解决路径观察数据只是第一步真正的挑战在于解决。这 10 天的后半段我集中火力测试了各种缓解措施最终沉淀出了三条有效路径。这三条路径不是理论推演是踩着坑趟出来的。3.1 结构锚点在对话中显式固化关键信息第一条路径的核心思想是既然压缩会丢信息那就在压缩发生之前把最关键的信息用“不易被压缩”的形式固化下来。什么叫“不易被压缩”的形式我用的是“结构锚点”也就是在与代理对话时定期让它把当前任务的关键信息整理成固定格式的清单。格式包括当前目标、已完成步骤、下一步计划、关键文件路径、关键约束条件、当前验证状态。实操上的做法是每完成一个阶段我会向代理发送一条特殊的指令让它输出当前状态的结构化摘要。这个摘要不是给我看的是给未来的代理看的。它的作用是如果上下文压缩把中间过程丢掉了至少保留了这样一份“任务快照”后续代理可以根据快照继续执行而不至于完全迷失。为什么这个方法有效关键在于压缩器对“结构化内容”的保留优先级往往更高。一段自然语言的对话可能被压成摘要但一段结构严谨的 Markdown 清单在摘要时更容易被完整保留。我实测的结果是使用结构化锚点之后策略级漂移的发生率降低了约 60%。因为代理哪怕丢了过程细节也能通过锚点恢复到正确的执行路径上。一个关键的实操细节是锚点不能太长。太长的锚点本身就容易被压缩截断。我试过把摘要写得非常详尽包括所有中间输出结果压缩后锚点本身也被破坏了。最佳长度是控制在 15 行以内只保留“目标 - 当前状态 - 下一步 - 关键约束”四项文件路径可以多列几个其他内容一律不写。3.2 检索增强压缩之前先建好“外部记忆”第二条路径是借鉴 RAG检索增强生成的思路把关键信息放到上下文窗口之外让代理在需要时主动去“查询”而不是依赖上下文窗口里的存量。具体做法是在仓库根目录下建立一个.agent-memory文件夹里面放几个 Markdown 文件分别记录项目结构、关键决策记录、常用命令、常见踩坑提示。在和代理对话开始之前我先让它读取这些文件并告知“后续所有操作都必须以这些文件中的记录为准如果发现上下文中有不一致的信息以这里的记录为准”。然后每完成一个重要步骤我会让代理把结果追加写到对应的记忆文件中。这样即使会话上下文被压缩得面目全非代理也能通过主动读取记忆文件来恢复关键信息。我在实验中对这个方案做了对比测试在启用外部记忆的情况下文件级失忆导致的问题减少了约 50%。原因不难理解代理在动手改代码之前已经养成了先查记忆文件的习惯而这个查询动作是实时的、不走压缩路径的所以准确率高得多。需要注意的一点外部记忆文件本身的维护成本不低。如果记忆文件写得混乱代理读取后反而会被误导。我踩过的坑是有些记录我写得过于口语化代理理解起来有歧义导致它按照错误的理解去操作。后来我定了一条规矩记忆文件只允许使用规范的结构化格式禁止口语化表述每条记录必须包含“背景 - 操作 - 结果 - 验证状态”四个要素缺一不可。3.3 压缩策略调优源头减少无谓的信息损耗第三条路径是从源头入手调整上下文压缩本身的行为减少无谓的信息损耗。这里要区分两个层面的压缩。第一层是模型自带的“上下文窗口截断”窗口满了之后必须丢内容这个我没法干预。第二层是代理框架自带的“摘要压缩”它在窗口还没满的时候就会主动把旧内容压成摘要以预留空间给新内容。第二层是可以干预的很多框架提供了参数来控制压缩的触发时机和摘要粒度。我用的框架支持几个关键参数context_compression_threshold控制压缩触发时上下文占用率阈值summary_preservation_tokens控制摘要保留的 token 数量prioritized_content_types控制哪些类型的内容优先保留。经过多轮调试我最终把阈值从默认的 60% 调到了 80%让压缩尽量晚触发把摘要保留长度从原来的 2000 token 调到了 4000 token给摘要更多的容量同时把“用户指令”和“文件内容”设置成高优先级让压缩器优先保留这两类信息。这套调整的效果是整体错误率从 35% 下降到了 22%效果显著。但它也有代价——token 消耗明显上升平均每个任务的 token 使用量增加了约 30%。对于 API 计费的用户来说这个成本要提前算清楚。不过我的判断是如果任务本身价值较高多花 30% 的 token 换取质量稳定是值得的。一个需要强调的细节是压缩阈值调高之后上下文窗口会更早进入“高占用”状态模型在生成时可能会因为窗口接近上限而自行截断输出。这个副作用我在测试中也遇到了——代理生成长代码时偶尔会突然中断出现不完整的代码片段。解决办法是配合“最大生成长度”参数一起调整给模型留出足够的生成余量。4. 十个典型问题与排查思路速查表这 10 天里还攒了一批非常具体的问题现象单拎出来都能写一篇小文章。我把最常遇到的十个问题汇总成一张速查表附上排查思路和解决办法。这些问题在我实测中反复出现如果你也在用编码代理大概率会碰到其中几个。问题现象根本原因排查思路解决办法代理重复读取同一个文件文件内容被压缩代理不记得已读查看对话日志确认读取行为发生在压缩之后使用外部记忆文件记录已读文件清单代理生成与之前矛盾的代码策略级漂移丢失了早期决策回看早期会话找出策略声明引入结构化锚点定期固化任务快照明确说“不要改”的文件还是被改了指令级遗忘否定词被压缩丢失检查压缩摘要中是否还有否定词把约束条件写入记忆文件并置顶代理中途开始“自我发挥”压缩后丢失了任务边界观察代理输出是否偏离任务描述重新发送任务描述并强调“以此为准”长代码生成中途截断上下文窗口接近上限模型被迫停止查看 token 消耗曲线调低压缩阈值或调大最大生成长度代理忘了“下一步计划”压缩丢失了阶段性规划检查代理输出的“下一步”是否突变使用结构化锚点保留下一步计划读取文件内容被摘要篡改摘要压缩时丢失细节约束对比原文和摘要的关键字段关键文件在修改前强制重新读取多次执行同一操作重复修复代理不记得已修复过检查操作日志中的重复记录在记忆文件中记录已完成修复的清单代理丢失了用户自定义规则自定义规则属于早期指令易被压缩检查规则是否出现在摘要中将规则写入.agent-memory置顶多文件任务只改了一个文件压缩丢失了全局文件地图观察文件列表是否在摘要中完整使用外部记忆文件保存文件地图这张表是 430 条公开记录里反复踩坑后提炼出来的。没有高深的理论每一个都是实操中真正遇到过的情况。排查的思路就是先确认问题发生在压缩之前还是之后如果压缩之前就错了那是理解问题如果压缩之后才错那才是记忆问题。4.1 绕不开的 Token 成本账最后想聊聊 token 成本这是上下文压缩实验里很容易被忽略但极其现实的问题。压缩本身是为了省 token但缓解压缩带来的副作用又会消耗额外的 token。这里存在一个跷跷板效应。从我的数据可以算一笔账。不用任何缓解措施的情况下一个跨文件任务的平均 token 消耗约 11 万使用外部记忆和结构化锚点之后平均涨到了 14.8 万再加上压缩策略调优进一步涨到 16 万左右。token 消耗大约增加了 45%但错误率从 35% 压到了 16%任务的人工返工时间节省了至少一半。这笔账怎么算划算取决于你任务的价值密度。如果是一个十分钟就能改完的小需求那多花 45% 的 token 去换稳定性不划算直接小上下文窗口跑完就行。但如果是一个需要跨多个模块、涉及大量历史决策的重构任务多花四五成 token 换来“不用返工、不用人工盯梢”那绝对是划算的。我的建议是轻量任务关闭压缩调优用默认策略重量任务开启全部缓解措施宁可多花 token 也要保证任务连续性。这 10 天的实验结论可以用一句话概括上下文压缩之后代理不是不能接关键是要给它“看得见的外部记忆”和“丢不掉的任务锚点”。这两个东西到位了压缩带来的断链问题基本都能接上。