软件工厂不是只用提示词串云代理，很多公司已后悔

别用“vibe coding”方式搭建你的软件工厂
我经常在推特上看到一些帖子，暗示搭建一个软件工厂只需要用一串提示词把云代理串联起来就行。但根据我与大量客户合作的经验，这种想法是错误的。很多公司从这种方式起步，最终却后悔了，因为它无法规模化。这些公司想要的是有韧性、可改进、低延迟的工厂，并且能与它们现有的工具深度集成。它们想要高水平的可配置性和可度量性。它们想要审计日志、安全保证——简而言之，它们对自己的工厂有着与对产品同等的生产质量要求，因为它们押注于软件工厂，将其视为更快交付产品的未来。
这篇文章将深入探讨构建生产级软件工厂需要什么。我说的“软件工厂”是指一个可度量、可改进的云端系统，用于在整个组织中规模化运行编码代理，以实现最大ROI和生产力。正如我之前写过的，正确的思考方式是把软件工厂视为基础设施，并具有明确定义的技术栈。

实现技术栈——工厂即代码

在技术栈的底层，你用代码定义工厂。代码里包含在工厂中完成工作所需的全部描述：代理提示词、工作流、MCP、技能、运行器配置、集成配置、自动化，以及所有用于度量、评估和基准测试的机制。可以把它看作是你公司构建软件所需的所有编码代理工作流的Terraform。
代码方法很关键，因为它解锁了系统化测试不同工厂配置并度量其性能的能力。它可以让你回答这类问题：“对于前端任务，使用开放权重模型可以吗？我真的需要X、Y、Z技能才能获得高质量输出，还是它们只是在浪费token？”通过用代码定义工厂，你还允许编码代理对工厂定义提出建议并进行修改——这是自我改进的基础。
所以第一个技术挑战是如何建立基于代码的工厂执行。对于Warp Factories，代码格式是内置的。如果你想自己搭建，你需要创建一种代码格式，尽可能多地描述如何在工厂中完成工作。
例如，假设你有一个用于从Sentry分类并修复服务器崩溃的工厂工作流。你的工厂代码需要支持：
定义与Sentry的集成：
Webhook是什么、负载格式、认证机制等。
当事件到达时调用哪个工作流。
该工作流的细节：
处理服务器错误的步骤是什么？
是自动分类还是自动修复？
工厂是否需要人工介入？
修复问题是否需要规格说明？如果需要，何时给出？
如果生成PR，作者是谁？
谁应该审查？
如何验证PR是正确的？
需要几轮审查？
是否使用计算机使用验证？
等等……
运行器配置：
这个工作流在哪里运行？
沙箱配置和工具链是什么？
它可以访问哪些仓库？
除了Sentry之外，还需要哪些MCP？
它们如何认证？
代理如何与你的源代码托管平台通信？与你的任务跟踪器呢？
工作流中不同步骤使用哪些模型和框架？
模型路由策略是什么？
数据：
这个工作流生成的所有数据存储在哪里？
你如何评估这个工作流与人工分类相比是否具有成本效益？
你如何随时间改进这个工作流？
重点是，即使支持一个看起来简单的工作流也需要丰富的配置。
以下是Warp Factories中支持所有这些的代码格式示例（完整示例）：

实现技术栈——编排

一旦你有了代码格式，就需要向上移动技术栈，构建一个编排层，它接收该格式并推动工作在其中流动。它需要：
读取当前版本的代码（如果你在运行实验，也可以读取某个分支）
按需启动正确的沙箱，并具有低延迟和高可靠性
根据工厂代码中的内容，将一个或多个代理路由到正确的模型和框架配置，以处理该工作
提示它们按照工厂代码中的定义处理工作
将任何工件和代理追踪记录到持久化存储中
在需要时让人类介入，包括让他们能够交接或引导迄今已完成的代理工作
与所有其他参与系统集成，如Sentry、Github、Jira、Slack等。
编排从根本上说就是启动并协调云代理。对于一些主要进行本地开发的组织来说，仅仅让云代理运行起来就是一项大工程。这类似于为人类工程师设置远程开发环境，我们合作的许多公司都会复用这些基础设施来进行代理沙箱化。
但情况也可能不同。你可能希望远程通过SSH工作的人类工程师比你的代理拥有更广泛的权限和工具。他们可能获得不同的MCP访问权限。他们可能能够访问环境中的机密（代理不应该能访问）。同样，重点是，根据组织的规模和大小，设置这些需要大量的工程和配置工作。
一旦你有了云执行能力，你的编排器还需要具有韧性和持久性。如果代理中途崩溃，它能否从上次中断的地方恢复，而不会重复工作、浪费token？如果Github宕机（想象一下！），它能否执行合理的重试策略？这指向需要有内置的检查点和持久性，也许可以使用类似Temporal的工具。
当编排是响应直接的人工提示（例如来自Slack）时，它需要低延迟，否则会浪费人的时间。这意味着你可能希望“预热”代理沙箱，而不是按需启动它们。如果编排是通过自动化触发的，你可以放宽延迟要求，甚至可能为了省钱而这么做。再说一次，这取决于具体的工作——你会希望它是可配置的。
你会希望你的编排器能够使用不同的模型和（可能）不同的框架。有些任务可以用开放权重模型完成。有些可能应该使用Codex、Claude Code、Pi，或者内部的编码代理框架。这些框架都有不同的接口，要把它们整合成一个统一的体验需要大量工作。

