找对文件还不够：SWE-Explore 怎么评仓库探索

本文是 arXiv 论文 SWE-Explore: Benchmarking How Coding Agents Explore Repositories（arXiv:2606.07297）正文第 1 节至第 5 节，以及附录中语言分布、标注规则和局限的中文译文，由智测团队翻译。参考文献未逐条展开。正文保留了论文主表里的探索指标和下游修复率。

摘要

仓库级编码基准，例如 SWE-bench，推动了编码智能体能力的快速上升。但它们通常把编码任务当成一个整体的二值预测：解决或未解决。仓库理解、上下文检索、代码定位和缺陷诊断这些更细的能力被盖住了。本文提出 SWE-Explore，把仓库探索单独拿出来评。给定仓库和一条 Issue，探索者要在固定的行预算下，返回一份相关代码区域的排序列表。基准覆盖 10 种编程语言、203 个开源仓库上的 848 条 Issue。每条实例的行级地面真值，来自独立的、成功解决同一条 Issue 的智能体轨迹，蒸馏出这些解题路径实际查阅过的代码区域。评测沿覆盖、排序和上下文效率展开。这些指标强烈跟踪下游修复行为。在检索方法、通用编码智能体和专门定位器上，智能体式探索者明显高过经典检索一层。现代方法的文件级定位已经很强；行级覆盖和高效排序，仍是区分前沿探索者的关键轴。

代码与数据：https://github.com/Qiushao-E/SWE-Explore-Bench ，以及 Hugging Face 数据集 SWE-Explore-Bench/SWE-Explore-Bench。

1 引言

仓库级编码基准，例如 SWE-bench，推动了自动编码智能体能力的快速上升。围绕这些基准的生态扩张很快：新的评测分布覆盖多语言仓库、多模态软件问题和更难、更长程的专业任务。与此同时，SWE-smith、SWE-Gym、SWE-Dev 这类面向训练、可扩展的资源也在推动智能体开发。在这些资源上，SWE-agent、AutoCodeRover、Agentless、OpenHands、Claude Code、Mini-SWE-Agent 和 AweAgent，已经把仓库规模的 Issue 解决变成软件工程智能体的日常试验场。

这些基准被广泛采用，协议既是优点也是主要限制：每次修复尝试被收成一次通过或失败，如图 1。二值指标让模型可以直接比，但盖住了成功的内部机制。一个整体的通过/失败分数，看不出到底是哪一步成了或败了：读到相关代码、定位缺陷、生成补丁，还是验证修复。从这一次预测退后一步，失败有两种。智能体要么没探索到修复所需的相关代码，要么已经取回足够证据，却没能合成正确补丁。后一种现有可执行基准抓得到，前一种大体被藏起来。真实仓库有几千个文件。判断哪些具体行携带某条 Issue 的证据，即使对最终解开它的智能体也很难。近期关于上下文管理和缺陷定位的工作，越来越承认这种分解。

因此，编码智能体的仓库探索能力仍然测得不够。尽管已有工作研究智能体式定位和检索，现有评测仍缺少一个共同、精确的目标，用来比较经典检索器、搜索智能体和长上下文选择器。只测文件或函数级定位，只说明智能体有没有走到大致正确的街区，没有任何指标揭示到底探索了哪些代码行。看不见行级覆盖，就不能严格评智能体在开始写代码之前把仓库探索得怎么样。

图 1 的动机是：解决率这种整体指标把探索、定位和补丁合成混在一起。SWE-Explore 把仓库探索隔离成行级评测目标。

本文把仓库探索变成可比较的评测目标。给定一条 Issue 和一个仓库，探索者返回一份代码区域的排序列表。这份列表对照地面真值打分。地面真值来自独立的、成功解决同一条 Issue 的智能体轨迹，问的是：列表多早露出那些轨迹实际依赖的证据。输出格式故意简单：稀疏检索器、交互式智能体和长上下文选择器，都当作同一份排序区域列表的生产者，并受固定行预算约束。这样评探索行为，不要求探索者写补丁或验证补丁。

为检查更高的探索分数是否真带来更好的修复，SWE-Explore 配了一套受控的下游协议：把每个探索者的输出，而且只有这份输出，作为可用的仓库上下文喂给一个固定的编码智能体，再看生成的补丁能否通过原来的测试套件。这不是主基准的替代，而是用来核验：探索指标量的，就是驱动下游成功的那件事。下游协议是外部效度检查，基准本身仍是一个轻量的上下文选择任务。

