# The software factory stack
**作者**: Zach Lloyd
**日期**: 2026-09-09T17:29:14.000Z
**来源**: [https://x.com/zachlloydtweets/status/2097739116720910619](https://x.com/zachlloydtweets/status/2097739116720910619)
---
Software factories should be built on an infrastructure stack that is open, composable and [defined in code](https://docs.warp.dev/factories/factory-as-code/).
Open == works with any model, agent and hosting configuration
Composable == you can adopt part or all of the stack, and use the pieces however you want
Defined in code == factory state is versioned, testable, and revertible
In this article, I’ll lay out how we designed the stack for [Warp Factories](https://www.warp.dev/factories). The principles apply to anyone who is looking to move to a factory model.
Let’s break this down layer by layer, starting with the foundation and working our way up:
## Factories-as-code
Underlying the entire factory stack is a definition of the [Factory-as-code](https://docs.warp.dev/factories/factory-as-code/), starting with [factory.yaml](https://docs.warp.dev/factories/factory-as-code/), including:
- [Agent config](https://docs.warp.dev/factories/factory-agents/): Their prompts, skills, MCPs, [model routing](https://docs.warp.dev/platform/harnesses/) configs
- [Runners](https://docs.warp.dev/platform/runners/): Information on what environments the factory runs in (e.g. how to launch factory agents)
- Repos: A set of repos corresponding to the product the factory operates on
- [Automations](https://docs.warp.dev/factories/automations/): Triggers and actions that drive agentic behavior, like scheduled crons, error monitor pings, taskboard status changes, GitHub pull request updates, etc.
- [Integrations](https://docs.warp.dev/factories/connect-your-factory/):What tools the factory integrates with (e.g. Slack, Jira) Webhook config for triggering factory actions externally (e.g. Grafana or Sentry alerts)
- [Scorers, evals and benchmarks](https://docs.warp.dev/factories/measure-and-improve/): Tools for measuring the quality of the factory
The precise format of the code matters less than having a code-based approach that allows for versioned changes to the factory definition. Versioning opens up the possibility of benchmarking, A/B testing, rollbacks, etc. It’s Terraform for factories. If your factory is defined in code with versioning, it's much easier for you (or your agent) to test and improve.
## Data and context
One level up sits the Context Layer of your factory. This is comprised of:
- [Internal MCPs and CLIs](https://docs.warp.dev/platform/mcp/): Tools for your factory agents to pull organizational info into agent context, plus the authentication and RBAC systems for managing their use
- [Memories](https://docs.warp.dev/agents/agent-memory/): Memories are learnings that your agent stores (e.g. “here’s our coding convention for global constants”), either through explicit user instructions or inferred improvements. They could be stored via a third-party service, a vector DB, or plain files
- Agent traces: All past runs of factory agents (full conversation logs) Metadata around agent runs like cost, time spent, etc. These form the raw input for self-improvement loops.
- Agent telemetry and access logs: Full audit trails for all agent interactions and tool calls for security and debugging
- Repos: The code the factory operates on The versioned agent Skills that live in that code
- [Skills and plugin marketplaces](https://docs.warp.dev/factories/factory-skills/): Extensible ways of discovering and using internal Skills
The Context Layer should be pluggable and extensible.
If you are using a third-party context layer, you should be able to store all data from it on your own infrastructure. No external provider should get to train on this data. [ZDR is a must.](https://x.com/zachlloydtweets/status/2097701689340129781?s=20)
## Compute
Next up is the Compute Layer. This is where your agents run.
In the Compute Layer, you need:
[Remote dev environments](https://docs.warp.dev/platform/environments/): They can be defined in Docker or k8s, or any other cloud hosting primitive.
- They need the ability to start quickly, check out repos, install your toolchain, build and run your app
- They should be pausable, resumable, and allow for moving state across machines
[Computer and browser use](https://docs.warp.dev/agents/capabilities/computer-use/): You should be able to hook up computer use models to test the apps that are built by agents in your remote dev envs. This is useful for reproduction, verification and prototyping.
Multi-platform support: Depending on your app requirements, you may want runner capabilities across Linux, Mac and Windows. This matters most for folks building native and mobile apps, not just browser apps.
If you are evaluating factory infra providers, you should make sure that compute is [self-hostable](https://docs.warp.dev/platform/self-hosting/).
## Inference
The Inference Layer should support running any model and any agent so that you can evolve and test your factory configuration to optimize quality, cost and speed. It also prevents lock-in and any single model provider having pricing power over your org over time, and insulates you against risks of just having one model source (e.g. regulation, etc.).
It should support frontier and open-weight models and multiple agent harnesses so you can test their quality.
E.g. you should have at least one harness that supports open-weight models like [Warp Agent](https://docs.warp.dev/platform/harnesses/) or OpenCode, plus the ability to run the main model harnesses from the model labs directly, like Claude Code and Codex.
It also should support different inference sources, including connecting to APIs…
- From external providers like the model labs (e.g. OpenAI, Anthropic, xAI)
- From neo-clouds serving open-weight models (e.g. Baseten, Fireworks)
- From hyperscaler hosting like AWS Bedrock and GCP Vertex
- From self-hosted fine-tuned models
Finally, it should support tune-able model routing, so that as you measure and benchmark your factory, you can change the model and harness mix to optimize performance on your own workflows.
## Improvement
An important part of any software factory is the Improvement Infrastructure: what the factory provides to ensure that software gets built at higher quality and lower cost over time.
The first piece of improvement is [metrics and observability](https://docs.warp.dev/factories/factory-dashboard/). The factory should provide visibility into:
- [Cost per PR](https://docs.warp.dev/factories/measure-and-improve/)
- Automation measurements
- Cycle times
- And more…
All raw internal metrics data should be available via MCP and API so you (and your agents) can slice and dice your data to understand factory throughput.
Once you have reliable metrics, you’ll want improvement infrastructure:
- [Scorers](https://www.warp.dev/blog/engineering-self-improving-software-factories): LLM-as-a-judge or human feedback on past runs along different dimensions
- Replay: the ability to replay real factory work at its exact initial state, to test differences of configuration
- [Benchmarking](https://www.warp.dev/blog/warp-factory-benchmarks): Creating suites of test tasks with varied config to empirically test how different factory model and harness configurations perform on real work
- [Self-improvement](https://www.warp.dev/blog/agent-self-improving-software-factories): agents that automatically look for areas of potential improvement in your factory and suggest changes to factory config like model routing, skills, etc.
Note that measurable improvement is only possible if:
- Your factory stores and makes available all the data needed for improvement.
- The factory is defined as code, so you can reliably test and measure improvements. Otherwise, you are just guessing.
## Orchestration
Your factory needs a runtime. It needs:
- The ability to launch agents that do work
- Tracking across all agents that are running
- Recovery for when they fail
- A central “[control room](https://docs.warp.dev/factories/factory-dashboard/)” dashboard for showing the folks managing the factory what’s going on
Think of this as the “control plane” for your factory. It should handle things like:
- Launching agents from all integrations points
- Managing automations and crons
- Dividing work into subagents, monitoring their progress
- Allowing for steering of live agents as they run
- Allowing for [handoff of agent work from the cloud to local](https://docs.warp.dev/factories/factory-mcp/)
As mentioned above, the Orchestration Layer should support multiple agent harnesses, and present a unified interface for working with all of them and storing the data exhaust from each.
## Access
The Access Layer sits at the top of the Factory Stack.
Think of “access” in terms of how work gets in and out of the factory from external systems.
These systems are:
- External coding agents that can use a [Factory MCP](https://docs.warp.dev/factories/factory-mcp/) to talk to the factory, put work in and pull work out
- Knowledge work tools like [Slack / Teams, Jira / Linear](https://docs.warp.dev/factories/connect-your-factory/)
- Source code forges ([Github / Gitlab / Azure Devops](https://docs.warp.dev/factories/connect-your-factory/)) where you might review PRs
- Dedicated web and mobile UIs for working with the factory
All of these access points under the hood should use a [unified set of APIs](https://docs.warp.dev/reference/api-and-sdk) that allow for launching work, monitoring progress, updating the factory definition, and so on.
API-first is essential because it allows agents to debug and control the factory (with human supervision).
## Conclusion
In sum, as the world moves towards automated development, you should be thinking of your software factories as an Infrastructure Stack. Warp Factories provides an open, composable implementation of this stack.
Warp Factories is being deployed by enterprises across the Fortune 500 to help them scale development while measurably improving coding agent ROI.
If you are exploring adopting a software factory approach, [we would love to chat](https://warp.dev/factories/request-access).
## 相关链接
- [Zach Lloyd](https://x.com/zachlloydtweets)
- [@zachlloydtweets](https://x.com/zachlloydtweets)
- [15K](https://x.com/zachlloydtweets/status/2097739116720910619/analytics)
- [defined in code](https://docs.warp.dev/factories/factory-as-code/)
- [Warp Factories](https://www.warp.dev/factories)
- [Factory-as-code](https://docs.warp.dev/factories/factory-as-code/)
- [factory.yaml](https://docs.warp.dev/factories/factory-as-code/)
- [Agent config](https://docs.warp.dev/factories/factory-agents/)
- [model routing](https://docs.warp.dev/platform/harnesses/)
- [Runners](https://docs.warp.dev/platform/runners/)
- [Automations](https://docs.warp.dev/factories/automations/)
- [Integrations](https://docs.warp.dev/factories/connect-your-factory/)
- [Scorers, evals and benchmarks](https://docs.warp.dev/factories/measure-and-improve/)
- [Internal MCPs and CLIs](https://docs.warp.dev/platform/mcp/)
- [Memories](https://docs.warp.dev/agents/agent-memory/)
- [Skills and plugin marketplaces](https://docs.warp.dev/factories/factory-skills/)
- [ZDR is a must.](https://x.com/zachlloydtweets/status/2097701689340129781?s=20)
- [Remote dev environments](https://docs.warp.dev/platform/environments/)
- [Computer and browser use](https://docs.warp.dev/agents/capabilities/computer-use/)
- [self-hostable](https://docs.warp.dev/platform/self-hosting/)
- [Warp Agent](https://docs.warp.dev/platform/harnesses/)
- [metrics and observability](https://docs.warp.dev/factories/factory-dashboard/)
- [Cost per PR](https://docs.warp.dev/factories/measure-and-improve/)
- [Scorers](https://www.warp.dev/blog/engineering-self-improving-software-factories)
- [Benchmarking](https://www.warp.dev/blog/warp-factory-benchmarks)
- [Self-improvement](https://www.warp.dev/blog/agent-self-improving-software-factories)
- [control room](https://docs.warp.dev/factories/factory-dashboard/)
- [handoff of agent work from the cloud to local](https://docs.warp.dev/factories/factory-mcp/)
- [Factory MCP](https://docs.warp.dev/factories/factory-mcp/)
- [Slack / Teams, Jira / Linear](https://docs.warp.dev/factories/connect-your-factory/)
- [Github / Gitlab / Azure Devops](https://docs.warp.dev/factories/connect-your-factory/)
- [unified set of APIs](https://docs.warp.dev/reference/api-and-sdk)
- [we would love to chat](https://warp.dev/factories/request-access)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:29 AM · Sep 10, 2026](https://x.com/zachlloydtweets/status/2097739116720910619)
- [15.5K Views](https://x.com/zachlloydtweets/status/2097739116720910619/analytics)
- [View quotes](https://x.com/zachlloydtweets/status/2097739116720910619/quotes)
---
*导出时间: 2026/9/10 09:13:17*
---
## 中文翻译
# 软件工厂技术栈
**作者**: Zach Lloyd
**日期**: 2026-09-09T17:29:14.000Z
**来源**: [https://x.com/zachlloydtweets/status/2097739116720910619](https://x.com/zachlloydtweets/status/2097739116720910619)
---
软件工厂应当构建在一个开放、可组合且[以代码定义](https://docs.warp.dev/factories/factory-as-code/)的基础设施技术栈之上。
开放 == 可与任何模型、智能体和托管配置协同工作
可组合 == 你可以采用技术栈的部分或全部，并按自己的需求使用各个组件
以代码定义 == 工厂状态可版本化、可测试、可回滚
在本文中，我将阐述我们为 [Warp Factories](https://www.warp.dev/factories) 设计技术栈的方式。这些原则适用于任何希望转向工厂模式的人。
让我们逐层拆解，从基础开始，逐步向上：
## 工厂即代码
整个工厂技术栈的底层是[工厂即代码](https://docs.warp.dev/factories/factory-as-code/)的定义，从 [factory.yaml](https://docs.warp.dev/factories/factory-as-code/) 开始，包括：
- [智能体配置](https://docs.warp.dev/factories/factory-agents/)：其提示词、技能、MCP、[模型路由](https://docs.warp.dev/platform/harnesses/)配置
- [运行器](https://docs.warp.dev/platform/runners/)：工厂运行环境的信息（例如如何启动工厂智能体）
- 代码仓库：与工厂所操作的产品相对应的一组代码仓库
- [自动化](https://docs.warp.dev/factories/automations/)：驱动智能体行为的触发器和动作，如定时任务、错误监控通知、任务板状态变更、GitHub 拉取请求更新等
- [集成](https://docs.warp.dev/factories/connect-your-factory/)：工厂集成了哪些工具（如 Slack、Jira），以及用于从外部触发工厂操作的 Webhook 配置（如 Grafana 或 Sentry 告警）
- [评分器、评估和基准测试](https://docs.warp.dev/factories/measure-and-improve/)：衡量工厂质量的工具
代码的具体格式不如采用基于代码的方法重要，后者允许对工厂定义进行版本化变更。版本化开启了基准测试、A/B 测试、回滚等可能性。这相当于工厂领域的 Terraform。如果你的工厂以代码定义并具备版本化，你（或你的智能体）测试和改进起来就会容易得多。
## 数据与上下文
再往上一层是工厂的上下文层。它由以下部分组成：
- [内部 MCP 和 CLI](https://docs.warp.dev/platform/mcp/)：供工厂智能体将组织信息拉入智能体上下文的工具，以及用于管理其使用的认证和 RBAC 系统
- [记忆](https://docs.warp.dev/agents/agent-memory/)：记忆是智能体存储的学习成果（例如"这是我们关于全局常量的编码规范"），可以通过显式的用户指令或推断出的改进来获得。它们可以存储在第三方服务、向量数据库或普通文件中
- 智能体追踪：工厂智能体的所有历史运行记录（完整对话日志），以及智能体运行的元数据，如成本、耗时等。这些构成了自我改进循环的原始输入。
- 智能体遥测和访问日志：所有智能体交互和工具调用的完整审计追踪，用于安全和调试
- 代码仓库：工厂所操作的代码，以及存在于该代码中的版本化智能体技能
- [技能和插件市场](https://docs.warp.dev/factories/factory-skills/)：发现和使用内部技能的可扩展方式
上下文层应当是可插拔和可扩展的。
如果你使用第三方上下文层，你应当能够将其所有数据存储在自己的基础设施上。任何外部提供商都不应获得在这些数据上训练的权利。[ZDR 是必须的。](https://x.com/zachlloydtweets/status/2097701689340129781?s=20)
## 计算
接下来是计算层。这是你的智能体运行的地方。
在计算层中，你需要：
[远程开发环境](https://docs.warp.dev/platform/environments/)：可以用 Docker 或 k8s 定义，也可以用任何其他云托管原语。
- 它们需要能够快速启动、检出代码仓库、安装你的工具链、构建并运行你的应用
- 它们应当可暂停、可恢复，并允许跨机器迁移状态
[计算机和浏览器使用](https://docs.warp.dev/agents/capabilities/computer-use/)：你应当能够接入计算机使用模型，以测试智能体在远程开发环境中构建的应用。这对于复现、验证和原型设计非常有用。
多平台支持：根据你的应用需求，你可能需要跨 Linux、Mac 和 Windows 的运行器能力。这对于构建原生和移动应用（而不仅仅是浏览器应用）的人来说最为重要。
如果你正在评估工厂基础设施提供商，你应当确保计算是[可自托管](https://docs.warp.dev/platform/self-hosting/)的。
## 推理
推理层应当支持运行任何模型和任何智能体，以便你能够演进和测试工厂配置，从而优化质量、成本和速度。它还能防止锁定，防止任何单一模型提供商随时间推移对你的组织拥有定价权，并使你免受仅依赖单一模型来源的风险（例如监管等）。
它应当支持前沿模型和开放权重模型，以及多种智能体框架，以便你测试它们的质量。
例如，你应当至少有一个支持开放权重模型的框架，如 [Warp Agent](https://docs.warp.dev/platform/harnesses/) 或 OpenCode，同时具备直接运行模型实验室主要模型框架的能力，如 Claude Code 和 Codex。
它还应当支持不同的推理来源，包括连接以下 API……
- 来自外部提供商，如模型实验室（例如 OpenAI、Anthropic、xAI）
- 来自提供开放权重模型的新型云服务商（例如 Baseten、Fireworks）
- 来自超大规模托管服务，如 AWS Bedrock 和 GCP Vertex
- 来自自托管的微调模型
最后，它应当支持可调节的模型路由，这样当你测量和基准测试工厂时，可以更改模型和框架组合，以针对自己的工作流优化性能。
## 改进
任何软件工厂的一个重要组成部分是改进基础设施：工厂提供什么来确保软件随时间推移以更高质量和更低成本构建。
改进的第一部分是[指标和可观测性](https://docs.warp.dev/factories/factory-dashboard/)。工厂应当提供以下方面的可见性：
- [每个 PR 的成本](https://docs.warp.dev/factories/measure-and-improve/)
- 自动化测量
- 周期时间
- 以及更多……
所有原始内部指标数据应当通过 MCP 和 API 提供，以便你（和你的智能体）可以切分和分析数据，了解工厂吞吐量。
一旦你有了可靠的指标，你就会需要改进基础设施：
- [评分器](https://www.warp.dev/blog/engineering-self-improving-software-factories)：基于 LLM 的评判或人工对历史运行在不同维度上的反馈
- 回放：在精确的初始状态下回放真实工厂工作的能力，以测试配置差异
- [基准测试](https://www.warp.dev/blog/warp-factory-benchmarks)：创建具有不同配置的测试任务套件，以实证方式测试不同工厂模型和框架配置在真实工作上的表现
- [自我改进](https://www.warp.dev/blog/agent-self-improving-software-factories)：自动寻找工厂中潜在改进领域并建议更改工厂配置（如模型路由、技能等）的智能体
请注意，可衡量的改进只有在以下条件下才可能实现：
- 你的工厂存储并提供改进所需的所有数据。
- 工厂以代码定义，这样你才能可靠地测试和衡量改进。否则，你只是在猜测。
## 编排
你的工厂需要一个运行时。它需要：
- 启动执行工作的智能体的能力
- 对所有运行中智能体的追踪
- 失败时的恢复机制
- 一个中央"[控制室](https://docs.warp.dev/factories/factory-dashboard/)"仪表板，向管理工厂的人员展示正在发生的情况
可以将其视为工厂的"控制平面"。它应当处理以下事项：
- 从所有集成点启动智能体
- 管理自动化和定时任务
- 将工作分解为子智能体，监控其进度
- 允许在智能体运行时对其进行引导
- 允许[将智能体工作从云端移交到本地](https://docs.warp.dev/factories/factory-mcp/)
如上所述，编排层应当支持多种智能体框架，并提供统一接口来使用所有框架并存储每个框架产生的数据。
## 访问
访问层位于工厂技术栈的顶部。
从工作如何从外部系统进出工厂的角度来理解"访问"。
这些系统包括：
- 外部编码智能体，可以使用 [Factory MCP](https://docs.warp.dev/factories/factory-mcp/) 与工厂通信，提交和获取工作
- 知识工作工具，如 [Slack / Teams、Jira / Linear](https://docs.warp.dev/factories/connect-your-factory/)
- 源代码托管平台（[Github / Gitlab / Azure Devops](https://docs.warp.dev/factories/connect-your-factory/)），你可以在其中审查 PR
- 用于与工厂协作的专用 Web 和移动 UI
所有这些访问点在底层都应当使用[统一的 API 集](https://docs.warp.dev/reference/api-and-sdk)，允许启动工作、监控进度、更新工厂定义等。
API 优先至关重要，因为它允许智能体（在人工监督下）调试和控制工厂。
## 结论
总之，随着世界迈向自动化开发，你应当将软件工厂视为一个基础设施技术栈。Warp Factories 提供了这一技术栈的开放、可组合实现。
Warp Factories 正在被财富 500 强企业部署，帮助他们扩展开发规模，同时可衡量地提升编码智能体的投资回报率。
如果你正在探索采用软件工厂方法，[我们很乐意交流](https://warp.dev/factories/request-access)。
## 相关链接
- [Zach Lloyd](https://x.com/zachlloydtweets)
- [@zachlloydtweets](https://x.com/zachlloydtweets)
- [15K](https://x.com/zachlloydtweets/status/2097739116720910619/analytics)
- [以代码定义](https://docs.warp.dev/factories/factory-as-code/)
- [Warp Factories](https://www.warp.dev/factories)
- [工厂即代码](https://docs.warp.dev/factories/factory-as-code/)
- [factory.yaml](https://docs.warp.dev/factories/factory-as-code/)
- [智能体配置](https://docs.warp.dev/factories/factory-agents/)
- [模型路由](https://docs.warp.dev/platform/harnesses/)
- [运行器](https://docs.warp.dev/platform/runners/)
- [自动化](https://docs.warp.dev/factories/automations/)
- [集成](https://docs.warp.dev/factories/connect-your-factory/)
- [评分器、评估和基准测试](https://docs.warp.dev/factories/measure-and-improve/)
- [内部 MCP 和 CLI](https://docs.warp.dev/platform/mcp/)
- [记忆](https://docs.warp.dev/agents/agent-memory/)
- [技能和插件市场](https://docs.warp.dev/factories/factory-skills/)
- [ZDR 是必须的。](https://x.com/zachlloydtweets/status/2097701689340129781?s=20)
- [远程开发环境](https://docs.warp.dev/platform/environments/)
- [计算机和浏览器使用](https://docs.warp.dev/agents/capabilities/computer-use/)
- [可自托管](https://docs.warp.dev/platform/self-hosting/)
- [Warp Agent](https://docs.warp.dev/platform/harnesses/)
- [指标和可观测性](https://docs.warp.dev/factories/factory-dashboard/)
- [每个 PR 的成本](https://docs.warp.dev/factories/measure-and-improve/)
- [评分器](https://www.warp.dev/blog/engineering-self-improving-software-factories)
- [基准测试](https://www.warp.dev/blog/warp-factory-benchmarks)
- [自我改进](https://www.warp.dev/blog/agent-self-improving-software-factories)
- [控制室](https://docs.warp.dev/factories/factory-dashboard/)
- [将智能体工作从云端移交到本地](https://docs.warp.dev/factories/factory-mcp/)
- [Factory MCP](https://docs.warp.dev/factories/factory-mcp/)
- [Slack / Teams、Jira / Linear](https://docs.warp.dev/factories/connect-your-factory/)
- [Github / Gitlab / Azure Devops](https://docs.warp.dev/factories/connect-your-factory/)
- [统一的 API 集](https://docs.warp.dev/reference/api-and-sdk)
- [我们很乐意交流](https://warp.dev/factories/request-access)
- [升级到 Premium](https://x.com/i/premium_sign_up)
- [1:29 AM · Sep 10, 2026](https://x.com/zachlloydtweets/status/2097739116720910619)
- [15.5K 次浏览](https://x.com/zachlloydtweets/status/2097739116720910619/analytics)
- [查看引用](https://x.com/zachlloydtweets/status/2097739116720910619/quotes)
---
*导出时间: 2026/9/10 09:13:17* 
