软件工厂采用指南：循序渐进实施路径

软件工厂方法（一种在云端运行的闭环 Agent 循环）正日益流行，但采用起来可能令人望而生畏。在这篇文章中，我将介绍从本地交互式 Agent 过渡到自动化云端开发的“爬行、行走、奔跑”步骤。

爬行

我与之交流过的许多工程领导者和平台工程师已经通过构建简单的自动化开始“爬行”阶段，他们使用云端 Agent 来搭建软件工厂。

将这些自动化视为：触发器 → Agent 活动。

例如：

问题复现与分类：让 Agent 查看所有新提交的问题，进行复现并打上标签。
代码审查：自动审查新提交的 PR 并留下评论。
监控：让 Agent 响应 Sentry 警报，调试并修复问题。
CI 自愈：通过识别需要回滚的 PR 和需要解决的合并冲突来修复损坏的 CI。
文档自动更新：更新面向用户的文档并生成变更日志。
验证：browser-use 和 computer-use Agent 通过视觉方式对变更进行 QA 和验证。
简单 Bug 修复：Agent 识别并修复用户报告的简单问题。

所有这些方法的共同点在于，它们自动化了软件生命周期中的离散部分。从简单的自动化入手是一种低风险、低成本的方法，有助于建立直觉，了解如何在更复杂的多阶段任务中有效使用 Agent。

警报监控的自动化示例

这些自动化可能是基于自建基础设施构建的（例如，将 Claude Code SDK 放入 Docker 容器并配置服务器以触发它），或者使用旨在根据触发器运行 Agent 的通用云端 Agent 自动化平台。它们也可能使用专门针对生命周期某一阶段的完整平台（例如，专用的 Agentic 代码审查工具或 AI SRE）。

从一系列点对点自动化开始是可以的，但大多数团队最终会在这种方法上遇到瓶颈。

具体来说：

取决于设置方式，这些自动化可能不共享上下文。这意味着当你改进某一方面（比如代码审查）时，这些改进不会延续到其他阶段，如分类和 QA。
没有全局视图来判断所有这些一次性自动化是否真正提高了整体生产力，也没有系统的方法来测试和改进你关注的高层指标，如每 PR 成本、周期时间、自动化百分比等。要跟踪这些指标，你需要一个跨开发阶段工作的系统。
每个点解决方案都会产生自己的设置和维护负担。它们扩大了需要管理的安全面。它们没有统一的观测接口。团队最终希望实现集中配置、审计和治理。

行走

所有这些问题都指向了对更全面方法的需求。已经完成“爬行”阶段的组织会问自己：“我们想要什么样的系统来真正扩展 Agentic 开发？”

更具体地说，他们会问：

开发应该在哪里进行？本地还是云端？通过什么接口？
成功的自动化开发流程是什么样的？关键指标有哪些？
我们的 AI 主权立场是什么？拥有编码 Agent 数据有多重要？我们应该多大程度上依赖模型提供商？
我们计划如何随时间改进开发流程？如何在加速交付的同时控制成本？我们如何知道自己在进步？
随着模型和 Agent 的改进，我们如何确保未来适应性？我们是否考虑了可能影响模型访问的监管风险？
工程师究竟应该如何参与开发过程？设计师、PM 和其他构建者呢？
我们如何保障开发安全？如果我们的软件生产流程受到攻击，我们的计划是什么？

大多数深入思考这些问题的工程领导者和平台团队最终会倾向于云端软件工厂方法。他们希望：

默认在云端进行开发，因为给 Agent 提供沙箱比让它们在当地自由运行更安全。
对编码 Agent 及其访问的工具和系统进行集中治理。
完整记录 Agent 的操作，用于审计和理解生产力。
在模型和框架方面保持选择性，以最小化风险并优化性能。
将开发集成到团队已经在使用的各种工具中（例如 Slack/Teams, Jira, Github 等）。
为人类提供接管途径，无论是通过引导实时 Agent 还是将工作带入内部开发循环。
一个跨 Agent 且覆盖所有开发阶段的共享上下文层。
一种允许进行测试、评估和基准测试的方法，以便团队有信心系统正在随时间改进。

一旦公司决定采用工厂方法，问题就变成了：如何从现有的点对点自动化过渡到那里？这通常归结为是 (1) 围绕这些自动化构建更多基础设施，还是 (2) 过渡到像 Warp Factories 这样提供工厂基础设施的平台。

请注意，我不建议将其视为传统的“自建 vs. 购买”决策。无论你选择哪条路径，都应该预期内部团队需要进行一些构建，因为要使工厂方法奏效，该工厂必须深度集成到你团队的上下文和工作流中。这更多是一个关于你是完全从零开始构建自动化基础设施，还是与那些为你提供先发优势的人合作的问题。

