跳过压缩器：编码智能体整文件选取可修复更多问题

1. 问题与价值

这篇论文解决的核心问题是：在固定 token 预算下，编码智能体应该把上下文预算花在“选哪些文件”上，还是花在“压缩 token”或“检索相关代码块”上？

问题的重要性来自一个现实矛盾：现代编码智能体要处理的仓库远大于其上下文窗口。论文给出的数据是 SWE-bench 代码库平均有 3,010 个非测试文件和 438K 行代码，而模型的上下文窗口远小于此。因此，任何实际部署的编码智能体都必须对仓库做某种形式的“压缩视图”。

作者指出，修复一个 issue 需要同时满足两个条件：一是上下文里必须包含需要修改的文件，二是这些文件的文本必须逐字准确，因为模型生成的补丁必须引用它编辑的代码行。检索器和压缩器各自只满足其中一个条件：检索器保留原文但常常选错文件，压缩器保留正确文件但篡改了文本。

受益者是所有构建编码智能体的人。如果结论成立，他们可以省掉压缩模型和检索模型的训练、推理成本，用更简单的“选文件 + 逐字展示”策略获得更高的问题解决率。论文给出的具体收益是：CQ2-CARE 用 GPT-5.6 解决 43.7% 的问题，用 Claude Opus 5 解决 46.7%，分别比最好的压缩器高 6.3 个百分点，比最好的检索器高 9.3 和 12.7 个百分点。

2. 已有工作的不足

在本文之前，处理“仓库大于上下文窗口”问题有三条路线，每条都有具体缺陷：

提示压缩器：代表方法是 LLMLingua-2（Pan et al., 2024）、LongLLMLingua（Jiang et al., 2024）和 LongCodeZip（Shi et al., 2025）。它们用小模型给 token、行或代码块打分，删除“最不有用”的部分。问题在于：压缩器删除 token 时不知道哪些 token 是补丁必须逐字引用的。论文的图 1 给出了一个具体例子：LLMLingua-2 删掉了 f-string 的 f 前缀和引号，导致模型生成的补丁引用了一行在真实文件中不存在的代码，补丁无法应用。论文的量化结果是 LLMLingua-2 只保留了 17.5% 的逐字行，补丁应用率只有 70.7%，而 CQ2-CARE 是 98.0%。

检索器：代表方法是 BM25 分块检索（Robertson and Zaragoza, 2009）、稠密检索（CodeRankEmbed, Suresh et al., 2025）和 SWE-bench 自带的文件级 BM25（Jimenez et al., 2024）。它们按“与 issue 文本的相似度”排序代码单元。问题在于：issue 报告中的措辞常常与测试文件、文档、issue 模板相似，而不是与需要修改的源文件相似。论文表 2 显示，分块 BM25 和稠密检索把上下文中五分之一或更少的行放在需要修改的文件里，在超过四分之一的问题上完全没有展示任何需要修改的文件。

面向 issue 解决的训练方法：SWE-Pruner（Wang et al., 2026）是训练过的行剪枝器，SweRank（Reddy et al., 2026）是训练过的函数检索器。它们比通用方法好，但 SWE-Pruner 仍然在文件内部留下空隙导致补丁应用率下降（GPT-5.6 下 93.0% 对 CQ2-CARE 的 98.0%），SweRank 虽然展示逐字函数，但只覆盖了 39% 的问题中金补丁修改的每一行，而 CQ2-CARE 是 70%。

关键空白：此前没有工作在逐问题匹配的预算下，让每种方法自由决定哪些文件进入上下文，然后用基准测试的测试用例端到端地比较检索、token 剪枝和文件选择。

3. 重建作者的思考路径

如果我是作者，面对第 2 项里的不足，我的思考过程大概是这样的：

第一步：先问“补丁到底需要什么”。 一个编码智能体生成的 unified diff 里，每一行被删除的代码必须和仓库里的真实行完全一致，否则 git apply 会失败。这意味着上下文中被编辑的文件必须逐字出现。这个观察很直接，但它的推论不直接：如果逐字是硬约束，那么任何删除 token 的操作都有风险，除非删除的是与编辑无关的部分。但压缩器不知道哪些 token 与编辑有关——这正是它要压缩的原因。

