人力劳动是下一个蒸汽机
现有的基于人力劳动的企业和社会结构，跟电气化革命中的“成组驱动”系统惊人地相似。现在的 AI 应用不过是把“蒸汽机”换成了“电机”。历史再次押韵，我们会看到新的企业和社会结构涌现，就会变成下一个“单元驱动”范式转变。
读了 OpenAI 发布的 2025 年企业 AI 现状报告 后，我有个想法。这个想法很有意思，但在某种程度上也相当残酷：现有企业中的人力劳动实际上就像是电气化革命时期的“蒸汽机”。未来的另一次飞跃并不在于 AI 替代人力劳动（不过这无论如何都会发生），而在于重构企业以及支撑它们的社会结构，以拥抱一种新的“电力” —— 即 AI 创造的智能富足。
序幕
以下是保罗·大卫（Paul David）1990 年发表的著名论文《发电机与计算机》（The Dynamo and the Computer）的摘要，由 Gemini 3 生成，并侧重于“重构”这个主题：
保罗·大卫 1990 年的论文《发电机与计算机：现代生产率悖论的历史视角》（“The Dynamo and the Computer: An Historical Perspective on the Modern Productivity Paradox,”）通过类比历史上的电气化进程，解释了为何到了 1980 年代后期计算机仍未带来显著的生产率提升。其核心洞见在于：通用技术需要根本性的组织重构才能带来生产率的提升，而不仅仅是技术上的采用。
来自电气化的重构教训
大卫观察到，电力发电机早在 1890 年代就已确立，但在美国制造业中，直到 1920 年代——即延迟了四十年——才产生生产率的激增。关键的洞察在于，早期的工厂仅仅是用大型电机替换了蒸汽机，采用了“成组驱动”（group drive）的配置，却保留了相同的工厂布局和生产流程。这种肤浅的“升级”带来的效率提升微乎其微。
真正的生产率提升只有在工厂完全围绕“单元驱动”（unit drive）——即为每台机器配备小型独立电机——进行重新设计后才出现。这使得单层建筑、灵活的工作流安排、危险的高架皮带系统的消除以及根本不同的制造流程成为可能。技术本身是一样的，但组织结构必须被重新发明才能释放其价值。
在计算机领域的应用
大卫认为，1990 年的企业在计算机应用上犯了同样的错误：将计算机简单地叠加在现有流程之上，而不是从根本上重构工作方式。他预测，只有当组织完全重新设计其运营模式以利用数字化能力时（就像几十年前工厂必须围绕电力进行重建一样），显著的生产率收益才会实现。因此，“生产率悖论”是一个暂时的衡量问题，反映了技术采用与有效利用所需的组织学习之间的自然滞后。
由人力劳动构成的机器
先不管有些工人在从事体力劳动，但在企业中，办公室里的打工人还是类似于机械部件。比如说，真实机器中的传动系统有层级结构（齿轮、轴和滑轮），企业也是如此。这种商业机器的组件就是由人构成的。人力劳动和智能以一种中心化的方式分布在企业中。抽象地说，人力劳动（及智力）是企业的蒸汽机，而管理者、规则和官僚机构则是它的“传动装置”。我们社会结构的很大一部分是围绕人力劳动建立的。这些社会结构（公约、法律等）支撑着这台引擎，防止误用或滥用。例如，工人福利、劳动法和工会。甚至风险投资人（VC）也会说这一点，也就是“所有问题归根结底都是人的问题”。
AI：是涡轮增压器，还是新引擎？
现在每个人都在 AI —— AI 接管工作、接管商业、接管一切。一些实用主义者说 AI 可以提升人力劳动的生产率，但不能取而代之。这很合理。OpenAI 的报告中也提到：
企业用户报告说，每天节省了 40–60 分钟
读到这里时，我感到有些奇怪。为什么每天只能节省 40–60 分钟？我原本想的是成倍的提升，相当于每天节省几个小时。但我大概已经知道了答案——因为“人”这个组件。这里指的“人”这个组件，不仅指人本身，还指围绕着他们的结构。比如说，就算 AI 无处不在，我还要翻阅隐藏在某个网站深处的文件，填我都看不懂的表格，然后走复杂的流程。这不是在发牢骚，只是举个例子。另外，就算 AI 帮我处理了很多事，我还是要花时间审结果，老实说我比较懒，所以我这个人就成了瓶颈。AI 可以在几分钟内读写成页的内容，但我做不到在几分钟里审完这些结果。
这些事实让我意识到“人力机器”里的摩擦力。我们现在称 AI 为“副驾驶”（Copilot），但如果我们好好细想“人力引擎”这个类比，加上了副驾驶仅仅是给人力引擎安装了一个涡轮增压。它肯定可以提升动力，但大部分提升都在这个机器的“传动系统”中损耗掉了。
就算一些公司正在用 AI 替代人力劳动，但本质上依然是给机器安装一个新的“电机”。我们需要的是一个新的“单元驱动”范式转变，但目前所有 ToB AI 公司都在抢着给那些由“人力蒸汽机”驱动的旧工厂安装更多的涡轮增压或者新电机。
推论与未来
历史不会重复，但会押韵。我们现在看到了 AI 超级工厂，它们很可能会像发电厂一样保留下来。词元(Token)和算力会成为基础设施一样的资源，就像电力一样。如果我们进一步思考这个类比，那新的“单元驱动”范式转变发生时会发生什么？有些推论是很显然的：
每个人都是独立的创业者和企业： 我们不会再有为人力劳动建立的“成组驱动”结构。劳动力和智力资源不再在公司内部集中分配，不再有劳动力和智力的成组驱动。取而代之的是，每个人都是一个独立的企业，配备了“电机”（即 AI），这才是真正的新型单元驱动范式。
全民基本收入和词元保障： 旧式企业形态消失之后，个体创业者的生存底线就只能靠全民基本收入。获取词元也会变成新的人权，就像用电权和上网权一样。而由于大规模生产，词元的价格会持续下降，直到接近能源的成本。
2B 就是 2C： 当没有了巨型企业，向企业销售服务就等同于向个人销售服务。我们已经在“面向专业用户（Pro Users）”的服务中看到了这种趋势。
开放的技术和社会协议会是主流： 将不再有 All-in-One 的封闭应用。每个企业，也就是每个人，都会基于开源解决方案、模板和协议造自己的“电机”。
有意思的细节
如果上面的推论看起来太大了，在重新思考了我最近项目中的 Agent 开发之后，我有两个近期的预测：
- 一种新型的个人计算机（或者至少是一种新型的文件系统）将会出现，以适应人类与 Agent 协作的需求。
- Agentic CI/CD 将是迈向无需人类参与（哪怕是最低限度的监控）的自动化的第一步。
背景是这样的：我有不少专门为桌面浏览设计的数据可视化图表，但我想把它们全部改成移动端版本。这个转换并不像看起来那么的简单。负责转换的 Agent 需要理解/提取可视化背后的数据，从原始可视化中推测意图（比如要保留、展示甚至强调哪些信息），最后生成移动端界面，而且必须确保在移动设备上以可读和友好的方式呈现“相同”的信息。
我最初的尝试是使用 Google Antigravity，因为它可以让 Agent 在浏览器中自己看转换后的移动端界面，修正任何 UX 错误。但是，因为 Agent 需要经历很多步骤（比如在桌面浏览器和移动浏览器上读取原始可视化，读取原始代码，提取数据，实现移动端版本，然后移动端浏览器上检查），它有时会漏掉一些关键步骤然后犯错。这在我的意料之内，所以我会给 Agent 一些提醒。结果其实还行，甚至可以说是出乎意料地好。但是我知道这样没有扩展性，因为我有很多图表要转换，但没有那么多时间去盯着 Agent。
于是，我想试试多 Agent：一个 Agent 做规划，一个做数据提取，一个做实现，最后一个做审查。我想到的第一个库是 LangChain，但是实话说，虽然我有很长很长时间（大概 10 个月！）没写多 Agent 项目了，但是我还记得它有多难用。我也读了它的文档，发现了一个叫 DeepAgent 的新库，看起来确实不错。但我就是不想用。我有很多可视化图表，就意味着有很多需要 Agent 处理的小项目，我就要为它们准备很多个干净的工作空间，但 DeepAgent 好像不能很容易地生成很多基于文件夹的工作空间。另外，一想到要管理这四个 Agent 之间的交互，我就头大。相互发什么消息，共享什么上下文，用什么工具，如何管理每个 Agent 的反馈循环，等等。
我只想要有一个零配置的 Agent，它能用我电脑上的所有工具，干活，然后自己检查结果。仔细想想，其实我不止有一个，而是已经有好几个了：codex、gemini-cli 和 claude code！所以最后我用双 Agent 的配置：
- 规划 Agent 实际上只是一个工作流。一个 Python 脚本在桌面浏览器和移动浏览器上渲染原始的可视化。不需要让 Agent 打开两个不同的浏览器并使用不稳定的工具。渲染结果连同原始代码和其他文本需求会发送给 Gemini 3 Pro，它就会可靠地生成详细的实施计划。
- 对于每个可视化，从模板生成一个干净 JS 项目，包含必要的依赖和脚手架代码。详细计划保存在项目里，原始可视化的渲染图和原始代码也一并保存。一种桌面端可视化 -> 一个干净的 JS 项目。
- 第二个 Agent 就是
gemini-cli，它读取计划并执行任何必要的操作来实现计划。
唯一的小问题是，项目里有很多个 node-modules ，占用了大量空间。但这是合理的代价，因为现在我唯一需要写的脚本就是：
# 伪代码
对每个桌面可视化：
在桌面浏览器和移动浏览器上渲染可视化
运行 Python 脚本生成详细实施计划
复制模板文件创建新项目
将计划保存到项目中
为 gemini-cli 配置 playwright MCP
运行 gemini-cli 实现计划，让它自己审自己的结果
没有上下文管理，没有任何消息传递。只要运行脚本，坐等结果。
在等着结果去洗澡的时候，我突然想到这很像 CI/CD 流水线，只不过这个流水线是由 Agent 而不是脚本组成的，它运行在我的电脑上而不是远程服务器上，通过文件夹而不是 git 仓库进行版本控制。这种暴力美学既优雅又很蠢。但是，退一步想想：为什么我要这么做呢？
首先，作为一个人类，我已经是我这个“宏大项目”里的瓶颈了。我根本没有足够的时间自己做完所有的事，甚至没时间去监控 Agent。不管是过去还是现在，我都没有扩展性。在技术方面，PC（即“个人计算机”）也没有扩展性。它们是为单用户设计的，而不是为多用户设计的。例如，我们无法复制、生成多个文件夹，因为当唯一的用户就是我的时候，这没有意义。就算是 git，作为分布式版本控制系统，也不是为单台计算机上的多用户设计的。比如说，在一个仓库中，我们不能同时在多个分支上工作，因为以前没有意义。但是，时至今日，在一台计算机上、同一个项目、同一个目录或同一个工作区中工作的用户数量不再是 1 了。
当我们与多个 Agent 协作时，我们需要一个新的文件系统或 git 来支持同时进行的工作，就像平行宇宙。Docker 可能是一个解法，但是·····还是吃点好的吧。
我们需要监控 Agent 的时候，我们自己就成了新的大型机，因为我们的注意力和时间是有限的，所以必须多路复用。就像以前，每项工作或每件任务都分配给一个人。随着自动化，一些工作可以在人的监督/控制下完成。但是，如果大部分工作不再需要分配给人类控制员/监控员呢？在我看来，这就会是另一次飞跃，就像以前从大型机转变到个人计算机那样。
元数据
版本: 0.2.0
日期: 2025-12-09
许可: CC BY-SA 4.0
更新日志
2025-12-26: 增加了有意思的细节