2026 软件工厂基础设施栈 — Zach Lloyd，Warp.dev

嘿，又是我。我听到很多关于我们节目开场白的正面反馈，所以只要时间允许，我就会继续做下去。今天我们要和 Zach Lloyd 一起深入聊聊 Warp。Zach 在 Warp 上已经做了很久，它转型成了今天的样子，基本上就是那个标杆级的软件工厂，而且也是开源的。他有一套完整的定义，我觉得效果非常好。他在 AIE 上的演讲一直在疯传，是有史以来最热门的演讲之一，我觉得实际上每个人都在试图为自己搭建这套东西。他们为你提供了解决方案。但它同时也是一种开放规范，正在成为你必备的基本门槛。我觉得你会需要云端，会需要一个控制平面。你还会需要一些你习以为常的基础安全和团队功能。

Hey, it's me again. I have heard a lot of positive feedback about our episode intros, so I'm going to keep trying to do them as far as time allows. Today, we're going to dive into Warp with Zach Lloyd. Zach has been working on Warp for a while, and it's pivoted into what it is today, which is basically the definitive software factory that is also open source. And he has this whole definition, I think, which has done really well. His talk at AIE has been going viral as one of the top talks of all time, and I think effectively everyone is trying to set this up for themselves. They have a solution for you. But it's also kind of an open spec that is becoming table stakes for what you're going to want. And I think you're going to want cloud, you're going to want a control plane. You're going to want some other sort of basic security features and team features that you take for granted.

所以，我们把这一集作为 AIE Code 的预览发布。AIE Code 是今年最后一场 AIE 旗舰活动。它将在旧金山举行，我们会聚集所有顶尖的智能体工程师，讨论软件工厂以及其他话题。System one 模型正在回归，也在提升你的野心。Tariq、Jason，还有 Artcraft 的 Brandon 将做他有史以来第一次大会演讲。如果你感兴趣，Zach 也会做一场精彩的关于软件工厂的主题演讲，回顾这一年并预览接下来的内容。来加入我们吧，会很好玩的。再见。

So, we're releasing this episode as part of a preview for AIE Code. AIE Code is the last AIE flagship of the year. It's going to be in San Francisco, where we're gathering all the top agentic engineers and talking about software factories among other things. System one models are coming back and raising your ambitions. So, Tariq and Jason and Brandon from Artcraft is doing his first conference talk ever. If you're interested, Zach will also be giving a great keynote on software factories and sort of recapping the year and previewing what's next. Join us and it'll be lots of fun. See you.

我们在远程演播室和 Zach Lloyd 继续聊。欢迎。

We're in the remote studio catching up with Zach Lloyd for more. Welcome.

很高兴来到这里。谢谢邀请。

It's good to be here. Thanks for having me.

Zach，你在 AIE 上火了。怎么回事？你戳中了大家的神经。

Zach, you've been going viral on AIE. What's up? You've hit a nerve.

你戳中了大家的神经。人们对软件工厂真的很感兴趣，而这一直是我在专注的领域，也是 Warp 一直在专注的领域。我觉得我们对软件工厂到底是什么、对做一名软件开发者意味着什么，有一些有力而有趣的看法。所以是的——大家很买账。

You've hit a nerve. People are really interested in software factories, and that is an area that I've been focusing on, that Warp has been focusing on. I think we have some strong, interesting takes on what a software factory actually is and what it means for being a software developer. So yeah, that's — and people have been into it.

你们落地页上的大标题写着“面向云端软件工厂的开放基础设施”。我想，既然你比我花更多时间谈论和向人们介绍工厂，那人们认为软件工厂是什么，他们实际又需要什么？

Your H1 on the landing page says open infrastructure for cloud software factories. I think maybe since you spend more time than I do talking about and telling people about factories, what do people think is a software factory and what do they actually need?

当我和公司或开发者交流时，世界上大多数公司都在尝试搭建某种内部软件工厂或一组软件工厂。我认为它的含义——或者我就直接定义它对我来说意味着什么——就是云端的一个智能体式系统，你在其中定义各个智能体在为你的团队或产品构建软件时扮演什么角色，而且这个系统有一定程度的自主性。也就是说，智能体可以自己做事，而在我看来，这个系统应该是非常可度量、非常闭环的，随着时间推移，你作为一个团队可以调优、度量、做基准测试，最终获得信心：当人们转向这种智能体式开发方式时，他们是以最可扩展、最高效的方式在做。

When I talk to companies or developers, most of the world is trying to build some sort of internal software factory or set of software factories. What I think it means — or maybe I'll just define what it means to me — is like an agentic system in the cloud where you're defining what are the roles of various agents across building software for your team or for your product, and there's a certain amount of autonomy in that system. So the agents can do things on their own, and that system to me should be something that's very measurable, very closed loop, which over time you as a team can tune, measure, benchmark, and just ultimately get confidence that as people switch to this way of doing agentic development, they're doing it in the most scalable and efficient way.

那人们带着什么样的常见误解来找你？比如他们会说：“好吧，只要我做了这个、买了那个，我最后就能得到一台了不起的印钞机。”

And what do people come to you with that perhaps is a common misconception? Like they're like, "Okay, if I do whatever, if I buy whatever, I'm going to come out the other end with this amazing money machine."

是的。所以当人们来找我们、想搭建自己的软件工厂时，他们往往会把不同的自动化串在一起。有时人们把软件工厂想成——不是一个具体的东西，而只是“我们大量使用智能体来交付软件，我们把这叫做我们的内部软件工厂”。而我们试图让它更具体，就会说：不不不，你其实应该把软件工厂想成一个非常具体的东西。你应该用代码定义你的工厂。你应该确保工厂拥有所有工作流、技能、MCP——一切都像一个具体的东西，你应该能在某个时间点运行它并度量它的表现。因为人们对这些工厂有各种各样随意的想法。所以对我们的平台 Warp Factories 来说，我们会说：不不不，它其实是一个真实存在的东西。你可以编排它。你可以度量它。每个产品界面配一个工厂。我们试图把它从那种模糊的、由任意自动化和交互式智能体拼凑而成的集合，变成一个真正的——这才是思考软件工厂的方式，或者说我们思考它的方式。

