1. Agentic Rubrics:软件工程代理验证的新范式
在当今快速发展的软件开发领域,大型语言模型(LLM)驱动的软件工程代理(SWE Agents)正变得越来越强大。这些代理能够执行从简单的代码补全到复杂的bug修复等各种任务。然而,随着代理能力的提升,如何有效验证其输出的正确性成为了一个关键挑战。传统的单元测试验证方法虽然可靠,但在面对大规模、多样化的代码库时,环境设置和测试执行的成本往往令人望而却步。
Agentic Rubrics应运而生,这是一种创新的验证方法,它通过专家代理与代码库的深度交互,生成上下文相关的评分标准清单,从而实现对候选补丁的高效验证。这种方法的核心优势在于它完全摆脱了对代码执行的依赖,使得验证过程更加轻量级和可扩展。
关键洞察:Agentic Rubrics不是简单地替代传统测试,而是提供了一种互补的验证维度。它能够捕捉那些传统测试可能忽略的问题,如代码风格一致性、不必要的修改范围等"软性"质量指标。
2. Agentic Rubrics的核心设计原理
2.1 验证在软件工程代理中的关键作用
验证在SWE代理的工作流程中扮演着双重角色:
- 训练阶段的监督信号:为强化学习提供可靠的奖励信号,指导模型优化
- 推理阶段的性能提升:通过测试时间扩展(TTS)技术,从多个候选方案中选择最优解
传统验证方法主要分为两类:
- 基于执行的方法:依赖单元测试(人工编写或LLM生成)的实际运行结果
- 执行无关的方法:使用补丁分类器、相似度度量或LLM判断等方式评估补丁质量
这两种方法各有优劣。基于执行的方法虽然环境感知能力强,但存在以下问题:
- 每个实例都需要单独的环境设置(如沙箱初始化)
- 信号可能稀疏或脆弱(如区分度有限或测试毒性)
- 对于复杂系统或长尾仓库,测试覆盖率可能不足
执行无关的方法虽然操作轻量,但往往:
- 可靠性较低
- 可解释性差
- 容易受到表面线索(如代码风格)而非功能正确性的影响
2.2 Agentic Rubrics的创新架构
Agentic Rubrics的验证流程分为两个阶段:
2.2.1 评分标准生成阶段
在这个阶段,一个专家评分标准代理会与沙盒化的代码库进行交互,执行以下操作:
- 通过工具调用(如文件搜索、内容查看)探索代码库
- 收集与任务相关的上下文信息
- 生成结构化的评分标准文件(rubrics.yaml)
这个流程模拟了开发者在缺乏全面测试时验证修复的方式:检查周边代码和约定、追踪调用点、推理边界情况等。
生成的评分标准包含多个评分项,每个项由以下部分组成:
- 简短的自然语言标准描述(ti)
- 重要性权重(wi ∈ {1,2,3},分别对应"最好有"/"重要"/"必须有")
- 所属评分维度(共4个)
2.2.2 评分阶段
给定一个问题描述和候选补丁,LLM评分者会:
- 为每个评分项分配二元分数(si ∈ {0,1})
- 根据权重计算加权总分:S = ∑(wisi)/∑wi
- 得到最终的验证分数S ∈ [0,1],用于重新排序候选补丁
2.3 四大评分维度解析
Agentic Rubrics将评分标准组织为四个核心维度,确保全面覆盖软件工程质量的各个方面:
-
文件变更(File Change):
- 评估编辑是否最小化、局部化且足以解决问题
- 典型标准:"只修改xyz.py文件"、"避免修改utils.py"
- 权重:4-8个评分项
-
规范对齐(Spec Alignment):
- 评估补丁是否满足问题描述中的需求
- 典型标准:"将超时改为30秒"
- 权重:3-6个评分项
-
完整性(Integrity):
- 确保没有"作弊"和违反代码卫生的情况
- 典型标准:"不削弱xyz_test.py"、"避免大规模重构"
- 权重:3-6个评分项
-
运行时行为(Runtime):
- 评估变更是否暗示了预期的运行时行为
- 典型标准:"避免ABC中的竞态条件"
- 权重:3-6个评分项
这种多维度的评分体系不仅关注功能正确性,还涵盖了代码质量、维护性和一致性等软件工程的重要方面。
3. Agentic Rubrics的实现与评估
3.1 实验设计与设置
研究团队在SWE-Bench Verified基准上进行了系统评估,该基准包含500个真实的GitHub问题。实验采用以下配置:
候选补丁生成:
- 使用SWE-Agent框架生成补丁
- 两个生成模型:Qwen3-32B和Qwen3-Coder-30B-A3B
- 每个问题生成16个独立的候选补丁
评估协议(BEST@K):
- 问题被视为已解决当且仅当候选补丁通过所有真实测试
- 从K个候选中选择得分最高的补丁进行最终评估
- 对比基线包括:
- ORACLE PASS@K(使用真实测试选择,理论上限)
- RANDOM@K(随机选择)
- 其他验证方法(Self-Consistency、Patch Classifier等)
实现细节:
- 评分标准生成使用Claude Sonnet-4.5(30轮预算)
- 评分使用GPT-5(低推理模式)
- 所有验证器在相同的沙箱环境中运行
3.2 主要实验结果
在Qwen3-32B和Qwen3-Coder-30B-A3B上的实验结果如下:
| 验证方法 |
执行无关 |
专家产物 |
Qwen3-32B |
Qwen3-Coder |
| Oracle Pass@16 |
- |
- |
51.4 |
65.6 |
| Random Pass@16 |
- |
- |
22.6 |
39.6 |
| Self-Consistency |
✓ |
- |
33.2 |
47.6 |
| Patch Classifier |
✓ |
- |
37.1 |
50.2 |
| Agentic Tests |
✗ |
Tests |
33.6 |
49.0 |
| Agentic Patch Sim |
✓ |
Patch |
35.0 |
49.6 |
| Agentic Rubrics |
✓ |
Rubric |
40.6 |
54.2 |
关键发现:
- Agentic Rubrics在两个生成模型上都显著优于所有基线方法
- 对于Qwen3-32B,比最强的非代理基线(Patch Classifier)高出3.5个百分点
- 对于Qwen3-Coder,比最强的代理基线(Agentic Patch Similarity)高出4.6个百分点
- 随着K的增加,基于评分的优势持续存在,表明这不是单一操作点的偶然现象
3.3 评分标准质量分析
研究团队深入分析了Agentic Rubrics生成的评分标准质量,发现:
与真实测试的对齐:
- 评分标准分数与真实测试结果高度一致(ROC-AUC=0.886)
- 通过测试的补丁通常获得高分(0.85-1.0)
- 未通过测试的补丁分数较低且分布广泛(约0.4-0.5)
各维度的区分能力:
- 错误的补丁在文件变更、规范对齐和运行时维度得分明显较低
- 完整性维度通常表现较好,说明代理很少违反基本代码卫生
- 正确的补丁在规范对齐和完整性维度接近满分,但仍可能在文件变更和运行时检查上失分
超越测试的洞察:
- 评分标准能够识别测试未捕获的问题(如不必要的编辑、缺失的边缘情况处理)
- 即使测试通过,评分标准也可能标记出潜在问题(约54%的情况被认为是高价值警告)
4. Agentic Rubrics的关键优势与实用价值
4.1 与传统验证方法的对比
Agentic Rubrics在软件工程代理验证领域带来了多重突破:
-
执行无关的轻量级验证:
- 无需设置复杂的执行环境
- 避免了测试执行的资源消耗
- 特别适合大规模、分布式部署场景
-
代码库上下文的深度利用:
- 通过主动探索代码库获取相关上下文
- 生成的评分标准针对特定代码库定制
- 比仅基于问题描述的方法更准确
-
细粒度的诊断反馈:
- 不仅提供通过/失败判断
- 给出多维度的质量评估
- 帮助开发者理解补丁的优缺点
-
与现有流程的无缝集成:
- 可作为代码审查的自动化辅助
- 与CI/CD管道兼容
- 为人工审查提供初步筛选
4.2 实际应用场景
Agentic Rubrics在以下场景中表现出独特价值:
持续集成与部署:
- 在资源受限的环境中提供快速质量检查
- 作为测试套件的补充验证层
- 识别测试覆盖不足的问题区域
团队协作开发:
- 确保代码变更符合项目特定约定
- 维护代码库的一致性和完整性
- 减少不必要的广泛修改
教育训练场景:
- 为学生提供结构化的代码质量反馈
- 帮助学习者理解软件工程最佳实践
- 自动化评估编程作业的多维度质量
遗留系统维护:
- 在没有完善测试套件的情况下提供质量保障
- 帮助理解复杂的遗留代码约束
- 确保修改不会意外破坏隐含约定
5. 实施指南与最佳实践
5.1 部署Agentic Rubrics的关键步骤
-
环境准备:
- 设置能够与代码库交互的代理环境
- 配置必要的工具链(文件搜索、内容查看等)
- 确保对敏感代码的访问控制
-
评分标准生成:
- 选择合适的专家代理模型(如Claude Sonnet-4.5)
- 定义初始提示模板,明确评分维度和权重范围
- 实施结果验证,确保生成的rubrics.yaml可解析
-
补丁评分:
- 选择具有足够判断能力的评分模型(如GPT-5)
- 设计清晰的评分指令,确保一致的标准应用
- 实现分数聚合逻辑,支持加权计算
-
结果利用:
- 将评分结果集成到补丁选择流程
- 设置合理的通过阈值
- 提供可视化反馈,帮助理解评分详情
5.2 性能优化技巧
基于实验分析,我们总结出以下优化建议:
模型选择:
- 评分标准生成:优先使用前沿编码模型(如Claude Opus/Sonnet)
- 补丁评分:中等推理能力的模型通常足够
- 平衡成本与性能,考虑蒸馏小型专用模型
提示工程:
- 明确指示代理关注代码库特定元素
- 提供评分项示例和格式要求
- 鼓励生成更多细粒度的评分标准
流程优化:
- 缓存和重用生成的评分标准
- 对高重要性项目实施人工审核
- 定期更新评分标准以反映代码库演变
5.3 常见问题与解决方案
在实际应用中,可能会遇到以下挑战:
评分标准质量问题:
- 症状:评分标准过于笼统或与代码库无关
- 解决方案:增强代理的代码探索指令,提供更具体的上下文
评分不一致:
- 症状:相同补丁在不同运行中获得差异较大的分数
- 解决方案:标准化评分指令,使用更高能力的评分模型
过度约束:
- 症状:评分标准过于严格,拒绝合理的解决方案变体
- 解决方案:调整权重分配,增加评分标准多样性
计算成本:
- 症状:生成和评分过程资源消耗大
- 解决方案:对小型项目使用轻量级模型,仅在关键阶段使用强大模型
6. 未来发展方向
Agentic Rubrics为软件工程代理验证开辟了新的可能性,但仍有许多值得探索的方向:
-
与强化学习的深度集成:
- 将评分信号作为RL训练的奖励
- 研究对抗奖励黑客的技术
- 解决多步行为的信用分配问题
-
评分标准质量提升:
- 开发人工参与的反馈循环
- 建立评分标准模板库
- 针对常见失败模式定制提示
-
更广泛的应用场景:
- 扩展到非代码软件工程任务(如文档、设计)
- 适应不同编程语言和范式
- 支持多模态软件开发(如嵌入式系统)
-
生态系统建设:
- 开发开源工具链和标准
- 建立共享的评分标准数据集
- 促进社区最佳实践的交流
在实际部署Agentic Rubrics时,团队发现一个有趣的现象:针对某些复杂的历史遗留系统,自动生成的评分标准有时甚至比人工编写的测试用例更能捕捉系统的隐含约束和约定。这突显了代理深入探索代码库的能力,以及结构化评分标准作为验证手段的独特价值。