DarcFactory：黑灯工厂时代

AI 写代码越来越快，软件交付却未必跟着快。一个 AI agent（工人）做完一件事，人要检查一次；十个 agent 同时做事，十份成果就会一起等在人的桌上。把生产速度提高以后，我们才更清楚地看见，决定软件能否可靠交付的，还有组织工作、验证成果和承担判断的人。

我认为，软件工程下一阶段的瓶颈，正在从写代码转向组织、验证和监督工作。 ArcBlock 把我们希望走向的生产方式称为 DarcFactory，黑灯工厂：让 AI 在明确的意图与边界内持续工作，让成果接受独立检查，让人能看清进展，也能在需要判断的地方介入。

“黑灯工厂”是制造业里 lights-out factory 的形象说法：正常生产不需要人一直守在现场，机器不依赖给人照明的灯光，灯关了，生产也能继续。它描述的是无人值守的生产方式，并不意味着维护、异常处理和人的责任也一起消失。

这个想象在科幻里有一个很早的版本。菲利普·K·迪克的短篇 《Autofac》（意为“自动工厂”），首次发表于 1955 年 11 月的《Galaxy Science Fiction》。故事中的自动工厂在战争结束后仍自行寻找原料、制造和配送物品，还能修复或重建自身。幸存的人想重新掌握生产，却发现让工厂停下来远比让它继续生产困难。这个故事留下了一个问题：生产可以自主运转以后，人还能不能决定它该做什么、什么时候该停？

这个名字有两层意思。Darc 读起来接近 dark，呼应制造业的黑灯工厂；DARC 又是 Decentralized Autonomous Resource Coordination 的缩写，即去中心化自主资源协调协议。它指向让各自独立拥有的 Arc（人与 agent 使用的计算环境）协调工作、资源和核验的方向。我们的野心不止于让一座工厂自主运转，还希望让独立拥有的计算资源承接工作、以可核验的成果彼此协作，逐步形成一个协作经济。

趁着 ASE 2026，我想把这个愿景正式带到外面讨论。我们已经在内部实践中探索其中的机制；这里提出的是未来软件生产的方向，没有产品发售或开放使用的承诺。

这个时机很合适。ASE 的全称是 Automated Software Engineering，自动化软件工程。在它的 Harness4GenUI workshop，我会通过 keynote、现场演示和 panel discussion，与大家讨论 AFS-UI：当界面不断生成、模型不断变化，系统中什么应该保持稳定？黑灯工厂把同一个问题推到了生产现场。实现可以不断变化，工作所依据的意图、边界和证据，需要有一个稳定的家。

灯可以关，判断不能消失

制造业的黑灯工厂，是一个很有力量的画面：人不必一直站在生产线上，生产仍然继续。可这个隐喻用到软件上，最容易被记住的是“无人”，最容易被忽略的是让无人值守成立的条件。

生产线需要知道什么是合格品，怎样发现异常，以及什么时候必须停下来。软件更麻烦。我们经常是在做的过程中才弄清需求，一个能通过今天测试的改动，也可能让明天的修改变得困难。AI 工人的输出具有非确定性，验收标准本身还可能有缺口。关灯以后，这些问题不会消失。

行业已经开始认真探索。StrongDM 在 2026 年 2 月公开的软件工厂实践把规格和场景验证放在中心，试验不由人编写或审阅代码的开发方式。OpenAI 的 Symphony则把任务看板接到持续工作的 coding agent 上，并保留人对结果的审阅。两者让我们看到了从单次辅助编程转向持续组织工作的不同路径。

批评同样值得认真听。HumanLayer 的 Dex Horthy 在 AI Engineer 演讲 Harness Engineering is not Enough: Why Software Factories Fail 中指出了一个关键问题：短任务上的测试通过，不能充分评价代码长期是否容易维护。一个工厂可以不断完成任务，却让代码库越来越难改。这不是靠多加几层循环就能回答的问题。

