从 OpenClaw 的接入方式，看通信模型的选择逻辑
最近在把 OpenClaw 接到不同设备和渠道上的时候，我开始系统性地梳理这些通信方式。一开始只是为了搞清楚每个渠道怎么连上去，后来发现不同平台选择接入方式其实就是在解决完全不同的前提和场景。
Bot 通信的三种基本模式
在深入之前，我们需要先理解几个基础通信概念。
Webhook：推送模型的起点
平台主动把消息“推”给你的服务器。就像你点了外卖，骑手送到你家门口按门铃（推送），而不是你每隔 5 分钟去楼下看一次（轮询）。
技术特点：
- 实时性高：消息一来立即送达
- 需要公网 IP 或域名：平台要能找到你的服务器
- 服务器压力小：只有消息时才处理
Long Polling：被误解的“伪实时”
你的服务器向平台发起请求，平台会保持这个连接不返回，直到有消息时才响应，然后客户端再发起下一次请求。
更准确地说，它不是“不断轮询”，而是：
一种“串行的长连接请求”模型
就好像你打电话问朋友“到了吗”，对方说“等着，到了我告诉你”，你们一直保持通话。
技术特点：
- 实时性较好：接近实时，但略有延迟
- 不需要公网 IP：适合本地部署
- 服务器压力中等：需要维持长时间请求
WebSocket：真正的双向通道
建立一个持久化的双向通道，双方可以随时发送消息。就像两个人开着语音通话，随时说话对方都能听到。
技术特点：
- 双向实时通信：客户端和服务端都可以主动发送
- 适合高频交互：聊天、游戏、实时数据
- 实现复杂：需要处理连接状态、心跳、重连等
SSE：HTTP 世界里的流式方案
SSE（Server-Sent Events）是一种基于 HTTP 的通信方式，服务器可以在连接建立后持续向客户端推送数据。就像打开了一个一直不挂断的“信息广播频道”，服务端一有新内容就往里发，你只负责接收。与传统请求不同，它的连接一旦建立，就会保持打开状态，数据以“流”的形式不断发送。
技术特点：
- 单向通信（服务器 → 客户端）
- 自动重连（浏览器原生支持）
- 基于 HTTP，兼容性强
OpenClaw 的通信渠道
OpenClaw 支持多个通信平台，但这些平台的差异，并不只是接入方式不同，更在于它们对“事件”和“交互”的抽象方式不同。这里有两个概念：
- 通信方式：消息是怎么送过来的
- 事件模型：这条消息代表什么
通信方式像是“快递”，而事件更像是“信的内容”。同样是通过 Webhook 接入，- 有的平台只告诉你“收到了一段文本”，有的平台会明确告诉你-用户发了一条消息，点击了一次按钮，某个流程的状态发生了变化。
官方 Bot API ：通信与事件模型都比较完整
这些平台不仅提供稳定的接入方式，同时也定义了清晰的事件模型，是最适合构建 Agent 的基础设施。
|平台|通信方式|事件模型|交互能力|特点| |—|—|—|—|—| |Telegram|Webhook / Long Polling|Update（消息驱动）|⭐⭐⭐|简单直接| |Slack|Webhook / Socket Mode|Event（完整事件体系）|⭐⭐⭐⭐|强交互| |Discord|WebSocket|Gateway Event|⭐⭐⭐⭐|实时性强| |飞书|Webhook|Event（消息 / 卡片 / 审批）|⭐⭐⭐⭐|强业务集成| |Google Chat|Webhook|Message Event|⭐⭐⭐|轻量| |Microsoft Teams|HTTPS|Activity Event|⭐⭐⭐⭐|企业集成| 这一类平台的好处是它们已经帮你定义好了“事件”。
非官方接入：有通信，但缺少稳定的事件抽象
这类平台通常没有完整的 Bot API，需要通过协议模拟或封装实现接入。
| 平台 | 通信方式 | 你拿到的数据 | 交互能力 | | ——– | ————- | ——– | —- | | WhatsApp | 长连接（模拟 Web 端） | 原始消息内容 | ⭐⭐⭐ | | Signal | 本地工具转发 | 原始消息内容 | ⭐⭐ | | iMessage | 系统通知转发 | 系统消息 | ⭐⭐ | | 微信（个人号） | 模拟客户端或自动化操作 | 抓取到的消息内容 | ⭐⭐⭐ | 这一类的核心问题是：通信可以实现，但事件模型是“推断出来的”，需要用户自己去判断这是普通消息还是指令，是输入还是状态变化。
开放协议：通信与事件都不绑定平台
还有一类方案不依赖具体产品，而是基于开放协议：
|平台|通信方式|事件模型|特点| |—|—|—|—| |Matrix|HTTP / WebSocket|标准化事件结构|可自建| |IRC|TCP Socket|简单消息模型|极简| |Mattermost|HTTP / WebSocket|类 Slack 事件模型|开源| 这一类的特点是通信能力和事件定义都不依赖某一个具体平台，而是由协议本身决定。。
不同通信模型的设计取舍
同样是做通信，不同平台选择的模型其实差异很大。这些差异往往不是技术能力的问题，而是取决于它们要解决的核心场景。
以 Telegram 为例，它的设计重点并不在“实时性有多强”，而在于让开发者更简便地接入到平台。
Webhook 从技术上看是更干净的方案。平台有事件时直接把数据推过来，不需要额外请求，也不会产生无效流量。但它隐含了一个前提：你的服务必须是“对外可访问的”。换句话说，Telegram 要能主动连到你。这通常意味着你需要一个公网地址、一个稳定运行的服务，以及能够处理外部请求的能力。
但现实情况是，很多开发者并不在这样的环境里工作。很多 bot 是直接跑在本地电脑上的，或者在内网机器里，甚至只是一个临时运行的脚本。在这种情况下，平台根本无法“找到你”。
Long Polling 解决的正是这个问题。它把原本平台主动推送的过程，变成了客户端持续去等待结果。请求由你发起，连接始终是向外的，这样就绕开了“必须被公网访问”的限制。从实现上看，它只是把 HTTP 请求保持住，等有数据再返回，然后立即发起下一次请求。
这其实是一种很典型的工程取舍：它牺牲了一部分效率（会有重复请求和连接开销），但换来了对运行环境的极强适应性。Telegram 同时提供 Webhook 和 Long Polling，本质上就是为了提供更简便的接入环境。
理解了这一点，再看 Discord 的选择，就是基于它平台的特色：假设客户端长期在线并且持续参与交互。因此它直接使用 WebSocket，在这种模型下，通信不再是“请求和响应”，而是一个持续存在的事件流。消息、状态变化、用户行为都通过同一个连接实时推送。这种设计适合高频交互、多用户同步的场景，比如聊天室、社区或者协作工具。相比之下，如果用 Long Polling，不仅效率低，而且很难表达这种“持续在线”的状态。
再看 SSE，它的出现又是另一种取舍，这个是rokid glasses的接入方案。你在眼镜这种设备上看到的 AI 输出，本质上并不是“交互”(眼镜的交互模式非常有限），而是“内容在不断生成”。在这种场景里，用户并不需要一个双向通道，也不需要复杂的状态同步，只需要一条稳定的“输出管道”。SSE 正保留了 HTTP 的简单性，同时允许数据以流的形式持续发送。它本质上就是把“响应”延长成一条持续的数据流。
| 模型 | 典型平台 | 解决的核心问题 | 前提 | 代价 |
|---|---|---|---|---|
| Webhook | Telegram（生产环境） | 如何高效接收事件 | 服务可被公网访问 | 部署复杂 |
| Long Polling | Telegram（开发环境） | 如何在任意环境接入 | 客户端可以主动请求 | 资源效率较低 |
| WebSocket | Discord | 如何维持实时交互 | 客户端长期在线 | 实现复杂 |
| SSE | 浏览器 / Rokid / AI流式接口 | 如何持续输出数据 | 单向输出即可 | 不支持双向 |
在 AI 时代，工具和框架会越来越多，表面上的选择也会越来越复杂，作为技术人员一方面，需要对底层原理有足够清晰的理解。不是为了记住每一种技术细节，而是能够看清它解决的是什么问题，它依赖的前提是什么；另一方面，更重要的是，要习惯去分析这些技术选择背后的逻辑。 很多时候，技术本身并不复杂，复杂的是我们是否看清了它所对应的场景。 而这件事，可能是现在每一个工程师都应该刻意去训练的能力。