Compact-Bench：衡量上下文压缩给长程编程智能体带来的代价

（说明：本文涉及的模型名、版本号一律沿用论文原文，其中部分是论文使用的匿名或未来代号 —— 例如 GPT-5.6-Luna、GPT-6-Astra —— 不代表本站在描述现实产品。）

1. 问题与价值

这篇论文解决的核心问题是：上下文压缩（context compaction）到底会让长程编码智能体丢掉什么。当一个编码智能体在长任务中积累了大量历史——指令、工具观察、测试结果、部分决策——上下文窗口不够用时，系统必须把历史替换成一段摘要。但摘要可能丢掉「继续完成任务所需的进度状态」，而不只是丢掉可检索的事实。

为什么重要：现有评测要么只看压缩效率（省了多少 token），要么只看信息保留（摘要里还留了多少事实），要么只看端到端成功率。这三类指标都无法隔离「历史替换」这一个动作对任务结果的影响。端到端成功率里，压缩造成的失败可能被其他环节的成功抵消；信息保留率高也不代表智能体拿到摘要后真的能把活干完。

谁受益、怎么受益：部署长程编码智能体的团队（例如用 Claude Code、Kimi Code 这类 agentic harness 做多步仓库修复的开发者）可以直接用这个基准来选 summarizer 和 compaction prompt。论文给出的具体受益方式是：在同一个仓库快照上，把「完整历史续跑」和「仅摘要续跑」配对比较，团队能看到某个 summarizer 是否稳定地把本来能修好的 repair 修坏，而不是只看摘要看起来是否完整。

2. 已有工作的不足

在本文之前，最接近的工作分三类。

第一类是直接评测压缩的方法。COMPINT 评测 side-constraint 的保留，LANTERN 测试归档对话的检索，Slipstream 检查摘要能否支持后续轨迹步骤。这些方法各自抓一个侧面，但没有把「历史替换」和「任务结果变化」直接绑定。

第二类是端到端智能体基准，例如 SWE-bench、OpenHands、AgentBench。它们给出最终通过率，但一个最终分数无法隔离「任务中途替换历史」这个动作的效应。一个 repair 失败可能是因为压缩，也可能是因为智能体本来就不会修。

第三类是 prompt compression 和摘要质量评测，例如 LLMLingua、RECOMP、FEQA、QuestEval。它们衡量压缩后文本的事实一致性或可回答性，但评测目标是「文本质量」，不是「智能体拿到这段文本后能否继续完成一个可执行任务」。

具体哪一步不够：缺少一个共享边界上的配对续跑设计。已有方法要么没有可执行的结果判据，要么没有把「完整历史」和「仅摘要」放在同一个仓库快照、同一个智能体、同一个步数预算下对比。因此无法区分「摘要丢了信息」和「摘要丢了完成任务的进度」。

3. 重建作者的思考路径

如果是我面对第 2 项里的不足，我会先想：要隔离历史替换的效应，最直接的办法是控制变量——同一个任务、同一个仓库状态、同一个智能体，只改变「给完整历史还是给摘要」。这看起来像 A/B 测试。

但马上会撞上一个矛盾：智能体轨迹是随机的。如果 PRE 和 POST 各跑一次，结果不同可能只是采样噪声，不是摘要的错。怎么解决？一个自然的想法是多次运行取稳定结果。但全量多次运行太贵，所以只能对「第一轮出现 damage 或 rescue 的格子」做验证。这里有个分叉：是重跑 PRE 还是只重跑 POST？如果 summarizer 之外的 backbone 不变，PRE 的结果理论上可以复用，只重采样摘要和 POST 即可；但 Kimi-K3 作为 continuation agent 本身也有随机性，所以对它要连 PRE 一起重跑。

接着会撞上第二个矛盾：即使配对续跑能测出「摘要导致任务失败」，它不能告诉我们为什么失败。是摘要丢了目标文件名？丢了关键代码片段？还是丢了「已经做过什么、下一步该做什么」的进度？于是需要第二个轨道：不看任务结果，只看摘要里保留了多少结构化细节。这里又有一个选择：细节的「参考集」怎么定？如果只看摘要里有什么，无法判断什么该留；如果只看压缩前历史里有什么，可能保留了很多后续根本不会再出现的东西。所以合理的参考集是「压缩前历史和未来请求载荷的交集」——即那些在后续交互中真的会再次出现的细节。

