Agent Retrieval Bench：评估编程Agent找对文件的能力

被大多数评测忽略的关键环节

当我们谈论AI编程助手的能力时，注意力往往集中在最终生成的代码质量、能否通过单元测试、修复bug的成功率上。但一个被绝大多数评测体系刻意或无意隐藏的前置问题是：Agent在动手修改代码之前，真的找到了正确的仓库文件吗？

Agent Retrieval Bench 正是针对这一环节设计的评测基准。它把编程Agent工作流中最容易被掩盖的部分单独抽离出来——即代码检索（retrieval）阶段的准确性。用一句话概括其核心理念：在修复之前，先看它能不能找到文件（Finds The Files Before The Fix）。

为什么检索环节如此重要

现实中的代码库动辄包含成百上千个文件，一个功能的实现可能横跨多个模块。当用户提出"修复登录时的会话过期问题"这样的自然语言需求时，Agent 首先要做的不是写代码，而是定位到与该问题相关的那几个文件。

如果Agent在这一步就找错了文件，那么后续无论生成的代码多么优雅、多么符合语法规范，都是在错误的地方做无用功。这就好比让一位医生在没有确诊的情况下直接开刀——手术技巧再高也毫无意义。

传统的端到端评测（如让Agent直接跑通测试用例）存在一个盲点：它只看最终结果的通过与否，无法区分失败究竟发生在检索阶段还是编辑阶段。当一个Agent在综合评测中表现不佳时，开发者很难判断问题的根源——是它找错了文件，还是它找对了文件却写错了代码？

从技术实现角度看，编程Agent的代码检索通常依赖几种策略的组合：基于关键词的符号搜索（如grep/ripgrep）、向量嵌入相似度搜索（将代码片段转化为语义向量后做近邻查询），以及利用语言服务器协议（LSP）进行符号引用跳转。不同策略各有盲点——关键词搜索容易遗漏语义相关但命名不同的文件；向量搜索在代码领域的嵌入质量参差不齐；LSP依赖正确的项目配置才能生效。真实代码库中往往还存在跨语言调用、动态加载等情况，进一步增加了定位的难度。这些技术挑战正是检索环节值得被单独度量的根本原因。

Agent Retrieval Bench 的差异化价值

Agent Retrieval Bench 的设计思路在于隔离变量。通过将检索能力从完整的编程工作流中独立出来单独考察，它为诊断Agent的短板提供了更精确的工具。

更透明的能力拆解

把"找文件"和"改文件"两个环节解耦评估，意味着开发者能够回答此前难以回答的问题：某个模型在代码理解和定位上是否具备足够的空间感知能力？它对代码库结构的把握是否准确？这种拆解为模型的针对性优化提供了明确方向。

暴露评测中的"隐藏项"

原文特别指出，这一部分是"大多数评测隐藏的"（most evals hide）。这个措辞值得玩味——它暗示当前主流的编程Agent评测体系存在系统性的盲区。当整个行业都在用端到端成功率来标榜自家Agent的进步时，检索准确率这一关键指标却长期缺席。Agent Retrieval Bench 的出现，某种程度上是对这种评测惯性的一次纠偏。

目前主流的编程Agent基准（如SWE-bench）采用端到端评测模式：给定一个GitHub issue，Agent自主操作代码仓库，最终以能否通过该issue对应的测试用例作为唯一评判标准。这种设计的优点是贴近真实场景，但代价是将"理解需求→定位文件→修改代码→验证结果"的完整链路压缩为一个通过/失败的二元信号。研究人员已观察到，在SWE-bench上失败的案例中，相当一部分根源在于Agent修改了无关文件而非真正相关的模块，但这一信息在最终评分中完全消失。Agent Retrieval Bench 的定位因此与SWE-bench形成互补，而非竞争关系。

对开发者与研究者的意义

对于正在构建或选型编程Agent的团队而言，检索能力的独立评估提供了一个更细粒度的决策依据。一个在检索环节表现优异的Agent，即便当前的编辑能力尚有不足，也更具备优化潜力——因为定位问题往往比修复问题更难自动化。

对研究者来说，这类专项评测有助于推动Agent架构的模块化设计。当检索与编辑被明确区分后，研究可以更聚焦于改进代码库理解、上下文管理和相关文件排序等具体技术点。

结语

Agent Retrieval Bench 的核心贡献并非提出全新的技术，而是重新定义了我们评估编程Agent的视角。它提醒整个行业：在追求代码生成质量之前，先要确保Agent站在了正确的起跑线上。找对文件，是修好代码的前提，也是最容易被忽视的第一步。

受限于目前公开的信息，关于该基准的具体测试方法、覆盖的编程语言、参与评测的模型及其得分等细节尚待进一步披露。但其提出的问题本身，已经足以引发对现有Agent评测范式的反思。