Agent 把 PR 数量推高十倍后，Code Review 该从哪里收回控制权

发表于2026-10-16|更新于2026-10-23|视界AI研究

|浏览量:

今年 5 月到 9 月，Anthropic 的 monorepo 每日落地变更从约 2500 个涨到超过 30000 个。

这不是一个让人兴奋的效率数字。我看到它时，第一反应反而是，谁来读？

如果一个团队还把 Code Review 理解为资深工程师逐行扫 diff，这个问题没有答案。Agent 生成代码的速度一旦跨过某个阈值，人会立刻从创造瓶颈变成排队瓶颈。PR 越堆越多，review 就越像机场安检，大家都在催队伍快一点，但真正危险的行李不会因此少一件。

Anthropic 在 10 月 15 日公开了 Claude Code 团队自己的做法。6 月到 9 月，他们合并的 PR 数量翻了一倍多，需要 revert 的占比却下降了四成以上。更值得读的不是那个结果，而是他们没有用一个更聪明的 reviewer 来替代人。他们把 review 拆成一条持续运行的验证链，让机器读大部分代码，让人把注意力留给机器不该替你做的决定。

我觉得这是 Agent 编程进入下一阶段的分水岭。

问题不再是模型能不能写出一个像样的 patch，而是当 patch 以分钟为单位涌进来，团队怎样仍然知道自己在合什么。

逐行 review 已经不是质量机制了

先承认一件有点刺耳的事。很多传统 review，本来也没有真的在逐行发现 bug。

一个人打开几百行改动，花十几分钟理解上下文，留两条命名意见，最后点 Approve。这个动作有价值，它让作者感到有人看过，也能传递团队约定。但把它当作质量保证，会有点自欺欺人。真正棘手的并发条件、跨服务的副作用、某个历史兼容分支，往往不是靠扫一遍 diff 就能发现。

Agent 只是把这个旧问题放大了。

Anthropic 的数据很直观。Claude Code 团队自己的代码约九成由 Claude 参与编写，而 monorepo 的日变更量在四个月内超过十倍。此时要求人把每段代码读完，不叫严谨，叫把稀缺注意力花在不可规模化的地方。

他们换了一个问题来问。不是有没有人读过代码，而是这次变更可能出什么问题，哪一道检查最适合抓住它。

这两个问法差得很远。

前者把人工阅读当成仪式。后者承认不同故障有不同的捕获方式。格式错误交给 lint，类型不匹配交给 type check，已知回归交给测试，漏洞模式交给安全扫描，架构取舍和业务风险再交给人。

你想想看，Java 团队里一个 Spring Boot 接口把字段改名，最可靠的检查并不是某位同事盯着 DTO 多看三秒，而是编译、契约测试、消费者集成测试和灰度监控。反过来，如果一个 Agent 建议把支付状态从同步查询改成异步最终一致，CI 全绿也不够。谁承担对账失败，用户会不会重复扣款，补偿入口放在哪里，这些问题需要一个了解业务的人拍板。

人应该从低价值的阅读里退出来，但不能从责任里退出来。

真正的变化是 review 提前了

传统流程把 review 放在 PR 最后。代码写完，测试跑完，作者把链接扔到群里，接着等待另一个人切换上下文。这段等待常常比写代码更长。

Claude Code 团队把大量检查前移到 PR 出现之前。Agent 要先运行测试、构建或截图对比，并展示真实输出。随后用一个带新鲜上下文的 subagent 再看一次 diff。这里我特别认同新鲜上下文这个设计。

同一个 Agent 写完代码后立刻评价自己，很容易顺着原来的假设走下去。它知道自己想实现什么，就容易把实现里的漏洞解释成合理细节。另一个没有参与写作的 reviewer，至少不会背着同一套思维惯性。

这和人类协作也一样。写作者自己做第一轮检查很必要，但编辑的价值就在于他不在作者脑子里。

团队还把重复出现的 review 意见往源头挪。某个规范总是被 reviewer 指出，就写进 CLAUDE.md、REVIEW.md，或者干脆变成 lint rule。这个动作看似普通，其实是 Agent 时代很关键的组织能力。不要把同一种批评重复留在几百个 PR 评论里，应该把它变成下一次生成前就能读取的约束。

代码评审最好的结果，不是评论越来越漂亮，而是某类评论慢慢消失。

对于已有 Java 和 Spring 体系的团队，我建议先做一个很小的版本。不要急着接入全自动 reviewer，先列出过去两个月最常被人指出的十个问题。比如事务边界遗漏、Controller 直接泄露领域对象、Redis key 缺少过期策略、Webhook 重试不幂等。能用静态规则表达的写规则，必须依赖上下文的写成短小的 REVIEW.md。把模糊的团队经验变成 Agent 可读取、CI 可验证的东西，才是最划算的一步。

AI reviewer 不该只有一个，更不该直接拥有话语权

