← 返回 PaperDaily 大模型与智能体

代码修复新范式：定位+诊断一起上，token省23%

这篇论文把“找 Bug”从盲猜升级成了“带诊断报告的定位”。不用训练、不用多智能体吵架，靠一个推理 LLM 加四个仓库工具，就能把定位和修复一起带飞，挺适合喜欢看智能体干活的同学。

龙哥读论文发布于 2026-08-20 00:20:06 阅读 3 查看原文

#大语言模型 #Agent #人工智能

🐉 龙哥读论文知识星球来了！
公众号每日8篇拆解不够看？星球无上限更AI领域论文、资讯、招聘、招博、开源代码，一站式干货，每日2分钟刷完即赚！
👇扫码加入「龙哥读论文」知识星球，前沿干货、实用资源一站式拿捏～ xingqiu_header

龙哥推荐理由：
这篇论文把“找 Bug”从盲猜升级成了“带诊断报告的定位”。不用训练、不用多智能体吵架，靠一个推理 LLM 加四个仓库工具，就能把定位和修复一起带飞，挺适合喜欢看智能体干活的同学。

原论文信息如下：

论文标题:
SHERLOC: Structured Diagnostic Localization for Code Repair Agents

发表日期:
2026年06月发表单位:
NVIDIA, TU Darmstadt, hessian.AI & National Research Center for Applied Cybersecurity ATHENE 原文链接:
https://arxiv.org/pdf/2606.24820v1.pdf

代码修复新利器SHERLOC：告别盲目搜索，结构化诊断精准定位Bug

如果把代码修复比成看病，那很多智能体以前的工作方式有点像“先满屋子翻抽屉，再猜病因，最后开药方”。问题是，找 Bug 的过程往往比修 Bug 还费劲。这篇论文 SHERLOC 直接把思路拧了一下：不再只给一个“可疑文件名”，而是输出带解释的结构化诊断，告诉修复智能体“哪里出问题、为什么出问题、该怎么修”。

图1：SHERLOC 总览。一个推理型大模型配合四类仓库工具和自恢复机制，先做定位，再给诊断，最后还能把这些信息喂给修复智能体，顺手把 token 也省了。

这里先解释两个关键词。LLM agent是指由大语言模型驱动、能多轮调用工具完成任务的智能体；repository-level code repair则是“仓库级代码修复”，不是改一行小代码，而是面对整个项目仓库，先找问题再打补丁。SHERLOC 的妙处就在于：它把“定位”从粗糙的文件检索，升级成了“结构化诊断”。

论文最扎眼的点有两个。第一，它不训练、不微调、不搞多智能体开会，只靠一个推理 LLM 和四个仓库工具就能把定位做得很强；第二，它不只提升定位精度，还能反过来帮助下游修复智能体少走弯路，平均让修复成功率提升 5.95 个百分点，同时减少定位和总 token 消耗。这个结果挺像什么？像是给修 Bug 的人配了一个“会思考的导航仪”，而不是只扔一张地图。

方法解读：训练无关的SHERLOC如何工作？——推理LLM+四类智能工具

SHERLOC 的名字来自 Structured Hypothesis-driven Exploration and Reasoning for Localization，中文可以理解成“面向定位的结构化、假设驱动探索与推理”。名字很长，思路很朴素：先提出假设，再用工具验证假设，最后输出诊断结论。它的核心不是“多看几眼代码”，而是“带着怀疑去看代码”。

图5：一个真实示例。输入仓库中的问题描述后，SHERLOC 不仅预测出可能修改的文件和行区间，还给出 location explanation、root cause、solution idea、dependencies、testing impact 五项结构化诊断。

先看整体流程。用户给它一个 issue 描述和仓库快照，系统先过滤掉文档、构建产物、版本控制目录这些“看了也不修 Bug”的地方，然后把项目树、问题描述和工具说明一起喂给推理模型。之后模型进入多轮循环：要么调用工具，要么继续思考，要么在证据足够时直接输出最终定位和诊断。

