长程编码 Agent 有一个所有重度用户都体会过的痛点：任务越往后，上下文里堆的早期探索越没用——过时的假设、失败的修复尝试、几百行没人再看的工具输出。业界主流方案是按长度触发自动压缩，但什么时候该压、压的时候保留什么、压完怎么继续，这三件事一直没有好的答案。10 月 1 日挂上 arXiv 的 AutoCompact（arXiv:2610.02163，南洋理工团队）给出了一个训练侧的解法：把这些决策直接学进 Agent 策略。
核心思路：压缩是策略，不是机制
现有工具把压缩当作脚手架层的机械机制——上下文快满了就触发摘要。AutoCompact 的立场是：压缩决策本质上和「下一步调用哪个工具」一样，是策略的一部分，应该由模型自己判断。
为此它给终端式 REPL 脚手架增加了一个 compact() 动作，模型可以主动调用，也可以永远不调。训练分两段：先监督微调建立行为，再用强化学习打磨。
训练数据：judge 在线纠错
监督数据的收集是这篇论文最有工程味道的部分。团队在 379 个 SWE-rebench 任务上跑基础模型，用 GPT-5.5-Codex 做 judge，逐步审查三类决策：
- 触发时机——当前节点适不适合压缩；
- 工作状态——以
# Auto Context Summary开头的摘要是否保留了后续所需的信息； - 压缩后延续——压缩后的第一批动作是否遵循了摘要里的计划。
关键设计是纠正发生在执行之前：发现缺陷就替换成修正版，环境执行的是纠正后的输出，轨迹从好状态继续。最终收集到 1,052 条纠正轨迹，其中 24% 监督触发、53% 监督状态构建、23% 监督延续。评估时 judge 完全移除。
RL 阶段：只给二元任务奖励
第二段在 SWE-Gym 上用 GRPO 做端到端多轮强化学习，奖励只有「最终补丁是否通过测试」这一个二元信号，没有任何压缩专用的奖励塑形、没有 KL 惩罚、没有熵奖励。
技术上有个巧妙的处理：每次 compact() 会重写上下文前缀，所以轨迹要在重写处切分成多个 segment，同一轨迹的所有 segment 共享组内 advantage，策略损失按 token 级平均。这解决了「动作改写历史」给信用分配带来的麻烦。
结果：9.2 个绝对点，且低预算收益最大
基于 Qwen3-Coder-30B-A3B-Instruct 的主结果：
| 方法 | 上下文 | SWE-bench Verified | SWE-PolyBench |
|---|---|---|---|
| 完整历史基线 | 256K | 30.4% | 19.5% |
| 固定长度压缩 | 16K | 28.8% | 18.6% |
| AutoCompact-SFT | 256K | 32.2% | 21.7% |
| AutoCompact（SFT+RL） | 256K | 39.6% | 24.5% |
三个值得注意的细节：
- 固定长度压缩比不压缩还差 1.6 个点——机械压缩会伤人，这与很多工程团队的体感一致；
- 主动压缩在上下文远未溢出时就有收益：256K 窗口下没有任何轨迹触发强制压缩，AutoCompact 仍然领先全部六档推理预算（每任务 0.10 到 4.00 美元），且预算越紧收益越大；
- 消融证明压缩本身贡献了增益：同一检查点跳过
compact()调用后，优势在最低预算档损失 19.9%，最高预算档仍损失 1.9%。
RL 对压缩行为的改善是可量化的：主动压缩的任务占比 44.3% 到 58.5%，摘要遗漏关键状态 3.1% 到 0.2%，遗漏下一步动作 8.2% 到 2.2%。一个案例研究尤其精彩：SFT 版在摘要里记录了未解决的语法错误，却提议「直接结束」，评估时报 SyntaxError；RL 版的摘要与提议动作完全自洽，通过测试。作者把这称为摘要自洽性——信息覆盖率之外更本质的质量维度。
成本评估的口径也值得借鉴
论文的成本评估没有用「token 总数」这种粗粒度指标，而是按六档推理预算（每任务 0.10 到 4.00 美元）来切分通过率，缓存 token 按标准输入价的 20% 计价，所有通过率取三次运行平均。这个口径把「省钱」和「成功率」放在同一张图里，直接回答了工程团队最关心的问题：同样的钱能买到多高的任务完成率。
答案对低预算场景尤其友好：AutoCompact 的优势在最低预算档最大——因为它不是靠拉长轨迹堆成功，而是靠更聪明的状态管理减少浪费的探索步。这与很多「训练后变啰嗦」的 RL 后训练形成鲜明对比。
与工程实践的对照
把论文结论映射到现有工具链上，有三条可以直接执行的实践：
第一，检查你的脚手架有没有主动压缩机制。 大多数开源 Agent 框架只有长度触发的被动压缩。论文证明了「模型主动调用压缩」是可以训练出来的行为，框架层面应该把压缩暴露成模型可调用的动作，而不是只做水位监控。
第二，压缩摘要要有结构约定。 AutoCompact 的摘要以 # Auto Context Summary 开头，固定保留三类内容：已确立的结论、相关代码与工作区状态、剩余动作。这个结构比自由发挥的「总结一下进展」可靠得多，值得直接抄进自己的提示词模板。
第三，摘要自洽性应该是评估维度。 大多数团队评估 Agent 时只看任务成功率和 token 消耗，论文的案例研究揭示了第三个维度：摘要内容与后续动作是否自洽。SFT 模型能写出信息覆盖率很高的摘要，却提出与摘要矛盾的下一步动作——这种「总结写得漂亮但不用」的失败模式，值得加进你的回归测试集。
与本周生态的呼应
把这篇论文放进本周的语境看会更有味道：Pi Durable 刚刚把「压缩在后台异步进行、对话不阻塞」做成了框架特性；DeepSeek Harness 把执行轨迹的排查做成了产品功能；而 AutoCompact 回答的是更上游的问题——压缩的决策本身应该长在哪。
三者的分工正在清晰化：框架层负责压缩的机制（什么时候存检查点、怎么不丢消息），模型层负责压缩的判断（这个阶段该不该清、清什么）。短期内两层共存，长期看 AutoCompact 这类研究会把越来越多的 harness 决策内化进权重——这正是 harness 演化曲线的下一个拐点。
局限与工程意义
局限方面：RL 只在 32K token 序列上训练，短于评估时的 256K 窗口；研究绑定单一脚手架；作者明确建议与 Codex、Claude Code 等现有长度触发压缩机制结合而非替代。
对构建 Agent 产品的团队，这篇论文的价值在于三个可以直接抄走的结论：第一，提示词诱发不出主动压缩，基础模型几乎不会在溢出前调用压缩，这必须靠训练引入；第二，压缩时机应绑定任务阶段（定位完成之后、动手实现之前是最佳窗口），而不是上下文水位；第三，二元任务奖励足以塑造出高质量的压缩行为，不需要为压缩单独设计奖励——这对所有「想教会 Agent 某种元行为」的团队都是可复用的范式。