Anthropic 的流程里，每个 PR 都会先经过 Claude review。多个 Agent 并行找问题，再由另一组 Agent 对每条发现投票。只有足够多人判断为真的问题才会留给人看。纯样式、诊断信息或清理建议会被过滤掉，剩下的评论按严重等级排好。

这套机制听上去很重，但它是在处理 AI reviewer 最烦人的毛病，噪声。

人收到一条错误评论，通常几秒就能略过。Agent 作者收到一条错误评论，可能会认真改一遍，再触发新的 commit、新的 review 和新的反馈。两个 Agent 如果都没有停手条件，就会在一处根本不存在的问题上来回修，最后消耗掉比人工编写更多的计算和等待。

Claude Code 团队真的遇到过这样的情况。有一个 CLI PR 在一夜之间经历了五十多轮 review 和修复，直到作者主动叫停。随后他们复盘发现，reviewer 反复标出的内容里，约 59% 在第一轮时就已经存在。它不是持续发现新 bug，而是在旧代码里一遍遍挖出几个没价值的点。

这个细节太真实了。

许多团队一看到 AI review 能抓到更多问题，就会自然追求召回率。可是工程 review 不是垃圾邮件过滤器。多报一个问题也有成本，尤其在自动修复链路里，噪声会被放大为新的 diff、新的构建和新的不确定性。

Anthropic 后来加了几个收敛措施。三轮以后要求作者重新审视方案，只对新增 diff 做再审，要求 reviewer 标出一类问题而不是只挑一个位置，也不再重复已经发过的发现。调整之后，一轮 review 加修复就通过的 PR 从 65% 升到 78%，需要五轮或更多的 PR 从 8.9% 降到 1.5%，平均 review 轮数从 2.08 降到 1.32。

这组数据给我的提醒是，Agent 系统不是只要会找错，还必须会停止。

在 LangGraph 里做 reviewer 节点时，很多人只设计了 review 到 fix 再到 review 的闭环，却忘了给图定义退出条件。一个更稳妥的 state 至少该记录 reviewRound、已确认的 finding 指纹、剩余风险和升级给人的条件。相同指纹不再重提，超过轮数不再自动修，而是输出争议点和证据。

没有停手线的自治，不叫自治，只是循环。

把人放回高风险决策，而不是留在最后盖章

AI review 最大的误解，是机器多做一点，人就少负责一点。

Claude Code 团队给的边界很清楚。低风险的文档、文案、内部功能和 feature flag 后的增量改动，在自动检查和安全检查都通过后，可以不要求人工批准。普通产品变更和缓存、自动更新器、system prompt 等敏感区域，要一位人类批准。最高风险的代码和指定路径，要两位人类批准。

决定层级的是变更，不是作者。

这个原则比按资历分审批更适合 Agent 时代。一个经验丰富的工程师让 Agent 改 CI workflow，风险并不会因为作者可信就消失。反过来，一个新人提交一处文档错别字，也没必要让两位 senior 排队。系统应该读变更类型、路径、影响范围和可回滚性，再决定人要投入多少注意力。

还有一条不能丢。Agent 的批准不能顶替所需的人类批准。谁指挥 Agent 做这次改动，谁就对它负责。Anthropic 的做法是，发起 Agent 任务的人可以算作要求的审批人之一，但不允许 Agent 自己占据人的位置。

我很喜欢这个姿势。它没有把人降格成机器人后的签字机，也没有把责任藏到模型输出里。

对于业务 Agent，这条边界更要收紧。一个 LangGraph 流程可以帮你生成客户跟进内容、查 CRM、创建工单，但涉及付款、权限授予、生产配置、对外发送，应该进入更高风险等级。系统不必要求负责人读完每一段 prompt，却必须让他看见将要改变什么、依据什么改变、失败后怎样撤回。

审的是状态变更，不是聊天记录。

最容易被忽略的一层，是可逆性

再好的 review 也会漏。

Anthropic 没有把所有赌注押在合并前。他们在 merge queue 中重新跑检查，避免两个单独通过的 PR 合在 main 上才出错。新功能通常先给内部员工用，再逐步发布到 latest 和 stable。feature flag 可以无须重新部署就关掉，作者和 on-call 负责观察异常，必要时 fix forward 或 rollback。

这不是保守，它反而让团队敢更快。

很多工程讨论爱问，什么时候才能让 Agent 自动 merge。我觉得更应该先问，出错后多快能确认，多快能关掉，多快能恢复。这三个答案如果还是小时级，自动化就只是把事故提前送进生产。反过来，若变更足够小，有明确开关，监控能捕捉异常，回滚路径经过演练，低风险自动合并才有了可讨论的基础。

这和 Channing 常做的 AI 平台工程很贴近。一个 Agent 调用 Webhook 后说任务完成，并不证明业务完成。你要确认目标系统是否收到一次而且只收到一次，副作用是否写入审计记录，重试是否幂等，失败后是否可重放。代码合并和业务执行，都是同一类问题，系统得能看见终态，也得能回到安全状态。