长会话最怕什么？不是模型不会写，也不是工具不够多，而是任务做到一半，历史内容被压缩后，模型突然忘记自己刚刚读过哪些文件、调用过哪些技能、正在推进哪个计划、后台还有哪些 Agent 没有回收结果。如果没有一套严密的状态恢复机制，自动压缩就会从"降本提效"变成"上下文断片"。Claude Code 的设计很有代表性：它并不幻想把所有历史原封不动塞回来，而是把"最可能马上用到的状态"做成附件包，在压缩后的第一轮重新交给模型。
|----------------------------------------------------------------------------|
| 本文重点：压缩不是简单删历史，而是一次上下文迁移。先快照、再清空、后恢复；文件、技能、计划、工具声明、异步任务分别走不同通道，最终让长任务继续推进。 |
一、为什么"压缩后恢复"是 AI 编码工具的生死线？
在 AI 编码场景里，长任务往往不是一次问答能解决的。模型要先阅读目录，再定位核心文件，再推理依赖关系，再修改逻辑，再运行测试，最后还要根据报错回到前面继续修。这个过程会不断吞掉上下文空间，历史消息越来越长，系统迟早要压缩。
压缩的意义，是把长长的对话浓缩成摘要，让后续任务还有空间继续进行。但问题也随之出现：摘要能保留"做过什么"，却很难完整保留"刚刚读过的具体文件内容""某个技能的完整行为约束""计划状态""后台 Agent 的运行状态""动态注册过的工具说明"。
所以，真正成熟的 Agent 系统不能只会压缩，还必须会恢复。恢复不是把所有历史倒回去，而是在有限空间里，把关键状态重新补到模型可见范围内。它本质上是一套上下文工程：哪些内容值得恢复？恢复多少？按什么顺序？重复内容要不要过滤？恢复后会不会破坏缓存？这些都是工程问题。
可以把它理解成手机系统的"后台恢复"。应用被系统清理后，如果重新打开还能回到刚才的页面，是因为系统提前保存了关键现场。AI 编码工具也一样，长会话被压缩后，要想不断片，就必须保存现场、清空状态、选择性恢复。
二、先保存现场再清空：快照-清空模式
压缩恢复的第一步，不是"恢复"，而是"快照"。系统在压缩前会把当前读过的文件状态从内存缓存中取出来，转成一个普通对象保存下来。这个快照通常包含文件路径、文件内容、读取时间戳等信息。
为什么保存完还要清空？因为从模型视角看，压缩后旧消息已经被摘要替换，它确实不再能看到之前读过的完整文件。如果系统继续保留旧缓存，就会造成一种危险的假象：程序以为模型还知道这些文件内容，于是后续可能跳过必要的重新注入，最终导致模型凭模糊记忆继续操作。
清空不是为了丢数据，而是为了让系统状态和模型真实视角保持一致。清空之后，再根据预算和优先级，把少数关键状态重新作为附件注入。这样既避免"假记忆"，又避免把压缩节省下来的空间立刻塞满。
这就是快照-清空-恢复模式的价值：先存现场，清掉脏状态，再精准回填。它比单纯缓存更可靠，也比全量恢复更省空间。
三、文件恢复不是全量回填：最近 5 个、单文件 5K、总预算 50K
文件恢复是最容易被误解的地方。很多人以为：既然系统知道模型读过哪些文件，那压缩后把所有文件都重新塞回来不就行了？答案是不行。因为一次长任务里，模型可能读过几十甚至上百个文件。如果全部恢复，压缩刚腾出的空间会马上被文件内容吃掉。
更合理的做法是设定预算。常见设计可以概括为三层限制：最多恢复最近读取的少数文件；每个文件最多恢复一个固定 token 上限；所有文件加起来不能超过总预算。这样做的结果是，恢复机制优先照顾"最近最可能继续使用"的文件，而不是照顾"历史上读过的一切"。
这背后的判断非常务实：模型下一步最可能编辑的，不是十几轮以前随手扫过的配置文件，而是刚刚阅读、刚刚分析、刚刚准备修改的文件。时间戳排序相当于给文件状态加了一个"新鲜度"指标。越新，越可能被恢复。
单文件上限也很关键。大文件如果完整注入，很可能一个文件就吃掉大量空间。把单文件控制在约 5K token，可以让系统在"有内容可用"和"不要过度膨胀"之间取得平衡。对于超大文件来说，恢复通常只保留开头或截断后的部分，所以在实际使用时，关键区域最好被单独读取、单独指出。
总预算则是最后的闸门。即使只有几个文件，如果加起来超过预算，也必须丢弃一部分。这听上去残酷，但它保证了压缩恢复不会反过来毁掉压缩本身。
四、文件如何决定恢复或丢弃：四层过滤管线
文件恢复的完整逻辑可以看成一条过滤管线。第一层是类型排除：计划文件通常不走普通文件恢复，因为计划有自己的专用恢复通道；记忆类文件也不需要通过普通文件恢复重复注入，因为它们会通过系统提示相关机制进入上下文。
第二层是重复排除：如果压缩后保留的尾部消息里已经包含某个文件的读取结果，那模型其实还能看到它，就不需要再重复恢复。重复注入不仅浪费空间，还可能打乱上下文结构。
第三层是时间排序：系统把剩下的文件按最近读取时间倒序排列，只取排名靠前的少数文件。这个策略很像浏览器恢复最近标签页：不是恢复你曾经打开过的所有页面，而是恢复当前工作最可能相关的几个。
第四层是预算控制：文件生成附件后，还要估算 token 数，按顺序累加，只要超过总预算，就停止接纳后续附件。也就是说，文件最终能不能"幸存"，不只取决于是否重要，还取决于体积是否合理。
这套管线体现了一个非常成熟的工程观：状态恢复不是情怀，而是成本收益计算。最有价值、最新鲜、最不重复、最不超预算的信息才值得进入下一轮。
五、技能为什么要重注入：被调用技能的选择性恢复
技能可以理解成一组可复用的行为说明和专业能力，比如代码审查、提交规范、测试验证、安全检查等。模型在某个任务里调用过技能后，技能内容会影响后续行为。压缩发生后，如果这些指令完全消失，模型可能继续做任务，但不再遵守之前的技能约束。
因此，技能需要独立恢复。不过，技能恢复也不是全量恢复所有技能，而是只恢复当前 Agent 真正调用过的技能。这样可以避免把无关能力塞进上下文，也能防止主流程和子 Agent 之间互相污染。
技能恢复还有一个很有意思的策略：倾向于截断，而不是直接丢弃。因为技能文件往往把最关键的行为规则放在开头，后面才是补充说明、案例、边界条件。把每个技能截断到固定上限，保留头部核心指令，通常比完全丢弃某个技能更稳。
这给开发者一个重要启发：写技能说明时，最关键的规则一定要放前面。不要把"必须运行测试""禁止直接覆盖用户改动""审查时先看安全风险"等关键约束放到尾部。因为一旦发生截断，尾部内容最容易丢失。
六、有些内容故意不恢复：技能列表的成本账
状态恢复听上去像是"多多益善"，但高级系统会故意不恢复某些内容。一个典型例子是完整技能名称列表。它能让模型知道有哪些技能可用，但如果压缩后每次都重新注入完整列表，就会产生额外 token 成本，而且这些内容未必立刻用得上。
更关键的是，模型通常已经通过工具 schema 知道技能工具存在；真正调用过的技能内容也会通过独立附件恢复。换句话说，完整技能列表的边际收益很低。与其每次压缩后重新发送一大段列表，不如保留已发送状态，让模型在需要时再通过搜索或工具机制发现更多能力。
这类设计体现了"恢复完整性"和"token 经济性"的平衡。信息并不是越完整越好，尤其在长会话里，每 1K token 都会影响速度、成本、缓存命中和后续空间。成熟的 Agent 系统，必须敢于舍弃低价值信息。
七、计划和模式双附件：不只恢复内容，还恢复行为轨道
复杂任务通常离不开计划。比如一次重构，要先理解模块，再列出改动步骤，再分阶段执行，再回归测试。压缩发生后，如果计划丢了，模型就可能只记得一个模糊目标，却忘记原来为什么要按那个顺序做。
因此，计划内容需要专门的恢复通道。计划文件不会走普通文件恢复，因为那样会跟其他文件争预算，也容易重复注入。专用计划附件可以把"正在执行的任务蓝图"直接带回模型视野。
但仅恢复计划内容还不够。还需要恢复模式状态。计划模式不是普通聊天状态，它意味着模型应该继续先分析、先提出方案、先等待确认，而不是马上动手修改。
所以，这里有两个互补附件：一个恢复计划内容，告诉模型"你正在做什么"；另一个恢复计划模式，告诉模型"你现在应该以什么行为规则继续"。内容和行为轨道都恢复了，长任务才能真正不断片。
八、Delta 完整重播：工具、Agent、MCP 指令重新亮相
在 Agent 系统里，工具并不一定一开始全部展开。为了保护缓存、降低提示词体积，很多工具会延迟加载；一些 Agent 列表、MCP 服务器指令也可能随着会话进展通过增量附件告诉模型。
问题是，压缩会把旧的增量附件一起吞掉。压缩后的上下文里，模型可能只看到摘要，却看不到之前被声明过的动态工具、子 Agent 和外部服务约束。如果不补回来，下一轮就可能出现能力缺失或规则遗忘。
解决办法是"完整重播"。它复用了增量机制，但把历史基线视为空。正常情况下，Delta 函数会比较"当前状态"和"历史已发送内容"，只发新增部分；压缩后把历史当成空，就等于重新宣告完整状态。
这是一种很聪明的复用：不用单独写一套恢复逻辑，只要让差异计算面对空基线，就能得到完整列表。重播内容通常包括延迟工具说明、可用 Agent 列表、MCP 指令和约束。
从工程上看，这和前面提到的 prompt caching、延迟工具加载是同一条思路：稳定的大前缀尽量不动，动态能力按需出现，必要时再通过附件重播，避免每轮都把全部工具说明塞进系统提示。
九、异步 Agent 状态：后台任务不能被压缩抹掉
现代 AI 编码工具越来越依赖子 Agent。主流程可以把搜索、审查、定位、分析等任务委派出去，让子 Agent 在自己的上下文中消化大量中间信息，只把结果摘要返回主流程。这样可以节省主上下文，也能让任务并行推进。
但异步任务带来一个新问题：压缩发生时，某些子 Agent 可能还在运行，或者已经完成但结果尚未被取回。如果压缩后模型忘记了它们，就可能重复启动相同任务，浪费时间和资源，甚至造成冲突。
所以，系统需要生成任务状态附件，告诉模型：哪些后台任务还在运行，任务描述是什么，当前进度如何，是否已有结果等待读取。这样压缩后的模型不会误以为一切都没发生过。
这其实是分布式系统里的老问题：主流程和后台任务之间必须有状态同步。AI Agent 只是换了表现形式，本质还是要避免重复执行、状态丢失和结果遗漏。
十、整体编排：从快照到附件包的恢复流水线
把所有机制串起来，就能看到一条完整流水线。第一步，压缩前保存文件状态快照；第二步，清空读文件缓存和嵌套记忆路径；第三步，并行生成文件附件和异步 Agent 状态附件；第四步，追加计划内容、计划模式、技能内容等专用附件；第五步，完整重播工具、Agent、MCP 指令相关 Delta；第六步，把这些附件合并到压缩后第一轮上下文里。
这个流程的特点是"分层恢复"。文件走文件预算，技能走技能预算，计划走独立通道，动态工具走 Delta 重播，后台任务走状态附件。不同类型的信息有不同恢复方式，而不是一锅炖。
另一个特点是"选择性恢复"。系统承认不可能恢复一切，所以重点恢复：最近使用、最可能继续需要、行为约束强、会影响下一步决策、会造成重复工作的状态。
第三个特点是"避免重复"。已经保留在尾部消息里的文件不重复恢复；计划文件不走普通文件通道；记忆文件不通过普通文件附件重复注入。所有这些细节都在减少上下文浪费。
这就是 Agent 工程和普通聊天机器人的差别：普通聊天只关心一句回答是否顺畅，Agent 工程要关心任务生命周期、工具状态、后台任务、缓存经济、恢复语义和失败边界。
十一、普通开发者如何利用这套机制提升长任务质量？
第一，保持文件读取聚焦。不要让模型一开始就读大量文件，尤其不要把"可能相关"的文件全部扫一遍。恢复机制更偏向最近读取的文件，所以任务后半段真正要改的文件，最好在关键节点重新读一次。
第二，重要文件要刷新时间戳。如果某个文件非常关键，但已经很久没被读取，临近压缩边界时可以让模型重新查看它。这样它更可能进入最近文件列表。
第三，大文件要拆关注点。大文件恢复可能被截断，模型未必能看到你关心的中间区域。更稳的方法是明确指出函数名、类名、配置段、错误位置，让模型围绕关键片段工作。
第四，技能说明要把核心规则放前面。因为技能恢复保留头部更稳，最重要的约束应该前置：目标、禁止事项、验证要求、输出格式、风险提醒都应该放在开头。
第五，复杂任务优先使用计划模式。计划拥有独立恢复通道，适合跨越较长工作流。如果任务要经历多轮探索、多轮修改、多轮测试，先规划再执行通常更稳。
第六，关键否决和关键决策要显式保留。摘要更容易记录"做了什么"，不一定完整记录"为什么没做另一个方案"。如果某个方案已经被否决，或者某个约束绝对不能忘，最好主动要求模型写入摘要重点。
十二、从这套设计看 Agent 上下文工程的底层原则
原则一：压缩一定要配套恢复。没有恢复的压缩，只是把信息丢失包装成了摘要。真正能用于生产的长任务系统，必须在压缩前保存关键现场，在压缩后补回必要状态。
原则二：恢复必须有预算。上下文窗口再大也不是无限的。文件、技能、计划、工具说明、MCP 指令、后台任务状态都想进来，就必须有明确上限和优先级。
原则三：不同状态要走不同通道。文件适合按时间和预算恢复；技能适合按调用记录恢复；计划适合专用通道；动态能力适合 Delta 重播；后台任务适合状态附件。统一处理反而会更乱。
原则四：状态要和模型真实视角一致。如果模型已经看不到旧文件内容，系统就不能假装它还记得。清空缓存是为了避免假记忆，附件恢复是为了重新建立真实上下文。
原则五：低价值信息要敢于不恢复。完整性不是最高目标，持续推进才是最高目标。真正要保留的是会影响下一步行动的信息，而不是所有历史细节。
十三、总结：自动压缩后不断片，靠的是一套状态恢复工程
Claude Code 的压缩后状态保留机制，表面看是在处理文件、技能、计划和工具声明，深层看是在解决一个通用难题：长会话 Agent 如何在上下文有限、任务复杂、工具众多、状态分散的情况下，继续稳定工作。
它的核心不是某个单点技巧，而是一整套组合拳：压缩前快照，压缩后清空，最近文件有限恢复，技能按调用重注入，计划和模式双通道保留，Delta 完整重播，异步 Agent 状态补回，低收益内容主动舍弃。
如果用一句话概括：自动压缩负责把历史变轻，状态恢复负责让任务不断。前者解决成本问题，后者解决连续性问题。只有两者配合，AI 编码助手才能真正承担长周期、复杂、多步骤的工程任务。
参考资料：https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd=6fkr