最小权限矩阵 · channels status 与探针 · 回调与 WebSocket · 在线无回复分流
已经能在本机拉起 OpenClaw Gateway、却要在 Slack、Discord、Telegram 上稳定收发的团队，最常踩的坑不是模型不够强，而是平台权限、事件订阅、Webhook 回调可达与反向代理上的 WebSocket 升级没对齐，于是出现「channels 显示在线但消息石沉大海」的假健康。本文把三通道最小权限与管理员动作矩阵、从官方诊断到探针的逐步判据、回调与 TLS 常见 4xx/5xx 对照，以及在线不回时的检查顺序：线程上下文、速率限制、工具失败与模型配额串成可复现 Runbook；并与生产加固、运行期排障、安装与 doctor互链，便于把问题收敛在通道层而不是盲调模型。
多数团队把「能收到一条测试消息」当成上线标准，却忽略事件订阅不完整、Bot 令牌轮换、回调 URL 在反代后丢失 Upgrade、以及频道级速率与线程上下文等长尾问题；与三段式排障一致，证据链必须先分层，否则你会在模型侧看到大量「无意义重试」。下面五条是 2026 年最常见的返工来源，建议写成评审表逐项勾选。
权限缺口税：Slack 缺 chat:write 或事件未订阅 message.channels；Discord 未开 Message Content Intent；Telegram 未把命令或 webhook secret 对齐，表现为偶发收得到却回不出。
回调路径税：公网入口、证书链、HSTS 与反代超时组合问题，让平台侧判定你的 Gateway「不可达」，channels 状态却仍可能短暂显示已连接。
反代 WebSocket 税：只转发了 HTTP 而未放行 Upgrade 与 Connection，Discord 与部分 Slack 交互路径会出现握手成功但消息不同步。
线程与上下文税：在 Slack 线程里触发却在主频道等待回复，或 Telegram 更新 offset 未提交导致重复处理与自我阻塞。
观测混责税：把通道重试、工具失败与 429 记在同一告警里，排障只能扩大重启范围；与白名单与审计表强调的字段最小集相冲突。
当你把以上五条映射到「谁负责改：平台管理员 / 基础设施 / OpenClaw 配置」三列，就能把扯皮时间从半天压到一小时量级；若仍卡住，请回到安装与 doctor核对运行时与版本，再进入下一节权限矩阵。
这张表的意图不是替官方文档逐字背书，而是给你可勾选的评审清单：任何一列留空，都可能在生产流量下被放大成「偶发无回复」。实际 scope 名称以各平台当时控制台为准，但检查顺序应当固定：先身份与权限，再事件订阅，再回调 URL。
| 平台 | 最小 Bot 能力 | 管理员必须动作 |
|---|---|---|
| Slack | 频道消息读写、应用级令牌轮换、事件订阅覆盖目标频道类型；需要时使用 Socket Mode 时另审隧道 | 安装应用到工作区、授权频道、把事件请求 URL 指到可达 HTTPS、在审计日志里确认订阅变更 |
| Discord | Server Members 读权限按需开启；Message Content Intent；与应用命令或斜杠命令注册一致 | 在开发者门户勾选意图、把 Bot 拉进目标服务器并授予频道权限、校验 Gateway 意图与分片连接稳定 |
| Telegram | BotFather 令牌、Webhook 或长轮询二选一；命令白名单与隐私模式策略 | 设置 webhook、保存 secret token、在防火墙放行平台出口 IP 段并记录变更窗口 |
通道问题几乎总能还原成「权限、回调、订阅」三件事之一；模型问题应当排在它们之后。
若你已经在做生产加固，请把本表与监听地址、反向代理和 TLS 章节放在同一变更单里评审，避免「加固做了但通道仍半残」的半截交付。
下面六步假设你使用 OpenClaw 官方或兼容 CLI；子命令名称可能随版本调整，但判据顺序不要调换：先确认进程与配置可读，再确认通道注册表，再做对外探针，最后才看模型路由。与运行期排障组合时，请把每一步的控制台输出保存为同一份工单附件。
确认 Gateway 配置落盘：核对配置文件路径、环境变量注入与权限，避免「终端里能跑、守护进程读不到」。
执行通道列举：用官方提供的通道列表或 status 子命令确认三类 IM 是否都注册成功、是否有重复条目。
对照 health：区分进程存活、端口监听与外部回调可达三类健康信号，禁止混在一个布尔值里。
发起探针：对公开入口做 TLS 与 HTTP 语义探活，记录状态码与耗时；必要时从外网 VPS 复测消除本地网络偏差。
试发送与回执：用最小消息验证入站与出站各一次，确认事件 ID 或 update id 单调递增。
落审计字段：把通道 ID、重试次数与最后错误码写入日志，便于与模型侧 request_id 关联。
# 示例：先列通道再探针（命令以你安装的 CLI 为准）
openclaw channels status --json
openclaw channels probe slack --timeout 15s
openclaw channels probe discord --timeout 15s
curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://your-public-host/openclaw/callback
提示：若 probe 成功但真实消息仍失败，优先查事件订阅与频道授权，而不是改模型温度。
这一节只回答「平台能不能把你的入口当合法后端」；一旦这里失败，模型再强也不会被调用。请把下列代码与 TLS 症状和运维动作绑定到同一张变更记录上，与加固清单中的 TLS 段落交叉验证。
| 症状 | 更可能原因 | 修复动作 |
|---|---|---|
| 401/403 | 签名校验失败、时钟漂移、或反代剥离了必需头 | 对齐服务器 NTP、恢复平台要求的头字段、轮换密钥后全链路重放一次测试 |
| 404/405 | 路径未挂载到正确进程或 HTTP 方法不匹配 | 核对 Ingress 规则与 Gateway 路由表，打印命中路径 |
| 502/504 | 上游超时、连接池耗尽、或 cold start | 上调反代超时、为 Gateway 进程设最小副本、加健康检查摘除 |
| 握手成功但消息不同步 | WebSocket 升级被拦截或 HTTP/2 与 WS 路径冲突 | 为 WS 路径单独 location，显式传递 Upgrade 与 Connection |
先证 TLS：用外部扫描与证书透明度核对 SAN 与链完整性，避免「浏览器能开、平台回调被拒」。
再证路径：对回调 URL 做幂等 GET/POST 试跑，确认返回体符合平台重试策略。
最后证 WS：若平台使用长连接或 Socket Mode，检查企业防火墙与出站代理是否截断。
注意：在 Discord 场景中误关意图或权限会导致「偶发能读不能写」；这类问题重启模型无法缓解。
下列三条是 Agent 与 IM 通道联合运维时常用的经验区间，用于立项评审而非性能保证；你应用真实日志与账单替换数字。把它们写进 README，可显著减少「先重启试试」的无效操作。
| 团队规模 | 通道形态 | 更稳的第一选择 |
|---|---|---|
| ≤ 5 人 | 单工作区或单群 | 固定回调域名、单一反代、完整权限表与值班手册 |
| 6–20 人 | 多频道与自动化并存 | 分通道速率预算、线程策略与只读降级 |
| 20 人以上 | 多租户与审计 | 强制审计字段、令牌轮换与不可变变更记录 |
| 强合规 | 数据出境敏感 | 区域化部署、限制出站目的地、日志留存与责任人字段 |
个人笔记本与间歇在线机器在睡眠、系统更新与钥匙串隔离上会持续制造「假在线」；即便通道权限一次配对成功，底层不稳定也会让回调与健康检查失真。相较之下，可合同化的云端 Mac 常驻节点才能把 Gateway 进程、心跳与 SLA 落在可验收条款上。
常见误区：把「模型回复慢」当成首要优化对象；实际上大量工单在修完回调与意图后才需要讨论模型档与路由。
若团队希望 OpenClaw 在多条 IM 通道上可审计、可回滚、可对照 SLA 地运行，而本地开发机又无法满足 7×24 与固定公网入口，VpsMesh 的 Mac Mini 云端租赁通常是更优解：区域可选、节点专用、便于把回调与健康检查绑在稳定主机上，让「通道在线」与「消息真的在流动」一致，而不是互相矛盾。