devgo.cn核心观点
- 软件工厂的本质是「规模化运行的 harness 循环」：把单个 Agent 的循环（收集上下文-行动-检查-再循环）放大成由工作队列驱动、经评审门禁进入生产的系统。
- 三层结构要分清：loop（单个 Agent 循环一件事，最小的 Agentic 工作单元）、harness（围绕循环的环境：沙箱、工具、持久记忆、完成门禁）、factory（许多 harnessed 循环并发运行，工作队列喂入、评审门禁流出）。
- 「亮工厂」把人留在循环里，用判断力与专注换速度；「暗工厂」移除人的阅读环节——代码由机器生成、由机器验证、无人读过，这是制造界「熄灯工厂」在软件上的对应。
- 工厂里几乎一切成本都趋近于零（生成、测试、扫描），唯一顽固拒绝规模化的是评审门禁——那个琥珀色的盒子是「判断」，也是整个论点的核心。
内容精讲
「软件工厂」概念可追溯到 1968 年 Bob Bemer 的论文：半个世纪以来，人们梦想软件像工厂冲压汽车零件一样可重复、可仪表化，而不是孤立个体的手艺。历史上这个梦想大多落空，原因在于「难以冲压想法」。但过去两年的变化大到值得重新审视——同时必须精确区分：什么是真正的新东西，什么只是打扮成新机会的旧陷阱。
**循环是原子，工厂是规模化。** 整个技术栈是三个概念层层叠加：loop 是单个 Agent 重复做一件事——收集上下文、采取行动、检查结果、再来一轮直到满足条件，它是 Agentic 工作最小的单元。loop 工程的意义在于：你不再逐轮提示 Agent，而是设计一个「替你做提示的小系统」。harness 是 loop 四周的墙：运行的沙箱、可触及的工具、运行之间存活的记忆、判定「完成」的门禁。把裸模型扔进无 harness 环境，它会永远空转；harness 是让它有用且安全的一切周边。factory 是许多 harnessed loop 同时运行：被工作队列喂入、通过评审门禁排入生产，人在整体上拥有它。它不是更大的 Agent，而是一张由 loop 组成的组织结构图。范式转移随之发生：工作单元从「单个代码 diff」上移为 loop、harness 与它们之间的流转。
**工厂的电路图：几乎全免费，只有一个昂贵盒子。** 意图与生产信号喂入队列（工程领导愿景、工程师直接输入、事故与用户请求驱动的信号），harness 从队列取一项并做出改动；自动化检查（CI、测试、静态分析、各类扫描）同时运行、成本趋近于零；之后是唯一的决策点——评审门禁。通过后部署上线，监控数据反馈回驱动循环起始的信号。全图唯一顽固拒绝扩展的昂贵盒子就是评审门禁，那个琥珀色的「判断」。生成、测试、扫描都可以无限扩容，唯独判断难以规模化——这正是「开发能否更快更频繁」争论的核心。
**「暗」不是营销词，是物理描述。** 暗工厂源于制造业：FANUC 自 2001 年就在日本运行熄灯工厂，小米 2024 年开了自己的高自动化暗工厂——共同点是产品被组装、运输，却没有一个人读过任何环节。软件版的暗工厂同理：写出 diff 的人、评审它的人、发布它的人都不在了，剩下的只是由生成它的机器验证过的 diff。做这件事出乎意料地容易，至少一开始如此——因为缺失的评审步骤挡在所有东西前面，它的缺席会让团队的垂直吞吐看起来惊人地高。
**选择的重量落在哪。** 亮暗之分不是道德判断，而是取舍：亮工厂用人（判断、专注）换速度与破损，暗工厂让 Agent 自己界定范围、构建、发布。但一旦人停止阅读，就会停止理解软件。最难的工作不再是写代码，而是决定「要构建哪些检查、委托多少自主权」。对工程管理者来说，这意味着：规模化的不是「更聪明的模型」，而是「多少 harnessed loop 汇聚到一个评审门禁 + 谁拥有外层循环」的组织设计。
阅读价值
对工程管理者与技术负责人，亮/暗工厂框架提供了一个可操作的自检：你的评审门禁还有人在读吗？对 Agent 平台与开发者，loop→harness→factory 的三层结构是理解「Agentic 软件工程」下一代形态的最小心智模型。
内容与图片版权归原作者所有 · 原文: https://addyosmani.com/blog/software-factories/