编辑：LRST
ContextBench首次从「过程」评测代码智能体，不再只看是否修好代码，而是追踪它是否精准找到并真正使用了关键代码片段，揭示了当前模型多读少用、被关键词误导、复杂架构无效等深层问题，推动AI助手向更可靠、可解释的方向进化。
在自动化软件工程（Automated Software Engineering）领域，以SWE-bench为代表的评测基准已成为衡量大语言模型代码能力的事实标准，SWE-bench、SWE-bench Pro、Multi-SWE-bench、SWE-PolyBench等代码库级评测推动了代码智能体快速进步。
然而，这类评测仍以最终修复成功率为核心，主要关注端到端成功率（End-to-End Success Rate），即Agent是否能够生成通过测试用例的补丁。
这一评价方式隐含着一个关键缺陷：它仅观察最终结果，却无法刻画模型的中间推理过程，难以量化「过程中是否检索到解决问题必需的上下文、是否真正把它用进补丁」
换言之，我们无法判断Agent是真正理解了代码库的语义结构，还是通过试探式修改或偶然匹配测试条件而得到正确结果。
因此，现有评测更接近于「结果可验证」，而非「过程可解释」。
为了填补这一空白，来自南京大学、伦敦大学学院（UCL）等机构的研究团队推出了首个面向过程的代码上下文检索评测基准ContextBench，基于1,136个真实问题修复任务（66个代码库、8种语言），由专家在文件/代码块/行号三个粒度标注「关键上下文」，并自动追踪智能体的检索与阅读轨迹进行结构化对齐，用召回率、准确率、F1、效率与「使用衰减」等指标，把「找上下文」和「用上下文」拆开评估。
论文链接：https://arxiv.org/abs/2602.05892
项目主页：https://contextbench.github.io/
代码仓库：https://github.com/EuniAI/ContextBench
数据集：https://huggingface.co/datasets/Contextbench/ContextBench
ContextBench并非直接构造新的编程任务，而是从真实开源仓库的 Issue 与补丁出发，逆向追踪问题修复过程中实际依赖的代码片段，并将其组织为评测用的「黄金上下文」。评测的核心由「是否修复成功」转变为「是否定位到正确代码」
ContextBench不再只问「修好了吗？」，而是追问：「在解决问题时，Agent究竟检索并使用了哪些代码上下文？」
研究人员观察到几条典型现象：复杂的智能体脚手架不一定带来更好的上下文检索质量，反而像一种「苦涩的教训」(The Bitter Lesson)式的过度工程化；
很多最强大模型倾向「多捞少漏」，导致噪声偏多；
「检索到」不等于「用到了」，看过关键代码也可能没体现在最终补丁里；更均衡的检索策略往往在成功率与成本之间更划算。
ContextBench希望为代码智能体提供可观测、可度量、可优化的过程评测视角，帮助社区更精准地改进检索与推理链路。
「黄金上下文」由人类专家认证
为了构建这一基准，研究团队并没有依赖自动化生成，而是采用了一套严谨的「人机回环」（Human-in-the-loop）标注流程。
大规模覆盖：包含来自66个真实代码仓库的 1,136个 问题解决任务，覆盖 Python、Java、C++、Go、Rust、JavaScript、TypeScript、C 等 8种主流编程语言。
专家级标注：每一条数据都配有由专家开发者标注的「黄金上下文」（Gold Contexts）。这些上下文并非「相关代码」的简单集合，而是问题修复过程中不可或缺的最小代码依赖集。研究者通过分析真实补丁，沿函数调用、类引用与变量依赖关系逐步回溯，最终确定必须阅读的代码片段。
一个真实仓库中的依赖链条：若未阅读箭头所连接的函数与类，即使模型生成补丁，也难以保证语义正确
细粒度追踪：评测框架能够记录Agent的每一步操作轨迹，并在文件（File）、代码块（Block）、行（Line）三个层级上计算检索的精确率（Precision）和召回率（Recall）。这意味着模型的行为可以被量化为「定位能力」：不仅判断是否访问了关键文件，还能判断是否精确定位到关键函数乃至关键语句。
评测对象
顶尖模型与主流Agent
研究团队使用CONTEXTBENCH评测了当前最强的4款LLM和5种主流代码Agent框架：
LLM：GPT-5, Claude 4.5 Sonnet, Gemini 2.5 Pro, Devstral 2
Agent框架：SWE-agent, OpenHands, Agentless, Prometheus, mini-SWE-agent
各个LLM的表现情况如图所示，该排行榜将在主页上持续更新
代码Agent的「苦涩教训」
实验结果揭示了当前LLM和Agent在代码检索上的三大痛点：
1. 架构越复杂，效果越好？未必！
通过分析排行榜数据可以发现，复杂的 Agent 架构在上下文检索性能上带来的增益微乎其微。
实验显示，复杂的检索脚手架——比如基于图的检索或复杂的向量库——在检索成功率上，甚至有时还不如简单的基准方案（如 mini-SWE-agent）。这再次印证了 AI 领域的「苦涩教训」：复杂的工程堆砌，往往不如底层模型能力的提升。
不同Agent框架在检索F1分数上的差异远小于预期，复杂检索结构并未带来显著收益
对比不同Agent架构在不同层级检索上的成功率，数据表明复杂架构并未拉开显著差距
2. 宁滥勿缺：模型偏爱高召回率
所有的LLM在检索策略上都表现出惊人的一致性：重召回，轻精确。模型倾向于阅读大量的代码以确保覆盖相关信息，但这引入了大量的噪音。例如，GPT-5虽然召回率很高，但引入的无关代码严重拖累了精确率。这也解释了为什么更高昂的Token消耗并没有线性转化为解决率的提升。
从精确率与召回率的对比可以看到，多数模型倾向于扩大检索范围以避免遗漏，但代价是大量无关上下文被引入，从而干扰后续推理
数据展示了各模型Recall极高、Precision极低的「偏科」现状，精确率普遍偏低
3. 策略分化：GPT-5「大口吞」 vs Devstral 2「小步跑」
不同模型在检索策略上展现出了截然不同的性格 。
GPT-5 倾向于「少次多量」，平均只需 5.87 轮检索，但每一步会阅读高达 119 行代码，试图一次性获取大量信息 。
Devstral 2 则采取「多次少量」的策略，平均需要进行 22 轮检索，但每一步仅读取约 12 行代码 。
这种高频交互导致 Devstral 2 的Token消耗激增，成为成本最高的模型
4. 致命的「关键词陷阱」：Agent 容易陷入局部视野
通过对失败案例的分析，研究者发现Agent极易被表面关键词误导，从而陷入「隧道视野」（Tunnel Vision）。
案例：在修复一个涉及Django多数据库（MySQL/SQLite）的 Bug 时，OpenHands因为搜索结果中大量出现MySQL相关关键词，就固执地将排查范围锁定在 MySQL 模块 。
后果：尽管Agent拥有查看整个代码库的权限，但关键词的干扰使其完全忽略了真正出问题的SQLite模块，导致结构性的检索失败 。
5. 「读了」不等于「用了」
这是一个更为致命的问题：检索与利用之间存在巨大鸿沟。轨迹分析显示，Agent经常在中间步骤成功检索到了「黄金上下文」，但在最终生成补丁时，却未能有效利用这些信息，导致修复失败。
这种「过目即忘」的现象（Information Consolidation Bottleneck）是当前Agent推理能力的一大短板。轨迹分析进一步表明，模型在中间步骤能够访问到黄金上下文，但在最终生成补丁时未能有效利用这些信息，即「检索成功但推理失败」。
总结
ContextBench的发布，标志着代码Agent的评测进入了「过程可解释」的新阶段。
该工作表明，端到端成功率不足以刻画代码Agent的真实能力。未来的代码Agent不仅需要具备代码生成能力，更需要具备稳定且精确的代码定位能力。只有当Agent能够精准地定位、检索并有效利用代码上下文时，它们才能真正成为开发者值得信赖的助手。
联丰配资提示：文章来自网络，不代表本站观点。