Yeah. So when people come to us and they're trying to build their own software factory, often they'll be stringing together different automations. Sometimes people are conceiving of software factories as just — not a specific thing, but just like, we're using agents a lot to ship software and we're calling that our internal software factory. And what we try to do to make that more concrete is be like, no no no, you should actually think of a software factory as a very specific thing. You should define your factory in code. You should make sure that the factory has all the workflows, skills, MCPs — everything is like a concrete thing that you should be able to run at some point in time and measure how it's doing. Because people have all sorts of random ideas around what these factories are. And so for Warp Factories, which is our platform, we say, no no no, it's actually a real thing. You can orchestrate it. You can measure it. You have one factory per product surface. And we try to take it out of the realm of just being this nebulous collection of arbitrary automations and interactive agents into a thing that's an actual — the way to think about a software factory, or the way that we think about it.

你现在看到的是 Warp 软件工厂平台。一个工厂作用于某个产品界面。所以想象你在构建你的移动应用，或者你在构建你的服务端应用之类的，而工厂本身作用于一组代码仓库，它有一套它需要的技能、一组 MCP，然后它有一个与之关联的工作流。这个工作流大致对应你的团队为改动那个代码库可能已经在做的事情。所以可能有一个做分诊的步骤。可能是做规格说明和实现的步骤。重要的是存在某种已定义的工作流，而这个工作流本身是用代码定义的。所以对我们来说，我们基本上有一个 YAML 文件，上面写着：好，这些是你可以使用的所有仓库。这些是所有 MCP、所有接好的集成。所以你基本上把这一整套东西定义在某个地方。

What you're looking at here is the Warp software factory platform. A factory operates on some product surface. So imagine you're building your mobile app or you're building your server app or whatever, and the factory itself is operating on a set of repos, and it has a set of skills it needs, a set of MCPs, and then it has a workflow associated with it. And this workflow roughly matches what your team is probably already doing to make changes to that codebase. So there could be a step where you're doing triage. It could be where you're doing spec and implementation. The important thing is there's some kind of defined workflow, and that workflow itself is defined in code. So for us, we basically have a YAML file which says, okay, these are all the repos that you can be using. These are all the MCPs, all of the integrations that are hooked up. So you basically have this whole thing defined someplace.

理解如何使用这个工厂的方式是，其实有两类人。一类是构建产品的人。他们在做产品工程。他们通过工厂交付功能。对这些人来说，他们使用工厂的方式是通过他们现有的工具。所以他们可以在 Slack 里给工厂发消息，把工作放进去。他们可以使用像 Linear 或 Jira 这样的任务跟踪工具。他们可以通过 GitHub 与工厂交互。他们可以通过 API 或 MCP 调用它。这个比喻就像你把一个工作项放进工厂。当它进入工厂时，就启动了一个预定义的工作流。而这个工作流是用代码定义的。到这里说得通吗？

The way to think about using the factory is that there are actually two personas. So there's someone who is building the product. They're doing product engineering. They're shipping features through a factory. And for those people, the way they use the factory is through their existing tools. So they could be slacking the factory to put work into it. They could be using a task tracker like Linear or Jira. They could be interacting with the factory through GitHub. They could be calling it via API or MCP. And the metaphor is like you're putting a work item into the factory. And when it goes into the factory, that starts a predefined workflow. And that workflow is defined in code. Does that make sense so far?

我很喜欢用代码定义东西。

I love defining things in code.

是的。好。所以你在代码里把这一整套东西搭好，然后一旦你把它就位——再打个比方，就像有人在 Slack 或 Linear 里发起一个任务，或者通过一个自动化，比如你知道，出现了一个服务器错误。关键是它全都经过同一个系统。一旦这套东西运转起来，你基本上就能获得由此带来的一大堆好处。

Yes. So, okay. So you have this whole thing set up in code, and then once you have that in place — and again the metaphor is like someone starts a task in Slack or in Linear or through an automation like, you know, there's a server error. It all goes through one system, is the key thing. And once you have that working, you basically get a whole bunch of benefits that flow out of it.

所以一大好处是，无论这些智能体在哪里运行，你都能实时看到 Warp 内部团队的情况——我们是怎么用自家工厂的。你能拿到所有人用编码智能体做事的完整追踪记录，覆盖任何有对应工厂的产品。这很酷的地方不只是“哦，我想看看大家在干什么”，比如我想看看 Sopic 在干什么——这确实很酷——而是它开始把整个团队里编码智能体产生的所有对话和产物都集中起来。所以当我说要有一个闭环系统时，这些智能体对话、这些智能体追踪记录，正是这个系统得以改进的关键。

And so one of the big benefits is that wherever these agents are running, you're sort of seeing a real-time view across Warp's internal team — how are we using our own factories. You get a full trace of what everyone is doing with coding agents across any product that has a factory for it. And this is cool not just for, oh, I want to see what people are doing, like I want to see what Sopic is doing — which is cool — but it also starts centralizing all of the agent conversations and agent artifacts in all of the work that is being done by coding agents across your team. And so when I talk about having a closed-loop system, these agent conversations, these agent traces are the key aspect of how this system improves.

举个例子，就看其中一条智能体追踪记录，Sopic 正在做我们的移动应用。Sopic 是在 Slack 里做这件事的。我如果想的话，可以在 Slack 里把它调出来。但这个东西实际在生成——它有完整的对话记录，有所有这些的完整记录——这些是构建这个东西过程中产生的计算机操作截图。你能看到编排智能体各个部分到底在做什么的完整记录。所以你有了这个，而且不只是对一件事有，是对每一件事都有。

And so for instance, just to look at one of these agent traces, Sopic is working on our mobile app here. Sopic was doing this in Slack. So I could pull this up in Slack if I wanted to. But the thing is actually generating it — it has a full record of the conversation, a full record of all of these — these are computer-use screenshots that are coming out of building this thing. You can see a full record of exactly what the different pieces of the orchestration agent were doing. And so you have this, but you have it not just for one thing — you have it for every single thing.

所以今天在你们团队里——我跟公司聊的时候，大多数公司没有这样的东西，因为他们大多数工程师都是各自在终端里用 Claude Code，或者 Codex、Codex 应用之类的，在各自的本地环境里用。但他们想走到一个有这种集中化的世界。当你有了集中化，你基本上就能拿到所有这些有意思的数据，了解你公司里智能体式编码的运作情况。

So on your team today — when I talk to companies, for the most part they don't have something like this, because most of their engineers are individually using Claude Code in their terminal, or Codex, the Codex app, or something like that in their own local setups. But they want to get to a world where they have this centralization. When you have the centralization, you can basically get all this interesting data on how your agentic coding is working across your company.

