← 返回 2026-06-09

SWE-Explore：基准测试编码代理如何探索代码仓库 SWE-Explore: Benchmarking How Coding Agents Explore Repositories

Shaoqiu Zhang, Yuhang Wang, Jialiang Liang, Yuling Shi, Wenhao Zeng, Maoquan Wang, Shilin He, Ningyuan Xu, Siyu Ye, Kai Cai, Xiaodong Gu 📅 2026-06-05 👍 122 2026-07-13 08:36
上下文选择 代码仓库探索 代码代理 基准测试 轨迹驱动标注
arXiv HuggingFace PDF

提出首个评估代码仓库探索能力的行级基准测试SWE-Explore

前置知识

Repository-level coding benchmarks

仓库级代码基准测试是一类评估AI代码代理在真实开源仓库中解决实际问题的测试框架。这些基准通常包含完整的代码仓库快照、问题描述（如GitHub issue）、测试用例等，要求代理在限制条件下分析问题并生成修复补丁，然后通过测试验证修复是否成功。典型代表是SWE-bench系列，它将复杂的软件开发任务简化为可执行的二元评估（解决/未解决）。

本文正是基于这类基准测试，发现它们只关注最终结果，忽略了过程中的探索能力，因此提出SWE-Explore来独立评估仓库探索这一关键子能力。

Agent trajectory

代理轨迹是指代码代理在执行任务过程中的完整操作序列记录，包括读取文件、运行命令、搜索代码、编辑文件等所有可观察的动作。在SWE-bench等环境中，每个代理的运行都会产生详细的轨迹日志，记录了它在解决特定问题时访问了哪些文件、查看了哪些代码行、做了哪些修改等。这些轨迹反映了代理的问题解决思路和上下文获取策略。

本文的核心创新就是从成功解决同一问题的多个独立代理轨迹中提取共识性的代码区域，作为评估探索能力的ground truth，避免了昂贵的人工标注。

Context efficiency

上下文效率是本文提出的一个关键评估指标，定义为预测的可见行中有多少比例落在ground truth区域内。这个指标量化了探索者选择的上下文中有多少是真正有用的证据，有多少是无关噪声。高上下文效率意味着探索者既能找到相关代码，又能避免引入过多冗余信息。

实验表明上下文效率与下游修复成功率有最高的Pearson相关性（r=0.950），说明有用的上下文必须既相关又紧凑，这是评估探索质量的核心维度之一。

Line-budget evaluation

行预算评估是一种评估代码检索或探索方法的技术，它不按排名截断（如top-K），而是按总行数预算B截断。给定排序列表P=(r_1, r_2, ..., r_K)，取最长前缀P_{<=B}使得其累计行数不超过B。这意味着一个冗长的区域即使排名靠前，也会因为消耗过多预算而被惩罚。这种设计更贴近实际应用中的上下文窗口限制。

SWE-Explore采用行预算而非排名截断来计算nDCG等指标，更能反映在有限上下文窗口约束下的探索效率，这是本文评估协议的重要设计特征。

研究动机

现有的仓库级代码基准测试（如SWE-bench）将编码任务简化为整体的二元预测问题——要么解决要么未解决。这种设计虽然便于模型间比较，但掩盖了成功或失败的具体机制。一个整体的通过/失败分数无法揭示到底是哪个具体步骤成功了或失败了：是读取了相关代码？定位到了bug？生成了正确的补丁？还是验证了修复？实际上，真实世界的仓库包含数千个文件，确定哪些特定行包含了给定issue的证据，即使对最终解决它的代理来说也是巨大挑战。更关键的是，代理可能因为两种截然不同的失败模式而未通过测试：要么未能探索到修复所需的相关代码，要么检索到足够证据但未能合成正确的补丁。后者被现有的可执行基准捕获，但前者在很大程度上被隐藏了。

本文的目标是本文的目标是将仓库探索从端到端修复中分离出来，形式化为一个可比较的评估目标。具体而言，给定一个issue和一个仓库，探索者需要返回一个相关的代码区域排序列表P = (r_1, r_2, ..., r_K)，其中每个区域r_i = (p_i, s_i, e_i)包含文件路径和行范围。SWE-Explore评估这个列表与从独立成功轨迹中提取的ground truth的匹配程度，衡量探索者多早地浮现场解决路径实际依赖的证据。输出格式刻意保持简单：稀疏检索器、交互式代理和长上下文选择器都被比较为在固定行预算下产生相同排序列表的生成器，这样可以在不要求探索者编写或验证补丁的情况下评估探索行为。

