长任务里，Context 是一条越走越长的流水线。文件检索、代码阅读、修改、测试，每一步都会向上下文追加记录。运行越久，历史越多。目前常见的处理方式是设置长度阈值：剩余空间不足时，系统触发压缩，把此前的交互历史整理成摘要，Agent 再继续执行。
这套方案有一个结构性缺陷：Context 的长度与任务的进度并不同步。Agent 可能只消耗少量 Context 就定位了 Bug，正要进入修改阶段，此时大量搜索记录和失败假设的作用已开始下降，却仍占据上下文空间。反过来，Agent 也可能正卡在一个复杂问题的调查中，尚未找到原因，就因为触及长度阈值被强制压缩，尚未验证的线索就此丢失。两种情形，一处浪费，一处损伤。
1. 方案：把触发权交给模型
针对这个问题，一篇发表于上周的论文提出 AutoCompact: Learning When to Compact Context in Long-Horizon Coding Agents。核心思路是让 Coding Agent 自主判断压缩时机、生成压缩后的工作状态，并依据保留的信息继续执行。
实验以 Qwen3-Coder-30B-A3B-Instruct 为基础模型。在 SWE-bench Verified 与 SWE-PolyBench Verified 上，AutoCompact 的任务通过率分别提高了 9.2 与 5.0 个百分点。
传统方案里，Agent 不断积累工具输出与交互历史，直到 Context 用量达到预设阈值，压缩才被触发。AutoCompact 改为引入一个由模型主动调用的 compact() 动作。Agent 依据当前任务进度，决定是否需要整理已有信息。
2. 从长度阈值转向任务进度
以一次 Bug 修复为例，执行通常分为四个阶段：搜索代码仓库并找到相关文件；阅读代码、定位问题原因；修改代码并运行测试；检查修改结果并提交。
当 Agent 已完成问题定位、准备进入代码修改时，此前的大量搜索记录和探索过程已不必完整保留。此时 Agent 可以主动调用 compact()，把已确认的问题原因、相关代码位置和后续任务整理成工作状态摘要，为修改阶段保留必要上下文。
这套机制实际是三个连续决策。
第一，何时压缩。判断当前阶段是否完成，历史信息能否被整理为更简洁的工作状态。
第二，保留哪些信息。保留已确认的结论、相关代码位置、工作区状态以及剩余任务，舍弃不再需要的探索细节。
第三，压缩后如何继续。根据摘要中的工作状态继续执行，避免重复搜索、遗漏修改或偏离原定任务。
实际压缩时，AutoCompact 会把此前的交互历史替换为模型生成的工作状态摘要。摘要以 "# Auto Context Summary" 开头，同时保留原始任务要求。Agent 从压缩后的上下文继续工作。
但允许模型主动调用 compact() 只解决了接口问题。模型还需要学会何时调用、如何正确使用压缩结果。这是训练要解决的问题。
3. 用 Judge 修正 Agent 的压缩行为
初步实验显示，即使在 Prompt 中明确写入 Context 压缩规则，基础模型也极少在达到长度限制前主动调用 compact()。为此，AutoCompact 采用两阶段训练：先通过 Judge 引导的数据收集与监督微调（SFT），让模型学习压缩时机、摘要生成与后续执行；再引入强化学习（RL）进一步优化任务表现。
第一阶段，研究团队让基础模型执行真实软件工程任务，并引入 Judge 检查执行过程。每当模型提出一个动作，Judge 就依据当前可见的执行历史，判断该动作是否合理、是否需要修正。Judge 主要检查三类问题。
一是压缩时机。Agent 已定位 Bug 却仍在重复搜索，Judge 可将当前动作替换为 compact()；问题尚在调查中，则允许继续探索。
二是摘要内容。摘要遗漏目标文件、已确认结论或当前修改进度，Judge 会补充，确保摘要足以支撑后续执行。
三是后续动作。摘要已明确记录下一步要修改的文件，Agent 却重新执行此前完成的搜索，Judge 会修正当前动作，使其与摘要记录的任务状态一致。
整个流程是：模型提出动作，Judge 审核，修正后的动作进入执行环境。修正后的轨迹成为 SFT 数据，共 1,052 条。其中压缩时机占 24%，摘要内容占 53%，后续动作占 23%，最终得到 AutoCompact-SFT。推理阶段不再需要 Judge。
4. 训练数据的真实性问题
这套数据收集流程的关键，在于 Judge 在动作执行前完成检查与修正。当 Agent 应进入代码修改却仍提出搜索时，Judge 会修正该动作，执行环境随后采用修正后的动作。Agent 后续看到的交互历史，也包含实际执行的修正结果。
这样收集到的数据，能反映 Agent 在 Context 压缩后的真实执行过程。相比之下，如果在一条完整轨迹中事后插入压缩动作，后续动作会沿用原始轨迹；即使摘要改变了上下文，也无法反映 Agent 在新上下文下会如何继续。
5. 用任务结果训练 Context 管理
监督微调后，模型开始学会主动调用 compact()，但合理的压缩行为还需要通过最终任务结果验证。作者进一步引入强化学习，让模型根据任务完成情况优化 Context 管理策略。
这一阶段使用 SWE-Gym 软件工程任务训练，采用 GRPO 算法。每个任务采样 8 条执行轨迹，依据最终生成的补丁能否通过测试，给予二元结果奖励。奖励同时作用于 Coding Agent 的代码操作与 Context 管理行为，包括何时调用 compact()、如何生成摘要、压缩后如何继续。
作者没有单独设计衡量摘要质量的奖励函数，而是直接利用最终任务结果，让模型学习不同压缩决策对任务完成的影响。
训练还需处理 Context 重写带来的问题。调用 compact() 后，原交互历史被摘要替换，一条完整轨迹无法再按上下文持续增长的单一序列处理。因此，作者以每次 Context 重写为分界点，将完整轨迹拆成多个片段。片段内部的上下文前缀连续增长，不同片段共享所属轨迹的强化学习优势信号。压缩前的决策、摘要生成与压缩后的执行，都能依据同一次任务的最终结果优化。
6. 实验结果与条件差异
作者在两个基准上评估 AutoCompact：SWE-bench Verified 含 500 个经过验证的软件工程任务；SWE-PolyBench Verified 用于评估跨编程语言代码任务。所有方法均采用相同基础模型与 Agent 执行框架，结果取三次运行的平均值。
完整历史基线在 256K 上下文下的通过率为 30.4% 与 19.5%。固定长度压缩（Fixed Compaction）为 28.8% 与 18.6%，两项均略低于基线。引入强化学习的 CompactionRL 为 32.7% 与 19.8%，有改善但幅度有限。
主动压缩方法中，SelfCompact 为 31.7% 与 20.6%，SWE-Compressor 为 31.0% 与 20.1%，AutoCompact-SFT 为 32.2% 与 21.7%。AutoCompact 经 SFT 转 RL 后达到 39.6% 与 24.5%，相比 SFT 阶段分别提高 7.4 与 2.8 个百分点。
解读这些数字需要留意实验条件差异。Fixed Compaction 与 CompactionRL 使用 16K 的强制压缩阈值，主要的主动压缩方法采用 256K Context。性能差异可能受上下文预算影响，不能全部归因于压缩策略本身。为此作者设计了多组不同推理预算与压缩机制下的对比实验。
7. 有效的主动压缩
一组实验考察主动压缩在 Context 空间充足时是否仍有效。Context 窗口设为 256K，所有轨迹均未达到强制压缩阈值。研究团队设置每任务 0.10 至 4.00 美元共六档推理预算，对比不同模型的通过率。
结果显示，AutoCompact-SFT 在所有预算档位均优于基础模型，强化学习后的 AutoCompact 进一步提高。在另一组 16K 阈值实验中，所有模型使用相同的长度触发兜底压缩机制，AutoCompact 依然在所有预算档位取得更高通过率。
消融实验进一步区分训练收益与压缩执行收益。两组使用同一个训练后的模型，一组正常执行 compact()，另一组忽略压缩调用、保留原交互历史；两组参数完全相同，区别仅在是否真正执行压缩。执行压缩的一组表现更好：每任务 0.10 美元预算下，两组通过率相差 19.9 个百分点；预算提高到 4.00 美元时，差距缩小到 1.9 个百分点。
结论是性能提升既来自训练对执行行为的改善，也来自压缩本身。推理预算有限时，及时清理不再需要的历史，能减轻上下文负担，让 Agent 把更多资源投向当前任务。
8. 压缩行为的量化
除通过率外，论文还统计了压缩行为本身。主动压缩的任务占比，基础模型接近 0%，AutoCompact-SFT 为 44.3%，AutoCompact 达到 58.5%。关键状态遗漏率从 3.1% 降到 0.2%，下一步动作遗漏率从 8.2% 降到 2.2%。训练不仅提升了结果，也让压缩变得更规范。
9. 工程启示
这篇文章对工程实践有三点启示。
其一，把触发条件从静态阈值换成任务状态。长度阈值只看量，不看阶段；任务进度才是决定"何时清理"的有效信号。类似原则也适用于接口治理：与其依据固定阈值，不如依据请求意图与当前状态判断。Treerouter 这类 API 网关采用的就是状态感知的路由与限流，而不是一刀切的静态规则。
其二，让执行层记录真实过程。Judge 在动作执行前修正，再让修正结果进入交互历史，训练数据才反映真实行为。事后补插的做法会失真。
其三，长任务 Agent 会产生大量模型调用，token 用量与预算需要统一计量。推理预算以美元/任务计算时，跨模型、跨任务的用量统计成为必要基础设施。Treerouter 这类 API 网关，恰好能把密钥、限流与按任务、按模型的用量计量集中到一处，让长任务 Agent 在可控成本下运行。
AutoCompact 的意义在于重新定义了压缩的触发逻辑：不是等 Context 满了才动手，而是在任务推进到合适阶段时主动整理。对长任务 Agent 而言，丢掉什么、保留什么、如何继续，比压缩动作本身更值得设计。
