代码审查智能体基准：如何评估审查者，并在您自己的代码上运行 c-CRAB

如何判断一个代码审查代理好不好？在这个领域短暂的历史中，大多数时候答案是“衡量它的评论与人类审查者的评论有多接近”——这听起来合理，直到你真的去尝试，因为两个审查者可以用完全不同的措辞提出同一个问题。代码审查代理基准（Code Review Agent Benchmark）——论文编号为 arXiv:2603.23448，数据集为 c-CRAB——是第一个认真尝试根据采纳评审意见后产生的结果、而非评审措辞来给评审打分的基准。它将 234 条人类评审意见转换为可执行测试，并用四个广泛使用的审查器运行——PR-Agent、Devin、Claude Code 和 Codex——结果发现，这四个加在一起只通过了其中 41.5% 的测试，用论文自己的话说就是“只有大约 40%”。本页是一份操作指南：如何正确解读这一结果而不至曲解，如何自行运行 c-CRAB，以及当你的代码库根本不在该基准中时该怎么做。

标题上的数字是这一页上最没用的信息。有用的是方法和失败模式：为什么早先每一种评分方案衡量的都是错误的东西，改用可执行测试来给评审打分要付出什么代价，以及为什么“评审代理只能捕获40%的bug”是对实际结果的三重误读。这里的一切都是社区对已发布的基准测试以及从业者运行经验的解读——而不是相关工具制造商的厂商建议。

为什么显而易见的指标不起作用

在c-CRAB之前，对代码审查代理的评估主要分为少数几类，论文自己的对比表（表1）展示了这一演化脉络。最古老的是文本重叠方法——BLEU、ROUGE、chrF及其同类，被CodeReviewer和ContextCRBench等基准测试采用。其核心思想是：当代理生成的评论与人类评论在n-gram上匹配时，就认为该评论是好的。但这种想法在代码审查中随处可见的一种情况下会失效：同一个缺陷用不同的措辞来描述。

论文的案例研究是最清晰的例子。在 python-telegram-bot 的一个拉取请求（PR #3514）中，人类审阅者和 Codex 都指出了同一个嵌套索引健壮性缺陷。Codex 的审阅在行为上是正确的——一个依据该审阅采取行动的编码代理生成了一个通过可执行测试的修复。然而，文本指标给它的评分为 BLEU-4 0.00、ROUGE-L 7.02、chrF 20.74，嵌入相似度 54.59。n-gram 重叠度为零，而审阅是正确的。同样的关注点，不同的措辞：字符串指标无法看出这一点。嵌入相似度是部分提升——54.59 相对于确认通过的结果仍然远未达到可用阈值——而且它以更柔和的形式继承了同样的问题。

LLM-as-judge，即让一个模型将智能体的评审与人类的评审进行比较并投票，解决了词汇问题，但引入了三个新问题，论文直接点名：偏见、不稳定性和对提示设计的敏感性。同样的比较运行两次，法官可能给出不同的裁决；重新措辞评判提示，排名就会变动。当你在同一基准上得分相差三分的两位评审者之间做选择时，具有这种偏差的法官无法支持一个决定——而一个你无法复现的分数，就不是分数。

可执行预言机带来了什么——以及它的代价

c-CRAB 所基于的理念既简单又激进：不是问“评审意见听起来像人写的吗？”，而是问“如果你依据评审意见采取行动，代码会被修复吗？”。每条被保留的人工评审意见都会被转化为一个可执行的测试，以捕捉其背后的根本问题。如果依据某条评审意见采取行动能产生行为上正确的修复，并使测试通过，那么该评审意见就算作正确——而且每个实例都附带一个可运行的 Docker 环境，因此“使测试通过”是一个事实，而非一种判断。

论文定义了两种测试。行为测试“在运行时导入并执行被测代码”，以“特定输入”调用函数，并检查“输出或验证异常”。结构测试“检查源代码文本、匹配模式，并检查 API 表面，以确定是否做出了预期的代码更改。”最终划分为 42 个行为测试（17.9%）和 192 个结构测试（82.1%）——这种倾斜值得一句诚实的话：这个 oracle 大部分是在源代码文本上进行模式匹配，而不是执行代码。金标准是行为测试；而数据集的大部分是它的务实版本。

构建 oracle 是一个四阶段的漏斗，每个阶段都会丢弃一些东西：

• 初始数据集 — 671 个 PR，1,313 条评审评论。

• 评审过滤 — 410 个 PR、595 条评论。一个 LLM 分类器，基于 100 条人工标注评论的黄金标准集进行校准，仅保留客观可验证的问题，并剔除对话式或主观的反馈。

