Agentic Code Review（智能体代码审查）

Agentic Code Review（智能体代码审查 / Agent 代码审查） 指在 AI Agent（智能体）自主编写绝大多数代码（如 Anthropic Claude Code 团队内部约 90% 的代码由 Claude 生成）、变更吞吐以数量级激增的背景下，重构传统代码审查体系的工程范式。

这是一个 新兴工程说法：随着代码生成速度彻底突破人类阅读上限，传统在流水线末端由人类工程师逐行肉眼把关的“门禁式审查（Gatekeeping）”不可避免地失效。以 Anthropic 为代表的团队将审查机制重构为 以机器阅读为主体、纵深防御多层防护、风险动态分级的人机协同质量系统。

核心矛盾：代码吞吐激增与人类注意力瓶颈

传统软件工程的代码审查承担两个核心职能：

在代码合入前发现并修复缺陷；
在团队内部建立共享上下文与代码库认知。

传统审查建立在一个隐含假设之上：“人类逐行审阅了代码”等于“代码经过了严格检验”。但在 Agent 规模下，这一假设彻底破裂：

吞吐爆炸：Anthropic 单体仓库每日合入量从 2026 年 5 月约 2,500 次飙升至 9 月超过 30,000 次（见 Scion）；而在使用独立 GitHub 仓库的 Claude Code 团队，合并的 Pull Request 数量在三个月内翻倍。
注意力稀缺：让人类工程师逐行阅读机器生成的数万行变更既不现实，也会诱发审批疲劳（Approval Fatigue），导致代码审查退化为不假思索的橡皮图章（Rubber-stamping）。

Anthropic 团队提出：“是否有人类读过代码”只是一个粗糙的代理指标，真正的问题是“这项变更可能引入什么故障，而哪种检查（自动化还是人工）才是拦截它的正确手段？”

因此，审查系统将优化的核心标的从“让流程走完”转向 人类时间与注意力（Human Time and Attention）：

监控指标：跟踪每个 PR 的中位数与 P95 人工审批耗时、人工评论数量、PR 等待人类处理的时长；
安全护栏：以 回滚率（Revert Rate）与线上事故率（Incident Rate） 作为绝对底线。如果压缩人工时间导致回滚率反弹，意味着团队只是把成本从“审查阶段”转嫁到了“排障救火阶段”，并没有真正节省人类时间。

实测数据显示，通过纵深防御与自动化收敛，Claude Code 团队在合并 PR 翻倍的同时，代码回滚比例下降了超过 40%。

纵深防御：变更的完整生命周期

在 Agent 规模下，代码审查不再是一道静态门禁，而是一套纵贯“开发前 → PR 中 → 合入中 → 上线后”的纵深防御流水线（借鉴瑞士奶酪模型，每一层都有各自的盲点，最终由底层的快速回滚承托）。

flowchart TD
    subgraph PrePR["1. PR 创建前：自闭环验证"]
        A1["开发者/Claude 本机环境"] --> A2["本地验证：测试 / 构建 / Lint / 截图比对"]
        A2 --> A3["Subagent 独立上下文审阅 Diff"]
        A3 --> A4["专用 Skills 预检：Bug 猎手 / Diff 简化器 / 行为检查"]
    end

    subgraph OnPR["2–5. PR 阶段：自动化审查与分级审批"]
        A4 --> B1["强制 CI：跨平台构建 / 类型检查 / 测试矩阵 (红标阻断)"]
        B1 --> B2["Claude Code Review：多 Agent 并行找虫 + 投票验证"]
        B2 --> B3["Security Review：独立安全扫描 (未解决阻断)"]
        B3 --> B4{"风险分级审批 (分类器判定)"}
        B4 -->|"低风险 (文档/配置/Flag内功能)"| C0["0 人工审批 (机器全自动放行)"]
        B4 -->|"中风险 (常规产品代码/敏感模块)"| C1["1 人审批 (Prompt 者可作为审查者)"]
        B4 -->|"高风险 (核心资产/特权路径/CI)"| C2["2 人审批 (必须人工同行评审)"]
    end

    subgraph PostMerge["6–7. 合入与上线：发布阶梯与快速回滚"]
        C0 --> D1["Merge Queue：基于最新 main 重跑检查"]
        C1 --> D1
        C2 --> D1
        D1 --> D2["Feature Flag：Anthropic 员工内部全量 Dogfooding"]
        D2 --> D3["渐进式发布：Latest 渠道先行 → Stable 渠道跟随"]
        D3 --> D4["实时遥测监控：异常即时切 Flag / 快速 Revert"]
    end

1. PR 之前的自验证（Pre-PR Verification）

绝大多数常规审查在 PR 产生前就已在本地完成：

