Agentic Rubrics as Contextual Verifiers for SWE Agents

发表时间: 2026-01 · arXiv:2601.04171 (Scale AI)

原文: https://arxiv.org/abs/2601.04171

作者：Mohit Raghavendra$^{1,*}$, Anisha Gunjal$^{1,*}$, Bing Liu$^1$, Yunzhong He$^1$
机构：$^1$Scale AI
联系方式：[email protected] | https://scale.com/research/agenticrubrics

速读

一句话结论 提出 Agentic Rubrics 方法，通过专家智能体主动交互代码库生成细粒度规则清单并在评估时免代码执行打分，在 SWE-Bench Verified 基准上显著超越基于测试执行与补丁分类的基线验证器。

要解决什么问题 软件工程智能体在强化学习训练与推理期并行采样测试时缩放（Test-Time Scaling）时，高度依赖验证器选出正确补丁；原有基于代码执行的测试验证由于需要逐实例配置沙箱环境而开销高昂且难以扩展，且生成的测试用例常存在判别力有限、测试脆弱甚至毒性问题；而免执行的替代方案（如基于问题的补丁分类器或启发式方法）缺乏对代码库深层上下文的锚定，容易依赖表层特征导致判定不可靠且缺乏可解释性，仅凭问题描述起草的评分规则往往由于缺失具体代码接口和约束而过于模糊。

怎么做的 核心思路是将“深入代码库理解上下文”与“补丁验证打分”解耦为两阶段流水线：在规则生成阶段，让专家智能体先进入沙箱仓库探索交互，生成具象化的评分清单；在验证打分阶段，直接使用语言模型裁决器对候选补丁逐项免执行打分，既具备代码库上下文深度，又规避了多候选补丁重复运行环境的高昂代价。整个方法由两个关键环节构成：

  1. 具身规则生成：基于 SWE-Agent 脚手架，专家智能体（如 Claude Sonnet-4.5）通过仓库导航、文件检索和终端命令检查调用链与契约约束，生成一份结构化的 rubrics.yaml。规则清单涵盖四大正交维度：文件变更（校验修改局部性与充分性）、规格对齐（校验是否满足问题需求）、完整性（防作弊与卫生约束，如禁止弱化测试或大范围重构）以及运行时（推断运行行为与回归安全）。每个细则项定义为一个二元组 $(t_i, w_i)$，其中 $t_i$ 为自然语言描述，$w_i \in \{1, 2, 3\}$ 为重要性权重。
  2. 免执行规则打分：针对待评估补丁，语言模型裁决器仅输入问题描述、补丁与细则，为每个细则输出二值评分 $s_i \in \{0, 1\}$，并按加权平均公式计算最终标量得分：

    $$S = \frac{\sum_{i} w_i s_i}{\sum_{i} w_i}$$


    随后根据综合得分 $S \in [0, 1]$ 对全部采样补丁重新排序，选出最优解。这种显式分解将原本非黑即白的测试结果转化为密集的连续梯度，能准确识别部分完成的代码。

效果如何 实验在 500 个任务的 SWE-Bench Verified 上开展，固定生成模型生成 16 条轨迹，使用 4 节点共 32 张 H100 GPU 运行微调实验；对比基线涵盖两类路线：无伪制品的非智能体基线（Self-Consistency、Patch Classifier）与依赖交互生成伪制品的智能体基线（Agentic Tests 生成独立测试脚本并执行、Agentic Patch Similarity 生成参考补丁算相似度）。在 Best@16 设置下，当生成模型为 Qwen3-32B 时，Agentic Rubrics 达到 40.6% 解决率，领先最强非智能体基线 Patch Classifier 达 3.5 个百分点，领先 Agentic Patch Similarity 达 5.6 个百分点；当生成模型为 Qwen3-Coder-30B-A3B 时，达到 54.2% 解决率，领先最优基线至少 4.0 个百分点。单实例总开销（制品生成加 16 次打分）仅为 0.293 美元，显著低于测试生成路线的 0.515 美元与补丁相似度路线的 0.736 美元。局限与代价在于：高度依赖规则生成智能体的能力，弱模型生成规则容易格式解析失败或数量不足；在测试通过但规则不给分的低一致性案例中，仍有 46% 属于规则过度限定实现细节或规则规格冲突的低效用判定；此外，当前仅在推理期重排序评估，直接接入强化学习训练时仍面临奖励黑客攻击与信用分配难题。

主要贡献

在软件工程（SWE）智能体领域，验证（Verification）是提升智能体能力的关键枢纽：它既为强化学习（RL）提供可验证的奖励信号，又能在推理阶段通过测试时扩展（Test-Time Scaling, TTS）采样多个候选方案并重排序以实现性能增益。然而，现有的验证机制面临严峻瓶颈：基于代码执行的验证（如单元测试）受制于沙箱初始化与依赖配置的巨大开销，且测试往往稀疏或存在脆性；基于非执行的替代方案（如补丁分类器或启发式相似度匹配）虽然轻量，却极度缺乏代码仓库上下文感知能力，难以解释且易受浅层表征影响。

