🤖 machine learning

Probe-and-Refine Tuning of Repository Guidance for Coding Agents

本文介绍了“探测-优化微调”（probe-and-refine tuning）方法，该方法通过使用合成缺陷修复探测器来迭代优化仓库引导文件（AGENTS.md），通过扩大可评估补丁的覆盖范围而非提高单补丁精度，从而显著提升编码智能体在 SWE-bench Verified 上的性能。

原作者： Asa Shepard, Jeannie Albrecht

发布于 2026-06-19

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Asa Shepard, Jeannie Albrecht

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你雇佣了一位才华横溢但缺乏经验的学徒来修理一座巨大的、古老的图书馆（代码仓库）。这位学徒足够聪明，能读懂书并修复破损的页面，但他并不知道这座图书馆的秘密规则：哪一个书架存放着珍贵的地图，如何在不吵醒睡觉中的猫的情况下向管理员寻求帮助，或者哪些梯子是安全的。

由于缺乏这些“本地知识”，学徒会漫无目的地游荡，爬错梯子，或者试图在错误的区域修理书籍，并在过程中弄坏东西。

这篇论文介绍了一种名为**“探测与精炼微调”（Probe-and-Refine Tuning）**的方法来解决这个问题。以下是其工作原理，使用简单的类比说明：

问题所在：“一刀切”的手册

工程师们经常为他们的 AI 编程智能体编写一份“小抄”（比如一个 AGENTS.md 文件）。

旧方法（静态知识）： 他们要求一个聪明的 AI 写一份通用的手册：“修复前务必检查索引，”或“寻找主入口点。”这就像是给学徒一张全世界所有图书馆的地图。这很有用，但它没有告诉他们这个特定图书馆的秘密藏宝处在哪里。
结果： 学徒表现尚可，但仍然经常迷路。

解决方案：“试错型”教练

作者创建了一个名为 Probe-and-Refine 的新流程。与其只是写一次手册，不如将手册视为一份通过犯错来进行训练的“活文档”。

把它想象成教练训练新球员的过程：

探测（演练）： 教练针对这个特定的图书馆生成 10 个虚构的、编造的问题（探测）。
尝试： 学徒尝试使用当前的手册来解决这些虚构问题。
诊断： 教练观察尝试过程。“噢，你试图修理厨房里的水管，但水管其实是在地下室。而且你忘了先检查蓝图。”
精炼： 教练立即更新手册，加入一条具体的规则：“对于这座图书馆，水管在地下室，并且务必先检查蓝图。”
重复： 他们这样做 3 到 5 次。手册从一份通用的指南进化成了一份超具体的、“内部人士级别”的指南。

至关重要的一点是，整个训练过程并不需要智能体去修复真实的 Bug。 这是一个模拟循环，AI 编写手册，在虚构问题上测试它，并根据结果修正手册。

他们的发现

研究人员在著名的编码基准测试（SWE-bench）上进行了四轮测试。结果如下：

没有指南： 学徒解决了 25.5% 的问题。
通用指南： 学徒解决了 28.3% 的问题。
Probe-and-Refine 指南： 学徒解决了 33.0% 的问题。

核心奥秘：在于找到正确的门，而不是更擅长修理
你可能会认为改进后的手册让学徒变得更“聪明”了，或者更擅长修理东西了。事实并非如此。

当学徒确实修复了某个东西时，无论他们使用哪种手册，修复质量都是完全一样的（成功率约为 59%）。
真正的魔力在于“覆盖率”。 改进后的手册帮助学徒更频繁地找到了要修复的正确文件。
- 类比： 通用手册让学徒敲了 100 扇门，但其中只有 40 扇是正确的；而精炼后的手册让学徒敲了 100 扇门，其中有 56 扇是正确的。一旦他们找到了正确的门，他们修理锁的能力是一样的。

“步骤预算”陷阱

论文还发现，只有当你给学徒足够的时间时，这份指南才会奏效。

