正文

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 的供给被放大，审查能力却没有

分流成本这个 PR 值不值得进入 review 队列
审查成本reviewer 要看多少文件、多少业务分支
CI 成本触发了多少测试、失败后重试了几次
返工成本人类要改多少 AI 已经写过的代码
合并风险这个 PR 是否改到权限、支付、数据、构建配置
维护成本三个月后谁能理解、修复、扩展这段代码
无 issue、无验收标准先退回，让 Agent 补任务说明
一次改太多模块要求拆成多个 PR
只改格式、注释、README批量处理，不单独占 review
依赖、权限、CI 配置要求人工确认风险和回滚
修真实 bug、补真实边界测试进入正常 review
一份 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 面对的应该是候选改动，而不是免费代码

  • 创建分支。
  • 起草实现。
  • 补测试。
  • 回应 review comment。
  • 更新 PR 描述。
  • 合并到主分支。
  • 绕过 branch protection。
  • 修改生产配置。
  • 更新高权限依赖。
  • 删除测试或降低质量门槛。
任务来源有 issue、错误日志、用户场景
改动范围文件集中，边界清楚
测试覆盖失败路径或业务边界
PR 描述能解释为什么这样改
风险说明标出兼容性、数据、权限影响
打开 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 做这些事： 这些动作不应该自动发生： 如果自动化执行了 merge，日志可能只记录执行者，不一定能还原真实决策者。团队要保留人类审批记录。

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

  • reviewer 改了多少行。
  • reviewer 要求 Agent 重做几轮。
  • CI 失败是否来自 Agent 误改。
  • 最终合并版本和 Agent 初稿差多少。
  • 同一个 PR 连续两次 CI 失败后，Agent 停止自动修复。
  • 失败来自环境、依赖或 flaky test 时，人类先判断，不让 Agent 猜。
  • 失败涉及权限、数据库、迁移、部署时，PR 转人工处理。
同时改业务、测试、文档、格式要求拆成业务 PR 和清理 PR
一个 PR 里包含多个目标按 issue 或验收标准拆
commit 信息看不出阶段要求重新整理 commit 或 PR 描述
diff 里有无关文件要求删除无关改动
测试只覆盖新实现要求补回归和失败路径
返工不是噪声，它才是 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 合并前记录四个返工指标： 如果某类任务经常需要人类大幅重写，就不要继续把它当成“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。 你可以设置三条停止规则： Agent 可以读日志、总结失败、提出候选修复。它不应该在根因不清楚时反复扩大改动。

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

  • 未来谁负责这段代码。
  • 哪些测试能保护这段代码。
  • 哪些文档或注释能让下一位开发者接手。
Agent PR 创建数Agent 是否开始制造队列压力
Agent PR 合并率哪类任务能进入主分支
Median time to mergereview 是否被拖慢
Review comments / PRreviewer 是否在反复纠错
CI failed runs / PRAgent 是否带来测试压力
Human rework ratio合并版本和 Agent 初稿差多少
Post-merge fixes合并后是否需要再修
Surviving code smellsAI 引入的问题是否长期留存
维护成本从合并后才真正出现

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 和返工。 这段记录能让 reviewer 看到四件事：Agent 做了几轮、CI 跑了几次、人类改了什么、合并前还有哪些门槛。

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

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

YAML
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

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

  • 给 Agent PR 设置入口标准：必须有 issue、验收标准、测试说明。
  • 给大 PR 设置拆分规则：跨模块、跨目标、跨风险等级就拆。
  • 给 CI 失败设置停止条件：连续失败后转人工判断。
  • 给 review 模板加返工字段：记录 Agent 初稿和最终合并差距。
  • 给高风险模块设置人工 owner：没有 owner 不合并。
  • 每周复盘 Agent PR 的合并率、review 轮数、CI 失败和 post-merge fix。
小范围 bug fix，有明确复现和测试适合 Agent 起草 PR
补测试、补日志、补文档适合 Agent，但要批量处理低价值 PR
跨模块重构先让 Agent 做计划，不直接开大 PR
权限、支付、数据迁移Agent 可辅助分析，PR 必须人工主导
CI/CD 配置小改可以尝试，高风险变更要人工审查
模糊需求先让 Agent 提问题和验收标准，不写代码
哪些任务值得继续交给它

你可以用任务类型决定是否继续让 Agent 写 PR。 Agent 最适合做边界清楚、验证路径清楚的任务。任务越模糊，PR 之后的 review 和返工成本越高。

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

已经在合并 Agent PR 的团队，通常会从这几项约束开始。 这些动作能把 Agent PR 从“自动产生更多改动”变成“可筛选、可审查、可维护的候选改动”。

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

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

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

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

参考来源

AIDev: Studying AI Coding Agents on GitHubarXivCollaborator or Assistant? How AI Coding Agents Partition Work Across Pull Request LifecyclesarXivA Task-Level Evaluation of AI Agents in Open-Source ProjectsarXivHow AI Coding Agents Modify Code: A Large-Scale Study of GitHub Pull RequestsarXivDebt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the WildarXivTo What Extent Does Agent-generated Code Require Maintenance? An Empirical StudyarXivReliability of AI Bots Footprints in GitHub Actions CI/CD WorkflowsarXivAbout GitHub Copilot cloud agentGitHub Docs

相关文章

AI Coding 跑得越快，GitHub 和 CI 为什么先开始吃不消智能编程 / 约 10 分钟7 个关键洞察：AI Coding 工具真正改变的不是写代码，而是验证代码智能编程 / 约 18 分钟AI 生成的测试都通过了，为什么还是漏掉真实 bug？智能编程 / 约 11 分钟AI 写代码最危险的不是报错，而是看起来能跑的代码：开发者必须警惕的五大陷阱智能编程 / 约 10 分钟AI 编程开始按量计费后，团队终于得给每次 Agent 长跑算账了智能编程 / 约 11 分钟当 AI Agent 开始替人动手，企业最先缺的不是更强模型智能编程 / 约 9 分钟如何让 AI 只改该改的文件：保障代码安全与项目完整的策略智能编程 / 约 9 分钟AI Coding 的下一步：从 prompt 技巧到工程约束智能编程 / 约 18 分钟

作者信息

luowj

关注 AI Coding 工具链、开发环境排障、工程发布和安全边界。文章优先基于官方文档、 真实报错、公开事件和可复现的检查步骤整理。

luowj1998@gmail.com提交文章反馈