再往下推，会发现人工边界和真实生产边界不一样。人工边界可以复用同一条历史，让多个 summarizer 在同一个参考集上打分；但真实系统里的压缩是连续发生的，第二次压缩的输入已经包含第一次的摘要。所以需要第三条轨道：生产链保留，直接记录真实会话里每次压缩后摘要保留了多少未来细节。

到这里，一个关键的分叉出现了：信息保留和任务成功可能不是一回事。我最初的假设会是「保留越多细节，续跑越容易成功」。但数据可能显示 DeepSeek-Flash 细节保留最高却 damage 最多。这时就必须回头检查：摘要里留了目标文件和代码字符串，为什么续跑还是失败？答案可能是摘要丢了「进度」——例如某个修复方案已经被验证过、某个假设已经被排除、某个具体编辑已经定位到某一行。这些不是可提取的结构化值，而是推理状态。

与论文实际路径的差异：我猜的路径是先做配对续跑、再加细节保留、最后加生产链，这和论文的三轨结构基本一致。但论文实际路径中有一个我一开始不会想到的设计：rescue 单独报告。我最初可能只报告 damage rate，把 rescue 混进总成功率里。论文明确把 rescue 和 damage 分开，防止某些 repair 上的改进抵消另一些 repair 上的损失。另一个差异是：我可能不会想到用 anchor_index 这种机械提取器作为参照。论文用确定性提取器从原始历史里抽结构化值，得到 79.1% 的保留率，作为「理论上可恢复的信息上限」，这个对照非常有效地量化了 LLM 摘要的信息损失。

4. 核心 intuition

用一个日常类比：压缩历史就像给接力跑的下一位选手递交接棒笔记。

完整历史相当于把整个训练日志、每一次试跑的视频、每一次教练喊话都交给下一位选手。摘要相当于一张手写便条。便条上可能写着「跑道在第 3 道」「对手穿红鞋」这些可核对的细节，但如果便条没写「你已经试过从外侧超车，失败了；现在应该在第 2 个弯道从内侧切」，下一位选手还是会重复试错，甚至因为不知道某个方案已经被排除而做出错误决策。

这个类比对应到机制上：论文的 Recurring-Detail Retention 测的是便条上有没有写「跑道在第 3 道」这类可提取的字符串；Task Preservation 测的是下一位选手拿到便条后能不能真的跑完。论文的核心发现——摘要保留了目标文件和代码字符串，但续跑仍然失败——正是「便条上有事实，但没有进度」的情形。anchor_index 的 79.1% 说明机械提取能保住大部分「事实」；LLM 摘要只有 16.0%，说明生成式摘要连事实都丢了很多；而即使事实保住了，任务仍可能失败，说明「进度」是另一层更难保留的东西。

5. 方法 pipeline 举例

编一个具体输入：假设有一个 pytest repair 任务（这一步是为示意而虚构的，不对应论文里的任何具体实例），目标文件是 src/_pytest/assertion/rewrite.py，FAIL_TO_PASS 测试是 testing/test_assertrewrite.py::test_assertion_message。

流程如下。

第一步，Phase A 缓存历史。让 continuation agent 在仓库快照 D 上跑最多 10 步，产生历史 H。假设 H 里包含：读文件 rewrite.py 的 3 次调用、跑测试失败的输出、一次 grep 定位到某一行、一次失败的 sed 尝试。把 H 和快照 D 存下来。

第二步，构造摘要。用 Kimi-K3 作为 summarizer，Claude Code prompt 作为压缩指令，对 H 做序列化和截断后生成摘要 S。假设 S 里写了目标文件 rewrite.py，写了 5 个 gold-patch token 中的 5 个，但没写「已经确认问题出在断言改写的那条分支里，另一条候选路径已经排除」。

第三步，配对续跑。PRE 条件：从快照 D 恢复仓库，给 agent 完整历史 H，最多 8 步。POST 条件：从同一个快照 D 恢复仓库，只给摘要 S，同样最多 8 步。两个条件用同一个 agent、同一套工具、同一个测试命令。