第二步：撞上第一个矛盾。 如果逐字是硬约束，那检索器应该更好，因为检索器保留原文。但检索器的问题是排序依据：BM25 和稠密检索按“与 issue 的相似度”排序，而 issue 的语言和代码的语言是两种语言。一个报告“f-string 缺少 f”的 issue，其词汇和 issue 模板里的“f-string”高度重合，但真正要改的文件里可能根本没有“f-string”这个词。所以检索器会系统性地把预算填满“回声文本”。这个矛盾让我意识到：排序信号错了。需要的不是“哪些代码和 issue 相似”，而是“哪些文件必须改变”。

第三步：怎么知道哪些文件必须改变？ 最直接的办法是让模型自己说。模型读了 issue 和路径清单后，可以输出“哪些文件必须改”。但单次回答不可靠——模型可能漏掉文件，也可能乱说。一个自然的想法是采样多次，取交集。这来自 self-consistency 的思路（Wang et al., 2023）：两次独立采样都提到的文件更可能是真的。但这里有个陷阱：取交集会减少文件数量，而减少文件数量本身就会提高精确率。所以“一致性”到底是在利用可靠性信号，还是只是变相地“选更少的文件”？这个疑问后来被论文自己的消融实验证实了：单次采样截断到同样文件数，解决率差不多。

第四步：选对了文件还不够。 假设模型选对了要改的文件，但修复常常依赖其他文件里的定义、调用者或字符串。如果只展示选中的文件，模型可能不知道某个函数在哪里定义、谁调用了它。所以需要一种机制让模型主动请求额外的代码片段。这引出了 evidence step：模型在读完选中文件后，可以提出最多四个类型化搜索请求（比如“找这个函数的定义”“找它的调用者”），用 grep 在仓库里定位，把匹配位置的包围定义或窗口作为证据加入上下文。

第五步：预算怎么定？ 如果每种方法都在不同预算下比较，结果没有意义。所以需要先跑 CQ2-CARE，得到它在这个 issue 上的实际 token 数 B_i，然后让所有基线方法都拟合到这个预算。这带来一个微妙的问题：CQ2-CARE 的预算不是预先设定的，而是它自己“自然”产生的。这意味着比较发生在 CQ2-CARE 的操作点上。作者在限制里也承认了这一点，并用 100 个 issue 的速率扫描覆盖了其他预算点。

第六步：怎么证明“两种失败模式各自独立造成损失”？ 主比较是观察性的：压缩器既改了文件选择又改了文本。要分离因果，需要控制实验。一个实验是：拿 CQ2-CARE 自己的上下文，只删除每行 20% 的 token，文件不变，看解决率掉多少。另一个实验是：拿 CQ2-CARE 的候选文件，让压缩器只在这些文件上压缩，看解决率是否恢复。如果第二个实验里压缩器追平了 CQ2-CARE，就说明 CQ2-CARE 的优势主要来自文件选择，而不是“不压缩”本身。

与论文实际路径的差异：我猜的路径和论文实际走的路径在大方向上一致，但有一个重要差异。我最初以为“一致性采样”是方法的核心创新，但论文自己在 4.4 节里拆掉了这个假设：单次采样截断到同样文件数，解决率差不多。论文把真正的核心定位为“选择单元是整文件，而不是 token 或 chunk”。另一个差异是：我没有预料到论文会引入一个基于金补丁的离线估计器来分解每个方法的失败原因。这个估计器用金补丁的“已修改行”覆盖率 κ 和“token 保留率” q 来预测解决率，并声称对留出的主上下文有 11/11 的区间覆盖率。这是一个相当重的诊断工具，我一开始不会想到要构建它。

4. 核心 intuition

类比：外科手术的器械盘。 一个外科医生要做一台手术，他面前有一个器械盘。手术需要的是正确的几件器械，而且这些器械必须是真实可用的——不能是器械的照片，不能是“差不多形状”的替代品，因为医生要用它们做精确操作。

检索器像一个按“和病历文字的相似度”来装器械盘的助手：病历里写了“用刀切开”，他就往盘子里放了一堆和“刀”字面相关的说明书、包装盒、甚至其他手术的记录，但真正要用的那把手术刀没放进去。

