# Adopting the software factory model: crawl, walk, run
**作者**: Zach Lloyd
**日期**: 2026-09-09T17:29:14.000Z
**来源**: [https://x.com/zachlloydtweets/status/2099941244063432720](https://x.com/zachlloydtweets/status/2099941244063432720)
---
The [software factory approach](https://www.warp.dev/blog/a-guide-to-cloud-software-factories-for-engineering-leaders) (a closed agentic loop that runs in the cloud) is growing in popularity, but it can be daunting to adopt. In this post I’ll go through “crawl, walk, run” steps for making the transition from local, interactive agents to automated cloud development.
## Crawl
Many eng leaders and platform engineers I speak with have already started on the “crawl” part of building a software factory by building simple automations using [cloud agents](https://docs.warp.dev/platform/).
Think of these automations as Trigger → Agent Activity.
For example:
- [Issue reproduction and triage](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-the-automatic-triage-skill): have an agent look at all new issues that are filed and reproduce them and label them.
- [Code review](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-self-improving-code-review): Automatically review PRs as they are opened and leave comments
- Monitoring: have an agent that responds to a Sentry alert and debugs and fixes an issue
- Self-heal CI: fix broken CI by identifying PRs to roll back, merge conflicts to resolve
- Autoupdate docs: update user-facing documentation and generate changelogs
- [Verification](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-computer-use-verification): [browser-use](https://docs.warp.dev/agents/capabilities/computer-use/browser-use/) and [computer-use](https://docs.warp.dev/agents/capabilities/computer-use/) agents visually QA and verify changes
- Simple bug fixes: agents identify and fix simple user-reported issues
The thing in common with all of these approaches is that they automate a discrete part of the software lifecycle. Starting with simple automations is a low risk, low cost approach and it helps build intuition on how to effectively use agents across more complex, multi-stage tasks.
Sample automation for alert monitoring
These automations might be built using homegrown infrastructure (e.g. putting the Claude Code SDK into a Docker container and wiring up a server to trigger it), or might use a [generic cloud agent automation platform](https://docs.warp.dev/platform/) designed to run agents on triggers. They might also use an entire platform dedicated to one stage of the cycle (e.g. a dedicated agentic code reviewer or AI SRE).
Starting with a patchwork of point automations is fine, but most teams eventually hit limits with this approach.
Specifically:
- Depending on how things are set up, these automations might not share context. That means as you make improvements to one aspect (say, code review) they don’t carry over to other stages, like triage and QA.
- There’s no global view of whether all these one-off automations actually improve overall productivity, and no systematic way of testing and improving the high level metrics you care about like [cost-per-PR, cycle time, automation percent](https://www.warp.dev/blog/agent-self-improving-software-factories), etc. To track these you need a system that works across development stages.
- The point solutions each create their own setup and maintenance burden. They create a larger security surface to manage. They don’t have a unified interface for observability. Teams eventually want central configuration, auditing and governance.
## Walk
All these issues point towards the need for a more holistic approach. Organizations that have crawled ask themselves “what is the system we want for truly scaling agentic development?”
More specifically, they ask:
- Where should development happen? Locally or in the cloud? Through what interfaces?
- What does a successful automated development process look like? What are the key metrics?
- What’s our AI sovereignty posture? How important is it to own our coding agent data? How dependent should we be on model providers?
- How do we plan on improving our development process over time? How do we control costs while accelerating how fast we ship? How do we know we are improving?
- How are we future-proofing as models and agents improve? Are we accounting for regulatory risk that might impact access to models?
- How exactly should engineers participate in the development process? Same for designers, PMs and other builders?
- How are we securing development? What’s our plan if our software production process is compromised?
Most engineering leaders and platform teams that think hard about these questions land on something like a [cloud software factory approach](https://docs.warp.dev/factories/). They want
- [Development in the cloud](https://www.warp.dev/blog/if-you-want-better-agent-roi-and-governance-move-your-agents-to-the-cloud) by default, because it’s more secure to give agents sandboxes than to let them loose locally
- Centralized governance of coding agents and the tools and systems they access
- Complete traces of what agents have done, for auditing and understanding productivity
- Optionality around models and harnesses, for minimizing risk and optimizing performance
- Integration of development into all of the tools your team is already using (e.g. Slack/Teams, Jira, Github, etc)
- Escape hatches for humans to take over, either by [steering live agents](https://docs.warp.dev/factories/factory-dashboard/) or bringing work into the [inner development loop](https://docs.warp.dev/factories/factory-mcp/)
- A shared context layer that works across agents all phases of development
- An approach that allows for testing, [evals and benchmarks](https://docs.warp.dev/factories/benchmarks/) so that your team has confidence the system is improving over time
Once a company decides on a factory approach, the question becomes: how do you get there from your existing point automations? This usually boils down to whether (1) you build more infra around those automations or (2) you transition to a platform like [Warp Factories](https://www.warp.dev/factories), which provides factory infrastructure.
Note that I wouldn’t frame this as a traditional build vs. buy decision. No matter what path you take, you should expect your internal team to do some building because to make a factory approach work, that factory has to be deeply integrated into your team’s context and workflows. It’s more a question of whether you build your automation infrastructure totally from scratch, or you partner with folks who are providing you with a head start.
For example, no matter what path you take, you should expect to build organization-specific skills and tune them for your codebase. You should expect to expose and configure organization specific MCPs and internal context sources. But, you might not want to build cloud infrastructure for running and managing agents, steering them, handing off their work, measuring their efficacy, doing computer use, and so on. The rule of thumb is to focus on building the pieces that are specific to your org, not the ones needed by every organization.
Whichever approach you take, I suggest that the biggest milestone in the walk phase is [deploying a first factory](https://docs.warp.dev/factories/quickstart/) end-to-end on a simple product surface. This could be your marketing site or an internal app.
Starting with one simple project has the advantage of getting a whole loop going with low stakes and minimal complexity. Adding more repos, lines of code, service dependencies, human stakeholders, and so on increases complexity and can lead to a feeling that you’re not ready for automation. Better to dial in a simple loop first.
The goal is a multi-agent system that goes from [triage → spec → implement → review → verify → monitor](https://docs.warp.dev/factories/how-factories-work/). In more detail:
1. New issue comes into the system, either via a human or a monitoring agent
2. Triage agent runs and tries to understand and repro issue. If it determines the task is automatable → hand it to the Implementation agent. If it needs specs because of scope → have the spec agent iterate with a human to come up with a spec. If it’s ambiguous → get human input and re-run, or just decide to park the issue for now
3. [If necessary] Spec agent runs, human reviews specs, and then passes to implementation agent
4. Implementation agent writes code
5. Code review agent reviews code
6. Verification agent does [computer-use or other verification](https://docs.warp.dev/agents/capabilities/computer-use/testing-and-recordings/)
7. Human reviews code and verification output. If necessary, go back to step 2, 3, 4 or 5
8. CI / CD
9. Ship it
10. Monitor agent runs and creates issues if need be completing the loop
Internally at Warp our walk factory automates about 75% of changes to [warp.dev](http://warp.dev/), our marketing site. Unlike Warp Terminal (65k GitHub stars, almost a million active devs, 1M lines of native rust), our marketing site is a pretty simple app. Note that by “automate” I mean going from human input to a shipped feature entirely through the factory, with minimal human touchpoints besides describing the change we want, [either in Slack or our task tracker](https://docs.warp.dev/factories/connect-your-factory/).
## Run
Only when you have the basic loop in place on a simple project should you scale up to more complex projects. Scaling factories requires more robust infrastructure.
Specifically, as you scale certain bottlenecks arise:
- Getting [remote dev environments](https://docs.warp.dev/guides/agent-workflows/run-a-software-factory-in-the-cloud/) working on large projects is hard. More repos, lines of code, service dependencies, all make automation harder.
- As you have more skills and code, etc. it becomes harder to know if the changes you are making to your factories are having a positive impact on development or just causing churn
- You naturally run higher cost risks as agents do work on more complex codebases because you need more powerful models and agents need to run longer. Model routing and harness choice become more important.
- Security and auditing becomes more important the more you bring a factory approach to mission critical user-facing apps
- More app stakeholders means more human coordination and signoff. You’ll want a factory solution that allows for multi-player inputs and audit trails
- Inevitably PRs will start to pile up so you’ll want a defined strategy for what gets code reviewed, how you use agentic verification and QA
- You’ll want more robust tools for closing the loop, making sure that changes that ship to production are at high quality, not crashing, etc.
Getting scaled factories working is, in my opinion, going to be one of the more interesting software engineering challenges in the next few years; software engineering is becoming [factory engineering](https://www.warp.dev/blog/we-are-now-factory-engineers-not-product-engineers). Organizations that can make their factories robust, dependable, and [self-improving](https://www.warp.dev/blog/engineering-self-improving-software-factories) will be able to ship more at better cost and have a competitive advantage.
To make factories really hum takes significant investment. At Warp, we think of this as fully building your factory stack:
I cover each of these layers in detail in this post:
> **Zach Lloyd@zachlloydtweets**: [原文链接](https://x.com/zachlloydtweets/status/2097739116720910619)
>
> Software factories should be built on an infrastructure stack that is open, composable, and defined-in-code.
> This article lays out the principles that apply to anyone who is looking to move to a factory model.
A few key ones to call out that might not be obvious:
- [Factories-as-code](https://docs.warp.dev/factories/factory-as-code/): one of the key choices you can make is defining your factories as code. This enables testing of different factory configurations to see which are most efficient, highest quality, etc.
- [Multi-model & multi-harness](https://docs.warp.dev/factories/factory-agents/): you should make sure that your factories are able to use the latest models, both frontier and open-weight, and use different coding agent harnesses like Claude Code and Codex.
- [Data ownership](https://docs.warp.dev/factories/infrastructure-and-security/): you should make sure you store and own all data coming out of your factory - this is the raw material for improving its operations.
In a fully humming factory, the key characteristic is that it’s a [closed loop](https://www.warp.dev/blog/agent-self-improving-software-factories), measurable, improvable system. This should be the goal. In such a system everyone is working from the same context, in public, in a fully-audited, observed way. Agents themselves are observing the skills and config that drive the system and suggesting improvements. Platform engineers are able to extend the system to integrate it into all internal systems. Engineering leaders can see productivity metrics and understand what changes are being made to improve them. The whole thing is running empirically, not on vibes.
At Warp, we are getting closer to this vision. Every day we are all working in public, tuning our factory, driving down costs and improving throughput and quality.
Our mission is to provide the world’s best engineering teams with the tools to build, measure and optimize their own workflows using any underlying model and harness on open infrastructure. These capabilities will help teams ship better software more quickly and efficiently.
[Warp Factories](https://www.warp.dev/factories) is currently in [early access](https://docs.warp.dev/factories/). Qualified companies get $10k of factory usage.
## 相关链接
- [Zach Lloyd](https://x.com/zachlloydtweets)
- [@zachlloydtweets](https://x.com/zachlloydtweets)
- [61K](https://x.com/zachlloydtweets/status/2099941244063432720/analytics)
- [software factory approach](https://www.warp.dev/blog/a-guide-to-cloud-software-factories-for-engineering-leaders)
- [cloud agents](https://docs.warp.dev/platform/)
- [Issue reproduction and triage](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-the-automatic-triage-skill)
- [Code review](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-self-improving-code-review)
- [Verification](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-computer-use-verification)
- [browser-use](https://docs.warp.dev/agents/capabilities/computer-use/browser-use/)
- [computer-use](https://docs.warp.dev/agents/capabilities/computer-use/)
- [generic cloud agent automation platform](https://docs.warp.dev/platform/)
- [cost-per-PR, cycle time, automation percent](https://www.warp.dev/blog/agent-self-improving-software-factories)
- [cloud software factory approach](https://docs.warp.dev/factories/)
- [Development in the cloud](https://www.warp.dev/blog/if-you-want-better-agent-roi-and-governance-move-your-agents-to-the-cloud)
- [steering live agents](https://docs.warp.dev/factories/factory-dashboard/)
- [inner development loop](https://docs.warp.dev/factories/factory-mcp/)
- [evals and benchmarks](https://docs.warp.dev/factories/benchmarks/)
- [Warp Factories](https://www.warp.dev/factories)
- [deploying a first factory](https://docs.warp.dev/factories/quickstart/)
- [triage → spec → implement → review → verify → monitor](https://docs.warp.dev/factories/how-factories-work/)
- [computer-use or other verification](https://docs.warp.dev/agents/capabilities/computer-use/testing-and-recordings/)
- [warp.dev](http://warp.dev/)
- [either in Slack or our task tracker](https://docs.warp.dev/factories/connect-your-factory/)
- [remote dev environments](https://docs.warp.dev/guides/agent-workflows/run-a-software-factory-in-the-cloud/)
- [factory engineering](https://www.warp.dev/blog/we-are-now-factory-engineers-not-product-engineers)
- [self-improving](https://www.warp.dev/blog/engineering-self-improving-software-factories)
- [Sep 10](https://x.com/zachlloydtweets/status/2097739116720910619)
- [30K](https://x.com/zachlloydtweets/status/2097739116720910619/analytics)
- [Factories-as-code](https://docs.warp.dev/factories/factory-as-code/)
- [Multi-model & multi-harness](https://docs.warp.dev/factories/factory-agents/)
- [Data ownership](https://docs.warp.dev/factories/infrastructure-and-security/)
- [closed loop](https://www.warp.dev/blog/agent-self-improving-software-factories)
- [Warp Factories](https://www.warp.dev/factories)
- [early access](https://docs.warp.dev/factories/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:19 AM · Sep 16, 2026](https://x.com/zachlloydtweets/status/2099941244063432720)
- [61.1K Views](https://x.com/zachlloydtweets/status/2099941244063432720/analytics)
- [View quotes](https://x.com/zachlloydtweets/status/2099941244063432720/quotes)
---
*导出时间: 2026/9/16 09:29:26*
---
## 中文翻译
# 采用软件工厂模式：爬、走、跑
**作者**： Zach Lloyd
**日期**： 2026-09-09T17:29:14.000Z
**来源**： [https://x.com/zachlloydtweets/status/2099941244063432720](https://x.com/zachlloydtweets/status/2099941244063432720)
---
[软件工厂方法](https://www.warp.dev/blog/a-guide-to-cloud-software-factories-for-engineering-leaders)（一种在云端运行的闭环代理流程）正日益流行，但采用起来可能令人望而生畏。在本文中，我将介绍从本地交互式代理过渡到自动化云端开发的“爬、走、跑”三步策略。
## 爬（Crawl）
与我交流过的许多工程负责人和平台工程师，已经开始通过使用[云端代理](https://docs.warp.dev/platform/)构建简单自动化，来着手“爬”这个阶段的软件工厂构建。
可以把这些自动化看作：触发器 → 代理活动。
例如：
- [Issue 复现与分类](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-the-automatic-triage-skill)：让代理查看所有新提交的 issue，复现它们并打标签。
- [代码审查](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-self-improving-code-review)：在 PR 打开时自动审查并留下评论
- 监控：让代理响应 Sentry 告警，调试并修复问题
- CI 自愈：通过识别需要回滚的 PR、需要解决的合并冲突来修复损坏的 CI
- 自动更新文档：更新面向用户的文档并生成变更日志
- [验证](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-computer-use-verification)：[浏览器操作](https://docs.warp.dev/agents/capabilities/computer-use/browser-use/)和[计算机操作](https://docs.warp.dev/agents/capabilities/computer-use/)代理以可视化方式进行 QA 并验证更改
- 简单 bug 修复：代理识别并修复用户报告的简单问题
这些方法的共同点在于，它们自动化了软件生命周期中的一个离散环节。从简单的自动化入手是一种低风险、低成本的方法，它有助于积累直觉，了解如何将代理有效应用于更复杂的多阶段任务。
告警监控的自动化示例
这些自动化可以基于自研基础设施构建（例如，把 Claude Code SDK 放进 Docker 容器，并搭建一个服务器来触发它），也可以使用为按触发器运行代理而设计的[通用云端代理自动化平台](https://docs.warp.dev/platform/)。它们还可以使用专注于生命周期某一阶段的完整平台（例如专门的代理代码审查工具或 AI SRE）。
先从拼凑式的单点自动化开始没问题，但大多数团队最终会遇到这种方法的局限。
具体来说：
- 根据设置方式的不同，这些自动化可能不共享上下文。这意味着当你对某一方面（比如代码审查）进行改进时，这些改进不会延续到其他阶段，比如分类和 QA。
- 没有一个全局视角来判断这些一次性的自动化是否真正提升了整体生产力，也没有系统性的方法来测试和改进你所关心的顶层指标，例如[每个 PR 的成本、周期时间、自动化百分比](https://www.warp.dev/blog/agent-self-improving-software-factories)等。要追踪这些指标，你需要一个能够贯穿各开发阶段的系统。
- 每个单点解决方案都带来各自的搭建和维护负担。它们扩大了需要管理的安全攻击面。它们没有统一的可观测性界面。团队最终会需要集中的配置、审计和治理。
## 走（Walk）
所有这些问题都指向需要一个更整体化的方法。已经完成“爬”阶段的组织会问自己：“我们想要什么样的系统来真正扩展代理化开发？”
更具体地说，他们会问：
- 开发应该在哪里进行？本地还是云端？通过什么界面？
- 成功的自动化开发流程是什么样的？关键指标是什么？
- 我们对 AI 主权的立场是什么？拥有我们自己的编码代理数据有多重要？我们应该在多大程度上依赖模型提供商？
- 我们计划如何持续改进开发流程？我们如何在加速交付的同时控制成本？我们如何知道自己在进步？
- 随着模型和代理的进步，我们如何确保面向未来？我们是否考虑到了可能影响模型访问的监管风险？
- 工程师应该如何参与开发过程？设计师、PM 和其他构建者又该如何参与？
- 我们如何保障开发安全？如果我们的软件生产流程被攻破，应对计划是什么？
大多数认真思考这些问题的工程负责人和平台团队，最终都会选择类似[云端软件工厂方法](https://docs.warp.dev/factories/)的方案。他们想要：
- 默认[在云端开发](https://www.warp.dev/blog/if-you-want-better-agent-roi-and-governance-move-your-agents-to-the-cloud)，因为给代理提供沙箱比让它们在本地自由活动更安全
- 对编码代理及其访问的工具和系统进行集中治理
- 完整记录代理做了什么，便于审计和了解生产力
- 在模型和执行框架上有可选择性，以最小化风险并优化性能
- 将开发集成到团队已经在使用的所有工具中（例如 Slack/Teams、Jira、Github 等）
- 提供人工介入的“逃生舱口”，可以通过[实时引导代理](https://docs.warp.dev/factories/factory-dashboard/)或将工作带回[内部开发循环](https://docs.warp.dev/factories/factory-mcp/)
- 一个在代理之间、贯穿开发全阶段的共享上下文层
- 一种支持测试、[评估和基准测试](https://docs.warp.dev/factories/benchmarks/)的方法，让团队有信心系统在持续改进
一旦公司决定采用工厂方法，问题就变成：如何从现有的单点自动化过渡到那里？这通常归结为：是 (1) 在这些自动化周围搭建更多基础设施，还是 (2) 迁移到提供工厂基础设施的平台，比如 [Warp Factories](https://www.warp.dev/factories)。
请注意，我不认为这是一个传统的自建还是采购的决策。无论选择哪条路径，你都应该预期内部团队要做一些构建工作，因为要让工厂方法奏效，工厂必须深度融入你团队的上下文和工作流程。这更多是一个问题：你是完全从零开始构建自动化基础设施，还是与能为你提供先发优势的伙伴合作。
例如，无论选择哪条路径，你都应该预期要构建组织专属的技能并为你的代码库进行调优。你应该预期要暴露和配置组织专属的 MCP 和内部上下文源。但是，你可能不希望为运行和管理代理、引导它们、交接它们的工作、衡量其效果、执行计算机操作等去构建云基础设施。经验法则是：专注于构建对你组织而言独特的部分，而不是每个组织都需要的东西。
无论采取哪种方式，我认为“走”阶段最大的里程碑是在一个简单的产品表面上[端到端部署第一个工厂](https://docs.warp.dev/factories/quickstart/)。这可以是你的营销网站或一个内部应用。
从一个简单项目入手的优势在于，能以低风险、低复杂度跑通整个闭环。增加更多仓库、代码行数、服务依赖、人工干系人等会增加复杂性，并可能让你感觉还没准备好自动化。最好先把一个简单的闭环调好。
目标是构建一个从[分类 → 规格 → 实现 → 审查 → 验证 → 监控](https://docs.warp.dev/factories/how-factories-work/)的多代理系统。更详细地说：
1. 新的 issue 进入系统，来源可以是人工或监控代理
2. 分类代理运行，尝试理解并复现 issue。如果判定任务可自动化 → 交给实现代理。如果因范围原因需要规格 → 让规格代理与人工迭代制定规格。如果问题含糊 → 征求人工意见并重新运行，或者干脆决定暂时搁置该 issue
3. [如有必要] 规格代理运行，人工审查规格，然后交给实现代理
4. 实现代理编写代码
5. 代码审查代理审查代码
6. 验证代理执行[计算机操作或其他验证](https://docs.warp.dev/agents/capabilities/computer-use/testing-and-recordings/)
7. 人工审查代码和验证输出。如有必要，回到第 2、3、4 或 5 步
8. CI / CD
9. 发布
10. 监控代理运行并在需要时创建 issue，完成闭环
在 Warp 内部，我们的“走”阶段工厂自动化了 [warp.dev](http://warp.dev/)（我们的营销网站）约 75% 的更改。与 Warp Terminal（65k GitHub 星标、近百万活跃开发者、100 万行原生 Rust 代码）不同，我们的营销网站是一个相当简单的应用。注意，我所说的“自动化”是指从人工输入到功能交付完全通过工厂完成，除了[在 Slack 或我们的任务跟踪器中描述我们想要的更改](https://docs.warp.dev/factories/connect-your-factory/)之外，人工介入极少。
## 跑（Run）
只有在简单项目上建立起基本闭环之后，才应该扩展到更复杂的项目。扩展工厂需要更强大的基础设施。
具体来说，随着规模扩大，某些瓶颈会出现：
- 在大型项目上让[远程开发环境](https://docs.warp.dev/guides/agent-workflows/run-a-software-factory-in-the-cloud/)运转起来很困难。更多的仓库、代码行数、服务依赖，都会让自动化更难。
- 随着技能和代码等不断增多，越来越难判断你对工厂所做的更改是对开发产生了积极影响，还是只是制造混乱。
- 当代理在更复杂的代码库上工作时，成本风险自然会升高，因为需要更强大的模型，且代理需要运行更长时间。模型路由和执行框架的选择变得更加重要。
- 越是将工厂方法应用于关键任务、面向用户的应用，安全和审计就越重要。
- 更多的应用干系人意味着更多的人工协调和审批。你会需要一个支持多人输入和审计追踪的工厂方案。
- PR 不可避免地会开始堆积，所以你需要一个明确的策略，规定哪些内容需要代码审查、如何使用代理验证和 QA。
- 你会需要更强大的工具来闭环，确保发布到生产环境的更改是高质量的、不会崩溃等。
在我看来，让规模化工厂运转起来，将是未来几年更有趣的软件工程挑战之一；软件工程正在变成[工厂工程](https://www.warp.dev/blog/we-are-now-factory-engineers-not-product-engineers)。能够让自己的工厂变得稳健、可靠且[自我改进](https://www.warp.dev/blog/engineering-self-improving-software-factories)的组织，将能够以更优的成本交付更多成果，并获得竞争优势。
要让工厂真正高效运转，需要大量投入。在 Warp，我们把这看作是完整构建你的工厂技术栈：
我在本文中详细介绍了其中的每一层：
> **Zach Lloyd@zachlloydtweets**：[原文链接](https://x.com/zachlloydtweets/status/2097739116720910619)
>
> 软件工厂应该构建在一个开放、可组合、以代码定义的基础设施栈之上。
> 本文阐述了适用于任何希望转向工厂模式的人的原则。
其中有几个可能不太显而易见的关键点值得指出：
- [工厂即代码](https://docs.warp.dev/factories/factory-as-code/)：你可以做出的关键选择之一，是将工厂定义为代码。这使得可以测试不同的工厂配置，看哪种最高效、质量最高等。
- [多模型与多执行框架](https://docs.warp.dev/factories/factory-agents/)：你应确保工厂能够使用最新模型，包括前沿模型和开放权重模型，并可以使用不同的编码代理框架，如 Claude Code 和 Codex。
- [数据所有权](https://docs.warp.dev/factories/infrastructure-and-security/)：你应确保存储并拥有工厂产出的所有数据——这是改进其运作的原材料。
在一个完全高效运转的工厂中，关键特征是它是一个[闭环](https://www.warp.dev/blog/agent-self-improving-software-factories)、可衡量、可改进的系统。这应该是目标。在这样的系统中，每个人都在相同的上下文中、以公开的方式工作，一切都被完整审计和观测。代理本身也在观察驱动系统的技能和配置，并提出改进建议。平台工程师能够扩展系统，将其集成到所有内部系统中。工程负责人可以看到生产力指标，并了解为了改进这些指标所做的更改。整个系统是基于实证运行的，而不是凭感觉。
在 Warp，我们正逐步接近这一愿景。每天我们都在公开环境中工作，调优我们的工厂，降低成本并提升吞吐量和质量。
我们的使命是为全球最优秀的工程团队提供工具，让他们能够在开放的基础设施上，使用任何底层模型和执行框架来构建、衡量和优化自己的工作流程。这些能力将帮助团队更快速、更高效地交付更好的软件。
[Warp Factories](https://www.warp.dev/factories) 目前处于[早期访问](https://docs.warp.dev/factories/)阶段。符合条件的公司可获得价值 1 万美元的工厂使用额度。
## 相关链接
- [Zach Lloyd](https://x.com/zachlloydtweets)
- [@zachlloydtweets](https://x.com/zachlloydtweets)
- [61K](https://x.com/zachlloydtweets/status/2099941244063432720/analytics)
- [software factory approach](https://www.warp.dev/blog/a-guide-to-cloud-software-factories-for-engineering-leaders)
- [cloud agents](https://docs.warp.dev/platform/)
- [Issue reproduction and triage](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-the-automatic-triage-skill)
- [Code review](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-self-improving-code-review)
- [Verification](https://www.warp.dev/blog/how-to-build-a-cloud-software-factory-computer-use-verification)
- [browser-use](https://docs.warp.dev/agents/capabilities/computer-use/browser-use/)
- [computer-use](https://docs.warp.dev/agents/capabilities/computer-use/)
- [generic cloud agent automation platform](https://docs.warp.dev/platform/)
- [cost-per-PR, cycle time, automation percent](https://www.warp.dev/blog/agent-self-improving-software-factories)
- [cloud software factory approach](https://docs.warp.dev/factories/)
- [Development in the cloud](https://www.warp.dev/blog/if-you-want-better-agent-roi-and-governance-move-your-agents-to-the-cloud)
- [steering live agents](https://docs.warp.dev/factories/factory-dashboard/)
- [inner development loop](https://docs.warp.dev/factories/factory-mcp/)
- [evals and benchmarks](https://docs.warp.dev/factories/benchmarks/)
- [Warp Factories](https://www.warp.dev/factories)
- [deploying a first factory](https://docs.warp.dev/factories/quickstart/)
- [triage → spec → implement → review → verify → monitor](https://docs.warp.dev/factories/how-factories-work/)
- [computer-use or other verification](https://docs.warp.dev/agents/capabilities/computer-use/testing-and-recordings/)
- [warp.dev](http://warp.dev/)
- [either in Slack or our task tracker](https://docs.warp.dev/factories/connect-your-factory/)
- [remote dev environments](https://docs.warp.dev/guides/agent-workflows/run-a-software-factory-in-the-cloud/)
- [factory engineering](https://www.warp.dev/blog/we-are-now-factory-engineers-not-product-engineers)
- [self-improving](https://www.warp.dev/blog/engineering-self-improving-software-factories)
- [Sep 10](https://x.com/zachlloydtweets/status/2097739116720910619)
- [30K](https://x.com/zachlloydtweets/status/2097739116720910619/analytics)
- [Factories-as-code](https://docs.warp.dev/factories/factory-as-code/)
- [Multi-model & multi-harness](https://docs.warp.dev/factories/factory-agents/)
- [Data ownership](https://docs.warp.dev/factories/infrastructure-and-security/)
- [closed loop](https://www.warp.dev/blog/agent-self-improving-software-factories)
- [Warp Factories](https://www.warp.dev/factories)
- [early access](https://docs.warp.dev/factories/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [3:19 AM · Sep 16, 2026](https://x.com/zachlloydtweets/status/2099941244063432720)
- [61.1K Views](https://x.com/zachlloydtweets/status/2099941244063432720/analytics)
- [View quotes](https://x.com/zachlloydtweets/status/2099941244063432720/quotes)
---
*导出时间： 2026/9/16 09:29:26* 
