c-CRAB，代码审查智能体基准：它衡量了什么，发现了什么，以及 41.5% 的真正含义

一个代码审查代理和一位人类审查者查看了同一个拉取请求，并提出了相同的顾虑。按照代理的评论进行修改后，该 bug 得以修复，测试通过。然而，作者计算出的每一项文本相似度指标都将代理的审查与人类审查判定为基本不相关：BLEU-4 为 0.00，ROUGE-L 为 7.02，chrF 为 20.74，嵌入相似度为 54.59。同样的顾虑，不同的措辞，而标准的审查评分方式却无法看出二者意见一致。这一个例子正是 c-CRAB（读作“see-crab”）即代码审查代理基准（Code Review Agent Benchmark）背后的论证依据，该基准发布于arXiv:2603.23448。

c-CRAB评估的是代码审查智能体，而不是代码编写智能体。给定一个拉取请求——它可能来自人类，也可能来自编码智能体——审查智能体生成一份审查意见，而c-CRAB根据采纳该意见后能否产生行为上正确的修复来为其评分。该基准由软件工程研究人员Yuntong Zhang、Zhiyuan Pan、Imam Nur Bani Yusuf、Haifeng Ruan、Ridwan Shariffdeen和Abhik Roychoudhury构建，并评估了四款工具：PR-Agent、Devin、Claude Code和Codex。其中一位作者隶属于SonarSource，论文中也明确说明了这意味什么、不意味什么，原文如下：“本文所表达的观点和结论仅代表作者本人，不代表SonarSource的官方政策或背书。此外，本文呈现的发现具有独立性，不应被解读为对SonarSource产品质量的评估。”

在详细说明之前，先提两点。一些第三方文章将同一项工作称为 “CR-bench”；它们是同一个基准，本页面通篇使用 c-CRAB。下文中的每张图表都是论文自行报告的结果，是今天从论文和复现包中读到的——并非独立重新运行——并且解读来自我们，再加上这篇论文已经引发的从业者讨论。这些都不是来自其工具被评估的厂商的指导。如果你还在犹豫是否要运行代码审查代理，我们的代码审查代理买家指南是更好的起点；本页面讨论的是这些代理是如何被衡量的。

为什么 c-CRAB 用测试而非 LLM 评判来给评论评分

对代码审查智能体进行评分的通常做法，是将其审查结果与人类的审查结果进行比较，使用 LLM-as-judge 或文本相似度指标。c-CRAB 的作者对这两种方式都持反对态度。他们认为，LLM-as-judge 存在偏见、不稳定性和提示敏感性问题，使得评分难以可复现、保持一致。而上述案例研究恰恰说明了字符串指标实际衡量的是什么：措辞，而非有效性。在那个 python-telegram-bot 的拉取请求中，Codex 的审查意见与人类所说的内容一致，但 BLEU-4 和 ROUGE-L 却无法识别出这一点。

所以，c-CRAB 的做法正好相反。每条人工评审意见都被转换成一个可执行的测试，用来捕捉其背后的本质问题。如果按照某条评审意见操作能够产生一个行为上正确的修复——即让测试通过——那么该评审意见就算作正确。每个实例都附带一个可执行的 Docker 环境，因此通过/失败的判定由运行代码来决定，而不是询问另一个模型两段文本有多相似。这就是为什么这很重要：评审的职责是改变开发者的行为，而测试是唯一能直接衡量这种改变的评分信号。

论文以它自己的话定义了两类测试：“行为测试在运行时导入并执行被测代码。它们用特定输入调用被测函数，并检查输出或验证异常。另一方面，结构测试检查源代码文本、匹配模式并检查API表面，以确定是否做出了所需的代码更改。”最终的划分是42个行为测试（17.9%）和192个结构测试（82.1%）。值得诚实地说一句：大多数oracle是对源代码文本进行模式匹配，而不是执行代码。这种偏差是一个真实的局限性，需要牢记。

基准是如何构建的，以及漏斗的成本

c-CRAB 构建于现有的 inclusionAI/SWE-CARE 数据集之上，该数据集提供带有提交元数据的拉取请求实例；c-CRAB 自身的贡献在于 oracle，而非 PR 语料库。数据整理流程运行四个过滤器，每个过滤器都会消耗实例。论文报告的漏斗如下：

