🚀 本文收录于Github：AI-From-Zero 项目 —— 一个从零开始系统学习 AI 的知识库。如果觉得有帮助，欢迎 ⭐ Star 支持！

为什么OpenClaw在实时推送场景下选择拥抱WebSocket？

by @Laizhuocheng

---

一、Agent的工作模型倒逼技术选型

因为Agent的工作方式是流式的、双向的、多客户端的——而这三点，HTTP轮询从设计上就满足不了。

说人话就是： 想象你正在看一场现场直播，而不是录播视频。直播需要实时传输每一帧画面，观众可以随时发送弹幕互动，多个观众看到的是同步的内容。OpenClaw的Agent就像这场直播——它的推理过程是连续的事件流，用户需要实时看到进展，多个客户端需要同步状态。

OpenClaw的Gateway运行在ws://127.0.0.1:18789，CLI、WebChat UI、macOS App、iOS/Android Node全都通过WebSocket连到这个控制平面。这不是随手选的技术，而是Agent运行模型倒逼出来的结论。

当你发一条消息给OpenClaw，Brain进入ReAct推理循环：Thought → Action → Observation → Thought……这个过程可能持续几秒到几十秒，中间会不断产生中间状态。如果用HTTP请求-响应，你只能等整个循环跑完拿到最终结果；用WebSocket，Gateway可以把每一步的状态实时流向所有连接中的客户端——这就是你在Telegram看到"正在思考"的原因。

---

二、HTTP轮询的根本性局限

HTTP轮询能用，但代价完全不值得付：

短轮询的问题

• 99%的请求换来空响应
• 每次都要重新走TCP握手和HTTP头解析
• 推理过程30秒，轮询间隔1秒就有30次空请求
• 设5秒延迟又高得难以接受

长轮询的妥协

长轮询是OpenClaw在Telegram通道上的选择——但这是一个刻意的权衡，不是通用最优解。Telegram Bot的长轮询模式之所以适合，是因为本地部署场景下无需公网IP、无需HTTPS证书，零配置开箱即用。

但长轮询本质上仍然是"等服务端回应后立刻发下一个请求"，本地维持一条连接的逻辑比较绕，高并发下服务端也需要维持大量挂起的连接。

---

三、OpenClaw的通信模型分析

要理解为什么选WebSocket，先得看清楚OpenClaw的消息流长什么样。

外部渠道（Telegram/WhatsApp） → HTTP → Gateway ← WebSocket ← 内部客户端（CLI/WebChat/App）
                                    ↓
                                  Brain
                                    ↓  
                           推理状态广播 → 所有连接客户端

注意图里有个细节：Telegram和WhatsApp走的是HTTP，CLI/WebChat/App走的是WebSocket。这不是矛盾，而是各归其位——外部平台的协议由平台决定，OpenClaw自己控制的通道全部选择了WebSocket。

Gateway在这里不是消息转发器，而是整个系统的神经中枢：它接收来自各个渠道的输入，驱动Brain推理，再把推理过程中产生的每一个中间状态实时广播出去。这个"实时广播"的需求，是选型的核心出发点。

---

四、三个具体场景，三个"HTTP做不到"的理由

场景一：流式推理输出

Brain执行一次任务的过程不是"输入 → 等 → 输出"，而是连续的状态机：

Thought: 用户想看PR列表，需要调用github skill
Action: exec("gh pr list --state open --json number,title,author")
Observation: [{"number":42,"title":"Fix login bug"...}]
Thought: 拿到数据了，整理成自然语言回复
Final Answer: "当前有3个open PR..."

每一步都是一个事件。WebSocket让这些事件实时流向客户端，用户能看到Agent"正在干什么"，而不是盯着转圈等结果。HTTP做不到这个——你必须等整条链路跑完，才能发出那个唯一的响应。

场景二：双向确认交互

Heartbeat触发了一个定时任务，任务执行到一半发现需要合并一个PR，OpenClaw需要向用户确认："要不要merge #42？“用户回复"可以”，任务继续执行，最终结果回推。

这整个过程里，服务端和客户端都需要随时主动发消息。HTTP的单向性（服务端不能主动发）在这里根本撑不住——你必须用轮询来"模拟"服务端的主动推，而WebSocket原生就支持。

场景三：多客户端状态同步

你同时在手机Telegram发了一条消息，在电脑上的WebChat看进度。Gateway通过WebSocket把同一个Agent的执行状态广播给所有已连接的客户端——Telegram那边显示"正在执行"，WebChat这边同步更新，两边看到的是同一个任务的同一个进度。

轮询方案里，每个客户端只能各自问、各自拿，状态同步需要额外的协调层。

---

五、方案对比：为什么WebSocket是唯一选择

特性	短轮询	长轮询	WebSocket
服务端主动推	✗	△ 模拟	✓ 原生
流式中间状态	✗	✗	✓
双向通信	✗	✗	✓
多客户端广播	需要额外层	需要额外层	原生支持
连接开销	高（每次重建）	中	低（一次握手）
OpenClaw用在哪	不用	Telegram通道	CLI/WebChat/App

---

六、不可忽视的代价：断线重连

WebSocket不是没有成本。选择持久连接，就必须认真处理"连接断了怎么办"。

断线原因

• 移动网络切换
• 服务端重启
• 网络抖动

解决方案

一个生产可用的客户端必须实现：

• 指数退避重连：避免频繁重连消耗资源
• 状态重新同步：重连后恢复到正确状态
• 消息去重机制：防止重复处理同一消息

OpenClaw本地运行的场景下，这个问题相对简单——主要是Gateway重启。但如果通过Tailscale Funnel把Gateway暴露到公网，移动客户端就必须把断线重连做扎实。

---

七、核心结论：匹配约束而非追求最优

OpenClaw的选择不是"WebSocket在所有场景都比轮询好"——Telegram通道至今用的还是long polling，因为那个场景下零配置比低延迟更重要。

技术选型从来不是找最优解，而是找最匹配约束的解。Agent的流式推理、双向交互、多客户端同步这三个约束加在一起，WebSocket是唯一能同时满足的方案。

选型哲学

• 外部渠道：遵循平台约束，用HTTP轮询
• 内部通道：发挥技术优势，用WebSocket
• 混合架构：不同场景用不同方案，不做一刀切

这种务实的选型思路，正是OpenClaw能在保持简单性的同时提供强大功能的关键。WebSocket不是银弹，但在Agent的实时推送场景下，它是最匹配的答案。