与已有工作不同的是，本文的独特切入点是提出了轨迹驱动的ground truth标注方法。传统方法需要人工标注哪些代码区域对解决问题是必要的，这在本文的规模（848个实例、10种语言）下成本高昂且难以保持一致性。相反，SWE-Explore从成功解决同一问题的多个独立代理轨迹中推导监督信号：将不同解决路径自然探索的代码区域视为核心上下文的行为信号。这种方法利用了强编码代理（如GPT-5.4、Gemini-3-Pro、Sonnet-4.6等）在原始工具下成功运行的轨迹，通过求交集保守地提取核心候选，然后使用LLM驱动的细化步骤提升小部分模型特定的可选读取，最后由作者人工审计每个细化的ground truth。这种方法实现了几乎零人工标注成本的细粒度监督信号。

核心方法

SWE-Explore的方法整体思路是构建一个轻量级的上下文选择任务来独立评估仓库探索能力，而不需要探索者实际编写或验证补丁。给定一个issue q和仓库快照R，任务定义为一个函数f: (q, R) -> P = (r_1, r_2, ..., r_K)，输出排序列表P。评估这个列表与从成功轨迹中提取的ground truth R_core的匹配程度，使用覆盖率、排名和效率三个维度的指标。为了验证这些探索指标确实能预测下游修复行为，SWE-Explore还设计了一个受限上下文修复桥接协议：将探索者的输出作为固定编码代理可见的唯一仓库上下文，测量结果补丁是否通过原始测试套件。这是一个一次性方法学验证，不是标准评估循环的一部分。

本文的核心创新点是轨迹驱动的ground truth标注方法。传统方法需要人工手动标注哪些代码区域对解决问题是必要的，这在跨语言的大规模数据集上成本高昂且难以保持一致性。SWE-Explore利用成功解决同一问题的多个独立代理轨迹中自然出现的阅读行为模式来推导ground truth。直观上，如果多个独立的成功解决路径都访问了某个代码区域，那么这个区域很可能包含了解决该问题的关键证据。这种方法完全基于实际成功的探索行为，而不是人工直觉或启发式规则，因此更加可靠且可扩展。另一个关键设计是行预算评估框架，它使用总行数预算B而非排名截断来计算nDCG等指标，这更贴近实际应用中的上下文窗口限制，使得一个冗长的区域即使排名靠前也会因为消耗过多预算而被惩罚。

方法步骤详情

SWE-Explore的构建分为五个主要步骤。第一步是收集已解决轨迹，对于每个实例，要求至少有两个来自强LLM（如GPT-5.4、Gemini-3-Pro、Sonnet-4.6等）的成功issue解决轨迹，实例满足|T| >= 2后保留。第二步是提取读取操作，从每个轨迹中收集所有能解析为显式文件-区间对的读取动作，包括编辑器风格的view工具调用、命令行读取（cat/head/tail/sed -n）和仓库R内的grep -n行命中，并将它们规范化为区域(p, s, e)。无法明确映射到这种对的动作（如自由形式的终端交互）被丢弃而非启发式扩展。第三步是生成区域，令R(tau)为从轨迹tau中提取的区域集合，首先计算保守交集候选R_int = intersection_{tau in T} R(tau)，然后收集模型特定的可选读取R^{(m)}_opt = union_{tau in T_m} R(tau) - R_int，其中T_m包含T是来自模型家族m的成功轨迹，交集和并在文件级别按行级别进行。第四步是共识聚合和最终化，使用LLM驱动的细化步骤提升小部分可选读取（当它们对issue是关键时），然后作者人工审计每个细化的ground truth，移除不受支持的区域。第五步是探索者评估，给定探索者的输出P和ground truth R_core，计算覆盖率（Precision/Recall/F1/HitFile/HitRegion）、排名（nDCG@B/FUH）和效率三个维度的指标。

技术新颖性