贡献有三条。

第一，新的评测目标。把仓库探索从端到端修复里拆出来，形式化成带排序的行级上下文选择，使检索器、搜索智能体和长上下文选择器能在它们本来要改进的轴上比较。

第二，以轨迹为根据的监督。从成功的智能体轨迹标注地面真值行，尽量少做手工标注。

第三，一套经过修复验证的指标。系统比较覆盖、排序和预算效率，并用受控下游协议说明保留下来的指标能预测修复成功。协议里，固定编码智能体看得见的上下文只有该探索者的输出。

2 相关工作

2.1 编码基准

表 1 从六个设计维度比较 SWE-Explore 和已有的仓库级编码与探索基准：是否基于可执行验证、是否多语言、是否有行级地面真值、地面真值是否来自轨迹、是否联合评测探索与修复、是否评测排序后的区域。

仓库级基准把可执行的 Issue 解决确立为编码智能体的中心评测目标。SWE-bench 把 Issue 描述、仓库快照和基于测试框架的验证接在一起；Verified 和 Live 变体收紧质量和污染控制。后续工作沿几条轴拓宽：多语言（SWE-bench Multilingual、Multi-SWE-bench），多轮和变基设置（SWE-bench Multimodal、SWE-rebench）。第二条线把评测推向中间行为：ContextBench 引入人工标注的黄金上下文，并在智能体轨迹上给检索打分；SWE-Pruner 和 SWE-ContextBench 分别评测上下文压缩和经验复用。相关工作还考察相邻的仓库级能力，包括分层调试与正确性检查、程序员行为模式、多智能体辩论、经验驱动的修复，以及仓库级问答。

这些基准要么对准完整的「从 Issue 到补丁」流水线，要么评测中间行为的孤立侧面。缺的是一个基准，能同时测量：以轨迹为根据的行级探索质量，以及它对 Issue 解决的下游影响。这很重要，因为探索质量既不能被粗上下文标签完全抓住，也不能被最终解决率完全抓住。探索者可能走到正确的文件，却错过决定性的代码段；也可能把正确证据排得太靠后。SWE-Explore 是补充而不是竞争：它直接从成功轨迹导出行级监督，把探索评成排序区域列表任务，并在同一批实例上用受限上下文做可执行验证。

图 2 是总览。从已验证解开问题的轨迹里抽出阅读动作，聚成核心上下文和可选上下文，再用上游探索指标和下游受限上下文验证来评探索者。

2.2 探索方法

定位和探索方法研究如何在仓库里找到相关代码。经典检索和缺陷定位用自然语言报告给代码制品排序。TF–IDF 和 BM25 是轻量基线，基于信息检索的缺陷定位对准可能有故障的文件。语义代码搜索和仓库检索把场景扩到自然语言到函数的搜索，以及跨文件的代码补全。nDCG 是奖励有用证据早出现的标准办法。长上下文压缩的工作进一步指出：选择、压缩和保留代码上下文，本身就是代码模型和智能体的核心设计。这些评测提供了有用方法，但目标通常是查询与片段的相关性、下一行补全的相关性，或缺陷文件的相关性，而不是成功解决 Issue 时实际查阅的行区域。

近期基于大模型的方法从静态检索走向交互式探索。AutoCodeRover 组合大模型推理、代码搜索和程序分析。LocAgent、OrcaLoca 和 CoSIL 在文件、函数、排序实体或迭代的代码图搜索上评定位。CodeScout 研究预探索，用来改进问题陈述。通用编码智能体进一步表明，在实际修复里，导航、上下文管理、工具使用和补丁生成是绑在一起的。仍然缺少系统比较的，是一个共同目标：把词法检索器、稠密检索器、重排器和智能体式探索者，都当成排序的、行级区域的生产者。SWE-Explore 用轨迹导出的行级目标，以及只改变所选上下文的固定脚手架下游协议，填这个缺口。

3 SWE-Explore 基准

3.1 任务形式

仓库探索被写成一项独立功能。给定 Issue q 和仓库快照 R，返回相关代码区域的排序列表：

f 把 (q, R) 映射到 P = (r1, r2, …, rK)

