Augment 如何搭建软件工厂：从编码智能体到全流程自动化
Beyond AI Coding Agents: How We Built Augment's Software Factory
Augment Code 公开其软件工厂实践，在 2025 年 11 月至 2026 年 7 月间把每位活跃开发者的规模调整后产出从 12.3 提升到 55.7，即 4.5 倍，同时 PR 中位合并时间从 11.2 小时降至 3.1 小时，14 天回滚率从 1.9% 降至 0.4%。
Augment 公开了软件工厂的搭建顺序与各环节智能体分工，可对照自身瓶颈判断先自动化哪一步。
TL;DR：我们构建了一个软件工厂，以自动化 SDLC 中的机械性工作。在八个月里，每位开发者经规模调整后的产出增长了 4.5 倍，同时合并时间和回滚率下降。我们在工作堆积的地方添加智能体，而不是按生命周期顺序进行自动化，并让工程师继续负责产品决策、架构和生产风险。
到 2025 年 11 月，AI 已经编写了 Augment 近 100% 的新代码。但生成代码并不等同于交付可靠的软件。随着编码加速，瓶颈转移到 SDLC 的其他部分：审查、验证、规划、事件响应或反馈解决。
软件工厂通过在需求、工单、拉取请求和生产之间更快地推进工程工作来解决这一瓶颈（阅读更多关于软件工厂模式的内容）。专门的智能体在每次转换时自动化机械性工作，而人类保留对重大决策的所有权。我们在 Augment Cosmos 上构建了我们的软件工厂，这是我们用于运行和协调智能体的平台。每当出现新的瓶颈时，我们就添加相应的组件。
在 2025 年 11 月至 2026 年 7 月期间，在整个 Augment 工程部门：
- 每位活跃开发者经规模调整后的产出从 12.3 增长到 55.7：4.5 倍。
- 每位活跃开发者的原始拉取请求数从 16.6 增长到 45.5：2.7 倍。
- 每位活跃开发者更改的行数从 8,031 增长到 35,147：4.4 倍。
- 合并中位时间从 11.2 小时降至 3.1 小时：降低 72%。
- 14 天回滚率从 1.9% 降至 0.4%：降低 79%。
这些收益是随着时间推移、我们将自动化从代码生成逐步扩展到规划、审查、验证、反馈和运维而逐渐显现的。
工程领导者构建软件工厂指南
软件团队如何从单个编码智能体迈向团队级软件交付。
工作如何在 Augment 的软件工厂中流转
到 8 月初，我们的软件工厂已覆盖工程工作的四个相互连接的状态：需求、工单、PR 和生产。我们的工厂循环连接了用于工单的 Linear、用于拉取请求的 GitHub、用于产品反馈的 Slack，以及用于事件响应的 Slack + PagerDuty。专门的智能体在这些状态之间的转换上运行，自动化推动想法前进所需的机械性工作，同时保留人类对重大决策的所有权。一旦 PR 被合并，我们现有的确定性部署流水线就会将更改带到生产环境。我们并没有按生命周期顺序自动化这些转换；而是从工作堆积的地方开始。我们的运营循环很简单：找到瓶颈，自动化它，然后重复。
| 工作流 | 触发条件 | 智能体 | 输出 | 人类角色 / 关卡 |
|---|---|---|---|---|
| 需求 → 工单 | 功能描述 | [Project Builder](https://www.augmentcode.com/blog/accelerating-large-engineering-projects-with-cosmos) | 基于代码库的设计文档，并将工作拆分为工单 | 与 Project Builder 就产品需求和架构决策进行迭代；批准设计 |
| 工单 → PR | 工单分配给 Cosmos；或在会话中粘贴任务描述 | [PR Author](https://docs.augmentcode.com/cosmos/experts-pr-author)、[Ticket Manager](https://docs.augmentcode.com/cosmos/experts-ticket-manager) | 草稿 PR 以及针对 CI 失败、冲突和审查意见的修复 | 如有需要审查规格；在 PR 上审查自动修复 |
| PR → 生产 | 打开或更新 PR | [Risk Analyzer、Deep Reviewer、Pair Reviewer](https://www.augmentcode.com/blog/optimizing-pr-to-merge-loop)；[Verifier](https://www.augmentcode.com/blog/the-bottleneck-moved-to-verification-so-we-automated-that-too) | Risk Analyzer 自动批准低风险 PR；Deep Reviewer 针对客观 bug 发表评论；Pair Reviewer 生成 Design & Architecture 报告；Verifier 通过 E2E 测试生成运行时证据（截图、日志等） | 审查 Design & Architecture 报告，审查 Verifier 证据，并做出最终合并决定 |
| Prod → Ticket | 产品反馈，或 PagerDuty 告警 | [Feedback Triager](https://www.augmentcode.com/blog/feedback-triage-with-cosmos)；[Incident Investigator](https://www.augmentcode.com/blog/scaling-incident-management-for-an-ai-native-organization-using-cosmos) | 有证据支持的 RCA、工单和修复建议 | 审查 RCA 并批准修复操作（即代码修复、回滚或升级） |
工厂成长过程中发生了什么变化
在我们引入这些智能体工作流之前，我们的工程师已经在 IDE 和 CLI 中使用交互式 AI 编码智能体，以及一个传统的 AI 代码审查引擎。主要转变是从单独操作的工具转向持久的、团队范围的智能体工作流，这些工作流跨系统拥有工作，并且仅在定义的判断点才涉及人类。
PR 到生产的循环让差异变得具体。以前，一个典型的 PR 大约需要 10–15 个人工接触点：审查者要求智能体解释 PR，作者提示它修复 CI 失败，提示它修复审查评论，配置测试环境，手动测试功能，反复审查更新，等等。到 8 月初，自动化审查工作流将其减少到三个主要接触点：审查 Pair Reviewer 的设计与架构报告，检查 Verifier 的运行时证据，并做出最终合并决定。它还用标准化的审查流程取代了定制的开发者工作流。
这减少了每个 PR 的活跃人工处理。在同一时期，合并中位时间从 11.2 小时降至 3.1 小时，而 14 天回滚率从 1.9% 降至 0.4%。
工厂积累了九个多月：
- 2025 年 11 月： Augment 获得了 Claude Opus 4.5 的访问权限，并部署了其传统的 AI 代码审查机器人。工程师使用交互式 IDE 和 CLI 编码智能体编写了几乎 100% 的新代码。
- 2026 年 1 月： Cosmos 在内部发布（仅限交互式使用）；自动化和编排原语仍在构建中。
- 2 月： 我们推出了 PR Author 和初始的代码审查团队。
- 4 月： 在 3 月和 4 月对团队进行调优和改进后，代码审查智能体在全工程范围内得到采用。
- 5 月： 我们部署了 Incident Investigator，在人类到达之前调查生产告警。
- 6 月： 我们部署了 Project Builder，以加速大型项目的规划、设计和执行。
- 7 月： 我们部署了 Feedback Triager 和 Verifier，闭合了更多反馈和运行时验证循环。
下面的分析展示了我们在 2025 年 11 月至 2026 年 7 月期间，对 Augment 工程团队全部 17,200 个已合并拉取请求的生产力和质量指标。我们使用 Cosmos ROI Analyst 生成了这份报告，这是一个只读代理，从 GitHub 检索已合并 PR 活动、识别回滚，并计算吞吐量、周期时间、质量和复杂度加权产出指标。
每位开发者的产出增长了 4.5 倍
每位活跃开发者的原始拉取请求数增长了 2.7 倍，从 16.6 增至 45.5。由于仅凭 PR 数量可能因 PR 大小变化而失真，我们构建了一个规模调整后的产出指数，以检验这一增长是否由将工作拆分为更小的 PR 所解释。该指数使用更改的文件和更改的行数对每个 PR 加权，并设置上限以限制极端更改的影响。
该指标从每位活跃开发者 12.3 个有效拉取请求增至 55.7 个：4.5 倍。每位活跃开发者的更改行数也以类似的 4.4 倍 增长，提供了一个额外但噪声更大的信号。
审查系统吸收了额外的量
从拉取请求创建到合并的中位时间从 11.2 小时降至 3.1 小时，减少了 72%，即便每位开发者的产出增长了 4.5 倍。从开发者的角度来看，这一减少至关重要。漫长的合并时间会导致审查积压，开发者可能同时并行处理 20 个打开的 PR，这对我们大多数人来说很快就会不堪重负；缺陷可能数天或数周无人修复。较短的合并时间（如 3 小时）确保开发者一次只处理几个打开的 PR，缺陷修复能在数小时内落地。
测得的质量信号有所改善
14 天内被回滚的拉取请求百分比从 1.9% 降至 0.4%。回滚率并非质量的完整衡量标准（许多缺陷是向前修复或后来才发现的），但它提供了一个一致的信号，表明更高的产出和更快的合并并未伴随更多即时回滚。
这些数字是一项纵向案例研究，而非对照实验。11 月包括对 Opus 4.5 的访问（这是我们发现第一个足够可靠、能端到端完成常规工程任务的模型）以及我们旧版审查机器人的部署。模型持续改进，但我们在研究期间没有看到另一次可比的阶跃变化。采用情况、工作流和工作组合也在演变，因此这些里程碑展示的是我们构建了什么以及何时构建——而非每个组件的因果贡献。
这一趋势确实表明，随着自动化从代码生成扩展到规划、审查、验证、反馈和运维，产出持续增长。
我们学到了什么
跟随瓶颈，而非生命周期顺序
部署顺序遵循我们遇到的瓶颈，而非软件生命周期的顺序。我们从自动化代码审查开始，因为我们的审查积压在 1 月迅速增长。同样，我们只在 Slack 反馈渠道开始消耗过多开发者时间时才自动化反馈分类。
只有当整个系统能够吸收这些工作时，吞吐量才会增加
仅增加代码生产会形成更大的审查队列。重要的结果不仅仅是每位开发者的 PR 数量增加。而是规模调整后的产出上升，同时中位合并时间和测得的回滚率下降。
我们把积压的工作视为库存。任何环节中不断增长的队列——等待实现的工单、等待审查的 PR、等待验证的变更，或等待调查的反馈——都向我们指明了下一笔投入应该放在哪里。
智能体需要与工程师相同的证据和环境
仅有代码仓库访问权限是不够的。当我们的智能体能够使用 CI、测试环境、日志、指标、工单、文档、部署状态，以及编码在技能和运行手册中的操作流程时，它们才变得更有用。
这对 Verifier 和 Incident Investigator 尤为重要。它们的价值来自收集可检查的运行时证据，而不是仅基于代码给出看似合理的解释。
保留人类对判断的所有权
我们设计这座工厂时并未追求完全自主。就像新入职的工程师一样，智能体并不总是具备在多个合理设计之间做出选择所需的组织背景。仓库指南和产品规格可以缩小这一差距，但新出现的问题仍然需要人类判断。因此，我们设计每个工作流时都让机械性工作自动化，同时保留人类的所有权。
智能体提出架构选择、收集证据、执行重复性分析、实现已批准的工作、运行并修复测试，以及解决机械性反馈。工程师做出产品和架构决策、评估模糊的权衡、批准生产风险，并在部署后继续对系统负责。
采用滞后于部署
部署一个智能体并不会立即改变工程行为。团队需要时间来理解它的优势、检查它的证据、纠正它的行为，并信任它去执行更长期的工作。我们还必须根据反馈调整每个智能体，确保它为每个团队独特的工作流具备正确的护栏、身份验证和配置。因此，一些可衡量的效果在相应的部署里程碑之后数周才显现出来。
这座工厂仍在演进
我们于 11 月起步，当时只有 IDE 和 CLI 编码智能体、对更强模型的访问权限，以及一个遗留的 AI 审查机器人。到 8 月初，专门的智能体已在规划、实现、审查、验证、反馈和事件响应等环节运作。
没有任何单个智能体或模型发布能够解释每位开发者经规模调整后的产出提升 4.5 倍。这一变化与反复识别工程工作在哪里等待，并构建推动其通过系统所需的下一个组件同时发生。
这座工厂并没有将工程师从软件开发中移除。它把他们的注意力从重复性调查和执行转移到了决策、所有权和学习上。我们的目标很简单：在保持质量门槛不变的同时，持续提升工程速度。
如果你正在构建自己的工厂，就从工作堆积的地方开始。你可以用一个工作流试用 Cosmos，并在它证明有用后逐步扩展。
来源：Augment Code Blog · augmentcode.com