压缩器像另一个助手，他确实知道要放哪些器械，但为了节省空间，他把手术刀的刀柄锯短了一截，把剪刀的螺丝拧松了。医生看到的是“一把刀”，但当他试图用这把刀时，发现它和真实器械不匹配，操作失败。

CQ2-CARE 的做法是：先问医生两次“你需要哪些器械”，取两次都说要的；然后让医生补充“我还需要看看这个器械的说明书或者谁用过它”，再把这些补充材料放进去。关键是：放进去的每一件器械都是完整的、真实的。这个类比对应到机制上：补丁生成必须逐字引用代码行，任何 token 删除都可能破坏引用；而文件选择错误则直接导致模型看不到要改的代码。两个失败模式分别对应“器械不完整”和“器械放错了”。

5. 方法 pipeline 举例

我构造一个具体输入，走一遍 CQ2-CARE 的完整流程。

输入：一个 issue 报告“dvc add 命令在某些情况下生成的 .dvc 文件里路径使用了反斜杠，应该用正斜杠”。仓库是 DVC，假设有 500 个 Python 文件。模型是 GPT-5.6。

第一步：路径清单。 系统提取仓库所有路径 P，用词重叠度对 issue 文本排序，取前 τ = min(∣P∣, 32K) token 的路径，按字母序排列。假设 dvc/repo/add.py、dvc/repo/diff.py、dvc/output.py 等路径和 issue 共享词“dvc”“add”“path”，进入清单。模型只看到这个路径清单，看不到文件内容。

第二步：定位采样。 模型被问三次“哪些文件必须改变？”，返回三个独立排序的列表 L0、L1、L2。假设 L1 = [dvc/repo/add.py, dvc/output.py, dvc/repo/diff.py]，L2 = [dvc/repo/add.py, dvc/utils/fs.py, dvc/output.py]。取 L1 ∩ L2，排除测试路径和文档路径，得到 F = {dvc/repo/add.py, dvc/output.py}。按两个列表中排名倒数之和排序，dvc/repo/add.py 排第一。

第三步：规划搜索。 模型读 issue 和 F 的内容，输出最多四个类型化搜索请求。假设它请求：dvc/repo/add.py 中调用的 save 函数的定义、dvc/output.py 中 Output 类的调用者。系统用 git grep 在仓库中搜索，对每个搜索取最多两个尚未展示的文件，加入证据 E。假设 save 的定义在 dvc/repo/save.py，Output 的调用者在 dvc/stage.py，则 E 包含这两个文件中匹配位置的包围定义或窗口。

第四步：组装上下文。 把 F 中的文件全文逐字加入，每个文件前加头部 --- SOURCE k: path lines a-b ---。然后把 E 中的证据片段加入，每个片段截断到 12K token。如果某个文件超过 60K token，只取前 60K。如果总上下文超过 80K token，跳过后续块。假设最终上下文 m 包含 dvc/repo/add.py 全文（约 3K token）、dvc/output.py 全文（约 2K token）、dvc/repo/save.py 的一个函数定义（约 500 token）、dvc/stage.py 的一个调用点窗口（约 400 token），总计约 5.9K token（估算：3K+2K+500+400=5.9K，各块 token 数为举例假设）。这个 5.9K 就是本 issue 的预算 B_i。

第五步：生成补丁。 模型读 issue 和 m，输出 unified diff。假设它正确地把 dvc/repo/add.py 里的 path.replace("\\", "/") 改为 path.replace("\\\\", "/") 或类似修复。补丁被 SWE-rebench 的测试用例验证。

中间结果总结：定位 F1 在这个例子里是 1.0（两个文件都在金补丁里），逐字行比例 ε = 100%，金文件召回 ρ = 100%。如果金补丁还改了第三个文件 dvc/repo/diff.py，那 ρ = 2/3 ≈ 66.7%。

6. 核心数学推导

论文的核心形式化是把上下文构建定义为三种操作，并用两个量来刻画上下文质量。这里推导这两个量的定义和它们在回归中的作用。

符号定义：设仓库 R 在 issue 的 base commit 上，issue 文本为 q，token 预算为 B。上下文步骤 C 把 (q, R) 映射为上下文 m = (s_1, ..., s_K)，其中每个 s_k 是文件 f_k 的第 a_k 到 b_k 行的逐字片段，记为 f[a:b]。模型 π 读 (q, m) 生成补丁 p，y ∈ {0,1} 表示 issue 是否被解决。