这里的四类工具分别是：查看文件、仓库搜索、项目树浏览、导入关系追踪。前两个负责“局部找线索”，后两个负责“全局看结构”。这套设计很关键，因为代码仓库里的 Bug 往往不是单点故障，而是文件之间、模块之间、依赖之间互相牵连。只盯着一个文件，很容易把锅甩错地方。

论文还加了一层“自恢复”机制，专门处理多轮工具调用中常见的翻车现场：上下文太长就截断，老是在同一个地方打转就提醒，工具调用格式写歪了就修复，快超出输出长度就重新提示，轮次用尽就强制总结。说白了，SHERLOC 不只是会找 Bug，还会在自己犯迷糊时把自己拽回来，多少有点“认真上班”的味道。🤨

它最终输出的不是单纯的文件名，而是一段结构化 finding。这里的 finding 可以理解成“诊断条目”，里面要说明位置为何可疑、根因是什么、解决思路是什么、会牵连哪些依赖、测试时要注意什么。对下游修复智能体来说，这比一个孤零零的路径名有用得多，因为它已经把“去哪儿看”变成了“看什么、为什么看、看完准备怎么改”。

论文还专门提到一个容易被忽略的点：SHERLOC 的定位不是靠一堆花里胡哨的训练技巧堆出来的，而是靠推理能力 + 受控工具使用。这意味着它更像一种可迁移的工作流，而不是某个仓库上“调参调到天荒地老”的定制怪兽。

实验结果：定位精度与下游修复效率双丰收，全面超越SOTA

先说结论：SHERLOC 的实验不是“只在一个角落里赢一下”，而是定位和修复两个环节都能打。它在 SWE-Bench Lite 和 SWE-Bench Verified 上都拿到了很强的文件级定位表现，而且把自己的定位结果喂给修复智能体后，修复成功率还能继续涨。这个结果很重要，因为它证明了：定位不是终点，能不能帮修复少走弯路才是关键。

图2：跨基准定位表现。左边是 SWE-Bench Lite 的文件级 accuracy@1，右边是 SWE-Bench Verified 的文件级 recall@1。SHERLOC 在两个基准上都站到了前排，且结果是多随机种子平均值。

在 SWE-Bench Lite 上，SHERLOC 最好的配置拿到 84.33% 的 accuracy@1；在 SWE-Bench Verified 上，拿到 81.27% 的 recall@1。对比之前的定位系统，这不是“挤出一点点提升”，而是相当明显的领先。更有意思的是，它在大约 30B 参数规模下也能保持很强的竞争力，说明这套方法并不是纯靠模型堆大，而是工具和推理方式真的起作用。

表3：不同 backbone 和不同基准上的完整评测。这里同时给出了文件级、chunk 级和工具交互相关指标。能看出 SHERLOC 不只是“猜对文件”，还在定位范围和工具使用效率上做了系统优化。

论文还补了一个很实用的评价视角：chunk-level metrics，也就是按行区间来评估覆盖率、精度和紧致度。这里的 chunk 可以理解成“代码片段区间”，而不是一定要落在某个函数或类里。这个设计挺合理，因为真实补丁不一定老老实实待在函数内部，有时改的是 import，有时改的是配置，有时是跨多个局部区域的联动修改。只看文件级，太粗；只看函数级，又可能错过真实编辑点。

更值得看的是下游修复实验。SHERLOC 把自己的定位和诊断信息注入到 OpenHands 和 SWE-Agent 这两类修复框架后，平均修复成功率提升 5.95 个百分点，同时定位 token 平均减少 36.7%，总 token 平均减少 23.1%。这说明它不是“看起来很聪明”，而是真的能把修复流程里的搜索成本打下来。

图3：下游修复成功率对比。每个格子都是修复成功率，蓝色越深表示效果越好。可以看到，把 SHERLOC 的诊断结果喂给修复智能体后，很多模型都能拿到更高的通过率。