如果你只给学徒 25 个步骤来解决问题，那花哨的手册就毫无帮助。他们没有时间去遵循复杂的指令。
如果你给他们 200 个步骤，这份花哨的手册就会大放异彩。它告诉他们一个需要时间但行之有效的流程（复现 -> 追踪 -> 修复）。如果没有这份手册，他们只会匆忙应对并最终失败。
类比： 如果你告诉某人，“走风景优美的路线以避开拥堵”，但只给了他们 5 分钟去上班，他们只会迷失方向。你需要给他们足够的时间去走那条风景优美的路线。

“模型不匹配”警告

最令人惊讶的发现是，这份指南并不通用。

他们尝试使用在一款 AI 模型（Qwen）上训练的指南，去驱动另一款稍弱的 AI 模型（Nemotron）。
结果： 第二个模型崩溃了。它被过于具体的指令搞糊涂了，以至于完全无法工作。
类比： 这就像是给一位驾驶慢速旧轿车的司机一份详细的高速赛车手册。指令对于这辆车来说太复杂了，导致司机不知所措。指南必须针对阅读它的“大脑”（模型）进行专门的“调优”。

总结

这篇论文证明了如何编写指令比仅仅拥有指令更重要。
通过使用一个简单的循环——“制造一个虚构问题，尝试解决它，并根据失败情况修正指令”——你可以将一份通用的指南变成一份专业的专家手册。这并不会让 AI 更擅长修复代码；它只是防止 AI 在错误的地方寻找，从而让它能够发挥出解决问题的全部潜力。

技术摘要：针对代码智能体仓库引导的“探测与精炼”微调

问题陈述

基于大语言模型（LLM）的代码智能体经常无法解决软件工程任务，这并非由于其推理能力不足，而是因为它们缺乏关于特定代码仓库的高层操作性知识。这种隐性知识——例如子系统边界、测试执行工作流以及历史调试模式——很少在代码本身中体现。虽然工程师会维护上下文文件（如 AGENTS.md）来提供这些信息，但近期的文献对这些文件的有效性提出了相互矛盾的证据：一些研究表明它们能提高效率，而另一些研究则指出，如果引导过于泛泛或具有反作用，则会降低解决率。核心问题在于，目前尚不清楚失败的原因在于“引导”这一概念本身，还是在于“如何生成”此类引导。当前的方法通常依赖单次生成的 LLM，这会导致生成的建议过于宽泛，而非智能体所需的特定且基于失败反馈的操作策略。

方法论

本文引入了探测与精炼微调（Probe-and-Refine Tuning），这是一种轻量级程序，旨在通过合成缺陷修复探测任务来迭代诊断并修补仓库的引导文件。该程序不同于标准的智能体循环，因为它完全依赖于单次调用（single-shot）LLM，在微调阶段不使用任何工具或强化学习。

微调循环

该过程通过 3–5 次迭代，将静态、通用的知识库转化为专门的操作性引导：

生成探测任务：系统从仓库代码库中生成一批 10 个合成缺陷修复任务，目标涵盖多样化的子系统。
尝试修复：对于每个探测任务，通过单次调用 LLM，尝试利用当前的引导产物生成补丁。
评判尝试结果：通过另一个单次调用评估尝试的解决方案是否符合预期行为（例如：强修复、部分修复或缺失修复），并针对识别出的不足之处提出具体的引导文件修改建议。
聚合与应用：最后一次调用负责聚合来自所有探测任务的诊断结果，并提出一套整合的修改方案。这些修改被机械地应用于引导文件（执行插入、修改或加强特定章节），字数上限为 3,000 字符。

如果引导内容趋于稳定（连续两次迭代间无变化），则提前终止循环。最终生成的产物随后用于在 SWE-bench Verified 评估阶段引导标准的 ReAct 式代码智能体。

实验设置

作者使用 Qwen3.5-35B-A3B 模型，在 500 个 SWE-bench Verified 实例上进行了四次独立试验，评估了三种条件：

无上下文（No Context）：智能体在没有任何仓库特定引导的情况下运行。
静态知识库（Static KB）：智能体使用一个包含结构化数据（通过 tree-sitter 解析）和通用、与仓库无关的最佳实践的两层知识库。
探测与精炼（Probe-and-Refine）：智能体使用通过上述迭代微调程序生成的引导。