金文件召回率 ρ：设 F* 是金补丁修改的、在 base commit 中已存在的文件集合。上下文 m 中出现的文件集合是 {f_1, ..., f_K}。则

ρ(m) = ∣F* ∩ {f_1, ..., f_K}∣ / ∣F*∣

这个公式在算什么：它衡量上下文中“覆盖了多少必须修改的文件”。如果金补丁改了 3 个文件，上下文展示了其中 2 个，ρ = 2/3。ρ 使用金补丁，所以只能离线计算，不能给模型看。

逐字行比例 ε：设 m 中所有非空行构成集合，每一行 ℓ 来自某个文件 f(ℓ)（由头部声明）。如果 ℓ 去掉尾部空白后等于 f(ℓ) 中的某一行，则 ℓ 是逐字的。则

ε(m) = ∣{ℓ ∈ m : ℓ 是逐字的}∣ / ∣{ℓ ∈ m}∣

这个公式在算什么：它衡量上下文中“有多少行是仓库里的原文”。检索器天然有 ε = 1，因为它们是逐字打包的；token 压缩器会降低 ε，因为删除 token 后行不再匹配原文；CQ2-CARE 除了被 60K 截断的文件外，ε ≥ 0.996。

三种上下文构建的公式：分块检索按相似度排序单元 u(j)，取前 r 个完整单元加上第 r+1 个单元的最长整行前缀，得到 m_ret = (u(1), ..., u(r), ū(r+1))。token 剪枝从一个更大的候选上下文 m̃ 中删除方法自己的规则 D_r(m̃) 判定的低分单元，得到 m_prune = m̃ \ D_r(m̃)。精确文件选择预测必须修改的文件集 F，展示它们全文，加上证据片段 E，得到 m_sel = (f[1:∣f∣])_{f∈F} ⊕ E。

回归模型：附录 H 里，作者用逻辑回归预测解决率。设 κ(m) 是金补丁修改行中被上下文展示的比例，q(m) 是已展示修改行的 token 保留率。回归形式是

logit(P(y=1)) = β_0 + β_1·y_∅ + β_2·y_* + β_3·ρ + β_4·ε + β_5·κ + β_6·q + β_7·(log∣m∣ - μ)

其中 y_∅ 和 y_* 分别是无源上下文和金文件上下文是否解决该 issue 的指示变量。论文表 10 给出的系数（GPT-5.6）是：ρ 的系数 0.19，ε 的系数 0.81，κ 的系数 1.86，q 的系数 0.88。这个公式在算什么：它把解决率分解为“文件选对了吗”（ρ）、“行展示对了吗”（κ）、“文本逐字吗”（ε 和 q）以及“issue 本身难不难”（y_∅ 和 y_*）的贡献。系数符号和大小说明：κ 的贡献最大，ε 次之，ρ 在控制 κ 后贡献较小——这支持了论文的核心主张：展示正确的行、逐字展示，比单纯展示正确的文件更重要。

7. 实验设计

数据集：SWE-rebench 排行榜（Badertdinov et al., 2025），860 个 Python 任务、413 个仓库。作者用加盐哈希抽了 340 个候选 issue，每个仓库一个，经过资格检查（金补丁能解决、空补丁不能解决）后剩 328 个，取前 300 个作为实验总体。issue 创建时间在 2025 年 1 月到 2026 年 5 月之间。选择 SWE-rebench 而不是 SWE-bench Verified 的理由是后者可能存在记忆化问题。

基线：三组。压缩器组：LLMLingua-2、LongLLMLingua（用 Qwen2.5-7B-Instruct 做打分器）、LongCodeZip（用 Qwen2.5-Coder-7B-Instruct）。检索器组：分块 BM25、稠密检索（CodeRankEmbed）、文件级 BM25（SWE-bench 官方基线）。训练方法组：SWE-Pruner（行剪枝器）、SweRank（函数检索器）。上界是金文件 oracle（直接展示金补丁修改的文件），下界是无源上下文（只给 issue）。

指标：解决率（金测试的 FAIL_TO_PASS 和 PASS_TO_PASS 全部通过）、补丁应用率、金文件召回率 ρ、逐字行比例 ε、平均上下文 token 数。统计检验是单侧精确 McNemar 检验，Holm 校正，95% issue-bootstrap 置信区间。