你可以从不同维度来看这些数据。你可以把它看成：好，我们团队在使用编码智能体方面的产出是什么。所以就是像传统的 DORA 指标——交付一个东西要多久。还有你自动化程度有多高。我们有一个指标是，每一个被合并的 PR，人类得对它动手多少次。你的吞吐量是多少。还有围绕成本的指标。我们一直在用这些。

And you could think of this data along different dimensions. So you could think of this data as, okay, what's our team's output in the world of using coding agents. And so that's things like traditional DORA metrics — how long does it take to ship something. It's things like how automated are you. And so we have a sort of metric around, for every PR that gets merged, how many times did a human have to do something with it. What's your throughput. It's metrics around cost. And so we're using this constantly.

我们跟公司聊的时候，成本这件事非常非常重要，你希望能用合适的模型、合适的技能来调校你的工厂，基本上让每个 PR 的成本随时间降下来。你希望能按人切分成本。你希望能按自动化切分，按你在 SDLC 的哪个环节花钱来切分。

And when we talk to companies, this cost thing is very, very important, where you want to be able to tune your factory with the right models, the right skills, to basically bring this cost per PR down over time. You want to be able to slice the cost by person. You want to be able to slice it by automation, by where in the SDLC are you spending money.

最后一件很酷的事是，一旦你有了这种闭环系统，你其实可以掀开引擎盖，看你的编码智能体在不同维度上表现如何。你可以把这看成在线评估，我们叫它评分器。这些可以从很通用的事情开始——比如你的智能体是不是太啰嗦了？它们高效吗？代码质量好吗？这方面我们还有活要干。

The final thing that's really cool once you have this sort of closed-loop system going is that you can actually look underneath the hood at how well your coding agents are doing along different dimensions. And so you can think of this as online evals, or we call it scorers. And these can go from very general things — like are your agents being too verbose? Are they being efficient? Is the code quality good? We got work to do on this.

这个是我作为用户来定义，还是你们作为平台提供？

Do I as a user define this, or do you provide this as a platform?

对，两者都有。我们开箱提供一组我们认为普遍有用的。但当我们和公司合作时，他们的智能体可能有他们想追踪的特定失败模式。他们可能会说，嘿，智能体是不是在做某类特定的改动，把我们的构建搞坏了？他们可能想要非常贴合自己工作流的东西。所以再说一次，这些都是用代码定义的，全部可定制。

Yeah, so both. So we provide out of the box a set of ones that we think are generically useful. But then, as we work with companies, they may have specific failure modes for their agents that they're interested in tracking. They may be like, hey, is the agent making a specific type of change that is breaking our build? They may want something very specific to their workflow. So again, this is all defined in code and all customizable.

你要做的是，当你设置其中一个时，背后实际发生的是，有一批运行记录——我说运行记录，指的是已经存下来的历史智能体对话——然后由一个智能体去回溯性地给它们打分。这是一个很好的例子，它在给冗余测试打分，这是用编码智能体时很常见的失败模式。有时候它们会写一堆你不需要的测试。它们在琢磨怎么实现某个东西的过程中写了这些测试，然后就留在代码里了。这会膨胀你的代码库，浪费 token。

And what you do is, when you set up one of these, what's actually happening behind the scenes is that there's some set of runs that you — when I say runs, I mean historical agent conversations that have been stored — that an agent then goes and retroactively grades. And so this is a good example of one where it's grading for redundant tests, which is a common failure mode if you're using coding agents. Sometimes they write a bunch of tests that you don't need. They write it in the course of figuring out how to implement something, and then they leave it in the code. And so this bloats your codebase, it wastes tokens.

所以假设你想检查这个，你基本上就创建这样一个评估。再给你多展示一点评估长什么样——这个评估，还是把它想成 LLM 当裁判。你选一个裁判模型。然后你看到，好，这些在哪里运行？用来评判的提示词是什么？然后是一个采样率，因为你可能不——这些是正在运行的智能体，你得注意它们的成本。但当你设置好之后，就把它想成你有这么多聪明的智能体，在扫视你整个团队所有编码会话的进行情况，它们在说，好，有时候有些智能体会写太多测试，对吧？于是你就拿到这份记录，也明白了该去哪里改进团队使用编码智能体的方式。

And so say you wanted to check for that, you basically create one of these evals. And just to show you a little more about what the eval looks like — the eval is, again, think of it as LLM as a judge. So you're picking a judge model. You're then seeing, okay, where do these run? What's the prompt for judging it? And then a sampling rate, because you might not — these are agents that are running, you've got to be aware of the cost of them. But when you have this set up, think of it then as you have all these smart agents that are looking across your team at how all your coding sessions are going, and they're saying, okay, sometimes there are agents that are writing too many tests, right? And so you get this record and this understanding of where you should look to improve the way that your team is using coding agents.

目前还不错，因为我想再展示几样东西，把你能用它做什么讲得更具体些。

So far so good, because I want to show a couple other things just to make it more specific what you can do with this.

整体不错。我有点好奇，是不是基本上 Warp 有不同层级的观测手段，其中——你给我们展示的是 CTO 层级，对吧？你在管公司，你有一堆程序员。

Overall good. I'm a little bit wondering if basically there's different levels of instrumentation of Warp, where there's — this is the CTO level, what you're showing us, right? You're running the company, you've got a bunch of coders.

用这个的人——部分是工程经理或 CTO，但也很常见的是平台团队。但通常不是你日常的一线工程师。我们和公司合作时，他们往往有一个内部团队一直在尝试——就是 DevX 团队或平台团队——他们在琢磨怎么优化编码智能体。所以我给你看的这里，就是他们在用的工具集，用来想：我们怎么在公司里把 Claude Code 或 Codex 之类的用到极致。

This is like the people who use this — it's partly the engineering manager or the CTO, but it's also very commonly the platform team. But it's not your day-to-day engineer typically. When we work with companies, they'll often have an internal team that's been trying to — it's like the DevX team or the platform team — and they're trying to figure out how to optimize coding agents. So what I'm showing you here is the tool set that they are using to be like, how do we get the most out of Claude Code at our company, or Codex, or something like that.

这部分清楚了。

That part is clear.

