很多团队已经能同时启动多个 Coding Agent，但“跑得更多”不等于“系统在变好”。模型、提示、Skill 和路由策略不断变化，团队往往只能凭主观感受判断哪套组合更强。Warp 这篇文章讨论的重点，正是如何把这种试错从零散经验变成一条可以测量、比较和回滚的工程闭环。
这里的软件工厂不是一个替代工程师的巨大 Agent，而是围绕软件交付生命周期组织起来的一组自动化角色：分诊、规格澄清、实现、验证、评审和监控。真正重要的不是角色数量，而是工厂能否留下统一的运行数据，并把数据重新用于下一轮改进。
#第一步：把工厂本身定义为代码
Warp 的第一个原则是 Factories as Code 。工厂需要一份显式、可版本控制的定义，里面包括模型选择、Agent 类型、Skill、工具连接、路由规则、触发条件和执行环境。它与基础设施即代码的思路相似：运行系统不再藏在某个人的操作习惯或网页配置里，而是变成一个可以实例化、测试和审查的版本化对象。
软件工厂的 YAML 定义包含仓库、模型、Agent、触发器和执行环境
这样做带来三项直接收益。
第一，任意一个历史版本都能成为性能基线。团队可以回答：当时使用了哪些模型和 Skill？每个 PR 的成本是多少？合并率和人工介入次数如何？
第二，工厂配置天然拥有分支、审批、回滚和变更历史。一次“优化”如果造成回归，不需要重新猜测旧设置，而是可以恢复到已知版本。
第三，也是自我改进成立的前提：Agent 可以针对工厂定义提出一个明确的 diff。它不是在后台悄悄改变行为，而是像普通代码变更一样提交建议，由人审阅后合并。
#云端的真正价值是集中数据，而不只是远程执行
Warp 强调工厂应运行在云端。这个判断带有其产品立场，但背后的工程要求是成立的：长时间自动化不能依赖一台可能休眠的个人电脑；团队需要共享运行入口；更重要的是，所有轨迹、成本、耗时、人工反馈与配置版本必须进入同一个可查询的数据面。
这些数据是改进系统的原料。只保存最终 PR 不够，因为结果无法解释 Agent 在哪里绕路、何时调用了错误工具、为什么需要人工接管。要改进工厂，必须把一次运行及其人机交互视为完整样本，而不是只记录“成功”或“失败”。
Warp 因此主张执行引擎采用 API-first：启动、暂停、引导、检索历史和读取遥测都应该有稳定接口。网页控制台是人类入口，API 才是其他 Agent、CLI 和自动化能够观察并操作工厂的基础。
#别只看 DORA，要测交付之前的内循环
传统 DORA 指标关注部署频率、变更前置时间和故障恢复等外部结果。软件工厂还需要更细的内循环指标，例如：
- PR 吞吐量；
- 每个 PR 的平均推理、计算与平台成本；
- 自动化比例，以及平均需要多少次人工触点；
- 与相似人工工作相比节省的成本；
- 最终是否真的加快了产品交付。
软件工厂仪表盘同时展示每个 PR 的成本、代码质量与效率趋势
这些指标不能被压成一个漂亮总分。吞吐量提高但返工率上升，或者 token 成本下降却让高风险错误漏过，都不能叫系统进步。正确做法是同时保留质量、成本、速度和人工介入等维度，并明确哪些指标是硬门槛，哪些只是优化目标。
#评分器负责产生信号，观察者负责寻找模式
有了轨迹和指标，还需要把“这次运行好不好”转化成可以计算的信号。Warp 把这个原语称为 scorer 。评分器接收一次或一组运行轨迹，根据 rubric 对任务遵循、流程遵循、正确性、代码质量、冗长度和成本效率等维度给分。
评分可以来自确定性代码、人工判断，也可以来自另一个模型。使用模型评分时，rubric、输入证据和采样策略必须版本化，否则分数本身会漂移。评分器也有运行成本，因此可以对高风险任务全量评分，对低风险、高频任务采样评分。
累计到足够多的已评分轨迹后，观察 Agent 才有材料寻找模式：哪些失败集中出现在某类任务？哪条 Skill 经常被误用？哪种模型路由成本高但没有带来质量增益？它把这些模式转化为对工厂定义的修改建议。
工厂 Agent 产生运行轨迹，评分 Agent 生成质量信号，改进 Agent 再提出配置变更
这形成一条受控链路：
- 工厂 Agent 执行分诊、实现和验证等工作；
- 评分器定期评价成本、质量和流程遵循；
- 改进 Agent 从成功与失败样本中提炼模式；
- 它对版本化工厂配置提出 diff；
- 人类审核并决定是否合并。
这里的人类审批不是临时补丁，而是系统设计的一部分。它把自动发现问题与自动获得生产权限分开，避免一次错误归因直接改变整条交付流水线。
#自我改进建议不是实验结论
观察历史轨迹后提出一个合理修改，只能说明“这个方向值得尝试”，不能证明它更好。历史样本可能存在任务分布变化、模型版本变化和评分偏差。Warp 因此把 benchmark 作为另一层验证机制。
团队先选择一组代表自己的参考任务，再并行运行多套工厂配置，只改变待比较的变量，例如模型、Skill、路由或提示。所有配置使用相同任务与评分器，最后比较质量、成本和人工介入。这才接近对配置改动的 A/B 测试。
同一批前端任务在不同 Agent 配置下的基准结果、成本与逐任务分数
一个健康闭环应当区分两种角色：观察者从生产数据里产生假设，基准实验负责验证假设。前者提高发现问题的速度，后者防止系统把偶然相关性写回生产配置。
#最终产物不是“自治”，而是可学习的工程系统
Warp 把软件工厂称为一种 meta-engineering：工程团队不仅构建产品，也构建并维护“生产软件的系统”。这个系统是否成熟，不取决于有多少 Agent，也不取决于运行时间有多长，而取决于五件事能否连在一起：版本化定义、完整轨迹、分维度评分、代表性基准和可审查的改进 diff。
当这些基础不存在时，自动化只会更快地产生难以解释的输出；当它们存在时，模型升级、Skill 调整和路由变化才不再是凭感觉换配置，而成为可以积累证据的工程实验。