Agent PR 合并率 90% 仍可能掩盖工程工作流弱点

当一个编程 Agent 提交十个 Pull Request，审阅者合并了八个，80% 的接受率看起来是一个有用的绩效指标。它告诉我们大部分提交的变更通过了审查。它没有告诉我们的是：Agent 是否在重要的问题上工作、是否缩短了交付时间，或者是否让产品处于更好的状态。

分母只包含我们交给 Agent、并且允许其提交的工作。一旦团队开始优化这个比率，他们就有动机将小型、明确规范的变更交给 Agent，而将模糊、高影响力的工作留在其他地方。这个指标可能在 Agent 对团队真正瓶颈几乎没有贡献的情况下仍然得到改善。

接受率衡量的是已提交的作品集

Pull Request 接受率很简单：

已接受的 Agent Pull Request ÷ 已提交的 Agent Pull Request

两部分都在审查开始前就被塑造了。有人选择任务、决定 Agent 的尝试是否拿得出手、以及选择是否真正打开一个 Pull Request。一个在本地分支中被放弃的失败尝试可能永远不会进入分母。

任务类型也会改变结果。2026 年的一篇论文分析了 AIDev 数据集中 7156 个 Agent 生成的 Pull Request。文档更改的接受率为 82.1%，而新功能的接受率为 66.1%。在所有类别中，报告的范围从琐碎任务（chores）的 84.0% 到性能工作的 55.4% 不等。作者将任务类型描述为主要因素，同时也指出另一种解释：不同类别的审查标准可能不同。这是来自公共仓库的观察性证据，而非同一差距存在于每个公司内部的证明。

另一项研究检查了 157 个开源项目中的 567 个 Claude Code Pull Request。报告指出开发者倾向于将 Agent 用于重构、文档和测试。虽然 83.8% 的 Pull Request 被合并，但其中只有 54.9% 无需进一步修改。

这些研究没有确立任何单个变更的业务价值。它们说明了为什么一个未分段的接受率难以解读：工作的混合比例以及合并背后的人类修正都至关重要。

满分可以来自狭窄的任务分配

考虑一个假设的 B2B SaaS 待办清单，包含三个变更：

• 修正文档中的一个 API 示例。
• 为一个缺失的可选字段添加校验。
• 跨计费系统、访问控制、存储文件和出站 Webhook 更改订阅取消流程。

前两个任务边界明确、易于验证。第三个跨越多个系统、包含未解决的产品决策，并且有更大的回滚成本。假设 Agent 完成了前两个，两个 Pull Request 都被接受，团队手动处理取消变更。

Agent 的接受率是 100%。这是准确的。但也是不完整的。

当然，Agent 移除了两个有用的工作，所以我不应该Dismiss这个贡献。但问题出现在我们用这个分数回答一个不同的问题时：这个工作流能承担多少有价值的工作？该指标没有代表第三个未被尝试的任务、其相对影响力，或者审阅者在修正已接受的第1和第2个变更时花费的精力。

这是一个更广泛的测量问题。在对 2026 年 1 月七名 METR 技术人员的编码 Agent 记录进行的探索性分析中，METR 明确警告了任务选择和任务替代问题。人们在期望获得帮助的地方使用 Agent，有时完成了有用但价值较低的任务——如果不做这些，他们可能根本不会去做。因此，作者将观察到的任务级时间节省作为生产力提升的软上限，而非生产力倍数来处理。

审阅工作量不在分子中

一个已合并的 Pull Request 可能只需要五分钟检查，也可能需要多轮修正。接受率将两者都算作一次成功。

对于 Agent 工作，隐藏的工作量可能包括：澄清工单、恢复 Agent 削弱的断言、检查租户边界、重新运行不稳定的测试、或者重写变更以使其符合现有设计。最终的合并告诉我们审阅者接受了结果代码。它没有说明这个结果有多少来自 Agent。

拒绝也有类似的模糊性。对困难迁移的有价值尝试可能发现一个未文档化的依赖，即使其 Pull Request 未被合并。一个微小的变更可能立即被接受。如果我们只按比率奖励团队，更安全的策略是提交更多第二类变更。

务实的回应不是停止追踪接受率。而是保留诊断信号，并添加解读它所需的上下文。

在审查前、审查中、审查后衡量工作

我会通过五个相互关联的问题来评估 Agent 工作流：

这些类别不需要复杂的评分模型。先将文档、测试、修复、功能、迁移和性能工作分开。只在同一组内比较接受率，并展示每个阶段已尝试、已放弃、已提交和已合并的任务数量。

对于任务成功，使用变更本应产生的行为来衡量。OpenAI 的 SWE-Lancer 展示了一种在评估中使此具体化的方法：它包含超过 1400 个真实的自由软件工程任务及实际报酬，而独立任务由经验丰富的工程师审查三轮来评分。这是一个基准，不是衡量内部团队的模板，但其设计将任务结果和经济上下文与补丁是否仅仅看起来可接受分离。

交付指标可以将 Agent 的贡献与周围系统连接起来。DORA 当前的软件交付指标包括变更前置时间、部署频率、失败部署恢复时间、变更失败率和部署返工率。这些是团队级指标，不应完全归因于 Agent。它们有助于揭示更多的已接受 Pull Request 是否与更安全、更快速的交付相吻合。

将接受率放在适当的位置

Pull Request 接受率对于发现摩擦点很有用。按任务类型分段、检查拒绝原因、追踪 Agent 输出是否通常需要相同的修正。它可以告诉我们工作流在哪里产生了可审查的变更。

更大的决策需要更宽的分母。包括 Agent 尝试的任务、我们选择不给它的任务、以及将其输出转化为生产软件所需的人类工作。然后将这些结果与交付和产品成果连接起来。

如果我必须从头开始，我会从一个月有 Agent 辅助的工作开始。按类型和不确定性标记每个任务、记录尝试是否达到审查、对已接受 Pull Request 背后的修正进行抽样。然后我们就可以判断 Agent 是在扩大团队能完成的工作，还是在非常高效地处理本来最容易接受的工作。

Originally published on nulltensor.com.