对，好。我想再强调几件事——不是要把这完全变成讲 Warp 工厂，而是这里的一般性原则，对任何想搭建自己内部工厂的人都适用，不管是不是用 Warp 工厂：你要走到一个所有东西都被存下来、一切可观测、一切可衡量的状态，因为那才是你真正能开始用工程严谨性来让编码智能体变得更好的时候。你可能在 Twitter 上老看到这个。大家总是在发推说，你该试试这个新模型，你该用这个新框架。

Yeah. Cool. And so a couple other things that I would just want to emphasize — not to make this just completely about Warp factories, but the general principle here for anyone who's trying to build their internal factory, whether it's on Warp factories or not, is you want to get to a spot where everything is sort of stored, everything is observable, everything is measurable, because that's when you can actually start to apply engineering rigor to how you make coding agents better. You probably see this on Twitter all the time. Everyone is always tweeting about, you should check out this new model, you should use this new harness.

哪个更好？是 Pi 还是 Claude Code，还是 Cursor 之类的？所以我们的观点是，这个世界真正需要的，是走出靠“感觉”来理解这些编程智能体的阶段，真正进入可度量的世界。我们认为这就是公司接下来会想走的方向。他们会想部署一套类似 Warp Factories 的系统——不管他们是真的用 Warp Factories，还是自己造一套——来收集所有这些信息，并提供各种方式来查看你的编程智能体表现如何。

What's better? Is it Pi or Claude Code or Cursor or whatever? And so what our opinion on this is, and what the world sort of needs, is to get out of the realm of vibes for understanding these coding agents and actually into the world of measurement. And so we think that this is the direction that companies are going to want to go. They're going to want to put in place a system that's like Warp Factories — whether they actually use Warp Factories or they build their own — which collects all this information and provides all this way to see how your coding agents are doing.

还有一点我几乎当作理所当然、但它其实是系统的一部分，就是你可以围绕它建立各种不同的自动化。就像我提到的，人们在 Slack 里工作，但人们也在设置各种基于触发的方式，把工作送进工厂。一旦你有了我之前展示的那个视图——给你的工厂打分、看它表现如何——你还可以再搭起另一种智能体循环——如今什么东西都是循环——让这些智能体去审视，去寻找你评分里的失败案例，寻找进展不顺的地方，并尝试对你的系统提出改进建议。

I guess one other thing I kind of take for granted that's part of the system is that you can create all these different automations around it. So like I mentioned, people work in Slack, but people are also setting up different trigger-based ways of putting work into the factory. Once you have this view that I showed earlier of scoring how your factory is doing, you can also set up another kind of loop of agents — and everything is kind of loops these days — where those agents are looking over, they're looking for failures in your scores, they're looking for things that aren't going well, and trying to suggest changes to your system to make it go better.

举个非常简单的例子——我们把这叫做自我改进——我们的自我改进智能体在观察我们的分诊步骤表现如何。我们有一个分诊步骤，它们说：好，我们有 54 个这种特定形式的失败案例，如果我们的分诊器能够派生一个子智能体去做调查，结果会更好。于是它们能做的——你如果愿意，也可以去看看它为什么这么认为——但酷的地方在于，因为你的整个工厂都是用代码定义的，而这些又是编程智能体，它们基本上可以针对工厂定义发起一个 pull request，来尝试改进工厂本身。

And so like a really simple example here — we call this self-improvement — is like, okay, our self-improvement agents were looking at how well our triage step was doing. So we have a triage step, and they're saying, okay, we have 54 failure cases of this particular form where it would have been better if our triager had been able to spawn a subagent to do its investigation. And so what they're able to do — and you could go look at why it thinks this if you want — but the cool thing is, because you have your whole factory defined as code and these are coding agents, they can essentially make a pull request against the factory definition to try to improve the factory itself.

所以这就像是内建在系统里的一个完整学习循环，试图真正实现自我优化。这个我们还没有，但我们接下来想做的是：对于任何这样的建议改动，你都可以回去重放那些运行记录，确认它是否真的能带来改进。所以一旦你有了正确的基础原语，你能怎么工程化这些东西，可能性会变得相当酷。

And so this is like a full learning loop that's built into the system to try to actually self-optimize. And like we don't have this yet, but the next thing that we want to do with this is, for any suggested change like this, you could go back, replay the runs, and make sure that this actually would have improved them. So the possibilities of how you can engineer this stuff get pretty cool once you have the right primitives in place.

我再展示最后一样东西，然后我们也许可以更宏观地聊聊这里的整体思路。我觉得公司应该努力追求的另一点、也是我们在内部觉得非常有用的，就是真正做我们所说的基准测试的能力。在这个语境下、在工厂的语境下，基准测试本质上意味着：你可以把系统里跑过的任何编程智能体——你可以把它加进一个基准测试套件，也就是说，你可能会精心挑选一组与前端编程之类相关的编程智能体运行记录。一旦你有了这些，你就有能力把同样的任务在一组不同配置的矩阵上重放。

And I'll show one last thing and then we could sort of maybe talk more generally about the whole approach here. But the other thing that I think companies should strive for that we find very useful internally is the ability to actually do what we call benchmarking. And so benchmarking in this context, in the factory context, means essentially the ability to take any coding agent that's run in your system — you can sort of add it to a benchmark suite, which means, you know, you might curate a set of coding agent runs that were related to doing front-end coding or something like that. And then once you have that, you have the ability to sort of replay those same tasks against a matrix of different configurations.

所以，我非常相信不仅要让你能更换模型，还要让你能更换运行框架（harness）。在 Warp 里我们有自己的运行框架，但我们实际上会让你针对 Claude Code、Codex 或 Pi 做基准测试。你可以选模型。当你做这样的事时，最终得到的结果看起来非常像 SWE 或 Terminal Bench 公布的结果，但它是基于你自己公司真实运行记录得出的。

And so, you know, I'm a big believer in not just allowing you to vary the model, but also to vary the harness. And so, you know, in Warp we have our own harness, but we actually will let you benchmark against Claude Code or Codex or Pi. You can pick the model. And when you do something like this, what you end up getting is a result that looks very similar to the published results for SWE or Terminal Bench, but on your company's own real runs.

比如，我们在这里看某一组任务上的成本与正确率之间的权衡。你想待在上左角，也就是成本最低、正确率最高。这些模型现在稍微有点旧了，因为世界变化太快。但思路基本上是：我们可以看到，GPT-5.6 Soul 在这个任务集上正确率大约 95%，但平均花费 6 美元。而 GLM-5.3 Flash 是 93%，花费 2 美元。