消融：CQ2-CARE 的消融包括：去掉 evidence step（解决率降 3.0 个百分点，p=0.068，不显著）、单次采样截断到同样文件数（解决率约等于 CQ2-CARE）、两次采样的并集（解决率高 4.0 个百分点但多 2.3K token）、t-of-5 一致性阈值扫描。

控制实验：两个。一是“只改文本”：拿 CQ2-CARE 自己的上下文，删除每行 20% 的 token，解决率从 43.7% 降到 34.0%，降 9.7 个百分点。二是“只改文件选择”：让压缩器压缩 CQ2-CARE 的候选文件而不是单次采样的更大上下文，LongCodeZip 追平 CQ2-CARE（44.7% 对 43.7%），LLMLingua-2 选整行时差距缩到 3.0 个百分点。

实验能否支撑结论：主比较是预算匹配的、端到端测试评分的，这比只报定位 F1 或退出码要强得多。控制实验把两个失败模式分开，是论文最有说服力的部分。但有几个缺口：一是每个上下文只有一个补丁样本，论文自己承认第二次采样会翻转 8.7% 到 18.9% 的结果，所以小差距（如 Claude 下 CQ2-CARE 对 LLMLingua-2 的 6.3 个百分点，p=0.027）很脆弱。二是预算 B_i 是 CQ2-CARE 自己的操作点，虽然 100-issue 速率扫描覆盖了其他预算，但主比较仍然偏向 CQ2-CARE 的自然预算。三是文件级 BM25、SWE-Pruner 和 SweRank 是主结果之后加的；其中 SWE-Pruner 并入压缩器家族、SweRank 并入预定检索器家族，各自做了 Holm 校正，真正没做校正的只有文件级 BM25（原文：as was file-level BM25, whose tests are unadjusted）。

8. take-aways

• 在匹配预算下，选整文件逐字展示比压缩 token 或检索 chunk 解决更多 issue：CQ2-CARE 用 GPT-5.6 解决 43.7%，比最好的压缩器 LongCodeZip 高 6.3 个百分点，比最好的检索器 SweRank 高 0.7 个百分点；用 Claude Opus 5 解决 46.7%，比 LongCodeZip 高 10.7 个百分点，比 SweRank 高 1.7 个百分点。

• 检索器的失败模式是“看不到要改的文件”：分块 BM25 和稠密检索在超过 26% 的问题上完全没有展示任何金补丁文件，它们上下文中只有约五分之一的行来自要改的文件，而 CQ2-CARE 是 51.7%。

• 压缩器的失败模式是“改了文本导致补丁无法应用”：LLMLingua-2 只保留 17.5% 的逐字行，补丁应用率 70.7%；CQ2-CARE 保留 100% 逐字行，应用率 98.0%。在 CQ2-CARE 解决而 LLMLingua-2 未解决的 48 个 issue 中，28 个是因为补丁无法应用。

• 文件选择的质量比“一致性采样”本身更重要：两次采样取交集把定位 F1 从单次采样的 0.430 提到 0.613，但单次采样截断到同样文件数达到 0.600 的 F1 和约等于 CQ2-CARE 的解决率。所以“选少而准的文件”是核心，“采样一致性”只是实现手段。

• 如果文件已经选对，逐行压缩可以追平：LongCodeZip 在 CQ2-CARE 的候选文件上压缩到同样预算，解决率 44.7% 对 CQ2-CARE 的 43.7%，差距 +1.0 个百分点且不显著。这意味着“先选对文件，再整行压缩”是一个可行的替代方案，但 LongCodeZip 为此花了 6.8 GPU 小时处理 300 个 issue。

9. 最脆弱的假设

最脆弱的假设是：单次补丁采样足以代表一个上下文方法的真实解决率。

论文的每个上下文只生成一个补丁，所有解决率都是这个单次采样的结果。论文自己在 Limitations 里承认：“大多数单元格只有一个补丁样本，第二次采样会翻转 8.7% 到 18.9% 的结果，所以小差距如 Claude 下对 LLMLingua-2 的 p=0.027 是脆弱的。”