为解决上述挑战，本文提出了 Agentic Rubrics 框架。该框架将验证过程解耦为两个阶段：首先由专家智能体主动交互并探索沙箱化代码仓库，提炼出紧密结合上下文的结构化评分细则（Rubric Checklist）；随后，在验证阶段，候选补丁无需进行任何代码执行即可直接依据该评分细则由大语言模型裁判完成细粒度打分。

图1：Agentic Rubric 工作流示意图。左侧为细则生成阶段：细则智能体使用仓库工具检查代码库和 PR 描述，生成组织为四大维度的 rubric.yaml；右侧为验证阶段：SWE 智能体提出候选补丁，直接对照细则打分，输出无需代码执行的验证得分。
图1：Agentic Rubric 工作流示意图。左侧为细则生成阶段：细则智能体使用仓库工具检查代码库和 PR 描述，生成组织为四大维度的 rubric.yaml；右侧为验证阶段：SWE 智能体提出候选补丁，直接对照细则打分，输出无需代码执行的验证得分。

本文的核心贡献概括如下：

  1. 提出 Agentic Rubrics 验证范式：构建了一种基于代码仓库上下文接地的结构化评分细则生成方法，在生成细则后执行免运行（Execution-free）评分，兼具环境感知能力与极高的推理与训练扩展效率。
  2. 在 SWE-Bench Verified 上实现显著的测试时扩展增益：在并行测试时扩展（Parallel TTS, $K=16$）评测中，Agentic Rubrics 在 Qwen3-Coder-30B-A3B 上达到 $54.2\%$ 的 Best@16 解决率，在 Qwen3-32B 上达到 $40.6\%$，相较于对比实验中最强基线分别取得了 $+4.0$ 与 $+3.5$ 个百分点的显著提升。
  3. 深入揭示细则验证的机理与超额效用：通过对评分对齐性与效用（Utility）的系统审计，证实 Agentic Rubrics 不仅与真实测试（Ground-Truth Tests）高度对齐（ROC-AUC 达 $0.886$），而且在测试通过的情况下仍能精准识别测试集未覆盖的潜在缺陷（如根因遗漏、边缘情况缺失及不必要修改）。
  4. 验证了向开源小模型蒸馏的可行性：证明了专家模型的智能体细则生成能力能够被监督微调（SFT）并蒸馏至如 Qwen3-32B 的开源模型中，其效果大幅优于传统补丁分类器的微调范式，为低成本大规模部署提供了工程支撑。

背景知识与设计原则

SWE 智能体验证机制的现状与瓶颈

验证机制的双重核心价值：依据验证者法则（Verifier's Law）【Wei, 2025, Blog】，AI 系统在某项任务上的训练效率与该任务候选解的验证效率与可靠性紧密相连。在软件工程任务中，强验证机制发挥着双重作用：

  1. 在后训练阶段（Post-training），为带有可验证奖励的强化学习（RLVR）提供精准的监督信号【13, OLMo et al., 2025】；
  2. 在推理阶段，通过测试时扩展（TTS）采样 $K$ 个独立候选补丁并由验证器挑选最优解，显著突破单次采样上限【3, Brown et al., 2024】。

现有两类验证信号的权衡与缺陷：

基于评分细则的验证原则（Rubric-based Verification）

评分细则（Rubric）的核心思想是将复杂的“正确性”判断解构为一组显式、原子化的评估准则集合【2, Arora et al., 2025】。形式化地，评分细则由准则文本、关联的权重以及将细粒度判定聚合成标量分数的聚合规则构成。面对待评估对象，裁判对各个维度给出离散或连续判定，并聚合成最终分数以供排序或策略更新。

SWE 场景下的上下文接地（Grounding）挑战：在开放式软件工程任务中，若仅根据 GitHub Issue 或 PR 问题描述编写评分细则，生成的准则往往高度欠规范（Under-specified），因为通用语言描述缺乏仓库内部特定的接口规范、私有约束、错误处理逻辑以及项目惯用约定。缺乏上下文约束的细则在打分时极具歧义性，难以稳定区分补丁优劣。因此，细则生成过程必须是 Agentic 的——验证系统必须主动检索代码库，将规则扎根于具体的代码路径与系统契约之中，同时在评分环节保持免代码执行的轻量级优势。

方法细节

Agentic Rubrics 体系构建

细则生成（Rubric Generation）：

细则评分（Rubric Grading）：

细则下的测试时扩展（Test-Time Scaling）与评估流程

问题形式化与生成采样：

评估指标（Best@K）：

对比基线设计与实现细节