For instance, we're looking at a sort of cost versus correctness trade-off for a certain set of things here. And like you want to be in the upper-left corner. So you want lowest cost, highest correctness. These models are now slightly older because the world's changing so fast. But the idea is basically, you know, we could see, okay, GPT-5.6 Soul here was like 95% correct on this task set, but it cost six bucks on average. And GLM-5.3 Flash was 93% and cost two bucks.

然后酷的地方在于，你可以把这些信息喂进一个专门为你们自己的工作流和代码库定义的模型路由策略——说实话，也可以是运行框架路由策略。所以，如果我再拉远一点看，我觉得这里最酷、最有力量的大图景是：你正在走出靠猜的阶段，进入我们所说的工厂工程，也就是你拿出真正的工程思维。你会想：我们有了编程智能体这个了不起的新原语，我作为一个团队、一家公司，怎么知道我们真的在正确地部署它们？

And then the cool thing about this is you can take this information and feed it into a model routing strategy — or harness routing strategy, honestly — that's defined specifically for your own workflows and codebase. And so, you know, if I had again to zoom out, the really big-picture thing that I think is so cool and powerful here is like you're getting out of the realm of guessing and you're getting into what we call factory engineering, where it's like you are taking a real engineering mindset. You're like, how do I — we have this amazing new primitive of coding agents — how do I know, as a team, as a company, that we're actually deploying them in the right way?

所以我们正试图为公司构建这套基础设施和工具，让他们能做到这一点。这个方法确实引起了很多一直在尝试自己搭建类似系统的公司的共鸣。所以这就是我所说的“工厂”到底指什么的一个快速导览。我可以先停一下。

And so, you know, we're trying to build this infrastructure and tools for companies to do this. And like this approach is really resonating with a lot of companies that have been trying to build their own versions of this. So that's like a quick tour of what do I mean when I talk about factory. I can sort of stop talking for a sec.

我确实觉得，真正的强势做法，大概就是把思想领导力做到极致，以至于所有人最后都在试图造一个 Warp，哪怕他们并不用 Warp。

I do think that the power move, I guess, is to sort of thought-lead so hard that everyone ends up trying to build Warp even if they don't use Warp.

是啊。

Yeah.

你知道，你的落地页上有一些我很喜欢的东西——你在几次演讲里也讲过——我特别喜欢的一点是“任意界面”，对吧？它真的必须能覆盖任意界面。它必须是“工厂即代码”。你必须有评估的对应物。就像整个——人们把这叫做 ADLC，我不知道你用不用这个词；看起来你还在用 SDLC——你知道，就是那一整套。不管是不是 Warp，我都会这样去思考它。

So you know, you have on your landing page something I like — in your talks you've done a few of these as well — something I really like also is any surface, right? It really has to be any surface. It has to be factories as code. You have to have the eval dupe. Like, what is the whole — people calling this the ADLC, I don't know if you use that term; it looks like you use SDLC still — you know, all that stuff. This is how I would think about it again, whether it's Warp or not.

如果是——我显然会——Warp 是我们全力专注的东西，我们有一个很棒的平台——但总的来说，如果你想在这个领域做点什么，我会把它看成一个技术栈。作为栈底的基础设施，我认为真正基础且重要的是，你要以声明式的方式把工厂定义为代码。

If it's — I would obviously — Warp is what we're fully focused on, we have an awesome platform for it — but just in general, what I would think about if you are trying to build something in this space is, I would view it as a stack. So as infrastructure at the bottom of the stack, I think it's really foundational and important that you define your factory declaratively as code.

所以还是那句话，这里的类比就像 Terraform。你能得到同样的好处，实际上还更多。把它定义为代码的好处是：你能得到一个带版本管理的视图，看到你的——SDLC、AI DLC、PDLC，你想叫什么都行。你得到它的版本化视图，然后你能从它上面拉分支来测试。你改动它之后，也能回滚。所以源码控制那些显而易见的好处你都有。

So again, the analogy is like Terraform here. You get the same benefits but actually more. So the benefits you get from defining it as code is like you get a versioned view of what was your — we SDLC, AI DLC, PDLC, whatever DLC you want. You get a versioned view of that, and then you get the ability to create branches off it which you can test. You get the ability, if you change it, to revert it. So all the obvious things about source control that are great.

然后你还得到一个极其酷的额外好处：因为它在代码里，编程智能体可以对它提出改进建议。所以对我来说，这就是自我改进的软件工厂体系的基础：以声明式的方式定义你的工厂。

And then you get the added benefit that's extremely cool, where because it's in code, coding agents can suggest improvements to it. So to me this is like the foundation of a self-improving software factory setup: define your factory declaratively.

在架构这套系统时，这个栈的下一步是有一个地方来汇集智能体产生的所有信息。因为你需要能够检视这些信息、寻找失败模式，或者用不同的变量重放过去那些任务，从而——我不知道“科学地”这个词是否准确，但从度量的角度——真正优化你的系统。这就是思路。所以你需要数据来做到这一点。你需要智能体的对话，也需要智能体的产物。你需要记录所有工具的全部交互，才能得到一个结果。

The next step up in this stack, as you think about architecting it, is someplace to gather all of the information that agents are producing. Because what you want to be able to do is examine that information, look for failure modes, or replay those same past tasks with different variables to — I don't know if scientifically is the right word, but from a measurement standpoint — really optimize your system. So that's the mindset. So you need the data to do that. You need the agent conversations and you need the agent artifacts. You need a record of all of the interactions from all of the tools to get to a result.

我的意思是，你可能有一个工厂对话，从 Slack 开始，然后延续到 Linear，再延续到 GitHub，中间有一条代码评审评论，整个交互最终会产生一段合并的代码。事实上，它甚至可能导致某个东西上线，然后服务器崩了，你希望能事后回溯——大概率是用智能体，但也可以由人来做——去诊断这本来怎么能做得更好。失败在哪里？

And so what I mean by that is, you might have a factory conversation that starts in Slack and then continues into Linear and then continues into GitHub, and there's a code review comment, and that whole interaction is going to result in some piece of merged code. In fact, it might even result in something that gets shipped, and then a server crashed, and you want the ability to retroactively go back — with an agent most likely, but you could do it as a person — and diagnose how could that have been better. What was the failure in it?