SWE-Explore的技术新颖性体现在多个方面。首先，它是首个将仓库探索形式化为独立评估目标的基准，将探索、定位和补丁合成解耦，使得检索器、搜索代理和长上下文选择器可以在它们设计改进的轴线上直接比较。其次，轨迹驱动的ground truth标注方法完全避免了昂贵的人工标注，通过利用多个独立成功轨迹的共识来提取细粒度的行级监督信号，这是可扩展且可靠的。第三，行预算评估框架（nDCG@B）比传统的排名截断更贴近实际应用中的上下文窗口约束，能够惩罚那些排名靠前但消耗过多预算的冗长区域。第四，受限上下文修复桥接协议提供了探索指标与下游修复行为之间的因果验证，证明了探索质量确实驱动修复成功，而不仅仅是相关性。最后，SWE-Explore的数据规模（848个实例、10种编程语言、203个开源仓库）和语言多样性使其成为当前最全面的仓库探索评估基准。

Overview of SWE-Explore. From solution-verified trajectories, SWE-Explore extracts read actions, aggregates them into core and optional context, and evaluates explorers using both upstream exploration metrics and downstream restricted-context validation.
Figure 2: Overview of SWE-Explore. From solution-verified trajectories, SWE-Explore extracts read actions, aggregates them into core and optional context, and evaluates explorers using both upstream exploration metrics and downstream restricted-context validation.
Example of a SWE-Explore instance.
Figure 4: Example of a SWE-Explore instance.

实验结果

实验结果揭示了多个重要发现。首先，代理探索形成了一个明显高于经典检索的清晰层级。稀疏检索器（BM25、TF-IDF）和轻量级密集检索器在大多数指标上接近Random，而每个代理探索者都显著高于它们。这证实了仓库探索不能被单次词法或嵌入检索单独捕获：与仓库的多步交互已经是达到现代编码代理占据的指标范围所必需的。其次，低F1主要是召回问题。尽管非oracle探索者都有很强的文件级命中率和排名分数，但它们的行级召回率仍然只在0.14-0.19左右，AutoCodeRover非常精确但也召回受限。这表明对于当前的代码代理风格的探索者来说，足够广泛的仓库探索仍然是一个中心瓶颈：它们通常很早就找到合理的文件，但错过了覆盖完整ground truth上下文所需的许多特定范围。第三，LLM选择会改变操作点，但不会改变瓶颈。在相同的Mini-SWE-Agent框架下，GPT家族模型形成最强层级，但所有LLM的文件级命中都远强于行级召回，因此仅替换基础模型并不能消除探索瓶颈。第四，通用编码代理的行为惊人地相似。Claude Code、Codex、OpenHands、Mini-SWE-Agent和AweAgent在覆盖率、排名和效率指标上的配置紧密匹配，这很有趣，因为它们在实现和工具复杂度上不同，但它们的探索输出占据几乎相同的操作点：高文件命中、高早期排名、紧凑上下文和低行召回。最后，专门的本地化器只有当它们扩展搜索时才有所帮助。学术代理并不一致地主导通用编码代理：AutoCodeRover精确但保守，OrcaLoca噪声很低但错过许多相关区域，LocAgent类似于通用代理配置而不是改变召回前沿。CoSIL是主要例外：它实现了迄今为止最高的非oracle行级召回率和F1，表明其迭代代码图搜索是高召回探索的重要组件。

Comparison of SWE-Explore with existing repository-level coding and exploration benchmarks across six design dimensions covering ground-truth granularity, evaluation protocol, and ranked-region assessment.
Table 1: Comparison of SWE-Explore with existing repository-level coding and exploration benchmarks across six design dimensions covering ground-truth granularity, evaluation protocol, and ranked-region assessment.
Per-instance averages of the ground-truth core context |Rcore| at the file, region, and line granularity.
Table 2: Per-instance averages of the ground-truth core context |Rcore| at the file, region, and line granularity.
Downstream resolve rate under the restricted-context validation environment (GPT-5.4 with Mini-SWE-Agent, K=5).
Table 3: Downstream resolve rate under the restricted-context validation environment (GPT-5.4 with Mini-SWE-Agent, K=5).
Explorer-level correlation between each upstream exploration metric and downstream resolve rate, computed across all explorers in our pool.
Table 4: Explorer-level correlation between each upstream exploration metric and downstream resolve rate, computed across all explorers in our pool.
Exploration quality at K=5 across different LLMs powering the same Mini-SWE-Agent scaffold.
Table 5: Exploration quality at K=5 across different LLMs powering the same Mini-SWE-Agent scaffold.
Exploration quality at K=5.
Table 6: Exploration quality at K=5.
Language distribution of the 848 retained SWE-Explore instances across 10 different coding languages.
Figure 3: Language distribution of the 848 retained SWE-Explore instances across 10 different coding languages.
查看结构化数据
任务指标本文基线提升
仓库探索（K=5，行级召回率） Line-level Recall CoSIL: 0.788 BM25: 0.021, TF-IDF: 0.049, Random: 0.004 CoSIL相比BM25提升约37.5倍
仓库探索（K=5，文件级命中率） File-level Hit Rate AweAgent: 0.682 BM25: 0.079, TF-IDF: 0.140, Random: 0.004 AweAgent相比TF-IDF提升约4.9倍
仓库探索（K=5，上下文效率） Context Efficiency Claude Code: 0.829 BM25: 0.087, TF-IDF: 0.190, Random: 0.002 Claude Code相比TF-IDF提升约4.4倍
受限上下文修复（下游验证） Resolve Rate (%) CoSIL: 59.3% TF-IDF: 26.0%, BM25: 12.7%, Random: 4.7% CoSIL相比BM25提升约46.6个百分点
探索指标与下游修复的相关性 Pearson相关系数 Context Efficiency: r=0.950, FUH: r=0.928, Rec@100: r=0.926 F1: r=0.673, 行级召回: r=0.617 Context Efficiency的相关性是F1的约1.4倍

