一种是功能清单式的兴奋：能在手机上发消息控制电脑、能定时执行任务、能跨平台收发消息、能持久化记忆……每隔几天就有新的玩法教程刷屏；然后，然后就不知道做什么了。

另一种是商业嗅觉式的焦虑：套壳机会来了、云服务要卖爆了、腾讯字节百度全在跟进、窗口期还有半年……各种"如何抓住这波红利"的文章铺天盖地；然后，然后也不知道具体如何去做了。

因为这两种讨论都没错，但都停在了表层。

作为“中文互联网第一个意识到openclaw价值的人”，对openclaw的观察是持续的。我认为：真正值得追问的问题是，OpenClaw 到底做了一件什么性质的事，让它能在 Claude Code 之后还能引发这么大的震动？

这个问题的答案，就藏在一个大多数人跳过的技术判断里。

01 大多数人都用错了视角

理解 OpenClaw，先要意识到一件事：大多数人在用产品视角看一个系统层的东西。

传统 AI 应用的逻辑是这样的：模型是中心，应用是壳，工具是插件。每个应用自己管自己的状态、自己的工具调用、自己的用户界面。ChatGPT 是这样，豆包是这样，几乎所有你能叫出名字的 AI 产品都是这样。

这套逻辑有一个隐含的前提：AI 是服务，人是调用者，产品是中间的界面。

OpenClaw 打破的，恰恰是这个前提。

它把 Agent、工具、会话、权限、通道，全部视为**系统的一等公民**。它有自己的目录结构、状态目录、Session 存储，目标是成为一个"对模型和工具中立的执行环境"——你可以换任何模型、接任何工具，系统层本身不变。

模型在这里，反而成了可以替换的零件。

用一个类比来说清楚这个差异：

传统 AI 应用，像是给每台电脑装一个独立的程序，每个程序自己管自己的文件、自己的网络、自己的界面，彼此互不相干。

OpenClaw 在做的事，是造操作系统本身——统一管理进程（Agent）、设备驱动（Channel Adapter）、系统调用（工具集）、用户权限（Agent 边界）。

小龙虾openclaw是从产品到系统，是抽象层的跃迁。

（一个谐音梗）

02 用这个视角，很多事情突然说得通了

为什么 IM 接入这件事，之前有人做过但没爆？

在 OpenClaw 之前，把 AI 接进 IM 的项目不是没有。Telegram Bot 接开源模型，这类项目早就存在。但它们本质上是在应用层做集成——IM 是前端，模型是后端，中间是一根直连的管道。

OpenClaw 不一样的地方，不是"接了更多 IM"，而是在 IM 和模型之间，造了一个真正的执行层：有独立工作空间、有跨会话持久状态、有任务调度机制、有子 Agent 的生成与回收。

在这套架构里，IM 不是产品入口，是系统的 I/O 设备。就像键盘和显示器对操作系统的关系——你可以换键盘，可以换显示器，操作系统本身不需要改变。

这就解释了为什么同样是"AI + IM"，OpenClaw 和之前的方案用起来感觉完全不同。前者是应用，后者是系统。

为什么 Always-on 这件事，OpenClaw 做到了，其他产品没做到？

因为 Always-on 不是一个功能，是一个系统特性。

你没办法在应用层实现真正的 Always-on，就像你没办法在一个 App 里实现操作系统的进程调度。心跳机制、后台常驻、主动触达——这些东西需要在系统层有对应的设计，而不是在产品层加一个"定时提醒"的开关。

OpenClaw 的心跳机制，每隔一段时间自动检查是否有事需要处理，没事则静默，有事则通过 IM 主动触达用户。这听起来很简单，但它成立的前提，是整个执行环境是持续运行的——不是"用户打开了才存在"，而是"一直在那里，等待被调用"。

这是系统的思维，不是产品的思维。

为什么大厂跟进这么快，但很多人觉得跟进的产品"不对味"？

国内大厂几乎每个都出一个仿款，据说腾讯内部还开启了赛马机制，意图快速结束战斗、占领场景，像微信那次一样。但似乎大厂在用产品思维复制一个系统层的东西。

他们看到的是：接 IM、加 Agent、做定时任务。这些功能不难复制，所以跟进速度很快。但他们没有复制的，是那套把 Agent、工具、会话、权限统一抽象成系统一等公民的架构哲学。

结果就是：功能上看起来差不多，但用起来就是感觉哪里不对。因为底层是两种不同的东西，一个是应用，一个是系统。

03 多 Agent 机制：最像操作系统的那个部分

如果你想找一个最能说明"OpenClaw 在做系统层"的具体证据，多 Agent 机制是最好的例子。