你还需要——这部分看起来相当显然——你需要一种把数据送进这个系统的方式。所以你需要某种接入 MCP 的方式。然后我们发现，随着公司变大，他们希望组织里不同部门有不同的访问权限。所以他们想要这样的东西：市场团队能访问哪些 MCP，销售团队能访问哪些，工程团队又能访问哪些？所以同样，如果你要推行这样的东西，你会发现根据组织规模不同，会有一堆复杂性。

You also need — this part will seem fairly obvious — but you need a way of getting data into this system. So you need some way of plugging in MCPs. And then we find that as companies get bigger, they want different access for different parts of their organization. So they want things like: what MCPs can the marketing team access versus the sales team versus the engineering team? And so again, you'll find there's a bunch of complexity depending on how big your organization is if you're trying to roll something like this out.

你确实需要一个算力层。你应该把它当作一个独立的东西。现在显然有很多智能体沙箱提供商。所以如果你要用第三方的，我会把它做成可插拔的。我们把 Namespace 作为主要的那个。

You really want a compute layer. You should think of that as a separate thing. And so there are obviously a lot of agent sandbox providers at this point. So if you're going to use a third-party one, I would just make that pluggable. We use Namespace as our primary one.

他们是在 AI Europe 上发布的。Namespace 很棒。

They launched it at AI Europe. Namespace is awesome.

但这应该是可插拔的。我觉得这非常重要。所以如果你想用 Daytona 或 Modal 或 E2B 之类的，我会把它架构成一个可插拔的组件。我会确保根据你的需求，你能支持不同的平台。所以同样，默认情况下你大概会想用 Linux 类型的沙箱，但对于电脑操作——就像我们测试 iOS 应用的方式——你会希望有能力跑一个 Mac 虚拟机，真正让它运行模拟器并到处点击。

But this should be pluggable. I think that's really important. So if you wanted to use Daytona or Modal or E2B or whatever, I would architect it so this is a pluggable component of it. I would make sure, depending on your requirements, that you can do different platforms. So again, by default I think you'll probably want to use a Linux-type sandbox, but for computer use — the way that we test iOS apps — you're going to want to have the ability to run a Mac VM and actually have it run the simulator and click around.

我们对推理持非常开放的态度。这非常符合我们想做到超级灵活的宗旨。我们发现现在很多公司已经有和 Anthropic、OpenAI 或 Google 的既有承诺用量，他们想把它消耗掉。所以我们提供了很大的多样性——你可以接入自己的推理提供商，也可以通过我们购买推理。你甚至可以接入自己的 harness，我觉得这相当重要。所以你可以编排像 Pi 这样的东西，就像我之前提到的，基本上任何兼容 ACP 的 harness 都行。

We have a very open approach to inference. And this is very much with our ethos of trying to be super duper flexible. So we find that a lot of companies right now will have pre-existing commits with Anthropic or OpenAI or Google that they want to burn down. And so we provide a very big variety — you can plug in your own inference provider, or you can buy inference through us. You can even plug in your own harness, which I think is a pretty big deal. So you can orchestrate things like Pi, like I mentioned earlier, basically any ACP-compatible harness.

然后你需要这个改进层。这就是我在演示里展示的一些东西，整个系统真正的威力就在于能够改进它。给一些数据：在 Warp，我们刚开始用工厂这套方法时，每个 PR 大约要花我们 80 美元，因为我们在不该用 Opus 的地方用了 Opus。我们的分诊智能体用了一个非常高性能的模型。我们在智能体的形态上做了一堆冗余工作——相对于只用更少的智能体，我们用了太多子智能体。

And then you want this improvement layer. This is some of the stuff that I showed in the demo, where the real power of this whole system is the ability to improve it. Just to give some stats: at Warp, when we first started using the factory approach, it was costing us about $80 per PR, because we were using Opus where we shouldn't have. Our triage agent was using a really high-powered model. We were doing a bunch of redundant work with the shape of agents — we were doing too many sub-agents relative to just having fewer agents.

所以我们基本上用这些内置功能做了一堆内部调优和测试，把每个 PR 的成本降到了大概 20 美元或 15 美元，差不多这样。我们能可度量地提升 PR 的吞吐量——过去一个月它涨了 40%。我们测量回滚率，它并没有上升。所以我对“观察、度量、调优”这个总体方法真的很有信心。

And so we basically did a whole bunch of internal tuning and testing using these built-in features, and we were able to get the cost per PR down to like 20 bucks or 15 bucks, something like that. We can measurably improve the throughput of our PRs — over the last month it's gone up by 40%. We measure the revert rate and it hasn't gone up. And so I really feel a lot of confidence in this general approach of observe, measure, tune.

最后，你需要某种编排器。有时候人们把编排器说成是整个平台。我认为它只是其中一块。我说的编排器是指，你需要一个系统，它接收工厂的定义代码，然后真正把工作沿着不同阶段推进，调用正确的模型、加载正确的技能等等。你需要某种能触发正确自动化的东西。

Finally, you need some sort of orchestrator. Sometimes people talk about the orchestrator like it's the whole platform. I think it's a piece of it. What I mean by orchestrator is you need some system that will take the factory definition code and then actually move work along the different stages, calling out to the right models, loading the right skills, etc. You need something that will fire the right automations.

然后最后，你需要一堆接入点。同样，我们在这方面的理念是——我也能理解别人有不同的理念——我们的理念是把工厂带进公司现有的知识工作工具里。想想最明显的那个：Slack。我们大约 60% 的工作是从 Slack 开始的。但有时候从任务追踪器开始更合理。有时候对一个更习惯在终端里用 Claude Code 的开发者来说，在那里做一堆工作，然后把一份规格提交进工厂，更合理。

And then finally, you need a bunch of access points. And again, our philosophy with this — and I could see people having different philosophies — our philosophy is to bring the factory into a company's existing knowledge work tools. So think of the most obvious one: Slack. We're doing like 60% of our work starting in Slack. But sometimes it makes sense to start in the task tracker. Sometimes it makes sense for a developer who is more comfortable using Claude Code in their terminal to do a bunch of work there and then submit a spec into the factory.

所以我们的理念是尽量让整个东西由 API 驱动、由 MCP 驱动，让工厂本身成为一块无头基础设施，拥有所有这些不同的入口。所以我觉得这种基于栈的视角——当我展示它、和公司交流时——似乎很能被接受，就是：好，是的，这说得通。这是开发者基础设施栈里的一个新东西。它大致位于 CI/CD 往后一层的位置，但我认为大多数公司都会为软件开发配备类似的东西。