第四步，判分。跑 FAIL_TO_PASS 测试。假设 PRE 通过，POST 失败。这个格子标记为 D（damage）。因为这是第一轮 damage，再跑两个 seed。假设三次结果分别是 D、P、D，三次中至少两次 POST 失败，所以标记为 stable damage。

第五步，细节保留打分。在另一个 146 会话的语料上，对同一条历史 H 提取参考集 A_i：从 H 和未来 3 到 8 个请求载荷的交集里，用确定性提取器抽出路径、commit SHA、PR 标识、错误类型、URL、键值对、IP 地址 —— 原文写作 A_i = A(H_i) ∩ A(F_i)，只有「历史里出现过、未来也会再出现」的细节才进参考集；取并集会把只出现在未来的细节也计入分母，改变这个指标的含义。假设 A_i 有 20 个值，摘要 S 里以大小写敏感子串方式匹配到 3 个，则该会话 retention 为 3/20 = 15%。对所有会话取未加权平均，得到该配置的 Recurring-Detail Retention 分数。

6. 核心数学推导

论文的核心公式是 Recurring-Detail Retention 的会话级分数。

先解释符号。H_i 是第 i 个会话在人工压缩边界前的历史文本。F_i 是该边界后接下来 3 到 8 个请求载荷的拼接文本，包含重传的历史。A(T) 是一个确定性提取器，输入任意文本 T，输出 T 中所有不同 (type, value) 对的集合，类型包括路径、commit SHA、PR 或 issue 标识、错误类型、URL、键值对、IP 地址。S_i 是被测摘要。

第一步，定义参考集 A_i。它是「压缩前历史里出现」且「未来载荷里也出现」的细节集合，即两个集合的交集：

A_i = A(H_i) ∩ A(F_i)

这个交集的含义是：只把那些在后续交互中真的会再次出现的细节算作「该保留的」。如果某个细节只在历史里出现、未来不再出现，它不进参考集，因为丢了它不影响后续。

第二步，定义匹配规则。一个参考对 (type, value) 匹配成功，当且仅当它的字面值 value 作为大小写敏感的子串出现在摘要 S_i 中。匹配不要求 token 边界，也不要求摘要里用同样的类型标签。用符号写：

matching pairs in A_i 表示 A_i 中满足「value 是 S_i 的子串」的元素个数。

第三步，定义会话级分数。用匹配数除以参考集大小：

retention_i = matching pairs in A_i / ∣A_i∣

其中 ∣A_i∣ 是集合 A_i 的元素个数。构造数据时要求每个会话至少 3 个参考细节，所以分母不为零。

第四步，聚合。对每个方法，报告所有会话 retention_i 的未加权平均。未加权意味着一个有很多细节的会话不会主导整体均值。

这个公式在算什么：它在算「摘要里以字面形式保留了多少个后续还会用到的结构化细节」。它不衡量语义等价，只衡量字面保留，因此是一个下界——语义保留但字面不同的细节会被算作丢失。论文用这个保守定义来保证评分的确定性。

Production-Chain Retention 的公式结构相同，但参考集不同：

R_i,k = matching detail pairs in A_i,k / ∣A_i,k∣

其中 A_i,k = A(F_i,k)，即第 i 个会话第 k 次压缩边界后最多 5 个请求载荷的提取细节集合。这里不要求与压缩前历史取交集，因为生产边界上「未来会用到什么」本身就是参考。

7. 实验设计

数据集分三块。Task Preservation 用 35 个本地化的 SWE-bench repair，来自 7 个仓库：pytest 18 个、sympy 6 个、xarray 3 个、pylint 3 个、requests 2 个、sphinx 2 个、flask 1 个。Recurring-Detail Retention 用 146 个会话，其中 143 个真实、3 个模拟器合成，客户端分布是 Kimi Code 73、Claude Code 50、opencode 14、其他 9，共 9,330 个 recurring details。Production-Chain Retention 用 106 个会话，224 个生产压缩边界，中位数每会话 2 个边界、最大 4 个。