这个假设一倒，论文中所有差距小于约 10 个百分点的结论都会变得不可靠。具体来说：CQ2-CARE 对 SweRank 的领先（0.7 和 1.7 个百分点）在单次采样下完全不显著，论文也承认“SweRank 的小差距不能说明性能相等”。CQ2-CARE 对 SWE-Pruner 的领先在 GPT-5.6 下是 2.0 个百分点（p=0.209，不显著），在 Claude 下是 7.3 个百分点（p=0.0154，弱显著）。如果补丁采样噪声的标准差是 8.7% 到 18.9% 的翻转率对应的量级，那么 2.0 个百分点的差距完全可能在重复实验中消失甚至反转。

论文给出的证据：它跑了第二次补丁采样，发现 CQ2-CARE 的解决率在两次采样间移动了 0.0 个百分点，LongCodeZip 和 LLMLingua-2 移动了最多 2.0 个百分点。但这只覆盖了三个方法，且第二次采样本身也只有一次。论文没有对所有 300 个 issue 的所有方法跑多次采样并报告方差。所以这个假设目前只有很弱的证据支持，而它恰恰是所有小差距结论的地基。

10. 一周最小复现

目标：复现论文最核心的结论——在匹配预算下，CQ2-CARE 的解决率高于分块 BM25 和 LLMLingua-2，且差距主要来自补丁应用率和金文件召回率。

硬件约束：1 张 24GB 消费级显卡。LLMLingua-2 在 CPU 上跑，不需要 GPU；分块 BM25 也不需要 GPU。CQ2-CARE 本身只调用 API 模型。所以 24GB 显卡足够。

步骤：

1. 数据准备：从 SWE-rebench 的 300 个 issue 里用哈希抽 30 个，每个仓库一个。跑资格检查：金补丁解决、空补丁不解决。预计 30 个里约 29 个通过（论文的通过率是 328/340，约 96.5%）。

1. 实现 CQ2-CARE：按 Algorithm 1 实现。路径清单用词重叠排序，取前 τ = (1/2)×min(∣P∣, 32K) 个 token 对应的路径（原文此处分数在 PDF 提取中损毁为 12，按上下文应为 1/2）。定位调用用 GPT-5.6 或任何可用的 API 模型；每个 issue 抽 5 个答案，其中两个是 construction sample（L1、L2），只保留两者都点名的文件（即这两个样本的交集），另有一个 comparator L0 用于样本畸形时兜底。evidence step 用 git grep 实现。上下文组装用 o200k tokenizer 计数。

1. 实现两个基线：分块 BM25 用 Pyserini 或自己实现，k1=1.2, b=0.75，分块单元是顶层 Python 定义或 60 行窗口。LLMLingua-2 用官方实现，在 CPU 上跑，用 Algorithm 2 拟合预算。

1. 预算匹配：对每个 issue，先跑 CQ2-CARE 得到 B_i，然后让 BM25 打包到 B_i，让 LLMLingua-2 压缩到 B_i ± 2%。

1. 生成补丁和评分：用 SWE-rebench 的官方 harness 跑测试。30 个 issue 的评分在 CPU 上约需几个小时到一天。

1. 预期指标：30 个 issue 上，CQ2-CARE 的解决率应该比 BM25 高约 10 到 15 个百分点，比 LLMLingua-2 高约 10 个百分点。补丁应用率 CQ2-CARE 应该接近 98%，LLMLingua-2 约 70%。金文件召回率 CQ2-CARE 约 79%，BM25 约 50%。由于样本量小，统计显著性可能达不到，但效应方向应该和论文一致。

关键简化：不需要跑 LongLLMLingua 和 LongCodeZip（它们需要额外的 7B 模型推理，时间和显存都紧张），不需要跑 SweRank 和 SWE-Pruner（训练方法，复现成本高），不需要跑 Claude Opus 5（成本高）。

11. 反例设计

要推翻的核心主张：论文声称“在固定 token 预算下，选整文件逐字展示优于压缩 token 或检索 chunk，因为检索器丢失文件、压缩器篡改文本”。

反例实验设计：构造一个代码感知的压缩器，它从 CQ2-CARE 的候选文件出发，但删除的是整行而不是 token，且删除规则是“保留所有被 issue 文本中的标识符、字符串字面量或行号引用的行，以及它们的语法依赖行（如函数签名、类定义、import 语句）”。这个压缩器可以用一个简单的静态分析器实现，不需要训练。

