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】。

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

  • 基于执行的方法（Execution-based）：通常依赖运行人类编写或 LLM 生成的单元测试【6, Ehrlich et al., 2025】。该机制虽然天然具备环境感知能力，但在 SWE 规模化应用中存在致命缺陷：首先是操作开销昂贵，每个实例都需要重新初始化复杂的容器沙箱与依赖环境；其次，测试信号通常非常稀疏（仅二元 Pass/Fail），区分度极差，并伴随严重的“测试毒性”（Test Toxicity，如生成了破坏环境或不合法的测试用例）【10, Jain et al., 2025】。
  • 免执行的方法（Execution-free）：通过预训练/微调的补丁分类器（Patch Classifier）、相似度度量或 LLM 裁判直接对补丁重排序【23, Wei et al., 2025】。此类方法在操作上极其轻量，但已被多项研究证实可靠性欠佳【4, Crupi et al., 2025】，黑盒打分缺乏可解释性，且极其容易过度拟合代码风格等表层线索，无法捕捉深层的功能正确性与架构约束。

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

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

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

方法细节

Agentic Rubrics 体系构建

细则生成（Rubric Generation）：

  • 智能体脚手架与探索机制：作者基于 SWE-Agent 脚手架【21, Wang et al., 2024; 28, Yang et al., 2024】构建了细则生成智能体。该脚手架为模型提供了包括仓库导航、代码文件查看/编辑以及 Bash 命令执行在内的完整工具链。通过定制系统提示词（System Prompt，详见附录 A.10），细则智能体被严令禁止自行编写修复补丁，而是引导其像资深软件工程师一样主动检索代码库：定位错误发生的具体调用栈、查阅周围代码契约、追踪调用点、推断边界条件，最终生成一个名为 rubrics.yaml 的结构化评分文件。

  • 细则四维轴线架构（Rubric Axes）：每个细则条目定义为一个二元组 $\left(t_i, w_i\right)$，其中 $t_i$ 为具体的自然语言准则描述，$w_i \in {1, 2, 3}$ 为重要性权重，分别对应“可有可无（nice-to-have, 1）”、“重要（important, 2）”和“必须满足（must-have, 3）”。所有准则被严格划分至四大正交轴线：

    1. 文件变更轴（File Change，4–8 条）：约束修改范围、局部性及充分性。严惩无关文件的代码扰动，奖励最小化、可逆且紧密贴合 Bug 根因的差异修改；
    2. 规范对齐轴（Spec Alignment，3–6 条）：严格比对代码实现与 Issue 描述的契约一致性，涵盖要求的输入类型、前置条件、异常处理与公有 API 行为；
    3. 完整性约束轴（Integrity，3–6 条）：设立防作弊与工程卫生红线，包括严禁弱化测试（如注释断言、添加 @pytest.mark.skip）、禁止大范围重构、严禁大批量命名替换或不必要的第三方依赖引入；
    4. 运行时行为轴（Runtime，3–6 条）：在免执行前提下，通过静态代码证据推导预期的运行时行为。涵盖可区分性（区分正确与错误行为的特异性哨兵或异常类）、回归安全性（向后兼容）、确定性（杜绝未设种子的随机性或硬编码 sleep 导致的抖动）、资源与超时边界、错误边界清晰度以及测试框架钩子完整性。

  • 格式校验铁律：智能体在交互末期必须通过 yaml.safe_load 验证文件的语法正确性。若最终提交的 rubrics.yaml 解析失败，则该实例生成尝试被标记为无效并赋予 0 分。

细则评分（Rubric Grading）：

  • 打分与聚合机制：在验证阶段，LLM 裁判接收问题描述、待测候选补丁以及由细则智能体生成的细则文件。针对每个细则项，裁判输出二元满意度判定 $s_i \in \{0, 1\}$。最终的验证标量得分 $S \in [0, 1]$ 采用加权平均进行汇总计算：

    $$S = \frac{\sum_i w_i s_i}{\sum_i w_i}$$


    所得分值 $S$ 直接作为候选补丁的质量评分，用于后续的多采样重排序选择。

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