每个 Agent 在 OpenClaw 里，是一个有完整边界的执行单元：独立工作空间、独立状态目录、独立会话存储、独立认证配置。这非常像操作系统里"用户 + 进程空间"的概念——不同用户的进程彼此隔离，但可以通过规定好的接口通信。

主 Agent 可以生成子 Agent，每个子 Agent 在独立的 Session 下运行，完成后向父会话汇报结果。子 Agent 默认不能再生成子 Agent，防止无限扩散。父 Agent 拿到的是一个异步任务句柄，不需要等待，可以继续处理其他事情。

这套机制，和操作系统里的进程 fork、异步任务调度，在逻辑上是同构的。

更进一步，当有多个能力相近的 Agent 时，可以用轮询、最短队列、基于历史成功率的权重等策略做负载均衡。这更像是在描述一个简化的集群调度器。

把这些放在一起：Agent 抽象、子进程机制、异步任务句柄、负载均衡调度——这套东西，和你在任何一本操作系统教材里读到的核心概念，有着清晰的对应关系。

04 通道适配与系统权限：驱动层和系统调用

操作系统有两个关键的抽象：驱动层（屏蔽不同硬件的差异）和系统调用（提供统一的底层能力接口）。

OpenClaw 在这两个维度上，都有对应的设计。

通道适配层，把 Telegram、Discord、Slack、iMessage、Web、桌面端等不同的 IM 平台，统一抽象成一个标准化的消息通道。Agent 看到的只是"收到一条消息"和"发出一条消息"，不需要知道这条消息来自哪个平台、用的是什么协议。

这和操作系统的设备驱动做的事情是一样的：不同"终端/设备"的差异，被藏在适配层里，上层逻辑不需要关心。

工具集和系统权限，是另一个维度。读写文件、执行 Shell 命令、控制浏览器、操作 UI——这些工具，本质上是对底层系统资源的统一调用接口。Agent 通过这些接口，拿到了对本地系统的控制权。

有一个具体的案例可以说明这意味着什么：你在手机上的 Telegram 发一条消息，OpenClaw 在你的 PC 上接收指令，驱动 Playwright 控制浏览器，执行一系列自动化操作，把结果发回你的手机。

这整个过程，是：手机 IM（I/O 设备）→ 通道适配层（驱动）→ Agent 执行层（内核）→ 工具调用（系统调用）→ 本地系统资源。

这就是一个操作系统的调用链。

05 真正的竞争还没开始

理解了 OpenClaw 在做系统层的事，就能看到一个大多数人还没意识到的判断：

AI 领域真正的竞争，正在从产品层转移到抽象层。而大多数人还在产品层打得热火朝天。

这个转移，历史上发生过很多次，每次的结构都差不多：

TCP/IP 出现之前，每家公司有自己的网络协议，竞争在协议层。TCP/IP 成为标准之后，竞争转移到应用层。

Linux 出现之前，每个硬件厂商有自己的操作系统，竞争在 OS 层。Linux 成为基础设施之后，竞争转移到上面的软件。

Kubernetes 出现之前，每家公司有自己的容器编排方案，竞争在编排层。K8s 成为标准之后，竞争转移到云服务和上层平台。

现在，OpenClaw 在尝试做的事情，是成为 "AI Agent 执行环境"这个层的标准。

如果它成功了，未来的竞争格局大概是这样的：

- 底层：谁的 Agent Runtime 成为标准（类似 Linux / Kubernetes）

- 中间层：谁的工具和技能生态最丰富（类似 npm / pip）

- 上层：谁的垂直 Agent 在特定场景最好用（类似各种 SaaS）

目前绝大多数人在争的，是上层那个位置。云厂商在争中间层的部署入口。但真正决定格局的战场，是底层——谁的执行环境成为标准，谁就拥有了定义上面所有东西的权力。

这场竞争，现在才刚刚开始。

06 OpenClaw 目前最大的短板，恰恰是机会所在

说了这么多 OpenClaw 做对的事，也要说清楚它现在最薄弱的地方。

一个成熟的操作系统，除了能运行程序，还需要：安全机制、权限分级、审计日志、沙箱隔离、稳定的 API 规范。

OpenClaw 目前在这些方面，距离"成熟 OS"还很远。它拥有系统级权限，但安全治理、权限分级、技能来源审核，仍然非常初级。这在个人玩家手里问题不大，但在企业级场景里，这是硬伤。

这个短板，恰恰是真实机会的位置。

在 OpenClaw 这个执行层之上，补上企业级场景需要的那些系统能力：审计、权限、合规、多租户隔离。

这需要的不是产品思维，是系统工程思维。能看到这个机会的人，目前还不多。

小龙虾会过去，热度会消退，套壳产品会在下一波浪潮里被淘汰。

因为每一次计算范式的切换，最终定义格局的，从来不是第一批做出好产品的人，而是第一批造出新系统层的人。