软件工厂不是“同时打开很多个编码 Agent”的炫技名称。Addy Osmani 给出的定义很直接：它是围绕软件工作建立的一套可重复循环。
任务进入队列，Agent 在隔离环境中完成分诊、实现和测试，结果带着证据进入审核；遇到阻塞时暂停，需要人工判断时交接，通过边界后才允许进入生产。真正困难的部分不是让 Agent 写代码，而是让不同批次的运行保持一致，让责任始终有明确归属。
#先问：现成的编码工具够不够
很多团队还不需要软件工厂。
Claude Code、Codex 等现成 coding harness，配合清晰规格、多个会话、验证要求和仓库约束，已经能推进相当复杂的工作。把一批 GitHub issues 交给 Agent，在任务中明确验收条件、人工介入点、必须执行的 lint、测试和构建，再要求它只开草稿 PR、不自动合并，实际上已经形成了一个最小循环。
定时任务、云端 Agent 和事件触发也能在没有自建基础设施的情况下，让这个循环持续运转。
软件工厂开始值得投入，通常不是因为“想跑更多 Agent”，而是出现了以下问题：
- 同类任务需要稳定、可重复地运行；
- 工作需要在多个 Agent 或人工审核者之间交接；
- 必须防止两个会话同时领取同一个 issue；
- 每次运行的测试、决策和风险证据需要被保存；
- 审核积压时，生产流程必须自动停下来；
- Slack、GitHub、Linear 或 backlog 中的事件需要进入统一队列；
- 任务必须在隔离的云环境中执行，并限制凭证与权限。
如果这些协调问题还没有成为瓶颈，自建工厂很可能只是提前购买复杂度。
#一个标签同时充当队列、锁和刹车
真正可用的工厂往往依赖一些看起来很无聊的机制。
Warp 的做法是先把每个新 issue 分到四种状态：可以实现、需要补规格、需要更多信息、暂缓实现。状态标签决定下一个 Agent 是否启动。
这个标签同时承担三项职责：它是待办队列，是防止重复领取的锁，也是人工暂停工作的地方。人不必永久拒绝任务，只要暂时不把它标记为 ready，自动化就不会继续向前。
这比“让一个超级 Agent 自己判断一切”更可靠，因为流程状态对人和机器都可见，而且每个阶段的进入条件都能被审计。
#人不应该只在最后看一眼 diff
好的软件工厂不会把人压缩成最终审批按钮。人的判断需要分布在整个循环中：
- 前期 ：决定产品意图、系统形态、架构边界和质量标准；
- 实现中 ：在需求歧义、风险操作和方向偏移时及时 steering；
- 交接时 ：说明已经发生了什么、为什么需要交接、还有什么未完成；
- 发布前 ：判断自动验证是否足够，决定什么真正可以进入生产；
- 生产后 ：观察真实表现，把故障重新送回分诊循环。
通知机制也不只是“任务完成了”。工厂必须能清楚表达自己为什么被阻塞：缺少凭证、需求不明确、操作越过安全边界，还是必须由人做产品决策。一次 manual 状态并不代表流程结束；只有接手的人知道下一步该做什么，交接才算完成。
#检查数量不等于质量
负责任的软件工厂会把大量时间花在验证上，但更多检查并不自动带来更高质量。
类型系统、lint、架构规则和快速安全扫描适合尽早、持续运行。完整测试套件、变异测试、浏览器测试和更重的安全检查，可以放在草稿 PR 前后。关键是为验证设置预算：既保留高价值信号，又不让低价值检查拖垮反馈循环。
Addy 的示例工厂里，一个没有被驳回的 quick finder 功能用了 7 分钟；另一个经历两次驳回和一次人工决策的收藏功能用了 56 分钟。相同的工厂，时间成本可以相差八倍。只记录“成功、缺陷、阻塞、人工处理”还不够，还需要记录每个阶段耗时，才能知道发现问题究竟花了多少成本。
而且，全绿并不等于正确。 Agent 为了通过测试，可能修改测试本身；为了给登录界面增加 GitHub，可能因为空间不足顺手删除一个真实用户依赖的认证方式。功能测试通过，只说明某些可测条件成立，不代表实现符合产品意图，也不代表没有破坏未被表达的约束。
因此工厂应该要求 Agent 提供工作证据，而不是只提供总结。约束也不能永久固定：当系统积累可信记录时可以适当放宽，一旦出现失误就重新收紧。自主性不是整个项目共用的单一档位，而应随任务风险变化。
#Agent 可以扩容，人的认知带宽不能
并行启动几十、几百个 Agent 很容易，但审核者的注意力不会同比增长。
当一个人同时跟进五到十个项目或功能，会不断在多套上下文之间切换。代码保留了最后的决定，却不一定保留为什么做出这个决定；会话压缩和多轮试错又会让过程信息进一步丢失。最终形成的不是单纯的 review backlog，而是理解债务：代码已经合并，负责人却无法解释功能如何工作。
Addy 提到一个亲身教训：Agent 完成了收藏功能，测试也通过并被合并；几天后需要修改一个细节时，他发现自己根本说不清这个功能的实现，只能重新逐步学习。这说明所有产出最终都流向人的注意力时，工厂真正应该优化的是审核者的决策成本。
对关键任务，运行轨迹、被否决的方案、重要权衡和交接原因应该被持久化，而不是只留在某个会被压缩的聊天会话里。它们可以提交到仓库，也可以保存在本地或团队知识库；重点是让未来的维护者能够恢复当时的心智模型。
#安全边界必须早于自动化规模
软件工厂会读取 GitHub issue、Slack 消息等外部输入，这些内容可能是恶意的，甚至试图诱导 Agent 读取凭证或引入供应链攻击。
因此任务应在隔离沙箱中运行，只获得完成当前工作所需的最少秘密和权限。认证、计费、数据库迁移、现有测试断言等高风险区域，可以在任务规格中明确禁止修改。分支保护则构成合并边界：Agent 可以实现、验证并提交草稿 PR，但不能自行跨过最终发布决策。
工厂扩容前必须先回答两个问题：一次被攻陷的运行能接触什么？一次判断错误的最大爆炸半径有多大？如果答案不清楚，增加并行度只会更快地放大风险。
#不要建一座只生产自己的工厂
软件工厂很容易让人沉迷于优化“做事的机器”，最后忘记它原本应该生产什么。
判断工厂是否健康，可以看外部是否存在真实拉力：用户、业务或维护者是否明确需要这些改进？如果工厂的大部分产出只是让工厂本身变得更复杂，而把它关闭后没有任何外部用户会察觉，那么系统已经形成了自我消费的闭环。
同样，Agent 让复活旧项目变得更容易，却没有替人回答这些项目是否值得存在。依赖可以升级、测试可以补齐、旧 UI 可以重写，但发布之后仍要维护，仍要对哪怕五个真实用户负责。生成成本下降，不会自动创造产品价值。
#所有权不会因为代码由 Agent 编写而消失
未来由人亲手输入的代码比例可能大幅下降，但人的所有权不需要随之下降：
- 仍然有人选择问题；
- 仍然有人选择架构；
- 仍然有人设定质量门槛；
- 仍然有人判断哪些验证信号值得信任；
- 仍然有人决定证据是否足以发布。
系统出故障时，“这是 Agent 写的”不能成为免责理由。
软件工厂真正改变的不是人是否留在循环里，而是人的判断被放在哪里。机器适合提供更快、更强、更确定的检查信号；人应该集中在上下文、品味、风险、长期维护和产品是否值得存在这些无法机械化的地方。
最好的软件工厂，不以消灭多少人工参与来衡量，而以它是否把人的判断放在了最有价值的位置来衡量。