为清晰解耦各模块效用，实验设计了严密的基线对比矩阵，分为两大流派：

  1. 非 Agentic 验证基线（Non-agentic Verifiers，无需额外工件生成）：

    • 自洽性（Self-Consistency）【17, Singhi et al., 2025; 20, Wang et al., 2023; 23, Wei et al., 2025】：计算每个候选补丁的 diff 文本与其余 $K-1$ 个候选补丁的平均相似度，选择相似度均值最高的补丁。
    • 补丁分类器（Patch Classifier）【10, Jain et al., 2025; 15, Pan et al., 2024】：利用大模型裁判直接基于问题描述与补丁文本进行单次前向判断，输出 $[0, 1]$ 连续分数或 YES/NO 判定。

  2. Agentic 验证基线（Agentic Verifiers，依赖仓库探索生成工件）：

    • Agentic Tests【10, Jain et al., 2025】：专家智能体深入仓库探索后，编写一个独立的测试脚本 test_issue.py；随后在沙箱容器中对候选补丁应用后执行该测试脚本，依据通过率评分。
    • Agentic Patch Similarity：专家智能体在沙箱中尝试解决该问题并生成一个代理参考补丁（Proxy Reference Patch）；随后 LLM 裁判比对待评估补丁与代理补丁在 1–5 分制下的语义相近度。
    • Agentic Rubrics（本文方法）：专家智能体生成结构化 rubrics.yaml，随后裁判进行免代码执行的评分。

实现细节与防作弊约束：

实验环境

实验结果

测试时扩展（Best@K）核心性能对比

下表汇总了在 SWE-Bench Verified（500 题）上，不同验证方法配合 Qwen3-32B 与 Qwen3-Coder-30B-A3B 生成器在 $K=16$ 候选下的解决率表现：

验证方法类型 具体方法 执行需求 生成工件类型 Qwen3-32B Best@16 (%) Qwen3-Coder-30B-A3B Best@16 (%)
理论基准 Oracle Pass@16 是 (真实测试) - 51.4 65.6
理论基准 Random Pass@16 否 - 22.6 39.6
非 Agentic 验证器 Self-Consistency 否 无 33.2 47.6
非 Agentic 验证器 Patch Classifier 否 无 37.1 50.2
Agentic 验证器 Agentic Tests 是 (沙箱执行) 单元测试 33.6 49.0
Agentic 验证器 Agentic Patch Similarity 否 代理补丁 35.0 49.6
本文方法 Agentic Rubrics (Ours) 否 结构化细则 40.6 54.2
图2：(左) Qwen3-32B 和 Qwen3-Coder-30B-A3B 在 K=16 时的 Best@16 解决率 (%)。验证信号由 Claude Sonnet-4.5 生成，LLM 裁判使用 GPT-5 (Low Reasoning)。(右) Qwen3-32B 在不同验证器下的 Best@K 扩展曲线，数据基于 100 次重复试验取平均。
图2：(左) Qwen3-32B 和 Qwen3-Coder-30B-A3B 在 K=16 时的 Best@16 解决率 (%)。验证信号由 Claude Sonnet-4.5 生成，LLM 裁判使用 GPT-5 (Low Reasoning)。(右) Qwen3-32B 在不同验证器下的 Best@K 扩展曲线，数据基于 100 次重复试验取平均。

实验分析结论：

  1. 全面超越各类基线：在两款生成器模型下，Agentic Rubrics 均以显著优势拔得头筹。在 Qwen3-32B 上达到 $40.6\%$，比最强免执行基线（Patch Classifier，37.1%）高出 $+3.5$ 个百分点，比最强工件基线（Agentic Patch Similarity，35.0%）高出 $+5.6$ 个百分点；在 Qwen3-Coder 上达到 $54.2\%$，相比 Patch Classifier（50.2%）提升 $+4.0$ 个百分点，相比工件基线高出 $+4.6$ 个百分点。
  2. 随采样量 $K$ 的单调增益优势：图 2 右侧的扩展曲线显示，随着候选补丁数从 1 增加至 16，Agentic Rubrics 始终稳居所有对比验证器之上，并在较大 $K$ 时展现出更具弹性的增长斜率，证明其评分优势并非局限于特定采样预算。
  3. 优于其他 Agentic 工件的原因解析：
    • Agentic Tests 表现受制于中间环境链条的脆性：生成的测试必须在复杂容器内无语法/依赖错误地跑通，且需要高度精准的辨别力；一旦测试本身有微小缺陷，便会导致整个验证失效（仅取得 33.6% 与 49.0%）。
    • Agentic Patch Similarity 存在“风格绑架”缺陷：真实开发中同构逻辑可能有完全不同的语法实现，强行比对文本相似度会系统性低估那些功能正确但编码习惯与代理补丁相异的优质解（仅 35.0% 与 49.6%）。
    • Agentic Rubrics 另辟蹊径，它利用深入代码库的交互来提炼“何为正确的目标契约（What should hold）”，打分阶段则在无需执行的环境中多角度静态审视，兼具灵活性、稳健性与极高的解释深度。

细则机制多维深度剖析

评分对齐性分析（Score Alignment Analysis）

