架构解析：OpenClaw 如何用一个 WebSocket 控制平面统一所有 AI 交互？

发表于 更新于 分类于 本文字数： 5.2k 阅读时长 ≈ 5 分钟
文章解析 OpenClaw 如何通过 WebSocket Gateway 构建统一的 AI 交互控制平面。将控制平面与数据平面分离，Gateway 负责会话状态管理、路由调度、权限策略和事件分发，成为唯一事实源。采用 JSON-RPC 2.0 加命名空间的协议设计，支持 CLI、WebChat、移动端、浏览器自动化和消息通道等多种节点接入。节点通过声明能力实现智能路由，解决了多端状态不一致、上下文串台等痛点，适合需要构建多端协同 AI 系统的架构师参考。

很多团队在做 AI 产品时，第一反应往往是 “再加一个入口”：给命令行做个插件、给网页加个聊天框、给手机做个壳、再接上 Slack/Telegram…… 短期看起来很合理，用户想在哪儿用就在哪儿用。但做着做着你会发现，系统不是变强了，而是被自己“拆碎” 了。

因为每多一个入口，就多一套协议、多一套状态、多一套上下文同步逻辑。最终你得到的不是一个 “多端一致的 AI”，而是一堆互相不认识的 AI 分身：CLI 里跑到一半的任务，Web 端看不到；手机端刚授权了定位，桌面端还在反复询问；浏览器自动化执行到了第 7 步，消息通道里却只剩一句 “处理中”。

问题不在模型，而在架构。

如果 AI 的能力是统一的， 为什么交互方式却把系统撕裂成碎片？

OpenClaw 给出的答案很 “反常识”：它不急着做一个更漂亮的聊天 App，也不把重心放在某个具体端，而是先把最关键的东西抽出来——做一个 “AI 交互控制平面”。所有端都不用各自为政，统一接入一个 WebSocket Gateway，让它成为整个系统的控制中枢。

下面我们就沿着这个思路，把 Gateway 这套架构拆开讲清楚：它到底控制了什么、为什么选 WebSocket、以及它如何把 CLI、WebChat、移动端、浏览器自动化和消息通道变成一个 “统一系统”。

一、先把概念摆正：控制平面到底是什么？

在分布式系统里，“控制平面 / 数据平面” 的划分非常经典。放到 AI 交互里，这个划分同样关键。

1）控制平面（Control Plane）

它负责 “指挥与协调”，典型职责包括：

  • 会话（Session）与状态管理：当前谁在发言？哪个任务在执行？执行到哪一步？

  • 路由与调度：这条消息该发给哪个节点？工具调用该落到哪台设备？

  • 权限与策略：哪些端可以读写？谁能触发浏览器自动化？谁能配对新设备？

  • 事件分发：模型流式输出、工具执行进度、typing 状态、通知推送……

2）数据平面（Data Plane）

它负责 “干活”，包括：

  • 模型推理与流式生成

  • 工具执行（文件读写、命令执行、浏览器操作）

  • 实际的多媒体传输（截图、录音、图片等）

把这两者分开，一个直接好处是：Gateway 只做 “调度与一致性”，不承担 “计算与执行”。它变成一个真正的 “中枢神经系统”，而不是又一个塞满业务逻辑的巨无霸服务。

二、为什么控制平面必须是 WebSocket？

如果你把控制平面当作 “请求 - 响应 API”，很容易走回老路：HTTP + REST，前端轮询，后端推送靠各种补丁。AI 交互一旦涉及多端协作、流式输出、任务进度、异步事件，你会发现 HTTP 模式天然别扭。

WebSocket 的优势不是 “潮”，而是它恰好匹配控制平面所需的三件事：

  1. 全双工

AI 交互不是一问一答，更像协作：模型在持续吐 token、工具在持续汇报进度、用户随时插话、节点随时上报状态。全双工让 “事件” 成为一等公民。

  1. 低延迟 + 长连接

流式输出、实时同步、typing indicator、任务状态更新，都需要持续连接和快速推送。

  1. 跨平台一致

CLI、浏览器、移动端、桌面端——几乎都能稳定地做 WebSocket Client。你不需要为每个平台重新造一套通信栈。

OpenClaw 的做法是：让所有节点统一连到一个 Gateway，比如本地模式：

1
2
ws://127.0.0.1:18789

从这一步开始，系统的形态就变了：不是 “每个端直连各自后端”，而是 “所有端都接入同一个控制平面”。

