Warp 软件工厂：用评分和 PR 改进 Coding Agent

摘要：Warp 在 8 月 27 日发表文章，介绍如何把云端 Coding Agent 组织成一个可测量、可持续改进的软件工厂。它的核心不是再增加一个聊天窗口，而是把 Agent 定义写进可版本控制的 factory.yaml，让 scorer 按正确性、成本效率、冗长度等维度给运行打分，再让 self-improvement Agent 根据失败模式提出配置 diff，最后由人以 PR 形式审查和合并。这个闭环值得工程团队关注，但文章没有给出完整定价、配额或 GA 承诺，不能把示例指标当成普遍收益。

factory.yaml 定义代码审查软件工厂的配置截图 — 图：factory.yaml 把仓库、模型、Agent 类型和自动化写成一个可审查的清单。来源：Warp Engineering。

团队在采用 Coding Agent 时常问两个问题：哪个模型最适合自己的代码库？一个 Agent 真的省下了多少工程时间？如果只看一次演示或几条成功 PR，很难回答。失败可能来自提示、技能、工具权限、路由或环境，而成本又会被人工返工掩盖。Warp 这次把问题改写为“能否把一次运行变成数据，再把数据变成可审查的工程变更”。

本文只分析 Warp 对 self-improving cloud software factories 的定义和流程，不把它延伸为“Agent 已经能自主管理研发”。真正的自动化仍然需要云端运行环境、评分规则、基准任务和人的合并决策。

AI Coding 交流群

如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。

具体发生了什么：从 Agent 配置到闭环工厂

Warp 的文章把软件工厂描述为围绕软件生命周期的 Agent 自动化：可以负责 triage、spec、implement、verify、review 和 monitor。工厂定义以代码保存，包含 Agent、skills、MCP 集成、模型路由、automations、benchmarks、runners 和 scorers；factory.yaml 充当 manifest。因为这些定义是代码，团队可以做版本控制、分支、审批、回滚和测试，Agent 也能以 diff 的方式提出修改。

文章还强调工厂应在云端运行。原因很具体：如果 Agent 依赖可能睡眠或离线的开发者笔记本，定时任务、团队共享数据和持续改进都无法稳定发生。API 驱动的运行时让触发器、记录和结果进入同一套基础设施，而不是留在某个人的终端历史里。

一个完整场景：从 Pull Request 到下一版配置

假设团队要让 Agent 做第一轮 PR 审查。GitHub 事件触发云端工厂，triage Agent 判断范围，review Agent 读取代码和测试，verify Agent 运行检查并把结果回写。一次运行不只保存最终评论，还保存对话 trace、工具交互以及人类在 PR 或任务系统中的反馈。这样，“审查是否正确”就不必只靠一句主观评价。

随后 scorer 按事先写好的 rubric 对运行打分。Warp 举的维度包括 correctness、cost efficiency 和 verbosity，也可以把合规、流程和代码质量拆成不同评分器。评分可以由人、代码或另一个 Agent 完成；评分器可以配置是否覆盖全部运行、采用怎样的 sampling、何时运行以及一次处理多少条。文章提到默认可以每隔几小时运行，但也明确提醒评分本身会消耗模型成本。

Warp Factories 中显示定时和 GitHub 触发自动化的界面截图 — 图：自动化触发和 Agent 分工被放进云端列表，便于观察哪些工作按计划发生。来源：Warp Engineering。

为什么这一步改变了工作流：优化对象从提示词变成工厂定义

当团队积累了一批带分数的运行，self-improvement Agent 可以寻找失败模式：哪些工单被分错团队，哪些问题没有复现，哪些模型组合成本太高。它提出的不是一句“下次更谨慎”，而是针对模型、skill、prompt、路由或流程的代码 diff。人类把 diff 当作工厂仓库里的 PR 审查，合并后再用同一套 scorer 验证是否真的改善。

这使工程管理获得了一个比“大家感觉更快”更接近交付的观测面。Warp 建议关注 PR 吞吐、每个 PR 成本、人类介入程度以及产品交付加速，而不仅是模型回答分数。指标面板的意义也在这里：成本、质量和效率必须同时看，否则一个看似高通过率的配置可能把返工和推理费用转移到了别处。

Warp Factories 指标面板显示每个 Pull Request 成本与质量趋势 — 图：指标面板把成本和质量放在同一个观察框架中，避免只用单一成功率判断 Agent。来源：Warp Engineering。

基准、成本与权限边界

历史运行不能回答所有配置选择。Warp 给出的做法是挑选约 5 到 10 个有代表性的前端任务，在多个工厂配置下并行执行，再用相同 scorer 比较结果；这只是文章中的示例规模，不是产品配额。基准任务的价值是让“换模型”或“换技能”有可重复的对照，而不是凭一次成功案例下结论。

边界同样清楚。文章没有确认 Factories 的完整可用区域、价格、保留周期、SLA、模型目录或 API 限流。评分器和 judge Agent 会增加成本，采样和调度必须先设置预算。更重要的是，self-improvement Agent 只应提出变更，生产工厂的提示、MCP 权限、路由和环境变更仍要经过人类审查；否则闭环会把一次错误评分放大成系统性改动。

结论：先量化一个环节，再谈自我改进

对工程团队，低风险试用不是立刻把整个 SDLC 交给“工厂”，而是选一个边界清楚的 PR 审查或工单分流流程。先用代码保存配置，固定一组代表性任务，记录成本、时延、正确性和人工返工，再只启用一个 scorer。等评分规则能稳定复现，才让 self-improvement Agent 提议一处 diff，并要求人类通过 PR 合并。这样验证的是“数据闭环是否帮助团队作出更好决策”，而不是被一张漂亮的通过率截图说服。