自动化的演进：从 Shell 脚本到 AI 组织

起初，我们自动化的是任务

我最早接触的自动化形式又小又局部。一个 shell 脚本替代了一串命令。一个 cron 任务让某件事按时发生。一个 Perl 或 Python 脚本把重复的流程变成了可复现的东西。

典型的例子是这些：

• 批量重命名或移动大量文件
• 每次都以同样的方式处理数据
• 在系统之间复制文件
• 执行重复的部署命令
• 安排周期性的维护作业

这个抽象很简单：我清楚知道要计算机做什么，我能足够精确地描述出来，而且我宁愿花时间教它一次，也不愿自己永远做下去。有时这意味着花两个小时去自动化一个手动只需五分钟的任务——如果你只打算做一次，这看起来很荒唐；如果你打算做几百上千次，答案就很明显了。

随着软件系统越来越复杂，同样的模式不断重演。

接着，我们自动化了基础设施

云计算扩大了可被脚本化的范围。我们不再只是自动化机器上的某个任务，而是开始自动化机器本身的创建与配置。

Terraform 让我们可以把基础设施描述为代码。Kubernetes 让我们可以描述分布式应用应当如何运行、扩缩、重启和通信。CI/CD 系统则自动化了软件从版本控制走向生产环境的过程。

突然之间，那些历来需要大量人工运维的东西，都可以被声明和重建：

• 服务器
• 网络
• 数据库
• 负载均衡器
• 权限
• 应用部署
• 扩缩规则
• 完整的环境

过去需要有人在控制台里点来点去、手工配置系统、协调部署的工作，逐渐变成了可以版本化、可评审、可测试、可复现的东西。

前期成本变高了，因为被自动化的对象变大了。好的基础设施自动化比十行 shell 脚本难得多，它需要更多思考、更多边界情况处理、更多调试和更多维护。但回报也随着复杂度一起放大。一旦环境被正确定义，过去需要数小时甚至数天手工搭建的整套系统，只需极少的人力就能重建。

自动化的原则完全没变。我们只是往上挪了一层。

现在，我们在自动化工作流

AI 智能体再一次把这个抽象往上推。起初，最显而易见的用法是把智能体当成一个非常能干的脚本：给它一个任务，让它执行，再把结果拿回来。

这确实有用，但也是一种相当狭窄的理解。更大的转变在于：我们现在能自动化的不只是单个任务，还有多个智能工作者之间的任务协调。

一个现代的智能体工作流可能是这样的：

• 一个智能体写代码。
• 另一个评审实现。
• 另一个运行测试。
• 另一个排查安全问题。
• 另一个核实原始需求是否真的被满足。
• 一条工作流决定出错时该怎么办。
• 若干审批关卡决定什么需要人来把关，什么可以自动放行。

到了这一步，你脚本化的就不再是工作本身，而是组织工作的那套系统。这比单纯把一个手动任务换成一个 AI 任务要大得多。自动化的边界正在从执行转向协调。

Orgabot 是同一个想法的最新版本

我就是这样看待 Orgabot 的。人们很容易把 AI 智能体编排看成与此前的自动化工具截然不同的东西，但在抽象层面上，它和我用了几十年的模式是同一个。

这条演进路线相当直白：

• shell 脚本自动化了我不想反复敲的命令。
• 基础设施即代码自动化了我不想反复配置的系统。
• CI/CD 自动化了我不想手动协调的部署流程。
• 智能体编排自动化了我不想一步步盯着的工作。
• Orgabot 把这件事推向了自动化工作者周围的组织结构本身。

差别在于规模。有了 Orgabot 这样的东西，被自动化的对象不再是一条命令，甚至不再是一条部署流水线，而可能是一整套软件开发流程，涉及多个专职智能体、权限、评审关卡、验证步骤和部署逻辑。

这个转变，是从脚本化「实现这个功能」这样一个任务，走向定义一个能够反复决定功能该怎么做、由谁来做、工作该如何评审、何时可以发布的系统。这看起来已经不太像在自动化一名开发者，而更像在自动化一个组织的一部分。

自动化不断沿着抽象层级向上走

回头看，这条演进路线出奇地一致：

• 我们自动化了命令。
• 然后自动化了重复任务。
• 然后自动化了部署。
• 然后自动化了基础设施。
• 然后自动化了流水线和工作流。
• 现在我们在自动化这些工作流里的工作者。
• 而且越来越多地，在自动化这些工作者之间的协调。

每一步都把自动化的边界往上推。有意思的是，每个阶段都让人觉得已经到顶了。当基础设施变得可编程时，那感觉像是抽象层级上的一次巨大飞跃。当 AI 智能体开始写软件时，人们很容易以为我们已经抵达了自然终点：告诉 AI 你想要什么，让它去造就行了。

但就连这一步，现在看来也已经像是一个中间环节。我们不再只是告诉某个智能体该做什么，而是在构建这样的系统：由它来决定哪些智能体上场、它们如何协作、它们的产出如何评估、接下来该发生什么。这就引出了那个显而易见的问题：自动化编排之上又是什么？

十年后，什么会是可脚本化的？

如果这个模式继续下去，下一层抽象可能远大于我们今天所说的任何工作流。也许我们自动化的单位会变成一整家组织。

你也许只需描述一个业务目标，然后由系统组装出相当于以下部门的东西：

• 产品开发
• 工程
• 基础设施
• 市场营销
• 客户支持
• 财务
• 法务流程
• 数据分析
• 运营

输入最终可能变得不那么程序化，而更偏向意图。你或许不必再指定任务、工作流或智能体，只需表达一个目标，比如「我觉得应该有一个能做这件事的产品」，然后由系统去搞定把这个想法变成现实所需的一切。

这里还有一个更宏观的历史规律。人与计算机的交互一直在朝更高的意图层级移动：

• 机器码变成了编程语言。
• 编程语言长出了库和框架。
• 服务器变成了基础设施声明。
• 命令变成了提示词。
• 提示词正在变成目标。

合乎逻辑的终点是：我们花在描述「某件事该如何发生」上的时间越来越少，花在描述「我们想要存在什么」上的时间越来越多。也许十年之后，连显式编排智能体这个想法都会显得原始。也许我们只需表达意图，让系统在底下自行搭建所需的智能体、工具、工作流、基础设施、组织和流程的任意组合。

推到极致，这种界面可能不太像编程，而更像「显化」：想到某样东西，把它描述出来，然后看着一套自动化系统把这个意图变成真实存在的东西。这听着很夸张，但此前的每一层抽象，在它出现之前听起来同样夸张。

自动化的经济账其实从未改变

我觉得最有意思的是，尽管有了这么多进展，这笔交易几乎和我几十年前写 shell 脚本时一模一样。自动化仍然需要前期投入。你得定义流程、搭建系统、处理边界情况、调试故障，并决定当现实与你的假设不符时该怎么办。

手动做事一开始往往显得更轻松，因为它省掉了那笔初始投入。然后自动化开始运转，重复次数不断累积，回报就变得显而易见。

当自动化还是十行 shell 脚本时，这是对的。当它变成几千行基础设施配置时，这也是对的。如今我们开始编排 AI 智能体团队，这依然是对的。规模一直在变大，原则却几乎没变：把力气花一次，好让自己不必永远花下去。

如果这个模式继续下去，最有意思的问题就不是我们今天能自动化什么，而是明天还有什么会显得大到无法自动化。