Warp团队：从本地智能体到云端工厂，先爬再走然后跑
软件工厂方法（在云端运行的封闭智能体循环）正越来越受欢迎，但落地可能让人望而生畏。在本文中，我将介绍从本地交互式智能体过渡到云端自动化开发的“爬、走、跑”三步路径。
爬
很多工程负责人和平台工程师已经开始了软件工厂搭建的“爬”阶段：他们借助云端智能体搭建了简单的自动化工具。可以把这些自动化理解为“触发→智能体活动”的模式。
例如：
- 问题复现与分类：让智能体审查所有新提交的问题，复现并打标签。
- 代码审查：在PR打开时自动审查并留下评论。
- 监控：让智能体响应Sentry告警，调试并修复问题。
- CI自愈：识别需要回滚的PR、解决待处理的合并冲突，修复损坏的CI。
- 文档自动更新：更新面向用户的文档并生成变更日志。
- 验证：使用浏览器操作和计算机操作智能体进行可视化QA并验证变更。
- 简单错误修复：智能体识别并修复用户报告的简单问题。
所有这些方式的共同点在于：它们自动化了软件生命周期中的某个离散环节。从简单自动化开始是一种低风险、低成本的做法，还能帮助团队建立直觉，了解如何在更复杂的多阶段任务中有效使用智能体。
这些自动化可以使用自建基础设施（例如将Claude Code SDK放入Docker容器，再连一个服务器来触发它），也可以使用一个专门用于在触发条件下运行智能体的通用云端智能体自动化平台，还可以使用专门服务生命周期某一阶段的整体平台（例如专门的智能体代码审查器或AI SRE）。
从一个由单点自动化拼凑起来的方案开始没问题，但大多数团队最终会碰到这种做法的天花板。
具体来说：
- 取决于搭建方式，这些自动化之间可能无法共享上下文。这意味着当你在某一环节（比如代码审查）做改进时，这些改进不会传导到分类和QA等其他环节。
- 没有全局视图来判断所有这些一次性自动化是否真的在提升整体生产力，也没有系统的方法来测试和改进你关心的顶层指标，比如单次PR成本、周期时间、自动化占比等。要追踪这些指标，你需要一个跨开发阶段运转的系统。
- 每个点方案都带来各自的搭建和维护负担，形成更大的安全暴露面需要管理，也没有统一的可观测性接口。团队最终会想要集中配置、审计和治理。
走
所有这些问题的指向，都是需要一种更整体的方法。已经完成“爬”阶段的组织会问自己：“我们到底想要什么系统，才能真正规模化智能体开发？”
更具体地说，他们会问：
- 开发应该在哪里发生？本地还是云端？通过什么接口？
- 一个成功的自动化开发流程应该是什么样？关键指标是什么？
- 我们的AI主权立场是什么？拥有我们的编码智能体数据有多重要？我们该在多大程度上依赖模型提供商？
- 我们计划如何随着时间改进开发流程？如何在加快发布速度的同时控制成本？我们怎么知道自己真的在进步？
- 随着模型和智能体不断进步，我们如何面向未来？是否考虑到了可能影响模型访问渠道的监管风险？
- 工程师应该以什么方式参与开发流程？设计师、PM和其他构建者呢？
- 我们如何保障开发安全？如果软件生产流程被攻破，我们的应对计划是什么？
大多数认真思考这些问题的工程负责人和平台团队，最终都会落在类似云端软件工厂的方案上。他们想要：
- 默认在云端开发，因为给智能体提供沙箱比让它们在本地放开跑更安全
- 对编码智能体及其访问的工具和系统进行集中治理
- 完整的智能体行为轨迹，用于审计和了解生产力
- 围绕模型和框架的弹性选择，以最小化风险并优化性能
- 让开发融入团队已在使用的所有工具（如Slack/Teams、Jira、Github等）
- 为人工接管提供逃生通道：可以引导实时智能体，也可以把工作带回内部开发循环
- 一个跨开发全阶段、跨智能体共享的上下文层
- 一套支持测试、评估和基准测试的方法，让团队对系统持续改进保持信心
公司一旦决定采用工厂方案，问题就变成：如何从现有的单点自动化过渡过去？这通常归结为两个选择：（1）围绕现有自动化再搭建更多基础设施；（2）迁移到像Warp Factories这样的平台，让它提供工厂基础设施。
注意，我不会把这件事框定为传统的自建vs.购买决策。无论走哪条路，你的内部团队都应该预期要做一些开发，因为要让工厂方案真正生效，工厂必须深度融入团队的上下文和工作流。这更多是一个问题：你是完全从零搭建自己的自动化基础设施，还是与能给你起步助力的伙伴合作。
例如，无论走哪条路，你都应该预期为组织开发专属技能，并针对你的代码库进行调优；你应该预期去暴露和配置组织专属的MCP和内部上下文来源。但你可能并不想搭建用于运行和管理智能体、引导它们、交接它们的工作、衡量效果、执行计算机操作等所需的云端基础设施。经验法则是：专注构建你组织特有的部分，而不是每个组织都需要的部分。
无论走哪条路，“走”阶段最大的里程碑，都是在一个简单的产品面上端到端部署第一个工厂。这可以是你的营销网站，也可以是一个内部应用。
从一个简单项目开始的好处在于，你能以低风险和最低复杂度跑通完整的循环。加入更多代码库、代码行、服务依赖、人类相关方等等，都会增加复杂度，并可能让你产生“还没准备好自动化”的感觉。最好先把一个简单循环调通。
目标是搭建一个从“分类→规格→实现→审查→验证→监控”的多智能体系统。具体展开：
- 新问题进入系统，要么由人工提交，要么由监控智能体产生
- 分类智能体运行，尝试理解并复现问题。如果判断任务可自动化→交给实现智能体。如果因范围问题需要规格→由规格智能体与人类迭代产出规格。如果存在歧义→请人工输入并重新运行，或者决定暂时搁置问题
- （如有必要）规格智能体运行，人工审查规格，再交给实现智能体
- 实现智能体编写代码
- 代码审查智能体审查代码
- 验证智能体执行计算机操作或其他验证
- 人工审查代码和验证输出。如有必要，回到第2、3、4或5步
- CI/CD
- 发布上线
- 监控智能体运行，有需要就创建问题，完成闭环
在Warp内部，我们的“走”阶段工厂自动化了warp.dev（我们的营销网站）约75%的变更。与Warp Terminal（GitHub上6.5万星标、近百万活跃开发者、100万行原生Rust代码）不同，我们的营销网站是一个相当简单的应用。注意，这里的“自动化”指的是从人工输入到功能发布，全程通过工厂完成，人工只在Slack或任务追踪器里描述我们想要的变更，除此之外几乎没有其他人工触点。
跑
只有当你已经在简单项目上把基础循环跑通，才应该扩展到更复杂的项目。扩展工厂需要更稳健的基础设施。
具体来说，扩展时会有这些瓶颈浮现：
- 在大型项目上让远程开发环境正常工作很难。代码库更多、代码行数更多、服务依赖更多，都会让自动化更难。
- 当你有更多技能和代码时，会更难判断你对工厂做的修改到底对开发产生了正向影响，还是只是在制造无效变动。
- 智能体在更复杂的代码库上干活，你自然会面临更高的成本风险，因为你需要更强的模型，且智能体需要跑更长时间。模型路由和框架选择变得更重要。
- 工厂方法越是用到面向用户的关键应用上，安全和审计就越重要。
- 应用涉及的相关方越多，意味着需要更多的人工协调和签字。你需要一个支持多参与者输入和审计轨迹的工厂方案。
- PR不可避免地会开始堆积，所以你需要一个明确策略：什么需要代码审查、如何使用智能体验证和QA。
- 你会需要更可靠的闭环工具，确保交付到生产的变更质量过关，不会崩溃等等。
在我看来，让规模化工厂真正运转起来，会是未来几年最有趣的软件工程挑战之一；软件工程正在变成工厂工程。能让自己的工厂变得稳健、可靠、自我改进的组织，将以更优的成本交付更多产品，并拥有竞争优势。
要让工厂真正轰鸣运转，需要大量投入。在Warp，我们把这视为完整构建你的工厂栈。我在这篇文章中详细介绍了每一层。有几个可能不太明显、值得指出的关键点：
- 工厂即代码：一个关键选择是把你的工厂定义为代码。这样可以测试不同工厂配置，看看哪些效率最高、质量最好等。
- 多模型、多框架：你要确保工厂能使用最新模型，包括前沿模型和开放权重模型，并且能使用像Claude Code和Codex这样的不同编码智能体框架。
- 数据所有权：你要确保存储并拥有工厂产出的所有数据——这是改进工厂运转的原材料。
在一个真正轰鸣运转的工厂里，关键特征是它是一个闭环、可测量、可改进的系统。这应该是目标。在这样的系统中，每个人都基于同一份上下文工作，以公开、完全可审计、可观察的方式进行。智能体自己也在观察驱动系统的那些技能和配置，并提出改进建议。平台工程师可以扩展系统，把它集成到所有内部系统。工程负责人能看到生产力指标，并理解为了改进这些指标正在做什么样的变革。整个系统依靠实证数据运转，而非凭感觉。
在Warp，我们正逐渐接近这个愿景。每一天，我们都在公开状态下工作，调优工厂，压低成本，提升吞吐量和质量。
我们的使命是给世界上最优秀的工程团队提供工具，让他们能够在开放基础设施上，使用任意底层模型和框架，去构建、测量并优化自己的工作流。这些能力会帮助团队更快、更高效地交付更好的软件。
Warp Factories当前处于早期体验阶段。符合条件的公司可获得1万美元的工厂使用额度。