问题形式化与生成采样：

  • 对于给定的 SWE 问题描述 $D$，目标编码智能体在沙箱环境中独立运行 $K$ 次（本文设 $K=16$），生成轨迹集合 $T^{(j)}$ 及对应的候选补丁集合 $P^{(j)}$（其中 $j = 1, \ldots, K$）。
  • 验证器的目标是独立为每个候选补丁计算出评分 $\dot{S}^{(j)} \in [0, 1]$，并通过降序排列选出得分最高的候选补丁 $P^* = \arg\max_j \dot{S}^{(j)}$。

评估指标（Best@K）：

  • 采纳 SWE-Bench Verified 基准的官方评估规则：候选补丁若能完全通过人类编写的真实测试集（包括 Fail-To-Pass 缺陷复现测试以及 Pass-to-Pass 防回归测试），则该问题被判定为已解决（Resolved）。
  • 系统计算在 Best@K 准则下的解决率。为了消除当候选数 $K < 16$ 时的采样偏差并提升统计稳健性，所有小于 16 的 $K$ 值结果均通过 100 次重复重采样实验取平均。同时设置两个理论参照线：
    • Oracle Pass@K：使用真实评测测试集直接挑选的最优上限；
    • Random@K：从 $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，随后裁判进行免代码执行的评分。

实现细节与防作弊约束：

  • 模型配置：涉及工件生成（测试生成、代理补丁生成、细则生成）的专家模型统一采用 Claude Sonnet-4.5（赋予 30 步交互预算）；所有裁判打分任务（分类器判断、相似度打分、细则打分）统一采用 GPT-5（Low Reasoning 模式）。
  • 沙箱隔离：所有智能体均在 SWE-Bench Verified 沙箱环境（重置为 PR 前的历史快照）中运行。严密隔离隐藏的真实评测测试集、参考补丁及 Git commit 历史，防止数据泄露。
  • 信息输入统一性：为避免裁判被智能体的思维链轨迹（Thinking Trace）或工具调用历史误导（防止“验证器作弊”，Verifier Hacking）【10, Jain et al., 2025】，所有验证方法的评分输入被严格限制为三要素：问题描述、验证工件与最终提交的补丁文件，一律剥离任何中间思考和执行轨迹。

实验环境

  • 基准数据集：SWE-Bench Verified【14, OpenAI, 2024】完整测试集，包含从知名开源 Python 项目中精心挑选并人工校验的 500 个真实复杂 GitHub Issue 实例。该基准消除了原始 SWE-Bench 中欠约束或测试环境配置有误的样本。

  • 代码生成模型（Generator）：

    • Qwen3-32B（Instruct 版本，对话轮次上限设为 30 轮）；
    • Qwen3-Coder-30B-A3B（对话轮次上限设为 50 轮）。
    • 两者采样生成补丁时均设置温度系数 $\text{temperature} = 1.0$，针对每个问题独立采样 $K=16$ 条完整解决轨迹。

  • 验证架构模型：

    • 细则生成专家模型：Claude Sonnet-4.5、Claude Opus-4.5、Gemini-3-Pro、GPT-5、Meta-CWM（Code World Model）、Qwen3-Coder-30B-A3B、Qwen3-32B。
    • 裁判模型：GPT-5（测试低/中/高推理模式）与 GPT-5-mini。

  • 计算与执行环境：

    • 补丁生成与交互沙箱基于 SWE-Agent 脚手架；
    • 智能体测试执行沙箱环境运行于 Modal 容器化云平台；
    • 开源模型微调（SFT）实验部署于 4 个计算节点，共计 32 张 NVIDIA H100 GPU。

实验结果

测试时扩展（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）。细则得分与真实测试表现高度对齐，错误补丁得分显著偏低，正确补丁高度集中于高分区间，同时呈现出高密度的区分性分布。
  • 区分通过与失败补丁的极高灵敏度：如图 3 所示，通过真实测试（GT Test Passed）的补丁，其细则得分高度聚集在 $[0.85, 1.0]$ 区间；而测试失败（GT Test Failed）的补丁平均得分极低（均值在 0.4–0.5 附近）且分布宽泛。经量化评估，Agentic Rubrics 预测真实测试是否通过的 ROC-AUC 高达 0.886，PR-AUC 达到 0.722。高 PR-AUC 证明在要求高精确率的顶层排序阶段，细则能够优先捕获真正的正确补丁，提供了远比二元 Pass/Fail 更加连续、密集的梯度奖励。
