用自我改进的云软件工厂闭环
用代码定义、云端运行、API驱动、内置指标与自我改进循环的软件工厂，让编码智能体基于自身数据持续优化，而非靠直觉配置。
是时候以真正的工程思维来部署编码智能体了。关于哪种智能体最佳、该用哪些模型，以及如何长期优化编码智能体的投资回报率，目前有太多空泛之谈。解决方案是在云端建立一个闭环系统，让所有智能体都根据你自己的数据和流程被追踪和衡量，从而基于实际数据而非直觉来调整你的配置。
支撑这一思路的新兴基础设施类别，便是云端软件工厂。软件工厂是围绕软件开发生命周期的自动化闭环，由负责分类、规格制定、实现、验证、审查、监控等任务的智能体组成。若构建得当，这些工厂能实现真正的度量、持续改进和自动化，并有助于证明你正以正确的方式践行智能体工程。
然而，并非所有工厂基础设施都同等出色。在评估选项时，你应当关注以下几点：
- 工厂应以代码形式定义、纳入版本控制，且其定义可由智能体编辑。
- 工厂必须部署在云端，以支持团队访问、集中数据存储和自动化。
- 工厂的运行时应以 API 驱动，而非以 UI 为先。
- 工厂应内置评估、改进循环和基准测试，以确保长期持续改进。
- 工厂应天然支持多模型和多智能体，以便充分利用模型及框架的进步。
这些原则无论你是从零构建，还是基于诸如 Warp Factories 这样的基础设施来构建，都同样适用。如果你对工厂还不熟悉，这份指南可以帮助你入门。
你们组织的目标是打造一个闭环工厂：一个集成了所有数据、可观测性和改进功能的工厂，使得智能体（以及人类）能够利用这些数据不断优化工厂。
工厂即代码
将工厂定义为代码至关重要。以代码形式定义工厂意味着整个自动化开发系统有一个明确、全面的定义，它存在于版本控制的文件中。这类似于其他基础设施即代码平台，如Terraform。
在Warp Factories中，我们通过一个factory.yaml文件，以及一个包含所有依赖的智能体定义、技能、MCP、模型路由规则等的目录层级来实现这一点。可以把factory.yaml视为工厂应用的清单。
将工厂定义为代码，你立即能获得以下好处：
- 你有了一个基准，可以随时衡量工厂的性能。你可以观察到诸如“在此工厂配置下，我们以每个PR Y成本合并了X%的智能体PR”、“我们跨Z个模型进行路由，技能内容如此这般”等信息。
- 因为工厂定义是代码，你可以对其进行版本控制，获得回滚、分支、变更审批、历史记录等功能。你的工厂变得可实例化、可测试。
- 关键在于，将工厂定义为代码使得智能体能够轻松提出差异建议。这是自我改进的基础：智能体观察工厂的运行情况，并对底层模型、技能等提出修改建议。
工厂应栖身云端
闭环工厂的第二个核心特性是它必须存在于云端。如果有人描述一个本地优先的工厂产品，那它并非真正的工厂。云端化包含三个关键要素。
首先，目标是实现代理自动化与自动改进，而如果代理运行在可能休眠或断网的开发者笔记本电脑上，这根本无法实现。代理本身必须运行在云端开发环境中。
其次，工厂代理产生的所有数据必须存储在云端。这些数据包括每次代理会话的追踪记录、受版本控制的工厂定义，以及与代理运行相关的所有遥测数据，如成本、耗时等。这些数据是改进的原材料——团队中的人类和代理将分析这些数据，以逐步提升工厂的吞吐量和效率。
最后，工厂本质上是团队概念而非个人概念，每个工厂对应一组代码仓库和一个共享产品。这意味着对工厂采取的所有行动都应能在Slack、Jira、Github等团队工具中访问。这只有在一切运行于云端时才能实现。
工厂应具备基于API的执行引擎
你的工厂基础设施应当以API为先。代码定义了工厂的可启动状态，但API驱动其执行。应当有用于启动代理、检索其历史记录、引导其方向、获取遥测数据等的API。工厂中的一切都应优先通过API实现。
这些API对于代理观察、运行和理解工厂运作至关重要。如果工厂由API驱动，就很容易添加新的集成，并在其之上构建应用程序。创建CLI和MCP以从其他工具与工厂交互也会变得简单。这使得工厂对其他代理具有可观测性。尤其是如果你在基础设施平台上构建，应确保该平台以API为先，原因与AWS和GCloud将所有基础建立在API上，然后在其上构建CLI、Web控制台等相同。
指标
工厂应内置指标。随着时间的推移，将这些指标推向更优性能是目标（显然如此）。
工厂指标与DORA指标相关，但更为细化。DORA衡量外部可见的生产力，涉及部署速度及部署质量。工厂指标则衡量内部循环指标，关注构建所部署功能的速度与成本。
核心工厂指标包括：
- PR吞吐量
- 每个PR的平均成本
- 自动化百分比（每个PR的平均人工接触点）
- 相对于人工工作的节省（与类似问题上的人力投入相比，估算节省的成本）
- 理想情况下，还包括已交付产品的加速情况（这难以衡量）
这些指标更贴近软件的实际构建过程，并且只有在你拥有像软件工厂这样的闭环系统时才能获得。
评分者与观察者
为了有意义地推动核心工厂指标，我们需要评估工厂质量的基础组件。在Warp Factories中，我们称此组件为评分者。这一概念在其他智能体质量框架中同样存在。
将评分者视为一个接收输入并返回评分的函数。在软件工厂中，该输入通常是智能体执行的“运行记录”，即智能体的对话轨迹。它可能是分诊智能体、编码智能体或代码审查者的轨迹，也可能是与单个工单相关的所有轨迹。输入不仅应包括智能体轨迹，还应包括来自集成工具的人类交互数据（例如，PR上的人类评论或任务跟踪器中的人类输入）。输入应提供足够信息以判断智能体在任务中的表现。
评分者还包含一套定义输入评分的标准。该评分可由人类、代码，或更常见的是由另一个智能体（LLM作为裁判）来分配。例如，在Warp Factories中，我们提供了默认评分者，根据正确性、成本效率、冗长度等标准对智能体运行进行评分。评分者本质上是对观察者智能体的提示，指示其“查看这些运行记录，并根据此标准进行评分”。
工厂基础设施应允许您配置这些评分者的运行方式；例如，是否对所有智能体和所有运行执行，或采用某种采样策略。它应允许您定义运行时间（我们的默认设置是每隔几小时）、一次评分的运行数量等。运行这些评分者需要成本，因此您应谨慎考虑如何使用它们。
自我改进循环
一旦基础设施搭建完成，你便开始收集一系列评分过的运行记录。例如，你可能拥有100条分诊代理的评分记录。对于每条记录，目标是判断该代理是否将工单分配给了正确的团队，是否正确决定是否需要规格说明，以及是否准确进行了根因分析和问题复现。这些维度中的每一个都可能拥有自己的评分器，因此你最终得到的是一份分级运行的列表。
这份分级运行列表构成了自我改进代理的输入。自我改进代理会接收一组评分过的运行记录，并寻找失败运行中出错（或表现优异）的模式。由于它们是代理，具备智能，能够提炼出这些模式。
如果你正确设置了工厂，这些代理会将其所学应用于提出工厂运作方式的变更建议。它们通过针对工厂定义创建差异补丁来实现这一点，因为定义本身就是代码，所以对它们而言修改起来十分容易。
总结一下，流程如下：
- 工厂代理执行分诊、实施、验证等工作——它们构建产品
- 评分代理定期根据成本、质量、冗长程度等重要维度对工作进行评分
- 自我改进代理审查评分并提出改进建议
- 人类以PR形式审查这些建议，针对工厂定义进行合并改进
基准测试
自我改进循环虽有效，却无法对不同配置进行真正的A/B测试。它们更像是“一个聪明人通过审视过往结果来改进系统的做法”。要更确信改动确实有效，就需要另一种方法，在Warp Factories中，我们称之为基准测试。
例如，你可能想确定，在自己的工作流程中，做前端工作最佳模型组合是什么。仅用开放权重模型是否足够？若足够，该选哪个？是否存在某种混合模型策略最为理想？
要解答此类问题，最佳途径是设定一组参考任务，并让代理以不同配置并行运行这些任务，再衡量结果。就前端示例而言，我们或许会挑选5-10个有代表性的前端实现任务。这些任务可从头创建，也可从过往工厂运行中选取。接着，我们会选定一组待测配置，例如变换模型（但也可调整工厂定义中列出的任何要素）。最后，利用基准测试系统，让工厂代理以所有不同配置运行，并用我们相同的评分器来评估结果。
输出结果是一个矩阵，展示每种配置的表现。若有明显胜出者，你可通过修改工厂代码将其反馈至系统。在Warp Factories中，我们让代理综合基准测试结果并生成差异补丁，以更新工厂原语（如模型路由策略），从而简化此过程。如此，我们再次闭环。
结语
工厂化方法的思考方式，可视为元工程。其目标在于构建一个闭环、自我优化的系统，并辅以人工指导。这是一项工程事业，您的工程团队应运营贯穿数据、调优系统的底层架构。现在就该投资于能让您衡量、测试并自动改进软件开发生命周期的基础设施。拖延越久，后续追赶的成本越高，期间消耗的令牌也越多。构建此类基础设施虽可行，但任务艰巨，因此在评估工厂平台时，应寻找具备恰当原语、能助您当下扩展软件开发规模的方案。