P 是排序后的区域列表。每个区域 ri = (pi, si, ei)，由文件路径和闭区间行范围组成。SWE-Explore 不要求最终补丁，不访问地面真值，也不要求必须和仓库交互。如图 2，基准用第 3.4 节的指标族，对照每条实例从轨迹导出的监督给 P 打分。另外，受限上下文的修复桥只做一次方法学验证，用来说明这些指标跟踪修复行为。它不是标准评测循环的一部分。新的探索者可以只用上面的指标来评。

3.2 数据来源

三个公开的仓库级数据源：SWE-bench Verified、SWE-bench-Pro、SWE-bench Multilingual。经过第 3.3 节的解题验证过滤后，保留 848 条实例，跨 10 种语言、203 个开源仓库。如表 2 和图 3，每条实例平均有 4.3 个地面真值文件、4.7 个区域、1,578 行可见代码，所在仓库平均有 759 个非测试文件、18.0 万行非测试源码。分来源的细目放在附录 A。

表 2 是核心上下文 R_core 的逐实例统计，给出均值和最大值。

3.3 地面真值标注

只保留至少观察到两条成功解题轨迹的实例。成功轨迹来自较强的大模型，例如 GPT-5.4、Gemini-3-Pro、Sonnet-4.6、GLM-5.1 和 Kimi-K2.6。没有两条成功轨迹的实例被排除，因为从轨迹导出的上下文支撑不了下面要用的跨运行一致信号。过滤后，三个来源合计保留 848 条。

手工标注必要上下文，在这个规模上既贵又难一致：几百条仓库级 Issue 跨十种语言，标注者对辅助函数、配置和测试的边界可能划得不一样。SWE-Explore 改从已验证解开问题的智能体轨迹取监督：强编码智能体在原始测试框架下的成功运行。正文列举的模型包括 GPT-5.4、Gemini-3-Pro、Sonnet-4.6、GLM-5.1 和 Kimi-2.6。对每条保留实例，收集成功轨迹集 T，并且 |T| 至少为 2。附录 G 有一处写成「池中至少一个智能体解开」。正文的过滤条件是至少两条成功轨迹。下文以正文为准。

跨独立成功轨迹反复出现的区域，被当作核心上下文的行为信号：它们是不同解题路径在解决同一条 Issue 时自然探索过的代码段。给定 T，先对阅读区域取交集，得到保守的核心候选；再用一步基于大模型的精炼，把一小部分模型特有的可选阅读提升进来，条件是它们对这条 Issue 是承重的。最后作者对照 Issue 和轨迹，手工审计每一份精炼后的地面真值，删掉没有依据的区域。

图 3 是 848 条实例在 10 种语言上的分布。附录表 7 给出计数：Python 547 条（64.5%），Go 84 条（9.9%），JavaScript 51 条（6.0%），Rust 31 条（3.7%），Java 30 条（3.5%），PHP 28 条（3.3%），TypeScript 27 条（3.2%），Ruby 22 条（2.6%），C 21 条（2.5%），C++ 7 条（0.8%）。Python 最多，是因为 SWE-bench Verified 以 Python 为中心；非 Python 覆盖主要来自 SWE-bench-Pro 和 SWE-bench Multilingual。

抽取阅读。从每条轨迹收集所有能解析成明确「文件–区间」对的阅读动作：编辑器式的查看工具调用，命令行阅读（cat、head、tail、sed -n），以及仓库内带行号的 grep -n 命中。再规范成区域 (p, s, e)。无法无歧义映射到这种对的动作，例如自由形式的终端交互，直接丢掉，不做启发式扩张。监督记录严格落在可观察的阅读上。

图 4 是一条实例。左侧是 Issue 加仓库快照，核心片段被标出。右侧是轨迹导出的核心区域 C_core（打分目标）和可选区域 C_opt，以及探索者对照 C_core 打分的排序预测。

生成区域。设 R(τ) 为从轨迹 τ 抽出的区域集合。先算保守交集候选：所有轨迹阅读区域的交集 R_int。交集之外、各模型族特有的阅读记为可选集。交集和并集都在文件内按行做。例如 parser.py 的 40–80 行和 60–100 行两次重叠阅读，对交集的贡献是 parser.py 的 60–80 行。

本文使用的最终核心 R_core 是 R_int 的精炼版：大模型精炼把一小部分可选阅读提升进来，作者再手工审计。除非另说，后文的 R_core 都指这份精炼并审计过的地面真值，而且它是主实验里唯一的打分目标。纯交集、精炼核心和并集变体的消融放在附录 B。