And so our philosophy is to try to make this whole thing API-driven and MCP-driven, so that the factory itself is a piece of headless infrastructure with all these different entry points. So I think this stack-based view of it — when I've shown it and we've talked to companies — seems to land very well, like, okay yes, this makes sense. This is a new thing in the developer infrastructure stack. It kind of sits one level back from where CI/CD is, but I think most companies will have something like this for software development.

是啊，这实际上有很多层。我其实从没见过像你这样把它讲清楚的。我在想——因为我觉得大多数，你知道，Cognition，我见过，你知道，Cursor，所有这些——它们都试图做某种从底到顶的打包，而且有一点捆绑，所有软件都有捆绑。所以有一个关键问题：你看，我作为一家 B2B SaaS 的 CTO，在这里努力做好我的工作——我真的需要这全部六层吗？我觉得问题也许是：这是给谁用的？

Yeah, that has a lot of layers, actually. I've never actually seen it spelled out like you have. I wonder — because I think most, you know, Cognition and I've seen, you know, Cursor, all these — they all try to do some bundle of, like, from bottom to top, and there's a little bit of bundling, and bundling with all software. And so there's a critical question of, like, look, I'm trying to do my job here as CTO of a B2B SaaS — do I need all these six layers? I think it's like, who's this for, maybe, is the question.

当我们和最能产生共鸣的公司交流时，那必须是有一定规模的公司。就像，这个——说实话，如果你只有几个人，这就是杀鸡用牛刀。

So when we talk to companies where this resonates the most, it has to be a company that has some amount of scale. Like, this is — if you're a few people, honestly, this is overkill.

别搞这个。用 Claude Code 订阅或 Codex 订阅之类的，就——你会更快。你大概不需要——

Don't do this. Use the Claude Code sub or the Codex sub or whatever, and just — you'll go faster. You probably don't need —

你也可以用这个。是的。任何更大的团队栈也一样，对吧？就像，到了某个时候你会从“随便开火、yolo”之类的，切换到：我们其实需要一个平台化系统来加速。

You could use this. Yeah. Same for any larger team stack, right? Like, at some point you switch from, like, fire, yolo, whatever, to: we actually need a platforming system here to accelerate.

是的。

Yeah.

所以你得达到一定规模。我们开始看到，大概 5 到 10 名工程师可能是这件事成立的下限，然后一直到非常大的公司，他们都想要这样的东西。公司越大，需要的实施工作就越多。我相信如果你在和 Cognition 合作——或者我不知道 Cursor 是不是也这样——但要在公司自己的基础设施里把这样的系统搭起来，它不会是纯粹的即插即用。一个团队内部开发者环境的复杂度就是会随规模增长。但有很多公司——也许是 10 到 100 名工程师、快速增长的成长期创业公司——其实相当自助化，他们用的就是 Slack、Linear、Jira 这套快乐技术栈。

So you have to be at a certain scale. We start seeing that maybe around 5 to 10 engineers would be the floor where this makes sense, and then all the way up to very large companies — they want something like this. The bigger the company, the more implementation work this requires. I'm sure if you're working with Cognition — or I don't know if Cursor does — but to get something stood up like this within a company's own infrastructure, it's not going to be purely plug-and-play. The complexity of a team's internal developer setup just grows with size. But there are a bunch of companies — maybe a 10 to 100 engineer, fast-growing, growth-stage startup — where it's pretty self-serve actually, where they're using the happy stack of Slack, Linear, Jira.

等等，你刚才把那叫快乐技术栈？

Hang on, did you call that the happy stack?

我叫它——对，那是我们的——不不不，对 Teams 之类的没有恶意，当然。但有一组集成，我觉得在创业公司里非常常见，你可以把这样的东西插进去，不需要太多配置就能立刻获得价值。我不知道你在这方面用得多少，但如果你在用 Devin 之类的，你大概能获得类似的体验——当你处在一个原生多人协作的环境里，比如 Slack 或 Linear。仅仅因为有了这个中心化的记录系统，你就能获得很多你可能没意识到的好处。比如 Slack 集成，你可以让信息从服务器崩溃频道、从用户反馈频道流进来，直接喂给工厂让它干活。工厂可以根据团队里谁熟悉代码库的哪部分，把多个人拉进来。所以我不认为这件事必须规模很大才成立，但它对一个小团队肯定不成立。它最适合那种公司——我想把正确的基础设施搭好，这样随着模型和智能体不断变化，我们有一个可以持续构建其上的系统。

I call it — yeah, that's like our — no, no, no shade to Teams or whatever, sure. But there's a set of integrations that I find very common at startups, where you can plug something like this in and get immediate value without too much setup. I don't know how much you're working like this, but if you're working with Devin or something, you can kind of get some of the same experience where you're working in an environment that's natively multiplayer — so like Slack, for instance, or Linear. There are all these benefits you might not realize just by having this central system of record. For the Slack integration, for instance, you can get some flow of information coming in through a server crash channel and through a user feedback channel — you can just feed that directly into the factory to have it do the work. The factory can loop in multiple people on your team depending on who knows the right part of the codebase. So I don't think you have to be that big for this to make sense, but it definitely doesn't make sense for a small team. It really makes the most sense for a company that's like, I want to put in place the right infrastructure so that as models and agents continue to change, we have a system that we're building upon.

这里有很多可以聊的。我再追问一个问题，然后就让你宣传一下你的 AI 演讲，以及大家一般可以在哪里跟进你。搭建这一切最有力的批评是什么？当你遇到批评或反对意见时，人们应该知道什么——比如，大家实际在遇到什么问题。

There's a lot to go on here. One follow-up question, and then I'm going to have you plug your AI talks and just generally where to follow up with you. What is the most steelman criticism of setting up all this? When you encounter criticism or pushback, what should people know — like, here's what people are running into.

我这样回答——有一类典型的客户，我认为他们不适合上这套东西，那就是——

I'll answer this in — there's a certain classic customer where I don't think it makes sense to go on to this particular thing, and that's —

对，而且除了规模之外。

Yeah, and beyond the size thing.