图3：Sonnet-4.5 生成的 Agentic Rubrics 在 Qwen3-32B 候选补丁上的加权细则得分分布图。绿色代表通过真实测试集（GT Test Passed），红色代表未通过（GT Test Failed）。细则得分与真实测试表现高度对齐，错误补丁得分显著偏低，正确补丁高度集中于高分区间，同时呈现出高密度的区分性分布。
图3：Sonnet-4.5 生成的 Agentic Rubrics 在 Qwen3-32B 候选补丁上的加权细则得分分布图。绿色代表通过真实测试集（GT Test Passed），红色代表未通过（GT Test Failed）。细则得分与真实测试表现高度对齐，错误补丁得分显著偏低，正确补丁高度集中于高分区间，同时呈现出高密度的区分性分布。
图4：Sonnet-4.5 细则得分在四大轴线（文件变更、规范对齐、完整性、运行时）上的分项分布。错误补丁在文件变更（修改范畴）、规范对齐与运行时检查上被大幅扣分；而通过真实测试的补丁虽然在规范对齐和完整性上接近饱和，但在修改范围和部分运行时检查上仍受到合理约束惩罚。
图4：Sonnet-4.5 细则得分在四大轴线（文件变更、规范对齐、完整性、运行时）上的分项分布。错误补丁在文件变更（修改范畴）、规范对齐与运行时检查上被大幅扣分；而通过真实测试的补丁虽然在规范对齐和完整性上接近饱和，但在修改范围和部分运行时检查上仍受到合理约束惩罚。

细则效用性审计（Rubric Utility Analysis）

为判定细则是否存在虚假指控或表层噪音，研究团队抽取了 100 个 SWE-Bench Verified 实例，由 GPT-5（Medium Reasoning）结合金标测试与金标补丁进行盲审，将细则判定划分为高价值效用（High-Utility，如核心语义、API 兼容、架构范畴、边缘情况）与低价值效用（Low-Utility，如过度指定、规则冲突、冗余信息）。

图5：Agentic Rubric 相对于真实测试的定性效用拆解图。(a) 在高对齐情形（测试与细则均判定合格或均不合格）下，78% 的细则具有实质性高价值，仅 22% 表现为低价值噪音；(b) 当测试判定通过但细则给出低分（<0.7）的“严格审查”情形下，仍有 54% 的细则属于高价值，精准指出了真实测试未能覆盖的深层隐患（如漏掉根因、缺少边缘场景处理）。
图5b子图

消融实验

细则生成智能体模型能力的影响

图6：(a) 由不同前沿模型和开源模型作为细则生成器时，在 Qwen3-Coder-30B-A3B 候选集上的 TTS 性能表现；(b) 不同生成模型在每个实例上生成的细则项数量分布情况。
图6：(a) 由不同前沿模型和开源模型作为细则生成器时，在 Qwen3-Coder-30B-A3B 候选集上的 TTS 性能表现；(b) 不同生成模型在每个实例上生成的细则项数量分布情况。

细则生成能力的开源模型蒸馏与微调

研究团队进一步探索：能否将前沿模型（Sonnet-4.5）强大的智能体细则生成能力蒸馏给开源模型（Qwen3-32B）？

图7：对开源模型（Qwen3-32B）进行微调实验的 Best@K 扩展曲线。微调为 Agentic Rubric 生成器的模型大幅胜过微调为 Patch Classifier 的模型以及未微调的基线。
图7：对开源模型（Qwen3-32B）进行微调实验的 Best@K 扩展曲线。微调为 Agentic Rubric 生成器的模型大幅胜过微调为 Patch Classifier 的模型以及未微调的基线。

仓库上下文接地（Repository Grounding）的消融分析

为了量化“与代码库主动交互”对生成高质量细则的必要性，实验对比了同一模型（Sonnet-4.5）在允许工具交互（Agentic）与剥离工具环境、仅基于 Issue 描述直接输出细则（Non-Agentic）的表现差异。

评估维度 Non-Agentic Rubrics (仅凭 Issue 生成) Agentic Rubrics (工具交互生成) 智能体在仓库中的工具调用动作 (Tool Calls)
案例 1 "在解析器中针对处理关系运算符的代码路径，不触碰无关运算符"（泛化抽象） "在 EvaluateFalseTransformer 类中添加 visit_Compare 方法"（具体符号定位） find -path "*/parsing/*"
str_replace_editor view
view_range 1090 1194
案例 2 "修改包含 HTML 生成逻辑的 kbd 角色实现文件"（指代模糊） "修改 transforms.py 中的 KeyboardTransform 类"（精确绑定类名与文件名） find -exec grep -l "kbd"
grep -r "kbd" transforms.py
str_replace_editor view

裁判模型（Judge Model）的敏感性分析

在 Sonnet-4.5 生成的细则下，评估不同推理强度的裁判模型在 Qwen3-Coder-30B-A3B 候选补丁上的 Best@16 排序效果：

裁判模型 (Judge Model) Best@16 准确率 (%)
GPT-5-mini $52.6 \pm 2.20$
GPT-5 Low Reasoning $54.2 \pm 2.22$
GPT-5 Medium Reasoning $54.3 \pm 2.25$
GPT-5 High Reasoning $55.0 \pm 2.21$