实现技术栈——自我改进与基准测试

直接执行工作项只是系统的一部分——它是让你的团队做产品工程的部分。你还需要设置工厂来支持度量和改进，这样你的团队就能做我所说的“工厂工程”：以最低成本实现最大吞吐量和质量来优化你的代理设置。
与任何其他工程学科一样，要做好工厂工程，你需要合适的基础和工具。
基础是工厂即代码以及所有工厂代理对话的持久化。工厂即代码允许测试不同的工厂配置，并实现代理的自我改进。记录代理对话让你能够从不同维度打分评估工厂的表现。注意，仅仅记录代理追踪是不够的——你还需要记录代理产生的所有工件（例如PR、视频、截图）。
一旦有了基础，你需要工具：
在线评估和打分器：使用LLM作为裁判，根据你可能想要改进的维度对过去的代理运行进行打分（例如“代理是否在编写冗余测试？它生成的设计是否与我们的风格指南一致？”）
自我改进循环：代理检查过去的评估结果，寻找改进工厂代码定义的机会。
基准测试：使用不同的工厂配置（例如不同的模型或技能定义）重新运行一组代理任务，以确定哪种配置最优。
模型路由：将评估和基准测试的结果应用到针对你团队自己的工作流优化的模型路由策略中。
A/B测试：通过运行受控的拆分测试，证明工厂代码在未来的运行中也是最优的。
构建所有这些度量和改进基础设施是构建工厂时最容易被忽视的部分。例如，对于之前任务的基准测试，你需要尽可能封闭的任务重放，并考虑之前运行可能产生的副作用；也就是说，当任务跟踪器已经将任务标记为完成时，你不能天真地重放修复该任务。相反，你需要将任务跟踪器的原始状态记录在某个地方，并将其一并重放。

实现技术栈——集成与访问

在构建工厂时，你必须考虑工作如何进出。在Warp Factories，我们做了一个有意识的选择：工作应该主要通过现有的开发者和知识工作工具流入，如Slack、Teams、Jira、Linear、Github、Gitlab等，而不是强迫工作通过一个专门的工厂产品界面。
我们看到很多客户从一个“工厂Web应用”开始，带有一个大大的提示输入框来提交工厂工作，这通常不会被广泛采用，因为它要求每个人都离开现有的工具，转移到一个新的应用。我们认为，更好的做法是把工厂带到工作已经发生、上下文已经存在的地方。
为此，我们把工厂视为无头基础设施——它是你团队运行的所有编码代理背后的引擎，而不是一个可以聊天的AI队友群，也不是一个需要采用新界面的产品。这意味着工厂首先是API和MCP优先的，不仅供人类使用，也供代理使用。工作可以从任何表面进出，接受来自任何地方的上下文，写回任何地方，而无论发生在哪里，工厂都应该能够接管并完成该任务，附带所有正确的工作流、跟踪等。
但这种灵活性也带来更多工作。与构建一个单一的新目的地应用相比，在大量异构集成上支持高质量体验要困难得多。虽然设置一个单一的Slack机器人相当简单，但我们发现，要让所有这些集成都正确，实际上涉及更多工作：例如，弄清楚如何在正确的工具中将工作路由给正确的人，管理不同工具集之间的权限（例如，仅仅因为某人能访问Slack，并不意味着他应该能使用为SRE团队设置的工厂），让每个集成都显得是工具的原生体验（例如，你表达代理“正在思考”的方式在Slack和Jira中是非常不同的）。

结语

这篇文章的目的是展示构建生产级软件工厂时一些有趣的技术考量。正如开头提到的，我认为要得到一个真正的工厂，你需要远远超越串起提示词和云代理。那些这样起步的公司，最终通常会退回来重新开始，转而采用一种看起来更像是实现（或使用）工厂技术栈的方法。
如果你对用这种方法构建自己的工厂感兴趣，我们很乐意聊聊。