• 可执行环境构建 — 410 个 PR，595 条评论。每个 PR 一个 Docker 镜像，在自动化失败时，依赖解析会回退到编码代理。

• 将自然语言评论转换为测试 — 339 个 PR，481 条评论。使用 GPT-5.2 在执行引导的优化循环下生成（最多三次尝试）；只有在前版本上失败、在后版本上通过的测试才会被保留。

• 使用编码代理进行验证 — 184 个 PR、234 条评论（最终）。Claude Code 在 Sonnet-4.6 后端上仅根据人类评审评论尝试修复代码；无法使测试通过的实例将被丢弃。

起始的拉取请求中约有27%能存活下来。直说吧，这是基于测试的预言机所付出的诚实代价：如果一条评论的可操作性不足以转化为失败的测试，或者环境无法构建，或者一个能干的编码智能体无法仅凭评论修复代码，那么该实例就会被丢弃。这也是基准测试规模小的原因。184个PR实例和234条经过验证的评论，是一个你可以阅读的数据集，而不是一个会让你淹没其中的语料库——而且对于一个必须运行真实Docker环境的预言机来说，小规模是一种优势。

作为规模参考：平均每个实例涉及418.1行修改的代码，测试平均31.8行，每个实例有1.27个测试。两位标注者在50个采样实例中，对于生成的测试是否忠实捕捉了人类评审者的关注点，有84%的时间达成一致。

如果你亲自去读这篇论文，会发现一个文献上的瑕疵：数据集表格（表4）列出了67个仓库，而“威胁有效性”一节却说“56个仓库中的184个拉取请求实例，含234个可验证的预言机”。论文在不同位置分别给出了这两个数字，且没有将它们调和一致。不要偏信其中一个，也不要把它们平均——在各自出现的地方分别引用即可。诸如此类的差异，正是读者用来判断一个基准是否值得花时间的细节。

为了在独立性方面进行尽职调查：论文披露，一位作者隶属于 SonarSource，并声明研究结果不应被解读为“对 SonarSource 产品质量的评估”。这就是他们的免责声明，是直接引用而非转述。

如何在不误引的情况下阅读 c-CRAB 上的乐谱

首要指标是通过率：每个实例中，该 PR 的测试通过的比例，在 184 个实例上取平均。以下是论文中的完整结果表，每个评审者一行。人工行是标尺标记而非竞争者——人类编写了 Oracle，因此他们按构造得分为 100%：

• Claude Code — 1,336 条评论，每个 PR 7.3 条，总体 32.1%（行为 38.1%，结构 30.7%）。

• Devin — 1,344 条评论，每个 PR 7.3 条，总体 24.8%（行为 31.0%，结构 23.4%）。

• PR-Agent — 524条评论，每个PR 2.8条，整体23.1%（行为性38.1%，结构性19.8%）。

• Codex — 324条评论，每个PR 1.8条，总体20.1%（行为性38.1%，结构性16.1%）。

• 人工 — 234 条评论，每个 PR 1.3 条，100% 由构造保证。

有三点需要更正，因为摘要中“仅约40%”这个数字是当前AI编程讨论圈里被引用错误最多的数字。第一，41.5%这个数字——234项测试中有97项至少被一个工具通过——是全部四位评审者的并集：只要任何一个智能体通过了某项测试，该测试就计为一次。没有任何单一智能体拿到41.5%；最高单项得分是Claude Code的32.1%。第二，人类那一行是基准（oracle），不是参赛者；将其说成“人类打败了机器人”是范畴错误。第三，也是最重要的一点：c-CRAB不会对人工评审者从未提出的有效问题给予任何计分。基准就是人工评审的意图。一个发现没人提到过的真实bug的智能体，在这一项上得分为零。因此，“AI评审智能体只能发现40%的bug”这个说法错在三处——它是一个并集，它不是bug发现率，而且它衡量的是与人工评审者的一致性，而非总体正确性。

评论数量是陷阱

结果中最有趣的数字并不是获胜者。Claude Code 和 Devin 各自发布了超过 1,300 条评论——大约每个 PR 7.3 条——分别达到了 32.1% 和 24.8%。Codex 发布了 324 条评论，大约每个 PR 1.8 条，达到了 20.1%。人类基线是每个 PR 1.3 条评论。数量不等于覆盖率：大约五倍的评论量，换来的通过率却不到两倍。如果你在选择评审者，这些额外评论的真正代价是人类评审疲劳——智能体发布的每条评论都是一个需要人工处理的判断。