图4：Sonnet-4.5 细则得分在四大轴线（文件变更、规范对齐、完整性、运行时）上的分项分布。错误补丁在文件变更（修改范畴）、规范对齐与运行时检查上被大幅扣分；而通过真实测试的补丁虽然在规范对齐和完整性上接近饱和，但在修改范围和部分运行时检查上仍受到合理约束惩罚。
图4：Sonnet-4.5 细则得分在四大轴线（文件变更、规范对齐、完整性、运行时）上的分项分布。错误补丁在文件变更（修改范畴）、规范对齐与运行时检查上被大幅扣分；而通过真实测试的补丁虽然在规范对齐和完整性上接近饱和，但在修改范围和部分运行时检查上仍受到合理约束惩罚。
  • 四大正交轴线的诊断功能解耦：如图 4 分项所示，测试失败的补丁之所以得分低，主因是做出了不必要的冗余修改（File Change 轴得分低）、遗漏了特定 Issue 需求（Spec Alignment 轴得分低）或引发了潜在运行时隐患（Runtime 轴得分低），但它们通常在防作弊指标（Integrity）上表现尚可。反观通过测试的补丁，其在规范对齐和完整性上得分趋近于满分，但在 File Change 上仍能暴露出修改范围过宽等潜在代码异味。

细则效用性审计（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子图

  • 细则与测试一致时的效用（图 5a）：在细则得分与测试通过性达成一致的样本中，$78\%$ 的细则判定属于高价值效用。其中核心语义（Core Semantics）占据 $45.0\%$，API 与兼容性占据 $12.8\%$，结构与范畴占据 $10.1\%$，边缘用例覆盖占 $8.2\%$；低价值中主要为低信号（$12.1\%$）与过度限定（$4.0\%$）。
  • 细则比测试更严苛时的效用（图 5b）：针对测试判定通过但细则评分低于 0.7 的样本，高达 $54\%$ 的细则否定判定被证实为高价值！其中 $17.5\%$ 成功揭示了“补丁并未真正解决根因（Root Cause Missed）”，$15.1\%$ 揭示了“遗漏了规格暗示的关键边缘场景（Missing Edges）”，$6.1\%$ 揭示了潜在的 API 破坏。这证实了 Agentic Rubrics 能够充当比有限单元测试更宏观、更深刻的代码审查防线，有效弥补基准测试套件本身覆盖不全的天然缺陷。

消融实验

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

图6：(a) 由不同前沿模型和开源模型作为细则生成器时，在 Qwen3-Coder-30B-A3B 候选集上的 TTS 性能表现；(b) 不同生成模型在每个实例上生成的细则项数量分布情况。
图6：(a) 由不同前沿模型和开源模型作为细则生成器时，在 Qwen3-Coder-30B-A3B 候选集上的 TTS 性能表现；(b) 不同生成模型在每个实例上生成的细则项数量分布情况。
  • 模型能力决定细则区分力：如图 6(a) 所示，前沿顶尖代码模型（Claude Opus-4.5、Claude Sonnet-4.5 与 Gemini-3-Pro）生成的细则能够取得最高的 Best@16 解决率（约 $54\%$）；开源代码模型（Qwen3-Coder-30B-A3B、Meta Code World Model）生成的细则效果次之（约 $45\%$）；而通用开源小模型 Qwen3-32B 仅能达到约 $43\%$。
  • 细粒度与规则数量的正向关联：图 6(b) 显示，更先进的前沿模型在每个问题上生成的细则条目数量显著更多。例如 Sonnet-4.5 平均每题生成超过 20 条细则，几乎是 Qwen3-32B 和 CWM 的两倍。高度原子化、细粒度的准则能够对候选解建立更加平滑的偏序关系，从而提升重排序精度。

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

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

  • 微调设置：遵循 R2E-Gym【10, Jain et al., 2025】的方法，针对分类器基线，微调 Qwen3-32B 对 4,696 个测试标记样本进行二元 YES/NO 判断；针对 Agentic Rubric 生成器，使用 Sonnet-4.5 探索生成的 2,000 条高质量轨迹对 Qwen3-32B 进行监督微调（SFT）。训练采用 AdamW 优化器，余弦学习率调度，初始学习率 $1.0\times 10^{-5}$，批大小 32，训练 2 个 epoch。