作为次要实验，作者更换了模型为 NVIDIA-Nemotron-3-Nano-30B-A3B 以测试跨模型泛化能力，并进行了步数预算（step-budget）扫描（25, 50, 100, 200 步）以分析引导与智能体预算之间的交互作用。

关键结果

性能提升

在四次试验中，探测与精炼实现了 33.0% 的平均解决率，显著优于 静态知识库（28.3%）和 无上下文 基准（25.5%）。这种提升在两种对比中均具有统计学显著性（ $p < 0.001$ ）。该程序还产生了 31 个一致的独特解（在 4 次试验中解决了 $\ge$ 3 次），而其他两种情况均无法解决这些问题。

机制：覆盖率 vs 精确度

论文通过分解性能增益来确定引导是如何发挥作用的：

覆盖率：性能提升的主要驱动力是评估覆盖率。探测与精炼引导使智能体能够为 56.2% 的实例生成格式良好的、可评估的补丁，而未引导基准仅为 41.7%（差距为 14.5 个百分点）。
精确度：在补丁可被评估的前提下，补丁的正确性在所有条件下保持统计学上的一致（ $\sim$ 59%, $p = 0.119$ ）。
结论：引导并未提高智能体所做代码更改的质量；相反，它帮助智能体定位到正确的文件，并生成一个评估框架可以接受的补丁。引导有效地降低了格式错误补丁或在断言检查前导致测试套件崩溃的补丁比例。

步数预算与工作流

研究发现，引导充当了步数预算效用的调节变量。

无引导智能体会迅速达到饱和；将步数预算从 25 增加到 200 步并不会提高其解决率，因为它们缺乏将额外步骤转化为更好补丁的结构化计划。
探测与精炼智能体能高效利用更大的预算。所规定的“重现-追踪-修复”工作流需要更多步骤才能完成。因此，在更高的预算（100 和 200 步）下，探测与精炼条件表现出了显著的收益，而简单的引导（静态知识库）在此阶段已进入平台期。

跨模型泛化

当应用于 Nemotron 模型时，结果凸显了关键的模型拟合依赖性：

微调失败：微调循环在 Nemotron 上表现下降，因为该模型无法在“评判”步骤中生成足够具有诊断性的输出，导致循环停滞。
负迁移：在 Qwen 上微调的引导应用于 Nemotron 时，主动导致了智能体性能坍塌（解决率为 13.2%，而 Nemotron 自身的基准为 27.0%）。详细且指令性的引导导致 Nemotron 进入了“通过分析进行合规”（即编写关于它要做什么的散文，而非执行命令）的状态，从而引发了一连串的失效。
精确度恒定：即使在跨模型坍塌的情况下，那些确实产生的补丁的精确度依然保持不变，这进一步证实了失败完全在于覆盖率（智能体未能产生补丁），而非补丁本身的质量。

意义与主张

论文声称，指令质量是代码智能体可靠性的第一阶变量，其重要程度与模型能力或步数预算的选择相当。

操作性知识是可学习的：作者证明了操作性知识（哪些文件承载哪些子系统、如何运行测试）可以从合成失败中提炼成紧凑的文本产物，而无需复杂的智能体循环或工具使用。
瓶颈在于引导，而非推理：结果表明，对于许多“困难”实例，智能体的失败并非缺乏推理能力，而是无法将问题定位到正确的文件。引导起到了定位辅助的作用，使智能体能够有效地导航仓库结构。
模型特定的校准：引导不是可迁移的仓库知识，而是针对特定模型的行为校准。针对一种模型的失败模式进行微调得到的引导，可能会对具有不同行为特征的其他模型产生负面影响。
调和先前的分歧：论文通过展示引导的有效性取决于如何生成它（迭代精炼 vs 单次生成）以及步数预算，从而调和了关于 AGENTS.md 文件功效的冲突文献。静态、通用的引导可能是中性的或有害的，而迭代精炼、面向工作流的引导则是受益的，前提是预算允许该工作流完成。

作者总结道，对于拥有高问题量的仓库，投资于迭代精炼的引导是值得的，前提是引导是在将要消费它的特定模型上进行微调，并且步数预算足以支持所规定的工作流。