研究发现AI编码代理常漏掉关键代码行
The Decoder··作者 Jonathan Kemper
关键信息
该基准将搜索阶段与补丁生成阶段分开衡量，避免最终是否修复成功掩盖中间失败。研究还发现，多余的无关上下文通常比缺失上下文的危害更小，而且更强的语言模型也无法消除这种行级别的差距。
资讯摘要
文章介绍了 SWE-Explore，这是一项新的基准，用来揭示 AI 编码代理在真正修复 bug 之前，代码搜索能力到底有多强。与以往只看最终是否修复成功的评测不同，这个基准把搜索阶段单独拿出来，要求代理在读到 bug 描述和软件项目后，返回一个按相关性排序的代码片段列表。研究团队用 203 个开源项目中的 848 个问题构建了数据集，覆盖 10 种编程语言。为了定义哪些上下文真正重要，他们参考了至少两次成功解决这些问题的强模型结果，包括 GPT-5.4、Gemini 3 Pro、Claude Sonnet 4.6 和 Kimi K2.6。
随后，团队从这些成功运行中提取模型实际查看过的文件和代码行，把多个独立解法都指向的内容视为有用上下文的信号，并再经过验证与人工复核。结果显示，通用型编码代理通常能找到正确文件并把它排得很靠前，但在真正相关的代码行上，平均只能覆盖 14% 到 19%。研究还发现，即使换用更强的模型，也不能解决这个问题，因为文件级命中率始终明显高于行级覆盖率。相比之下，专门的 CoSIL 系统表现更好，因为它把代码看作彼此关联的构件，而不是孤立的文本块，这说明未来的编码代理可能需要更好的定位方法。
资讯正文
AI 编码智能体能找到正确的文件，却找不到真正关键的具体代码行，研究显示
要点
- 新的 SWE-Explore 基准将 AI 编码智能体的搜索阶段与实际修 bug 过程分开评估。此前的测试通常只衡量修复的最终结果。
- 强大 AI 模型的成功解法被用作参考。结果显示，尽管智能体往往能找到正确的文件，但在行级别平均只捕捉到 14% 到 19% 的相关代码。
- 只有当模型识别出至少一半所需代码行时，修复通常才会成功。缺失上下文的伤害大于额外无关代码，因此未来系统需要更广泛地阅读，而不是更激进地筛选。
一项新的基准将代码搜索与实际修复过程分开，暴露了 AI 编码智能体的一个隐藏弱点：它们能找到大致正确的区域，却会错过最关键的地方。
到目前为止，AI 编码大多是按结果来评判的。智能体有没有修好 bug？这一个指标掩盖了真正出错的环节。也许智能体根本没有读取相关代码；也许它看到了正确文件，却仍然写出了错误补丁。不管怎样，结果看起来都一样。
一个包括上海交通大学在内的国际研究团队正在用 SWE-Explore 解决这一盲点。这个基准只评估流程的第一阶段。智能体接收一段 bug 描述和一个软件项目，然后返回一个它认为相关的代码段排序列表。
成功运行用来设定参考标准
弄清楚哪些代码段真正重要，几乎不可能靠人工完成。因此，研究团队采用了另一种方法。对于数据集中的 848 个问题，每个问题至少都有来自强大模型的两次成功解法尝试，例如 GPT-5.4、Gemini 3 Pro、Claude Sonnet 4.6 或 Kimi K2.6。
研究人员从这些运行中提取出 AI 在修复 bug 之前实际查看过哪些文件和代码行。多个独立解法路径共同指向的片段，被视为有用上下文的信号。它们并非绝对必需，但具有强烈指示意义。随后，单独的验证步骤会补全各个关键片段，团队再对每个区域进行人工复核。
该数据集来自 203 个开源项目，涵盖 10 种编程语言。Python 占主导，共有 547 个任务，占 848 个任务的大头，其后是 Go、JavaScript 和 Rust。
关键词搜索几乎只比碰运气好一点
研究将传统搜索方法与五种通用编码智能体进行对比，其中包括 Claude Code、Codex 和 OpenHands，另外还有四个专门为代码搜索构建的研究系统。
老式关键词搜索几乎只比碰运气好一点。作者在一个案例研究中解释了原因。像“RuntimeWarning on Overflow”这样的 bug 描述，里面的术语在项目的模板和文档中出现的频率，远高于在实际源代码中出现的频率。AI 智能体之所以明显更占优势，是因为它们会一步一步地搜索项目，而不是一次性对所有命中结果进行排序。
行级准确率断崖式下滑
在文件层面，这些代理表现得相当不错。它们能找到正确的源文件，把它排在较前的位置，并且将选择范围保持得很窄。可是一旦测试缩小到代码中的具体行，系统就崩了。通用编码代理真正覆盖到的关键代码行只有 14% 到 19%。
把更强大的语言模型扔进来并不能解决问题。研究团队用来自 OpenAI、Anthropic、Google、Moonshot 和智谱的六种不同模型运行了同一个代理。GPT 系列表现领先，但整体模式并没有改变。文件命中率始终明显高于实际的行级覆盖率。
不同的代理架构之间差距惊人地小。Claude Code、Codex、OpenHands、Mini-SWE-Agent 和 AweAgent 在每一项指标上的得分几乎都一样。
CoSIL 研究系统则是个异类。它把代码视为一个由相互连接的构件组成的网络来扫描，因此实现了高得多的行级覆盖率。在这些专门的定位系统中，AutoCodeRover 定位准确但比较保守，而 OrcaLoca 噪声很少，却遗漏了很多相关位置。
修复在最低上下文阈值以下会失败
在一项受控消融实验中，团队人为调整了上下文。修复模型看到的核心区域比例分别只有 0%、25%、50%、75% 或 100%，有时还会混入无关的非核心代码。对于数据集里较容易的任务，出现了明显的阈值效应。只要必要核心区域的可见比例不到一半，修复大多都会失败。
成功率只有在覆盖率从 50% 跳到 75% 之间才会明显上升。修复并不是逐步变好的；它们需要达到最低限度的线索，才会真正“开窍”。对于更难的任务，这种效应要窄得多。如果问题本身已经超出了模型能力，即便上下文更好，也帮不上太多忙。
一旦关键位置可用，无关的额外代码几乎不会造成干扰。阅读得太少的代理，表现比读得太多的更差。对未来改进而言，结论很明确：少过滤，多阅读。代码和数据可在 GitHub 和 Hugging Face 上获取。
大约两年前，一个研究团队创建了 SWE-bench，这是一个用真实 GitHub issue 报告来测试 AI 编码代理的基准。随后又衍生出一整套变体，涵盖更多语言、更干净的数据以及更困难的专业任务。不过最近，这一基础成功指标正从多个方向受到挑战。研究机构 METR 的一项研究发现，项目经理会拒绝自动评审器接受的大约一半解决方案，其中许多是因为基本的功能性错误。
来源与参考