图7：对开源模型（Qwen3-32B）进行微调实验的 Best@K 扩展曲线。微调为 Agentic Rubric 生成器的模型大幅胜过微调为 Patch Classifier 的模型以及未微调的基线。
图7：对开源模型（Qwen3-32B）进行微调实验的 Best@K 扩展曲线。微调为 Agentic Rubric 生成器的模型大幅胜过微调为 Patch Classifier 的模型以及未微调的基线。
  • 微调结果结论：如图 7 所示，经过轨迹微调的 Agentic Rubrics SFT 模型全面碾压了 Patch Classifier SFT 模型及未经微调的基线。这证明让模型学习在真实环境中探索并合成结构化细则，相比于单纯学习二元判别的分类任务，是一种更强韧、更具备信息泛化能力的训练目标。

仓库上下文接地（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
  • 消融量化结果：从上表对比可见，缺乏仓库交互的非 Agentic 细则描述泛化模糊，带来严重的误判与高假阳性率；而 Agentic 细则通过针对性的搜索与文件检查，精准绑定了具体的类名、函数与行号。在 SWE-Bench Verified 上，剥离仓库访问权限直接导致 Qwen3-32B rollouts 的 Best@16 下降 4.0 个百分点，Qwen3-Coder rollouts 的 Best@16 下降 1.4 个百分点。这证实环境探索是细则能够被客观、无歧义裁决的基石。

裁判模型（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 本身已被设计为原子化、自包含的高精度标准，裁判模型无需背负沉重的自我推理负担即可完成客观裁决，兼顾了评分速度与经济性。

补充细节

相关工作探讨

  • 代码智能体与测试时扩展（Coding Agents & TTS）：真实 GitHub 仓库构成了评测与训练前沿编程智能体的主战场【5, Deng et al., 2025; 11, Jimenez et al., 2023】。标准化的智能体脚手架（如 SWE-Agent、Agentless、Mini-SWE-Agent、OpenHands）【18, 2024; 21, 2024; 26, Xia et al., 2024; 28, 2024】确立了模型与计算机交互的标准界面。推理时计算扩展（TTS）【3, Brown et al., 2024; 30, Zhu et al., 2025】通过搜索与采样成为推高解决率的主流范式，但其效果极度受限于验证器（Verifier）的准确率。以往研究尝试利用补丁分类器或生成测试智能体作为验证器【10, 12, Luo et al.; 15, Pan et al., 2024; 24, Wei et al., 2025】，但在泛化性与开销上面临多重掣肘。
  • 评分细则作为 LLM 验证器（Rubrics as Verifiers）：在复杂推理与对齐任务中，细则已被广泛用作评估黄金标准【1, Akyürek et al., 2025; 2, Arora et al., 2025】以及强化学习训练阶段的奖励模型【7, Goel et al., 2025; 8, Gunjal et al., 2025; 16, Shao et al., 2025; 19, Viswanathan et al., 2025; 25, Wu et al., 2025】。本文首次将“上下文感知且基于智能体主动生成的细则”引入严肃软件工程代码补丁的验证环节，打通了兼具高区分度与低执行成本的新路径。

局限性与未来展望

  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 揭示了各模型在长期工具交互中对严格格式约束的遵从能力差距：

  • 前沿模型近乎完美：Sonnet-4.5 合法解析率为 $99.4\%$（解析错误率 0%），Gemini-3-Pro 达到 $96.8\%$，Opus-4.5 达到 $97.6\%$；
  • 中小开源模型受到工具调用与复杂指令跟随能力的制约：Qwen3-32B 的成功率骤降至 $74.6\%$（出现 $18.2\%$ 的语法解析错误与 $7.2\%$ 的完全缺失）；Meta-CWM 成功率仅 $69.4\%$，甚至有 $29.8\%$ 的任务未能生成文件。
