AI Agent 把 PR 写得更快以后，review 为什么反而更贵了

正文

Agent 最擅长的，是把“开始写”这件事压缩到几分钟。它开分支、写提交、起草 PR 的速度，往往会让团队误以为开发已经提速。但一份改动从进入 review 队列到被长期维护，中间的人工判断并不会自动消失。

GitHub 文档已经把 Copilot cloud agent 描述为能研究仓库、创建计划、修改分支，并在需要时创建 Pull Request 的后台开发资源。GitHub 也提供 Copilot cloud agent 的 PR 生命周期指标，包括创建和合并的 PR 数、Agent PR 合并数、merged PR 的 median time to merge。参考：GitHub Copilot cloud agent 文档。

你不能只问“Agent 写了多少代码”。更实用的问题是：这些 PR 有没有占满 review 队列、有没有引入返工、有没有在合并后留下维护债。

PR 的供给被放大，审查能力却没有

一份 Agent PR 到底把哪些成本推给了团队

Agent 写 PR 之后，团队要付的成本至少有六类。

更合适的定位，是把 Agent PR 当成候选方案。它可以节省起草时间，却不会自动消除 review、测试和维护成本。

当“能生成”变成“都要 review”

AIDev 研究收集了 932,791 个由 OpenAI Codex、Devin、GitHub Copilot、Cursor 和 Claude Code 生成的 agentic PR，覆盖 116,211 个仓库和 72,189 名开发者。参考：AIDev 论文。

这说明 Agent PR 已经进入真实开源开发，不再只是演示功能。你需要给 review 队列设置入口标准。

如果团队没有入口标准，Agent 会把“能生成”变成“都要 review”。reviewer 的时间会被低价值改动吃掉。

Reviewer 面对的应该是候选改动，而不是免费代码

打开 diff 前，先判断它值不值得审

你打开 Agent PR 后，先不要逐行读 diff。先看五个信号，决定这个 PR 能不能继续审。

这个检查可以在几分钟内完成。通过后再进入细节 review；不通过就让 Agent 补计划、缩范围或关闭 PR。

合并权仍然是人类对风险的最后签字

PR 生命周期研究分析了 29,585 个 PR，覆盖 OpenAI、Copilot、Devin、Cursor 和 Claude Code 等工具。研究把工具分在 Collaborator 和 Assistant 光谱上：Cursor、Devin、Copilot 更集中体现 Agent 发起和推进 PR 的特征，OpenAI、Claude 更偏人类主导下的辅助。研究还指出，终端 merge authority 仍然主要由人类掌握。参考：Collaborator or Assistant?。

这对团队很关键：Agent 可以发起工作，但合并决策要留给人。你可以让 Agent 做这些事：

• 创建分支。
• 起草实现。
• 补测试。
• 回应 review comment。
• 更新 PR 描述。

这些动作不应该自动发生：

• 合并到主分支。
• 绕过 branch protection。
• 修改生产配置。
• 更新高权限依赖。
• 删除测试或降低质量门槛。

如果自动化执行了 merge，日志可能只记录执行者，不一定能还原真实决策者。团队要保留人类审批记录。

真正昂贵的部分，往往发生在第二轮修改之后

返工不是噪声，它才是 Agent 成本的一部分

很多团队只记录 Agent 节省了多少起草时间，却没有记录 reviewer 后来改了多少。返工才是 Agent PR 的关键成本。

任务级评估研究基于 AIDev-pop 比较了五类 autonomous coding agents，衡量 PR acceptance rate、review discussion volume 和 commit message quality。研究发现，不同 Agent 在接受率、review 讨论量和 commit 质量上差异明显；Copilot PR 触发的人类和自动 review 讨论量最高，commit-level quality 并不总是跟接受结果一致。参考：A Task-Level Evaluation of AI Agents in Open-Source Projects。

你可以在 PR 合并前记录四个返工指标：

• reviewer 改了多少行。
• reviewer 要求 Agent 重做几轮。
• CI 失败是否来自 Agent 误改。
• 最终合并版本和 Agent 初稿差多少。

如果某类任务经常需要人类大幅重写，就不要继续把它当成“AI 提效任务”。把它降级为“AI 起草材料”，或者直接改回人工实现。

大 PR 不是效率，它通常只是把复杂度塞给 reviewer

关于 Agent 如何修改代码的研究分析了 24,014 个 merged Agentic PR 和 5,081 个 merged Human PR，并比较 additions、deletions、commit 数和 touched files。研究发现，Agentic PR 在 commit count 上和 human PR 有明显差异，也在触及文件、删除行等方面呈现不同特征。参考：How AI Coding Agents Modify Code。

当 Agent 交出一个大 PR，你要先拆问题，而不是硬着头皮 review。

Agent 写得快，不代表 reviewer 要接受一个难审的 PR。难审本身就是风险。

CI 不该成为 Agent 反复试错的游乐场

