# The guide to software factories
**作者**: Zach Lloyd
**日期**: 2026-07-14T15:44:40.000Z
**来源**: [https://x.com/zachlloydtweets/status/2077056692987027758](https://x.com/zachlloydtweets/status/2077056692987027758)
---
Software development is about to undergo yet another major change: the shift from interactive coding agents to cloud software factories. These factories are systems that automate major parts of the SDLC. They minimize human variability and maximize software output, while improving security and compliance. They allow organizations to directly measure the ROI and business value of coding agents and improve them over time. In short, factories fix the shortcomings of the current interactive agents, which tend to be expensive, hard to tie to ROI, and difficult to govern.
This document gives an overview of cloud software factories for engineering leaders: what they are, why they matter, a tour of the key components, and how to deploy them in your organization.
## Preface
Every C-suite executive is thinking about how to make their organizations agentic and make AI actually deliver business value. For software development, they want to: measurably increase velocity, deliver value to customers, and stay at the forefront of the market, all while maintaining a reasonable cost to ship (cost being humans + tokens).
Initially, there was a rush to put AI tools in the hands of every developer - first Copilot, then Cursor, then Claude Code. Organizations created leaderboards to celebrate token consumption. They tracked tool adoption to encourage usage. This made sense, given the power of a novel technology coming to the market and needing teams to try it.
Now I hear over and over again that every engineer is using interactive coding agents; but it’s still murky if the cost of tokens plus humans has real ROI. On top of that, the sprawl of these tools is a nightmare to control and govern.
You could try to layer controls over the current interactive toolset, but there’s a better solution: the cloud software factory.
## Introducing cloud software factories
For folks who aren’t familiar with the “factory” framing, a cloud software factory is just an automation around the core loop of development, from triage → spec → implement → review → verify → ship → monitor, where at every step a mix of agents and humans moves the process forward.
Cloud factories are becoming increasingly popular (they are a variant of an agentic “loop”), so much so that one of the main tracks at the mainstage of the AI Engineer World Fair was dedicated entirely to factory engineering.
Here are two reasons they are catching on: First, agents have recently become good enough that true automation is possible. That is, rather than having a human interactively use a coding agent like Claude Code or Codex in their terminal or desktop, it’s now possible for agents to automatically do some subset of engineering work on their own, all the way from issue to shipping.
An agent can triage an issue, come up with a proposal, implement a fix, verify it, ship it, and monitor it all on its own. Of course, this isn’t possible yet for all issues, but it doesn’t need to be in order to be valuable. What matters is that it’s possible for some issues, and that over time the percentage of issues feasible to address this way rises. Today about 20-30% of issues fall into this bucket, but this will rapidly increase in the next year. Even for the 70% of issues that aren’t fully automatable today, most of them are semi-automatable; the factory can do important parts of the SDLC like review, verification and monitoring.
The second reason is that extensive interactive agent use has created a number of problems that I’m hearing from engineering leaders again and again, from cost controls to governance to security. The root problem is that interactive agents have human operators, and those humans all use them in very different ways, which don’t always maximize business value and can create risk.
For instance, it’s easy for a human to always use the most expensive model, even when they don’t need to, for a given task. Or for a human to inadvertently create a security issue by installing MCPs that have too much access. Or for different humans to have different skill levels in prompting agents.
As I noted in the beginning of this article, the idea behind a factory approach is to set up a system that minimizes human variability and maximizes output, with controls that ensure security and compliance. It creates a system where you can measure the ROI of agents and tie them to business value.
You can also address these issues with non-factory approaches by trying to standardize every developer’s local setup, but in reality it’s much easier and more effective to create control by moving all development to a centralized cloud factory. Cloud factories should not be thought of as adding another tool that developers have to learn – rather, they work with existing tools and infra, stitching them together into automations. There’s a very similar logic here to the rise of the cloud 20 years ago – when you centralize in the cloud, you get control, standardization, visibility, and so on. Cloud Factories are the SaaSified version of interactive agents.
## The cloud factory workflow
Think of a cloud factory as an automation loop around the SDLC, with the following steps where agents do most of the work, and humans guide as necessary:
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 issueIf 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 runsHuman 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
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
This is the basic flow, but you can imagine variations – the point is just that a factory is an automation loop on top of the SDLC.
## The components of a cloud software factory
Cloud software factories are infrastructure, similar to CI/CD. As such, they have a few core components that you will want to set up, either by building them directly or partnering with a vendor (more on this below).
Cloud runtimes and sandboxes
Layer 1: cloud host, runtime/sandbox, and coding agent
In order to automate the SDLC, the first step is moving agents off of developers’ laptops. You can’t create reliable automations around machines that might be asleep or turned off, and you want to standardize the environment where agents run, so individual laptops are not suitable.
Typical solutions are
1. Run an agent in an existing cloud development environment if your team has this set up
2. Dockerize your environment and run it on a docker host
3. Use Kubernetes or another cloud orchestration platform to run your environments
In addition to needing an environment, you’ll also need a host, which is just a computer to run the environment in. This could be in AWS, GCS, or a hosting platform built specifically for agents like Modal or Daytona. It could be in a public cloud, or, for most enterprises, on your own infrastructure.
Within this runtime, you’ll also want to have a coding agent like Claude Code, Codex, Cursor, OpenCode, Warp or another harness that is able to make changes to the codebase.
For the coding agent to work well, it will also need access to the tools that coding agents rely on, like MCP, other CLIs perhaps, and likely an integration with your source code forge (e.g. Github or Gitlab). Typical MCPs might be for your task tracking system (e.g. Jira), your communication system (e.g. Slack or Teams). You’ll need a system for managing who the agent acts as – agent authentication – and what access the agent has – agent authorization. You can see how this starts to get complex.
Orchestration layer
Layer 2: orchestration, integrations, multi-harnesses, and human-in-the-loop
Once you have a place to run agents in the cloud, you need a system that actually launches those agents in response to a trigger. Triggers could be direct from a human (e.g. a user sends a slack message or opens a new ticket), or they could be more automated (e.g. a schedule).
For software factories in particular, there is a specific workflow around the SDLC that you probably want to implement that looks like triage → spec → implement → review → verify → ship → monitor, as I described above. But you’ll want to build your system so that the workflows it executes are actually more flexible. For instance, you may want to add an agent that does canarying or one that does dead code cleanup, and so on. The orchestrator should be flexible enough to handle custom agents and custom workflows.
This orchestration layer also should give you a global view of all agents, both active and historical, and what stage every issue is at. It should provide a way of seeing the state of every agent, including actually joining an agent session in case a human needs to interact and steer a running agent. Think of this as your factory control room – it’s where you go to see how the factory is running, what the bottlenecks are, what needs attention, and so on.
Work moving through a cloud software factory
Integrations
If you’re building a factory, the best way to interface with it is where work is already happening, rather than adding a new destination. Your team is already putting ideas and issues into Slack and Teams; those ideas are often things that ought to go directly into the factory. They are opening issues in Jira and Linear. They are responding to customer emails, using support tools, and so on. They are using terminals and IDEs on their desktops and responding to PR comments in Github and Gitlab. A factory should accept input from any source and be able to communicate with developers where they already are.
For this to work well, a factory needs to support integrations into the most common tools. These integrations should support adding work items to the factory, checking on their status, and, crucially, changing the operation of the factory itself. E.g. If someone notices a code review agent giving advice that doesn’t match the conventions of the repo, they should be able to instruct the agent directly in the code review tool how to adjust its behavior in the future.
Human-in-the-loop
Not all development is automatable. Currently the Warp team automates 20-30% of all PRs. Some complex tasks are better done interactively right now. Sometimes agents will get stuck and work needs to move from the cloud to a local workbench. Sometimes you want to directly test an agent's output and not rely on automated verification.
For this to work well, you need a few primitives in your factory:
1. Steering: the ability to join a live session and iterate with an agent
2. Handoff: the ability to transfer an agent session and associated context from the cloud to local and back
3. Notifications: the ability for an agent to notify a human that it needs help
These primitives are not trivial to build but are very important if you want developers to adopt a factory workflow; without them work gets stuck or done incorrectly and the factory creates friction.
Multi-harness and multi-model
The best agent today is not the best agent tomorrow. The landscape changes weekly, and you’ll want to build your factory in such a way that it’s able to use the agent and model that gives the best cost/quality/speed tradeoff down the road.
This means harness flexibility: whether to run Claude Code, Codex, Cursor, OpenCode, Warp, etc. at the harness layer, and possibly mix and match harnesses across tasks.
It also means model routing: within a given harness, is it using the right model for the task, where “right” means the least expensive, fastest model that meets the required quality bar. You might want to use open weight or frontier, and have routing even within a given task, to optimize for cost and quality.
Adding support for multiple harnesses creates more complexity, but provides you with the most flexibility going forward. Anchoring on a single harness or model is high-risk from a cost-control perspective (you get locked in from a model vendor), an availability perspective (model providers are struggling to even get two nines of reliability), and a geo-political risk perspective (e.g. export controls).
Measurement, evals and continual improvement
Layer 3: metrics and memory on top of the full factory stack
The promise of the factory approach is that it creates the foundation for measuring and improving the ROI of software development over time. This only works though if you measure your factory throughput and efficiency, where
factory efficiency = (shipped product) / (token cost).
In order to measure, you must first do all the above, centralizing and standardizing in the cloud. But once you’ve done that, you can start to approach software development more like COGS than R&D, and tune your factory over time.
To tune the factory and improve efficiency, you need evals and experiments, which allow you to benchmark and test different inputs into the factory and see how they impact the output. Typical inputs to test are model and harness mix, MCP and Skill availability and contents, and so on – anything that might impact how the agents work.
You also will want self-improvement loops: think of these as agents that observe how the factory is functioning and suggest improvements to make it work better. E.g. Can your factory become more cost efficient in how it triages issues? Can it become better at computer use to verify fixes?
Finally, you’ll want memory, a way of agents learning from interactions and prior conversations. This memory should be explicit – supporting instructions like “remember that we always use terraform for infra changes”-- and implicit, where the agent itself extracts relevant information from interactions and resurfaces it into context at the right time. You will want to make sure that your company owns and stores this memory, otherwise it’s a big lock-in risk.
## Factory-as-code
The best technical approach to setting up a factory is through code. After all, it’s infrastructure, and we have learned that there are benefits to defining infra-as-code over the years. That means all of your factory config should be defined in files and be version controlled. This has the added benefit that coding agents themselves can act on these files to update them.
## Build vs. buy
For most companies, it doesn’t make sense to build all this factory infrastructure. There’s a ton to develop and maintain over time, and all the effort of building and maintenance takes away from your team’s core focus on solving customer problems.
The exception is if you are truly a large software organization (think Stripe or Uber). Then, building might make sense because the factory needs to be very tightly tied to existing complex developer infrastructure.
You may find that folks on your engineering team want to build this infrastructure, and even that they can build a prototype of it quickly. This is indeed possible, but not recommended, because there is an explosion of complexity in going from the 20% of a demo to the 100% of a fully implemented system. Most companies should not be building custom CI/CD infrastructure (e.g. Github Actions), so you probably should not be building custom factory infra either.
Instead, most companies should look to partner with a vendor that provides the infrastructure for you. This is what Warp does: working closely with companies that want to start down the automation path and set up a solid foundation for their internal factories. If not Warp, there are other vendors with solid solutions as well, although none are as flexible.
If you do partner with a vendor, you should be on the lookout for various flags:
1. Single model or single harness: this is a form of lock-in that will make it harder for your factory to improve over time and give the model provider leverage over prices.
2. Data ownership: make sure that whatever vendor you use doesn’t capture or train on your factory data. All the data flowing through the factory should be owned and housed by your company.
3. Compute inflexibility: you probably want a variety of different hosting solutions, including self-hosting.
4. Forced token reselling: vendors should allow you to bring your own inference endpoints (e.g. Bedrock, Vertex and Azure) and generally not be in the business of selling or re-selling tokens. Folks in the token selling business are going to have a conflict of interest when it comes to optimizing your costs, so it’s better to pick a vendor that is agnostic to whether you buy inference through them.
If you are looking for more info on how to stand up your own cloud factory, we’d be excited to explore this with you – you can set up time for an initial chat here, or explore setting up a factory yourself here.
Illustrations by Dan Roam.
## 相关链接
- [Zach Lloyd](https://x.com/zachlloydtweets)
- [@zachlloydtweets](https://x.com/zachlloydtweets)
- [14K](https://x.com/zachlloydtweets/status/2077056692987027758/analytics)
- [was dedicated entirely to factory engineering](https://www.ai.engineer/worldsfair/schedule?track=Software+Factories)
- [Dan Roam](https://www.linkedin.com/in/danroam/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [11:44 PM · Jul 14, 2026](https://x.com/zachlloydtweets/status/2077056692987027758)
- [14.9K Views](https://x.com/zachlloydtweets/status/2077056692987027758/analytics)
- [View quotes](https://x.com/zachlloydtweets/status/2077056692987027758/quotes)
---
*导出时间: 2026/7/15 11:30:25*
---
## 中文翻译
# 软件工厂指南
**作者**: Zach Lloyd
**日期**: 2026-07-14T15:44:40.000Z
**来源**: [https://x.com/zachlloydtweets/status/2077056692987027758](https://x.com/zachlloydtweets/status/2077056692987027758)
---
软件开发即将经历又一次重大变革：从交互式编码代理转向云软件工厂。这些工厂是自动化软件开发生命周期（SDLC）主要部分的系统。它们最大限度地减少了人为差异，最大化了软件产出，同时提高了安全性和合规性。它们使组织能够直接衡量编码代理的投资回报率（ROI）和商业价值，并随时间推移对其进行改进。简而言之，工厂解决了当前交互式代理的缺陷，这些代理往往成本高昂、难以与 ROI 挂钩且难以治理。
本文档为工程负责人概述了云软件工厂：它们是什么、为何重要、关键组件导览，以及如何在您的组织中部署它们。
## 前言
每位高管都在思考如何让他们的组织实现“代理化”，并让 AI 真正交付商业价值。对于软件开发而言，他们希望：显著提高速度、向客户交付价值、并保持市场前沿地位，同时维持合理的交付成本（成本 = 人力 + Token）。
最初，出现了一股将 AI 工具交到每位开发者手中的热潮——先是 Copilot，然后是 Cursor，接着是 Claude Code。各组织制作排行榜来庆祝 Token 的消耗量。他们追踪工具采用情况以鼓励使用。鉴于这项新技术进入市场所具有的威力，以及团队试用它的需求，这是合理的。
现在我一次又一次地听到，每位工程师都在使用交互式编码代理；但 Token 加上人力的成本是否具有真正的 ROI 仍然模糊不清。此外，这些工具的泛滥简直是一场管控和治理的噩梦。
您可以尝试在当前的交互式工具集之上叠加管控，但有一个更好的解决方案：云软件工厂。
## 云软件工厂简介
对于不熟悉“工厂”这一概念的人来说，云软件工厂只是围绕开发核心循环的自动化系统，从分类 → 规格制定 → 实施 → 评审 → 验证 → 发布 → 监控，在每一步，代理和人类的混合组合推动流程向前发展。
云工厂正变得越来越受欢迎（它们是代理式“循环”的一种变体），以至于在 AI 工程师世界博览会的主舞台上，其中一个主要赛道完全致力于工厂工程。
它们之所以流行，有两个原因：首先，代理最近已经变得足够好，使得真正的自动化成为可能。也就是说，不再是人类在终端或桌面上交互式地使用像 Claude Code 或 Codex 这样的编码代理，现在代理可以自动地独立完成工程工作的某些子集，从问题一直到发布。
代理可以分类问题、提出提案、实施修复、验证它、发布它并自行监控。当然，这对所有问题来说还不可能，但这并不妨碍其产生价值。重要的是这对某些问题是可能的，并且随着时间的推移，可以通过这种方式解决的问题百分比会上升。今天大约有 20-30% 的问题属于这一类，但这将在明年迅速增加。即使对于目前无法完全自动化的 70% 的问题，其中大多数也是半自动化的；工厂可以完成 SDLC 的重要部分，如评审、验证和监控。
第二个原因是，广泛的交互式代理使用造成了许多问题，我从工程负责人那里反复听到这些问题，从成本控制到治理再到安全。根本问题是交互式代理有人类操作员，而这些人类以非常不同的方式使用它们，这并不总是能最大化商业价值，并可能产生风险。
例如，对于给定的任务，人类很容易总是使用最昂贵的模型，即使他们并不需要。或者，人类可能通过安装权限过大的 MCP 而无意中造成安全问题。或者，不同的人类在提示代理方面的技能水平不同。
正如我在本文开头提到的，工厂方法背后的理念是建立一个系统，最大限度地减少人为差异并最大化产出，并通过确保安全性和合规性的控制措施来实现。它创建了一个系统，您可以衡量代理的 ROI 并将其与商业价值联系起来。
您也可以通过尝试标准化每个开发者的本地环境，采用非工厂方法来解决这些问题，但实际上，通过将所有开发转移到集中的云工厂来创建控制要容易和有效得多。云工厂不应被视为开发者必须学习的另一个工具——相反，它们与现有工具和基础设施配合工作，将它们缝合在一起形成自动化。这里的逻辑与 20 年前云的兴起非常相似——当您在云端集中管理时，您会获得控制、标准化、可见性等。云工厂是交互式代理的 SaaS 化版本。
## 云工厂工作流
将云工厂视为围绕 SDLC 的自动化循环，包含以下步骤，其中代理完成大部分工作，人类在必要时进行指导：
1. 新问题进入系统，要么来自人类，要么来自监控代理
2. 分类代理运行并尝试理解和重现问题
- 如果它确定任务是可自动化的 → 将其移交给实施代理
- 如果由于范围需要规格说明 → 让规格代理与人类迭代以制定规格
- 如果它不明确 → 获取人类输入并重新运行，或者只是决定暂时搁置该问题
3. [如有必要] 规格代理运行。人类审查规格，然后传递给实施代理
4. 实施代理编写代码
5. 代码评审代理审查代码
6. 验证代理进行计算机使用或其他验证
7. 人类审查代码和验证输出。如有必要，返回步骤 2、3、4 或 5
8. CI / CD
9. 发布
10. 监控代理运行并在需要时创建问题，完成循环
这是基本流程，但您可以想象各种变体——要点是工厂是建立在 SDLC 之上的自动化循环。
## 云软件工厂的组件
云软件工厂是基础设施，类似于 CI/CD。因此，它们有几个核心组件，您需要通过直接构建或与供应商合作来设置（更多内容见下文）。
云运行时和沙箱
第 1 层：云主机、运行时/沙箱和编码代理
为了自动化 SDLC，第一步是将代理移出开发者的笔记本电脑。您无法围绕可能休眠或关机的机器创建可靠的自动化，并且您希望标准化代理运行的环境，因此个人笔记本电脑是不合适的。
典型的解决方案有：
1. 如果您的团队已经设置，请在现有的云开发环境中运行代理
2. 将您的环境 Docker 化并在 docker 主机上运行
3. 使用 Kubernetes 或其他云编排平台来运行您的环境
除了需要环境之外，您还需要一个主机，它只是一台运行环境的计算机。这可能在 AWS、GCS 中，也可能在专门为代理构建的托管平台上，如 Modal 或 Daytona。它可能在公有云中，或者对于大多数企业来说，在您自己的基础设施上。
在此运行时中，您还需要一个编码代理，如 Claude Code、Codex、Cursor、OpenCode、Warp 或其他能够更改代码库的工具。
为了使编码代理良好工作，它还需要访问编码代理依赖的工具，如 MCP、可能还有其他 CLI，以及可能与您的源代码管理系统（例如 Github 或 Gitlab）的集成。典型的 MCP 可能针对您的任务跟踪系统（例如 Jira）、您的通信系统（例如 Slack 或 Teams）。您需要一个系统来管理代理充当谁——代理身份验证——以及代理拥有什么访问权限——代理授权。您可以看到这开始变得多么复杂。
编排层
第 2 层：编排、集成、多工具集成和人在回路
一旦您有在云中运行代理的地方，您就需要一个系统，实际上响应触发器启动那些代理。触发器可能直接来自人类（例如，用户发送 slack 消息或打开新工单），或者它们可能更加自动化（例如，计划）。
特别是对于软件工厂，您可能希望实现一个围绕 SDLC 的特定工作流，正如我上面描述的分类 → 规格制定 → 实施 → 评审 → 验证 → 发布 → 监控。但是您希望构建您的系统，使其执行的工作流实际上更加灵活。例如，您可能想要添加一个执行金丝雀发布的代理，或者一个执行死代码清理的代理，等等。编排器应该足够灵活以处理自定义代理和自定义工作流。
这个编排层还应该为您提供所有代理的全局视图，包括活动的和历史的，以及每个问题处于什么阶段。它应该提供一种查看每个代理状态的方法，包括实际加入代理会话，以防人类需要交互和引导正在运行的代理。将其视为您的工厂控制室——您去那里查看工厂的运行情况、瓶颈在哪里、需要注意什么等等。
工作在云软件工厂中流转
集成
如果您正在构建工厂，与其添加一个新的目的地，不如在已经进行工作的地方与其交互，这是最好的方式。您的团队已经将想法和问题放入 Slack 和 Teams；这些想法通常应该直接进入工厂。他们在 Jira 和 Linear 中打开问题。他们正在回复客户电子邮件，使用支持工具等等。他们在桌面上的终端和 IDE 中工作，并在 Github 和 Gitlab 中回复 PR 评论。工厂应该接受来自任何来源的输入，并能够在开发者已经在的地方与他们交流。
为了使其良好工作，工厂需要支持对最常用工具的集成。这些集成应该支持将工作项添加到工厂，检查其状态，并且至关重要的是，改变工厂本身的操作。例如，如果有人注意到代码评审代理给出了不符合仓库约定的建议，他们应该能够直接在代码评审工具中指示代理未来如何调整其行为。
人在回路
并非所有开发都是可自动化的。目前，Warp 团队自动化了 20-30% 的所有 PR。一些复杂的任务目前最好以交互方式完成。有时代理会卡住，工作需要从云转移到本地工作台。有时您想直接测试代理的输出而不依赖自动验证。
为了使其良好工作，您需要在工厂中具备一些基本要素：
1. 引导：加入实时会话并与代理迭代的能力
2. 移交：将代理会话和相关上下文从云转移到本地再返回的能力
3. 通知：代理通知人类它需要帮助的能力
这些基本要素构建起来并非易事，但如果您希望开发者采用工厂工作流，它们非常重要；没有它们，工作会被卡住或完成错误，并且工厂会产生摩擦。
多工具集成和多模型
今天最好的代理并不是明天最好的代理。格局每周都在变化，您需要以这样的方式构建工厂，使其能够使用在未来提供最佳成本/质量/速度权衡的代理和模型。
这意味着工具集成的灵活性：是在工具集成层运行 Claude Code、Codex、Cursor、OpenCode、Warp 等，并可能跨任务混合匹配工具集成。
这也意味着模型路由：在给定的工具集成中，它是否使用适合任务的模型，其中“适合”意味着满足所需质量门槛的最便宜、最快的模型。您可能想要使用开源权重或前沿模型，甚至在一个任务内进行路由，以优化成本和质量。
添加对多个工具集成的支持会增加更多复杂性，但为您提供未来最大的灵活性。从成本控制的角度（您会被模型供应商锁定）、可用性的角度（模型提供商甚至难以达到两个九的可靠性）以及地缘政治风险的角度（例如出口管制）来看，将锚点固定在单个工具集成或模型上是高风险的。
衡量、评估和持续改进
第 3 层：整个工厂堆栈之上的指标和记忆
工厂方法的承诺是，它为随着时间的推移衡量和改进软件开发的 ROI 创造了基础。但这只有在你衡量工厂吞吐量和效率时才有效，其中
工厂效率 =（已发布产品）/（Token 成本）。
为了进行衡量，您必须首先完成上述所有工作，在云端进行集中化和标准化。但是一旦您完成了这些，您就可以开始更多地像销货成本（COGS）而不是研发（R&D）那样处理软件开发，并随时间调整您的工厂。
要调整工厂并提高效率，您需要评估和实验，这使您能够对工厂的不同输入进行基准测试和测试，并看看它们如何影响输出。典型的测试输入是模型和工具集成的组合、MCP 和技能的可用性及内容等等——任何可能影响代理工作的因素。
您还将需要自我改进循环：将这些视为观察工厂如何运作并建议改进以使其更好地工作的代理。例如，您的工厂能否在分类问题方面变得更加成本高效？它能否在计算机使用方面变得更好以验证修复？
最后，您需要记忆，即代理从交互和先前对话中学习的方式。这种记忆应该是显式的——支持诸如“记住我们总是使用 terraform 进行基础设施更改”之类的指令——以及隐式的，代理本身从交互中提取相关信息并在适当的时候重新浮现在上下文中。您需要确保您的公司拥有并存储此记忆，否则这是一个巨大的锁定风险。
## 工厂即代码
设置工厂的最佳技术方法是通过代码。毕竟，它是基础设施，多年来我们了解到定义基础设施即代码是有好处的。这意味着您的所有工厂配置都应该在文件中定义并进行版本控制。这有一个额外的好处，即编码代理本身可以对这些文件进行操作以更新它们。
## 自建与购买
对于大多数公司来说，构建所有这些工厂基础设施是没有意义的。随着时间的推移，有大量的开发和维护工作，所有构建和维护的工作都会使您的团队偏离解决客户问题的核心重点。
例外情况是如果您确实是一个大型软件组织（想想 Stripe 或 Uber）。那么，构建可能是有意义的，因为工厂需要与现有的复杂开发者基础设施非常紧密地结合。
您可能会发现工程团队中的人想要构建这个基础设施，甚至他们可以快速构建一个原型。这确实是可能的，但不是……