图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

  • 成本核算公式与结果：生成工件的成本为每个问题单次投入的固定成本，评分成本随采样数 $K$ 线性增长。计算每个问题在 $K=16$ 时的端到端总成本（$\text{总成本} = \text{工件成本} + 16 \times \text{评分成本}$）：

    • 代理补丁相似度：$0.640 + 16 \times 0.006 = \mathbf{0.736}$ 美元
    • 测试生成执行：$0.499 + 16 \times 0.001 = \mathbf{0.515}$ 美元
    • Agentic Rubrics：$0.245 + 16 \times 0.003 = \mathbf{0.293}$ 美元

  • 结论：Agentic Rubrics 不仅解决率最高，而且端到端成本仅为测试生成的 $56.9\%$、相似度对比的 $39.8\%$。原因在于其无需在沙箱中反复尝试运行测试，交互轮次大幅减少，真正实现了“低成本、高性能”。

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

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

  • 实验结论：强模型编写的细则展现出极高的确定性——Sonnet-4.5 生成的细则抖动率仅为 $2\%$（即 $98\%$ 的准则在 5 次重复判定中完全一致）；而 Qwen3-32B 生成的细则抖动率为 $9\%$。这归功于提示词中对“原子化、自包含、禁止跨条目依赖”的严苛约束，大幅挤压了裁判模型的自由自由度。

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)

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

  • 测试通过的假象：上述补丁巧妙地通过异常捕获并返回一个零尺寸边界框（dummy_bbox），完全规避了崩溃，因此顺利跑通了仓库中现有的单元测试。

  • 细则识破“创可贴敷衍式修复”：细则智能体生成的规则明确包含：

    • R4: 修复后必须保留内嵌轴相对于父坐标轴的准确定位与实际尺寸（FAILED）；
    • SA4: 必须兼容绝对尺寸（如 width=1.3）与相对比例（如 width='30%'）（FAILED）；
    • SA5: 确保在保存且设置 bbox_inches='tight' 时，紧凑布局机制仍能将内嵌轴作为一个真实视觉元素进行计算（FAILED）；
    • R1: 确保在 get_window_extent 访问渲染器前，self.figure 被赋予非空实例（FAILED）。

  • 技术裁决结论：候选补丁虽然通过了测试，但在本质上破坏了图形系统契约——由于返回了大小为 0 的边界框，tight 算法直接忽略了内嵌坐标轴，导致保存的图像中内嵌轴布局错乱。细则以高价值拒绝该补丁，体现了超越单元测试的代码审查纵深。

典型案例 2：matplotlib__matplotlib-25332

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

候选补丁与细则对齐：

  • 候选补丁试图在 cbook.py 的 Grouper 类中重载 __getstate__ 和 __setstate__，将弱引用直接强制解包转换为强引用列表进行序列化。
  • 细则成功捕获该方案引发的潜在严重隐患：
    • R5: 必须保持内存效率，严禁对坐标轴对象建立持久强引用，以防破坏原设计赖以存在的垃圾回收机制（FAILED）；
    • R6: 必须优雅处理在序列化与反序列化之间，坐标轴已被外部垃圾回收的边界状态（FAILED）。

典型案例 3：django__django-13417

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

候选补丁与细则裁定：

  • 候选补丁直接粗暴地在 django/db/models/sql/query.py 内部多处（如 resolve_expression）无脑调用 self.clear_ordering(True)，强行清空状态；
  • 细则条目给出了明确的架构分层制约：
    • FC1 & FC6: 修复必须严格限定在 django/db/models/query.py 的 QuerySet.ordered 属性 getter 内，严禁去破坏底层 sql/query.py 的解析与表达式计算状态（FAILED）；
    • I4: 必须保持 query.default_ordering 属性语义的不变性，不得在存在 GROUP BY 时直接修改底层字段状态（FAILED）；
    • R5: 必须通过只读检查保证状态确定性，避免多线程下的竞态修改（FAILED）。

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）提供高保真密集奖励信号开辟了极具前景的新方向。