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

架构解析：OpenClaw 如何用一个 WebSocket 控制平面统一所有 AI 交互？ 架构解析：OpenClaw 如何用一个 WebSocket 控制平面统一所有 AI 交互？ Modified March 3 • 心跳检测、断线重连（连接是否可信） • 会话生命周期管理（上线、离线、切换设备） 如果你做过移动端就会懂：网络切换、后台挂起、代理变化，都会让连接状态充满“脏边界”。没有一个统一的连接管理层，状态漂移是必然的。 2）消息路由中枢：Message Router 控制平面必须能做的不只是转发，而是“聪明地分发”： • 请求分发 / 响应回传（谁发起，谁接收） • 单播 / 多播 / 广播（一个事件同步多端） • 优先级队列（例如中断、取消要比普通消息更高优先级） 3）状态协调器：State Coordinator 这是真正决定“多端是否一致”的部分： • 全局状态同步（同一 Session 在不同端展示一致） • 事件驱动模型（任何状态变化都以事件形式传播） • 冲突解决（两个端同时操作时怎么处理） 你可以把它理解成“对话与任务的调度大脑”：它不执行工具，但它知道谁在执行、执行到了哪一步、结果应该广播给谁。 五、协议层怎么设计：JSON RPC + 命名空间 多端统一，协议一定要足够“规整”。OpenClaw 采用的思路是： JSON RPC 2.0 + 命名空间 。 调用看起来像这样： Code block JSON Copy { "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 节点： Code block Plain Text Copy {"capabilities": ["camera", "location", "notification"]} CLI 节点： Code block Plain Text Copy {"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。 控制平面的做法是先统一消息骨架，例如： Code block JSON Copy { "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、移动端、浏览器自动化、消息通道就不再是“多个产品”，而只是同一个系统伸出的不同触角。系统的整体性，从此开始出现。 • 心跳检测、断线重连（连接是否可信） • 会话生命周期管理（上线、离线、切换设备） 如果你做过移动端就会懂：网络切换、后台挂起、代理变化，都会让连接状态充满“脏边界”。没有一个统一的连接管理层，状态漂移是必然的。 2）消息路由中枢：Message Router 控制平面必须能做的不只是转发，而是“聪明地分发”： • 请求分发 / 响应回传（谁发起，谁接收） • 单播 / 多播 / 广播（一个事件同步多端） • 优先级队列（例如中断、取消要比普通消息更高优先级） 3）状态协调器：State Coordinator 这是真正决定“多端是否一致”的部分： • 全局状态同步（同一 Session 在不同端展示一致） • 事件驱动模型（任何状态变化都以事件形式传播） • 冲突解决（两个端同时操作时怎么处理） 你可以把它理解成“对话与任务的调度大脑”：它不执行工具，但它知道谁在执行、执行到了哪一步、结果应该广播给谁。 五、协议层怎么设计：JSON RPC + 命名空间 多端统一，协议一定要足够“规整”。OpenClaw 采用的思路是： JSON RPC 2.0 + 命名空间 。 调用看起来像这样： 用命名空间把系统能力分组，常见的会有： • chat. ：消息发送、会话管理、typing 等 • agent. ：Agent 编排、任务启动/取消、工具调用触发 • node. ：节点注册、能力上报、心跳与状态 • browser. ：自动化控制、DOM/截图回传 • system. / debug. ：系统级能力与诊断 这类协议的价值在于：它不像“拼凑的事件名”，而是一套可演进的 API 面。后续加新端、新能力，靠扩展 method 就能自然生长。 六、节点接入：设备不是“客户端”，而是“Node” OpenClaw 的一个很重要的抽象是： 每个设备/入口都是节点（Node） 。节点接入时不仅连接，还要声明能力（capabilities）。 比如 iOS 节点： CLI 节点： 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。 控制平面的做法是先统一消息骨架，例如： 然后再做三件事： • 版本协商与向后兼容：协议升级不拖垮旧端 • 通道隔离与互通：命名空间隔离 + 权限控制，但事件可跨通道同步 • 可靠性：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、移动端、浏览器自动化、消息通道就不再是“多个产品”，而只是同一个系统伸出的不同触角。系统的整体性，从此开始出现。 🔗 原文链接： https://mp.weixin.qq.com/s/g dJK59u... https://mp.weixin.qq.com/s/g dJK59u... 智能体AI 智能体AI 多模态智能体2026年2月19日 10:11 湖南 🧑‍💻 小伙伴们也可以通过阿里云百炼Coding Plan 来部署： 首购低至 7.9 元，续费 5 折起，支持Qwen3.5、Qwen3 max、Qwen3 coder、GLM 5、GLM 4.7、Kimi k2.5等模型 👉戳链接直达：https://t.aliyun.com/U/0iiOuy 👉查看详细部署教程：https://t.aliyun.com/U/MNkA9b 最多三步，即可拥有 7x 24小时在线、随时响应的AI助手 小伙伴们也可以通过阿里云百炼Coding Plan 来部署： 首购低至 7.9 元，续费 5 折起，支持Qwen3.5、Qwen3 max、Qwen3 coder、GLM 5、GLM 4.7、Kimi k2.5等模型 👉戳链接直达：https://t.aliyun.com/U/0iiOuy 👉查看详细部署教程：https://t.aliyun.com/U/MNkA9b 最多三步，即可拥有 7x 24小时在线、随时响应的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、工具在持续汇报进度、用户随时插话、节点随时上报状态。全双工让“事件”成为一等公民。 2. 低延迟 + 长连接 流式输出、实时同步、typing indicator、任务状态更新，都需要持续连接和快速推送。 3. 跨平台一致 CLI、浏览器、移动端、桌面端——几乎都能稳定地做 WebSocket Client。你不需要为每个平台重新造一套通信栈。 OpenClaw 的做法是：让所有节点统一连到一个 Gateway，比如本地模式： 从这一步开始，系统的形态就变了：不是“每个端直连各自后端”，而是“所有端都接入同一个控制平面”。 三、整体架构：Gateway 作为“唯一事实源” 想象一下拓扑结构：它不是网状互连，而是典型的 Hub & Spoke（星形拓扑）： 这里的关键点不是“都能连上”，而是 Gateway 变成唯一事实源（Single Source of Truth） ： • 会话状态在它这里统一收敛 • 任务执行进度在它这里统一编排 • 事件在它这里统一广播或定向分发 • 客户端越做越薄：只负责输入与渲染，不各自维护复杂状态机 你会发现一个非常工程化的收益： 扩展新入口 ≠ 重写 Agent 逻辑 。 新接一个 Telegram bot，本质上是多了一个“节点”，而不是多了一套“系统”。 四、把 Gateway 拆开看：它到底做哪些事？ 从职责上，Gateway 可以拆成三块核心角色： 1）连接中枢：Connection Manager 它解决“多端同时在线”带来的现实问题： • 客户端注册与认证（谁是谁）