架构解析：Gateway 网关与消息渠道

Gateway：整个系统的"神经中枢"

OpenClaw 的核心是一个长期运行的 Gateway 网关进程：上游连接各聊天渠道，下游调度 Agent 与工具，本身以 WebSocket 协议对外服务，实现多端（手机、电脑、服务器）协同控制同一个助手。

WhatsApp(Baileys) ─┐
Telegram(grammY)  ─┤                     ┌─ Agent（模型推理）
Discord/Slack     ─┼─→ Gateway 网关 ─→ ┼─ 内置工具（文件/终端/浏览器）
iMessage/WebChat  ─┘    (WebSocket)      └─ Skills（技能扩展）

渠道接入方式

• WhatsApp：通过 Baileys 协议（非官方 API，扫码配对，类似 WhatsApp Web）；
• Telegram：官方 Bot API（grammY 框架），创建 Bot 拿 Token 填配置即可 —— 国内用户首选，最稳；
• Discord / Slack / Signal / iMessage / 网页聊天（WebChat）各有对应渠道插件。

安全模型：三条红线

• allowFrom 白名单：配置里限定哪些用户能指挥助手（channels.telegram.allowFrom），陌生私信一律拒绝 —— 第一次私聊还需要你手动批准；
• 本地边界：Gateway 只监听你配置的地址，默认不暴露公网；
• 警惕提示注入：消息渠道是不可信输入源，别人发的消息可能试图诱导你的助手执行危险操作 —— 白名单 + 最小权限工具配置是基本防线。

对比本站实战课《客服工单路由》：allowFrom 白名单本质上就是入口层的"意图路由 + 权限过滤"，思想完全一致。