图4：搜索效率提升。绿色代表用了 SHERLOC 的方案，蓝色代表基线方案。很多情况下，定位阶段 token 消耗明显下降，尤其是大模型本来就能修得不错的时候，SHERLOC 更像是在帮它们“少问几句、少绕几圈”。

图6：不同修复智能体的定位“余量”。蓝色柱子是各智能体自己定位的效果，绿色虚线是 SHERLOC 的水平。柱子离虚线越远，说明这个智能体自己找 Bug 的能力越弱，也越需要外部诊断。

这里就出现了一个很有意思的现象：不同能力的修复模型，最适合的“投喂方式”并不一样。弱一点的模型，给它完整的 SHERLOC finding 往往帮助更大，因为它自己找路能力有限；强一点的模型，如果把低质量诊断一股脑塞进去，反而可能被噪声拖累。这就像给学霸和学渣发复习资料：学渣需要清晰答案框架，学霸更怕一堆半对不对的废话。

深入分析：质量过滤是关键？不同能力模型的最佳“投喂”策略

SHERLOC 的另一个聪明之处，是它没有把所有诊断都当成“神谕”。论文专门引入了一个质量判断流程，用 GPT-5.2 作为裁判，给每条 finding 从根因正确性、位置准确性、解决方案可操作性三个维度打分。这个思路很现实：不是所有看起来像诊断的东西，都真的能帮修复。

图7：按 finding 质量分桶后的修复成功率。高质量诊断能明显提升成功率，而低质量诊断甚至会比基线更差，说明“喂错信息”也会坏事。

图8：质量阈值扫描。阈值越高，命中的 finding 越少，但成功率往往更稳。论文里发现，大约 4.5 左右是一个比较平衡的位置。

这部分实验最重要的启发是：定位质量和下游收益并不是线性关系。一条 finding 只要“看起来像对的”，并不代表它就能提升修复；真正有用的，是同时包含正确位置、正确根因和可执行修复方向的诊断。论文里还观察到，solution idea 这个字段对最终修复成功率的相关性最强，这说明下游智能体最需要的，不只是“你可能错在哪”，还要“下一步该怎么动手”。

表8：不同质量层级的代表性 finding 示例。蓝色表示预测文件和真实修改文件一致，橙色表示不一致。这个表很好地说明了为什么有些定位能直接帮修复，有些则会把智能体带沟里。

表10：质量阈值扫描结果。可以看到，阈值越严，覆盖率越低，但整体收益不一定更差，说明“宁缺毋滥”在这个任务里是成立的。

论文还做了一个很有意思的对照：如果把 SHERLOC 的定位结果换成更弱版本的结果，准确率型收益会下降，但效率型收益仍然存在。换句话说，即使定位没有做到极致，只要它能把搜索范围缩小一点，修复智能体依然能少走不少冤枉路。这也是为什么 SHERLOC 的价值不只在“答对”，还在“帮忙省脑子”。

表7：499 条被评估的 SHERLOC finding 质量分布。大部分落在高质量区间，但也有一部分明显不够稳，这正是后面需要质量过滤的原因。

创新与局限：新颖的思路与值得关注的挑战

这篇论文最值得肯定的地方，是它把“定位”从静态检索问题，变成了一个可解释、可交互、可传递的诊断过程。以前很多方法只回答“可能是哪个文件”，SHERLOC 进一步回答“为什么是它、应该怎么修”。这个变化看似只是多写了几句话，实际上对下游修复流程的帮助很大。

它的第二个创新点是训练无关。不靠额外标注、不靠专门训练、不靠多智能体互相 debate，直接用推理 LLM 和结构化工具就能做出很强的效果，这对实际落地很友好。尤其是在新仓库、新语言、新项目上，少了大量再训练成本。

不过，局限也得老老实实看。第一，SWE-Bench 这类公开仓库基准有预训练熟悉度的影响，模型可能因为“见过这些项目”而显得更会定位；论文虽然做了 masked 控制，但这个问题并没有完全消失。第二，最强结果依赖较大的推理模型，意味着实际部署的算力成本并不低。第三，质量过滤目前还是借助外部裁判模型做的，真正上线时还需要一个更便宜、更稳定的质量估计器。