• 初始数据集 — 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条经验证的评审意见、每个实例1.27个测试、每个PR平均修改418.1行、每个测试31.8行。两位标注者独立对50个抽样实例进行判断，看生成的测试是否忠实反映了人工评审者的关切，他们的判断一致率达到84%。

如果仔细阅读，你会注意到一处不一致：数据集表格列出了 67 个仓库，而有效性威胁部分则写道“56 个仓库中的 184 个 pull request 实例包含 234 个可验证预言”。论文在不同位置给出了这两个数字，我们不会对它们取平均值，也不会默默选用更方便的那个。读者正是通过这类细节来判断一个基准是否值得他们花时间，因此这里按原文同时列出这两个数字。

结果，以及如何解读它们

通过率是总体测试通过率：对于每个实例，它是指该 PR 的测试中通过的比例，而主要数字是所有实例的平均值。论文按工具报告：

• Claude Code — 1,336条评论，每条PR平均7.3条 — 行为层面38.1%，结构层面30.7%，总体32.1%

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

• PR-Agent — 524条评论，每个PR平均2.8条 — 行为方面38.1%，结构方面19.8%，总体23.1%

• Codex — 324条评论，平均每个PR 1.8条 — 行为38.1%，结构16.1%，总体20.1%

• 人类——234 条评论，每个 PR 1.3 条——100% 由构造保证。人类编写了 oracle，因此这一行是标尺标记，而非竞争对手。

在引用任何一行之前，请仔细阅读那些行。摘要中的“仅约40%”是一个并集：在234项测试中，有41.5%至少被四个工具之一通过。它不是任何单个智能体的分数——最佳单项得分是Claude Code的32.1%——也不意味着四个工具合起来发现了40%的真实缺陷。下文解释了原因。

最有趣的数字不是赢家。Claude Code 和 Devin 各发布了超过 1,300 条评论——大约每条 PR 7.3 条——分别达到 32.1% 和 24.8%。Codex 发布了 324 条，每条 PR 约 1.8 条，达到 20.1%。人类基线是每条 PR 1.3 条评论。算一下：大约四倍的评论量换来了不到两倍的通过率。数量不等于覆盖率。一个健谈的评审者不等于一个有用的评审者，而 c-CRAB 是第一个为此设立的基准。

实用性反而会起反作用

低通过率读起来像是一种谴责，直到你看到作者还测量了哪些内容。他们人工检查了6个PR中的92条评论，判定其中84%是有用的（92条中的77条）——PR-Agent 94%，Codex 88%，Devin 85%，Claude Code 78%。所以，大多数未通过c-CRAB测试的评论并不是噪音；它们涉及的是人工审查者没有提出的问题。样本很小——92条评论，6个PR——论文中是这样说的，我们也应该这样说。

评审者们所谈论的内容中也出现了同样的模式。人类评审者偏向可维护性、设计和文档；工具则偏向健壮性、测试和错误处理。论文将此解读为支持人类与智能体协作而非取代的论据。这也是对分数为何偏低的最佳现有解释：智能体和人类往往关注的不是同一事物，而评估基准只对人类的清单给予奖励。

c-CRAB 无法看到的内容

该基准测试明确指出了自身的盲点，我们也一样。c-CRAB 不会对人类评审者未提出的有效问题给予任何分数。其评判标准是人类评审意图：如果一个智能体发现了没人提到的真实缺陷，那么它在这方面的得分为零。论文直接指出——自动化评审工具可能会生成其他人类评审者未识别出的有价值评论，但“与其他现有基准测试一样，c-CRAB 并不直接评估这些额外评论。”

这一句话就是对这一结果的大多数报道的纠正。任何引用“审查智能体只能解决40%”的人，若是把这当作衡量智能体捕获了多少真实缺陷，那就是在误读这个数字。它衡量的是这些智能体共同解决了多少人类提出的关切——一个更狭窄、也更诚实的说法。

自己运行