有用性的发现则指向相反方向，正是这一点使这不仅仅是一个廉价的“机器人很吵”的故事。作者人工检查了6个PR中的92条评论，判定84%（77/92）为有用——PR-Agent 94%，Codex 88%，Devin 85%，Claude Code 78%。因此，大多数未通过测试的评论并非噪音；它们涉及的是人类审查者未提出的问题。样本很小——92条评论、6个PR——这一点应该与这些百分比同时提及。

双方实际讨论的内容决定了结果呈现出的形态。人类评审者更偏向可维护性、设计和文档；工具则更偏向健壮性、测试和错误处理。论文将此解读为支持人类与智能体协作而非取代的论据——这也是对分数为何偏低的现有最佳解释。一个对边界情况敏锐但对设计兴趣寥寥的评审者，会系统性地遗漏人类标记的那些类别，而参照基准完全是由人类标记构建的。

经历过这些的实践者最终会得出相同的结论。Daniel Vaughan 在一篇详细分析文章中把这项工作称为 CR-bench，并得出同样的结论，将其转化为一个工作流程：让智能体负责鲁棒性和正确性的全面扫描，把设计、规范和架构——这些智能体得分最低的类别——留给人类，并通过点名这些薄弱类别的审查指令来引导智能体。他对任何阅读排行榜的人最有用的告诫是：“有用性不等于通过率”，因为测试套件要求匹配人类预期的修复方案，而一个有效的替代修复方案反而无法通过测试。在他看来，从20%到明显更高分数的路径不是模型升级，而是配置工作。

自行运行 c-CRAB

以上内容都是在解读他人的成果。复现包让基准测试可运行——它位于c-CRAB-Benchmark/dataset的GitHub仓库中——README也如实说明了运行所需的条件。

要求：code>uv sync/code>；Docker；以及以下任一：code>OPENAI_API_KEY/code> 或 code>ANTHROPIC_API_KEY/code>（Claude Code 还会从 code>~/.claude/.credentials.json/code>，默认情况下已挂载到容器中）。布局包含五个目录：code>pipeline//code>（流水线逻辑和提示词），code>execution//code>（Docker 镜像构建器和运行时辅助工具），code>results_preprocessed//code>（已发布的基准测试子集），code>results_pipeline_funnel//code>（stage0–stage4 的 JSONL 文件和漏斗摘要），以及 code>raw_results_compressed//code>（原始实验输出）。五个步骤依次为：

1. 构建 Docker 环境 — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>。如果您想跳过构建，也可以使用 c-CRAB-Benchmark GitHub packages 组织下发布的预构建镜像。

2. 生成测试：code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>。

3. 收集基线评审 — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>。在此步骤之前，请配置相应的外部工具凭据。

4. 运行代理解析 — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. 评估——每个工具重复一次：code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>。

README 没有提及两件事。要添加第五位审阅者，就需要编辑 code>run_batch_baselines.py/code>——各工具的基线审查提示词就存放在该文件中，而且没有插件接口；README 也没有记载更简洁的扩展点。此外，该仓库没有附带明确的许可证文件，因此不要假定代码采用 MIT 或 Apache 许可——论文采用 CC BY 4.0，而代码自身的条款并未说明。

成本是另一个未被提及的事项。论文没有公布运行该流水线的token或美元数字，因此网上引用的任何成本数字都应视为未经证实。结构所暗示的已经足够清楚：184个实例中每个PR对应一个Docker镜像，再加上每个工具的编码代理解析流程和评估流程。这不是一台笔记本电脑一下午就能完成的工作——要为真正的计算资源做好预算。

当您无法负担可执行的预言机

大多数团队的诚实立场是：基准测试是对的——LLM 评判器无法为评审打分；但为自己的 PR 构建基于测试的预言是一项繁重的工作。值得划出的区别在于：LLM 评判器作为评分器与作为过滤器。c-CRAB 拒绝将评判器用作预言，但这并不代表评判器在评审器内部毫无用处——一个能够聚类重复发现并剔除薄弱发现的评判器，仍然可以提高精确度。需要针对性设计防范的失效模式是独立性。

在审阅者自身模型上运行的评判者会自我认同：它读取审阅内容，觉得言之有理，便报告成功，但实际上什么也没改变。改用不同供应商的评判者可以降低这种自我认同——它不会把评判者变成测试，但能阻止橡皮图章式的盲批。因为我们自己的评估框架是开放的，我们可以向你展示一个恰好对应这一护栏的具体、可核查的实例：Orca-Code-Review 在 GitHub 上采用 MIT 许可证，其路由配方用仓库自己的话阐述了这条规则——评判者“不得提及默认模型的名称”，因为“在审阅者自身模型上，它会自我认同，于是通过操作形同虚设，却仍报告成功。”该 Action 从不指明模型；由路由配方决定。按当前配置，审阅者的默认模型是 deepseek/deepseek-v4-flash-0731，而一条匹配 code>x-cr-lens: judge/code> 头的规则会将评判者调用发送给 z-ai/glm-5.3——一个不同的供应商。这是与 c-CRAB 论点平行的设计，而非结果：我们不在基准测试中，也没有针对我们审阅者的 c-CRAB 评分。但对于任何无法构建可执行预言机（oracle）的人来说，这都是可用的实际缓解措施；而且当评判者和审阅者可以在同一个密钥（key）下分属不同提供商时，成本很低——这正是路由器的用途所在。在 OrcaRouter 上，审阅者及其评判者只是路由 DSL 中的两行配置，你按提供商的标价付费，零加价。

