规模化使用编程 Agent 需要系统工程

同时开几个 coding agent，和让一支团队稳定地靠 agent 交付软件，是两件难度不同的事。前者靠人盯任务也能运转，后者必须回答：工作怎么分配、失败怎么恢复、质量怎么验收，以及多交付一个改动究竟花了多少钱。

Warp 创始人兼 CEO Zach Lloyd 把后者称为「工厂工程」（factory engineering）。他的核心判断是：规模化使用编程 agent，瓶颈会从单次提示转向整个生产系统。这篇文章值得读的地方，是把讨论从「哪个模型更强」拉回了团队能测量、能改进的交付流程。

多开几个 agent，为什么还不算软件工厂

作者定义的软件工厂，是一个用代码描述的系统，负责协调云端编程 agent，覆盖软件开发生命周期，并持续改进运行效果。

它接收 issue，分流任务，把复杂需求拆成规格说明，再安排实现、审查和验证。代码交付后，监控结果还要返回系统，成为下一轮改进的依据。

关键不在于串了多少个步骤，而在于步骤之间有没有明确的运行规则：agent 能自行决定什么，什么时候必须交给人，执行到一半失败后又该怎么办。

软件工厂的交付对象包括代码，也包括一套可检查、可测量的生产流程。

作者把生产系统拆成四层：

• 工作入口负责接收待处理事项。
• 控制平面负责分配和协调任务。
• 执行环境负责运行 agent，并限定它能访问的工具与上下文。
• 数据层记录执行过程，为衡量和改进提供依据。

这里的「控制平面」可以理解为调度中心。单次任务里的 agent 负责干活，调度中心负责决定谁来干、按什么流程干，以及异常发生后怎么处理。

文章提出了这些工程问题，但没有给出具体的部署架构、故障恢复方案或权限配置。它是一套系统设计主张，还不是可以照着搭建的技术教程。

别先争模型排名，先算每个 PR 的代价

作者最明确的方法论，是用团队自己的任务评估 agent。

公开榜单可以作为参考，但同一套模型和执行框架，面对不同代码库、任务类型与配置，表现可能不同。换模型、换 harness，也就是组织模型调用和工具执行的运行框架，或者调整工作流，都应该验证实际收益。

作者提到 Warp 关注三个指标：每个 pull request 的成本、吞吐量，以及回滚率。

它们分别回答三个问题：交付一个 PR 花多少钱，单位时间能完成多少工作，交付后的改动是否站得住。单看吞吐量，很容易把更多待审代码误当成更高产出；加上成本和回滚率，才开始接近交付效率。

作者建议用基准测试和 A/B 测试比较配置。不过，文章没有公布 Warp 的具体指标数值，也没有给出样本规模、任务分布或配置之间的对照结果。

因此，可以拿走的是评估思路，不能据此断言某种工厂架构已经证明能降低多少成本。

持续改进，靠的是把纠错变成系统输入

作者用四类机制描述工厂如何演进：Blueprints 定义工厂及工作流转方式，Automations 执行开发步骤，evals 评估 agent 表现并定位问题，Self-improvement 则利用历史运行结果改善后续执行。

大白话讲，就是先规定怎么干，再记录干得怎样，最后把教训带到下一次任务里。

文中举了一个代码审查场景：审查 agent 反复提出需要资深工程师纠正的意见，系统可以收集这些纠正，改进它的审查技能。

这里有一个容易被夸大的地方。作者用的是设想示例，并未提供上线后的效果数据，也没有说明「改进技能」具体通过更新规则、调整上下文、修改提示，还是其他机制完成。不能把它直接理解成模型会自动学习，更不能默认系统已经形成可靠的自我改进闭环。

相应地，作者认为工程师的工作会更多转向设计协调系统、测量表现和优化运行。产品判断仍然由人承担：要做什么、什么算好软件，都需要工程师决定。这是他对职业分工的预测，不是已经验证的普遍结果。

我的判断

我认同作者把测量放到模型偏好前面。对团队而言，「这个配置在我们的任务上是否更划算」比「它在榜单上排第几」更接近决策需要。

但从有价值的工程原则，到值得建设完整工厂，中间还有一笔账。任务是否足够重复、验收标准是否明确、团队是否有能力维护调度和评估系统，都会影响投入回报。文章没有讨论这些条件，也没有比较建设工厂与继续采用人工调度、现有 CI 流程之间的维护成本。

作者来自 Warp，本身就在提供 agent 开发平台。文末介绍其平台被超过半数 Fortune 500 企业使用，这能说明商业覆盖，却不能替代工厂工程的效果证据。

这篇文章更适合作为扩展 agent 使用规模前的设计检查表，效果判断仍需自己的数据。

至于资深工程师会更享受这类系统工作，也是作者的经验之谈。喜欢性能优化和复杂系统的人可能认同，但团队仍要有人承担需求澄清、代码审查和产品取舍，不能只安排工厂的建设者。

能拿来做什么

• 给现有 AI 编程流程补上最小记录：任务类型、采用的模型与运行配置、PR 成本，以及合并后是否回滚。先获得自己的基线，再讨论升级工具。
• 在前端或 Node 仓库中挑选一类验收清楚的重复任务，用同一组任务比较两种配置，同时观察吞吐量、成本和后续质量，避免只凭单次生成速度下结论。
• 把审查 agent 经常犯的错误和人工纠正整理成可复用规则，并用历史任务检查修改后的表现。先验证它确实少犯旧错，再扩大使用范围。
• 当多个 agent 已经需要频繁人工协调时，先写清任务流转、工具权限、失败处理和人工介入点，再决定哪些环节值得自动化。