我接受这个警告。对黑灯工厂的评价，不能停留在今天合了多少改动。还要看缺陷有没有逃到交付之后，下一次修改是否更困难，以及人在系统遇到不熟悉的问题时，能否理解并接管它。独立审查也不能自动解决这些问题，它只是让另一种判断进入过程。

所以，我们给这个愿景设下的前提是：自主生产必须建立在可信的验证之上。 验证能覆盖到哪里，自主执行才有依据推进到哪里。超出覆盖范围的工作，需要人的判断，或者需要先补足验证能力。

工作得有自己的身份

今天很多 AI 工作仍然住在聊天记录里。一个终端知道需求，一个会话知道实现，另一个会话给出审查意见。人负责在它们之间搬运上下文，并记住哪份意见对应哪一版代码。

DarcFactory 的设计从 Work Object，工作对象开始。一件需求、一项缺陷或一组改动，应当有可寻址的身份，能够关联它的意图、执行记录、成果和验证证据。换一个 agent，或者换一个界面，这件工作仍然是同一件工作。

拿修复一个缺陷来说，重要的远不止“已完成”三个字。最初授权修什么？哪些文件发生了变化？验证跑在哪个版本上？审查后代码是否又被修改？还有哪些条件没有满足？这些关系要跟着工作走，不能只留在某个工人的记忆中。

DarcFactory 的设计关系：共同记录承载工作；人保留意图与关键取舍，执行和验证围绕同一对象展开。

工作对象是组织方式的基础，也是人的观察入口。人在驾驶舱里看进展，agent 通过 AFS（Agentic File System，提供文件系统式寻址与操作的抽象）读写相应的对象与记录。设计目标是让双方面对同一份工作事实：一个 agent 说自己做完了，是一条陈述；相应版本的检查是否通过、成果是否交付，是需要另外核验的事实。

这个区别很实际。如果看板上的“可以交付”只是工人自己填的字段，那么看板再漂亮，也只是把自报消息排得更整齐。我们希望呈现的是依据事实推导的状态；没有足够证据时，就显示未知或需要处理。

我在 8 月公开过的一张内部样例，把工作队列的存量、年龄和流入流出放在同一页。它让一个很实际的问题变得可见：发现问题的速度，可能比处理问题更快。看见 agent 很忙还不够，人需要知道哪些工作正在积压。

内部样例，公开于 2026 年 8 月 31 日的 X 帖文。图中数字是当时的工作队列快照。

让工人自主，让成果接受检查

我们为工厂确立的一条分工原则是：责任在产出，自主在过程。 工厂的中心职责是组织派活和成果检查。工人怎样解决问题，怎样安排自己的执行过程，应当有自主空间；这种空间受任务授权、权限与安全约束限制。

这也意味着，工厂不能把一切活动都等同于产出。一个工人忙了多久、开了多少个进程，不足以说明它做得好不好。交付了什么、经过怎样的检查、返工多少次、后来出现了什么问题，才更接近我们要了解的能力。

这里的“引擎”，指 Claude Code、Codex 这类执行编程任务的 AI 系统，区别于同一系统里新开的会话。在我们的工厂设计中，代码审查采用跨引擎检查：负责审查的引擎不能属于参与编写该成果的引擎集合。例如，一个引擎编写，另一个引擎检查。目的很朴素，避免同一种推理习惯从实现一路延续到审查，把同一个误解再确认一遍。

这里的“独立”有明确的限度。换了引擎，不代表错误就在统计上相互独立；不同模型仍可能共享训练材料、假设和盲区。这是一种增加判断多样性的结构安排，效果还需要用漏检、返工和实际缺陷来评价。跨引擎审查也必须与确定性的检查、真实使用场景和人的专业判断一起工作。

证据还必须对应将要交付的那个版本。审查通过的是昨天的代码，今天再改了一段，昨天的批准就不能直接搬过来。验证通过了，却修改了授权范围之外的东西，也不能因此获得交付资格。我们希望把这些条件变成明确、可核验的规则，在满足既定授权和检查条件的范围内推进自动交付；需要新的取舍或授权时，把问题交回人。