注意这里的两个分母别混：106 个会话共 224 个压缩边界，按位置是第一 106、第二 106、第三 10、第四 2 个；其中只有 140 个边界（106/27/6/1）至少含一个可评估的未来细节，也就只有这些进入评分。所以第 8 项里出现的 n 一律是可评估边界数，不是会话数。

基线。Task Preservation 的 backbone 比较固定 Claude Code prompt 和 Kimi-K3 continuation agent，变化 14 个 summarizer backbone：Claude Opus 4.8、Kimi-K3、GPT-5.6-Luna、GPT-5.6-Sol、Claude Fable 5、Claude Fable 5.1、GPT-6-Astra、Qwen3.8-Max、GPT-5.6-Terra、Claude Opus 5.5、GLM-5.3、DeepSeek-V4-Pro、Hy4-Preview、DeepSeek-Flash。prompt 比较固定 Kimi-K3 为 summarizer，变化 5 个生产 prompt：Claude Code、Codex、Gemini CLI、opencode、Kimi Code。Recurring-Detail Retention 的机械基线是 anchor_index，一个确定性提取器，从历史前 400,000 字符里每类最多保留 40 个值。

指标。Task Preservation 的 damage rate 是「PRE 通过但 POST 失败」的实例数除以 22 个验证过的 PRE-pass 实例数；preservation rate 是 1 减 damage rate。stable damage 要求三次运行中至少两次 POST 失败。Recurring-Detail Retention 是上述会话级保留率的未加权平均。Production-Chain Retention 按边界位置分别报告平均保留率。

消融。论文没有传统意义上的模块消融，但有三个维度的对照：backbone 对照（固定 prompt）、prompt 对照（固定 backbone）、机械提取对照（anchor_index 对比 LLM 摘要）。另外有三轮验证实验：解释器对齐（v1 系统解释器、v2 实例解释器但分离目录、v3 实例解释器加共享目录和快照恢复），显示 v3 修复了路径泄漏问题。

实验能否支撑结论：配对续跑设计能支撑「历史替换导致任务结果变化」的因果推断，因为 PRE 和 POST 共享同一个快照、同一个 agent、同一个预算。稳定 damage 的三轮验证支撑「damage 不是纯噪声」。细节保留和任务保留的分离支撑「信息保留不等于任务成功」这个核心主张。

缺什么。第一，22 个 PRE-pass 实例的样本量小，Wilson 置信区间很宽，例如 Claude Opus 4.8 的 5% 对应 1/22，区间是 1% 到 22%。第二，生产链第三、第四边界的样本量急剧缩小（n=6 和 n=1），这些数字几乎不能做统计推断。第三，所有结果都条件于 Kimi-K3 作为 continuation agent 和 8 步预算，换一个 agent 或预算可能改变排序。第四，细节保留只测字面子串匹配，不测语义等价，可能系统性低估 LLM 摘要的保留能力。

8. take-aways

1. 在 22 个验证过的 PRE-pass repair 上，14 个 summarizer backbone 的 stable damage rate 从 5% 到 64% 不等，跨度 59 个百分点；Claude Opus 4.8 只 damage 1 个，DeepSeek-Flash damage 14 个。

1. 信息保留和任务成功不是一回事：DeepSeek-Flash 在 Claude Code prompt 下 Recurring-Detail Retention 最高，为 16.0%，但它 damage 了 22 个 repair 中的 14 个；Kimi-K3 保留率 15.0%，只 damage 4 个。

1. LLM 摘要的字面细节保留远低于机械提取：最好的 LLM 摘要保留 16.0%，而 anchor_index 机械提取保留 79.1%，差距 63.1 个百分点。

1. 摘要可以保留目标文件和关键代码字符串却仍然导致续跑失败：在 4 个稳定 damage 的 Kimi-K3 案例中，目标文件全部出现在摘要里，pytest-7571 的 5 个 gold-patch token 全部保留，但 POST 仍然失败。

1. 生产环境里，摘要保留率总体随压缩次数衰减，但不是单调的：第一边界 15.7%，第二边界反而略升到 19.9%，之后第三边界 4.9%、第四边界 1.8% 才算真正塌下去。后两个位置的样本很小，只能当趋势看（各位置的样本口径见第 7 项）。

9. 最脆弱的假设

