ContextBench：面向代码智能体上下文检索能力的基准评测 ContextBench: A Benchmark for Context Retrieval in Coding Agents
首个评估编程智能体代码上下文检索能力的过程级基准
前置知识
LLM编码智能体（Coding Agent）
基于大语言模型的自主系统，能够通过多步推理和工具调用来解决代码仓库级别的软件工程任务。典型代表包括SWE-agent、OpenHands、Agentless等，它们可以自主浏览代码库、搜索文件、执行命令、生成补丁来修复bug或实现新功能。这些智能体通常由LLM作为推理核心，配合文件浏览、代码搜索、终端执行等工具接口构成完整的工程系统。
本文的核心研究对象就是这类智能体在解决问题过程中如何检索和利用代码上下文，理解编码智能体的基本架构是理解本文评测框架的前提。
SWE-bench系列基准
一组从真实GitHub issue中构建的代码修复基准，要求智能体根据issue描述生成通过测试用例的补丁。包括SWE-bench Verified（500个Python任务）、Multi-SWE-bench（1632个多语言任务）、SWE-PolyBench PB500（500个多语言任务）和SWE-bench Pro（1865个任务）等变体。这些基准主要以Pass@k（即生成k个补丁中至少一个通过测试的比率）作为评价指标，关注最终结果而非过程。
ContextBench的任务来源正是这四个基准，理解SWE-bench的评测方式才能理解本文提出过程级评测的动机和必要性。
Gold Context（金标准上下文）
由人类专家标注的、解决某个issue所必需的最小代码片段集合，包括相关文件、AST代码块和具体行范围。这些上下文从ground-truth patch出发，通过追踪代码依赖（函数调用、类继承、数据流等）逐步构建，并经过LLM生成验证（仅基于标注上下文能否生成通过测试的补丁）和交叉审查确保质量和紧凑性。
Gold Context是本文评测框架的核心参照物，所有检索质量指标（recall、precision、F1）都是将智能体检索的上下文与Gold Context对比计算得出的。
AST（抽象语法树）与Tree-Sitter
AST是将源代码解析为树状结构的中间表示，每个节点代表代码中的一个语法构造（如函数定义、类声明、条件语句等）。Tree-Sitter是一个增量解析工具，支持多种编程语言，能快速将源代码解析为具体的语法树，被广泛用于代码编辑器的语法高亮和代码分析。在本文中，Tree-Sitter用于将代码仓库解析为统一的结构坐标系统，实现文件级、块级（AST定义节点）和行级的精确对齐。
Tree-Sitter是本文实现细粒度上下文对齐和评测的技术基础，理解它的工作原理才能理解recall、precision如何在不同粒度上被计算。
上下文检索的Recall与Precision
在本文的评测框架中，Recall衡量智能体检索到的上下文覆盖了多少Gold Context（即相关信息的查全率），Precision衡量智能体检索的上下文中有多少确实是Gold Context的一部分（即检索结果的准确率）。F1是二者的调和平均。这三个指标分别在文件级、代码块级和行级三个粒度上计算，使用区间重叠（interval overlap）方法对齐。
这组指标是本文量化评测的核心，论文的主要发现——LLM普遍偏向recall而非precision——就是通过这三个指标的对比得出的。
研究动机
当前LLM编码智能体的评测体系严重偏向结果导向，以SWE-bench为代表的基准只关注最终任务成功率（Pass@k），完全忽略了智能体在解决问题过程中如何检索和利用代码上下文。这种评测方式存在根本性缺陷：高成功率可能源于反复试错或对特定测试用例的过拟合，而非真正理解了代码上下文。例如，一个智能体可能通过暴力搜索生成了恰好通过测试的补丁，但在实际场景中并不可靠。更具体地说，现有基准无法回答一个关键问题——LLM智能体在解决软件工程任务时，是如何检索和使用关键代码上下文的？这意味着我们无法区分哪些智能体是通过精准的上下文理解成功解决问题的，哪些是通过大量冗余探索碰巧成功的。此外，现有基准也无法提供过程级的中间信号来指导智能体行为的改进。
本文的目标是本文旨在构建一个全新的过程级评测基准ContextBench，专门评估编码智能体在仓库级代码问题解决过程中的上下文检索能力。具体目标包括三个方面：第一，构建包含1136个issue-resolution任务的基准，每个任务都附带人类专家标注和验证的Gold Context；第二，开发自动化评测框架，追踪智能体的完整执行轨迹，测量其检索上下文与Gold Context的recall、precision和F1；第三，利用该基准系统性评测4个前沿LLM和5个主流编码智能体，揭示上下文检索中的关键模式和瓶颈。
与已有工作不同的是，本文的独特切入角度在于将评测视角从「最终结果」转向「过程行为」。与只看补丁是否通过测试的end-to-end评测不同，ContextBench关注智能体「怎么找到正确代码」这一中间过程。这类似于在考试中不仅看最终答案，还要看解题过程——一个靠死记硬背答对题的学生和一个靠理解推导答对题的学生，虽然得分相同但能力完全不同。这种过程级评测的实现依赖于精心构建的Gold Context——它为每个任务定义了「应该检索什么」的标准答案，使得我们可以精确衡量智能体实际检索了什么、遗漏了什么、以及检索了多少噪声。这种评测范式的转变填补了编码智能体研究中「黑箱评测」的空白，为理解智能体行为和指导改进提供了全新的中间信号。
核心方法
ContextBench的构建遵循一条清晰的技术路线：从现有基准中采样任务→去重和筛选→人类专家标注Gold Context→自动化评测框架。整体思路可以类比为「为代码检索考试出题」——先从题库中选题（任务去重与筛选），再请专家写出标准答案（Gold Context标注），最后设计自动阅卷系统（评测框架）。任务来源于4个广泛使用的issue-resolution基准（SWE-bench Verified、Multi-SWE-bench、SWE-PolyBench PB500、SWE-bench Pro），总计4497个初始任务。通过规则匹配和嵌入相似度去重后得到3100个唯一任务，再基于三个难度指标筛选出1500个候选任务，经人工审查最终保留1136个。评测框架则通过追踪智能体执行轨迹、解析代码仓库结构、在多个粒度上对齐和比较上下文来实现自动化评估。
本文的核心创新在于两个方面。第一是Gold Context的构建方法：不同于简单的代码片段收集，Gold Context采用人机协作的三步流程——从ground-truth patch出发追踪代码依赖（函数调用、类继承、数据流路径），通过LLM验证标注的充分性（仅基于标注上下文能否生成通过测试的补丁），以及交叉审查确保紧凑性。这保证了每个Gold Context既是解决问题所必需的（sufficient），又是尽可能简洁的（compact）。第二是多粒度过程级评测：将智能体的检索上下文和Gold Context都映射到Tree-Sitter解析的统一结构坐标系统上，在文件级、AST块级和行级三个粒度计算recall、precision和F1，实现了比传统end-to-end评测精细得多的行为分析。这种评测方式的本质区别在于：它不只看「有没有修好」，而是看「有没有找到对的代码、找到多少、浪费了多少」。
方法步骤详情
ContextBench的构建分为三个关键步骤。第一步是任务去重（Task Deduplication）：从4个源基准汇总4497个任务，首先通过规则匹配（仓库名和issue标识符）消除精确重复，得到3981个任务；然后计算issue描述之间的嵌入语义相似度，去除相似度超过0.9的近似重复，得到3100个唯一任务；最后人工检查边界情况避免误删。第二步是任务选择（Task Selection）：使用三个难度指标筛选——agent solvability（从公开排行榜抓取各任务被智能体成功解决的次数，优先选择未被解决或仅被少数智能体解决的任务）、edit scope（分析ground-truth patch修改的文件数量，优先选择修改范围大的任务）、edit dispersion（使用Tree-Sitter计算编辑区域在仓库结构树上的平均结构距离，优先选择编辑分散在多个模块的任务）。筛选出1500个候选任务后，人工审查去除语义上平凡的任务（如大规模变量重命名、批量格式化），最终保留1136个。第三步是专家标注（Expert Annotation）：6位作者和一批经验丰富的开发者耗时4个月，采用human-in-the-loop流程。标注者从ground-truth patch出发追踪代码依赖（函数/类调用、继承关系、控制流和数据流路径），确保上下文充分且紧凑。然后通过LLM（GPT-5）验证：仅基于标注上下文生成5个候选补丁，若至少一个通过官方测试套件则验证通过。未通过的任务再进行两轮独立标注和验证。最后由不同标注者进行紧凑性检查，去除冗余代码段。
技术新颖性
本文的技术新颖性体现在多个层面。首先是评测范式的创新：这是首个将编码智能体评测从end-to-end结果导向转向过程级行为分析的基准，填补了「智能体如何找到正确代码」这一关键空白。其次是Gold Context的构建方法论：通过人机协作（人类标注+LLM验证+交叉审查）保证标注质量，这在代码智能体评测领域是首创。第三是多粒度对齐技术：利用Tree-Sitter将代码解析为统一的AST坐标系统，实现文件级、块级、行级三个粒度的精确上下文对比，这种结构化对齐方式比简单的文本匹配更加准确和有意义。第四是过程级指标体系：除了传统的recall、precision、F1，还引入了效率（efficiency）、冗余度（redundancy）和使用衰减（usage drop）等动态指标来分析检索过程中的行为模式，这些指标能够揭示智能体在执行过程中的策略差异，如Claude Sonnet 4.5的高效率但高冗余特征。
实验结果
本文的实验评测覆盖4个前沿LLM（GPT-5、Claude Sonnet 4.5、Gemini 2.5 Pro、Devstral 2）和5个主流编码智能体（mini-SWE-agent、SWE-agent、OpenHands、Agentless、Prometheus），在ContextBench Lite（500个任务子集）上进行评测，揭示了多个重要发现。第一，复杂智能体框架并不一定带来更好的上下文检索表现：在5个编码智能体中，采用简单bash命令检索上下文的mini-SWE-agent（F1: 文件级0.634、块级0.375、行级0.312）在多项指标上优于更复杂的Agentless（文件级F1 0.390）、SWE-agent（文件级F1 0.544）和OpenHands（文件级F1 0.463），Pass@1也达到0.472与更复杂的SWE-agent和OpenHands持平，呼应了AI研究中The Bitter Lesson的观点。第二，前沿LLM在有效上下文检索上仍面临挑战：所有LLM的块级F1均低于0.45，行级F1低于0.35，其中Claude Sonnet 4.5表现最佳（行级F1 0.344，Pass@1 0.530），而GPT-5虽然recall最高（行级0.606）但precision最低（行级0.301），导致F1反而较低。第三，LLM普遍偏好recall而非precision：所有模型都倾向于检索更广泛的上下文以最大化覆盖，但引入了大量噪声，如GPT-5在块级recall达0.645但precision仅0.369。第四，平衡检索策略能提升性能和成本效率：Claude Sonnet 4.5采用中等检索轮次（14.38步）和中等上下文大小（每步29.74行），Pass@1最高（0.530）；而Devstral 2检索轮次最多（22.16步）但成本最高（每实例$0.91）。第五，检索到的上下文与实际使用的上下文之间存在显著差距：所有智能体都表现出明显的context usage drop（GPT-5为0.179，Gemini 2.5 Pro高达0.431），说明大量在中间步骤成功检索到的gold context最终未被用于补丁生成。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 编码智能体上下文检索评测（5个智能体，GPT-5后端，ContextBench Lite） | 文件级/块级/行级 Recall、Precision、F1 + Pass@1 | mini-SWE-agent: 文件级F1=0.634, 块级F1=0.375, 行级F1=0.312, Pass@1=0.472 | SWE-agent: 文件级F1=0.544, 块级F1=0.285, 行级F1=0.208, Pass@1=0.490; Agentless: 文件级F1=0.390, 块级F1=0.242, 行级F1=0.376, Pass@1=0.452 | mini-SWE-agent作为最简单的基线，在文件级F1上分别超过SWE-agent 16.5%和Agentless 62.6%，证明复杂框架不必然带来检索优势 |
| LLM上下文检索评测（4个LLM，mini-SWE-agent框架，ContextBench Lite） | 文件级/块级/行级 Recall、Precision、F1 + Pass@1 | Claude Sonnet 4.5: 文件级F1=0.624, 块级F1=0.420, 行级F1=0.344, Pass@1=0.530 | GPT-5: 文件级F1=0.634, 块级F1=0.375, 行级F1=0.312, Pass@1=0.472; Gemini 2.5 Pro: 文件级F1=0.600, 块级F1=0.403, 行级F1=0.311, Pass@1=0.364 | Claude Sonnet 4.5在行级F1上超过GPT-5约10.3%，Pass@1超过GPT-5约12.3%，通过平衡的检索策略实现了最优综合表现 |
| Gold Context鲁棒性验证（82个有双补丁的任务） | Jaccard相似度 | 平均Jaccard相似度=0.9518（平均距离0.0482） | 无直接基线，衡量跨语义等价补丁的标注一致性 | 高一致性证明Gold Context在解决方案多样性下仍具有可靠的评测基准价值 |
局限与改进
本文存在若干值得讨论的局限性。首先，Gold Context标注虽然经过LLM验证和交叉审查，但本质上仍是基于单一ground-truth patch的，而现实中同一issue可能存在多种合理的解决路径，不同的解决路径可能需要不同的上下文——尽管RQ5的鲁棒性分析显示Jaccard相似度达0.95，但82个样本的规模相对有限。其次，评测在ContextBench Lite（500个任务子集）上进行，而非完整的1136个任务，这可能限制了结论的统计显著性和对不同任务类型的覆盖。第三，智能体上下文追踪依赖正则表达式提取代码区域，这种方式可能无法完美捕获所有形式的上下文访问（如通过记忆或隐式推理访问的上下文），导致对智能体实际使用的上下文的估计存在偏差。第四，当前评测框架将每个任务独立处理，无法评测智能体在跨任务学习或长期记忆方面的能力。此外，评测仅覆盖8种编程语言，对于新兴语言（如Rust的某些高级特性）的覆盖可能不够充分。最后，虽然论文发现「复杂框架不一定带来更好检索」，但这一结论可能受所选智能体实现的具体调优程度影响，不同参数配置下的表现可能有所不同。
独立分析的弱点
本文存在几个值得深入分析的弱点。第一，Gold Context的验证机制虽然创新，但仅使用GPT-5作为验证LLM可能存在偏差——如果验证LLM本身在某类任务上能力不足，可能导致本应通过验证的Gold Context被误判为不充分，建议引入多个LLM进行交叉验证以提高鲁棒性。第二，任务选择的三个难度指标（agent solvability、edit scope、edit dispersion）虽然互补，但都是基于静态特征的，缺少对任务语义复杂度（如是否涉及并发、是否需要理解复杂算法逻辑）的考量，可能导致选入的任务在语义难度上分布不均。第三，评测框架对「上下文使用」的定义较为粗糙——它关注的是检索到的上下文是否出现在最终补丁中，但智能体可能通过检索某段代码获得了理解（如理解了程序的控制流），即使该代码最终未被直接修改，这种「理解性使用」在当前评测中无法被捕捉。建议引入基于注意力机制或推理链分析的更细粒度的使用度量。
未来方向
本文作者提出process-oriented evaluation和intermediate context signals作为改进LLM编码智能体的有前景方向，基于这一成果可以延伸出多个研究方向。第一，可以将Gold Context作为中间奖励信号用于强化学习训练，引导智能体学习更高效的检索策略——目前的训练大多只依赖最终任务成功作为奖励，引入过程级奖励可能显著提升训练效率。第二，可以基于ContextBench的评测结果设计自适应检索策略——例如根据任务特征（编辑范围、分散度等）动态选择检索粒度和轮次，平衡recall和precision。第三，可以扩展评测到多智能体协作场景，研究多个智能体如何分工检索不同部分的代码上下文。第四，可以将ContextBench的评测范式扩展到其他软件工程任务，如代码审查、需求分析、测试生成等，构建更全面的过程级评测体系。第五，可以研究如何利用Gold Context进行检索增强生成（RAG），在推理阶段为LLM提供更精准的代码上下文。
复现评估
本文在可复现性方面做了较好准备。ContextBench的任务来源于4个公开的issue-resolution基准，均有良好的可复现性保证。论文提供了详细的附录（Section A到H），涵盖了任务去重、任务选择、智能体上下文追踪、AST块定义、标注指南、验证协议、指标定义等实现细节。评测使用的Tree-Sitter工具是开源的，所有评测的编码智能体（mini-SWE-agent、SWE-agent、OpenHands、Agentless、Prometheus）也都是开源且活跃维护的。数据规模方面，完整基准包含1136个任务，Lite子集500个任务，标注工作由6位作者和一批专家开发者耗时4个月完成，复现标注流程需要大量人力。算力方面，评测4个LLM和5个智能体需要显著的API调用成本（论文报告每实例成本在$0.38到$0.91之间），完整评测的成本可能达到数千美元。总体而言，基准数据和评测框架的复现可行性较高，但完整的人工标注流程复现难度较大。
论文图表
