这十天我一直在折腾一个看起来有点“自虐”的实验让同一个AI编码代理反复把上下文压缩到指定的临界点再让它接着干活前后一共攒了430条带日志的公开执行记录。起因特别简单——我手头一个中等规模的重构任务跑到一半对话窗口爆了系统自动把历史压缩成一页摘要然后代理当场“失忆”不知道自己改到哪个文件、为什么改、下一步该跑哪条命令。这种“压缩之后接不上”的问题但凡用AI编码代理处理过长任务的人迟早都会撞上。我想搞清楚一件事上下文压缩之后AI编码代理到底靠什么才能“无缝接续”是摘要写得够详细还是压缩前留了什么特殊的钩子为这事我设计了控制变量的对照实验连续跑了十天把压缩强度、任务类型、接续方式、成败结果全部落到结构化记录里。这篇文章不是讲大模型原理而是把我踩过的坑、验证过的方法论、以及430条数据里浮出来的规律一次性讲透。适合正在用AI编码代理做真实开发、或者自己开发智能体编排层的人参考。1. 先把问题说清楚压缩之后为什么“接不上”1.1 AI编码代理的上下文是怎么被耗尽的要理解“接不上”得先理解AI编码代理的工作方式。它跟普通的单轮问答不一样是一个多步骤的自主执行体读仓库结构、看具体文件、写修改计划、逐个文件改代码、跑测试、看报错、再修复、循环往复。这个过程每一步都会产生大量token尤其是读文件和看测试日志消耗速度远超正常人聊天。比如一次涉及五个模块的接口重构光是把相关代码读一遍可能就吃掉十几万token。这里有个容易被忽略的事实模型上下文窗口的数字很大但实际“有效工作区间”远远没那么宽。窗口塞得太满模型对早期内容的注意力会变差表现方式就是这个指令没执行、那个工具忘了调甚至把任务目标都记模糊了。所以做AI编码代理的人不能等窗口彻底满了才处理而是要在执行过程中主动做上下文瘦身。可问题恰恰出在瘦身后的那一下历史被压缩之后代理面对的是一段新的、不连续的文本输入它跟之前那个“有完整记忆的代理”在信息量上已经不是同一个物种。我自己常用一个类比上下文窗口就像一张有限的桌面。干活之前你可以把参考资料摊一桌子但桌子就那么大越干越满最终必须收起一部分文件才能继续放下新东西。压缩就是“收文件”的动作问题是如果你收的时候没有做标注等会儿想再找某个细节就得翻箱倒柜。对编码代理来说翻箱倒柜的成本极高——它没有人类的常识和身体记忆。1.2 压缩的本质从连续叙事到离散摘要很多人对上下文压缩有个错误理解以为它是“删掉一半对话”。实际在主流的压缩方案里系统会让大模型把已有的完整对话历史读一遍然后生成一段摘要再把摘要塞回上下文替代原来的全部内容。这个过程把“连续的、带时序和因果关系的原始过程”变成了“离散的、抽象化的最终结论”。这一转变非常微妙但致命。原始对话里自带过程知识之前为什么选了方案A而不是方案B、某段代码是在什么约束下写出来的、测试失败时试过了哪几种修法。这些信息不直接出现在最终代码里但对后续工作至关重要。压缩摘要通常会保留结果而丢掉过程比如写上“已修复鉴权逻辑”但完全没提当初为什么不用Redis方案——因为那个维护成本太高。压缩后的代理拿到摘要只知道结论不知道边界继续工作时很容易把已经被否定的方案又重新“发明”一遍。我做了一个很小的测试就能说明问题同一个重构任务在上下文未压缩时代理能准确回答“为什么不直接用继承”因为对话里有一大段关于原型链和耦合度的讨论压缩之后它斩钉截铁地推荐用继承理由还特别充分。这个现象就是离散摘要丢掉过程推理的典型代价。1.3 多数压缩方案翻车的三个原因我把十天里观察到的“接不上”归因成三类根因几乎覆盖了所有失败样本。第一个原因是只压缩不建档。系统把历史压成摘要却不同步保存工具调用记录、文件状态、未完成任务清单等结构化信息。代理只有一段散文式摘要没有“操作台账”自然没法恢复执行位置。第二个原因是摘要写法太像“工作总结”。人类的工作总结面向领导强调结果和亮点而编码代理需要的摘要面向“未来的自己”强调当前状态、下一步动作和注意边界。这个视角的偏差导致摘要里充斥着“已实现XXX功能”这类大而全的表述却没有“src/config.py 第147行的常量还没改改完记得跑 tests/test_config.py”这类真正有用的接续信息。第三个原因是没有验证环节。压缩完直接让它继续干活不做任何状态核对。代理基于摘要形成新一轮计划但这个计划的前提很可能已经过时。没有验证的接续本质就是让代理在不确定的地基上盖楼。认清这三个原因之后我的整个实验目标就变成了找到一套能让压缩后的代理完成“状态重建”的方法而不是单纯追求“摘要写得多详细”。2. 十天的实验怎么设计430条公开记录的采集方法2.1 先定基线环境、模型和任务库实验如果变量太多结论就是一堆废数据。我强迫自己先锁死几个关键变量。第一模型固定。整个实验期间只用同一款商用闭源模型参数、温度全部保持默认配置不升级版本不做任何针对实验的诱导弹性调整。否则中途换个模型成功率变化是模型的功劳还是压缩策略的功劳根本说不清。第二仓库固定。我拿我自己维护的一个中型Node.js项目当测试场代码量约两万行包含完整的测试套件。这个项目我熟悉每一个角落能准确判断代理干得好坏同时它结构足够复杂具备触发上下文耗尽的天然条件。第三任务库固定。我把实验任务分成四类缺陷修复、模块重构、新功能开发、测试补充。每一类准备多个具体任务控制在相近的规模区间里。比如缺陷修复都是“一个文件内能定位、需要动5到15行代码”的级别模块重构都是“涉及二到四个文件、需要保持接口兼容”的级别。如此控制之后失败率的差异才有横向可比性。十天的节奏是每天早中晚各跑一批每批三到五条任务加上各种对照组轮换累计达到430条有效记录。这里说的“公开记录”指每一条任务都有完整的原始日志按日期和任务ID归档在公开仓库里压缩前的上下文长度、压缩后的摘要全文、最终执行结果全部可回溯。2.2 一条记录里到底要记什么记录字段的设计直接决定实验能挖出什么规律。我最终固定下来的字段有七个任务ID、任务类型、压缩强度、接续方式、是否成功、失败模式、摘要长度。下面这个表是记录结构的核心版字段取值说明为什么要记录任务类型修复/重构/新功能/补测试区分不同任务对连续上下文的依赖度压缩强度移除token占比看成功率与压缩程度的量化关系接续方式裸接/接续校验对照测试不同的交接策略是否成功成功/失败按统一验收标准判定失败模式目标漂移/参数复活/其他归类失败找针对性解法摘要长度约多少token控制摘要自身的读取代价执行耗时分钟数辅助判断“接上”的质量而不只看成败压缩强度我定义为“移除token占总上下文的比例”比如压缩前上下文是8万token压缩后剩3万那压缩强度就是62.5%。这个定义量化清晰后面做区间分析时特别好用。接续方式分成两组A组是压缩后直接把摘要丢给代理继续执行我管它叫“裸接”B组是压缩后先执行一步接续校验流程我管它叫“带校验接续”。这样AB组一对比就能量化校验流程到底值多少成功率。2.3 什么样算“接得上”验收标准实验里最容易被糊弄的就是“成功”的定义。如果标准含糊随手就能把半成品算成成功。我定的验收标准有三条缺一不可第一任务原始目标达成功能行为符合预期不靠代理自说自话第二相关测试套件通过并且没引入新的失败用例第三没有出现肉眼可见的范围蔓延——例如本来只是修复一个边界条件结果它顺手重构了半个模块。三条全过才算“成功”。同时我把失败定义成三类每一类都有明确特征。第一类叫“目标漂移”特征是代理做着做着开始执行和原任务无关但“看起来合理”的操作比如修登录鉴权时突然去优化数据库索引第二类是“参数复活”特征是用已经淘汰的旧函数签名、旧配置项、旧常量仿佛压缩后的世界停留在过去第三类是“质量劣化”目标表面达成、测试也过了但改法有明显硬伤比如用全局状态绕过问题或者复杂度高得离谱。这个分类在后面统计失败模式时发挥了很大作用。3. 压缩之后怎么接得上核心接续机制拆解3.1 核心认知接续靠的不是记忆是状态重建实验做到第三天的时候我的一个判断被彻底颠覆了。原本我花很多精力研究“怎么让摘要写得更详细”试图让代理通过精美摘要找回更多记忆。但对照数据出来之后我发现摘要详细度对成功率的影响远远小于“是否做了接续校验”。最详细的摘要裸接成功率也不过略高于平均水平而一份普普通通的摘要只要接续时强制进行状态重建成功率直接跳上一个台阶。这背后的逻辑其实不难理解。人类在连续工作时依靠的也不是把所有细节都背下来而是随时可以感知“我现在做到哪了、周围是什么状态”。对编码代理而言这个能力必须靠外部机制补上。当压缩抹平了过程细节代理真正需要的是一个新的起点一份能自洽描述当前世界状态的基线。它不需要记得沿途所有的坑但必须知道此刻哪些文件是改过的、哪个接口是生效的、还没跑完的测试是哪个。我把这个动作叫作“状态重建”它是压缩之后能不能接上的分水岭。所以我调整了研究重心不再纠结于摘要要多长而是设计一套标准化的接续协议让代理拿到摘要后的第一部动作是重建世界模型而不是急着写代码。这套协议经过反复迭代最后沉淀成三个步骤读摘要、验证状态、声明计划。3.2 四段式接续摘要模板摘要本身决定状态重建的起点质量。实践下来我最推荐的不是自由散文而是一个固定结构的四段式模板。它可能看起来有点啰嗦但每一行都有明确用途。目标本次任务要交付的结果以及“完成”的判定条件。越明确越好比如“让 /api/users 在参数缺省时返回 400而不是当前的空数组新增两条测试覆盖”。 状态当前代码与环境的真实状态。列出已经改过的文件、已经跑过的命令、已经生效的配置如“src/auth.js 已改完中间件已接入package.json 未动测试命令使用 npm test”。 决策过程中做过的关键选择与原因。简短记录“为什么不能用方案X”防止未来的代理重新走一遍死路。 约束接下来必须遵守的边界。包括不要再动哪些文件、必须先跑哪个测试、哪些命名规范必须遵守。这个模板的价值在于把“叙事”转化为“工程状态”。我试过用更长的自由文本来写摘要效果反而不如这种结构化的短文本。原因是自由文本读起来流畅但信息密度低代理在长摘要里找关键状态就像在小说里找坐标而四段式把状态字段独立出来代理一眼就能定位“当前世界什么样”。摘要的读者不是人类评审而是另一个时刻的模型它最需要的就是明确、直接、可执行的状态信息。3.3 写给未来执行者的摘要不是工作总结我给这个实验定了一条写作铁律摘要要从“未来执行者的视角”写而不是从“过去经历者的视角”写。这两者的区别是本质性的。工作总结式的摘要长这样“已完成登录鉴权模块的重写解决了令牌刷新并发问题性能提升明显。”这句话作为给老板的周报无可挑剔但作为给编码代理的交接文档等于零——它只回答了“做了什么”没回答“你现在在哪、下一步做什么、别碰什么”。可执行视角的摘要则像给另一个程序员留的交接便签“auth.js 第88行附近的 refreshToken 逻辑改动已被验证但 routes/ 目录还在调用旧的 ensureAuth 包装器你接下来要替换这4个调用点然后跑 tests/auth.test.js注意不要在 login 函数内部直接改 token 逻辑那部分已经锁定了。”同样的内容后者把代理从“我要回忆之前干了啥”变成“我直接照着便签干”。实验中有个特别直观的现象吃“工作总结型”摘要的代理恢复工作时平均要走七八步探索才能重新踩准节奏吃“交接便签型”摘要的代理往往一步就进入正确工作状态。好摘要还有一个共性特征以命令式语句为主。“先检查什么”比“我们曾经检查过什么”有效十倍。摘要里多出现“验证”“不要改”“下一步用”这类指令词代理的执行稳定性明显提升因为这类词会把模型的注意力引导到行动路径上而不是被历史叙事拉着走。3.4 压缩后的第一步永远不是写代码这个实践建议听起来简单但它是我踩了不知道多少坑之后才定死的规矩压缩后第一轮输出绝对不允许代理直接进入文件修改或工具调用必须先完成一次“交接确认”。交接确认包含三件事。第一代理用自己的话复述当前任务目标以及它计划完成的最终结果。这一步能过滤掉目标漂移——如果压缩后代理对任务的理解已经跑偏在这里就会暴露。第二代理列出它认为当前状态已经生效的关键文件与配置并挑出它接下来两步会依赖的具体代码触发对旧API或旧路径的“参数复活”检测。第三代理声明它计划执行的最小下一步这个计划必须和摘要里的约束不冲突。很多人担心交接确认会导致上下文进一步膨胀得不偿失。我在实验里量过这个成本一次交接确认大约消耗两千到四千token与它换来的成功率提升相比性价比极高。在压缩强度超过50%的样本里带校验接续的成功率比裸接高出超过二十个百分点。用一个两千token的动作换两成成功率这笔账太划算了。代理接不上任务反复试错烧掉的钱远超这点交接成本。4. 430条记录里看到的规律4.1 压缩强度与接续成功率的量化关系430条记录里最先浮现的规律就是压缩强度跟成功率之间有一条清晰的拐点。我把数据按压缩强度分成四档结果非常直观压缩强度样本数裸接成功率带校验成功率30%以下10291.2%94.1%30%-50%12480.6%88.7%50%-70%11863.6%82.2%70%以上8639.5%64.0%这张表有几个值得细读的地方。第一压缩强度低于30%时两种接续方式的成功率都很高说明轻量压缩对上下文完整性的破坏还在可控范围。第二裸接成功率的拐点出现在50%到70%档位掉幅接近十七个百分点这个下坠非常突然不是平滑过渡。第三也是最重要的带校验接续在70%以上压缩强度时依然能保住六成以上的成功率虽然也下降但下降幅度比裸接平缓得多。这说明什么压缩强度升高时摘要本身的信息损失是不可避免的但接续校验就像给代理加了一根安全带能把信息损失造成的影响卸掉大半。我在记录里还标注了另一组数据压缩强度超过70%以后摘要长度如果低于两千token无论接续方式如何成功率都会跌破一半。所以我的操作建议是如果判断上下文必须大幅压缩宁可在摘要里保留多一点状态细节也别为了省token压成干巴巴一句话。4.2 哪类任务最容易在压缩后断线任务类型与失败率之间的关系直接决定了日常使用中该在什么时候压缩、压缩前该多谨慎。我的430条样本里四个任务类型都有覆盖结果是模块重构类110条成功率最低裸接只有58.2%新功能开发类95条成功率居中裸接约72.6%缺陷修复类145条成功率较高裸接约81.4%测试补充类80条成功率最高裸接约92.5%重构任务之所以最容易断线是因为它本质上在做“跨文件一致性维护”。一个接口改了所有调用方都要跟着改代理必须同时记住旧签名、新签名、每个调用点的位置这种多要素协同的上下文依赖极重。压缩一旦把某个调用点的细节抹掉重构就像拼图少了一块后面的行为立刻散架。测试补充任务则几乎不受压缩影响因为它本质是局部增量工作依赖的是单个文件的局部上下文历史信息的多少对结果影响极小。这给了我一个非常实用的指导上下文紧张时优先安排测试补充这类低依赖任务去执行重构类任务则必须在上下文充足的窗口内一口气做完或者在压缩后立刻做完整的接续校验否则失败概率极高。4.3 两类反复出现的失败模式失败样本归因之后两类模式占了总数的接近八成值得单独拎出来讲。第一类“目标漂移”占了失败样本的46%。特征非常统一代理拿到压缩摘要后并没有按原任务继续走而是开始执行一个“看起来差不多但其实是新任务”的操作。比如有一次任务是修登录页面的表单校验压缩后代理直接开始重写整个前端路由结构还给自己编了一套理由说这样能彻底解决问题。这种漂移的恐怖之处在于它完全不自知代理在错误的方向上跑得信心满满。接续校验的存在价值第一次体现出来——让代理先复述目标当场就把这类偏差拦住大半。第二类“参数复活”占了31%。表现是压缩后代理重新调用已经被淘汰的旧接口、旧参数名、旧配置文件。比如项目已经把 useLegacyAuth 标志删了压缩摘要里只写了一句话提到“鉴权已迁移”代理恢复工作后居然又开始读这个旧标志还试图往代码里加回老逻辑。这本质上是模型的先验知识在上下文空白处“补全”了它以为存在的世界。要防住它最有效的手段就是在摘要状态段里显式列出“已经不存在的关键符号”用否定句描述比用肯定句更有效比如“注意src/legacyAuth.js 已删除不要引用”。4.4 损耗递减规律与一条安全线除了上述发现我还观察到一个没法放进表格、但极其重要的规律上下文压缩带来的损失是叠加的不是独立的。同一个任务连续压缩三次哪怕每次压缩强度都不高最终的信息退化程度远大于一次性高压缩。我管这个叫“损耗递减规律”——每次压缩都是一次信息再编码摘要生成摘要时原文里那些本来就模糊的细节会被二次抹平出错概率成倍上涨。这给了我一记警钟。之前我习惯窗口快满才压压完继续跑满了再压循环好几次。现在我的策略改了连续压缩超过两次的任务人必须介入检查一次或者干脆把已经完成的部分提交掉开一个新的干净上下文处理剩余工作。另外我也划出一条安全线净可用的原始上下文低于五万token时不再启动新的模块重构类任务因为实验数据告诉我这个体量下启动重构中途必然要压缩而压缩后的重构成功率撑不住。5. 踩坑实录与排查技巧5.1 压缩后代理还在用旧接口这是“参数复活”最日常的表现摘要明明已经写了新接口代理却依然调旧函数。一开始我以为是摘要写得不够清楚后来发现根因在于代理“先验补全”——模型训练时见过大量项目里旧风格的代码上下文空白时它会倾向于用记忆中更普遍的模式填空。我现在的应对办法很朴素在摘要的“约束”段直接列出“不存在的旧标识符清单”用否定句点名效果比单纯写“已更换新接口”好得多。例如“不要使用 parseTokenLegacy()该函数已不存在统一使用 parseTokenWithClaims()”。把旧名字点出来之后代理引用旧接口的概率大幅度下降而且它自己遇到类似情况时会主动去验证符号是否还存在而不是依赖记忆。5.2 代理突然“重写”整个任务计划“目标漂移”的高发场景是压缩后第一次输出。代理拿到摘要感觉信息不足于是自动脑补出一个更大的任务边界试图通过“扩大战果”来弥补认知缺口。这种情况如果放任不管通常以代理提交一堆无关代码告终。我在摘要的“目标”段加了配套手段明确写出“禁止超出范围的操作完成以下最小目标即停止”。同时接续校验时强制它声明“最小下一步”。如果它声明的计划超出了原任务范围我会在记录里标记为高风险样本。实践上有一种不错的做法把原任务切成若干个可独立验证的里程碑每个里程碑之间允许压缩。里程碑切得越细代理越不容易在大范围里漂移。5.3 连状态校验都做不下去怎么办有些场景下压缩强度太高摘要太薄代理做完交接确认后直接说“无法确认当前状态”。第一次遇到时我以为实验失败了后来发现这是个有价值的结果信号——说明摘要信息量已经不足以支撑任务接续硬要继续就是纯赌运气。我的处理方法是启动缩小验证范围的流程不让代理检查所有文件只让它检查接下来两步会接触的那两三个文件。如果小范围检查能通过就继续如果连小范围都查不通就把这个任务标记为“需要人工介入”人工补看一遍摘要和仓库状态把缺的信息补进摘要后再让代理继续。这个流程在强压缩样本里救回了不少原本被判死刑的任务。5.4 快速排查表整理一个我在实验后半段一直贴在旁边的排查表遇到异常先照表查别急着改代码重跑现象最先查什么标准接续动作代理使用已删除的旧API摘要约束段有没有列出旧标识符清单补上否定式清单让它验证符号存在性代理开始做无关改动第一轮交接确认的目标复述重新明确最小目标禁止范围外操作代理声称无法确认状态检查摘要状态段覆盖的文件范围缩小验证范围到依赖文件逐级恢复代理重复已否定的方案决策段是否记录了“为什么不选X”在决策段补充负面结论注明否决原因测试过了但改动质量差检查目标段是否有复杂度约束补充“禁止全局变量绕过”等质量边界这张表不是什么神奇魔法它只是把最容易翻车的几个点提前格式化让排查变成一个肌肉记忆式的动作而不是依赖临场反应。5.5 两个亲测有效的省钱技巧最后分享两个和钱直接相关的技巧。第一个是主动压缩比被动压缩省钱。窗口即将耗尽时被动压缩系统需要在极长的上下文上做一次大摘要消耗的token非常多而上下文用到五到六万token时主动压缩摘要生成的输入长度小成本低摘要质量还更稳定。算下来主动压缩的单次成本大约是被动压缩的一半后续接续失败率也低得多。第二个是我无意间试出来的把“接续摘要”的生成任务单独交给一个小模型去写而不是让主模型自己在执行间隙产摘要。小模型没有历史包袱反而更严格地照着四段式模板输出抓状态重点的能力比主模型总结时更稳关键是便宜。这个做法现在我固定下来了效果稳定成本还能再压一截。我个人在430条记录里最大的体会是上下文压缩之后代理“接不上”本质上不是模型的记忆力问题而是工程交接机制缺失的问题。每一次压缩都是一次中断中断之后必须有一次显式的、结构化的状态重建代理才能真正“接得上地气”。给代理留一份“工程日志”而不是“回忆录”它会用稳定的连续工作回报你。这个结论我自己已经复用了很久也建议你在真实项目里拿三五十条记录做个量化验证你会发现规律的确定性远超预期。