从上表数据可以看出：裁判模型的推理能力对打分表现有小幅但不可忽视的积极影响。然而，从 Low Reasoning 到 High Reasoning 的增益相对平缓（54.2% 到 55.0%），这表明由于 Agentic Rubrics 本身已被设计为原子化、自包含的高精度标准，裁判模型无需背负沉重的自我推理负担即可完成客观裁决，兼顾了评分速度与经济性。

补充细节

相关工作探讨

局限性与未来展望

  1. 后训练强化学习（RLVR）集成挑战：本文主要在固定策略模型的并行测试时扩展（Parallel TTS）场景下对验证器进行纯净评估。将 Agentic Rubrics 信号直接用作强化学习策略迭代的奖励模型是显而易见的下一步，但这将引入多步行为信用分配（Credit Assignment）、策略自适应带来的奖励作弊（Reward Hacking）以及动态非平稳性等算法挑战。
  2. 细则质量的低价值噪声消除与人机协同：虽然效用审计表明大多数生成细则是高价值的，但仍有部分细则表现出过度限定（Over-specification）、规则冗余或与金标规范冲突。未来可通过引入轻量级人机协同（Human-in-the-loop）工作流——例如人工模板复用、针对常见失效模式的提示词防御与人工微调，进一步净化细则保真度。

附录

A.1 真实人类参考补丁（Ground-Truth Patch）的评分验证

为检验细则与人类专家真实代码的兼容性，作者使用各模型生成的细则直接对通过 SWE-Bench Verified 测试的原始 PR 人类补丁进行打分。

细则生成模型 在真实补丁上的平均加权得分
Claude Opus-4.5 0.8658
GPT-5 0.8413
Claude Sonnet-4.5 0.8233
Gemini-3-Pro 0.8082
Meta-CWM 0.8015
Qwen3-Coder-30B-A3B 0.8037
Qwen3-32B 0.6729
图8：优质模型（Opus-4.5、Sonnet-4.5）与较弱模型（Qwen3-32B、Qwen3-Coder）生成的细则在人类真实补丁上的四大轴线得分分布对比。
图8：优质模型（Opus-4.5、Sonnet-4.5）与较弱模型（Qwen3-32B、Qwen3-Coder）生成的细则在人类真实补丁上的四大轴线得分分布对比。

现象分析：如上表及图 8 所示，前沿模型生成的细则在人类真实补丁上获得了超过 0.82 的极高均分，证实了细则与工业级人类解决方案的高兼容度。人类补丁被扣分的主要情形仍旧集中在 File Change 轴上——细则智能体往往倾向于非常严苛的最小修改位置，而人类开发者的补丁可能会顺带调整周围的辅助代码。

A.2 细则生成模型的智能体交互与格式遵从能力

图9：各模型在细则生成脚手架中输出合法可解析 YAML 细则文件的成功率柱状图。
图9：各模型在细则生成脚手架中输出合法可解析 YAML 细则文件的成功率柱状图。

图 9 揭示了各模型在长期工具交互中对严格格式约束的遵从能力差距：

图10：(a) Qwen3-32B 经过 Sonnet-4.5 细则轨迹 SFT 微调后，合法解析率大幅提升至 88.8%，格式错误显著压低；(b) 微调后其生成的细则数量分布完全贴合专家教师模型。
图10：(a) Qwen3-32B 经过 Sonnet-4.5 细则轨迹 SFT 微调后，合法解析率大幅提升至 88.8%，格式错误显著压低；(b) 微调后其生成的细则数量分布完全贴合专家教师模型。

如图 10 所示，通过使用教师轨迹进行监督微调，Qwen3-32B 的合法生成率从 $74.6\%$ 跃升至 $88.8\%$，不仅错误急剧减少，其细则数量分布曲线也高度逼近 Sonnet-4.5，证明了通过蒸馏打造专用轻量细则生成器的可行性。

A.3 验证方案的成本效益经济学分析

下表详列了基于相同底层模型（Sonnet-4.5）的不同 Agentic 验证方案的代币与计算成本核算（基于 SWE-Bench Verified 全部样本平均）：

验证方法 工件生成成本 (Artifact Cost, USD) 单个候选补丁评分成本 (Grading Cost, USD) 轨迹平均 API 交互轮数 Qwen3-32B Best@16 (%)
Agentic Patch Similarity 0.640 0.006 48.5 36.6
Agentic Tests 0.499 0.001 (容器启动) 29.2 33.6
Agentic Rubrics (Ours) 0.245 0.003 22.9 40.6

A.4 细则评分的稳定性与抖动性（Flakiness）研究

为评估基于 LLM 裁判的细则判决确定性，作者设计了重复判决试验：随机抽取 20 个实例，针对 Sonnet-4.5 与 Qwen3-32B 生成的细则各取 5 个条目（每模型 100 个条目），使用 GPT-5（Low Reasoning）独立重复打分 5 次。若某一细则项在 5 次评分中出现任何分歧，则视该项为“抖动（Flaky）”。