还有一个现实问题：SHERLOC 的表现和 backbone 的“工具使用习惯”有关。某些模型会更积极地调用工具，某些模型则容易偷懒直接猜答案。也就是说，这套框架虽然方法上通用，但在不同模型上，提示词和交互风格还可能要稍微调一调。这个坑不算大，但绝对不是“复制粘贴就完事”。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底解决了什么问题？它解决的是仓库级代码修复里“先定位、再修复”这一步太费时、太费 token 的问题。SHERLOC 不只找文件，还给出根因和修复方向，让下游智能体少绕路。

文中的 recall@1、accuracy@1、chunk-level 这些指标是什么意思？accuracy@1 可以理解成“第一名猜对的比例”；recall@1 更强调真实目标有没有被第一名覆盖到；chunk-level 则是把代码按行区间来评估，看看预测范围和真实修改区间贴得紧不紧。

为什么论文特别强调质量过滤？因为诊断信息不是越多越好，错的诊断会干扰修复智能体。论文发现，高质量 finding 能明显提升修复成功率，而低质量 finding 甚至可能拖后腿，所以必须筛一筛、挑一挑。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆ 不是简单的“再做一个定位器”，而是把定位升级成结构化诊断，并且能直接服务下游修复，思路挺新。

实验合理度：★★★★☆ 不只看定位，还看下游修复和 token 成本，外加做了 masked 控制，实验设计比较完整。

学术研究价值：★★★★☆ 对代码智能体的工作流理解很有启发，尤其适合研究“定位—修复”协同优化。

稳定性：★★★☆☆ Demo 和基准表现都不错，但依赖大模型推理与工具调用，真实场景里还要看鲁棒性。

适应性以及泛化能力：★★★★☆ 训练无关、工具固定，跨 backbone 也能跑，泛化潜力不错。

硬件需求及成本：★★★☆☆ 最强结果依赖较大模型，省的是搜索 token，不是把算力变成空气。

复现难度：★★★☆☆ 方法本身不复杂，但要复现完整链路，仓库、模型和评测环境都得配齐。

产品化成熟度：★★★☆☆ 适合做修复辅助模块或内部工具，但离“开箱即用的工业标配”还有距离。

可能的问题：核心短板是预训练熟悉度和质量评估依赖外部裁判，若换仓库分布或新语言，效果可能需要重新校准。

主要参考文献

Tamoyan, H., Narenthiran, S., Arakelyan, E., Mezini, M., & Ginsburg, B. SHERLOC: Structured Diagnostic Localization for Code Repair Agents. arXiv:2606.24820v1, 2026.

Jimenez, C. et al. SWE-Bench: Can Language Models Resolve Real-World GitHub Issues? 2024.

Yang, J. et al. SWE-Agent. 2024.

Wang, X. et al. OpenHands. 2025.

项目与演示链接：本文未提供公开 demo 链接。

*本文仅代表个人理解及观点，不构成任何论文审核或者项目落地推荐意见，具体以相关组织评审结果为准。欢迎就论文内容交流探讨，理性发言哦～想了解更多原文细节的小伙伴，可以点击"阅读原文"，查看更多原论文细节哦！

欢迎加入龙哥读论文粉丝群，扫描下方二维码或者添加龙哥助手微信号加群：kangjinlonghelper。一定要备注：研究方向+地点+学校/公司+昵称（如图像处理+上海+清华+龙哥），根据格式备注，可更快被通过且邀请进群。
『龙哥读论文』微信群目前包含：图像处理、大模型及智能体、自动驾驶及机器人、AI医疗及AI金融5个群
这篇 SHERLOC 适合做代码修复/智能体研究的同学重点围观：先定位，再诊断，再修复，少走弯路，少烧 token。 dianzan