对。我们现在遇到挑战的地方，是那些基础设施非常非常定制的公司，或者——比如 Uber 或 Ramp 这类，对我们这套东西来说就是不太合适的客户。他们在自建自己的东西，有非常大的内部开发者团队。但除了规模之外——我是说，肯定有——对某些人来说，对非常小的团队，直接用订阅就是更经济。但这又回到规模——

Yeah. Where we have challenges right now are companies with very, very bespoke infrastructure, or companies with — our kind of not-a-good-fit customer for this, for instance, would be like Uber or Ramp. They're building their own thing, they have very large internal developer teams. But apart from the size thing — I mean, there's definitely — for some people it's just going to be more economical to just use the subs, for small, very small teams. But that comes back to the size —

确实。

Actually.

对。

Yeah.

我其实不想略过订阅这件事，因为我觉得很多人直接走 API、按 API 付费，而那比直接买一堆订阅贵 5 到 50 倍。人们真这么干吗？这是不是太违反服务条款了，所以大家干脆别费劲，还是说——

I don't want to actually omit the subs stuff, because I think a lot of people go straight to API, pay by API, and that is between five to 50 times more expensive than just getting a whole bunch of subs. Do people do that? Is that so against terms of service that you just don't bother, or like —

我们聊过很多小公司，他们说，哦，这套系统看起来很棒，我们想要，但我们在用一堆 200 美元的订阅轮着用。我说，轮着用 17 个不同的订阅，对吧？你很难想象这是被允许的。但事实是我真的不太清楚。但他们确实在这么做，而且——说实话，如果你能这么干，那会是最便宜的方式，但这么做你会失去一大堆其他好处。而且这不是可扩展的做法，如果你的公司扩展到一定程度，你肯定不会被允许这么做。但它说得通。

Talk to a lot of small companies we talked to, where they're like, oh, this system seems amazing, we want this, but we're on these collection of $200 subs that we're rotating through. I'm like, rotating like 17 different subs, right? And then you can't imagine that's allowed. But the truth is I just don't really know. But they are, and it's — honestly, if you can do that, that's going to be the cheapest way, but you do lose a whole bunch of other benefits if you do that. And it's not a scalable thing, and if your company scales to a certain point, you're definitely not going to be allowed to do that. But it makes sense.

对。我只是说，补贴的程度——一个 200 美元的套餐你能拿到 8000 美元的 API 额度，对吧？

Yeah. I'm just saying, like, the extent of subsidy you get — for a $200 plan you get $8,000 of API, right?

对。太疯狂了。这可不是小钱。

Yeah. It's crazy. That's not money to sneeze at.

不不不。而且这是——我是说，单从商业角度看，这就是我不想做纯编程智能体业务的原因之一，因为你根本没法——祝你好运去竞争吧。

No, no, no. And it's one of the — I mean, just from a business perspective, it's one of the reasons that I don't want to be in the pure coding agent business, because you just can't — good luck fighting.

你没法在一个成本高得多的东西之上构建一个有竞争力的编程智能体。这就是现实。我是说，Cursor 很聪明——他们做到了，然后我觉得他们完美退出、变成了一家模型实验室，因为我觉得他们完全看清了这里的经济账。所以 Warp Factories 酷的地方在于，我们其实不是——我们不是在推销一个转卖 token 的产品。我们推销的基本上是一个编程智能体优化平台和一个编程智能体生产力平台。所以我们这个产品不参与那场游戏，这是我们的优势。而那场游戏——我知道外面还有几家独立的编程智能体。我不知道它们打算怎么活。基本上就是 Cognition 和 OpenCode。就这些。哦，当然还有 Factory。

You can't build a competitive coding agent on top of a thing that costs so much more money. And that's just the reality of it. I mean, Cursor was brilliant — they did it, and then I think they had a perfect exit and became a model lab, because I think they fully realized the economics of it. And so the cool thing about Warp Factories is we're actually not — we're not trying to pitch a token reselling product. We're trying to pitch basically a coding agent optimization platform and a coding agent productivity platform. So we're not in that game with this product, which is a strength. And that game — I know there's still a few independent coding agents out there. I don't know how they're going to do it. It's basically Cognition and OpenCode. That's it. Oh, and Factory, of course.

我们最后来宣传一下你的演讲。大家会来看你，我们也会直播之类的，但请给我们讲讲你一直在做的这个系列的大致脉络，以及你下次要讲什么。

Let's wrap up with a little plug for your talk. People will come see you and we'll live stream it and all that, but give us a general arc of the series that you've been developing and where you're going to talk about next.

这次演讲的重点是，在这个工厂工程日益增多的世界里，做一名工程师是什么样子，以及你的角色是什么？你的工作会变成什么？两种工程——产品工程和工厂工程——分别是什么？然后，如果你想用这个词的话，工厂工程这门新学科实际上是什么样子？有哪些工具？作为一名工程师，你如何培养正确的技能，让你去工程化那个构建软件的系统，而不只是直接构建软件？

What the talk is going to focus on is what it looks like to be an engineer in this world of increasing factory engineering, and like, what are your roles? What's your job going to be? What are the two types of engineering — product engineering, factory engineering? And then what does this new discipline, if you want to use the word, of factory engineering actually look like? What are the tools? How do you as an engineer build the right skills so that you're engineering the system that builds the software and not just building the software directly?

这是完美的回顾和概述。如果人们想联系你，应该去哪里找你？如果你们在招人，招什么岗位？任何类似行动号召的内容。

That is a perfect recap and overview. If people want to talk to you, where should they find you? If you're hiring, what are you hiring for? Anything that's like a call to action.

好的。

Yeah.

欢迎来看看 warp.dev，大部分内容都在那里。我们在招工程师，在招市场团队，在招数据团队，在招设计师——一大堆岗位都在招人。如果你对我关于工厂的思考感兴趣，我现在在 Twitter 上发了很多内容，就是 Zach Lloyd 的推文。来关注一下，我会继续分享我的想法。

So come check out warp.dev. Most stuff is there. We're hiring engineers, we're hiring on our go-to-market team, we're hiring on the data team, we're hiring a designer — hiring for a whole bunch of roles. If you're interested in my musings on factories, I put out a lot of content on my Twitter now, so Zach Lloyd tweets. Come follow that and I'll keep sharing how I'm thinking about it.

我们会关注的，会的。好的，非常感谢你抽时间，Cole。

We'll do. We'll do. All right. Thanks so much for the time, Cole.

好，谢谢邀请我。

Cool. Thanks for having me.