最脆弱的假设是：「PRE 通过」的 repair 集合能代表「摘要应该保留的进度」的完整范围。整个 Task Preservation 的 damage rate 都条件于这 22 个 PRE-pass 实例。如果这 22 个 repair 恰好是某种特定类型——例如都是单文件、少测试、短 gold patch 的简单修复——那么「5% 到 64% 的 damage」这个结论就不能推广到更复杂的修复任务。论文自己给出的选择标准是「修复局限在一个测试文件、FAIL_TO_PASS 测试少、gold patch 中位数小于 1 KB」，这明确说明样本偏向简单、局部化的修复。对于需要跨多个文件协调、长 gold patch、大量测试的 repair，摘要丢失进度的方式可能完全不同，damage rate 可能更高，也可能出现新的失败模式。

论文没有直接检验这个假设的成立范围。它没有报告「复杂 repair 上 damage 是否更高」的对比，也没有说明这 35 个实例在原始 SWE-bench 难度分布中的位置。附录 E 只给了实例清单和环境配方，没有难度分层分析。如果这个假设不成立，论文的核心数字仍然有效，但「可靠压缩需要保留完成任务所需的进度」这个一般性结论的强度会被削弱——它可能只在简单修复上成立。

10. 一周最小复现

只有 1 张 24GB 消费级显卡和 1 周，最核心的结论是「摘要保留细节不等于任务成功」。复现这个不需要跑全部 14 个 backbone 和 35 个实例。

具体步骤。第一天，选 3 个本地化的 SWE-bench 实例，优先选论文里行为最清晰的：pytest-7571（5/5 token 保留仍失败）、sphinx-9230（所有 prompt 都失败）、pytest-10081（13/14 backbone 失败）。搭好环境：Python 3.9 venv，pytest 仓库用 setuptools_scm shim，sphinx 用 era-pinned 依赖。用一张 24GB 卡本地跑一个开源 7B 到 14B 模型作为 continuation agent，例如 Qwen2.5-Coder-14B 或更小的 7B 版本，通过 vLLM 或 llama.cpp 部署。

第二天到第三天，实现配对续跑的最小版本。Phase A 用本地 agent 跑最多 10 步，缓存历史和仓库快照。PRE 给完整历史续跑 8 步，POST 给摘要续跑 8 步。摘要用一个本地可跑的 summarizer，或者直接调一个便宜的 API summarizer（如果允许 API）。每个实例每个条件跑 3 个 seed。预期在 pytest-7571 上看到：PRE 至少 2/3 通过，POST 至少 2/3 失败，且摘要里能找到目标文件名。

第四天到第五天，做细节保留的最小对照。写一个简化版确定性提取器，只抽路径和错误类型两类。对每个实例的历史和未来载荷取交集，得到参考集。计算机械提取的保留率（应该明显高于 LLM 摘要），再算 LLM 摘要的保留率。预期看到机械提取超过 50%，LLM 摘要低于 20%。

第六天到第七天，检查失败轨迹。对比 PRE 和 POST 的 action trace，确认 POST 是否像论文说的那样「读到了目标文件但没有做出修复」。记录 PRE 和 POST 的 read_file 和 run_command 调用序列。

预期指标：在 3 个实例上，至少 1 个实例出现 stable damage（3 次中至少 2 次 POST 失败而 PRE 通过）；该实例的摘要里目标文件可检出；机械提取保留率至少是 LLM 摘要的 2 倍。如果这三点都成立，就复现了论文的核心机制。数据规模是 3 实例 × 2 条件 × 3 seed = 18 次续跑，加上 Phase A 的 3 次，总共约 21 次 agent 运行，一周内可完成。

11. 反例设计

要推翻本文的核心主张——「可靠压缩需要保留完成任务所需的进度，而保留相关信息本身不足以保证成功续跑」——可以设计这样一个实验。

判据：如果存在一种摘要方法，它的 Recurring-Detail Retention 显著低于 anchor_index 的 79.1%，但在 Task Preservation 上的 damage rate 不高于最好的 backbone（即不超过 5%，对应 22 个中 damage 不超过 1 个），那么「细节保留和任务成功是两回事」这个主张就被削弱。更强的反例是：如果一种摘要方法在细节保留率接近 0% 的情况下，damage rate 仍然很低，那就直接推翻「保留信息是成功续跑的必要条件」。