提供可运行的验证锚点：给 Claude 提供测试套件、构建脚本或设计对比截图，要求其在声明完成前必须运行并展示结果。Claude Code 创始人 Boris Cherny 指出，给 Agent 提供验证手段是获得高质量结果最关键的动作，能将最终产物质量提升 2–3 倍。
独立上下文审查：由全新上下文的 Subagent（子智能体）审阅 diff，避免编写代码的模型因自身偏见漏看盲点。
专用本地 Skill 过滤：预先运行 bug 猎手、diff 简化器和 UI 设计规范检查器。
指令规范双轨制：
- CLAUDE.md：保持简短，陈述技术栈、全局架构约束与非目标。审查器会自动标记破坏约定的代码，并警示陈旧规则。
- REVIEW.md：由各个代码领域的 Code Owner 编写，定义该领域“何为失败”（如对文档是“撒谎”，对配置是“路由错误”），限制 Nit 级细碎挑剔，列出跳过路径，并强制要求模型基于文件和具体行号提供确凿证据，杜绝基于名称的猜忌。

2. PR 级多智能体代码审查（AI Code Review）

每个 PR 均由自动化 Reviewer 优先过目，阅读 diff、整库上下文与 PR 描述：

并行狩猎与投票验证：多个 Agent 并行寻找 bug，随后由独立的 Verifier Agent 群对每项 Finding 进行表决，唯有足够多的验证者判定属实才公开。单纯关于代码风格、临时诊断日志或轻微清理的建议会被主动剔除。
严重度分级：保留的条目被标记为 Important、Nit 或 Pre-existing（已存在缺陷），明确界定这是否由本次 PR 引入。
强制闭环响应：PR 作者必须修复 Finding，或附带理由主动关闭该 Thread（用于消除误报）。

3. 阻塞级安全专项审查（Security Review）

安全检查作为独立阶段运行（CLI 命令 /security-review 或 GitHub Action）。只要代码审查或安全审查存在未关闭的 Finding，PR 绝对禁止合入。若后续 commit 修复了对应漏洞，系统会自动解除阻塞。

4. 自动化测试与回滚契约（Required CI）

除常规类型与单元测试外，PR 模板被强制注入契约字段：声明本次变更是如何验证的，以及出现故障时如何一键回滚。

5. 风险分级的人工审批（Risk-based Approval）

彻底放弃“一律需人类 Peer Review”的教条，依据代码的潜在破坏半径（Blast Radius）动态匹配审批要求：

风险等级	典型范畴	人工审批要求
低风险（Low）	文档、文案、纯内部工具、隐藏在 Feature Flag 后的纯增量改动	0 人（自动化审查与安全检查全绿即可合入）
中风险（Medium）	常规产品功能改动，涉及缓存、自动更新器、系统 Prompt 等敏感模块	1 人（主导 Prompt 的工程师可计入合规名额）
高风险（High）	计费系统、身份凭证、权限边界、CI 工作流配置及高危核心路径	2 人（严格强制人类同行复核）

分级审批的关键运行规则：

变更决定层级，而非作者身份：由两阶段分类器根据语义 diff 和受影响路径打标，避免人情担保。
轻量路径限定可信作者：只有对应代码库的核心维护团队（Trusted Authors）能享受 0 人或 1 人审批通道；外部贡献者一律需要第二人复核。
Agent 批准绝不等同于人类：Bot 无论多强，都不能占用需要人类签署的审批槽位。
提示词发起人终身负责：在 Agent 编写的 PR 中，指导 Agent 的人类工程师承担作者责任（“谁指导，谁负责”）。
增量作废原则：一旦有未经过审计的新 commit 推入，此前获得的人工批准全部作废重来。

6. 合并队列与发布阶梯

通过 Merge Queue 将变更基于最新的 main 分支重跑测试，杜绝两个独立绿标的 PR 合并后引发隐式破坏。合入后首先对内部员工全量开启（Dogfooding），随后推向 latest 渠道，最终才进入 stable 渠道。

7. 秒级感知与快速回滚

当不可避免地出现漏网之鱼时，依靠底层防御网：Feature Flag 无需重新部署即可瞬间关闭；全天候 On-call 轮值；每次事故复盘第一问必是：“七层防御网中的哪一层本该拦住它？”。

审查收敛工程：破解 Agent 互磨死循环

当 PR 作者与 PR 审查者同时由 Agent 担任时，会暴露出经典 Evaluator-Optimizer（评估器-优化器）架构在开放代码库中的严重病态——审查无限发散（Review Divergence）。

在实践中，曾出现过作者 Agent 与审查 Agent 连夜互相推诿、连续修改审查超过 50 轮的情况。Anthropic 团队对反复被挑刺的代码进行 git blame 溯源，发现了一个惊人事实：在审查器持续报警的代码中，约 59% 是从第一轮审查起就存在的老代码，审查器根本没有在新提交中发现新 bug，而是在存量历史代码里不断钻牛角尖。

为了确保审查高效闭环，团队落地了四项 收敛控制机制（Convergence Controls）：

设置硬性轮次上限（Round Cap）：PR 经历 3 轮审查仍未通过时，审查器强制熔断，要求作者停下来重新审视整体实现路径与架构，禁止在错误方向上打补丁。
后续轮次仅审增量（Diff-only Re-review）：前两轮之后，审查器仅评估最新 commit 引入的局部增量 diff，禁止重新漫游全库存量代码。
按缺陷类型整体报警（Flag the Class of Bug）：审查器不得就同类缺陷逐行逐处开 issue，必须指出“这一类模式有误”，驱动作者一次性修复所有上下文。
全局去重（No Repeats）：严格禁止重复发布此前已经由人或前序轮次讨论过的 Finding。