三、整体架构：Gateway 作为 “唯一事实源”

想象一下拓扑结构：它不是网状互连，而是典型的 Hub & Spoke（星形拓扑）：

这里的关键点不是 “都能连上”，而是 Gateway 变成唯一事实源（Single Source of Truth）：

  • 会话状态在它这里统一收敛

  • 任务执行进度在它这里统一编排

  • 事件在它这里统一广播或定向分发

  • 客户端越做越薄：只负责输入与渲染，不各自维护复杂状态机

你会发现一个非常工程化的收益：扩展新入口 ≠ 重写 Agent 逻辑。

新接一个 Telegram bot，本质上是多了一个 “节点”，而不是多了一套 “系统”。

四、把 Gateway 拆开看：它到底做哪些事？

从职责上，Gateway 可以拆成三块核心角色：

1）连接中枢：Connection Manager

它解决 “多端同时在线” 带来的现实问题：

  • 客户端注册与认证（谁是谁）

  • 心跳检测、断线重连（连接是否可信）

  • 会话生命周期管理（上线、离线、切换设备）

如果你做过移动端就会懂：网络切换、后台挂起、代理变化，都会让连接状态充满 “脏边界”。没有一个统一的连接管理层，状态漂移是必然的。

2）消息路由中枢：Message Router

控制平面必须能做的不只是转发，而是 “聪明地分发”：

  • 请求分发 / 响应回传（谁发起，谁接收）

  • 单播 / 多播 / 广播（一个事件同步多端）

  • 优先级队列（例如中断、取消要比普通消息更高优先级）

3）状态协调器：State Coordinator

这是真正决定 “多端是否一致” 的部分：

  • 全局状态同步（同一 Session 在不同端展示一致）

  • 事件驱动模型（任何状态变化都以事件形式传播）

  • 冲突解决（两个端同时操作时怎么处理）

你可以把它理解成 “对话与任务的调度大脑”：它不执行工具，但它知道谁在执行、执行到了哪一步、结果应该广播给谁。

五、协议层怎么设计：JSON-RPC + 命名空间

多端统一，协议一定要足够 “规整”。OpenClaw 采用的思路是：JSON-RPC 2.0 + 命名空间。

调用看起来像这样：

1
2
3
4
5
6
7

{
  "jsonrpc": "2.0",
  "method": "chat.sendMessage",
  "params": { "peer": "tg:12345", "text": "Hello" }
}

用命名空间把系统能力分组，常见的会有：

  • chat.*：消息发送、会话管理、typing 等

  • agent.*：Agent 编排、任务启动 / 取消、工具调用触发

  • node.*：节点注册、能力上报、心跳与状态

  • browser.*：自动化控制、DOM / 截图回传

  • system.* / debug.*：系统级能力与诊断

这类协议的价值在于：它不像 “拼凑的事件名”，而是一套可演进的 API 面。后续加新端、新能力，靠扩展 method 就能自然生长。

六、节点接入：设备不是 “客户端”，而是 “Node”

OpenClaw 的一个很重要的抽象是：每个设备 / 入口都是节点（Node）。节点接入时不仅连接，还要声明能力（capabilities）。

比如 iOS 节点：

1
2
3

{"capabilities": ["camera", "location", "notification"]}

CLI 节点：

1
2
3

{"capabilities": ["exec", "file_read"]}

Gateway 维护一张 “能力感知路由表”：当 Agent 需要“定位” 或“拍照”，它不会盲目广播给所有端，而是路由到具备对应能力的节点。这比 “写死某个平台负责某件事” 更灵活，也更符合多设备协作的现实。

七、多端细节：看起来像接入，实际上是治理

把几个典型端拆开，你会发现每个端的难点都不一样，而统一控制平面恰好能 “把难点收敛到一个地方”。

1）CLI 节点

CLI 的挑战不是连接，而是 “交互节奏”：

  • 输入是行式的，但输出可能是流式的

  • Ctrl+C 不是 “退出程序”，可能是 “中断当前任务”

  • 终端要实时回显，同时不能把状态搞乱

有了 Gateway，CLI 只需要把输入包装成控制消息，订阅对应 Session 的事件流就行：流式 token 直接推回来，取消 / 中断也有统一语义。

2）WebChat 节点

WebChat 的痛点集中在 “连接波动与 UI 一致性”：

  • 断线重连后怎么补发 / 补拉消息？

  • 多标签页如何保持一致？

  • typing indicator 与任务进度如何实时展示？

