采用软件工厂模型的爬行-行走-奔跑框架

# 采用软件工厂模型：爬行、行走、奔跑

软件工厂方法（一种在云端运行的封闭式智能体循环）正日益流行，但采用起来可能令人望而生畏。在这篇文章中，我将介绍从本地交互式智能体过渡到自动化云端开发的"爬行、行走、奔跑"步骤。（https://www.warp.dev/blog/a-guide-to-cloud-software-factories-for-engineering-leaders）

## 爬行

与我交流过的许多工程负责人和平台工程师，已经开始了构建软件工厂"爬行"阶段的工作，即利用云端智能体构建简单的自动化流程。（https://docs.warp.dev/platform/）

将这些自动化流程理解为：触发器 → 智能体活动。

例如：

- 问题复现与分类：让智能体查看所有新提交的问题，对其进行复现并打上标签。（https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-the-automatic-triage-skill）

- 代码审查：在 PR 被打开时自动进行审查并留下评论（https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-self-improving-code-review）

- 监控：让智能体响应 Sentry 告警，调试并修复问题

- 自愈 CI：通过识别需要回滚的 PR、解决合并冲突来修复失败的 CI

- 自动更新文档：更新面向用户的文档并生成变更日志

- 验证：浏览器智能体和计算机操作智能体对变更进行可视化质量保证与验证（https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-computer-use-verification）（https://docs.warp.dev/agents/capabilities/computer-use/browser-use/）

- 简单缺陷修复：智能体识别并修复用户反馈的简单问题

以上所有方法的共同点在于：它们都将软件生命周期中某个独立的环节自动化了。从简单的自动化开始，是一种低风险、低成本的方式，有助于建立对如何在更复杂的多阶段任务中有效使用智能体的直觉。

这些自动化可能是基于自研基础设施构建的（例如将 Claude Code SDK 放入 Docker 容器中，并搭建一个服务器来触发它），也可能使用专为在触发器上运行智能体而设计的通用云端智能体自动化平台。它们还可能使用专门针对某一开发阶段的完整平台（例如专用的智能体代码审查工具或 AI SRE）。（https://docs.warp.dev/platform/）

从一系列零散的点式自动化开始并无不妥，但大多数团队最终都会遭遇这种方式的局限。

具体来说：

- 根据配置方式的不同，这些自动化可能不共享上下文。这意味着当你改进某一方面（比如代码审查）时，改进效果不会延续到其他阶段，如分类和质量保证。

- 没有全局视角来判断所有这些一次性自动化是否真正提升了整体生产力，也没有系统性的方式来测试和改进你所关注的高层指标，例如每 PR 成本、周期时间、自动化占比等。要跟踪这些指标，你需要一个贯穿各开发阶段的系统。（https://www.warp.dev/blog/agent-self-improving-software-factories）

- 各点式解决方案各自带来独立的部署与维护负担，扩大了需要管理的安全攻击面，也没有统一的可观测性界面。团队最终需要集中化的配置、审计与治理能力。

## 行走

所有这些问题都指向了采用更整体性方法的必要性。已经完成"爬行"阶段的组织会问自己："我们希望拥有怎样的系统，才能真正实现智能体开发的规模化？"

更具体地说，他们会问：

- 开发应该在哪里进行？本地还是云端？通过什么界面？

- 一个成功的自动化开发流程应该是什么样的？关键指标是什么？

- 我们的 AI 自主性立场是什么？拥有我们的编程智能体数据有多重要？我们应该在多大程度上依赖模型提供商？

- 我们计划如何随时间推移改进开发流程？如何在控制成本的同时加快交付速度？我们如何知道自己在不断进步？

- 我们如何应对模型和智能体持续演进带来的未来挑战？是否已将可能影响模型访问的监管风险纳入考量？

- 工程师究竟应如何参与开发流程？设计师、产品经理及其他构建者又该如何参与？

- 我们如何保障开发安全？如果软件生产流程遭到入侵，我们的应对方案是什么？

大多数认真思考这些问题的工程负责人和平台团队，最终都会落脚于某种云端软件工厂方案。他们希望实现（https://docs.warp.dev/factories/）