A.5 混合验证器（Hybrid Verifiers: Rubrics + Tests）

图11：结合 Agentic Rubrics 与 Agentic Tests 构建的混合验证器扩展曲线。两者结合后的综合解决率超越了单一验证器。
图11：结合 Agentic Rubrics 与 Agentic Tests 构建的混合验证器扩展曲线。两者结合后的综合解决率超越了单一验证器。

受到 R2E-Gym 启发，作者探索了将 Agentic Rubrics 的免执行得分与 Agentic Tests 的沙箱执行结果进行线性加权融合。如图 11 所示，“细则 + 测试”构成的混合验证器在 Qwen3-32B 候选补丁上的 Best@K 曲线始终处于最高点，展示了两类互补信号协同挖掘代码质量的巨大潜力。

A.6 细则效用性分类学分类标准（Taxonomy）

效用层级 (Tier) 子类别 (Sub-category) 详细技术定义
高价值 (High-Utility) Rule Break 破坏了内部系统契约或设计假设，即使测试套件未对其进行直接断言覆盖。
Band-Aid Fix 补丁仅仅通过创可贴式防御满足了测试用例，但并未真正解决缺陷的底层语义。
Wrong Layer 修复逻辑被置于错误的模块、类或抽象层；该行为变更本应存在于代码库的其他部分。
Root Cause Missed 核心 Bug 依然存在或仅被局部掩盖，补丁未能真正消解报告的故障根因。
Missing Edges 未处理规格说明隐含的重要边缘用例或重现场景，尽管主路径已通过测试。
Scope Creep 补丁引入了脱离任务范围的无关改动（如多余文件、调试日志、大规模重构）。
Perf Risk 补丁很可能引入非平凡的性能回退或资源泄漏隐患，而单元测试无法直接量化。
API Break 破坏了既有的公共 API 签名或向下兼容行为，导致现有下游调用者损坏。
Security Risk 削弱了既有的输入验证、数据安全或权限约束，超出了测试用例的显式防线。
低价值 (Low-Utility) Test Rules Mismatch 细则假设了与实际环境不同的测试协议（例如错误地期望修改测试文件本身）。
Over-Specified Fix 细则强制要求某种特定的实现模式，哪怕规格本身允许多种正确的修复方案。
API Over-Strict 细则过度惩罚良性的结构重命名，即使外部可观测行为完全符合金标。
Style Nit 细则聚焦于纯代码风格或格式排版，对功能正确性没有任何语义影响。
Spec Clash 细则与 Issue 描述或金标行为直接矛盾（例如禁止了规格明确允许的操作）。
Ref Patch Conflict 人类编写的金标补丁本身违反了该细则约束，表明细则设计脱离实际。
Redundant Signal 细则未提供新增量信息，与已有细则完全重叠，造成权重的重复计算。
Eval Bug 评分失误由裁判解析或字符匹配缺陷引起，而非候选补丁真正违反了准则。
Irrelevant Rule 细则编码了对于该具体 Bug 场景毫无必要、不合时宜的无端约束。

A.7 SWE Agent 脚手架的工程定制与提示设计

实验在标准 SWE-Agent 脚手架【28】的基础上实施了重要改造：

  1. 轮次预警注入：在交互循环中，系统每隔 5 轮向智能体发送一条剩余轮次提示，防止模型因轮次耗尽发生不可控的截断崩溃；
  2. 强制思考摘要解析：由于多款前沿模型在默认脚手架下会跳过思考直接输出工具调用，这严重阻碍了将轨迹蒸馏至开源模型。研究团队重构了解析逻辑，严格强制要求智能体在每一轮交互中必须返回 4–5 句关于“当前推理、下一步目标与使用工具原因”的自然语言思考摘要。

A.8 & A.9 详细个案实录：通过测试但细则低分的经典案例分析

典型案例 1：matplotlib__matplotlib-26291

问题描述：创建 Inset 轴（内嵌坐标轴）并在保存图像时开启 bbox_inches='tight' 会抛出 AttributeError: 'NoneType' object has no attribute '_get_renderer'。根因在于 Matplotlib 的内嵌定位器在调用时传入了 renderer=None，下游代码误以为存在有效的渲染器对象。

Qwen3-32B 候选补丁（核心 Diff）：

--- a/lib/mpl_toolkits/axes_grid1/inset_locator.py
+++ b/lib/mpl_toolkits/axes_grid1/inset_locator.py
@@ -70,7 +70,18 @@ class AnchoredLocatorBase(AnchoredOffsetbox):
     def __call__(self, ax, renderer):
         self.axes = ax
         bbox = self.get_window_extent(renderer)
+        if renderer is None:
+            # 没有渲染器可用，直接返回一个零尺寸的哑边界框（dummy bbox）以绕开 tight layout 报错
+            dummy_bbox = Bbox.from_bounds(0, 0, 0, 0)
+            tr = ax.figure.transSubfigure.inverted()
+            return TransformedBbox(dummy_bbox, tr)
         try:
             bbox = self.get_window_extent(renderer)
         except (AttributeError, RuntimeError) as e:
