AutoCompact：教 AI 编程助手学会何时遗忘
你有没有过这样的经历：打开几十个浏览器标签页，每个都"以后可能用得上"，结果浏览器越来越卡，最后你不得不关掉一些——但你不知道该关哪些。你犹豫的不是"要不要关"，而是"什么时候关、关哪些"。
目录
AutoCompact：教 AI 编程助手学会"何时遗忘"
你有没有过这样的经历：打开几十个浏览器标签页，每个都"以后可能用得上"，结果浏览器越来越卡，最后你不得不关掉一些——但你不知道该关哪些。你犹豫的不是"要不要关"，而是"什么时候关、关哪些"。
AI 编程助手也面临同样的问题。当它帮你修一个复杂 bug 时，需要读代码、跑测试、看报错、再读代码……每一步都在往上下文窗口里塞东西。塞满了，模型就"看不过来"了，性能下降。解决方案看起来很简单：压缩上下文，把冗长的历史对话变成简短的摘要。但问题来了——什么时候压缩？压缩什么？压缩完怎么继续？
现有的做法要么是"到了长度就压"（length-triggered），要么是"模型自己决定要不要压"（proactive）。前者太机械，后者太随意。这篇来自阿里巴巴团队的论文提出了 AutoCompact，让模型通过强化学习自己学会"何时压缩"——而且，压缩行为和编程行为在同一个任务奖励下联合训练，不需要额外的奖励设计。
核心机制：一个 compact() 动作，三种决策合一
AutoCompact 的设计简洁到几乎"不像一个新方法"。它在模型的动作空间里加了一个特殊动作：compact()。当模型调用这个动作时，当前上下文会被替换成模型自己生成的摘要，然后模型基于摘要继续工作。
就这么简单？不。关键在于怎么训练。
传统做法会给压缩单独设计一个奖励：摘要质量好不好？信息丢没丢？但 AutoCompact 没有这么做。它用的是 GRPO（Group Relative Policy Optimization），唯一的奖励信号是最终任务是否通过测试。修好了 bug 得 1 分，没修好得 0 分。
这意味着模型必须同时学会三件事： 1. 什么时候压缩——太早压缩会丢信息，太晚压缩会超长 2. 压缩什么——哪些信息对后续任务关键，哪些可以丢 3. 压缩后怎么继续——基于摘要继续工作，而不是"忘了自己在干嘛"
三件事共用同一个奖励信号。这就像你让一个人学做饭，不告诉他"切菜要均匀""火候要适中"，只告诉他"最后这道菜好不好吃"。他得自己摸索出切菜和火候的关系。
训练细节：轨迹分段，优势共享
这里有一个技术细节值得展开。当模型调用 compact() 后，上下文被重写了——之前的对话历史变成了一个摘要。这意味着轨迹不再是"一条线"了，而是在压缩点被"切断"了。
AutoCompact 的做法是：在每次压缩处将轨迹切成段。每一段内部，模型看到的前缀只增长不缩短（正常的自回归生成）。不同段之间共享同一条轨迹的优势值（advantage）。
换句话说：压缩决策、摘要内容、压缩后的行为，三者收到的是同一个"任务成功与否"的信号。如果任务最终成功了，好的压缩决策会被强化；如果失败了，差的压缩决策会被抑制。模型不需要被告诉"你压缩得好不好"，它只需要从最终结果中学习。
这种设计避免了"奖励工程"的陷阱——你不需要设计一个"摘要质量评估器"，也不需要担心压缩奖励和任务奖励之间的冲突。任务奖励就是唯一的老师。
实验结果：9.2% 的绝对提升
在 SWE-bench Verified（软件工程基准测试）上，AutoCompact 取得了 39.6% 的通过率，比基础模型的 30.4% 提升了 9.2 个百分点。在 SWE-PolyBench Verified 上，通过率从 19.5% 提升到 24.5%，增长了 5.0 个百分点。
这些数字本身不算惊人。真正有意思的是消融实验：
固定压缩（Fixed Compaction）反而降低了性能——在两个基准上分别比基础模型低 1.6% 和 0.9%。这说明"无脑压缩"是有害的：如果你在不该压缩的时候压缩了，你会丢掉关键信息，性能反而下降。
CompactionRL（有 RL 但压缩是固定触发的） 比 Fixed 好一些（+3.9% 和 +1.2%），但仍然远不如 AutoCompact。这说明 RL 本身不够，关键是让模型自己决定何时压缩。
SFT 先建立基础行为，RL 再优化。AutoCompact-SFT（仅监督训练）已经让模型在 44.3% 的任务上使用压缩，RL 进一步提升到 58.5%。更重要的是，RL 减少了摘要中的信息遗漏：关键状态遗漏从 3.1% 降到 0.2%，下一步动作遗漏从 8.2% 降到 2.2%。
成本效率：压缩不只是为了性能
除了通过率，AutoCompact 还在成本效率上有显著优势。在 $0.10 的推理预算下，AutoCompact 比基础模型有 19.9% 的优势；即使在 $4.00 的高预算下，仍有 1.9% 的优势。
这意味着压缩不只是"在上下文满了时应急"，而是一种主动的成本优化策略——在任务早期就压缩冗余信息，可以节省大量 token 费用，同时不损失性能。
为什么这件事重要
这篇论文的核心贡献不在于"提出了上下文压缩"——这早有人做。而在于一个设计哲学：把上下文管理当作任务的一部分来训练，而不是当作一个独立的子问题来解决。
传统思路是"压缩是压缩，任务是任务，各管各的"。AutoCompact 说：不对，压缩决策本身就是任务执行的一部分。一个好的工程师不仅会修 bug，还知道什么时候该清理工作台、什么时候该重新读一遍代码。这种"元认知"能力不应该被单独训练，而应该在任务中自然涌现。
这让我想到一个更大的模式：AI 系统中的"遗忘"不是 bug，是 feature。人类的大脑也在不断遗忘——不是因为我们记不住，而是因为记住所有东西会让检索变得不可能。上下文窗口的大小限制，某种程度上"逼"着模型学会遗忘，这反而可能是一件好事。
当然，AutoCompact 也有局限。它目前只在编程任务上验证了，其他领域（对话、推理、创作）是否也适用？压缩的摘要质量如何评估（论文没有给出人工评估）？RL 训练需要的计算量是否可承受？这些问题留给了后续工作。
但至少，它证明了一件事：让模型自己学会"何时遗忘"，比告诉它"到了多少 token 就压缩"要好得多。