判据：如果这个压缩器在 CQ2-CARE 的候选文件上压缩到同样预算 B_i，解决率显著低于 CQ2-CARE（比如低 5 个百分点以上，且 McNemar 检验 p < 0.05），那么论文的“逐字整文件是必要的”主张得到支持。但如果这个压缩器追平或超过 CQ2-CARE，论文的核心主张就被削弱：它说明问题不在于“压缩”本身，而在于“现有压缩器不知道哪些行是补丁必须引用的”。论文自己的控制实验已经暗示了这个可能性——LongCodeZip 在 CQ2-CARE 候选文件上追平了 CQ2-CARE（+1.0 个百分点，不显著），LLMLingua-2 选整行时差距缩到 3.0 个百分点。如果我的反例压缩器用更精确的“引用感知”规则，可能进一步缩小甚至消除差距。

为什么这个反例有效：论文的结论是“选择文件比压缩 token 好”，但它没有排除“选择文件 + 智能整行压缩”这个中间方案。如果这个中间方案在更低的 token 成本下达到同样解决率，那么论文的实践建议“不要压缩，只选文件”就不再是最优的。论文在 Discussion 里也承认“给定我们的候选文件，LongCodeZip 追平了 CQ2-CARE”，所以这个反例直接针对论文最脆弱的推论。

12. 落地判断

能否用于“抢占式 GPU 自托管 27B 模型做多智能体脚手架”？

能，而且 CQ2-CARE 的思路特别适合这个场景。原因有三：

第一，自托管 27B 模型的上下文窗口和推理成本都受限。 抢占式 GPU 意味着推理可能随时中断，所以每次调用的 token 数越少越好。CQ2-CARE 的定位调用只需要路径清单（最多 32K token），补丁调用只需要选中的文件和证据（平均 13.8K token），比无压缩的单次采样上下文（20.1K token）省 0.68 倍的 token。对 27B 模型来说，13.8K token 的输入是可行的，而 20.1K 可能已经接近长上下文的性能衰减区。

第二，CQ2-CARE 不需要额外的压缩模型或检索模型。 自托管场景下，跑一个额外的 7B 压缩器（如 LongLLMLingua 的 Qwen2.5-7B）会占用宝贵的显存，而且论文报告 LongLLMLingua 和 LongCodeZip 每个 issue 要花 34 到 37 秒 GPU 时间。CQ2-CARE 多出来的是定位调用：每个 issue 抽 5 个排序答案，其中 L1、L2、L0 三个参与定位，另有一次规划搜索。这些调用都可以用同一个 27B 模型完成，不需要加载额外权重。

第三，多智能体脚手架的“文件选择”可以复用。 如果多个智能体协作处理同一个 issue，CQ2-CARE 的定位结果（选中的文件集 F 和证据 E）可以共享给所有智能体，每个智能体只需要付补丁调用的 token 成本。这比每个智能体各自跑检索或压缩要便宜得多。

成本量级：论文报告 CQ2-CARE 用 GPT-5.6 的 API 成本是每 issue 0.151 美元。自托管 27B 模型的成本结构不同：如果 27B 模型在 24GB 显卡上以 FP16 推理，每百万 token 的成本大约是 0.1 到 0.5 美元（取决于显卡利用率和电力成本），那么 13.8K token 的补丁调用加上定位调用的成本大约是每 issue 0.002 到 0.01 美元，比 API 便宜一个数量级以上。但抢占式 GPU 的中断风险意味着需要 checkpoint 机制，否则一次中断就丢失整个 issue 的进度。

最大的坑：27B 模型的定位能力可能远弱于 GPT-5.6 或 Claude Opus 5。论文的所有结果都建立在强模型上。如果 27B 模型在“哪些文件必须改变”这个问题上的 F1 远低于论文报告的 0.613，那么 CQ2-CARE 的文件选择质量会崩溃，整个方法的优势就不存在了。论文没有在 27B 量级的模型上做消融，所以这是落地前必须先验证的假设。建议先用 30 到 50 个 issue 测一下 27B 模型的定位 F1 和解决率，如果定位 F1 低于 0.4，就需要考虑用更强的模型做定位、用 27B 模型只做补丁生成的混合方案。