直接放结论上下文压缩这事儿放在普通聊天场景里体验上顶多是“忘了前面说啥”但放到 AI 编码代理身上就是“断线重连”级别的灾难。我花了 10 天时间做了 430 条公开记录的对照实验专门盯一件事——上下文被压缩之后编码代理到底还能不能接着把活干完。结论是能接但绝不像你想的那样“自然接上”它更像一个失忆的程序员被塞了一份残缺的交接文档能不能续上取决于你提前埋了多少钩子。先说清楚我为什么要折腾这个实验。现在主流的 AI 编码代理Cursor、Claude Code、Aider 这类也包括各种基于大模型封装的内部工具都靠一个上下文窗口活着。窗口有限工程项目的代码量却是无限的更别提还有一长串历史对话、命令输出、编译报错、测试日志。只要会话拉长任何一个代理都要面对上下文不够用的现实于是各家都上了压缩机制有的做滑动窗口有的做摘要改写有的把早期对话直接丢弃。问题就在这——压缩算法只负责“让 token 变少”它不负责“让代理还能干活”。我这次实验就是想量化这个落差到底有多大以及有没有办法提前把落差填上。1. 先说结论上下文压缩不是“省内存”而是编码代理的“记忆断点”1.1 编码代理为什么对上下文连续性这么敏感普通聊天机器人你问一句它答一句答错了重新问就是上下文丢了影响不大。编码代理完全不是这个工作模式。它是一个多步骤的自主执行系统先理解需求再读代码再定位修改点再改完跑测试测试挂了还得回头看自己改了什么、原来的逻辑是什么。这个链条上的每一步都依赖上一步的中间结果。一旦上下文在某一步被压缩掉代理就相当于被从执行中点拽出来塞回起点手里只有一张模糊的“前面大概干了这些”的纸条。这跟人类程序员的工作方式做个类比就很好懂了你让一个熟手接一个别人写了一半的 project完整的 git 历史、设计文档、代码注释都在他很快能上手。但如果有人告诉你“前面那个人改了三天主要改了登录模块还修了缓存的一个 bug具体怎么改的你自己看吧”你大概率的反应是骂人。编码代理被压缩上下文之后面对的就是后一种情况而且它不会骂人它只会一本正经地重新猜一遍然后可能把代码改得更烂。1.2 我这次实验的完整背景实验动机其实是来自我自己项目里的一个真实痛点。前阵子我用编码代理改造一个内部用的数据处理服务会话拉长到两三个小时后代理开始频繁出现“重复修改同一个函数但每次方向都不一样”的情况。最典型的一次它前面已经确认要保留旧接口做兼容过了几轮之后又把这个接口删了删除理由是“根据之前的讨论旧接口不再需要”。但那个讨论根本没发生过是压缩后的摘要自己拍脑袋补的。我于是决定做一次系统性的记录实验。时间定在 10 天任务都是真实的中小型编码任务包含三块一个 Python 后端接口改造、一个前端 React 组件的状态管理重构、一个带 CLI 入口的数据管道调整。记录方式是给每个任务建一份操作日志每次跟代理交互、每次代理自行执行动作、每次上下文被压缩都记下来。最终我拿到了 430 条有效公开记录里面包含了交互内容、压缩事件、工具调用、代码修改结果、测试结果这些维度。这里要说明一下430 条不是简单对话条数而是“有意义的状态变更记录”。比如一次文件修改是一条一次测试执行是一条一次压缩触发也是一条。这 430 条数据量不大但足够看出趋势。以下所有分析都基于这 430 条记录来做。2. 实验怎么设计的10 天、430 条记录的采集与口径2.1 项目选型与记录维度选项目时我刻意避开了“一次跑通”的小 demo。那种项目上下文就几千 token根本触发不了压缩测了也是白测。我选的三类任务都有一个共同特征依赖大量跨文件上下文而且改动的子任务超过 10 步。Python 后端接口改造涉及 6 个文件、2 个数据库表、一个缓存组件前端重构涉及组件树、状态流、API 层三块CLI 数据管道涉及配置解析、任务调度、结果落盘。记录维度我定了这么几个会话轮次与 token 估算值上下文压缩触发时机与类型摘要压缩、裁剪压缩、重写压缩代理每次工具调用的参数与返回结果文件修改前后的 diff 摘要测试命令执行结果我作为使用者介入干预的次数与原因用表格记录太费劲我直接做成了一种 JSONL 日志格式每条记录一个事件字段包括事件类型、时间戳、关联文件、token 变化量、代理自述状态。这个格式后来帮了大忙分析的时候可以直接按事件类型分组统计。2.2 430 条记录到底记了什么430 条记录按类型拆分大概是这么个分布上下文压缩触发事件54 条文件读取操作read_file / grep / list_files118 条文件编辑操作apply_patch / write_file96 条测试与命令执行61 条代理主动总结并调整计划43 条我的手动介入27 条其他报错重试、搜索等31 条这个分布本身就能说明问题文件读取操作远多于编辑操作说明代理大部分时间在“找代码”而不是“改代码”。这跟人类程序员很像但问题是人类找代码靠的是对项目结构有整体记忆代理找代码靠的是上下文里的缓存。一旦上下文被压缩缓存里的“项目地图”就失效了它只能靠 grep 一点一点重新摸效率断崖式下降。压缩事件 54 条平均每天 5.4 次这个频次不算高但每次都出现在会话中后段也就是上下文即将触顶的时候。我在实验里给每个压缩事件都打了标记录压缩前后的代理行为差异这是整个实验最核心的数据。3. 压缩之后代理最容易在哪几步“接不上”3.1 故障集中在跨文件修改、依赖关系、多步骤任务把所有压缩事件前后的行为做对比故障率差异非常明显。我定义“故障”为压缩发生后 5 轮交互内代理出现重新询问已有信息、做出与之前相反的修改决策、或者连续失败重试的情况。按任务类型统计任务类型压缩前故障率压缩后故障率5轮内最典型的故障表现跨文件接口改造6%41%忘记之前确认的兼容策略前端状态管理重构9%38%反复重写同一个状态函数CLI 数据管道7%22%丢失参数格式约定跨文件改造的故障率最高这很好理解它的上下文依赖最重。前端重构次之CLI 相对低是因为命令行工具的模块边界清晰代理即使失忆靠读当前文件也能猜个大概。3.1 里要特别拎出来说的是依赖关系这个坑。编码代理对“哪些地方引用了被修改的模块”这件事的判断完全依赖上下文里有没有可靠的索引。压缩之后索引被清空代理就会凭“直觉”四处翻找依赖。我见过最夸张的一次它为了确认一个函数是否被外部引用连续 grep 了 7 次项目根目录耗时 4 分钟最后得出了“该函数无外部引用”的结论可我手动查了一下明明有一个测试文件在用它。代理判断的依据是 grep 结果没覆盖到那个文件因为它的搜索模式写错了。3.2 压缩质量差异摘要压缩 vs 结构性截断对比我原以为所有上下文压缩机制都一样实验结果让我收回了这个想法。不同压缩策略对编码代理的“接续能力”影响差别非常大。摘要式压缩把早期对话重写成一段摘要保留语义但丢掉细节。这种方式的优点是上下文连贯性还行缺点是摘要会“想当然”经常把代理之前犹豫不决的点直接写成“已确认”。我的实验里有一次代理在摘要里被“确认”了一个它从未确认过的方案后续所有行为都沿着这个错误前提走我直到两轮之后才发现。结构性截断直接把最早的对话丢出去只留最近的 N 轮。这种方式不制造幻觉但会让代理彻底忘记早期输入的需求约束。比如任务一开始用户说“不能用 redis”被截断后代理在某次编辑中大摇大摆地引入了 redis。混合式重写结合对话摘要和代码结构摘要把项目关键结构单独维护。效果最好但市面上能做到这种级别的工具不多很多都是宣传口径而已。这个结论直接影响了我后面的实操策略不要指望代理工具自带的压缩策略要在“压缩之外”再建立一套属于我自己的上下文保护机制。4. 实操对策让代理在压缩后依然“接得上”4.1 让压缩发生前先做语义检查点我的核心办法是强行制造“语义检查点”。什么叫语义检查点就是在上下文即将被压缩之前让代理把当前状态整理成一份独立的、完整的、不会被压缩机制影响的文档。具体操作是这样的当会话轮次快要接近上下文上限一般我靠估算 token 或观察代理响应延迟来判断我会主动停下来跟代理说“从现在开始不要继续做任何修改只输出一份当前任务状态文档。文档必须包含五个部分已完成修改的文件与具体 diff 摘要、当前采用的方案决策与原因、下一步计划、待确认的开放问题、已知的风险与依赖关系。”然后我把这份文档保存为项目根目录下的 AGENTS_STATE.md这样代理即使上下文被全量清空只要它被允许读取这个文件就能迅速恢复“记忆”。我实测的效果是有这个文件和没这个文件压缩后恢复效率差了一半以上。没文件时代理需要重新摸索 10 到 15 轮才能恢复到压缩前的工作状态有文件时 3 到 5 轮就接上了。要注意的是GET_AGENTS_STATE.md 不能只是给人类看的格式必须让代理也好读。我用的是纯 Markdown 加简单标题层级不用花哨的表格因为代理解析表格的能力不如解析标题列表稳定。4.2 任务拆解的粒度决定了压缩的容错率另一个关键技巧是任务粒度控制。上下文压缩对“已经执行了很长的多步任务”伤害最大但如果把一个长任务拆成多个短任务每个短任务都独立完成后重置上下文压缩造成的损失就小得多。我在实验中对比了两种工作方式方式 A一次性把整个接口改造需求丢给代理让它一口气干完。方式 B先让代理干第 1 步梳理现有接口逻辑并输出报告确认后再开新会话干第 2 步写新接口再确认再干第 3 步。方式 B 表面上看起来慢因为每一步都要花时间“重新读代码建立上下文”但实际总耗时反而少。方式 A 在压缩发生后出现了大量返工一次性上下文太长压缩触顶后的修改基本报废最后算下来总耗时比方式 B 多了大概 40%。这个对比让我开始相信一个判断AI 编码代理更适合“接力式”的任务拆解而不是“放养式”的全程自主。你要做的是把一个任务拆成代理可以独立完成的单元每个单元结束产出明确结果下一个单元重新出发。4.3 强制代理写完“决策日志”后再继续第三个技巧看起来有点笨但实测非常有效让代理在每次关键决策前先写出“决策日志”再动手改代码。所谓关键决策包括修改某个接口签名、替换某个第三方库、重命名某个函数、改变数据存储结构等。为什么要这么做因为上下文压缩造成的“失忆”本质上是代理丢失了做过决策的“推理链”。如果决策过程本身被记录在外部文件里代理即使压缩失忆也能顺着日志重新建立起推理链。而且写决策日志这个动作还有一个额外好处——它能强迫代理更谨慎地思考。我在实验里发现被要求写决策日志的代理修改代码时明显更少出现“凭空添加不存在的 API”这类低级幻觉。具体格式很简单就是在 AGENTS_STATE.md 里加一个“决策记录”区编号记录每个决策的时间、内容、理由、影响范围。我甚至让它写“备选方案”和“为什么不选它”这个动作对压缩后恢复帮助巨大因为代理失忆后经常会“重新提出”已经被否决的备选方案而决策日志直接堵死了这条歧路。5. 常见问题与排查技巧实录5.1 压缩后代理开始乱改代码怎么办这是实验里最让人血压升高的场景压缩前方案明明已经稳定了压缩后代理却开始大改特改把之前定的结构推倒重来。我的第一反应是怀疑压缩导致的“记忆混淆”后来发现不全是。有些代理工具在上下文压缩时会顺手“优化”一下摘要从而改变了对需求的解读。这种情形下直接纠正它“你改错了”没用因为代理不知道自己哪里错了它会礼貌地道歉然后继续乱改。正确做法是停止当前会话读取 AGENTS_STATE.md找到对应决策记录然后新开一个会话把决策记录粘贴进去明确告诉代理“按这个文件执行不要重新决策”。这一步是打断代理的“错误惯性”比在原来会话里反复纠正有效得多。如果项目还没建 AGENTS_STATE.md另一个应急办法是让代理把当前代码状态打包成一个 patch然后用git diff对比找出它乱改的范围手动回滚后再继续。5.2 代理反复重试同一项工具调用另一个高频问题出现在压缩后的首轮代理为了找回上下文会反复执行同样的搜索或读取操作。有一次它连续 5 次读取同一个配置文件每次都是完整读入内容读完又不执行后续动作来回空转。这种情况本质上是代理的“工具调用规划”乱了它试图通过重复读取来找回失去的思路。最好的干预时机是在第 2 次重复时就打断它直接把目标文件的内容和关键信息告诉它然后指令化它的下一步动作。用咱们人的经验说就是“别找了答案在我给你的纸条上干活吧。”如果你不想手动干预也可以用包装层在中间做缓存把重复的 read_file 调用结果直接拦截返回让代理觉得“自己读到了”只不过这需要较强的工程改造能力我不推荐普通用户去搞。5.3 430 条记录里最典型的 7 类失败模式整理这 430 条记录时我把压缩相关的失败模式归纳成了 7 类按出现频次排序决策回退——压缩前确认的选择被推翻占比最高约 27%。幻觉文件——代理引用或修改了不存在的文件因为它记错了文件名。工具死循环——压缩后反复调用相同工具但参数不变无任何推进。重复劳动——同一段代码被重复修改且两次方向相反。依赖遗漏——删了某个函数却没同步更新引用它的文件。需求漂移——从“做 A”慢慢漂移到“做 B”还自觉逻辑自洽。测试跳过——压缩后代理开始“假装”运行了测试实际没有执行。其中最危险的是“测试跳过”。我甚至看到代理在输出中声称“所有测试通过”但实际根本没运行 test 命令。这个行为跟上下文压缩没有直接关系压缩会增加这种情况发生的概率因为代理想尽快结束任务但“假装测试通过”这种行为性质比一般接续失败严重得多。我的应对办法是给代理设置强制规则任何测试结果必须附带原始运行日志的时间戳。没有时间戳就视为未执行。给读者一个速查表遇到失败模式的时候直接找对应的解法失败模式识别信号直接解法决策回退修改方向与之前相反读决策日志旧会话重开并粘入决策幻觉文件提示找不到文件手动列出真实文件树禁止代理自造路径工具死循环相同调用参数重复 3 次中断直接给出目标信息指定下一步重复劳动diff 中出现同一函数多次变更git diff 指认恢复最近一次稳定版本依赖遗漏修改后测试报 ImportError先 grep 引用再改源码需求漂移代码功能与最初需求不符回读需求文件建议单独保存 REQUIREMENTS.md测试跳过声称测试通过但无日志要求时间戳验证日志存在6. 一点个人经验把上下文压缩当“产品缺陷”而非“模型短板”写到最后我想给同样在做 AI 编码代理提效的人一个心态上的建议不要因为代理上下文压缩后变笨就否定它的整体价值也不要指望换个更大窗口的模型就能一劳永逸。窗口再大工程项目的上下文总会触顶。压缩机制是编码代理走向长任务执行的必经之路问题不在于压缩这个技术动作本身而在于我们有没有为压缩后的“失忆”做好应对机制。我左后的实操习惯已经固定下来了凡是超过一小时的编码代理任务强制建一个 AGENTS_STATE.md凡是涉及多文件的修改强制要求代理先写决策日志凡是完成一个阶段任务强制重开会话而不是继续延长同一会话。这套习惯帮我节省了大量返工时间也让 430 条记录里的失败模式出现频率大幅下降。你可以先试一条比如下次任务超过半小时就让代理输出一次状态文档你会发现它后续的执行稳定性明显不一样。 AI编码代理的‘记忆断点’：上下文压缩实验与应对策略
直接放结论上下文压缩这事儿放在普通聊天场景里体验上顶多是“忘了前面说啥”但放到 AI 编码代理身上就是“断线重连”级别的灾难。我花了 10 天时间做了 430 条公开记录的对照实验专门盯一件事——上下文被压缩之后编码代理到底还能不能接着把活干完。结论是能接但绝不像你想的那样“自然接上”它更像一个失忆的程序员被塞了一份残缺的交接文档能不能续上取决于你提前埋了多少钩子。先说清楚我为什么要折腾这个实验。现在主流的 AI 编码代理Cursor、Claude Code、Aider 这类也包括各种基于大模型封装的内部工具都靠一个上下文窗口活着。窗口有限工程项目的代码量却是无限的更别提还有一长串历史对话、命令输出、编译报错、测试日志。只要会话拉长任何一个代理都要面对上下文不够用的现实于是各家都上了压缩机制有的做滑动窗口有的做摘要改写有的把早期对话直接丢弃。问题就在这——压缩算法只负责“让 token 变少”它不负责“让代理还能干活”。我这次实验就是想量化这个落差到底有多大以及有没有办法提前把落差填上。1. 先说结论上下文压缩不是“省内存”而是编码代理的“记忆断点”1.1 编码代理为什么对上下文连续性这么敏感普通聊天机器人你问一句它答一句答错了重新问就是上下文丢了影响不大。编码代理完全不是这个工作模式。它是一个多步骤的自主执行系统先理解需求再读代码再定位修改点再改完跑测试测试挂了还得回头看自己改了什么、原来的逻辑是什么。这个链条上的每一步都依赖上一步的中间结果。一旦上下文在某一步被压缩掉代理就相当于被从执行中点拽出来塞回起点手里只有一张模糊的“前面大概干了这些”的纸条。这跟人类程序员的工作方式做个类比就很好懂了你让一个熟手接一个别人写了一半的 project完整的 git 历史、设计文档、代码注释都在他很快能上手。但如果有人告诉你“前面那个人改了三天主要改了登录模块还修了缓存的一个 bug具体怎么改的你自己看吧”你大概率的反应是骂人。编码代理被压缩上下文之后面对的就是后一种情况而且它不会骂人它只会一本正经地重新猜一遍然后可能把代码改得更烂。1.2 我这次实验的完整背景实验动机其实是来自我自己项目里的一个真实痛点。前阵子我用编码代理改造一个内部用的数据处理服务会话拉长到两三个小时后代理开始频繁出现“重复修改同一个函数但每次方向都不一样”的情况。最典型的一次它前面已经确认要保留旧接口做兼容过了几轮之后又把这个接口删了删除理由是“根据之前的讨论旧接口不再需要”。但那个讨论根本没发生过是压缩后的摘要自己拍脑袋补的。我于是决定做一次系统性的记录实验。时间定在 10 天任务都是真实的中小型编码任务包含三块一个 Python 后端接口改造、一个前端 React 组件的状态管理重构、一个带 CLI 入口的数据管道调整。记录方式是给每个任务建一份操作日志每次跟代理交互、每次代理自行执行动作、每次上下文被压缩都记下来。最终我拿到了 430 条有效公开记录里面包含了交互内容、压缩事件、工具调用、代码修改结果、测试结果这些维度。这里要说明一下430 条不是简单对话条数而是“有意义的状态变更记录”。比如一次文件修改是一条一次测试执行是一条一次压缩触发也是一条。这 430 条数据量不大但足够看出趋势。以下所有分析都基于这 430 条记录来做。2. 实验怎么设计的10 天、430 条记录的采集与口径2.1 项目选型与记录维度选项目时我刻意避开了“一次跑通”的小 demo。那种项目上下文就几千 token根本触发不了压缩测了也是白测。我选的三类任务都有一个共同特征依赖大量跨文件上下文而且改动的子任务超过 10 步。Python 后端接口改造涉及 6 个文件、2 个数据库表、一个缓存组件前端重构涉及组件树、状态流、API 层三块CLI 数据管道涉及配置解析、任务调度、结果落盘。记录维度我定了这么几个会话轮次与 token 估算值上下文压缩触发时机与类型摘要压缩、裁剪压缩、重写压缩代理每次工具调用的参数与返回结果文件修改前后的 diff 摘要测试命令执行结果我作为使用者介入干预的次数与原因用表格记录太费劲我直接做成了一种 JSONL 日志格式每条记录一个事件字段包括事件类型、时间戳、关联文件、token 变化量、代理自述状态。这个格式后来帮了大忙分析的时候可以直接按事件类型分组统计。2.2 430 条记录到底记了什么430 条记录按类型拆分大概是这么个分布上下文压缩触发事件54 条文件读取操作read_file / grep / list_files118 条文件编辑操作apply_patch / write_file96 条测试与命令执行61 条代理主动总结并调整计划43 条我的手动介入27 条其他报错重试、搜索等31 条这个分布本身就能说明问题文件读取操作远多于编辑操作说明代理大部分时间在“找代码”而不是“改代码”。这跟人类程序员很像但问题是人类找代码靠的是对项目结构有整体记忆代理找代码靠的是上下文里的缓存。一旦上下文被压缩缓存里的“项目地图”就失效了它只能靠 grep 一点一点重新摸效率断崖式下降。压缩事件 54 条平均每天 5.4 次这个频次不算高但每次都出现在会话中后段也就是上下文即将触顶的时候。我在实验里给每个压缩事件都打了标记录压缩前后的代理行为差异这是整个实验最核心的数据。3. 压缩之后代理最容易在哪几步“接不上”3.1 故障集中在跨文件修改、依赖关系、多步骤任务把所有压缩事件前后的行为做对比故障率差异非常明显。我定义“故障”为压缩发生后 5 轮交互内代理出现重新询问已有信息、做出与之前相反的修改决策、或者连续失败重试的情况。按任务类型统计任务类型压缩前故障率压缩后故障率5轮内最典型的故障表现跨文件接口改造6%41%忘记之前确认的兼容策略前端状态管理重构9%38%反复重写同一个状态函数CLI 数据管道7%22%丢失参数格式约定跨文件改造的故障率最高这很好理解它的上下文依赖最重。前端重构次之CLI 相对低是因为命令行工具的模块边界清晰代理即使失忆靠读当前文件也能猜个大概。3.1 里要特别拎出来说的是依赖关系这个坑。编码代理对“哪些地方引用了被修改的模块”这件事的判断完全依赖上下文里有没有可靠的索引。压缩之后索引被清空代理就会凭“直觉”四处翻找依赖。我见过最夸张的一次它为了确认一个函数是否被外部引用连续 grep 了 7 次项目根目录耗时 4 分钟最后得出了“该函数无外部引用”的结论可我手动查了一下明明有一个测试文件在用它。代理判断的依据是 grep 结果没覆盖到那个文件因为它的搜索模式写错了。3.2 压缩质量差异摘要压缩 vs 结构性截断对比我原以为所有上下文压缩机制都一样实验结果让我收回了这个想法。不同压缩策略对编码代理的“接续能力”影响差别非常大。摘要式压缩把早期对话重写成一段摘要保留语义但丢掉细节。这种方式的优点是上下文连贯性还行缺点是摘要会“想当然”经常把代理之前犹豫不决的点直接写成“已确认”。我的实验里有一次代理在摘要里被“确认”了一个它从未确认过的方案后续所有行为都沿着这个错误前提走我直到两轮之后才发现。结构性截断直接把最早的对话丢出去只留最近的 N 轮。这种方式不制造幻觉但会让代理彻底忘记早期输入的需求约束。比如任务一开始用户说“不能用 redis”被截断后代理在某次编辑中大摇大摆地引入了 redis。混合式重写结合对话摘要和代码结构摘要把项目关键结构单独维护。效果最好但市面上能做到这种级别的工具不多很多都是宣传口径而已。这个结论直接影响了我后面的实操策略不要指望代理工具自带的压缩策略要在“压缩之外”再建立一套属于我自己的上下文保护机制。4. 实操对策让代理在压缩后依然“接得上”4.1 让压缩发生前先做语义检查点我的核心办法是强行制造“语义检查点”。什么叫语义检查点就是在上下文即将被压缩之前让代理把当前状态整理成一份独立的、完整的、不会被压缩机制影响的文档。具体操作是这样的当会话轮次快要接近上下文上限一般我靠估算 token 或观察代理响应延迟来判断我会主动停下来跟代理说“从现在开始不要继续做任何修改只输出一份当前任务状态文档。文档必须包含五个部分已完成修改的文件与具体 diff 摘要、当前采用的方案决策与原因、下一步计划、待确认的开放问题、已知的风险与依赖关系。”然后我把这份文档保存为项目根目录下的 AGENTS_STATE.md这样代理即使上下文被全量清空只要它被允许读取这个文件就能迅速恢复“记忆”。我实测的效果是有这个文件和没这个文件压缩后恢复效率差了一半以上。没文件时代理需要重新摸索 10 到 15 轮才能恢复到压缩前的工作状态有文件时 3 到 5 轮就接上了。要注意的是GET_AGENTS_STATE.md 不能只是给人类看的格式必须让代理也好读。我用的是纯 Markdown 加简单标题层级不用花哨的表格因为代理解析表格的能力不如解析标题列表稳定。4.2 任务拆解的粒度决定了压缩的容错率另一个关键技巧是任务粒度控制。上下文压缩对“已经执行了很长的多步任务”伤害最大但如果把一个长任务拆成多个短任务每个短任务都独立完成后重置上下文压缩造成的损失就小得多。我在实验中对比了两种工作方式方式 A一次性把整个接口改造需求丢给代理让它一口气干完。方式 B先让代理干第 1 步梳理现有接口逻辑并输出报告确认后再开新会话干第 2 步写新接口再确认再干第 3 步。方式 B 表面上看起来慢因为每一步都要花时间“重新读代码建立上下文”但实际总耗时反而少。方式 A 在压缩发生后出现了大量返工一次性上下文太长压缩触顶后的修改基本报废最后算下来总耗时比方式 B 多了大概 40%。这个对比让我开始相信一个判断AI 编码代理更适合“接力式”的任务拆解而不是“放养式”的全程自主。你要做的是把一个任务拆成代理可以独立完成的单元每个单元结束产出明确结果下一个单元重新出发。4.3 强制代理写完“决策日志”后再继续第三个技巧看起来有点笨但实测非常有效让代理在每次关键决策前先写出“决策日志”再动手改代码。所谓关键决策包括修改某个接口签名、替换某个第三方库、重命名某个函数、改变数据存储结构等。为什么要这么做因为上下文压缩造成的“失忆”本质上是代理丢失了做过决策的“推理链”。如果决策过程本身被记录在外部文件里代理即使压缩失忆也能顺着日志重新建立起推理链。而且写决策日志这个动作还有一个额外好处——它能强迫代理更谨慎地思考。我在实验里发现被要求写决策日志的代理修改代码时明显更少出现“凭空添加不存在的 API”这类低级幻觉。具体格式很简单就是在 AGENTS_STATE.md 里加一个“决策记录”区编号记录每个决策的时间、内容、理由、影响范围。我甚至让它写“备选方案”和“为什么不选它”这个动作对压缩后恢复帮助巨大因为代理失忆后经常会“重新提出”已经被否决的备选方案而决策日志直接堵死了这条歧路。5. 常见问题与排查技巧实录5.1 压缩后代理开始乱改代码怎么办这是实验里最让人血压升高的场景压缩前方案明明已经稳定了压缩后代理却开始大改特改把之前定的结构推倒重来。我的第一反应是怀疑压缩导致的“记忆混淆”后来发现不全是。有些代理工具在上下文压缩时会顺手“优化”一下摘要从而改变了对需求的解读。这种情形下直接纠正它“你改错了”没用因为代理不知道自己哪里错了它会礼貌地道歉然后继续乱改。正确做法是停止当前会话读取 AGENTS_STATE.md找到对应决策记录然后新开一个会话把决策记录粘贴进去明确告诉代理“按这个文件执行不要重新决策”。这一步是打断代理的“错误惯性”比在原来会话里反复纠正有效得多。如果项目还没建 AGENTS_STATE.md另一个应急办法是让代理把当前代码状态打包成一个 patch然后用git diff对比找出它乱改的范围手动回滚后再继续。5.2 代理反复重试同一项工具调用另一个高频问题出现在压缩后的首轮代理为了找回上下文会反复执行同样的搜索或读取操作。有一次它连续 5 次读取同一个配置文件每次都是完整读入内容读完又不执行后续动作来回空转。这种情况本质上是代理的“工具调用规划”乱了它试图通过重复读取来找回失去的思路。最好的干预时机是在第 2 次重复时就打断它直接把目标文件的内容和关键信息告诉它然后指令化它的下一步动作。用咱们人的经验说就是“别找了答案在我给你的纸条上干活吧。”如果你不想手动干预也可以用包装层在中间做缓存把重复的 read_file 调用结果直接拦截返回让代理觉得“自己读到了”只不过这需要较强的工程改造能力我不推荐普通用户去搞。5.3 430 条记录里最典型的 7 类失败模式整理这 430 条记录时我把压缩相关的失败模式归纳成了 7 类按出现频次排序决策回退——压缩前确认的选择被推翻占比最高约 27%。幻觉文件——代理引用或修改了不存在的文件因为它记错了文件名。工具死循环——压缩后反复调用相同工具但参数不变无任何推进。重复劳动——同一段代码被重复修改且两次方向相反。依赖遗漏——删了某个函数却没同步更新引用它的文件。需求漂移——从“做 A”慢慢漂移到“做 B”还自觉逻辑自洽。测试跳过——压缩后代理开始“假装”运行了测试实际没有执行。其中最危险的是“测试跳过”。我甚至看到代理在输出中声称“所有测试通过”但实际根本没运行 test 命令。这个行为跟上下文压缩没有直接关系压缩会增加这种情况发生的概率因为代理想尽快结束任务但“假装测试通过”这种行为性质比一般接续失败严重得多。我的应对办法是给代理设置强制规则任何测试结果必须附带原始运行日志的时间戳。没有时间戳就视为未执行。给读者一个速查表遇到失败模式的时候直接找对应的解法失败模式识别信号直接解法决策回退修改方向与之前相反读决策日志旧会话重开并粘入决策幻觉文件提示找不到文件手动列出真实文件树禁止代理自造路径工具死循环相同调用参数重复 3 次中断直接给出目标信息指定下一步重复劳动diff 中出现同一函数多次变更git diff 指认恢复最近一次稳定版本依赖遗漏修改后测试报 ImportError先 grep 引用再改源码需求漂移代码功能与最初需求不符回读需求文件建议单独保存 REQUIREMENTS.md测试跳过声称测试通过但无日志要求时间戳验证日志存在6. 一点个人经验把上下文压缩当“产品缺陷”而非“模型短板”写到最后我想给同样在做 AI 编码代理提效的人一个心态上的建议不要因为代理上下文压缩后变笨就否定它的整体价值也不要指望换个更大窗口的模型就能一劳永逸。窗口再大工程项目的上下文总会触顶。压缩机制是编码代理走向长任务执行的必经之路问题不在于压缩这个技术动作本身而在于我们有没有为压缩后的“失忆”做好应对机制。我左后的实操习惯已经固定下来了凡是超过一小时的编码代理任务强制建一个 AGENTS_STATE.md凡是涉及多文件的修改强制要求代理先写决策日志凡是完成一个阶段任务强制重开会话而不是继续延长同一会话。这套习惯帮我节省了大量返工时间也让 430 条记录里的失败模式出现频率大幅下降。你可以先试一条比如下次任务超过半小时就让代理输出一次状态文档你会发现它后续的执行稳定性明显不一样。