Augment Code 扩展 Cosmos：把代码审查延伸到 PR 到合并全流程
The software factory needs a faster review loop: further optimizing the path from PR to merge
Augment Code 将其 Cosmos 代码审查系统扩展到完整的 PR 到合并流程，新增 Verifier、PR Fixer、Review Dashboard 和 cosmos approve 等能力，由多个专职 Expert 分别负责风险分析、逐行审查、设计评审、运行时验证与修复。
TL;DR
在 AI 原生的工程组织中，生成代码不再是交付软件中最慢的环节。审查、验证、修复和人类决策成为瓶颈，并最终决定了组织能加速到什么程度。独立的 AI 编码工具可能带来 30–40% 的提速，但要实现吞吐量的阶跃式提升，需要优化代码写完之后发生的一切。
在我们上一篇关于用 Cosmos 解决代码审查的博文中，我们描述了一个审查系统，它帮助我们的工程组织将代码产出提高了 3 倍，同时缩短了中位合并时间并保持了质量。此后，我们将该系统从审查扩展到了完整的 PR 到合并循环：专门的智能体处理机械性工作、验证正确性并处理反馈，而人类提供判断和知识传递，并始终掌握最终的合并决定权。
这就是循环工程：改进将生成的代码转化为经过验证、被理解、可合并的变更的完整系统，而不是孤立地优化任何单一工具。
为什么一个“AI 代码审查工具”还不够
像 CodeRabbit 或 Greptile 这样的传统 AI 代码审查工具会分析 diff 并发表评论。这有用，但审查只是其中一步。真正的拖累是人工交接的链条：
- 重建意图和架构。
- 对低风险变更进行分诊。
- 应用审查反馈。
- 修复 CI 失败和合并冲突。
- 端到端验证功能行为。
- 收集足够证据以安全发布。
- 每次推送后重新审查。
PR 到合并循环让专门的 Experts 持续处理审查、修复、验证和决策支持，直到人类能够有信心地合并。机群中的每个 Expert 负责一个或多个这样的交接环节，将碎片化的手动任务序列转变为协调一致的系统。目标是优化整个循环：人类时间、成本、质量和合并延迟，而不是首次评论的时间。
1. 概述：设计完整的循环
一个 AI 原生的代码审查循环：智能体发现并修复 bug、验证变更并评估策略；人类解决判断性问题并做出最终合并决定。
我们最初的系统将风险分析（Risk Analyzer）、逐行正确性审查（Deep Reviewer）和人工引导的设计审查（Pair Review）分开。扩展后的系统增加了修复、运行时验证和扩展的自动批准，进一步减少了人工瓶颈。关于 Cosmos 及其可配置 Experts 的概述，请参阅我们上一篇关于用 Cosmos 解决代码审查的博文。
Experts 和能力，而不是一个通用审查者
| Expert 或能力 | 职责 |
|---|---|
| Risk Analyzer | 对风险进行分类并应用自动批准策略 |
| Deep Reviewer | 为客观正确性缺陷执行详尽的逐行分析 |
| Pair Reviewer | 重建意图、架构、产品上下文和权衡 |
| Memory Manager | 记住来自 PR 和 Pair Review 会话的反馈，以改进未来的运行 |
| Verifier [NEW] | 在测试环境中端到端地演练受影响的行为（[Verifier 博客](https://www.augmentcode.com/blog/the-bottleneck-moved-to-verification-so-we-automated-that-too)） |
| PR Fixer [NEW] | 修复审查发现、CI 失败和合并冲突 |
| Review Dashboard [NEW] | 观察并总结 expert 状态 |
| cosmos approve [NEW] | 在作者请求时评估可配置的批准策略，作为 Risk Analyzer 中的一个步骤 |
Deep Reviewer 与 Pair Reviewer 之间的区别尤为重要：
- Deep Reviewer 问：“这个实现中是否存在客观的 bug？”它自主运行，并依据
AGENTS.md或CLAUDE.md指南检查 PR。 - Pair Reviewer 问：“这个改动在更广泛的系统中是否合理，哪些决策需要人类判断？”它与人类交互式运行。人类还可以指示它在发布审查评论后监控 PR，并在这些评论得到处理后代表人类批准。
PR Author 还是 PR Fixer？我们之前的文章介绍了 PR Author，它编写改动，然后推动其 PR 通过审查反馈和失败。PR Fixer 执行相同的修复工作，但可以从任何现有的人类或智能体编写的 PR 开始。本文聚焦于 PR Fixer，因为它无论 PR 如何创建都能工作。
Review Dashboard 将 Expert 状态、已审查的提交、证据和可用操作汇集到一个视图中。
2. 设计 human-in-the-loop
在 AI 原生工程组织中，人工审查和验证正成为稀缺资源。目标不是不加区分地移除人类。而是只在人类注意力具有最高杠杆作用的地方投入它。
为什么人类仍然留在循环中
智能体可以执行很大一部分机械性分析和执行，但它们没有完整的业务和组织上下文。人类在以下方面仍然不可或缺：
- 判断决策：这段逻辑应该放在前端还是后端？这种权衡对产品是否合适？这个风险现在是否可以接受？
- 知识传递：审查是工程师建立对架构和产品行为共同理解的方式之一。
- 所有权与问责：软件发布后并不归智能体所有；它归人类开发者和工程组织所有。因此，始终由人类做出最终决定并点击 Merge。这些专家都不合并 PR。
因此，设计目标是：
智能体做机械性工作。人类做有后果的决策。
作者与审查者工作流：之前与之后
| 传统工作流 | Human-in-the-loop 工作流 |
|---|---|
| 手动分诊每个 PR 并识别低风险改动 | 让 Risk Analyzer 对风险进行分类，并应用组织的自动批准策略 |
| 逐行阅读 PR | 信任 Deep Reviewer 执行详尽的逐行分析 |
| 从 diff 中重建上下文、意图和架构 | 使用 Pair Reviewer 的简报来理解改动并识别判断决策 |
| 手动部署并试用该功能 | 检查 Verifier 证据：截图、日志、追踪和捕获的输出 |
| 从头重新审查每个修复 | 让 Pair Reviewer 监控已授权的评论是否得到处理 |
| 分诊反馈、实施修复、修复 CI、解决冲突，并解释每项改动 | 让 PR Fixer 负责机械性后续工作并报告改动了什么 |
| 在评论和检查中搜索当前状态 | 使用 Review Dashboard 作为入口点 |
| 在请求批准前手动收集审查、所有权和验证证据 | 调用 cosmos approve，根据当前证据评估配置的批准策略 |
| 决定是否合并 | 仍然决定是否合并 |
使用多个专家的经济学直觉
那些能够切实减少人工审查瓶颈时间的 token 值得投入。当 Expert 将数小时的审查和 PR 跟进工作缩短为几分钟时，它们就释放出稀缺的工程判断力，用于只有人类才能做出的关键决策，同时还能帮助功能更快地交付给客户。
Augment 的核心承诺之一是帮助组织优化成本。这意味着优化每个任务的总成本：人力投入加上 token 成本。这并不意味着以牺牲成功结果为代价来最小化 token 使用量。一个 Expert 身兼六项职责，每项都会做得不达标，并且需要更多人工介入。六个专职 Expert 可以各自专注于 PR 审查的不同部分，产出更高质量的审查成果，并更自主地推进流程。
3. 成本与质量：优化每次成功结果的成本
按 token 价格来看最便宜的模型往往是虚假的节约。漏掉一个缺陷、一次糟糕的修复或一次重试，其代价可能高于一次就把任务做对。我们对代表性工作进行基准测试，并选择能够通过每个 Expert 质量门槛的最低成本模型，这与我们在 Cosmos 中使用的按成功结果计成本原则相同。
如今，我们将 GPT-5.6 Sol 用于判断密集型工作，例如风险分析、深度审查与结对审查以及代码修复。有边界、可机械验证的任务，例如仪表盘聚合和合并冲突监控，则运行在 GPT-5.6 Luna 上。具有更长缓存 TTL 的模型也更适合长时间运行的 agent，因为缓存输入通常可享受 90% 的折扣。
4. 可配置的审批路径，带有 cosmos approve
Risk Analyzer 一直能够在保守策略下批准本质上低风险的变更。我们现在支持第二种审批模式，用于其他变更，默认处于禁用状态。
PR 作者可以评论 cosmos approve 来请求根据审批策略进行评估。最终合并仍由人类负责并执行。
组织定义自己的审批策略。我们的内部策略检查：
- 所有权：请求者是 PR 作者，且作者是每个被修改文件的有效 CODEOWNER。
- 当前 head 审查：没有未解决的 Deep Reviewer 发现、Pair Reviewer 阻塞项或未处理的人工评论。
- 无矛盾的运行时证据：Verifier 未报告针对当前提交的未处理缺陷。
5. 可定制性是架构的一部分
我们设计整个 fleet 时，让团队可以通过 Cosmos Advisor 自定义循环。
- Fleet：添加、移除或替换 expert；为每项职责选择模型和提示词。
- 操作：配置触发器、工具、集成和验证环境。
- 控制：限制谁可以调用操作，以及每个 expert 可以访问哪些凭据、仓库和系统。
- 策略：定义审批规则、必需检查、CODEOWNER 要求和可接受的证据。
AI 原生 PR 审查的运营模式
我们第一版的经验是，代码审查无法通过要求人类更快地阅读 AI 生成的代码来实现规模化。这一版的经验则更为广泛：没有任何单个审查 agent 能够优化通往合并的完整路径。
一个高效运转的从 PR 到合并的循环需要：
- Agent 专业化：将风险、正确性、设计判断、运行时验证和修复分开。
- 尽量减少人工检查点：仅在关键判断和知识传递时引入人类。
- 证据：向审查者提供可检查的证明，而不是无依据的结论。
- 修复循环：让发现的问题回流到实现中，无需等待人工干预。
- 可观测性：让整个集群的状态在一个地方清晰可见。
- 成本纪律：为每项职责使用能通过质量门槛的最便宜模型。
- 可配置性：根据每个组织的独特需求定制循环。
- 人类所有权：将最终合并决定权留给对软件负责的人。
这就是将循环工程应用于 PR 生命周期：优化的是产出经过验证、被理解、可合并变更的系统，而不是任何单个智能体的输出量。
构建你自己的从 PR 到合并的循环
Cosmos 为工程团队提供共享上下文、运行时控制、集成和人工检查点，以在审查、验证、修复及软件生命周期其余环节中运行智能体。
来源：Augment Code Blog · augmentcode.com