Agent 代码审查分层实践：审意图、控风险、设收敛边界

Agent 让 PR 变多后，Code Review 的瓶颈不再是写代码，而是判断哪些改动值得合并。Anthropic 的深度技术文章给出了一套完整做法：Agent 先自证，AI reviewer 结合仓库上下文审查，人类按风险介入，发布过程再用灰度和回滚控制影响范围。

本文根据 Viking 在 X 上的分享，拆解这套流程如何落地，以及为什么 Review 必须设置收敛边界，避免作者 Agent 和审查 Agent 无限来回修改。

代码审查的瓶颈已经变了

传统 Code Review 通常围绕一个问题展开：这段代码有没有明显错误？Reviewer 打开 diff，检查命名、逻辑、测试、兼容性和边界条件，然后留下评论。

Agent 进入开发流程后，问题会扩大。一个功能可能由多个 Agent 分别修改代码、补测试、更新文档和调整配置。PR 数量增加后，Reviewer 面对的不只是更长的 diff，还有更高的上下文切换成本。每个 PR 都要求人从头理解背景，团队最终会出现两种结果：审核越来越快，但质量下降；或者审核越来越慢，合并队列开始积压。

Anthropic 的文章提供了一个重要视角：Code Review 的目标应该围绕风险和反馈速度设计，而不是把"人工看过每一行"当作唯一质量证明。

第一层：让 Agent 在提交 PR 前先交作业

推文把这一层概括为 Agent 自证。Agent 创建 PR 之前，需要提交一组可以被其他系统读取的证据：运行过哪些测试、构建是否成功、关键页面是否验证、是否检查了相关日志，以及它认为仍然存在什么风险。

这一步可以直接落到 PR 模板中：

Agent Verification

• [ ] Build passed
• [ ] Unit tests passed
• [ ] UI tests passed or not applicable
• [ ] Changed files reviewed
• [ ] Screenshot attached when UI changed
• [ ] Rollback plan written

Commands

xcodebuild test \
  -workspace App.xcworkspace \
  -scheme App \
  -destination 'platform=iOS Simulator,name=iPhone 17'

Remaining risks

• None

这里的重点是让"我做过验证"变成可以被 CI 检查的字段。比如 PR 描述里写了测试已通过，流水线却找不到对应的测试结果，系统就应阻止进入下一步。

第二层：AI Reviewer 要审意图和仓库上下文

只把当前 diff 交给 AI reviewer，效果很容易受限。一个看似合理的改动，或许违反仓库里的架构约束；一个删除旧接口的 PR，也许影响另一个没有出现在 diff 中的模块。

更可靠的审查输入至少包括四部分：

• PR 描述：作者想解决什么问题。
• 变更 diff：具体改了哪些文件。
• 相关代码：调用方、协议、配置和测试。
• 仓库规则：架构约束、兼容性要求和禁止修改区域。

审查提示也要从"找所有问题"改成"只报告可行动的问题"：

你是代码审查器。

请根据 PR 意图、完整 diff、相关调用方和仓库规则检查：
1. 功能是否完成；
2. 是否引入安全、数据一致性或兼容性风险；
3. 测试是否覆盖主要失败路径；
4. 是否存在可以用确定证据复现的问题。

只输出会改变合并决定的问题。
纯风格偏好、已有代码中的历史问题和没有复现依据的猜测不要输出。
每个问题必须包含：文件、行号、原因、复现条件、建议修复方向。

这套输出约束很重要。AI reviewer 如果把格式偏好、命名争议和真实 bug 混在一起，Reviewer 很快会失去信任，最后连高风险问题也被忽略。

第三层：多个 Agent 找问题，另一组负责投票

多 Agent Review 的常见误区是把每个 Agent 的输出直接拼接给人看。这样只会把噪声放大：三个 Agent 或许重复报告同一个问题，也会因为同一段代码的上下文不足，集体产生相同误判。

更好的结构是把"发现"和"裁决"拆开：

PR + 仓库上下文
       │
       ├── Reviewer A：正确性
       ├── Reviewer B：安全与数据
       ├── Reviewer C：测试与兼容性
       │
       ▼
问题归一化：合并重复项，保留证据
       │
       ├── Judge A
       ├── Judge B
       └── Judge C
       │
       ▼
只发布多数认可、且有明确证据的问题

投票机制不需要追求"多数就完全正确"。它的价值在于降低单个 Agent 误报直接打断开发流程的概率。进入 PR 评论的问题，仍然要满足最低证据标准：能定位到代码、能说明触发条件、能解释影响范围。

第四层：按风险分配人工审批

所有 PR 都要求两个人批准，听起来很安全，实际会把最稀缺的资源平均分配给所有变更。文档、测试修正、低风险重命名和核心支付路径，显然不应该使用同一种审批策略。

