Warp 的软件工厂
又是我。大家对我们节目开场的反馈不错，所以只要时间允许，我还会继续做。今天聊聊 Warp 和 Zach Lloyd。Zach 在 Warp 做了很久，公司一路转型到今天，基本上成了软件工厂领域很有代表性的开源方案。他在 AIE 的演讲很受欢迎，已经成了最火的演讲之一；我觉得大家都在想办法给自己搭一套。Warp 有现成方案，但它也像一套开放规范，逐渐成了大家都需要的基础配置：云端环境、控制平面，以及安全和团队协作功能。这些最后都会变成理所当然的东西。
AIE CODE 将在旧金山举行
这期节目是 AIE CODE 的预热视频。AIE CODE 是今年最后一场旗舰活动，将在旧金山举行，汇聚顶尖的智能体工程师，讨论软件工厂等话题。System One Models 将再度登台，继续提升大家的目标。Artcraft 的 Tariq、Jason 和 Brandon 也会参加，Brandon 将首次在大会上演讲。Zach 还会带来一场关于软件工厂的精彩主题演讲，回顾这一年并展望下一步。欢迎来参加，一定很有意思，再见。
Zach Lloyd 与软件工厂
我们在远程演播室和 Zach Lloyd 聊聊。欢迎你，很高兴请到你。
很高兴来到这里，谢谢邀请。
Zach，你在 AIE 上的演讲火了。怎么回事？你说中了大家的痛点。大家真的很关心软件工厂，这也是我和 Warp 一直在关注的方向。我们对软件工厂究竟是什么、它对软件开发者意味着什么，有一些挺有意思的看法。你的主页主标题写着“面向云端软件工厂的开放基础设施”。你花了很多时间向大家介绍软件工厂：大家通常以为它是什么，实际又需要什么？
我跟公司和开发者交流时发现，很多人都在尝试搭建某种内部软件工厂，或者一组软件工厂。对我来说，软件工厂就是一个运行在云端的智能体系统：你要定义各个智能体在为团队或产品开发软件时分别承担什么角色，系统也要有一定自主性，让智能体可以自己完成一些工作。这个系统应该高度可衡量、形成闭环。团队能随着时间推移不断调优、测量、做基准测试，最终确信大家转向 AI 软件开发之后，采用的是最可扩展、最高效的方式。
大家找你时，有没有什么常见误解？比如觉得“只要买了某个东西，最后就会得到一台神奇的赚钱机器”？
有些人想自己搭软件工厂，就把各种自动化拼起来；还有人把软件工厂理解成一个很宽泛的概念：只要大量用智能体来交付软件，就叫内部软件工厂。我们想把概念说得更具体：软件工厂应该是一件明确的东西，要用代码定义，里面的工作流、技能、MCP 等都要明确，能够在某个时点实际运行并测量效果。大家对工厂有各种零散想法；对 Warp Factories 这个平台来说，我们强调它是个真正的系统，可以编排、测量，而且每个产品界面都应该有一套工厂。我们希望把它从一堆模糊、随意的自动化和交互式智能体，变成一个可以明确理解的软件工厂。
用代码定义工厂
……软件工厂应该怎么理解，或者说我们是怎么理解它的。你看到的是 Warp 软件工厂平台。一个工厂服务于某个产品界面，比如手机应用、服务器应用；它会操作一组代码仓库，配置所需技能、MCP，再配上一套工作流。工作流大致对应团队现在修改代码库的流程，比如问题分诊、规格定义、实现。关键是工作流要明确，而且本身用代码定义。我们用 YAML 文件列出可用仓库、MCP 和各种集成，把整套系统写清楚。
使用工厂大致涉及两类角色。一类是做产品的人，也就是产品工程师，他们通过工厂交付功能；他们仍然使用现有工具，比如在 Slack 里给工厂派活、用 Linear 或 Jira 任务跟踪，也可以通过 GitHub、API 或 MCP 交互。你把一个工作项送进工厂，就会启动一套预先定义、由代码描述的工作流。这样说清楚吗？
我喜欢用代码来定义东西。
对。设置好之后，无论有人在 Slack、Linear 里发起任务，还是自动化系统发现服务器错误，工作都会进入同一个系统，这是关键。一旦跑通，就会有一系列好处。其中之一是能实时看到 Warp 团队里各个智能体在什么地方运行，也能查看所有使用工厂的产品上，大家具体怎样使用编程智能体。你当然可以看看某个人在做什么，但更重要的是，所有智能体对话和产物都会集中起来，覆盖团队用编程智能体完成的工作。我们说要形成闭环，这些对话和运行轨迹正是系统改进的关键。比如可以打开一条运行轨迹看看……
跟着 Slack 请求一路看到 PR
……这条运行轨迹里，Sopic 正在做我们的移动应用。他是在 Slack 里发起的任务，我也可以直接去 Slack 看。但这里能看到完整记录：对话内容，以及构建过程中计算机操作留下的截图。你可以完整回看编排智能体具体做了哪些事，而且不是只有这一个任务，每项工作都有记录。现在我跟公司交流时发现，大多数公司还没有这样的集中视图，因为工程师通常是在自己的电脑上单独使用 Claude Code、Codex 应用之类的工具。但他们希望把这些工作集中起来。集中之后，就能拿到有意思的数据，了解公司整体的智能体编程效果，并从不同维度分析。我们可以先看……
衡量成本、吞吐量和质量
……在编程智能体的工作方式下，团队的产出如何？可以看传统的 DORA 指标，比如交付一项改动要多久；还可以衡量自动化程度，例如每个合并的 PR 有多少次需要人工介入，以及吞吐量和成本。我们一直在用这些指标。成本对公司特别重要：要用合适的模型和技能调优工厂，逐渐降低每个 PR 的成本；还要按人员、自动化类型、软件开发生命周期的不同阶段拆解成本。
另一个很棒的地方，是闭环系统让你能深入观察编程智能体在不同维度上的表现。我们把这称为在线评测，也叫 scorers。评测可以很通用，比如智能体是不是太啰嗦、是否高效、代码质量好不好——这方面我们也还有很多工作要做。
这些评测是用户自己定义，还是平台直接提供？
两种都有。我们会内置一组普遍有用的评测；但不同公司会有各自关心的智能体失效模式。比如某类改动会不会把构建弄坏，或者是否符合他们特定的工作流。这些都可以用代码定义，也都能定制。背后是把过去保存下来的智能体运行记录交给另一个智能体回头打分。
这里举个检查冗余测试的例子。这是编程智能体常见的问题：它们在摸索实现方法时可能写出一堆其实不需要的测试，最后又留在代码里，导致代码库臃肿，还浪费 token。你可以为这种问题创建评测。评测可以理解为“让 LLM 来当裁判”：选择裁判模型，设置评测在哪些运行上执行、判断提示词是什么，以及抽样率。因为这些裁判智能体也要运行，得留意成本。
配置好之后，可以把它想象成一群聪明的智能体，持续查看团队的编程会话，指出有些智能体写了太多测试。这样你就能知道应该从哪些地方入手，改善团队使用编程智能体的方式。到目前为止不错。我还想再展示几件事，让大家更具体地看到能做什么。整体上我有点想确认：你展示的是不是 Warp 的管理层视角？你在运营公司，手下有一群工程师。这些工具的使用者既可能是工程经理或 CTO，也很常见是平台团队；通常不是日常写代码的工程师。很多公司会有内部 DevEx 或平台团队，专门想办法优化编程智能体。所以我展示的就是他们用来研究怎样在公司里充分发挥 Claude Code、Codex 等工具的那套工具。
衡量成本、吞吐量和质量（续）
明白了。
还有几点我想强调一下，不是要把话题只限定在 Warp Factories。任何想搭内部工厂的人，不管用不用 Warp Factories，都应该让所有东西集中保存、可观察、可衡量。做到这些，才能真正用工程化的严谨方法改进编程智能体。你肯定经常在 Twitter 上看到大家推荐新模型、新 harness，然后争论 Pi、Claude Code、Cursor 哪个更好。我们认为，整个行业需要从凭感觉讨论编程智能体，走向实际测量。公司会想要一套类似 Warp Factories 的系统，不管是直接用我们的产品还是自己搭建，都能收集这些信息、查看智能体表现。
系统还有一部分我觉得大家容易忽略：你可以围绕它配置各种自动化。大家除了在 Slack 里派任务，也会用不同的触发器把工作送进工厂。一旦有了前面展示的工厂评分视图，还可以……
让智能体改进工厂
……再搭一层智能体循环。现在什么东西都讲闭环：让这些智能体检查评分里的失败，发现表现不好的地方，再建议怎样改进系统。一个很简单的例子是我们所说的自我改进：负责自我改进的智能体检查分诊步骤，发现有 54 个同类失败案例；如果分诊智能体能再派生一个子智能体去调查，结果会更好。你可以查看它为什么得出这个判断。酷的地方在于，整个工厂是用代码定义的，而这些又是编程智能体，所以它们可以直接针对工厂定义提交 PR，尝试改进工厂本身。这就把完整的学习循环嵌进了系统，让系统尝试自我优化。
我们还没做出下一步，但希望对这类建议的改动，可以回放以前的运行记录，确认它确实能改善结果。只要基础构件搭对了，这套系统能带来的工程化可能性就很有意思。我再展示最后一件事，然后我们可以进一步聊整个方法。我们觉得公司还应该追求的一项能力是……
用自己的任务做基准测试
……我们发现，公司内部很有用的一项能力是做基准测试。在工厂这个语境里，就是把系统里运行过的任何编程智能体任务加入基准测试套件。你可以挑选一组相关任务，比如前端开发，再用不同配置矩阵重放同一批任务。我认为不能只换模型，也应该能换 harness。Warp 不仅能用自己的 harness，也能跟 Claude Code、Codex 或 Pi 做对照，还可以挑选模型。
结果会很像公开的 SWE 或 Terminal Bench 测试结果，只不过基于的是你们公司真实跑过的任务。比如这里比较某一组任务的成本和正确率，你想找的是左上角：成本最低、正确率最高。模型变化太快，图里的型号现在已经有些旧了，但你可以看到 GPT-5.6 Soul 在这组任务上的正确率是 95%，平均每次花 6 美元；GLM-5.3 Flash 的正确率是 93%，花 2 美元。然后你可以把这些结果写进模型路由或 harness 路由策略里，并针对自己的工作流和代码库用代码定义。
拉远来看，最有力量的地方是：我们不再靠猜，而是进入了所谓的“工厂工程”。团队和公司用真正的工程思维，思考怎么部署这个强大的新构件——编程智能体，怎样确认用得对。我们正在为公司搭建这类基础设施和工具，这套思路也引起了很多正在搭建自有方案的公司的共鸣。这就是我说的软件工厂的大致含义。我先停一下。某种意义上，最厉害的打法就是把思想领导力做得足够好，让大家就算不用 Warp，也都想自己搭一套 Warp。
对。你在产品页面和演讲里反复讲“任何界面都可以”，工厂要用代码定义，还要有评测循环。现在有人把它叫 ADLC，你似乎还是用 SDLC。无论叫法如何，如果要做这个领域，我会把它看成一套分层架构。最底层是基础设施。
基础设施是整个技术栈最底层，非常基础、非常重要的一点是用声明式代码定义工厂。可以把它类比成 Terraform，得到同样的好处，甚至更多。……
用自己的任务做基准测试（续）
……定义成代码后，可以版本化，按不同分支做测试，改坏了也能回滚——这些都是源代码管理的明显好处。还有一个特别酷的额外好处：既然它是代码，编程智能体就可以建议改进。所以在我看来，声明式地定义工厂，是搭建自我改进软件工厂的基础。
再往上一层，是一个汇集智能体产出的所有信息的地方。你要检查这些信息、寻找失效模式，或者拿过去的任务重放，只改变不同变量，从测量角度科学地优化系统。为此你需要数据：智能体对话、智能体产物，以及从各种工具到最终结果的完整交互记录。一次工厂任务可能从 Slack 开始，接着进 Linear、GitHub，出现代码审查意见，最后合并代码，甚至发布上线后服务器崩溃。之后你要能让智能体（也可以由人）回头诊断：哪里出了问题，本来怎样做会更好。
还需要把数据接入系统的方式，比如接入 MCP。公司越大，不同部门的访问权限越复杂：市场、销售、工程团队可以访问哪些 MCP，可能都不一样。再往下还要有计算层，最好当成独立部件。现在有很多智能体沙箱服务商；如果用第三方，架构上就要能插拔。我们主要用 Namespace，他们在 AI Europe 发布了产品，确实很棒，但这部分应该可替换。你也可以用 Daytona、Modal、E2B 等。通常 Linux 沙箱就够了，但如果要用计算机操作来测试 iOS 应用，就得能启动 Mac 虚拟机、运行模拟器并实际点击。
推理方面，我们的态度也很开放，这符合我们追求灵活的理念。很多公司已经和 Anthropic、OpenAI、Google 有预付额度想要消耗，所以我们既支持接入自己的推理服务商，也可以通过我们购买推理服务；甚至可以接入自己的 harness，这一点很重要。比如编排 Pi，或者任何兼容 ACP 的 harness。然后还要有改进层，我刚才演示的就是其中一部分。整个系统真正的价值在于……
每个 PR 的成本从 80 美元降到 15–20 美元
……它能不断改进自己。举个数字：Warp 刚开始用工厂模式时，每个 PR 大约要花 80 美元，因为我们在不该用 Opus 的地方用了它，分诊智能体用了能力过强的模型，而且智能体结构也做了不少冗余工作——子智能体开得太多，不如减少智能体数量。我们用这些内置功能做了一系列内部调优和测试，把每个 PR 的成本降到了约 20 美元，甚至 15 美元。PR 吞吐量也能测出有提升：过去一个月上涨了 40%。我们还测了回滚率，它没有上升。因此我对“观察、测量、调优”这套方法很有信心。
最后还需要某种编排器。有人把编排器说成整个产品平台，我认为它只是其中一部分。它要读取工厂定义代码，让工作在各个阶段之间流转，调用合适的模型、加载合适的技能，并触发适当的自动化。
最后要有很多接入点。我们的理念是把工厂接入公司现有的知识工作工具。最典型的是 Slack，我们大约 60% 的工作从 Slack 开始；有时也应该从任务管理器开始。有些开发者更习惯在终端里使用 Claude Code，可以先在那里做很多工作，再把规格提交给工厂。我们的理念是让整套系统以 API 和 MCP 驱动，工厂本身像一块无头基础设施，提供不同入口。
把它看成一套分层架构，跟公司交流时大家很容易理解：这是开发者基础设施栈里的新一层，位置大概比 CI/CD 再往前一级。我认为大多数公司最终都会有这样的软件开发系统。
这其实有很多层。我以前没见过有人像你这样把它完整画出来。Cognition、Cursor 等产品都想从底层到顶层打包一部分能力，软件里一直有这种打包趋势。关键问题是：我作为一家 B2B SaaS 公司的 CTO，到底需要这六层吗？这东西是给谁用的？
谁需要软件工厂？
最适合这套方案的公司，得有一定规模。只有几个人的话，这完全是过度设计。
别这么做，直接用 Claude Code、Codex 的订阅版之类，速度会更快。你可能不需要……
当然，大一点的团队也能用这些工具。任何大型团队的技术栈都是这样：有时候你从“先冲再说”变成需要一个平台系统来加速。我们觉得大约 5 到 10 名工程师可能是开始值得考虑的门槛，一直到非常大的公司都会需要类似东西。公司越大，落地就越需要定制实施。把系统搭到公司自己的基础设施里，不会完全即插即用，因为团队内部开发环境会随规模增长而变复杂。
不过也有很多 10 到 100 名工程师的高速增长型公司，使用 Slack、Linear、Jira 这套常见工具时，确实可以比较自助地接入，很快获得价值。
等等，你刚才把这叫“快乐工具栈”了吗？
我不是在评价谁好谁坏，只是说创业公司里常见的一组集成。把这样的系统接进去，不需要太多配置就能立刻见效。我不知道你用 Devon 这类工具有多深，但在 Slack、Linear 这种原生支持多人协作的环境里，会有很多你可能没想到的好处：有一个统一的系统记录信息。比如服务器崩溃频道、用户反馈频道里的信息可以直接送进工厂处理；工厂也可以根据谁最熟悉相应代码，把团队里的几个人拉进来。所以公司不一定要很大才适合，但很小的团队确实没必要。最适合的是希望提前搭好合适基础设施、让它能跟上模型和智能体持续变化的公司。
还有很多可聊的。我再问最后一个问题，然后请你介绍 AIE 演讲，以及大家在哪里能关注你。面对“搭这一整套东西”的批评或反对意见，最有力的批评是什么？大家实际会遇到什么问题？
我会分情况回答。有一种典型客户，我不认为适合用我们这个产品……
先不说公司规模的因素。
现在不太合适的是基础设施非常特殊的公司，比如 Uber 或 Ramp。它们规模很大，也有自己的内部开发团队，正在自己搭系统。抛开规模，我确实认为有些小团队直接用订阅版更划算。
谁需要软件工厂？（续）
对。
这是规模问题。
我不想漏掉订阅服务这一点。很多人直接走 API 按量付费，但订阅可能便宜 5 到 50 倍。大家真会这么做吗？这是不是违反服务条款，所以不该碰？
我们跟不少小公司聊过，他们会说：“这个系统看起来太棒了，我们想用，但我们现在轮流用一堆每月 200 美元的订阅。”他们可能同时轮换 17 个不同订阅。你会觉得这应该不被允许，但说实话，我也不太清楚实际规则。他们确实在这么做。如果可以这样用，成本当然最低，但会失去很多其他好处，而且不可扩展。公司发展到一定规模，肯定也不能继续这么干。不过小团队这么做是讲得通的。
我只是说补贴力度有多大：比如 200 美元的套餐，可能拿到价值 8,000 美元的 API 用量。
对，太夸张了。
这可不是小钱。
是啊。从商业角度看，这也是我不想只做纯编程智能体业务的原因之一——跟这种价格竞争几乎没法打。你没法基于一个贵得多的东西，做出有竞争力的编程智能体。Cursor 当年做得很聪明，后来我觉得它成功退出、变成模型实验室，是因为充分看清了其中的经济账。
Warp Factories 的好处是，我们不是要卖一个转售 token 的产品，而是做编程智能体优化平台、提升编程智能体生产力的平台。这个产品不处在那场竞争里，这反而是优势。现在独立编程智能体大概还剩 Cognition、OpenCode，当然还有 Factory。我也不知道它们会怎么走。
产品工程师与工厂工程师
最后请你简单宣传一下演讲。大家会来现场看，我们也会直播。概括一下你一直在发展的这组演讲主题，以及下一场准备讲什么？
我想讲的是，在工厂工程日益普及的世界里，工程师的工作会是什么样：你的角色和工作会怎样变化？工程师分成哪两类——产品工程师和工厂工程师？如果把工厂工程看作一门新学科，它实际是什么样？有哪些工具？作为工程师，怎样培养合适的技能，去构建生产软件的系统，而不是只直接写软件？
总结得太好了。大家想联系你、了解你们的招聘信息，应该去哪里？
去 warp.dev 看看，主要信息都在那里。我们在招工程师、市场拓展团队成员、数据团队成员，还有设计师，很多岗位都在招。如果你对我关于工厂的想法感兴趣，我最近在 Twitter 上发了不少内容，搜 Zach Lloyd 的推文就能找到，欢迎关注，我会继续分享自己的思考。
好的。非常感谢你抽时间来聊。
谢谢邀请。