Michael JohnsonAI审查代理即使留下几十条评论，也仍可能漏掉对发布至关重要的缺陷。2026年10月5日，GitHub推出了ReviewBench研究预览版，这项基准测试根据代理发现的问题、漏掉的问题以及意见的准确性来进行比较。
对开发者来说，重要的变化在于：评估重点从统计评论数量转向检查评论内容。该基准测试将代理的输出与拉取请求的问题参考集进行比对，并分别考虑问题的严重程度和类别。
ReviewBench具体评估什么
数据集包含来自187个采用开放许可证的代码仓库的219个公开拉取请求，涉及19种编程语言。GitHub表示，在构建数据集时，它分析了超过1.039亿个拉取请求的分布情况。仓库和语言的规模参考了GitHub整体样本的分布；同时，有意将变更规模偏向内容更丰富、适合进行审查的拉取请求。
每个拉取请求都附有标注严重程度和类别的参考意见，例如正确性、安全性、可靠性、可维护性和测试。ReviewBench会计算准确率——代理评论中有多少比例对应实际问题；也会计算查全率——代理发现了已知问题中的多少。Fβ指标可调整这两项标准的相对权重：提高查全率的权重适合尽可能多地发现问题；提高准确率的权重则适合减少噪声意见。
如何解读GitHub公布的数据
发布内容称，ReviewBench的标注结果与资深工程师独立复核结果之间的一致率为96.6%。这是对参考问题的专家评估一致性的衡量，并非任何AI代理的准确率。
此外，GitHub还介绍了针对Copilot代码审查模型集成方案开展的一项内部A/B测试。公司称，与对照组相比，后续引发相应代码修改的评论比例上升了8.0%，查全率提高了13.6%，评论数量增加了61%，审查成本降低了8.0%。这些数据来自GitHub的一项实验，并不代表对所有代理的评估，也不保证其他团队能获得相同效果。
将指标拆分开来，对团队选择审查设置尤其有用。意见数量增加可能伴随着有用发现的增加，但仅凭数量无法得知其中有多少得到确认。ReviewBench还按严重程度和类别拆分结果，让团队可以分别关注严重缺陷或安全问题等方面。
如何试用这项基准测试
根据GitHub的说明，研究预览版允许用户查看完整数据集、比较已发布的结果并运行自己的代理。初步运行提供25个拉取请求；完整运行则涵盖219个拉取请求，分为三轮。参与者需提供容器镜像、配置和自己的模型密钥，并由统一评审器进行评估。结果在提交内容经过审核和批准前保持私密。
实际使用这项测试，可以先建立一个可比较的基线，然后根据团队自己的审查规则以及仓库特有的变更来检验系统。不同团队的具体条件——例如使用的语言、架构、严重程度门槛和可接受的噪声水平——可能与通用数据集有所不同。
GitHub表示，在其开展的实验中，ReviewBench离线评估结果的变化方向与实际运行结果一致。已发布的测量数据来自该公司的内部测试。因此，目前这项基准测试最可靠的用途，是在共同数据集上比较代理并诊断其优势；至于是否部署，也应结合团队自身工作流程中的测试结果来决定。