可以先建立一套粗粒度风险矩阵：

风险等级	典型变更	人工审批	发布方式
低	文档、测试、内部工具	0 或 1 人	自动合并，持续集成验证
中	普通业务逻辑、非核心 UI	1 人	Merge queue，灰度观察
高	权限、支付、数据迁移、核心登录	2 人或指定负责人	小流量灰度，保留回滚开关

这套分级的关键是"按路径"而不是"按作者"。一个资深工程师修改支付逻辑，仍然需要更高等级的保护；一个新成员修改内部文档，没有必要被同样的流程拖慢。

风险标签可以由目录、CODEOWNERS、文件类型和业务元数据共同决定。不要把风险判断完全交给 Agent 自己填写，因为它未必知道某个配置文件背后的生产影响。

第五层：把合并和发布拆开

代码通过 Review，不等于代码应该立即对所有用户生效。Anthropic 文章提到的 merge queue、feature flag 和灰度发布，解决的是发布阶段的风险隔离。

一个稳妥的路径可以是：

Agent 提交 PR
  ↓
自动检查与 AI Review
  ↓
按风险完成人工审批
  ↓
Merge queue 串行合并
  ↓
内部员工或测试群体灰度
  ↓
观察错误率、崩溃率和关键业务指标
  ↓
扩大范围或关闭 feature flag

feature flag 的价值在于把"回滚"从一次代码部署变成一次配置切换。它不能替代数据库回滚，也不能掩盖数据已经写坏的问题，所以高风险功能仍然需要迁移脚本、补偿方案和审计日志。

灰度发布也不能只看服务是否返回 200。需要根据业务建立观察指标，例如请求失败率、关键任务完成率、崩溃、延迟和用户投诉。没有指标的灰度，只是延迟发现问题。

第六层：让 Review 收敛，防止 Agent 互相折腾

推文提到一个很有启发的案例：某个 PR 一夜之间来回修改五十多轮，后来通过 git blame 发现，反复被标记的代码中，有约 59% 在第一轮审查时就已经存在。

这暴露出一个常见问题：后续 Reviewer 看到旧问题，又把它当成当前 PR 新引入的问题；作者 Agent 收到评论后继续修改；下一轮审查再次扫描整份文件，于是历史问题被反复拉出来。

解决方案可以落成三条规则：

1. Review 最多循环三轮。
2. 第二轮开始只关注新增 diff。
3. 已经明确处理、拒绝或标记为历史问题的评论不重复生成。

超过三轮后，不要继续提高 Agent 的修改次数。让作者重新说明方案，或者由人工决定是否拆 PR、换实现路径。Review 系统需要有"停止条件"，没有停止条件的自动化流程只会把时间变成循环成本。

这套流程里，哪些事情仍然需要人

人类 Reviewer 最适合做四类判断：

• 这个改动是否值得合并。
• 需求和实现是否匹配。
• 风险等级是否正确。
• 出现异常时，团队是否愿意承担后果。

AI reviewer 更适合做四类工作：

• 搜索跨文件影响。
• 检查重复模式和已知风险。
• 对照测试、日志和 PR 证据。
• 在多份结果中合并重复问题。

两者的边界应该写进流程，而不是留在个人习惯里。否则团队会在"AI 太吵"和"AI 不可信"之间来回摆动。

给团队的最小落地版本

不需要一开始就搭建完整的多 Agent Review 平台。可以先从以下五步开始：

1. PR 模板加入 Agent 验证清单。
2. CI 强制检查测试结果和构建结果。
3. AI reviewer 只报告有证据、可行动的问题。
4. 按目录和业务路径建立低、中、高风险审批规则。
5. Review 最多三轮，后续只审新增 diff。

跑通这五步后，再增加多个 reviewer、投票器、灰度指标和自动合并。每增加一个 Agent，都要回答一个问题：它减少了哪种风险，还是只增加了另一份输出？

我的判断

Agent 让代码产出变快后，Code Review 的设计重点会从"把所有 diff 看完"转向"建立可信的证据链"。Agent 先自证，AI reviewer 结合仓库上下文审查，人类按风险介入，灰度和 feature flag 负责控制发布半径，收敛规则负责防止自动化流程失控。

这套方法并没有消除工程判断，只是把判断放到更值得投入的地方。对开发团队来说，最值得今天就开始做的动作很简单：给 PR 加验证清单，给 Review 设置停止条件，再把低风险变更从人工队列中释放出来。

来源

X 推文

Viking：Code Review 的实践与 Anthropic 工程文章解读：
https://x.com/vikingmute/status/2111302797794885999

Anthropic 原文

How the Claude Code team does code review：
https://claude.dev/blog/solving-code-review-at-anthropic/