局限与改进

本文存在几个局限性。首先，ground truth的质量依赖于成功轨迹的多样性和质量，如果某些issue只有很少的成功轨迹，或者所有成功代理都遗漏了某些关键区域，那么ground truth可能不完整。作者通过要求至少两个成功轨迹来缓解这个问题，但这仍可能在某些情况下引入偏差。其次，SWE-Explore不评估补丁生成或验证能力，这是有意的设计选择，但也意味着一个优秀的探索者如果配合一个弱的补丁生成器，仍然可能无法解决问题。第三，评估协议假设ground truth区域是必要的，但不同的代理可能有不同的解决路径，某些区域对某些代理可能是可选的。作者通过引入R^{(m)}_opt来部分解决这个可变性问题，但完全消除路径依赖性仍然困难。第四，行预算参数B的选择会影响nDCG等指标的结果，作者在主实验中固定了K=5，但没有系统分析不同预算值的影响。第五，虽然SWE-Explore覆盖了10种编程语言，但Python仍然占主导地位（547个实例，约64.5%），这可能使得评估结果偏向Python友好的方法。最后，受限上下文修复桥接虽然验证了探索指标与下游修复的关联，但这种理想化的环境可能高估了真实场景中的修复成功率，因为真实代理可能需要多次迭代调整上下文。

独立分析的弱点

独立分析来看，SWE-Explore存在几个潜在的弱点。首先，ground truth提取方法依赖于强代理的成功轨迹，但如果所有现有代理都遗漏了某些真正关键的代码区域，那么ground truth将系统性地不完整。这可能导致评估偏向于模仿现有代理行为的方法，而不是真正更优的探索策略。一个改进方向是引入少量人工标注作为质量检查，或者开发更鲁棒的轨迹聚合方法（如加权共识而非简单交集）。其次，SWE-Explore的评估指标假设所有ground truth行同等重要，但实际中某些行可能比其他行更关键。改进可以引入行级权重或重要性评分，更精确地反映哪些代码区域是绝对必要的。第三，行预算评估虽然更贴近实际应用，但可能不适用于那些需要大量上下文才能理解复杂问题的场景。改进可以提供多种预算配置的评估结果，或者开发自适应预算分配机制。第四，SWE-Explore不评估探索的效率（如时间成本、API调用次数），这在实际应用中很重要。改进可以添加计算资源效率指标，使得评估更全面。最后，受限上下文修复桥接虽然验证了指标的有效性，但单次修复可能与真实的多轮迭代过程有差异。改进可以设计更接近真实使用场景的验证协议。

未来方向

作者提出和基于成果可延伸的未来研究方向包括：首先，扩展SWE-Explore到更多编程语言和更复杂的任务类型，如多模态软件问题、长期视野的专业任务等，使其更全面。其次，开发更高效的探索算法，特别是针对行级召回率这个当前瓶颈的研究，如改进的代码图搜索、多模态检索（结合代码结构、注释、提交历史等）或动态预算分配策略。第三，研究如何将探索与补丁生成更紧密地集成，而不是分离评估。例如，可以开发端到端的探索-修复联合训练框架，或者探索反馈驱动的迭代探索（根据补丁生成器的反馈调整探索策略）。第四，分析不同探索方法在不同类型问题上的表现差异，找出它们的适用场景和互补性，从而设计问题感知的探索策略选择机制。第五，研究如何利用失败轨迹来改进探索，失败的尝试可能揭示哪些探索路径是无效的，从而帮助避免重复错误。最后，将SWE-Explore的评估框架应用到其他领域，如自然语言处理的文档理解、多模态推理的场景探索等，验证其通用性。

