如果你把一个 20 万 token 的“豪华上下文”一次性丢给某个 AI 编码代理，然后突然截掉其中 15 万 token，它的反应可能会让你很受冲击——它开始像一个刚醒来的失忆症患者一样行动，语气依然流畅，逻辑依然自洽，但已经彻底忘了自己最初要在哪个文件里改哪一行代码，更糟糕的是，它还会自信地告诉你“我理解了这个需求”，然后写出一段方向完全错误的实现。这不是夸张，这是我在某托管开发环境里反复踩过的坑：大上下文窗口给人一种“记忆可以无限外挂”的错觉，但上下文压缩一旦发生，代理的整个任务心智模型就像被做了一次脑叶切除手术。这个标题里的两个意象我很喜欢：Unix init.d 和电影《记忆碎片》，它们恰好对应了我对抗上下文压缩的核心思路。init.d 代表“服务可以随时被杀掉然后重新启动，只要状态声明还在磁盘上”；《记忆碎片》代表“人脑短期记忆靠不住时，就用纹身和纸条建立外部记忆”。把这两样东西放进 AI 编码代理的架构里，你能得到一个让人相当安心的结论：即使上下文被压缩到只剩一个尾巴，代理也能像什么都没发生过一样继续干活。这篇文章不打算讲某个具体模型或某个神秘外挂工具，而是分享一套我实际用在这个场景里的工作流：把代理当作服务来跑，把记忆外置为状态文件，把每次上下文清空都当成一次可重复的启动过程。如果你是做 AI 编码代理、自动化编程、或整天和超长上下文打交道的开发者，这篇内容应该对你有用。1. 先聊聊“20 万 token”这件诱人的外套1.1 全局上下文和有效上下文是两回事先说个反直觉的事实：你手头那个号称 20 万 token 的上下文窗口，并不意味着模型在任一时刻都能平等地“看到”这 20 万 token。从我实际使用的体感来看，哪怕模型架构上支持 20 万 token 的输入，参与每一步输出决策的往往只是最近的一段局部序列，再加上系统提示和当前正在处理的文件内容。更早期的指令、更早期的报错信息、更早期的代码片段，会被折叠成越来越粗糙的摘要，甚至在某个时刻直接变成“模糊的记忆”。这不是模型厂商在骗你，而是长序列推理的天然成本。注意力机制在极长输入下会被稀释，模型对早期 token 的“关注强度”会衰减，结果就是：它很可能记得“你让它处理一个队列系统”，但已经记不清队列的消费者应该从哪个消息源拉数据。当上下文窗口足够大时，这种衰减还不致命；但当压缩发生时，你的原始需求可能直接变成一段语义模糊的转述。1.2 “脑叶切除术”到底切掉了什么上下文压缩这件事，在 API 层往往以一个很隐蔽的方式发生：它不会明着告诉你“我把你的前 10 万 token 删了”，而是把中间一大段内容替换成自然语言摘要。你可能前一秒还在和代理讨论某个接口的返回值格式，下一秒它就只能根据一段概括性文字猜测你的意图。我自己对这种现象有句吐槽：这是在给代理做脑叶切除术——切除的恰好是它构建任务心智模型最关键的那部分。被切掉的东西具体有三类。第一类是目标和验收标准，也就是“你到底要什么”；第二类是约束和禁忌，也就是“哪些东西千万别碰”；第三类是已经探索过的盲区，也就是“哪些方案已经试过了，别再来一遍”。这三类信息恰恰是纯对话式记忆最容易丢失的，因为它们在对话早期就出现了，一旦被压缩，后续所有决策都会歪掉。1.3 为什么编码代理比聊天会话更怕压缩普通聊天场景里，上下文压缩造成的后果，顶多是被用户纠正一次“我刚才不是这个意思”。但编码代理不一样，它每次决策都映射为对真实文件系统的修改。如果它忘记了你禁止改动某个模块，它不会重新问你，而是直接生成一段重构代码，然后提交上去。我在某个模拟项目里就遇到过这种事：我让代理完成一个异步任务调度模块，中间我明确说过“不要动底层存储接口，只改调度层”。一万行代码之后上下文被压缩，代理在后续重构中判断“底层接口的鉴权逻辑是这个任务的关键瓶颈”，于是自作主张重写了鉴权模块，差点把整个系统的安全边界破坏掉。从那以后我得出一个结论：不要把编码代理当成一个“聊天遗忘问题”来处理，而是当成一个“分布式系统状态管理问题”来处理。聊天窗口只是瞬时的工作内存，磁盘状态才是唯一可靠的长期记忆。2. init.d 的启示：把代理当服务跑，而不是当对话聊2.1 init.d 的思想移植：声明期望，而不是记忆过程Unix 里的 init.d 是一个让我想到就觉得很踏实的设计。它的核心逻辑是：无论系统之前经历过多少次崩溃、重启、电源故障，只要有一组声明式的启动脚本放在指定目录里，系统就能按预定顺序把服务拉起来。服务进程本身可以随时被杀掉，但它的“重启意图”是持久化的。把这个思想移植到 AI 编码代理上，就形成了一句我自己的口头禅：代理不靠上下文里的记忆活着，靠磁盘上的状态声明活着。具体做法是：不要在对话里反复叮嘱代理“记住某某约定”，而是把这些约定写成一份独立的状态文件，放进工作区里的 .agent 目录。代理每开始一个新会话、每经历一次上下文压缩、每被用户打断又恢复，都先加载这份状态文件，而不是加载一段聊天记录。这样，“记住约定”就从模型的注意力问题，变成了文件系统的读写问题。2.2 状态文件的三种层次：目标层、进度层、证据层在实践中，我会把代理状态拆成三层：目标层、进度层、证据层。三层各自承担不同的职责。目标层是一个精简的子目标描述文件，里面写明最终交付物是什么、有哪些硬性约束、有哪些绝对不能碰的代码禁区。它的作用相当于 init.d 里的启动参数：不解释历史，只定义当前应该处于什么状态。进度层是代理当前执行阶段的检查点，包含当前处于哪个阶段、接下来要做哪个动作、有哪些前置条件需要满足。它相当于 init.d 脚本里的“runlevel”：告诉代理现在应该启动到什么级别。证据层则是一批短期快照文件，记录最近几次操作的结果摘要、最近一次测试执行的输出、最近一次代码搜索的结论。它的作用是让代理在恢复之后不需要重新探索一遍环境，而是直接基于已有的证据继续推理。这三层关系就像操作系统的启动过程：目标层对应内核参数，进度层对应运行级别，证据层对应上次关机前的临时缓存。每层都独立存储，任何一层丢失，都可以从其他层重新推导。2.3 幂等重启：灾后恢复的关键协议让代理像 init.d 服务一样重启，还有一个前提条件：代理的操作必须是幂等的。所谓幂等，就是无论同一个动作被执行一次还是十次，最终的结果都一致。很多编码代理在上下文压缩后最大的问题是“重复劳动”。它忘了自己已经改过某个函数，于是又改了一遍；它忘了自己已经确认过某个测试通过，于是又跑了一遍；它忘了自己已经否决过某个方案，于是又提了一遍。这就是典型的非幂等行为。我的应对方式是在进度层里维护一个“完成标记列表”，每次动作完成后就把文件哈希、测试状态、决策结论记录下来。代理在恢复时必须先检查这个列表，如果某个动作已经有完成标记，就跳过它，绝不重做。这一步看起来简单，但在实际操作中能把恢复后的无意义工作量减少一半以上。3. 《记忆碎片》的启示：外部记忆比脑子里的记忆更可靠3.1 代理的记忆不该是“稀释过的聊天摘要”电影《记忆碎片》讲了一个短期记忆受损的人如何靠笔记、照片、纹身来维持生活逻辑。他每过几分钟就会忘记刚才做了什么，但他可以翻开笔记本，看到自己写下的话，从而知道下一步该干什么。AI 编码代理在上下文压缩后的处境和这个角色高度相似：模型本身没有主动遗忘机制，但上下文窗口的压缩相当于外部的“脑损伤”。你无法阻止压缩发生，也不需要阻止，但你可以学电影里的做法：把记忆写到身体之外。这里的“身体之外”就是工作区里的状态文件。我见过一些人试图通过不断让模型“总结之前的对话摘要”来对抗压缩，但事实证明这是最脆弱的方式：摘要也会被压缩，压缩后的摘要又会变成更模糊的摘要，最后你得到的只是一句“我们正在解决一些用户反馈的问题”之类毫无价值的话。与其维护一段稀释过的对话记忆，不如维护一组结构化的外部记忆：目标、进度、证据、标记。这些不是自然语言总结，而是机器可读的事实记录。3.2 给代理刻上的“纹身”：目标锚、指纹、状态戳在《记忆碎片》里，主角最可靠的记忆不是笔记，而是纹在身上的关键词。那些关键词很短、很硬、不会因为情绪或遗忘而改变。对代理来说，我设计了三种“纹身”：第一种是目标锚，是一句不可妥协的最终目标描述，比如“交付一个带身份验证的 API 网关”。这句描述必须简短到即使在压缩后的上下文里也能完整保留。第二种是环境指纹，是当前工作区的一组哈希值、文件清单和关键配置路径。代理恢复后可以通过指纹确认自己到底在哪个项目、哪个分支、哪个目录层级。第三种是状态戳，是一个执行计数和时间戳，记录当前是第几次重启、上一次进度确认发生在什么时刻。状态戳能帮代理快速判断自己是不是掉进了一个“不断重复同一阶段”的循环。这三种纹身有一个共同特征：短、不可歧义、必须持久保存。不要试图把详细设计文档写进状态文件里，那只会撑爆恢复上下文。3.3 笔记不是日志：怎么写出能自我重建的状态描述很多人会把状态文件写成流水账，比如“第 3 步完成了，第 4 步在做”，但这种描述对代理恢复毫无帮助。代理需要的不是“发生过什么”，而是“接下来基于什么状态、可以做什么”。我写状态描述有一个原则：每条描述必须能在不参考任何历史对话的情况下，独立支撑一个动作的决策。比如“当前已完成 modules/queue.py 中调度循环的初步实现，测试 file tests/test_queue.py 中 3 个用例通过，剩余待办为增大并发时出现的竞态问题”。这句话里包含了位置、进展、验证结果、下一步方向，代理恢复后可以直接拿它当行动依据。用一句话总结：状态文件是代理的“可执行记忆”，不是聊天记录的摘要，更不是心情随笔。如果一段描述无法让另一个人（或另一个模型）看完后立刻知道接下来做什么，那这段描述就不合格。4. 落地架构：一个能扛住压缩的编码代理工作流4.1 文件系统布局：把状态放进工作区而不是聊天窗我建议在项目根目录下创建一个.agent/state目录，专门存放代理状态文件。目录结构通常是这样：.agent/state/ goals.md # 目标锚 + 硬性约束 progress.yaml # 当前阶段、待办清单、完成标记 evidence/ # 近期的操作证据快照 ......关键点是：这个目录必须被纳入版本控制（如果项目用 git，就让这个目录一起提交）。因为状态文件如果只存在本地磁盘上，一旦工作区被迁移或清理，代理照样失忆。放进版本控制里，状态就等于有了分布式备份。我见过有人把状态文件放在聊天工具的“记忆库”或“项目备忘”里，但这违背了就近原则：代理每次读状态都要跨系统调用，既慢又容易失败。放在工作区里，代理只需要一次文件系统读取，可靠性高得多。4.2 一轮编码会话的完整运行循环我的代理工作流不再是一个持续的对话流，而是一个由多个“启动-执行-打点-恢复”阶段组成的循环。同一段任务，代理可能会经历几十次上下文重建，但每一次重建后它都能从磁盘里恢复心智模型。具体运行循环如下：启动阶段：代理先读取 goals.md 和 progress.yaml，确认目标、当前阶段、禁止动作。指纹核对阶段：代理检查当前工作树的 git 版本、关键文件哈希，确认文件系统状态和 progress.yaml 里记录的一致。计划阶段：根据 progress.yaml 中的 next_action 字段，代理决定接下来具体做什么，而不是依赖对话历史里的“刚才”猜测自己该做什么。执行阶段：代理修改代码、运行测试、搜索文件，并保存输出摘要到 evidence 目录。打点阶段：代理把当前阶段标记为完成、更新 progress.yaml 的 next_action、提交一次 git 快照。每次上下文被压缩后，重新执行 1 到 3 步即可。整个过程相当于 init.d 里的重新加载服务：你不用重写代理的“灵魂”，只需让它重新读取配置并应用增量。4.3 从 20 万到 20 万：标记预算的分配策略20 万 token 看起来很多，但如果你不做预算控制，它会像内存泄漏一样被慢慢耗尽：先是塞进无关日志，然后是臃肿的搜索结果，再然后是代理自己生成的中间分析，最后你连系统提示词都要被压缩。我自己的分配策略是：系统提示词控制在 5000 token 以内；目标锚控制在 2000 token 以内；进度层控制在 3000 token 以内；证据层控制在 2000 token 以内；剩下的全部留给当前执行任务的上下文。也就是说，真正核心的持久化状态加起来不超过 12000 token，剩下的 18 万 token 都是“临时工作区”。这个策略的妙处在于：即使上下文被压缩到只剩最后 2 万 token，核心状态依然可以全量装入上下文，代理不会在启动阶段就发生信息丢失。如果代理还要执行长文件操作，那就在临时上下文里处理，处理完把结论写回进度层。5. 模拟脑叶切除：实操测试与结果对照5.1 制造一次“人工失忆”就算你相信这套架构理论上行得通，也一定要亲自动手做一次“模拟脑叶切除术”测试。做法很简单：让代理在一个模拟项目里执行一个较长的编码任务，运行到一半时，强行切断它的对话会话，然后在新会话里只执行启动协议，看它能不能继续推进任务。我常用的切割方式是：先让代理完成第一阶段开发，把状态文件提交好；然后在新会话里清空所有聊天历史，只在初始消息里附上“请读取 .agent/state 并继续工作”。这比等 API 层自动截断更严格，因为它模拟的是完全失忆，不是部分遗忘。第一次做这个测试时，我预期代理会比较混乱，但它读状态文件后直接说了一句话：“检测到当前处于阶段 3，下一动作为……”，然后开始写测试用例。那一刻我确实有种“这一套设计没有白做”的感觉。但我也发现，状态文件如果不写清楚，恢复就会很生硬：代理虽然不会瞎猜目标，但会对某些环境细节过度怀疑，反复检查目录结构。5.2 恢复前后的关键指标对比我在测试中记录了几个指标：恢复时间、前五步操作的准确率、产生多余代码的概率、以及最终交付物与完整上下文版本的一致性。有状态文件的情况下，恢复时间通常在 1 分钟以内，而且代理前五步操作基本直接落在当前阶段的关键路径上，不会重新探索已经完成的区域。而没有状态文件的对照组，代理恢复后会浪费时间重新阅读整个项目结构，重新猜测需求，甚至重新实现已经被否决的旧方案。两者最终交付物的一致性差距也很大：有状态文件的版本基本能到达原路径终点，没有状态文件的版本往往产出完全不同风格和结构的代码。5.3 不同压缩策略下的表现我还尝试过几种压缩策略，包括“截断中间段只留头部和尾部”“全文摘要成一段”“只保留最近系统消息”。结论是：无论压缩策略是什么，只要状态文件还在，代理的核心目标都不会丢失；但如果只依赖聊天摘要，代理的心态就会像坐过山车一样忽高忽低，决策时自信、行动时偏航。有意思的是，即使压缩策略极端到“只保留系统提示词和状态文件”，代理依然能启动并完成大部分待办项。这说明外部状态文件的语义承载能力远高于对话摘要，因为它没有被二次转述过，始终是原始事实。6. 实战中踩过的坑与排查方法6.1 状态文件与真实代码脱节最大的坑是状态文件写得太美，实际代码完全不是那么回事。比如进度层写着“已完成接口鉴权”，但代码里鉴权逻辑其实还没提交，或者已经被你在手动调试时改掉了。代理恢复后看到状态文件里描述的任务，会以为代码已经处于那个状态，然后直接在其基础上开发，最终产生一堆基于假象的改动。解决办法是：每次打点之前，强制要求代理先执行一遍相关测试和文件哈希校验，确认“状态文件描述”和“真实文件树”一致。如果校验失败，就先更新状态文件，再继续下一步。宁可多花几秒校验，也不要把错误状态固化下来。6.2 记忆碎片越攒越乱，上下文却没有变小状态文件如果一直往里塞内容，会慢慢变成一个巨大的“记忆垃圾场”，恢复时反而把宝贵的上下文预算全耗尽。有个阶段我为了保险，把每一次动作的完整日志都写进 evidence 目录，结果代理启动时把整个目录都读了一遍，上下文瞬间上涨 3 万 token。教训是：外部记忆也要有淘汰策略。我后来规定 evidence 目录只保留最近 10 条操作摘要，更早的数据直接提交进 git 历史里就好，不需要让代理每次启动都重新加载一遍。真正要进入上下文的必须是高度浓缩过的结论，而不是过程的完整复述。6.3 恢复后代理陷入“零起点焦虑”有些代理在恢复后发现自己丢了对话历史，会变得过分谨慎，反复检查环境、重新阅读目标文件、重跑验证流程，反而降低了效率。这种“零起点焦虑”在心理上可以理解，但在工程上不可接受。我的方法是：状态戳里明确写入一个“恢复级别”字段。如果代理检测到恢复级别为 2，就表示“只需读取目标层和进度层，不要重新探索项目结构”；恢复级别为 3 时才允许做完整重新扫描。这样，代理每次恢复的行为模式是确定性的，而不是情绪化的。6.4 多代理协作时的状态版本冲突当你开始让多个代理实例并行处理同一个项目时，状态文件的并发写就成了问题。两个代理同时更新 progress.yaml，后写的一方会把前写的一方的进度覆盖掉，最终状态缺失某一半进展。解决方式有两个：一是把状态文件拆分成多个独立文件，每个代理只写属于自己的状态；二是用 git 分支隔离，每个代理在自己的分支上打点，最后手工合并。我建议小项目直接选第一种，大项目才考虑分支方案。无论选哪种，都要把状态文件视为普通代码文件来对待，引入版本冲突处理机制，而不是默认它永远是单线程安全的。7. 写在最后：这不是抵抗，而是并存我这套工作流不是要让代理“免疫压缩”，因为只要上下文窗口存在，压缩就会发生，这是客观规律。真正让人安心的不是避免压缩，而是设计一套状态系统，让压缩成为一次可恢复的服务重启，而不是一次灾难。在多次实验之后，我个人有一个很深的体会：编码代理的上下文窗口就像一个人脑海里的短期工作记忆，而磁盘上的状态文件才是它的长期记忆。短期记忆随时可能被外力抹除，但长期记忆只要还在磁盘上，代理就永远不会真正“忘记”自己是谁、在做什么、下一步要去哪里。如果你也在折腾 AI 编码代理，我建议你从今天开始，不要继续把对话历史当成唯一的记忆载体。花一个小时，把你手头项目的目标、进度、证据写成一个结构化的状态目录，然后亲手触发一次上下文压缩，看看代理能否从废墟里爬出来。能爬起来，你就真正理解了这个标题的含义；爬不起来，你也知道该改哪里。
如果你把一个 20 万 token 的“豪华上下文”一次性丢给某个 AI 编码代理，然后突然截掉其中 15 万 token，它的反应可能会让你很受冲击——它开始像一个刚醒来的失忆症患者一样行动，语气依然流畅，逻辑依然自洽，但已经彻底忘了自己最初要在哪个文件里改哪一行代码，更糟糕的是，它还会自信地告诉你“我理解了这个需求”，然后写出一段方向完全错误的实现。这不是夸张，这是我在某托管开发环境里反复踩过的坑：大上下文窗口给人一种“记忆可以无限外挂”的错觉，但上下文压缩一旦发生，代理的整个任务心智模型就像被做了一次脑叶切除手术。这个标题里的两个意象我很喜欢：Unix init.d 和电影《记忆碎片》，它们恰好对应了我对抗上下文压缩的核心思路。init.d 代表“服务可以随时被杀掉然后重新启动，只要状态声明还在磁盘上”；《记忆碎片》代表“人脑短期记忆靠不住时，就用纹身和纸条建立外部记忆”。把这两样东西放进 AI 编码代理的架构里，你能得到一个让人相当安心的结论：即使上下文被压缩到只剩一个尾巴，代理也能像什么都没发生过一样继续干活。这篇文章不打算讲某个具体模型或某个神秘外挂工具，而是分享一套我实际用在这个场景里的工作流：把代理当作服务来跑，把记忆外置为状态文件，把每次上下文清空都当成一次可重复的启动过程。如果你是做 AI 编码代理、自动化编程、或整天和超长上下文打交道的开发者，这篇内容应该对你有用。1. 先聊聊“20 万 token”这件诱人的外套1.1 全局上下文和有效上下文是两回事先说个反直觉的事实：你手头那个号称 20 万 token 的上下文窗口，并不意味着模型在任一时刻都能平等地“看到”这 20 万 token。从我实际使用的体感来看，哪怕模型架构上支持 20 万 token 的输入，参与每一步输出决策的往往只是最近的一段局部序列，再加上系统提示和当前正在处理的文件内容。更早期的指令、更早期的报错信息、更早期的代码片段，会被折叠成越来越粗糙的摘要，甚至在某个时刻直接变成“模糊的记忆”。这不是模型厂商在骗你，而是长序列推理的天然成本。注意力机制在极长输入下会被稀释，模型对早期 token 的“关注强度”会衰减，结果就是：它很可能记得“你让它处理一个队列系统”，但已经记不清队列的消费者应该从哪个消息源拉数据。当上下文窗口足够大时，这种衰减还不致命；但当压缩发生时，你的原始需求可能直接变成一段语义模糊的转述。1.2 “脑叶切除术”到底切掉了什么上下文压缩这件事，在 API 层往往以一个很隐蔽的方式发生：它不会明着告诉你“我把你的前 10 万 token 删了”，而是把中间一大段内容替换成自然语言摘要。你可能前一秒还在和代理讨论某个接口的返回值格式，下一秒它就只能根据一段概括性文字猜测你的意图。我自己对这种现象有句吐槽：这是在给代理做脑叶切除术——切除的恰好是它构建任务心智模型最关键的那部分。被切掉的东西具体有三类。第一类是目标和验收标准，也就是“你到底要什么”；第二类是约束和禁忌，也就是“哪些东西千万别碰”；第三类是已经探索过的盲区，也就是“哪些方案已经试过了，别再来一遍”。这三类信息恰恰是纯对话式记忆最容易丢失的，因为它们在对话早期就出现了，一旦被压缩，后续所有决策都会歪掉。1.3 为什么编码代理比聊天会话更怕压缩普通聊天场景里，上下文压缩造成的后果，顶多是被用户纠正一次“我刚才不是这个意思”。但编码代理不一样，它每次决策都映射为对真实文件系统的修改。如果它忘记了你禁止改动某个模块，它不会重新问你，而是直接生成一段重构代码，然后提交上去。我在某个模拟项目里就遇到过这种事：我让代理完成一个异步任务调度模块，中间我明确说过“不要动底层存储接口，只改调度层”。一万行代码之后上下文被压缩，代理在后续重构中判断“底层接口的鉴权逻辑是这个任务的关键瓶颈”，于是自作主张重写了鉴权模块，差点把整个系统的安全边界破坏掉。从那以后我得出一个结论：不要把编码代理当成一个“聊天遗忘问题”来处理，而是当成一个“分布式系统状态管理问题”来处理。聊天窗口只是瞬时的工作内存，磁盘状态才是唯一可靠的长期记忆。2. init.d 的启示：把代理当服务跑，而不是当对话聊2.1 init.d 的思想移植：声明期望，而不是记忆过程Unix 里的 init.d 是一个让我想到就觉得很踏实的设计。它的核心逻辑是：无论系统之前经历过多少次崩溃、重启、电源故障，只要有一组声明式的启动脚本放在指定目录里，系统就能按预定顺序把服务拉起来。服务进程本身可以随时被杀掉，但它的“重启意图”是持久化的。把这个思想移植到 AI 编码代理上，就形成了一句我自己的口头禅：代理不靠上下文里的记忆活着，靠磁盘上的状态声明活着。具体做法是：不要在对话里反复叮嘱代理“记住某某约定”，而是把这些约定写成一份独立的状态文件，放进工作区里的 .agent 目录。代理每开始一个新会话、每经历一次上下文压缩、每被用户打断又恢复，都先加载这份状态文件，而不是加载一段聊天记录。这样，“记住约定”就从模型的注意力问题，变成了文件系统的读写问题。2.2 状态文件的三种层次：目标层、进度层、证据层在实践中，我会把代理状态拆成三层：目标层、进度层、证据层。三层各自承担不同的职责。目标层是一个精简的子目标描述文件，里面写明最终交付物是什么、有哪些硬性约束、有哪些绝对不能碰的代码禁区。它的作用相当于 init.d 里的启动参数：不解释历史，只定义当前应该处于什么状态。进度层是代理当前执行阶段的检查点，包含当前处于哪个阶段、接下来要做哪个动作、有哪些前置条件需要满足。它相当于 init.d 脚本里的“runlevel”：告诉代理现在应该启动到什么级别。证据层则是一批短期快照文件，记录最近几次操作的结果摘要、最近一次测试执行的输出、最近一次代码搜索的结论。它的作用是让代理在恢复之后不需要重新探索一遍环境，而是直接基于已有的证据继续推理。这三层关系就像操作系统的启动过程：目标层对应内核参数，进度层对应运行级别，证据层对应上次关机前的临时缓存。每层都独立存储，任何一层丢失，都可以从其他层重新推导。2.3 幂等重启：灾后恢复的关键协议让代理像 init.d 服务一样重启，还有一个前提条件：代理的操作必须是幂等的。所谓幂等，就是无论同一个动作被执行一次还是十次，最终的结果都一致。很多编码代理在上下文压缩后最大的问题是“重复劳动”。它忘了自己已经改过某个函数，于是又改了一遍；它忘了自己已经确认过某个测试通过，于是又跑了一遍；它忘了自己已经否决过某个方案，于是又提了一遍。这就是典型的非幂等行为。我的应对方式是在进度层里维护一个“完成标记列表”，每次动作完成后就把文件哈希、测试状态、决策结论记录下来。代理在恢复时必须先检查这个列表，如果某个动作已经有完成标记，就跳过它，绝不重做。这一步看起来简单，但在实际操作中能把恢复后的无意义工作量减少一半以上。3. 《记忆碎片》的启示：外部记忆比脑子里的记忆更可靠3.1 代理的记忆不该是“稀释过的聊天摘要”电影《记忆碎片》讲了一个短期记忆受损的人如何靠笔记、照片、纹身来维持生活逻辑。他每过几分钟就会忘记刚才做了什么，但他可以翻开笔记本，看到自己写下的话，从而知道下一步该干什么。AI 编码代理在上下文压缩后的处境和这个角色高度相似：模型本身没有主动遗忘机制，但上下文窗口的压缩相当于外部的“脑损伤”。你无法阻止压缩发生，也不需要阻止，但你可以学电影里的做法：把记忆写到身体之外。这里的“身体之外”就是工作区里的状态文件。我见过一些人试图通过不断让模型“总结之前的对话摘要”来对抗压缩，但事实证明这是最脆弱的方式：摘要也会被压缩，压缩后的摘要又会变成更模糊的摘要，最后你得到的只是一句“我们正在解决一些用户反馈的问题”之类毫无价值的话。与其维护一段稀释过的对话记忆，不如维护一组结构化的外部记忆：目标、进度、证据、标记。这些不是自然语言总结，而是机器可读的事实记录。3.2 给代理刻上的“纹身”：目标锚、指纹、状态戳在《记忆碎片》里，主角最可靠的记忆不是笔记，而是纹在身上的关键词。那些关键词很短、很硬、不会因为情绪或遗忘而改变。对代理来说，我设计了三种“纹身”：第一种是目标锚，是一句不可妥协的最终目标描述，比如“交付一个带身份验证的 API 网关”。这句描述必须简短到即使在压缩后的上下文里也能完整保留。第二种是环境指纹，是当前工作区的一组哈希值、文件清单和关键配置路径。代理恢复后可以通过指纹确认自己到底在哪个项目、哪个分支、哪个目录层级。第三种是状态戳，是一个执行计数和时间戳，记录当前是第几次重启、上一次进度确认发生在什么时刻。状态戳能帮代理快速判断自己是不是掉进了一个“不断重复同一阶段”的循环。这三种纹身有一个共同特征：短、不可歧义、必须持久保存。不要试图把详细设计文档写进状态文件里，那只会撑爆恢复上下文。3.3 笔记不是日志：怎么写出能自我重建的状态描述很多人会把状态文件写成流水账，比如“第 3 步完成了，第 4 步在做”，但这种描述对代理恢复毫无帮助。代理需要的不是“发生过什么”，而是“接下来基于什么状态、可以做什么”。我写状态描述有一个原则：每条描述必须能在不参考任何历史对话的情况下，独立支撑一个动作的决策。比如“当前已完成 modules/queue.py 中调度循环的初步实现，测试 file tests/test_queue.py 中 3 个用例通过，剩余待办为增大并发时出现的竞态问题”。这句话里包含了位置、进展、验证结果、下一步方向，代理恢复后可以直接拿它当行动依据。用一句话总结：状态文件是代理的“可执行记忆”，不是聊天记录的摘要，更不是心情随笔。如果一段描述无法让另一个人（或另一个模型）看完后立刻知道接下来做什么，那这段描述就不合格。4. 落地架构：一个能扛住压缩的编码代理工作流4.1 文件系统布局：把状态放进工作区而不是聊天窗我建议在项目根目录下创建一个.agent/state目录，专门存放代理状态文件。目录结构通常是这样：.agent/state/ goals.md # 目标锚 + 硬性约束 progress.yaml # 当前阶段、待办清单、完成标记 evidence/ # 近期的操作证据快照 ......关键点是：这个目录必须被纳入版本控制（如果项目用 git，就让这个目录一起提交）。因为状态文件如果只存在本地磁盘上，一旦工作区被迁移或清理，代理照样失忆。放进版本控制里，状态就等于有了分布式备份。我见过有人把状态文件放在聊天工具的“记忆库”或“项目备忘”里，但这违背了就近原则：代理每次读状态都要跨系统调用，既慢又容易失败。放在工作区里，代理只需要一次文件系统读取，可靠性高得多。4.2 一轮编码会话的完整运行循环我的代理工作流不再是一个持续的对话流，而是一个由多个“启动-执行-打点-恢复”阶段组成的循环。同一段任务，代理可能会经历几十次上下文重建，但每一次重建后它都能从磁盘里恢复心智模型。具体运行循环如下：启动阶段：代理先读取 goals.md 和 progress.yaml，确认目标、当前阶段、禁止动作。指纹核对阶段：代理检查当前工作树的 git 版本、关键文件哈希，确认文件系统状态和 progress.yaml 里记录的一致。计划阶段：根据 progress.yaml 中的 next_action 字段，代理决定接下来具体做什么，而不是依赖对话历史里的“刚才”猜测自己该做什么。执行阶段：代理修改代码、运行测试、搜索文件，并保存输出摘要到 evidence 目录。打点阶段：代理把当前阶段标记为完成、更新 progress.yaml 的 next_action、提交一次 git 快照。每次上下文被压缩后，重新执行 1 到 3 步即可。整个过程相当于 init.d 里的重新加载服务：你不用重写代理的“灵魂”，只需让它重新读取配置并应用增量。4.3 从 20 万到 20 万：标记预算的分配策略20 万 token 看起来很多，但如果你不做预算控制，它会像内存泄漏一样被慢慢耗尽：先是塞进无关日志，然后是臃肿的搜索结果，再然后是代理自己生成的中间分析，最后你连系统提示词都要被压缩。我自己的分配策略是：系统提示词控制在 5000 token 以内；目标锚控制在 2000 token 以内；进度层控制在 3000 token 以内；证据层控制在 2000 token 以内；剩下的全部留给当前执行任务的上下文。也就是说，真正核心的持久化状态加起来不超过 12000 token，剩下的 18 万 token 都是“临时工作区”。这个策略的妙处在于：即使上下文被压缩到只剩最后 2 万 token，核心状态依然可以全量装入上下文，代理不会在启动阶段就发生信息丢失。如果代理还要执行长文件操作，那就在临时上下文里处理，处理完把结论写回进度层。5. 模拟脑叶切除：实操测试与结果对照5.1 制造一次“人工失忆”就算你相信这套架构理论上行得通，也一定要亲自动手做一次“模拟脑叶切除术”测试。做法很简单：让代理在一个模拟项目里执行一个较长的编码任务，运行到一半时，强行切断它的对话会话，然后在新会话里只执行启动协议，看它能不能继续推进任务。我常用的切割方式是：先让代理完成第一阶段开发，把状态文件提交好；然后在新会话里清空所有聊天历史，只在初始消息里附上“请读取 .agent/state 并继续工作”。这比等 API 层自动截断更严格，因为它模拟的是完全失忆，不是部分遗忘。第一次做这个测试时，我预期代理会比较混乱，但它读状态文件后直接说了一句话：“检测到当前处于阶段 3，下一动作为……”，然后开始写测试用例。那一刻我确实有种“这一套设计没有白做”的感觉。但我也发现，状态文件如果不写清楚，恢复就会很生硬：代理虽然不会瞎猜目标，但会对某些环境细节过度怀疑，反复检查目录结构。5.2 恢复前后的关键指标对比我在测试中记录了几个指标：恢复时间、前五步操作的准确率、产生多余代码的概率、以及最终交付物与完整上下文版本的一致性。有状态文件的情况下，恢复时间通常在 1 分钟以内，而且代理前五步操作基本直接落在当前阶段的关键路径上，不会重新探索已经完成的区域。而没有状态文件的对照组，代理恢复后会浪费时间重新阅读整个项目结构，重新猜测需求，甚至重新实现已经被否决的旧方案。两者最终交付物的一致性差距也很大：有状态文件的版本基本能到达原路径终点，没有状态文件的版本往往产出完全不同风格和结构的代码。5.3 不同压缩策略下的表现我还尝试过几种压缩策略，包括“截断中间段只留头部和尾部”“全文摘要成一段”“只保留最近系统消息”。结论是：无论压缩策略是什么，只要状态文件还在，代理的核心目标都不会丢失；但如果只依赖聊天摘要，代理的心态就会像坐过山车一样忽高忽低，决策时自信、行动时偏航。有意思的是，即使压缩策略极端到“只保留系统提示词和状态文件”，代理依然能启动并完成大部分待办项。这说明外部状态文件的语义承载能力远高于对话摘要，因为它没有被二次转述过，始终是原始事实。6. 实战中踩过的坑与排查方法6.1 状态文件与真实代码脱节最大的坑是状态文件写得太美，实际代码完全不是那么回事。比如进度层写着“已完成接口鉴权”，但代码里鉴权逻辑其实还没提交，或者已经被你在手动调试时改掉了。代理恢复后看到状态文件里描述的任务，会以为代码已经处于那个状态，然后直接在其基础上开发，最终产生一堆基于假象的改动。解决办法是：每次打点之前，强制要求代理先执行一遍相关测试和文件哈希校验，确认“状态文件描述”和“真实文件树”一致。如果校验失败，就先更新状态文件，再继续下一步。宁可多花几秒校验，也不要把错误状态固化下来。6.2 记忆碎片越攒越乱，上下文却没有变小状态文件如果一直往里塞内容，会慢慢变成一个巨大的“记忆垃圾场”，恢复时反而把宝贵的上下文预算全耗尽。有个阶段我为了保险，把每一次动作的完整日志都写进 evidence 目录，结果代理启动时把整个目录都读了一遍，上下文瞬间上涨 3 万 token。教训是：外部记忆也要有淘汰策略。我后来规定 evidence 目录只保留最近 10 条操作摘要，更早的数据直接提交进 git 历史里就好，不需要让代理每次启动都重新加载一遍。真正要进入上下文的必须是高度浓缩过的结论，而不是过程的完整复述。6.3 恢复后代理陷入“零起点焦虑”有些代理在恢复后发现自己丢了对话历史，会变得过分谨慎，反复检查环境、重新阅读目标文件、重跑验证流程，反而降低了效率。这种“零起点焦虑”在心理上可以理解，但在工程上不可接受。我的方法是：状态戳里明确写入一个“恢复级别”字段。如果代理检测到恢复级别为 2，就表示“只需读取目标层和进度层，不要重新探索项目结构”；恢复级别为 3 时才允许做完整重新扫描。这样，代理每次恢复的行为模式是确定性的，而不是情绪化的。6.4 多代理协作时的状态版本冲突当你开始让多个代理实例并行处理同一个项目时，状态文件的并发写就成了问题。两个代理同时更新 progress.yaml，后写的一方会把前写的一方的进度覆盖掉，最终状态缺失某一半进展。解决方式有两个：一是把状态文件拆分成多个独立文件，每个代理只写属于自己的状态；二是用 git 分支隔离，每个代理在自己的分支上打点，最后手工合并。我建议小项目直接选第一种，大项目才考虑分支方案。无论选哪种，都要把状态文件视为普通代码文件来对待，引入版本冲突处理机制，而不是默认它永远是单线程安全的。7. 写在最后：这不是抵抗，而是并存我这套工作流不是要让代理“免疫压缩”，因为只要上下文窗口存在，压缩就会发生，这是客观规律。真正让人安心的不是避免压缩，而是设计一套状态系统，让压缩成为一次可恢复的服务重启，而不是一次灾难。在多次实验之后，我个人有一个很深的体会：编码代理的上下文窗口就像一个人脑海里的短期工作记忆，而磁盘上的状态文件才是它的长期记忆。短期记忆随时可能被外力抹除，但长期记忆只要还在磁盘上，代理就永远不会真正“忘记”自己是谁、在做什么、下一步要去哪里。如果你也在折腾 AI 编码代理，我建议你从今天开始，不要继续把对话历史当成唯一的记忆载体。花一个小时，把你手头项目的目标、进度、证据写成一个结构化的状态目录，然后亲手触发一次上下文压缩，看看代理能否从废墟里爬出来。能爬起来，你就真正理解了这个标题的含义；爬不起来，你也知道该改哪里。