衡量 AI 编程智能体吞吐量的关键在于同时审视两个相互制约的数据：已合并的 Pull Request 数量（PRs merged）与拒绝率（denial rate，即未合并即被关闭的 PR 所占比例）。再结合从制定计划到最终合并的交付周期（cycle time）以及单个已合并 PR 的成本，你就能准确判断智能体是否以合理的开销交付了真正被团队采纳的高质量成果。大多数团队最先汇报的指标是“已发起的 PR 数”，但这项指标本身并不能说明问题：智能体完全可以每天发起五十个无人问津、未被合并的 PR，在数字上营造出虚假的进展。本文将逐一界定各项指标、阐明指标恶化背后的深层原因，并展示 Ivy Tendril 与 Ivy 免费计算器如何精准追踪这些数据。

核心指标矩阵

指标	定义	指标恶化意味着什么
发起 PR 数	统计周期内创建的 Pull Request 总数	单独看毫无意义。若该指标攀升而合并数停滞，说明智能体正在生产团队并不需要的无用代码
已合并 PR 数	统计周期内成功合并的 Pull Request 总数	若发起数上升而合并数持平或下降：代码审查存在严重瓶颈，或者生成质量明显劣化
拒绝率	未合并即关闭的 PR 数，除以所有已关闭的 PR 数（已合并数加上未合并直接关闭数）	过高：任务计划有误、验证体系薄弱，或审查人在后期才予以否决。若总量极低且拒绝率接近零：说明智能体仅在处理毫无风险的细枝末节
交付周期	从任务计划生成到最终合并的历时	过长：任务在某个人工检查点发生积压。需要立即定位具体环节
单个已合并 PR 成本	统计周期内的 Token 总消耗或实际金额，除以已合并的 PR 数量	持续攀升：重试次数多、计划体量过大，或在低成本模型本可过关的任务上滥用了高价模型
自动化验证通过率	首次执行即通过测试、代码规范（lint）及构建的执行比例	过低：任务计划的规格说明模糊，或者智能体缺乏对当前代码库的必要上下文

其中有两个定义的计算方式需要特别注意。拒绝率的计算分母采用的是“已关闭的 PR 数”，而非“已发起的 PR 数”，这样可以避免将仍在审查中的未决 PR 错误地归类为已接受或已拒绝。单个已合并 PR 成本是将周期内的所有支出（包括那些因计划被拒绝或废弃而产生的所有花销），严格除以真正完成合并的 PR 数量。这是刻意设计的核算逻辑：被拒绝事务所消耗的成本，本质上就是最终成功交付成果总成本不可分割的一部分。

为什么已合并 PR 与拒绝率是不可分割的“诚实指标对”

任何单一维度的指标，都可以通过牺牲另一个维度的指标被轻易粉饰。

放宽智能体执行代码的准入门槛，发起的 PR 数量就会直线上升，但拒绝率也会随之水涨船高。
审查人员若草率通过审核，已合并的 PR 数量会迅速增加，但合并后的线上缺陷将急剧上升，拒绝率以完全错误的方式被压低。
若只允许智能体执行绝对安全的小修小补，拒绝率确实会降得很低，但已合并的 PR 数量将断崖式下跌。

这与 DORA 研发效能指标的逻辑如出一辙：吞吐量与稳定性始终成对汇报，正是因为任何单项指标都能通过牺牲另一项指标来被恶意“刷榜”。将已合并 PR 与拒绝率绑定评估则能有效抵御这种失真。若想在不增加拒绝率的前提下提高合并数，就必须促使智能体产出更多团队愿意合并的高水准代码；若想在不减少合并数的前提下压低拒绝率，就必须在前端改善任务计划和自动化验证，而不是消极减少任务执行量。忽视其中任何一个数字，都无法真正改善研发效能。

发起 PR 数之所以具有诱惑力，是因为它是智能体最先交出的直观产物，也最容易统计。然而，一个未合并的 PR 本质上是在索取其他团队成员宝贵的时间。将单纯的请求计数当成有效产出，是在变相奖励智能体给审查人员增加负担；而以合并为考核标准，则是在激励智能体把工作彻底做好并交付价值。

Ivy 自身的数据正是按照这一准则进行披露的。选择 Ivy 页面上展示的每日 PR 数量与拒绝率关系图，基于 2026 年 2 月至 4 月期间 Ivy 各代码仓库中的 1,946 个 Pull Request 真实数据。Ivy 团队在推行涵盖“规划、执行、验证、复核”的标准流程——即软件工厂体系后，日均 PR 处理量从约 10 个提升至 100 个以上。图表中 PR 数量始终与拒绝率并列展示，因为脱离了拒绝率，数量本身说明不了任何实质效能。

单个已合并 PR 成本与自动化验证通过率

当合并数与拒绝率被稳定掌控后，单个已合并 PR 的成本将明确揭示交付合格代码的实际经济代价。这是 CTO 最关心的核心商业指标。该指标必须以“每次已合并改动所消耗的美元或 Token”来计算，绝不能以单个任务计划或单次执行为单位统计，必须全面摊入重试损耗与被否决工作的开销。

此外，单个已合并 PR 成本还是暴露排队瓶颈的灵敏探针：根据利特尔法则（Little's law），在合并速率固定的前提下，待审 PR 的不断堆积必然意味着交付周期的拉长，无论团队是否正式进行了计时统计。以下三个要素直接主导着单个已合并 PR 的成本：