- 默认在云端开发，因为为智能体提供沙箱环境比让其在本地自由运行更为安全（https://www.warp.dev/blog/if-you-want-better-agent-roi-and-governance-move-your-agents-to-the-cloud）

- 对编码智能体及其所访问的工具和系统实施集中治理

- 完整记录智能体的操作轨迹，用于审计与生产力分析

- 在模型和运行框架上保留灵活选择空间，以降低风险并优化性能

- 将开发流程集成到团队已在使用的所有工具中（例如 Slack/Teams、Jira、Github 等）

- 为人工接管提供退出通道，既可实时干预正在运行的智能体，也可将工作纳入内部开发循环（https://docs.warp.dev/factories/factory-dashboard/）（https://docs.warp.dev/factories/factory-mcp/）

- 一个跨智能体、贯穿开发各阶段的共享上下文层

- 支持测试、评估和基准测试的方案，使团队对系统的持续改进保持信心（https://docs.warp.dev/factories/benchmarks/）

一旦公司决定采用工厂方案，问题就变成：如何从现有的单点自动化过渡到这一目标？这通常归结为两种选择：（1）在现有自动化基础上构建更多基础设施，或（2）迁移至 Warp Factories 等平台以获取工厂基础设施。（https://www.warp.dev/factories）

需要指出的是，我不会将此框定为传统的"自建与采购"决策。无论走哪条路，都应预期内部团队需要承担一定的构建工作——因为要让工厂方案真正奏效，该工厂必须与团队的上下文和工作流深度集成。真正的问题在于：你是完全从零开始构建自动化基础设施，还是与能为你提供先发优势的合作伙伴携手前行。

举例来说，无论选择哪条路，都应预期要构建特定于组织的技能，并针对自身代码库进行调优；也应预期要开放和配置特定于组织的 MCP 以及内部上下文来源。但你或许并不想自行构建用于运行和管理智能体、对其进行引导、交接工作成果、衡量效能、执行计算机操作等方面的云基础设施。经验法则是：专注于构建那些对你的组织独一无二的部分，而非每家组织都需要的通用部分。

无论采用哪种方式，我认为"行走阶段"最重要的里程碑，是在一个简单的产品界面上端到端地部署第一个工厂。这可以是你的营销网站，也可以是一个内部应用。（https://docs.warp.dev/factories/quickstart/）

从一个简单项目起步的好处在于，能够以低风险、低复杂度跑通整个闭环。引入更多代码仓库、代码行数、服务依赖和人员干系方等因素会增加复杂性，容易让人觉得尚未准备好推进自动化。不如先把简单闭环调试到位，再逐步扩展。