收敛优化落地前后的核心工程数据对比：

指标	优化前	优化后	变化幅度
1 轮审查即闭环通过的 PR 比例	65%	78%	+13%
需要 5 轮及以上的死循环 PR 比例	8.9%	1.5%	−83%
平均通过审查轮数	2.08 轮	1.32 轮	−36.5%

审查器自进化：事故即 Eval（Incidents as Evals）

为了避免审查器沦为充斥误报的“狼来了”系统，团队建立了双向评估闭环：

flowchart LR
    A["线上事故 / Revert 发生"] --> B["领域专家复核根因"]
    B --> C["沉淀为标准评测用例 (Case)"]
    C --> D[("事故 Eval 数据集\n持续累积")]
    D --> E["审查器每日基准跑分\n(Prompts / Tools / 模型更新)"]
    E --> F{"评测得分提升？"}
    F -->|"是"| G["保留并上线改动"]
    F -->|"否"| H["丢弃改动并排查退化"]

事故转评测（Incidents as Evals）：每一次导致线上故障或回滚的 PR，都会被对应业务模块的专家拆解、提炼出标准测试案例，纳入每日回归 Evals（评估）集。审查器的系统 Prompt、挂载工具或底层模型的任何改动，必须证明在全量事故库上的拦截率上升且不产生严重误报，才被允许合入。
基于人类行为度量噪音：根据人类工程师对审查评论的真实动作（修复代码、反驳报错、标为预期行为、忽略关闭）进行分类统计。首要优先级是捕获真实缺陷，次要优先级才是减少审查轮次。

人类在环的五个核心锚点

将资深工程师从逐行阅读琐碎语法中解放出来，并不意味着人类退出研发。在 Human-Agent Teams 模式下，人类注意力被收敛并固定在机器无法胜任的五个核心决策锚点上：

应不应该做？（Should we build this at all?）：把握技术方向、业务品味（Taste）与需求范围。在 Agent 让编码启动成本降为零的时代，人类最重要的职责之一是对外部 PR 或伪需求及时说“不”，避免系统陷入膨胀。
高危特权代码（Risky Code）：计费、权限认证、自动更新器、CI/CD 发布脚本等具备不可逆破坏力的代码，始终需要双人把关。
架构范式把控（Architecture）：审视核心抽象与接口设计，防范不良模式被后续数十个 Agent 复制传播。
审阅证据而非盲猜（Reading the Evidence）：工程师不再靠肉眼猜想代码能否运行，而是审查客观证据——测试日志、实际运行输出、UI 截图比对与审查器 Findings。无法确认自动化会漏掉什么时，必须要求严肃审查。
终身责任归属（Owning the Outcome）：代码无论由谁敲下，“谁合入谁拥有（You land it, you own it）”。机器不能承担线上故障责任，必须由具体的人类工程师签发并背书。

认知传播破局：按需切片解释替代全量 Diff 阅读

传统代码审查的第二项功能是向全组同步代码库认知。当机器写了 90% 的代码时，“阅读队友的每一个 PR diff”在生理上成为不可能，也容易让工程师积累严重的 Comprehension Debt（理解债）。

Anthropic 团队彻底放弃了“每个团队成员脑中都维持一份代码库全局心理模型”的旧观念：

按需切片解释（Slice Explainers）：当工程师需要改动某个模块时，直接指示 Claude 针对该特定切片（如“Claude Code 是如何加载和管理托管配置的？”）生成反映最新代码现状的文档，只需耗时几分钟。
互动可视化产物：必要时由 Claude 生成局部的交互式可视化 Artifact，以工程师最易吸收的形式呈现。
开放透明沟通：团队默认在 Slack 公开频道中工作，任何人都能看到正在发生的高层设计讨论，以此维系团队宏观共识。

架构对比：Claude Code 审查 vs Scion / Antique

Anthropic 内部同时存在两套面向高频 Agent 负载的代码审查与版本控制范式：

维度	Claude Code 团队做法	Monorepo Scion + Antique 做法
适用环境	独立 GitHub 仓库、多端客户端（CLI/Desktop/Web/Mobile）	超大型单体仓库（全公司核心研发、日合并超 3 万次）
工作流载体	标准 GitHub Pull Request + Merge Queue	彻底废黜 PR，自研轻量 Changeset 与 Antique CR
合并机制	基于 Merge Queue 的前置重跑验证	彻底放弃合并队列锁，转向后置与部署前自动化测试
审查核心策略	纵深防御分层、机器先行拦截、风险分级审批	语义分流（注释与逻辑分离）、对抗性审查纠偏
回滚与韧性	强调 PR 模板中的一键回滚契约与 Feature Flag	强调无锁瞬时 Revert 与 Spanner 单行元数据变更