例如，无论你选择哪条路径，都应该预期构建特定于组织的技能并针对你的代码库进行调优。你应该预期暴露并配置特定于组织的 MCP 和内部上下文源。但是，你可能不想构建用于运行和管理 Agent、引导它们、交接工作、衡量其效能、执行计算机操作等等的云基础设施。经验法则是专注于构建特定于你组织的部分，而不是每个组织都需要的通用部分。

无论你采取哪种方法，我建议行走阶段的最大里程碑是在一个简单的产品表面上端到端地部署第一个工厂。这可能是你的营销网站或内部应用。

从一个简单的项目开始的好处在于，可以在低风险和最小复杂度的情况下启动整个循环。添加更多的仓库、代码行、服务依赖、人类利益相关者等会增加复杂性，并可能导致你觉得还没有准备好进行自动化。最好先调整一个简单的循环。

目标是建立一个多 Agent 系统，涵盖分类 → 规格说明 → 实施 → 审查 → 验证 → 监控。更详细地说：

新问题进入系统，要么通过人类，要么通过监控 Agent。
分类 Agent 运行，尝试理解并复现问题。如果确定任务可自动化 → 交给实施 Agent。如果因范围原因需要规格说明 → 让规格说明 Agent 与人类迭代以制定规格。如果模糊不清 → 获取人类输入并重试，或者直接决定暂时搁置该问题。
[如有必要] 规格说明 Agent 运行，人类审查规格，然后传递给实施 Agent。
实施 Agent 编写代码。
代码审查 Agent 审查代码。
验证 Agent 执行计算机操作或其他验证。
人类审查代码和验证输出。如有必要，返回步骤 2、3、4 或 5。
CI / CD。
发布。
监控 Agent 运行，如有需要则创建问题，完成循环。

在 Warp 内部，我们的行走工厂自动化了 warp.dev（我们的营销网站）约 75% 的变更。与 Warp Terminal（6.5 万 GitHub 星标，近百万活跃开发者，100 万行原生 Rust 代码）不同，我们的营销网站是一个相当简单的应用。请注意，这里的“自动化”是指从人类输入到功能发布完全通过工厂完成，除了描述我们想要的变更外，几乎没有其他人类接触点，无论是在 Slack 中还是在我们的任务追踪器中。

奔跑

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

具体来说，随着规模扩大，某些瓶颈会出现：

在大型项目中让远程开发环境正常工作很难。更多的仓库、代码行、服务依赖都会使自动化变得更难。
随着技能和代码等的增加，很难判断你对工厂所做的更改是对开发产生了积极影响，还是仅仅造成了混乱。
当 Agent 在更复杂的代码库上工作时，你自然会面临更高的成本风险，因为你需要更强大的模型，且 Agent 需要运行更长时间。模型路由和框架选择变得更加重要。
随着你将工厂方法应用于关键的用户面向应用，安全和审计变得更加重要。
更多的应用利益相关者意味着更多的人类协调和签核。你会希望有一个支持多人输入和审计轨迹的工厂解决方案。
不可避免地，PR 会开始堆积，因此你需要一个明确的策略来决定哪些代码需要审查，以及如何利用 Agentic 验证和 QA。
你会需要更健壮的工具来闭合循环，确保发布到生产的变更质量高、不崩溃等。

在我看来，让规模化工厂正常工作将是未来几年最有趣的软件工程挑战之一；软件工程正在变成工厂工程。能够使其工厂稳健、可靠且自我改进的组织将以更好的成本交付更多产品，并获得竞争优势。

要让工厂真正高效运转需要大量投入。在 Warp，我们将此视为完整构建你的工厂技术栈：

我在本文中详细介绍了每一层：

https://x.com/zachlloydtweets/status/2097739116720910619

有几个关键点值得强调，它们可能并不显而易见：

工厂即代码：你可以做出的关键选择之一是将工厂定义为代码。这使得测试不同的工厂配置成为可能，以查看哪些配置效率最高、质量最好等。
多模型与多框架：你应该确保你的工厂能够使用最新的模型，包括前沿模型和开放权重模型，并使用不同的编码 Agent 框架，如 Claude Code 和 Codex。
数据所有权：你应该确保存储并拥有从工厂产生的所有数据——这是改进其运营的原材料。

在一个完全高效运转的工厂中，关键特征是它是一个闭环、可测量、可改进的系统。这应该是目标。在这样的系统中，每个人都在相同的上下文中公开工作，处于完全审计和观察的状态。Agent 本身也在观察驱动系统的技能和配置，并提出改进建议。平台工程师能够扩展系统，将其集成到所有内部系统中。工程领导者可以看到生产力指标，并理解正在做出哪些更改以改进它们。整个过程是基于实证运行的，而不是凭感觉。

在 Warp，我们正在接近这一愿景。每一天，我们都在公开环境中工作，调优我们的工厂，降低成本并提高吞吐量和质量。