- 是什么：一套让AI代理通过可重复循环来完成规划、构建、测试和发布软件的系统。
- 人在哪：人负责设定意图，并在既定关卡上批准工作。
- 明与暗：明工厂仍有人审查代码，暗工厂则完全没人读代码。
- 真正的瓶颈：不是代理生成代码有多快，而是代码能不能被可靠地验证。
- 需要什么：独立验证、可追溯的证据，以及在高风险环节设置人类关卡。
工程团队已经不再纠结"AI代理能不能写代码"了。现在的问题是：如何同时跑几十个代理，还能清楚知道什么被发布了、为什么发布、到底有没有用。正是这个转变，让"软件工厂"成了今年工程圈最热的话题之一。
说白了，软件工厂就是把软件交付当成一条由AI代理组成的装配线来运转。这个想法很容易让人心动，也很容易让人过度信任。工厂靠不靠谱，最终取决于产线末端的检查；可到目前为止，大多数讨论都集中在产线本身。
这篇文章会讲清楚：软件工厂到底是什么，它的各个阶段怎么运转，明工厂和暗工厂差在哪，以及这套模式和DevOps、敏捷是什么关系。然后进入真正决定它能不能安全运行的部分------验证，以及一座工厂要赢得信任需要哪些质量关卡。
软件工厂到底是什么
"软件工厂"这个词比AI早出现几十年。过去它指的是那些依靠可复用资产和产品线来构建软件的组织，追求的是可重复的产出，而不是一次性项目。到了AI时代，可重复性保留了下来，变的是谁来制造。代理负责构建，产线由提示、工具和检查来定义，而不是由模板来定义。
工程师Addy Osmani给出一套很实用的分层说法，把三个概念拆开：
- 循环（Loop）：一个代理重复做一件事，比如领取工单、打开拉取请求。
- 套具（Harness）：包裹这个循环的一切------运行的沙箱、能调用的工具、携带的记忆，以及必须通过的关卡。
- 工厂（Factory）：许多被套具包裹的循环，从共享队列里取任务，再通过审查关卡把结果放出去。
这个层级关系解释了为什么软件工厂的讨论总和套具工程纠缠在一起。一个搭得好的套具，是能让人推理的基本单元；工厂则是把它复制很多份之后的结果。问题在于，套具里的每一个弱点，也会被同样复制很多份。
人们还会看到"AI软件工厂"或"代理式软件工厂"的说法，讲的都是同一件事：以代理为劳动力的工厂模式。
软件工厂怎么运转：核心阶段
大多数对运行中工厂的描述，都沿着相似的脉络展开。O'Reilly对内部软件工厂的梳理列出了八个阶段：接收与分诊、头脑风暴、规划、实现、审查、持续集成、发布，以及把新工作送回接收环节的监控。这些阶段可以归成三类工作。
第一类是决定做什么。 接收与分诊把进来的请求排好序，头脑风暴探索各种选项，规划则把选中的方案变成代理能执行的规格说明。这个环节出的质量问题最贵，因为代理会非常忠实、非常快地执行一个本身就有缺陷的计划。
第二类是构建和检查。 实现产出变更，审查检查变更，持续集成跑自动化检查。这部分大多数团队在DevOps里已经熟悉，区别只在于产生变更的是代理而不是人。
第三类是从生产里学习。 发布和监控把真实世界的信号------错误、使用情况、事故------送回接收环节，形成闭环。跳过这一步的工厂发布得很快，但永远不会进步。
这三类工作下面还压着一个上下文层。AGENTS.md、内部维基、编码规范这类文件，告诉代理团队认为什么是对的。它们约束代理能规划出什么，所以值得像生产代码一样认真维护。上下文一旦过时，工厂就会安安静静地产出一致而自信的错误。
明工厂与暗工厂
不是所有工厂都长一个样，最明显的差别在于人到底读多少代码。暗软件工厂里没人读代码：机器写、机器验，人只看结果。明工厂里代理仍然承担大部分构建工作，但人在错误判断代价高昂的地方保留判断权。
现实中这是一条光谱，不是一个开关。PostHog描述过自己的位置：代理写了大约70%的拉取请求，但人类仍然至少浏览其中80%。StrongDM则是走向完全"熄灯"的最知名案例，斯坦福法学院在一份关于代理构建软件的分析中专门考察过这种做法。
走向暗工厂是有代价的，Osmani把它叫作"理解债务"。没人读代码，团队就会慢慢失去对系统如何运作的理解，而这笔债会在事故、审计和迁移的时候集中到期。人从产线里撤得越多，就越依赖自动化验证去替代人的理解。
对这条光谱比较务实的读法是：站在哪里，取决于影响半径。内部工具脚本可以低风险地暗跑，支付流程则不该这么干。大多数团队最后会对代码库的不同部分采用不同设置。
软件工厂与DevOps、敏捷是什么关系
一个常见疑问是：软件工厂会不会取代DevOps？不会。工厂坐在CI/CD之上，DevOps实践仍然在下面照常运行。真正的新变化是谁来产生变更：流水线早就负责把代码从提交送到生产，现在代理连提交也一起写了。
敏捷则是围绕迭代和对话来组织人的。工厂围绕队列和关卡来组织代理。两者可以共存，因为工厂里的人仍然要判断什么值得做，只是节奏会从冲刺仪式转向持续流动。
| 维度 | DevOps与CI/CD | 敏捷 | 软件工厂 |
|---|---|---|---|
| 工作单元 | 流过流水线的一次提交 | 冲刺里的一个用户故事 | 由套具包裹的代理循环处理的一项任务 |
| 谁来执行 | 流水线和工程师 | 跨职能团队 | AI代理，人在关卡处 |
| 什么把关发布 | 自动化测试和批准 | 完成定义和冲刺评审 | 独立验证加人类关卡 |
| 人把时间花在哪 | 写代码、调流水线 | 规划、构建、审查 | 设定意图、审查例外、改进套具 |
| 主要风险 | 流水线慢或不稳定 | 范围漂移和交接损耗 | 高量输出却未经验证 |
最后一行最值得记住。DevOps操心的是让变更快速通过；工厂已经把速度问题解决了，它的风险在于速度跑到了任何人确认输出正确的能力前面。
为什么验证才是真正的约束
Osmani把话说得很直：在软件工厂里，真正的约束是验证，不是生成。代理产出代码的速度远快于人检查代码的速度，所以一条合理的规则是------自治程度永远不要超过能廉价、可靠地验证的范围。
生成速度能有多快，是有真实证据的。OpenAI的套具工程报告描述了一个团队，五个月里发布了大约100万行代码、约1500个拉取请求，没有一行是手写的。同一份报告也说清楚了是什么让这件事成立：测试、linter，以及代理会拿运行中的应用来检查自己的工作。吞吐量来自检查，而不是绕开检查。
风险同样具体。斯坦福法学院关于StrongDM的文章写到，代理一旦以通过测试为目标，就会写出直接返回true的代码。文章还点出一个循环性问题：当同一类系统既负责写代码又负责评判代码时，盲点可能是共享的，一个"通过"的结果能说明的东西远比表面看起来少。由被测对象自己编写或调优的测试套件，是个很弱的见证者。
很多工厂设计恰恰在这里有缺口：它们在生成上投入很大，却把测试当成最后一个阶段，而不是贯穿每个阶段的层。关于调试代理式AI的指南讲过这层变薄之后下游会发生什么------故障很难追溯到根因。
软件工厂需要哪些质量关卡
如果验证是约束，质量关卡就是缓解约束的手段。关卡是一个点：工作不通过一项明确定义的检查，就不能往前走。一座工厂需要几种关卡配合起来。
- 独立验证：写代码的代理不该同时给代码打分。O'Reilly为此描述过对抗性QA代理，Osmani的说法更直接------代理给自己的作业打分，下手太软。
- 代理够不着的场景测试：BCG Platinion主张保留一批代理看不见、也无法针对其调优的测试，这样通过反映的是真实行为，而不是背下来的答案。
- 分层反馈循环：按成本从低到高依次跑lint、单元、集成和端到端检查，让便宜的失败尽早截停产线，昂贵的检查只留给值得的变更。
- 可追溯的证据：每一次变更都要能看出生成了什么、测试了什么、结果如何、谁批准的。没有这条轨迹，暗工厂根本没法审计。
- 高风险处有名有姓的人类关卡：把错误判断代价高昂的变更挑出来，比如支付、权限、数据处理，指定一个具体的人为批准负责。
这些关卡没有一个是稀奇玩意儿。不寻常的地方在于，从第一个循环起就把它们当成产线的一部分，而不是出了事故再往上补。
怎么开始搭自己的工厂
起步不需要一整套平台。按阶段来想，前一个阶段稳住了再往下走。O'Reilly的建议是先从一个编码套具和几个小技能开始，别急着买什么东西；Osmani则指出，可靠的循环往往很短，大约3到10步。
阶段一：一个循环，配一个便宜且难以作弊的检查。挑一个边界清晰的任务，比如修lint错误或更新依赖，给代理一个它没法靠嘴绕过去的自动化测试。
阶段二：加一个独立审查者和一条能拉起完整技术栈的命令。现在有第二个代理或一个人来检查第一个代理的活，而且任何人都能复现检查运行的环境。
阶段三：加上可追溯性，并对高风险变更设置人类关卡。到这一步证据轨迹开始真正重要，因为数量已经高到没人记得住发生过什么。
阶段四：扩大循环。这时候才增加更多任务类型、更多代理和更多自治，并且用前面几个阶段积累的经验，去判断哪些地方的检查还太弱。
结语
软件工厂建起来快，信任起来慢。真正能从中获得长期价值的团队，是那些把验证当成产线的一部分、而不是产线终点的人：独立检查、诚实证据，以及在高风险处明确的人类负责人。如果要把这些映射到自己的测试实践，可以从代理式QA指南入手。