一张表很容易被读成代码 Agent 排行榜：OpenAI Codex 提交的 PR 在合并后 90 天内有 6.1% 被回退，Devin 是 14.5%，人类基线是 11.5%。问题是，这些数字记录了不同团队把不同任务交给不同产品之后发生了什么，并没有让五种 Agent 做同一批工作。
9 月 12 日提交的论文《Not All Agents Are Equal》追踪了 37,623 个带来源标签的 GitHub PR。它把评测从“任务做完了吗”推进到“代码合并后是否被回退、继续修改或消耗审核”，这比只看 SWE-bench 分数更接近维护者的日常。但这项研究最有价值的结论，不是哪家产品排第一，而是现场数据必须和任务分配、PR 大小、审核流程一起读。
所谓匹配基线，没有把相同任务交给不同 Agent
研究使用 AIDev 的精选子集：33,596 个 Agent PR，来自 2,807 个星标超过 100 的公开仓库，时间覆盖 2024 年 12 月 24 日至 2025 年 7 月 30 日。作者另取 4,027 个人类 PR，限定在出现过 Agent PR 的 810 个仓库和同一时间窗内，并限制每个仓库贡献的样本量，避免少数项目淹没其余样本。
这种设计让人类和 Agent 处在相近的仓库环境，却不是逐任务、逐仓库或逐 PR 匹配。用于五种 Agent 分析的样本仍覆盖更大的 2,807 个仓库；开发者也会自行决定把什么任务交给哪种产品。一个团队可能让 Agent 更新文档，另一个团队让它改认证逻辑，回退率差异会同时包含产品能力、任务难度和项目治理。
样本量也相差悬殊。Codex 有 21,799 个 PR，Claude Code 只有 459 个；中间依次是 Copilot 4,970 个、Devin 4,827 个和 Cursor 1,541 个。Claude Code PR 的中位改动规模是 495 行，人类是 52 行，其余 Agent 在 61 至 96 行之间。比较对象不仅做的事不同，改动体量也不在同一档。
因此，论文中的“匹配人类基线”应理解为共享时间和部分仓库环境的观察性对照，而不是可以回答“换成另一个 Agent 会怎样”的随机实验。
6.1% 与 14.5%，测到的是结果差异，不是产品因果
37,623 个 PR 中有 27,090 个已合并；只有拥有完整 90 天观察窗的 26,283 个进入维护分析。论文按产品给出的回退样本量和结果如下：Codex 17,756 个，回退率 6.1%；Devin 2,185 个，14.5%；Copilot 2,094 个，12.5%；Cursor 946 个，11.4%；Claude Code 267 个，10.5%。
相对 11.5% 的人类基线，Codex 的回退优势和 Devin 的回退劣势在多重比较校正后仍显著：二者的比值比分别为 0.50 和 1.31，95% 置信区间分别为 0.44—0.57、1.11—1.54。Copilot、Cursor 和 Claude Code 与人类的差异都不显著。
这说明来源标签能帮助维护者分配注意力，却不能证明 Codex 写得更好或 Devin 写得更差。论文没有控制任务类型、任务难度、开发者经验、仓库规则和具体模型版本；研究窗口里的产品也不是 2026 年 9 月正在销售的同名版本。把观察结果直接用于今天的采购排名，相当于把“谁被派去做什么”误当成“谁更会做”。
连“维护负担”本身也是代理量。研究只查询每个 PR 中改动最多的那个文件，计算其 90 天内出现多少次后续提交，再用 PR 的总改动行数归一化。这个数不是后来重写了多少行；分母越大的 PR，数值还可能机械下降。回退则依赖提交信息中的回退措辞，安静地重写或删除代码不会被计入。论文也明确把这两点列为效度限制。
安全味道只覆盖四分之一 PR，也不等于漏洞
安全分析进一步缩小到含 Python、JavaScript 或 TypeScript 新增行的 8,933 个 PR，占总样本 23.7%。研究用正则表达式寻找八类代码“味道”，包括硬编码凭证、eval/exec、命令注入和不安全反序列化。
合并五种 Agent 后，2.9% 的 PR 至少命中一种安全味道，人类是 4.6%，比值比为 0.63。差异主要来自硬编码凭证和 eval/exec 模式更少；按新增代码行计算的整体密度差异效应很小。论文还记录了一次探测器修正：早期的路径遍历规则把相对导入误报为风险，令该类别膨胀约 150 倍。正则命中适合做筛查，不能被写成“漏洞率更低”。
产品间的数字同样受规模影响。Claude Code 有 9.5% 的被分析 PR 命中安全味道，高于人类的 4.6%，但这一组只有 241 个 PR 进入静态分析，同时其 PR 中位规模约为人类的 9.5 倍。作者做了按规模分桶的敏感性检查，仍无法把产品能力与任务组合彻底拆开。
两项早期研究给出不同结果，差别在测量尺
同样基于 AIDev，1 月发布的《Beyond Bug Fixes》对 206 个 Python 仓库中的 1,210 个已合并修复类 PR 做 SonarQube 前后差分。它发现五种 Agent 的原始问题数量看似不同，但按代码改动量归一化后，多数差异消失。该研究没有人类对照，Claude Code 也只有 15 个样本，却再次说明 PR 大小足以改写产品比较。
7 月发布的另一项纵向研究追踪 182 个仓库的代码行生存、后续维护意图和静态分析结果。它同样发现 Agent 与人类代码的总体维护率没有显著差异，却测得 Agent 代码的纠正性维护率高 46%，而且项目不经审核就合并的比例越高，Agent 维护负担越重。
两项结论并不必然冲突。本研究数“改动最多文件上的后续提交”和带回退措辞的提交；另一项研究追踪代码行何时被后续提交终止，并区分修复、功能、重构等维护意图。一个 PR 可以很少被整体回退，却不断接受小修。测量尺不同，回答的问题也不同。
真正可用的不是榜单，而是一张审核路由表
这组数据给工程团队的直接启示，是把 Agent 来源加入审核路由，但不要单独使用。更稳妥的做法是同时记录任务类型、PR 大小、语言、仓库、测试覆盖、审核深度、产品与模型版本，再追踪回退、缺陷修复、静态分析变化和人工审核时间。只有在相近任务和项目条件下，产品差异才开始接近可行动的质量证据。
研究已经显示审核成本分布不均：有记录的 Copilot PR 平均得到 3.6 次人工审核和 0.43 次修改请求，Claude Code PR 首次人工审核等待时间的中位数是 12.6 小时。但审核数据只覆盖 Agent PR，且各组覆盖率从 5.4% 到 51.2% 不等，不能据此与人类审核成本对比。
论文称已经发布分析流水线、63 个变量的 codebook 和统计报告，但 arXiv v1 的正文与 TeX 源文件没有给出可访问的仓库地址。外部研究者目前可以核对方法、表格和图，却无法从论文链接直接重跑全部结果。这使下一步的检验很明确：公开工件、补上任务分层，在新版本 Agent 上重复同一套生命周期测量。到那时，37,623 个 PR 才可能从一张引人注目的结果表，变成真正能指导采购与治理的证据。