如果你想复现这些数字，或添加自己的审阅者，复现包公开位于 c-CRAB-Benchmark/dataset。README 就是实际文档，它如实描述了项目的样子。设置方法是 code>uv sync/code>；你需要 Docker 和一个 code>OPENAI_API_KEY/code> 或 code>ANTHROPIC_API_KEY/code>，此外 Claude Code 还会从 code>~/.claude/.credentials.json/code> 读取凭据。该组织还为这些环境发布了预构建的 Docker 镜像。

布局：code>pipeline//code> 存放流水线逻辑和提示词，code>execution//code> 存放 Docker 镜像构建器和运行时辅助工具，code>results_preprocessed//code> 存放已发布的基准测试子集（410 个预处理实例），code>results_pipeline_funnel//code> 存放 stage0–stage4 JSONL 文件及漏斗汇总，以及code>raw_results_compressed//code> 存放原始实验输出。

完整复现整个过程需要五个步骤：构建 Docker 环境（code>execution.build_swe_care/code>）、生成测试（code>run_testgen_full.sh/code>）、收集基线评审（code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>）、运行智能体解析（code>run_batch_agent_resolution.py/code>）、然后进行评估（code>run_batch_tool_eval.py --tool <name>/code>）。如果你想添加第五个评审者，请注意，扩展点并不是插件接口：每个工具的基线评审提示词都位于code>run_batch_baselines.py/code>，而且 README 并未记录更简洁的方式——你需要编辑该脚本。

克隆之前，还有两点事实需要说明：论文以 CC BY 4.0 许可发布；仓库页面没有说明代码的许可证，所以不要假定其存在。此外，论文未公布运行该基准测试的成本或 token 用量数据——既然未公布，我们也不会去编造。而该流水线确实意味着：在 184 个实例上为每个 PR 构建一个 Docker 镜像，再加上一次智能体解析过程，这可不是一台笔记本电脑一个下午就能完成的事。

这对任何部署审查流水线的人来说意味着什么

c-CRAB 的核心论点是：LLM 评判器是一个不可靠的预言机。如果你无法构建可执行的预言机——大多数团队都做不到——那么最佳的缓解措施就是绝不要让评判器运行在生成该评审的模型上。与评审者共享同一模型的评判器会自说自话，验证环节就会沦为一道橡皮图章，仍然返回一个数字。

这正是我们随产品发布的审阅器背后的路由配方所要防范的失败——而且这是一个与 c-CRAB 的批评在设计上相平行的问题，而非基准测试结果。该评测框架仍然会运行一个 LLM 评判器作为第二轮检查：它会对发现的问题进行聚类，针对每个聚类是否为本次变更中的具体缺陷打 0–1 分，并丢弃所有低于阈值的聚类。而管理它的配方，code>recipes/orcacode-review.dsl.yaml/code>，是一个公开文件。该 Action 从不指定模型名称：它调用一个路由器别名，由配方来决定。在默认配置下，该配方只有四行——审阅器的默认模型是 code>deepseek/deepseek-v4-flash-0731/code>，而一条匹配头部 code>x-cr-lens: judge/code> 的规则会将评判任务发送到 code>z-ai/glm-5.3/code>，一家不同的供应商。配方本身的措辞要求评判器“不得提及默认模型的名称”，因为在审阅器自身的模型上，它会“与自身意见一致，从而使这一遍检查形同虚设，却仍报告成功”。

使用不同供应商的评测者会降低自我一致性，但这并不会让 LLM 评测者变成一项测试。c-CRAB 并未测试我们的评审者，我们也不会暗示它测试过。OrcaCode Review 运行一次评审流程，外加一个独立的验证评测者；按 token 而非按席位计费，而且其中的每个提示词都是公开的——所以你可以把它指向像这样的基准测试，得到你自己的数字，而不是我们的。

底线

c-CRAB 是首个代码评审基准，其评分的含义在大多数情况下值得信赖：只有当采纳评审意见能够修复代码时，才算通过。 headline 数字确实很低——最佳单一工具为32.1%，联合工具为41.5%——但这些数字衡量的是与人类提出的问题之间的重叠度，而非评审本身的质量，而有用性数据表明，大多数评论都是真实信号。具有持久价值的结论正是论文自身所论证的：数量不等于覆盖，智能体与人类关注的点不同，正确的部署方式是人与智能体协作。而且该基准是开放的，因此诚实的下一步是让您自己的评审器在上面运行，得到属于您自己的数字。