这些都更适合用事件流（WebSocket）做，而不是靠轮询补丁。

3）macOS / iOS / Android 节点

移动端更 “脏”：

  • 网络频繁切换（Wi-Fi/4G/5G）

  • 后台挂起导致连接断开

  • 系统限制让长连接不稳定

通常需要：自适应重连、离线消息队列、以及设备配对机制（比如 6 位验证码）来建立可信关系。控制平面统一后，这些机制不用每个业务重复造轮子。

4）浏览器自动化节点

浏览器自动化（Puppeteer/Playwright）本质上是 “执行器”，它要上报：

  • DOM 变化、执行日志

  • 截图、页面状态

  • 步骤进度与失败原因

更重要的是：人类操作与 Agent 操作可以共存于同一 Session。

比如用户在网页上手动点了一下，Agent 继续接管；或者 Agent 正在跑流程，用户从手机端发来 “暂停”。这些协作都需要一个统一的状态协调器，否则你很快会陷入“到底谁在控制” 的混乱。

八、多消息通道统一：把 WhatsApp/Telegram/Slack 当成同一种 “表面”

接入消息通道最容易掉坑：每个平台一套 webhook、回调、签名、消息格式…… 最后你会在业务里写满 if/else。

控制平面的做法是先统一消息骨架，例如：

1
2
3
4
5
6
7
8
9

{
  "id": "unique-msg-id",
  "type": "request|response|event",
  "channel": "cli|webchat|mobile|browser",
  "payload": {},
  "metadata": {}
}

然后再做三件事：

  • 版本协商与向后兼容：协议升级不拖垮旧端

  • 通道隔离与互通：命名空间隔离 + 权限控制，但事件可跨通道同步

  • 可靠性：ACK、超时重试、离线持久化、历史回放

这样一来，“从 Telegram 发来的消息”和 “从 WebChat 发来的消息” 对系统来说都只是同一种控制事件。通道差异被压到边缘层，不会污染核心逻辑。

九、两段实战流转：你才能真正理解它为什么值

案例一：CLI 发起任务，多端同步

  1. CLI 输入 prompt，发出 chat.sendMessage

  2. Gateway 接收后路由到 Agent（或触发 Agent 编排）

  3. 模型开始流式返回

  4. Gateway 把 token / 进度以事件形式广播到同一 Session 的订阅者

  5. WebChat、Mobile 同步展示同一条流式回复

这里最关键的是：状态不在客户端拼凑，而在 Gateway 统一生产与分发。多端只是 “不同的显示器”。

案例二：WebChat 下发浏览器自动化

  1. 用户在 WebChat 输入：“帮我登录并截图订单页”

  2. Gateway 判断需要 browser.* 能力，调度 Browser Node

  3. Playwright 执行，过程中持续上报步骤事件与截图

  4. Gateway 把截图 / 进度推送给所有相关端

  5. 手机端也能看到同一张截图、同一个进度条，必要时还能发 “停止”

这就是控制平面的力量：它把 “任务执行” 变成一个可观测、可中断、可协作的流程，而不是某个端里黑盒跑完再回一句“好了”。

十、安全、可观测与扩展：控制中枢必须可治理

一个统一入口带来的另一个必然要求是：它必须可治理。

  • 安全模型：local-only、token、tailscale 等多模式；配合细粒度权限（admin/read/write/pairing）

  • 可观测性：全链路 tracing、实时指标、统一日志；否则多端协作问题根本查不清

  • 扩展性：新增节点 = 新增能力声明 + 新增命名空间方法，不需要改动核心会话模型

当系统规模变大，你会发现 “可观测性” 不是锦上添花，而是你能否继续演进的前提。

十一、总结

下一代 AI 系统拼的不是模型，而是 “中枢神经系统”。

模型能力正在趋同，这几乎是确定趋势。真正拉开差距的，会越来越集中在架构抽象：你的 AI 是一堆入口的拼盘，还是一个能跨端协作、状态一致、可调度可治理的系统？

OpenClaw 的启示很明确： 把 Session 当作一等公民，把控制平面从各端抽出来，用一个 WebSocket Gateway 统一所有 AI 交互。

当你做到这一点，CLI、WebChat、移动端、浏览器自动化、消息通道就不再是 “多个产品”，而只是同一个系统伸出的不同触角。系统的整体性，从此开始出现。