如果你也遇到过这种情况：AI 编码代理跑了一个多小时，正在一个大型代码库的核心模块里改接口，窗口卡了一下，弹出一行提示：“之前的内容过长，已自动压缩总结”。然后代理就像刚被做了“脑叶切除术”一样，完全不记得半小时前它自己刚敲定的方案，开始重复读文件、重复提问，甚至想把已经完成的部分再改一遍。我就是在一次接近 20 万 token 的上下文任务里，被这样狠狠坑了一次。
后来我琢磨出了应对办法，思路来自两个老东西：一个是 Unix 世界里的 init.d 启动脚本，一个是电影《记忆碎片》里男主角用来对抗失忆的“外部笔记系统”。这套办法的核心，不是想方设法扩大上下文窗口，而是让 AI 编码代理本身就“对上下文压缩免疫”——不管窗口被压缩多少次，它都能从磁盘上的状态文件里把自己的“记忆”捡回来，接着干活。下面把完整方案拆开讲，包括原理、代码、提示词模板、问题排查，适合正在用 AI 编码代理做大型重构或跨文件长任务的读者。
1. 先把事故现场说清楚：20 万 token 的上下文到底怎么了
1.1 我看到的“脑叶切除术”不是比喻
所谓“20 万 token 上下文”，就是代理在一轮会话里能同时“记住”的数据量。听起来很大，但实际用起来远不够。我当时处理的是一个跨几十个文件的后端重构任务：每读一个文件就是几千 token，每看一下测试输出又是几千 token，再算上代理自己生成的中间分析，不需要太久，整个上下文窗口就会被塞满。
窗口满了之后，运行平台不会直接报错，而是触发“上下文压缩”——把前面的原始对话内容压缩成一段几十行的总结，然后继续。问题在于，这个压缩过程非常像脑叶切除术：它会把细节全部切掉，只留下一个模糊的轮廓。比如代理原本已经分析清楚“order_service 里的第 7 行依赖注入需要改成 cache_manager 传入”，压缩之后，它只知道自己好像“讨论过依赖注入”，却完全不知道具体改哪个文件、哪个参数、为什么这么改。
于是它开始犯那种让人血压飙升的错误：翻回已经重构完的模块重新读一遍，又开始问“这个项目的目录结构是什么”，甚至可能把之前刚写好的代码再改回旧版本。最气人的是，这些行为都不是故意的——在压缩后的上下文里，“昨天”和“五分钟前”一样陌生，它确实什么都不记得了。
1.2 为什么会压缩：这是经济账，不是厂商坑你
很多人第一反应是骂平台、骂模型，觉得为什么不能把上下文窗口再做大一点。我可以告诉你，这条路治标不治本。
现代大模型处理上下文时，注意力机制的计算复杂度几乎是随上下文长度平方级增长的。换句话说，窗口从 10 万扩到 20 万，成本不是翻倍，可能是三四倍甚至更多。再加上响应时间变慢、用户等待变长，任何提供编码代理服务的平台都必须在“记忆量”和“经济性”之间做平衡。于是压缩、截断、滑动窗口这些机制成了标配。
理解这一点，就能明白一个关键结论：指望“上下文永远不会被压缩”是不可能的，就像你不能指望硬盘永远不会坏。正确的思路是承认上下文是不可靠的短期记忆，然后像 Unix 系统设计者那样，把关键状态放到外部持久化存储里。
2. 重启哲学：Unix init.d 教会我“状态外置”
2.1 init.d 的设计精髓：进程会崩，但服务还要在
Unix 系统里有一套经典的启动管理机制，放在 /etc/init.d 目录下。每个服务都有一个脚本，里面声明了这个服务怎么启动、怎么停止、怎么查看状态、怎么重启。
系统重启之后，init 进程会依次执行这些脚本，把服务一个个拉起来。很多服务启动的时候，并不会恢复“崩溃前内存里的现场”，而是读取磁盘上的配置文件和日志数据，从已知状态重新开始。对 daemon 进程来说，内存本来就是易失的，谁也不会指望重启后进程还保留着原来的变量；大家依赖的是配置文件、状态数据库、日志文件这些“外置状态”。
这个设计非常优雅：进程可以被杀死，但服务定义不会死；内存会丢，但磁盘上的声明还在。
2.2 把长任务当成一组“可重启服务”来管理
我后来想明白一件事：AI 编码代理的上下文窗口，本质上就是它的“内存”。内存会被压缩/清空，这不是异常，而是常态。既然如此，那我就不能把一个长任务押注在“一个超长会话不中断”上，而应该把一个长任务设计成一个“可以随时重启的服务”。
具体做法是给项目建一个状态目录，比如.agent/，里面放一个state.json。这个文件就是代理的“init.d 启动脚本加配置文件”。每次会话开始，代理先读这个文件；每次会话结束，代理写回这个文件；如果会话中途被压缩，直接终止会话，重新启动一个新会话，新会话再读这个文件继续。
这不是什么高深技巧，本质就是“进程崩溃恢复”。把任务从“一个长会话”拆成“多个短会话 + 外部状态”，每次短会话只做一小步，做完就落盘。这样单个会话被压缩了不可怕，最坏情况就是丢掉这次会话开头到压缩前的那段临时记忆，但任务的主线、已完成步骤、下一步动作全都安全地躺在磁盘上。
3. 《记忆碎片》方法：代理的外部便签系统
3.1 为什么不能相信上下文里的“记忆”
《记忆碎片》这部电影里，男主角因为伤病失去了长期记忆能力，只能记住最近几分钟发生的事。为了查出真相，他把所有关键事实写成便签，拍成照片，甚至纹在身上：这个人是谁、那辆车是什么颜色、下一步要做什么。他给自己建立了一套“外部记忆系统”，因为他的大脑已经不可靠了。
AI 编码代理的处境和这个几乎一模一样。它的“大脑”——上下文窗口——天然不可靠，一旦被压缩，所有历史就变成碎片。如果你把关键信息只放在上下文里，就相当于男主角把线索只放在脑子里，过五分钟就忘。
所以铁律只有一条：只相信写下来的事实，不要相信对话里的记忆。
3.2 状态文件长什么样：一份给机器看的“便签”
我使用的状态文件就是一个 JSON，字段不多，但每一个都有明确用途。给你看一个示例：
{ "mission": "为购物车模块完成缓存层重构，保持对外接口不变", "completed_steps": [ "梳理 Redis 调用点，共 23 处", "抽出 cache_manager 模块", "为 cache_manager 增加单元测试" ], "next_action": "替换 order_service 中的 5 处调用，并运行项目测试", "constraints": [ "不得修改 controller 层方法签名", "必须兼容 Python 3.9", "所有 Redis key 前缀统一为 'v2:'" ], "key_decisions": [ { "decision": "使用统一 cache_manager 替代散落的 Redis client", "reason": "方便统一监控和降级策略" } ] }每个字段都有它的意义：
mission是整个任务的终极目标，一句话写死。代理不管聊到多偏，只要读一眼这个字段，就能回到主线上来。completed_steps是已经完成的工作。这是防重复执行的关键。上下文压缩后代理最容易犯的错就是把旧工作又做一遍，有了这个列表，它至少知道“这些不要碰了”。next_action是整个文件里最核心的一个字段，它告诉你压缩发生后，重启的入口在哪里。只要这个字段准确，新会话就能无缝接上。constraints用来保存那些最容易被压缩掉的“边界条件”。比如接口签名不能改、兼容版本不能破。这类信息在原始上下文里可能只是随口提到的一句话，压缩后必丢，必须单独拉出来。key_decisions记录关键决策和原因。编码代理有时候会“聪明反被聪明误”，试图把你之前的决策推翻重来。如果它看到决策背后还有 reason，就会更倾向于坚持原有方案。
注意控制状态文件长度，我一般让它保持在一屏能看完、大约三五十行的规模。太长了反而又变成新的上下文负担。
3.3 让代理“动手记笔记”的三个习惯
光有文件还不行，代理得养成使用这个文件的习惯。我是通过系统提示词强制约束的，你可以直接抄：
首先，每完成一个原子步骤，立刻更新completed_steps和next_action。所谓“原子步骤”，就是像“修改完一个文件”“跑完一轮测试”“写完一个函数”这种不会再拆分的操作。更新完了再继续下一步。
其次，每次做出技术决策时，顺手在key_decisions里记一行。不需要写长篇大论，一句话、一个原因就够了。比如“接口参数从位置参数改为关键字参数，原因是为了向后兼容”，这就是一条救命的决策记录。
最后，每次会话开始和结束时各做一次“状态对齐”。开始前，代理先读一遍文件并用一两句话复述“我的目标是 X，下一步做 Y”；结束后，代理把本轮做的改动、新生成的约束写回文件。习惯养成之后，压缩对它来说就只是“睡了一觉”，醒来还能靠便签明白自己在哪。
4. 上下文压缩免疫的实操流水线
4.1 第一步：用一个监控脚本识别“手术前兆”
想做到免疫，不能等压缩发生了才补救，最好在它发生之前就主动重启。长会话运行到后期，代理的响应速度会肉眼可见地变慢，这就是上下文快满的信号。你可以自己写一个简单的监控脚本，估算 token 用量，比如统计对话消息的字符总数，超过一个阈值就弹提醒，让你决定是否手动开新会话。
更省事的方式是设置“哨兵信号”。很多编码代理在上下文压缩后，会在输出里出现“前面的内容较长，我做了简化总结”之类的提示。如果代理是通过命令行运行的，你可以在管道里加一个文本匹配规则，一旦捕捉到这个信号，就认为上下文压缩已经发生，随即在外面终止当前会话、拉起新会话，然后从状态文件恢复。
# 一个简单的压缩信号检测示例（伪代码思路） tail -f agent_output.log | while read line; do if echo "$line" | grep -q "上下文.*压缩\|context.*compressed"; then echo "检测到压缩信号，终止当前会话" kill -TERM $AGENT_PID break fi done这个脚本负责的就是“感知异常”。压缩免疫的第一要义就是：你自己比压缩先知道。
4.2 第二步：自省提示词与周期性状态对齐
监控是外部手段，更重要的内部手段是让代理养成“自省”习惯。我在系统提示词里嵌入了这么一段：
在每次开始处理任务前，你必须先读取
.agent/state.json。用不超过 50 个字复述当前任务目标和下一步动作。如果发现当前目标不明确，或者后续操作与next_action不一致，就停下来重新阅读状态文件，不要猜测。如果上下文中的信息与状态文件冲突，一律以状态文件为准。
这段提示词起的就是“自省”作用。它让代理每走几步就回到外部便签上对齐一次，而不是顺着对话惯性越跑越远。你可以把“每完成一个工具调用后”改成“每完成 3 个工具调用后”，防止频繁读取文件占用 token。我自己的习惯是每个步骤之间做一次对齐，虽然略慢，但换来的是稳定。
4.3 第三步：重启循环脚本把“脑叶切除”变成“重启服务”
最后把整套流程自动化。我用一个外层 shell 循环来跑代理：
#!/usr/bin/env bash # run_agent_loop.sh PROJECT_DIR="/path/to/project" STATE_FILE="$PROJECT_DIR/.agent/state.json" while true; do echo "=== 开启新会话，读取状态文件 ===" my-ai-agent --project "$PROJECT_DIR" --resume "$STATE_FILE" exit_code=$? if [ $exit_code -eq 42 ]; then echo "检测到上下文压缩/异常中断，准备重启会话" sleep 2 continue fi echo "任务正常完成" break done这里约定了一个退出码42，代表“压缩导致会话异常”。代理脚本里可以在捕获压缩信号后主动以 42 退出，外层循环收到 42 就重新拉起新会话。每次循环做的事都一样：开新会话、读取状态文件、继续做一步、写回状态文件。
对代理来说，它只是“睡了一觉，醒来后看了看便签，继续干活”，中间的上下文压缩就像从来没有发生过一样。这就是我对“对上下文压缩免疫”的理解：不是没有压缩，而是压缩之后能立刻恢复。
5. 问题排查：压缩已经发生之后怎么办
5.1 代理开始胡言乱语，怎么救回来
最典型的场景是：压缩已经发生了，代理开始重复问“这个项目的背景是什么”“我们刚才聊到哪了”，甚至开始重做已经完成的步骤。这时候请记住一个原则：不要尝试修复旧会话，直接开新会话。
你可以关掉旧会话，把.agent/state.json里的内容直接粘贴给新会话，然后说一句：“请读取下面的状态信息，继续执行 next_action 字段描述的任务。”新会话没有拖着一大坨混乱的上下文，反而能非常清晰地理解当前局面。
如果代理还是犯糊涂，那就在 state.json 里加一个last_session_ts和last_completed_action字段，明确告诉它：“这些是你上一个会话已经完成的内容，本次会话不要重复执行。”这一步是为了对抗压缩后代理那种“明明做过了却以为自己没做”的幻觉。
5.2 状态文件本身变成了新的“压死骆驼的草”
状态文件虽然好用，但如果不管不顾地一直往里加内容，它也会越长越大。等我意识到这一点的时候，我的 state.json 已经有几百行，每次读文件都占掉很多 token，几乎又引发了第二次压缩。
解决办法是给状态文件做“压缩”。completed_steps只保留最近几条，旧条目挪到.agent/logs/archive_2025.log里；key_decisions里已经不再具有约束力的决策，直接清掉；constraints保留不变，因为这类信息最重要。做完这些清理后，状态文件重新回到一屏以内。
5.3 什么时候不需要这套机制
也不是所有任务都值得上这么重的机制。如果只是改一个单文件 bug、写一个几十行的小函数，上下文根本撑不到压缩，那就没必要建状态目录、写 JSON、配循环脚本，纯属浪费时间。
这套方案真正发威的场景是：跨几十个文件、需要连续几小时甚至跨天完成的大型重构、架构迁移、依赖升级。在这些任务里，上下文压缩几乎是必然发生的事，提前做好免疫设计才是正经事。
6. 一些测试体会和延伸想法
说实话，最初踩坑之后我一度很沮丧，觉得 AI 编码代理怎么这么不靠谱。后来换了个角度想，它其实就像一个患有短期记忆障碍的同事，不是不聪明，是记忆机制有硬伤。你骂它“怎么又忘了”没有用，不如主动在它桌上贴满便签，把每一步写清楚。
我在最近一次持续两个工作日的重构任务里，把这套状态文件加重启循环的方案完整跑了一遍，中间故意让压缩发生，结果是：代理在“失忆”后通过阅读 state.json，几乎是立刻接上了之前的进度，没有重读已经读过的文件，也没有再把旧代码改回去。对我来说，这就已经值回票价了。
后面我打算再做两件事：一是把历史归档做成自动摘要，每完成一轮任务就生成一份带结论的“记忆归档”，供新会话快速了解全局；二是想给状态文件加一个“决策图谱”，把关键决策之间的依赖关系画出来，让代理在遇到冲突时能更快判断应该保留哪个方案。方向是清晰的：既然上下文一定会被压缩，那就把记忆从窗口里搬出来，搬到文件里、脚本里、流程里。谁先把这件事想明白，谁就能在长任务里真正省心。