实验设计。取论文的 22 个验证过的 PRE-pass 实例，用同一个 Kimi-K3 continuation agent 和同一个 Claude Code prompt。构造一种「极简摘要」：只输出一行「继续完成 FAIL_TO_PASS 测试对应的修复」，不包含任何目标文件路径、代码字符串、错误类型。这相当于一个空摘要。在 22 个实例上跑 POST 续跑，每个跑 3 个 seed。同时对这个极简摘要计算 Recurring-Detail Retention，预期接近 0%。

如果结果显示：极简摘要的 damage rate 与 Claude Opus 4.8 的 5% 无显著差异（例如 22 个中 damage 0 到 2 个），那么论文的核心主张就被推翻——因为这说明 continuation agent 主要靠仓库快照和测试反馈就能完成任务，历史摘要里保留什么细节根本不重要。如果结果显示 damage rate 显著高于 5%（例如超过 50%），则论文的主张得到支持。

这个实验的关键控制是：仓库快照 D 必须和论文完全一致，因为如果快照里已经包含了足够的状态（例如未提交的编辑、测试缓存），那么摘要内容自然不重要。论文的配对设计正是为了排除这个混淆，所以反例实验必须严格复用其快照恢复流程。

12. 落地判断

用于「抢占式 GPU 自托管 27B 模型做多智能体脚手架」这个场景，这篇论文的结论可以直接用，但有一个重要前提需要注意。

怎么用。第一，把 compaction 从「默认开启」改成「显式评测后再决定」。在自托管 27B 模型上，先跑一个小规模的配对续跑：选 5 到 10 个你们自己任务分布里的代表性 repair，用 27B 模型同时作为 continuation agent 和 summarizer，对比完整历史和摘要续跑。如果 damage rate 超过 20%，就不要用 LLM 摘要，改用机械提取或结构化状态保存。第二，用 anchor_index 式的确定性提取器作为兜底。论文显示机械提取能保留 79.1% 的 recurring details，远高于 LLM 摘要的 16.0%。在自托管场景里，可以先用规则抽路径、commit SHA、错误类型、键值对，把这些作为摘要的骨架，再让 27B 模型只补充「进度」部分。第三，监控生产链的连续压缩。论文显示第一边界保留 15.7%，第三边界掉到 4.9%。如果你们的 agent 会话经常超过 2 次压缩，要预期信息会快速衰减，应该在第 2 次压缩后强制做一次外部状态检查点，而不是继续依赖摘要链。

成本量级。论文的完整 35-repair 研究用了约 8,000 次模型调用，压缩只占不到 5% 的 token。在自托管 27B 上，单次续跑 8 步、每步最多 4,096 token 输出，粗算一次续跑约 3 万到 5 万 token 的生成量。如果做 10 个实例 × 2 条件 × 3 seed = 60 次续跑，总生成量约 200 万到 300 万 token。在单张 24GB 卡上，27B 模型用 4-bit 量化，生成速度约 20 到 40 token/秒，60 次续跑大约需要 15 到 40 小时。这是可承受的一次性评测成本。

最大的坑。论文里 Task Preservation 那一组结论条件于「continuation agent 是 Kimi-K3」和「8 步预算」；另两条 retention（Recurring-Detail、Production-Chain）只做文本抽取与字符串匹配、不跑 continuation，因此不受这两个条件约束。但凡是涉及「修不修得好」的数字，都带着这两个条件。你们的 27B 自托管模型能力远弱于 Kimi-K3，damage rate 可能系统性更高，而且失败模式可能不同——小模型可能不是因为「丢了进度」而失败，而是因为「摘要本身写得太差」或「续跑时根本不会利用摘要」。所以不能直接把论文的 5% 到 64% 数字搬到 27B 场景，必须重新跑配对评测。另一个坑是抢占式 GPU 的不可预期中断：论文的配对设计依赖「PRE 和 POST 从同一个快照恢复」，如果 GPU 在 Phase A 和 POST 之间被抢占，快照恢复逻辑必须能处理不完整的轨迹，否则会引入论文里 v2 那种「路径泄漏」式的混淆。