如何为你的AI劳动力构建一个操作系统？

为什么在生产中运行一群智能体是一个运维问题，而不是框架问题，以及解决这个问题的层面需要处理什么。

过去两年，大部分精力都花在了让智能体更容易构建上。

我们有框架、工作流构建器、拖拽画布、Python库和多智能体编排器。启动一个执行单一任务的智能体从未如此简单。

然而，大多数将智能体投入生产的团队仍然像运行一次性实验一样对待它们。

截至目前，问题不在于构建智能体，而在于运行它们。

想想软件开发是如何按照可预测的顺序成熟的。

先是脚本，然后是应用程序，最终同时运行的进程足够多，以至于你需要一些底层的东西来管理它们。那个东西就是操作系统。它调度资源、协调进程，并为你提供一个界面来控制机器上运行的一切。

AI智能体正遵循完全相同的轨迹。

现在，大多数团队仍然处于脚本阶段。

你为一个任务构建一个智能体，发布它，然后构建下一个，再下一个。几个月后，你有十多个智能体在做十多个互不相关的任务，彼此之间毫不知情，也没有一个统一的地方来管理它们中的任何一个。

称之为“劳动力”也许有点牵强，但实际上，它只是一堆没有协调的、互不相连的脚本。

当前工具实际覆盖的范围

如今发布的大部分工具可以分为三类。

• 工作流构建器，如 n8n、Dify 和 Flowise，适合原型设计。你可以将节点拖到画布上，连接它们，然后得到一些可以运行的东西。但它们很快就会在多智能体协调、动态任务分配、访问控制和审计追踪方面遇到限制。

• 代码优先框架，如 LangChain、CrewAI 和 AutoGen，赋予你控制权，但代价是维护成本。你用 Python 编写图定义，连接基于角色的模式，并手动管理状态。任何使用这些框架上线过的人都知道，一旦 agents.py 超过几百行，事情会变成什么样。抽象开始与你对抗，追踪一次糟糕的运行变得困难，重写成为家常便饭。

• 个人助手，如 OpenAI 的智能体、Claude 和 Gemini，在单个任务上表现出色。如果你交给它们一个研究问题、一份待起草的文档或一个单一工作流，它们可以轻松完成。交互模式是一次一个对话，响应你的输入。协调一组并行运行、朝共同目标努力的专门智能体，从来不是它们的设计初衷。

这三类工具中都有一个共同模式：

• 每个都围绕单个智能体构建，无论你是在构建它还是与它对话

• 没有一个提供对运行中集群的统一视图

• 你无法用自然语言将新任务分配给已部署的智能体

• 没有跨智能体的共享记忆、共享状态或共享治理

换句话说，它们解决了构建问题，但管理运维仍然是一个问题。

智能体的操作系统

让我们回到第一性原理。

操作系统不编写你的程序。

相反，它运行程序并在它们之间协调资源。它为你提供一个界面来查看和控制机器上发生的一切，执行权限，记录运行的内容，并隔离故障，这样一个进程就不会拖垮其他进程。

智能体的操作系统在更高层面做同样的工作，跨越你的所有智能体。

它为你提供一个统一的地方：

• 构建、修改和部署智能体，无需深入代码

• 通过自然语言指挥整个集群

• 将任务路由到正确的智能体并观察它们的进展

• 将每个智能体连接到共享的知识、数据和工具

• 限定权限范围，使团队只能接触他们应该接触的智能体

• 读取日志并审计每个智能体做了什么以及为什么这么做

重申一下，这一层不是构建器，而是你已经构建的智能体的指挥中心。

构建器仍然重要。智能体必须设计良好，工作流必须结构清晰。

但一旦它们上线，你需要一个上层的层面来将整个系统作为一个整体来操作，而不是作为十几个互不相连的系统。

为什么这个限制一开始就存在

几乎所有这里的工具都是自下而上设计的。

从 LLM 开始，你添加工具使用，串联几次调用，添加记忆，然后尝试协调多个智能体。每一层都将复杂性堆积在一个本已复杂的基座上。