重试消耗（Retries）。 每次验证失败都意味着一次全新的重新运行。验证通过率是极具参考价值的先行指标：一旦该指标下跌，单 PR 成本通常会在数天后明显上升。验证关卡详细介绍了需要检验的维度，并阐释了为何前置的计划关卡最为关键。
计划体量（Plan size）。 庞大的任务计划单次执行消耗更高，且由于人工审查时更容易发现瑕疵，被拒绝的概率也大幅增加。将大型计划拆解为数个紧凑的子任务，通常能同时降低拒绝率和单 PR 成本，代价仅仅是审查总数略微增加。
模型选型（Model choice）。 如果某个更便宜的模型能以相同的通过率满足验证标准，就能带来立竿见影的成本节约。唯一的验证手段是记录每个计划的成本与通过率，并在同一代码库上对不同模型展开横向对比。

如需进一步了解从衡量开发者工作量到考核被接纳产出的整体演变，请参阅环内与环外：智能体工程背后的 KPI 转移。

Ivy Tendril 如何系统化追踪这些指标

Ivy Tendril 是一款本地优先（Local-First）的桌面端应用程序（支持 macOS、Windows 与 Linux），能够覆盖编程智能体从最初立项到生成合规 PR 的全生命周期，并在执行过程中自然留存上述各项指标数据，无需团队额外搭建任何监控埋点。

Dashboard 仪表盘： Dashboard 实时展示任务计划在各阶段的流转状态、成本关键指标、历史趋势图表，以及所关联仓库的 Git 动态。计划状态提供了打开、合并及拒绝的 PR 数据；Git 动态则还原了完整的合并轨迹。
按计划与任务统计成本： 系统为每个计划及计划内部的每次作业（Job）独立记录 Token 与开销。如果某个计划在通过验证前经历过 3 次执行任务，系统会完整罗列这 3 次运行记录，从而在底层架构上确保重试成本精准计入单 PR 成本。在 Jobs 面板中，每次作业的实时流式输出、工具调用（tool calls）以及对应开销皆一览无余。
多智能体与跨模型横向比对： Tendril 原生支持 Claude Code、OpenAI Codex CLI、GitHub Copilot CLI、Google Gemini CLI、OpenCode 以及各类 CLI 智能体，并允许针对不同任务计划灵活指派模型。因此，团队可以在不改动工作流的前提下，在同一代码库中精准评估各个模型的成本与通过率表现。
本地数据安全保障： 所有的任务计划、运行日志和成本明细均保存在本地计算机上。唯一的外部请求仅定向至用户配置的 AI 模型 API 以及 GitHub。

对于尚未部署 Tendril 的研发团队，Ivy 推出了一款开源免费的 PR Cost Calculator（PR 成本计算器）。它可以读取代码仓库的 GitHub 公开数据，计算 14 天滑动窗口内的已合并 PR 均值与拒绝率，帮助团队在流程改革前建立可靠的数据基线。建议今天就对你的主力仓库进行一次测算，并在引入智能体一个月后再次比对。

如何开始使用

建立基线：在团队的核心代码仓库上运行 PR Cost Calculator，记录 14 天滑动窗口内的已合并 PR 数与拒绝率。
安装 Tendril：curl -sSf https://cdn.ivy.app/install-tendril.sh | sh（macOS、Linux）或 irm https://cdn.ivy.app/install-tendril.ps1 | iex（Windows）。安装文档详见安装指引。
进行两周的任务计划运行，并持续观察 Dashboard：关注合并量、拒绝量、单计划成本及演进趋势。
手动核算一次单已合并 PR 成本（总支出除以成功合并量），确保全团队在这一数值成为正式上报指标前对统计口径达成共识。

Tendril 基础版本免费，并在 Functional Source License 协议下开放源码。针对团队协作功能、本地私有化部署、单点登录（SSO）以及 CI 验证结果导入等进阶需求，可在 Pro（每用户每月 59 美元）和 Enterprise 方案中获得支持。

常见问题解答

怎样的拒绝率算是理想区间？

行业内并不存在放之四海而皆准的绝对标准；通常如果拒绝率低至 0%，意味着团队可能只让智能体尝试了毫无风险的平庸改动。建议长期观测团队自身的指标走势，一旦拒绝率出现异常上升，应将其视为诊断任务计划质量与验证有效性的触发信号，切勿通过人为压制任务执行来粉饰数据。

单个已合并 PR 成本是否应计入人工审查工时？

如果你拥有持续且可复现的工时统计手段，可以将其计入。大部分团队通常先从自动统计的 Token 消耗和模型调用费用起步，待核算机制成熟稳定后，再把审查人员的时间成本折算在内。若在定义未清晰统一前过早混算，往往会导致不同月份之间的数据失去可比性。

这些指标与 DORA 指标有何区别？

两者在关注点上存在重叠。从计划生成到合并的交付周期与 DORA 的变更提前期（Lead Time for Changes）非常接近。但拒绝率在 DORA 中并没有直接对应项，因为 DORA 默认代码是由人类工程师编写的，仅关注它能否部署上线；而拒绝率关注的核心命题是“这项修改到底是否值得被接纳”——当海量代码改动由智能体自动生成时，这才是更具诊断价值的灵魂拷问。

开始使用 Ivy Tendril

准备好体验面向开发者的并行智能体编排了吗？

探索代码库：查看 GitHub 上的 Ivy Tendril（开源项目）。
查阅文档：访问 tendril.ivy.app 阅读集成指南。
预约架构咨询：发送邮件至 renco@ivy.app 预约 30 分钟的技术架构沟通。

评估 AI 编程智能体吞吐量：已合并 PR、拒绝率与单 PR 成本