软件工厂 (Software Factory) 是什么?
2026年9月3日
在 2025 年时，我们曾在 1-2 AI 编程助手 (Coding Assistant) 与 AI 代理 (Coding Agent) 有什么不同? 中谈过 AI 从 2021 年的自动补全到 2025 年的 AI 代理发展简史。进入 2026 年，AI 代理发展得更加成熟，我们也进一步在 [在线课程] AI Coding 201 — 从实战到最佳实践 中讨论了使用 AI 代理的最佳实践。
进入 2026 年下半年，AI 代理仍是社群讨论的主轴；围绕这个主轴又发展出驾驭工程 (Harness Engineering)、循环工程 (Loop Engineering)，以及软件工厂 (Software Factory) 等新名词。
本文将探索软件工厂的相关概念，讨论这个并不算新的名词为何会在今年再次被提出、AI 时代的软件工厂与过去有何区别，同时也会谈谈目前建设软件工厂时会遇到哪些限制，以及该如何突破这些限制。
什么是软件工厂?
软件工厂其实不是一个新概念，早在 1968 年就已被提出。早期的软件工厂概念着重建立标准化的开发环境、工具、流程与可复用组件，希望提升软件生产的规模与效率。
然而，过去软件工厂遇到的根本限制在于，使用传统软件开发方法时，一旦碰到变化，模块与框架便不足以应对，仍需要依赖人类工程师处理需求差异、设计判断与异常情况。因此它能做到的是“工业化软件生产”，而不是今天所谈的自主软件生成。
进入 AI 时代后，AI 代理不再只是按照固定模板生成代码，而是能够读懂需求、探索现有代码库，并根据不同变化生成相应代码。只要人类输入目标、规格、限制与验收场景，AI 代理就有机会在较少人为介入的情况下持续实现、测试与修正。如果过程中出现错误，AI 代理也能自行调试，直到成果通过验证。
2026 年，StrongDM 团队公开了他们打造的软件工厂，以全自动化的方式完成软件开发实现，过程中不由人类编写代码，甚至也不由人类审查代码。
StrongDM 团队把这种方式称为“非交互式开发 (Non-interactive Development)”。相比人类工程师需要持续与 AI 互动并要求 AI 调整，软件工厂则让 AI 从头到尾自行完成，整个过程不与人类互动，直到任务结束。
社群中还有人进一步使用“关灯工厂 (Dark Factory)”来形容这种流程。在工业领域，关灯工厂是指工厂内完全没有人类、全部由机器自动化操作；因为没有人类，也就不需要开灯，因此得名。
规模化的循环
了解软件工厂的概念后，相信读者会问：“如何实现自动化的软件工厂?”
这就不能不提当前社群讨论度最高的循环工程 (loop engineering)。所谓循环工程，是指为 AI 代理设计循环。目前业界有许多团队采用这种开发方式，其中最知名的是 Claude Code 团队。Claude Code 负责人 Boris Cherny 曾在 WorkOS 举办的 Acquired Unplugged 访谈中提到：“我已经不再直接向 Claude 输入提示词，现在我的工作是编写循环。I don’t prompt Claude anymore… My job is to write loops.”
具体来说，可以把 AI 代理的运行看作一个 while 循环。在某个终止条件达成之前，这个循环会一直运行下去。如果最终目标是完成功能，AI 代理就会在完成前持续不断地运行。
所谓编写循环，就是设计循环中的条件。举例来说，“循环的终止条件是完成功能”其实是一个很粗略的描述。如何定义“完成功能”，必须依赖循环设计者。通过所有新测试、通过现有回归测试、代码风格与现有代码库一致，都可以被视为“完成”的条件。这些条件设计得越明确、越精细，循环最终产出的成果也越贴近开发者的预期。
回到 StrongDM 的方法，可以在他们开源的 attractor 项目中看到以下核心执行循环：
FUNCTION run(graph, config):
context = new Context()
mirror_graph_attributes(graph, context)
checkpoint = new Checkpoint()
completed_nodes = []
node_outcomes = {}
current_node = find_start_node(graph)
-- Resolves by: (1) shape=Mdiamond, (2) id="start" or "Start"
-- Raises error if not found
WHILE true:
node = graph.nodes[current_node.id]
-- Step 1: Check for terminal node
IF is_terminal(node):
gate_ok, failed_gate = check_goal_gates(graph, node_outcomes)
IF NOT gate_ok AND failed_gate exists:
retry_target = get_retry_target(failed_gate, graph)
IF retry_target exists:
current_node = graph.nodes[retry_target]
CONTINUE
ELSE:
RETURN Outcome(
status=FAIL,
failure_reason="Goal gate unsatisfied and no retry target"
)
RETURN Outcome(status=SUCCESS, notes="Pipeline completed")
-- Step 2: Execute node handler with retry policy
retry_policy = build_retry_policy(node, graph)
outcome = execute_with_retry(node, context, graph, retry_policy)
-- Step 3: Record completion
completed_nodes.append(node.id)
node_outcomes[node.id] = outcome
-- Step 4: Apply context updates from outcome
FOR EACH (key, value) IN outcome.context_updates:
context.set(key, value)
context.set("outcome", outcome.status)
IF outcome.preferred_label is not empty:
context.set("preferred_label", outcome.preferred_label)
-- Step 5: Save checkpoint
checkpoint = create_checkpoint(context, current_node.id, completed_nodes)
save_checkpoint(checkpoint, logs_root)
-- Step 6: Select next edge
next_edge = select_edge(node, outcome, context, graph)
IF next_edge is NONE:
IF outcome.status == FAIL:
RETURN outcome
RETURN Outcome(status=SUCCESS, notes="Pipeline completed")
-- Step 7: Handle loop_restart
IF next_edge has loop_restart=true:
restart_run(graph, config, start_at=next_edge.target)
RETURN
-- Step 8: Advance to next node
current_node = graph.nodes[next_edge.to_node]
RETURN Outcome(status=SUCCESS, notes="Pipeline completed")
如果用可视化方式来看，简化后的流程如下：AI 代理在执行任务时会检查是否已到达终点；如果没有，就确认是否需要重试，有需要便继续。在任务执行过程中，如果发生任何错误（例如测试未通过），系统会记录结果，并通过下一次循环进行修正：
由于近年来的前沿模型普遍增强了工具使用与长时间代理工作的能力，因此只要在系统提示词中设置相关流程，AI 代理就会按照这样的循环完成任务。Cursor 团队先前在 《Expanding our long-running agents research preview》 一文中提到，现代前沿模型可以持续执行任务超过 30 小时。
软件工厂真的像想象中那么美好吗?
看完上述描述，相信许多读者可能会有所质疑。毕竟，大多数人在工作中使用 AI 代理时仍需要适时介入，避免 AI 代理越走越偏。在实践中，关灯工厂真的可行吗? 社群中也有人质疑，如果采用关灯工厂的方式，前期虽然能做出可用产品，但内部代码混乱，很可能导致长期维护成本大幅提升。
在实践中采用这种形式，必然会遇到一些问题。例如：“如果人类完全不经手任何东西，要如何确保代码真的可以运行?” 有人可能会回答，可以通过软件测试来保证；那么下一个问题便是：“如果实现与测试都由 AI 代理编写，要如何证明它产出的软件真的能按预期运行，而不是 AI 只写出了一段满足测试、却不符合预期的实现?”
社群中的知名工程师、同时也是 HumanLayer 创始人的 Dex，曾发表长文《Why Software Factories Fail》，分享团队实际尝试后的结论：即使到了今天，关灯工厂仍是不可行的概念。当遇到某个代理无法解决的问题时，团队回头查看代码，发现代码已经混乱得难以理解。第一次遇到这类问题时，他花了将近两周梳理 AI 生成的代码；到了第三次左右，团队甚至认为从头重构更容易，最后又花两周手动整理代码结构。
他在质疑中也提到，当时仍找不到足够完整、能够评估长期成效的 StrongDM 后续数据，这让人不得不怀疑 StrongDM 的关灯工厂从长期维护角度来看是否真的可行。
除了可行性外，社群中也有人质疑软件工厂的成本效益比。StrongDM 的发布文章提到：“如果今天平均每位人类工程师还没有花掉至少 1,000 美元的 token 费用，那么你的软件工厂仍有改善空间。” 假设每位人类工程师每天花费 1,000 美元，按照每月 22 个工作日计算，一年的成本将超过 25 万美元。放到亚洲公司的环境中，以台湾为例，这几乎相当于四到五名资深工程师的年薪。如此高昂的费用，让许多人认为采用软件工厂的形式未必更具效益。
尽管存在这些批评，而且我们也不认为真的能够实现 100% 的全关灯自动化，但我们认为朝这个目标前进仍然有意义。因此，在下一段中，我们将讨论可以通过哪些方法，在实际使用 AI 代理时降低人为介入的需要。
加入 E+ 会员方案
如果你觉得这篇分享有帮助，想阅读更深入的内容，欢迎加入 E+ 会员。除了有会员专属的深度文与影片，探讨前后端开发、AI 工程、职业发展，同时有 Discord 社群一同交流与成长。
许多 E+ 会员通过所任职公司的教育训练补助 (E+ 会开立有统编的发票)，不用花自己的钱，也能每周通过深度主题文与社群交流，拓展技术视野、加速职业成长。