+            dummy_bbox = Bbox.from_bounds(0, 0, 0, 0)
+            tr = ax.figure.transSubfigure.inverted()
+            return TransformedBbox(dummy_bbox, tr)
         px, py = self.get_offset(bbox.width, bbox.height, 0, 0, renderer)
         bbox_canvas = Bbox.from_bounds(px, py, bbox.width, bbox.height)
         tr = ax.figure.transSubfigure.inverted()
         return TransformedBbox(bbox_canvas, tr)

细则判决与技术深度对比：

典型案例 2：matplotlib__matplotlib-25332

问题描述：在执行 fig.align_labels() 后，尝试进行序列化 pickle.dumps(fig) 会抛出 TypeError: cannot pickle 'weakref.ReferenceType' object，原因在于内部的 Grouper 数据结构持有了不可直接序列化的弱引用对象。

候选补丁与细则对齐：

典型案例 3：django__django-13417

问题描述：对于定义了 Meta.ordering 的模型，如果查询集包含 GROUP BY 聚合（例如 annotate(Count('pk'))），其 qs.ordered 属性仍旧返回 True，然而 Django 底层生成的 SQL 实际上为了避免分组歧义已经清空了 ORDER BY。这造成属性状态与 SQL 真实行为严重脱节。

候选补丁与细则裁定：

A.10–A.12 核心提示词与交互协议规范

细则生成智能体系统提示词规范（Agentic Rubrics Scaffold Prompt）

agent:
  templates:
    system_template: |-
      You are an expert code reviewer that can understand issues and are well versed in the codebase. 
      Your job is to write high quality rubrics to grade the solution to a given issue.

      IMPORTANT: In EVERY turn, you MUST ALWAYS include:
      1. A summary of your thinking - explain what you're planning to do and why, and what tool you're going to use (4-5 sentences max).
      2. A tool call. You can only make one tool call per turn.

    instance_template: |-
      <uploaded_files>
      {{working_dir}}
      </uploaded_files>
      I've uploaded a python code repository in the directory {{working_dir}}.
      Consider the following PR description:
      <pr_description>
      {{problem_statement}}
      </pr_description>

      Can you help me write high quality rubrics to grade the solution to the task described in the <pr_description>? 
      This means you SHOULDN'T attempt to solve the task yourself, but rather understand the task, go through the codebase, and write rubrics only.

      Follow these steps to write the rubrics:
      1. Find and read code relevant to <pr_description> using search tools.
      2. Think of the approach to solve the task (functional requirements, non-functional requirements).
      3. Understand codebase structure, conventions, and style.
      4. Write a list of rubrics along the specified axes.
      5. Create 'rubrics.yaml' with valid YAML structure.
      6. Ensure 'rubrics.yaml' is parseable via yaml.safe_load.
      7. Do not touch any other files. Submit the task.

      Atomicity: Each criterion evaluates exactly one distinct aspect. Break 'and' into multiple items.
      Self-containment: Bind items to exact paths/symbols/tokens. No cross-item references.
      MECE: Mutually exclusive and collectively exhaustive.
      Style: Descriptions start with 3rd-person singular verbs (Identifies, Avoids, Preserves). 
      Weights: 1=nice, 2=valuable, 3=must.

      Axes:
      - file_change_rubrics (4-8 items): Scope, locality, minimal diff.
      - spec_alignment_rubrics (3-6 items): Issue requirements and API contracts.
      - integrity_rubrics (3-6 items): Hygiene, no test weakening (@pytest.mark.skip), API stability.
      - runtime_rubrics (3-6 items): Intended runtime properties (Distinguishability, Backward compatibility, Flake resistance).

      Output Structure:
      metadata:
        task_summary: "..."
        underlying_bug: "..."
      axes:
        file_change_rubrics:
          - id: "FC1"
            description: "..."
            weight: 3
        spec_alignment_rubrics:
          - id: "SA1"
            description: "..."
            weight: 2
        integrity_rubrics:
          - id: "I1"
            description: "..."
            weight: 2
        runtime_rubrics:
          - id: "R1"
            description: "..."
            weight: 2

免执行细则裁判提示词规范（Rubric Judge Prompt）

SYSTEM_PROMPT = """
You are a rubric based evaluator for software-engineering agent's generated patch. 
Use the provided rubric to evaluate the generated patch.

Inputs:
- PR_DESCRIPTION: problem + expected behavior.
- RUBRIC: dictionary of n rubric items for an ideal patch with their ids as keys and descriptions as values.
- PATCH: the model's predicted code patch

Your job:
1. Analyze the rubric and the patch to evaluate the SWE-agent's generated patch.
2. Emit a score for each rubric item. The score should be a binary score of 1 if the patch satisfies the rubric item and 0 otherwise.

Return the scores in JSON format:
{
  "<rubric_id_1>": <score_1>,
  "<rubric_id_2>": <score_2>,
  ...
}
"""