路径按仓库相对路径存放。行区间从 1 起、闭区间。打分前做路径规范化，使 ./src/foo.py 和 src/foo.py 指向同一文件。每条实例对着来源基准继承来的固定仓库快照评测。生成文件、临时文件、外部依赖路径和检出之外的文件，不算有效仓库文件。

3.4 指标

设 L(r) 为区域 r 覆盖的（文件，行号）对。对预算 B，P≤B 是 P 的最长前缀，其累计可见行数不超过 B。L(P) 是各区域覆盖的并。Y 是核心 R_core 覆盖的行集合。

覆盖与准确率。精确率和召回在行级定义。精确率是预测行与核心行的交集除以预测行数。召回是该交集除以核心行数。F1 是二者的调和平均。另外报两个更粗的命中率，用来抓住「即使行区间不精确，也重叠到了正确代码」这件事。文件级 HitFile 是预测碰到的核心文件占核心文件的比例。区域级 HitRegion 是至少被一条预测重叠到的核心区域所占的比例。

预算下的排序。把 nDCG 改进行预算设置。每个预测区域的增益等于它覆盖的核心行数。按预测顺序处理，DCG@B 在累计行数仍不超过 B 的最长前缀上，累加折扣增益。折扣分母是 log2(i+2)。nDCG@B 用同一实例、同一行预算下能达到的最好 DCG 来归一。理想排序的做法在附录 C。用行预算而不是名次截断，意味着一个啰嗦、耗尽预算却没有成比例增益的区域，和漏掉有用内容受到同样重的惩罚。另外报告首次有用命中 FUH，定义为 1 减去首次与核心目标相交的名次除以列表长度；若没有任何一名相交则为 0。FUH 越高，有用证据出现得越早。

效率与噪声。上下文效率是预测可见行里，落在核心或该模型可选区域之内的比例，用来量化所选上下文有多少是有根据的证据、多少是偏题。互补的噪声率是预测区域里既不重叠核心、也不重叠可选区域的比例，作为区域级诊断。

下游修复验证。为检查上述指标是否跟踪修复行为，构造一次性的受限上下文环境：对某个探索者输出 P，把仓库里并集区域之外的一切藏起来，让一个固定编码智能体产补丁，再用原来的 SWE-bench 测试框架判定。这是对指标的一次性健全性检查，不是标准评测程序的一部分。第 4.2 节用它量化每个指标对解决率的预测力。容器、行预算 B、测试回调和补丁脚手架的实现细节在附录 D。

4 实验

4.1 设置

探索者分四族。两个基线用来框住动态范围：Oracle 直接返回 R_core，Random 返回均匀抽样的区域。稀疏检索是 BM25 和 TF–IDF。轻量稠密检索是用 Potion 实例化的 RAG 流水线。Potion 是从一个句子变换器蒸馏出的静态词嵌入检索器。智能体式探索者包括五个通用编码智能体：Claude Code、Codex、OpenHands、Mini-SWE-Agent、AweAgent；以及四个已发表的学术定位智能体：AutoCodeRover、LocAgent、OrcaLoca、CoSIL。Oracle 在第 4.2 节验证地面真值构造时特别重要。

指标。主指标是精确率、nDCG@500、HitFile 和上下文效率，因为它们与下游行为相关高、彼此冗余低。另外把召回、F1、命中率和噪声率当作常规参考，尽管其中几个单独的预测力较弱。

K 的选择。精炼后的地面真值里，每条实例的核心区域数平均大约 4.7。因此全文把 K 固定为 5：每个探索者返回最相关的五个区域。这样比较公平，也和监督目标的规模对齐。

4.2 下游验证

在把上游探索指标当作主评测目标之前，先问它们是否跟踪下游修复。在 SWE-Explore 的一个共享子集上，n = 150。每个探索者提供 K = 5 的排序区域，再把得到的上下文交给固定的 Mini-SWE-Agent 补丁器。正文写这个补丁器由 GPT-5.4 和 Gemini-3-Pro 支撑，解决率是两个补丁器的平均。表 3 的表注则写成「GPT-5.4 配 Mini-SWE-Agent，K = 5」。两处表述不完全一样。下面的解决率按表 3 照录。

表 3 里的 RAG 对应第 4.1 节用 Potion 实例化的那条轻量稠密检索。表 6 直接把这一行标成 Potion。