目标是构建一个多智能体系统，流程为：分诊 → 规格说明 → 实现 → 审查 → 验证 → 监控。更详细地说：(https://docs.warp.dev/factories/how-factories-work/)

1. 新问题进入系统，来源可以是人工输入，也可以是监控智能体

1. 分诊智能体运行，尝试理解并复现问题。若判断任务可自动化 → 移交给实现智能体。若因范围问题需要规格说明 → 让规格说明智能体与人类协作，共同制定规格说明。若问题模糊 → 获取人工输入后重新运行，或直接决定搁置该问题

1. 【如有必要】规格说明智能体运行，人工审查规格说明，然后移交给实现智能体

1. 实现智能体编写代码

1. 代码审查智能体审查代码

1. 验证智能体通过计算机操作或其他方式进行验证 (https://docs.warp.dev/agents/capabilities/computer-use/testing-and-recordings/)

1. 人工审查代码和验证输出。如有必要，返回第 2、3、4 或 5 步

1. CI / CD

1. 发布上线

1. 监控智能体运行，如有需要则创建问题，从而形成闭环

在 Warp 内部，我们的工厂流程（walk factory）实现了约 75% 的 warp.dev 营销网站变更的自动化。与 Warp Terminal（GitHub 65k 星标，近百万活跃开发者，100 万行原生 Rust 代码）不同，我们的营销网站是一个相当简单的应用。这里所说的"自动化"，是指从人工输入到功能上线完全通过工厂完成，人工介入极少，只需在 Slack 或任务跟踪工具中描述所需变更即可。(http://warp.dev/) (https://docs.warp.dev/factories/connect-your-factory/)

## 运行

只有当你在一个简单项目上建立起基本循环之后，才应该扩展到更复杂的项目。扩展工厂需要更健壮的基础设施。

具体而言，随着规模扩大，某些瓶颈会逐渐显现：

- 在大型项目上让远程开发环境正常运行是件难事。更多的代码仓库、代码行数、服务依赖，都会让自动化变得更加困难。(https://docs.warp.dev/guides/agent-workflows/run-a-software-factory-in-the-cloud/)

- 随着技能和代码量的增加，越来越难以判断你对工厂所做的调整究竟是在正向推动开发，还是只是在制造无效变动

- 由于智能体在更复杂的代码库上工作时需要更强大的模型、运行时间也更长，成本风险自然随之上升。模型路由和运行框架的选择变得更加重要。

- 当工厂方案被引入到面向用户的关键业务应用中时，安全性和审计变得更加重要

- 更多的应用利益相关方意味着更多的人工协调与审批。你需要一套支持多方输入和审计追踪的工厂解决方案

- PR 不可避免地会堆积，因此你需要制定明确的策略，决定哪些代码需要人工审查，以及如何使用智能体进行验证和质量保障

- 你需要更健壮的工具来形成闭环，确保发布到生产环境的变更质量过硬、不会崩溃等

在我看来，让规模化工厂真正落地运转，将是未来几年最有趣的软件工程挑战之一；软件工程正在演变为工厂工程。那些能够让工厂变得健壮、可靠、自我优化的组织，将能够以更低成本交付更多成果，并获得竞争优势。(https://www.warp.dev/blog/we-are-now-factory-engineers-not-product-engineers) (https://www.warp.dev/blog/engineering-self-improving-software-factories)

要让工厂真正高效运转，需要大量投入。在 Warp，我们将其理解为全面构建你的工厂技术栈：

在这篇文章中，我将详细介绍其中每一个层次：

以下几个关键点值得特别指出，因为它们可能并不那么显而易见：

- 代码即工厂：你可以做出的关键选择之一是将工厂定义为代码。这使得对不同工厂配置进行测试成为可能，从而找出哪种配置最高效、质量最优等。(https://docs.warp.dev/factories/factory-as-code/)

- 多模型与多执行框架：你应确保工厂能够使用最新模型，包括前沿模型和开放权重模型，并支持使用不同的编码智能体框架，如 Claude Code 和 Codex。(https://docs.warp.dev/factories/factory-agents/)

- 数据所有权：你应确保存储并拥有从工厂输出的所有数据——这是改进工厂运营的原始素材。(https://docs.warp.dev/factories/infrastructure-and-security/)

在一个完全高效运转的工厂中，其核心特征是：它是一个闭环的、可量化的、可持续改进的系统。这应当是我们的目标。在这样的系统中，所有人都在同一上下文中工作，以公开透明、完全可审计、可观察的方式协作。智能体本身会观察驱动系统运行的技能与配置，并主动提出改进建议。平台工程师能够扩展系统，将其集成到所有内部系统中。工程领导者可以查看生产力指标，并了解正在推进哪些改进措施。整个系统以实证方式运行，而非凭感觉行事。(https://www.warp.dev/blog/agent-self-improving-software-factories)

在 Warp，我们正在不断接近这一愿景。每天，我们所有人都在以公开透明的方式工作，持续调优我们的工厂，降低成本，提升吞吐量与质量。

我们的使命是为全球最优秀的工程团队提供工具，帮助他们在开放基础设施上，利用任意底层模型和执行框架，构建、衡量并优化自己的工作流程。这些能力将帮助团队更快速、更高效地交付更优质的软件。

Warp Factories 目前处于早期访问阶段。符合条件的公司可获得价值 1 万美元的工厂使用额度。(https://www.warp.dev/factories)(https://docs.warp.dev/factories/)