当你的代码不在基准测试中

184个PR分布在56或67个公共仓库中，这并不是你的代码库，也从来不会成为你的代码库。可迁移的部分是方法，你可以在自己的历史记录上以更小的规模运行它。选取那些有人工评审意见的已合并PR。对这些意见中的一部分样本，编写一个测试，使其在评审意见被采纳之前失败，而在采纳之后通过——“先失败后通过”这一特性才是整个游戏的关键。在评审前的diff上运行你的候选评审器。然后检查根据它的意见进行操作是否能让测试通过。你得到的数字是基于你实际发布的代码计算出来的，这比排行榜上的名次更有价值。而它的代价恰恰是论文所撞上的那堵墙：你需要可重现的、每个PR独立的环境，因为一个只在你自己笔记本电脑上通过的测试并不能作为判定标准。

你不需要234个测试。在你们团队真正争论过的PR上精心挑选十几个，比基准分数更能让你了解你的评审者。而对该基准家族的一份并行从业者分析在门槛问题上直言不讳：LLM分类器判断一条评论是否为有效且可验证的问题时，精确率介于66%到85%之间。因此，要把机器过滤当作候选名单，并在任何内容变成测试之前保留人工裁决环节。该文还指出，LangChain的ReviewBench基于同样的评论转测试思路独立构建，最多只能恢复其基线问题中约30%——与c-CRAB的20%–32%处于同一范围，这也提醒我们，工具之间个位数的排行榜差值往往小于自己环境中的噪声。

如果你完全是在决定该买哪款审查工具，那是个不同的问题——我们的代码审查代理购买指南涵盖了机器人vs代理、按席位vs按令牌的定价，以及自托管何时更胜一筹——而一旦你拥有了工具，每次推送时运行审查框架的持续成本则包含在我们的自动化代码审查说明中。本页只关注度量，而本篇的配套文章会带你了解基准测试的构成：构建漏斗、数据集统计和完整的结果表。

常见问题

41.5% 是最佳智能体的分数吗？不。41.5% 是四种工具的并集——只要其中任何一个工具通过了某项测试，该测试就计为一次。最佳单一分数是 Claude Code 的 32.1%。

c-CRAB 是否衡量审阅者发现了多少个漏洞？不。它衡量的是审阅结果与人类审阅者提出的内容（已转化为可执行测试）的匹配程度。一个人类审阅者从未提及的真实缺陷，无论多么有效，其得分都为零。

人类评审员是否“击败”了机器人？100%人类那一行本身就是基准——测试由人类编写——因此它是标尺，而不是竞争对手。

c-CRAB 和 CR-bench 是同一个东西吗？ 是的。数据集是 c-CRAB；一些第三方报道称它为 CR-bench，但这里只有一个基准。

运行它需要多少成本？论文中没有公布成本数据。每个PR对应一个Docker镜像，共涉及184个实例，再加上一次代理解析过程，这意味着实打实的计算量——不是笔记本电脑规模一下午就能搞定的。

底线

c-CRAB 的贡献不在于排行榜本身，而在于它证明了：可以通过执行评审建议来为评审打分，而此前的文本相似度方案和 LLM 评审方案都在给错误的对象打分。如果只能记住一点，那就是这三项修正：41.5% 是并集，人类那一行才是 oracle，基准对人类从未提出的缺陷不给任何分数。如果你想要一个能据此行动的数字，这个方法是可以迁移的——在你自己的已合并 PR 上运行先失败后通过的测试，加入人工裁定步骤；如果无法构建可执行的 oracle，至少使用一个模型独立于评审者模型的裁判。

如果你宁愿度量一个评审器，而不是争论一个评审器，那就从一个你能读懂的测试框架开始。OrcaCode Review会运行一次评审遍，外加一位独立的验证裁判，按 token 而非按席位计费，并且其中的每个提示词都是公开的——因此，你可以把它指向像这样的基准测试，得出你自己的数字，而不是我们的。