表 4 是每个上游指标与下游解决率的探索者级相关，在全部探索者上计算。Pearson r 衡量线性相关，Spearman ρ 衡量秩相关。向下箭头表示越低越好。

稳定信号。最强的指标既不是纯文件级，也不是纯召回。上下文效率的 Pearson 相关最高（r = 0.950），说明有用上下文必须既相关又紧凑。Rec@100 是秩相关最强的信号（ρ = 0.845），说明紧行预算下的早期覆盖对修复特别有预测力。HitFile、HitRegion 和 FUH 的 Pearson 信号仍然强：它们分别抓住是否走到正确文件、是否重叠正确证据、是否早早露出有用证据。精确率也有预测力，但和覆盖类指标一起看才最有信息。

有用但不完整的信号。nDCG@500 这类排序指标 Pearson 很高、Spearman 较弱，说明它们能分开大的质量档，但对邻近探索者的排序不够稳。召回类指标有预算效应：Rec@100 在两种相关里都强；更宽的召回和 F1 更敏感于秩，而不是尺度，因为它们倾向于奖励读得很广，即使所选上下文并不紧凑。噪声率有预期中的负相关，但更适合当诊断，不适合当单独的成功度量。因此要报一组混合指标，而不是单一分数。表 5 和表 6 强调 HitRegion、HitFile、精确率、nDCG@500、FUH 和上下文效率，同时保留召回、F1、Recall@500 和区域噪声率作为补充诊断。

4.3 探索质量

表 5 是同一个 Mini-SWE-Agent 脚手架、换不同大模型，在 K = 5 时的探索质量。加粗在原文中标每列最好，下划线标第二。这里只保留数字。

表 6 是 K = 5 时各探索者的探索质量。智能体式探索者的底层模型都是 GPT-5.4。Oracle 在若干预算内指标上并不是最高，例如 nDCG@500 为 0.858，低于若干紧凑的智能体；它的不受预算限制的行召回是 0.953，而 Rec@500 只有 0.576。这与第 3.4 节一致：行预算会惩罚一次倾倒过多行、却没有成比例增益的输出。核心上下文均值有 1,578 行，远超 500 行预算。

观察如下。

智能体式探索明显高于非智能体检索。BM25、TF–IDF 和轻量稠密检索在多数指标上仍接近 Random，而每个智能体式探索者都明显高于它们。仓库探索不能被一次性的词法或嵌入检索充分抓住。要进入现代编码智能体所在的指标区间，与仓库的多步交互已经是必要的。

低 F1 主要是召回问题。尽管文件级命中和排序分数很强，多数非 Oracle 探索者的 F1 仍然低，限制项通常是行级召回而不是精确率。通用编码智能体都能达到很高的 HitFile 和 nDCG@500，但行级召回只在大约 0.14 到 0.19。AutoCodeRover 很精确，同样受召回限制。当前这种代码智能体式探索者的中心瓶颈，仍是探索得不够广：它们常常很早找到像样的文件，却错过覆盖完整地面真值上下文所需的许多具体片段。

换大模型会移动工作点，但不去掉瓶颈。表 5 把脚手架固定成 Mini-SWE-Agent。GPT 家族是最强的一档，但画像略有不同：GPT-5.4 更干净、更紧凑；GPT-5.4-mini 露出更多核心区域，也更早排出有用证据。Kimi-K2.6 和 Sonnet-4.5 是中间档。GLM-4.7 和 Gemini-3-Pro 主要落后在覆盖和排序。比精确名次更重要的是更大的模式：所有大模型上，文件级命中都远强于行级召回。只换底模去不掉探索瓶颈。高召回的区域发现，仍然需要更好的探索机制，而不只是更强的补丁模型。

通用编码智能体的行为意外地接近。Claude Code、Codex、OpenHands、Mini-SWE-Agent 和 AweAgent 在覆盖、排序和效率上画像很近。它们的实现和测试框架复杂度不同，探索输出却几乎占同一个工作点：文件命中高、早期排序高、上下文紧凑、行召回低。这说明研究探索这个子问题时，不一定需要复杂的修复框架；更简单的探索接口就能露出大部分同样的行为。

专门定位器只有在扩大搜索时才有帮助。学术智能体并不一律压过通用编码智能体。AutoCodeRover 精确但保守。OrcaLoca 噪声极低，但错过很多相关区域。LocAgent 更像通用智能体的画像，而不是改写召回前沿。CoSIL 是主要例外：它的非 Oracle 行级召回和 F1 远远最高，说明迭代的代码图搜索是高召回探索的重要成分。更依赖外壳式导航或狭窄搜索动作的探索者，可能走到正确文件，仍然盖不住行级证据。

