Anthropic为AI代码配置多智能体审查 实质审查意见占比升至54%
要点
人工智能生成代码进入工程流程之后，审查环节由谁承担、以什么方式承担，成为软件开发组织需要重新回答的问题。Anthropic 在官方渠道先后公布了数项与这一环节相关的能力与产品：面向终端的 /security-review 命令与配套的 GitHub Action，用于拉取请求的…
人工智能生成代码进入工程流程之后，审查环节由谁承担、以什么方式承担，成为软件开发组织需要重新回答的问题。Anthropic 在官方渠道先后公布了数项与这一环节相关的能力与产品：面向终端的 /security-review 命令与配套的 GitHub Action，用于拉取请求的多智能体 Code Review，以及公司内部各团队把编码工具用于测试与评审的做法。这些发布都附带可核对的口径与数字，也附带明确的适用边界，把它们放在同一条链路上阅读，比单独看任何一项更接近事情的全貌。
最先落地的是安全审查的自动化。2025 年 8 月公布的更新包含两部分：开发者在提交前可在终端运行 /security-review，让工具检索代码库并给出潜在漏洞的说明；另一部分是一个 GitHub Action，在每个拉取请求创建时自动触发，按可配置规则过滤误报与已知问题，把发现以行内评论的形式贴回。官方列出的检查范围包括 SQL 注入风险、跨站脚本、认证与授权缺陷、不安全的数据处理以及依赖项漏洞五类。Anthropic 同时说明这套机制已用于保护自家生产代码，并给出两个内部案例：一个接收本地连接的内部工具被识别出可经 DNS rebinding 利用的远程代码执行漏洞，一个用于管理内部凭据的代理系统被标记存在 SSRF 风险，两者都在合并前得到修复。
到 2026 年 3 月，面向拉取请求的多智能体审查被单独产品化。官方给出的背景数字是，过去一年每位工程师的代码产出增长了 200%，代码评审因此成为瓶颈，许多拉取请求只得到快速浏览而非细读。产品在 Team 与 Enterprise 订阅中以研究预览形式提供，页面顶部另有更新说明称其后已正式可用。内部运行数据显示，获得实质性审查意见的拉取请求占比从 16% 升至 54%；对超过 1000 行改动的大型请求，84% 会得到发现，平均 7.5 条，而 50 行以下的小请求这一比例降至 31%、平均 0.5 条；单次审查平均耗时约 20 分钟，按 token 用量计费，一般每次 15 至 25 美元。官方特别写明，它不会批准拉取请求，批准仍由人作出。
把这两类发布与官方文档对照，可以看出一套分层的设计，而不是单点工具。文档把一次审查拆成四个阶段：多个智能体并行读取改动及其周边代码以寻找问题，随后由验证环节把候选发现与实际代码行为比对、过滤误报，再把保留下来的结果去重并按严重度排序，最后以行内评论和一份检查运行记录发布到拉取请求上。默认关注点是会导致生产故障的正确性缺陷，而非格式偏好或测试覆盖缺口；仓库可通过 REVIEW.md 与 CLAUDE.md 文件调整审查重点，并且规定读取的是基础分支上的规则文件，不取拉取请求自身改动里的版本。组织还可在 Quick、Standard、Deep 三档审查深度之间选择，深度越高耗时与费用越高。值得注意的是，检查运行记录不会以失败作为结论，审查从不批准也不阻断合并，合并决定始终留在团队手里；文档同时附有免责说明，写明这类审查可能漏掉缺陷、安全漏洞或其他问题，没有发现并不意味着代码无误或安全。
官方材料内部的几组口径需要分层阅读，否则容易把不同层级的事实叠成同一个结论。其一，16% 升至 54% 衡量的是获得实质性评论的拉取请求占比，它反映评论覆盖面的变化，不等于发现或阻止了多少缺陷，比例上升既可能来自更充分的检查，也可能伴随更多噪音。其二，84%、31%、7.5 条、0.5 条、不到 1% 被标为错误等指标，来自 Anthropic 自家仓库的内部运行，样本是该公司的代码库、模型与流程，官方并未给出跨组织的对照或事故率的前后对比。其三，产品状态本身存在时间差：正文写研究预览与测试版，页面顶部的更新又说明已正式可用，二者对应同一产品在不同时点的状态，而非互相否定的两种说法。其四，付费与配额设计——月度组织上限、仓库级开关、分析面板——说明审查在这里已经被当作一项有成本、需要治理的服务，而不是可以无限叠加的免费检查。把覆盖指标、内部样本、产品状态与成本机制分开看，才不会把一组宣传性数字直接换算成可靠性结论。
企业自用实践与行业、学术及政策侧的判断之间，存在一处值得对照的张力。公司方面的材料强调的是把读代码的活交给机器、把判断与责任留给人，其配套手段是并行智能体、验证过滤、严重度排序、功能开关与灰度发布。而美国计算社群联盟发布的《Beyond Code》报告从另一个角度指出，生成速度已经超过验证能力：报告援引 2025 年 Stack Overflow 开发者调查与 Google 的 DORA 报告，给出 84% 至 90% 的工具采用率区间，并把问题归结为两条——面对大量机器生成的拉取请求，人工审查者会出现认知疲劳与自动化偏见，从而漏掉细微缺陷；自动化生成的测试套件可能虚高覆盖率指标，却在验证错误的行为。报告还列出集中度风险，即多数组织依赖同一个主导模型时会同时继承相同的盲点。这些判断并不针对某一家公司的产品，却解释了为什么单靠增加审查次数未必等于提高可靠性，也为什么报告主张让质量检查以与生成相当的速度扩展，并点名基于属性的自动化测试、形式化语义验证以及用不同模型相互探测输出等方向。该报告源自 2026 年 2 月在旧金山举行、由 IEEE Computer Society 共同参与、汇集 41 位学界产业界与政府专家的愿景工作坊，相关评述由计算研究协会刊发，材料注明受美国国家科学基金会两项资助支持。
政策与一线的做法，则把同一问题落到了可执行的约束上。工业和信息化部印发的《”人工智能+软件”专项行动实施方案》在安全保障条款中提出，需要加强人工智能生成代码的安全审查，防范智能编程工具恶意指令注入一类新型攻击，并强化开发工具与代码库的访问控制；方案同时要求完善软件产品和服务质量管理与测评规范，加强生成代码的知识产权合规治理。标准研制部分另提出，为智能编程能力建立成熟度分级评估一类标准，并研制面向软硬件协同的智能体接口规范。方案设定的目标包括到 2028 年把相关工具与平台推广覆盖 2 万家规模以上软件企业，并组织实施 100 项软件企业智能化技改项目。在神州数码于郑州举办的一场企业巡游活动中，来自郑州信源信息技术股份有限公司的负责人给出的做法是按风险分级决定审查强度：报表、小工具等低风险应用可放开使用，内部接口等中风险应用加强测试，涉及交易与费用的高风险系统则要求对 AI 生成代码逐行审计。同一场合也有企业代表提醒，跟风上马 AI 服务器与大模型的尝试中，约 90% 并未真正见效。政策的分级思路、企业的分级做法与官方文档里默认只查正确性、关键路径仍需人工的设定，指向同一个判断：审查强度需要与变更风险相匹配，而不是一刀切地增加或取消。
从更长的时间线看，变化的不只是工具数量，还有审查这一职能的位置。公司官方对内部用法的描述显示，编码工具已被用于编写单元测试、通过 GitHub Actions 自动处理拉取请求评论、把安全团队的工作流转向测试驱动开发，以及在生产事故中缩短诊断时间；这与前述产品化审查共同构成一条从编写、测试、评审到发布与回滚的连续链路。相应地，人的角色被官方和学术报告同时描述为向两端移动：一端是需求定义、规格与系统设计，另一端是风险判定、批准与事故后的补救；中间大量重复性的阅读与比对工作转由机器承担。但这一步转移有明确前提——机器负责发现，人负责决定与担责，且发现能力本身仍被官方文档标注为可能漏检。把多层审查、灰度发布与回滚机制合起来看，它们处理的是两类不同的失败：合并前的检查试图在代码进入主干之前拦住问题，合并后的功能开关、监控与快速回滚则应对只在生产环境才暴露的问题。两者不能互相替代，这也是为什么在讨论由谁承担审查时，答案既不是回到逐行人审，也不是把批准权一并交出去。
综合公开材料，可核的事实分为几层：官方发布的安全审查命令与 GitHub Action、多智能体 Code Review 产品及其功能边界；企业自报的内部运行数据；官方文档对漏检、不批准、不阻断的限定；学术机构报告对验证瓶颈、审查疲劳、指标失效与集中度风险的判断；以及政策文件与企业实践中的分级治理思路。这几层各自成立，却不在同一层级上——产品能力不等于可靠性结论，内部数据不等于跨组织效果，研究建议也不等于已落地的行业标配。把它们分开把握，比给出审查已被解决或审查已经失效这样的整体判断更贴近材料本身。