复现评估

SWE-Explore的复现性良好。数据集、代码和评估脚本已开源，包含完整的848个实例、ground truth标注和评估工具。所有实验使用的都是公开可用的预训练模型（GPT-5.4、Gemini-3-Pro、Sonnet-4.6、GLM-5.1、Kimi-K2.6等）和开源工具（SWE-agent、AutoCodeRover、LocAgent等）。评估协议清晰明确，只需要标准的Python环境和必要的依赖库。论文在附录中详细描述了ground truth构建、指标计算、受限上下文修复验证等所有技术细节，使得研究者可以完全复现实验结果。唯一可能增加复现难度的是某些商业模型（如GPT-5.4）的访问权限，但论文也提供了多个开源和开放模型的结果，研究者可以使用这些模型进行验证。总体而言，SWE-Explore是一个高度可复现的研究成果。

论文图表

Motivation of SWE-Explore. A holistic metric of resolution rate conflates exploration, localization, and patch synthesis. SWE-Explore isolates repository exploration as a line-level evaluation target.
Figure 1: Motivation of SWE-Explore. A holistic metric of resolution rate conflates exploration, localization, and patch synthesis. SWE-Explore isolates repository exploration as a line-level evaluation target.

Figure 1通过对比图展示了现有基准测试和SWE-Explore基准测试的区别。左侧是现有基准测试的流程：给定Issue和Repository，Agent执行Explore、Patch、Verify三个步骤，最终输出一个Resolve Rate（解决率）。这个整体指标将探索、定位和补丁合成混在一起，无法区分哪个步骤成功或失败。右侧是SWE-Explore基准测试的流程：同样是给定Issue和Repository，问Explorer哪些上下文是必要的？，然后输出哪些上下文被看到、哪些没被看到，最终评估Exploration Quality（探索质量）。SWE-Explore将仓库探索分离为行级评估目标，而不是端到端评估。

这张图对理解论文至关重要，因为它直观地展示了SWE-Explore解决的核心问题：现有基准测试的整体指标掩盖了探索能力的评估，而SWE-Explore通过将探索分离为独立的评估目标，使得研究者可以直接比较检索器、搜索代理和长上下文选择器的探索质量，而不需要它们编写或验证补丁。

Figure 5: Resolve rate as the visible context degrades from the Oracle's full core set Rcore to either a% of Rcore alone (GT scaling, solid) or a% of Rcore padded back to full size with random non-core regions (noise injection, dashed).

Figure 5包含4个子图，展示了在上下文退化情况下的resolve rate变化。横轴是GT fraction a%（从0到100），纵轴是Resolve rate（%）。四个子图分别是：Easier subset | GPT-5.4-mini（左上）、Easier subset | GPT-5.4（右上）、Harder subset | GPT-5.4-mini（左下）、Harder subset | GPT-5.4（右下）。每个子图有两条曲线：实线是GT scaling（只保留a%的Rcore），虚线是noise injection（保留a%的Rcore并用随机非核心区域填充回完整大小）。从曲线可以看出：1）在easier subset上，resolve rate在a=0到50时较低，在a=50到75之间显著跃升，然后趋于平稳；2）noise injection曲线在a>=75时 closely tracks GT scaling曲线，说明当核心证据足够时，现代补丁生成器可以容忍额外的无关代码；3）在harder subset上，resolve rate范围更窄，说明当issue本身超出补丁生成器能力时，仅改进上下文效果有限；4）easier subset在a=0到25时有dip，这可能是memorization导致的。

这张图对理解论文的核心结论很重要，它量化了缺失上下文和冗余上下文对下游修复的相对影响。结果表明缺失核心上下文是主导的失败模式，而适度冗余上下文的伤害较小，这验证了高覆盖率召回的重要性超过了小精度增益。这张图也解释了为什么Context Efficiency和Rec@100等指标与下游修复有强相关性。