在这个堆栈中，没有任何一个环节是为操作结果的人设计的。

例如，连线工作流的开发者不会考虑下个月需要给该智能体分配新任务的团队负责人。设计多智能体管道的工程师不会考虑需要审计每个行为的合规官员。

这导致了一个巨大差距：一边是已经部署的智能体，另一边是你实际上可以管理的劳动力。

许多团队掉进了这个差距，再也爬不出来。

新架构

如果你要从头开始为你的 AI 劳动力设计一个操作系统，它需要几个要素。

• 自然语言命令界面，而不是你拖来拖去的可视化画布，或你用来构建的 Python SDK。这将是一个对话层，你可以说“创建一个监控我们的支持收件箱并将紧急工单升级到 Slack 的工作流”，然后它就会发生。这就是人们真正想要的与他们的 AI 劳动力交互的方式。

• 每个智能体都应该共享对相同知识库、文件存储、数据库和集成凭证的访问。这些不应该按智能体隔离，而应该在工作区级别管理。当你构建一个新智能体时，它应该能够看到并使用其他所有已有访问权限的东西。

• 一个地方查看每个智能体正在做什么、做了什么以及为什么选择那条路径，而不是从分散在不同服务中的日志中重构它。一个单一的、结构化的审计追踪。

• 不同团队应该能够使用不同的智能体而不会互相干扰。管理员应该能够限制任何智能体可以使用的模型或工具。敏感数据应该保持隔离。

• 对于任何严肃的企业部署，你不能将数据发送给第三方 SaaS。操作系统需要在你自己的基础设施中运行。

这些都不是可选的附加功能，因为如果你放弃其中任何一个，你得到的将不是一个操作系统，而只是一个带有更好 UI 的构建器。

今天使用 AI 构建的团队的下一步

这种理念完全重新定义了你对智能体的思考方式。

不再是“我如何构建这个智能体”，而是问集群在六个月后会是什么样子，以及你如何让它保持运行。

从这种定位可以得出几个结论：

• 智能体成为工作者，而不是脚本。它们承担角色、责任和监督，当需求变化时，你重新指示它们，而不是从头重建。

• 集群是可组合的。一个支持智能体、一个研究智能体和一个数据丰富智能体可以共享上下文并相互传递工作，因为同一层治理着它们所有。

• 非工程师可以操作它。有了自然语言界面，启动一个智能体或分配任务不再需要通过开发者。PM、运营负责人和分析师都可以直接进行更改。

• 治理变得可控。审计追踪、访问控制和合规性从一开始就存在于管理层中，而不是在压力下后期改造。

这有助于使 AI 智能体在大规模下变得可行，而不需要更换更好的模型或添加更多集成。它为你提供了一个连贯的管理层，将整个集群视为一个可操作的系统。

未来方向

采用瓶颈早已不是模型能力的问题，而是基础设施成熟度的问题。

团队知道他们希望智能体做什么。他们缺少的是一种干净的方式来大规模部署、管理和治理它们。谁先解决运维方面的问题，谁就能获得复合优势。

朝着这个方向努力的团队不是从“我们如何制造更好的智能体”出发，而是从“集群的指挥中心应该是什么样子”出发。

这是一个更有价值的问题。

如果你想看到这种理念已经被实现，Sim（开源，27k+ 星标） 已经构建了它。它为你提供了一个用于 AI 自动化的协作工作区中的工作流智能体，用于构建、部署和管理 AI 智能体及工作流。

它最初是一个开源的可视化工作流构建器，后来成长为一个自然语言命令层，用于从一个界面创建、管理和指挥一群智能体，而不是一个组装单个工作流的工具。

你可以自托管它，阅读代码，并且不会被锁定在别人的基础设施中。

这里是 GitHub 仓库 →

（别忘了给它加星 ⭐️）

这就是全部内容！

如果你喜欢阅读本文：

找到我 → @_avichawla

每天，我都会分享关于数据科学、机器学习、LLM 和 RAG 的教程和见解。