行级评测提供文件命中之外的信息。HitFile 仍然是强信号，第 4.2 节的下游相关说明了这一点。但它区分不了探索者有没有在那些文件里露出相关片段。多数智能体式探索者 HitFile 高、行召回低得多。这支持 SWE-Explore 的行级设计：文件级定位量的是走到正确街区，行级指标量的是成功轨迹需要的证据有没有被暴露出来。

4.4 受控的上下文退化

前面说明探索者在覆盖、精确率、排序和效率上不同，而且这些差别影响下游修复。这里问一个更受控的稳健性问题：补丁器更怕缺相关上下文，还是更怕多余的无关上下文？在受限上下文环境里，对 Oracle 上下文做合成扰动。缺失条件只暴露核心区域的比例 α，α 取 0、25、50、75、100。冗余条件把去掉的预算用随机抽到的非核心区域填回原规模。在 SWE-Explore 的两个分层 n = 150 子集上扫描 α，补丁器一个弱（GPT-5.4-mini）、一个强（GPT-5.4）。图 5 报告四个面板。实线是只缩放地面真值，虚线是注入噪声后填回原规模。

缺上下文是主导失败模式。在较易子集上，下游解决率只在足够的核心证据出现之后才急剧变化：部分上下文时一直低，然后在 α = 50 和 α = 75 之间跳升。这种阈值形态说明，补丁器不是从每一个新增区域平滑地积累价值；若干块核心证据必须一起在场，正确修复才变得可能。一旦越过这个阈值，冗余上下文伤害较小：α 大于等于 75 时，冗余曲线紧贴缺失曲线。也就是说，必要证据已经可见时，现代补丁器能容忍额外的无关代码。这与上面的指标分析一致：在高覆盖区间，缺核心证据比中等程度的精确率损失更要紧，所以面向召回的改进比小幅过滤更有价值。核心证据稀缺时冗余伤害最大，尤其在 α = 0，随机的非核心代码把解决率降低 7 到 9 个百分点。较难子集的变化范围窄得多。当 Issue 本身超出补丁器能力时，只改善上下文作用有限。

较易子集上的下凹，提醒不要轻信空上下文基线。两条较易子集曲线都从 α = 0 下凹到 α = 25，强补丁器更明显。一个说得通的解释是记忆：没有仓库上下文时，模型可能依赖只看 Issue 的先验；一小片不完整的核心上下文却迫使它去调和部分证据。较难子集上这个下凹消失，因此把它当作提醒，而不是主效应：在常见仓库上，空上下文基线可能被抬高，解释时要小心。

5 结论

SWE-Explore 通过带排序的行级上下文选择，把仓库探索的评测从补丁生成里独立出来。它用轨迹导出的监督，按探索者露出的证据来比较检索器、搜索智能体和长上下文选择器，而不是只看最终修复结果。实验表明：探索指标跟踪下游修复；当前智能体很会找相关文件，但在行级上仍受召回限制；缺核心证据比中等程度的冗余上下文更伤。作者希望 SWE-Explore 成为一个集中的目标，用来建造读仓库更广、并能露出修复智能体真正需要的代码段的探索者。

附录里与正文直接相关的边界

局限。SWE-Explore 覆盖的是池中智能体能够解开的实例，并不代表全部未解决的仓库级 Issue。附录 G 写成「至少一个智能体解开」，与正文「至少两条成功轨迹」的过滤条件用词不同。轨迹导出的地面真值是有用上下文的经验近似，不是证明不存在别的证据也能支撑一个合法解。有些合法解题路径依赖的证据，可能不同于观察到的成功轨迹。因此受限上下文协议应读成对探索指标的受控验证，而不是补丁生成能力的绝对度量。

发布范围。基准来自公开的软件工程基准和公开仓库元数据。发布排除私有仓库、凭据和用户数据。记录保留来源归属，并包含模式、出处和预期用途的说明。

计算。稀疏检索基线在仓库建索引后用 CPU 工人跑。稠密检索还要算嵌入，但不微调。智能体式探索者和受限上下文验证最贵，因为需要大模型调用和可执行测试框架。每次下游运行记录模型、提示、工具预算、墙钟时间、补丁状态和是否解决。