下面这张早期测试报告样例，把失败和没有查完分开呈现，也保留每次运行的来源与覆盖范围。没有检查到的部分，不能因为已经检查的部分通过就一起算作通过。这样的区别，是人判断是否可以继续交付所需要的。

内部样例，公开于 2026 年 8 月 20 日的 X 帖文。这是当时的测试记录视图。

内部实践也提醒我们，工厂本身同样会犯错。有一次，系统把测试代码里引用的“额度用完”提示，误认为 AI 引擎真的耗尽了额度，结果停工了几个小时。监督信号发现了这个问题，它随后被整理成工作，再进入修复和另一个引擎的审查过程。另一轮修复中，审查引擎指出，看似正确的修改会顺带掩盖一类真实故障，于是修复被打回重做。

这两个例子没有证明工厂可以无人照管。它们说明了我们为什么要把生产、检查和监督分开：写出了修复，不等于修复值得接受；系统解释了自己为什么停下来，也不等于解释正确。

监督因此需要工人不能单方面改写的信号。任务是否真的交付、检查是否实际发生、外部运行是否正常，需要从相应的事实来源观察。信号缺失本身就值得处理，不能把安静当成健康。这样的观察能力，是减少日常人工介入的前提。

AFS-UI 看见工作，DarcFactory 组织工作

这也是我想在 ASE 把两件事放到一起讲的原因。AFS-UI讨论界面与共享操作上下文的关系：界面是对工作环境的一种投影，人在屏幕上操作，agent 通过支持的地址与操作访问相应结构。界面可以演变，底下对象的身份与操作语义需要保持可理解。

DarcFactory 把这个思路用到生产组织上。工作对象、审查和证据需要留在共同的操作环境里；驾驶舱可以提供不同视图，却不该为每个视图另造一份工作真相。AFS，Agentic File System，为这种组织方式提供了文件系统式的寻址与操作抽象。“文件”在这里不只指磁盘上的文档，也可以是通过路径访问的资源和视图。

当人看到某项工作被卡住，应当能找到原因与相关证据；当 agent 接手它，应当能读到相应的意图与边界。这是我们希望在同一个底座上连接起来的两端。一个用于理解和介入，一个用于执行和检查。

我们的野心是，让软件生产逐步从人守着终端的作坊，走向可监督的自主生产系统。未来，同样的工作组织方式也值得在软件以外的领域探索。但工作能否委托，始终取决于相应领域的验证能力，不能因为抽象通用就把自动化边界一并放大。

对 ASE 的研究社区，这里有几个值得共同研究的问题。减少人工介入，究竟意味着系统更自主，还是遗漏了应有的判断？跨引擎验证需要多大的多样性，才能减少共同盲区？长期可维护性怎样进入持续验收？监督者本身又该怎样被检查？

我们在内部尝试记录每轮工作的人工介入，让这些问题逐渐变成可观察的事实。不过，介入次数必须与任务难度、返工、缺陷逃逸和后续维护放在一起看。一个从不求助却交付坏结果的工厂，没有值得庆祝的自主性。

另一张质量看板样例，把已发现与已关闭的问题、需要人处理的队列，以及测试实际执行的比例放在一起。它也标出了检查尚未覆盖的部分。这里值得看的是这些观察之间的关系：问题关闭了多少，人是否跟得上，验证究竟覆盖了什么。图里的某个百分比，不能单独替整个工厂证明质量。

内部样例，公开于 2026 年 9 月 1 日的 X 帖文，看板标注为 8 月 28 日。数字与检查范围属于该次记录。

我希望黑灯工厂改变的是人参与工作的层级。人守住意图，决定什么值得做、哪些边界不能越过，并在证据不足或需要取舍时承担判断。机器负责把已经明确授权、能够验证的工作持续推进。人的注意力可以从重复确认，转向真正需要人的地方。

这就是 DarcFactory 想走向的黑灯工厂时代。衡量它的尺度，是人不必一直站在生产线上时，工作仍然有清楚的来处，成果仍然接受可信的检查，出了问题仍然有人能看见、理解和接管。做到这些，关灯才有意义。

参考