Agent PR 触发 CI 失败时，团队很容易让 Agent 继续修。这个循环如果没有停止条件，会消耗 CI、review 和上下文预算。

GitHub Actions 中 AI bot footprint 的研究分析了 61,837 次 workflow runs，来自 2,355 个仓库，并覆盖 Claude、Devin、Cursor、Copilot 和 Codex 触发的 PR。研究发现，在仓库层面，AI agent 贡献频率和 workflow success rate 存在负相关。参考：Reliability of AI Bots Footprints in GitHub Actions CI/CD Workflows。

你可以设置三条停止规则：

1. 同一个 PR 连续两次 CI 失败后，Agent 停止自动修复。
2. 失败来自环境、依赖或 flaky test 时，人类先判断，不让 Agent 猜。
3. 失败涉及权限、数据库、迁移、部署时，PR 转人工处理。

Agent 可以读日志、总结失败、提出候选修复。它不应该在根因不清楚时反复扩大改动。

合并以后，代码才开始接受时间的审查

维护成本从合并后才真正出现

AI-generated code technical debt 研究分析了 304,362 个 verified AI-authored commits，覆盖 6,275 个 GitHub 仓库。研究识别出 484,606 个问题，其中 code smells 占 89.1%；每个 AI coding assistant 至少有 15% 的 commits 引入一个问题；24.2% 的 AI 引入问题在最新版本中仍然存在。参考：Debt Behind the AI Boom。

另一篇维护研究基于 AIDev 和 GitHub 分析了 100 个热门仓库中的 1,000 多个文件和约 3,200 次变更。研究发现，AI-generated files 后续维护频率低于 human-authored code，AI 代码后续修改更常见的是 feature extension，而 human updates 更集中在 bug fixes；大多数维护仍然由人类完成。参考：To What Extent Does Agent-generated Code Require Maintenance?。

你合并 Agent PR 前要确认三件事：

• 未来谁负责这段代码。
• 哪些测试能保护这段代码。
• 哪些文档或注释能让下一位开发者接手。

没有 owner、没有测试、没有可读上下文的 Agent PR，不应该因为“现在能跑”就合并。

把返工写进 PR，团队才看得见它

你可以把 Agent PR 模板改成能记录 review 和返工。

ai_pr_review:
  agent: "GitHub Copilot cloud agent"
  task_source: "issue-1284"
  change_scope:
    files_changed: 8
    modules:
      - "orders/export"
      - "tests/orders"
  risk_level: "medium"
  agent_iterations: 2
  ci_runs:
    passed: 1
    failed: 1
  human_rework:
    required: true
    reason:
      - "金额精度规则需要人工确认"
      - "补充历史订单回归测试"
  merge_gate:
    owner_confirmed: true
    rollback_ready: true

这段记录能让 reviewer 看到四件事：Agent 做了几轮、CI 跑了几次、人类改了什么、合并前还有哪些门槛。

比起代码行数，更值得看的几组信号

你可以每周看一张 Agent PR 成本表。

GitHub 文档已经提到，企业管理员和组织 owner 可以用 Copilot usage metrics 分析 Copilot cloud agent 创建的 PR outcome，包括创建、合并和 median time to merge。你可以把这些指标和团队自己的 review、CI、缺陷数据放在一起看。

Agent 不是少用一点就好，而是该放在合适的位置

哪些任务值得继续交给它

你可以用任务类型决定是否继续让 Agent 写 PR。

Agent 最适合做边界清楚、验证路径清楚的任务。任务越模糊，PR 之后的 review 和返工成本越高。

先把入口和退出规则立起来

已经在合并 Agent PR 的团队，通常会从这几项约束开始。

1. 给 Agent PR 设置入口标准：必须有 issue、验收标准、测试说明。
2. 给大 PR 设置拆分规则：跨模块、跨目标、跨风险等级就拆。
3. 给 CI 失败设置停止条件：连续失败后转人工判断。
4. 给 review 模板加返工字段：记录 Agent 初稿和最终合并差距。
5. 给高风险模块设置人工 owner：没有 owner 不合并。
6. 每周复盘 Agent PR 的合并率、review 轮数、CI 失败和 post-merge fix。

这些动作能把 Agent PR 从“自动产生更多改动”变成“可筛选、可审查、可维护的候选改动”。

结语：PR 要按维护成本定价

AI Agent 写 PR 的速度很快，但软件团队最后付钱的地方不止模型和 token。reviewer 时间、CI 队列、返工轮次、合并后缺陷和长期维护，都会进入真实成本。

Agent PR 需要像工程资产一样验收：范围清楚、测试有效、风险可见、owner 明确、返工可追踪。通过这些检查后，它才可能减少团队负担。

如果一个 Agent PR 让人类花更多时间理解、修正和维护，团队只是把编码时间转移到了 review 和维护阶段。

参考来源

相关文章