方法细节关键引用梳理

下表完整汇总了本文方法与实验设计中所引用的核心参考文献、其在文中的具体论证作用及对应文献详情：

引用编号 原文出现位置及论证逻辑描述 参考文献完整信息
[2] 阐明评分细则的基本架构，证明其将复杂的任务正确性解构为一组显式、原子化判定标准的有效性。 Arora et al., Healthbench: Evaluating large language models towards improved human health. arXiv:2505.08775, 2025.
[3] 论证测试时扩展（TTS）在推理阶段通过重复采样和验证重排序带来显著性能提升的理论基础。 Brown et al., Large language monkeys: Scaling inference compute with repeated sampling. arXiv:2407.21787, 2024.
[4] 指出免代码执行的黑盒 LLM 裁判在代码生成与摘要任务中存在可靠性缺陷，支撑提出环境感知细则的动机。 Crupi et al., On the effectiveness of llm-as-a-judge for code generation and summarization. arXiv:2507.16587, 2025.
[6] 强调依赖单元测试执行的验证方法在大规模并发下存在沙箱配置极其昂贵及测试脆性的弊端。 Ehrlich et al., Codemonkeys: Scaling test-time compute for software engineering. arXiv:2501.14723, 2025.
[10] 重点借鉴其作为基线的 Agentic Tests 设定；采用其 R2E-Gym 训练集方案进行开源模型微调；强调去除思考轨迹以防“验证器作弊”。 Jain et al., R2e-gym: Procedural environments and hybrid verifiers for scaling open-weights swe agents. arXiv:2504.07164, 2025.
[13] 论述验证器为强化学习提供后训练（Post-training）可验证奖励信号的核心价值。 OLMo et al., 2 olmo 2 furious. arXiv:2501.00656, 2025.
[14] 作为本文实验评测的基准测试集（SWE-Bench Verified 500 题）。 OpenAI, Introducing SWE-bench Verified. OpenAI Blog, 2024.
[15] 确立免执行验证器中主流的“补丁分类器（Patch Classifier）”基线模型架构。 Pan et al., Training software engineering agents and verifiers with SWE-gym. arXiv:2412.21139, 2024.
[16] 指出评分细则在多步探索和深度研究智能体强化学习中作为动态奖励机制的可行性。 Shao et al., Dr tulu: Reinforcement learning with evolving rubrics for deep research. arXiv:2511.19399, 2025.
[17, 20] 确立基于文本表征一致性进行重排序的“自洽性（Self-Consistency）”非智能体验证基线。 Singhi et al., 2025; Wang et al., Self-consistency improves chain of thought reasoning in language models. ICLR, 2023.
[21, 28] 本文构建细则生成智能体所依托的交互底层框架 SWE-Agent 与 OpenHands。 Wang et al., Openhands, 2024; Yang et al., SWE-agent: Agent-computer interfaces enable automated software engineering. NeurIPS, 2024.
[22] 引用验证者法则（Verifier's Law），论述 AI 系统的训练难度与候选解验证的高效性、可靠性直接绑定。 Wei, Asymmetry of verification and verifier's rule. Blog post, 2025.
[23] 讨论近期 SWE-RL 中免执行验证信号在开源软件演化中的使用与局限。 Wei et al., SWE-RL: Advancing LLM reasoning via reinforcement learning on open software evolution. arXiv:2502.18449, 2025.
[25] 论述细则评估在自由文本生成中作为评价模型（Critic）的理论发展。 Wu et al., RLAC: Reinforcement learning with adversarial critic for free-form generation tasks. arXiv:2511.01758, 2025.
[27] 本文主要评测的候选解策略生成模型 Qwen3 系列技术规范。 Yang et al., Qwen3 technical report. arXiv:2505.09388, 2025.

结论

高质量、自动化且兼具扩展性的验证机制是推动 SWE 智能体实现技术跃迁的核心基石。针对当前代码执行验证开销昂贵、免执行验证缺乏上下文感知的困境，本文提出了 Agentic Rubrics 验证范式。通过驱动专家智能体深入代码仓库提炼环境接地的四维结构化评分细则，再辅以完全无需代码执行的 LLM 判定，该方法在保持轻量级计算特性的同时实现了卓越的验证深度。

在 SWE-Bench Verified 的严格并行测试时扩展实验中，Agentic Rubrics 展现出显著超越现有测试生成器与补丁分类器的性能（Best@16 达到 $54.2\%$ 与 $40.6\%$）。机制分析进一步证实，该细则不仅与真实单元测试高度对齐，更能突破测试用例盲区，敏锐识别出漏掉根因、破坏契约或缺少边界处理的隐蔽代码缺陷。此外，微调实验确认了该生成能力能够低成本蒸馏至开源小模型。这些成果为后续构建高吞吐测试时扩展验证系统，以及为软件工程大模型强化学习（RLVR）提供高保真密集奖励信号开辟了极具前景的新方向。