2026 OpenClaw「通道在线但不回复」排查手册：pairing、requireMention、Discord intents / Slack 权限与网关日志分层对照（Mac VPS 7×24）
Dashboard 与 channels status 都绿，用户却收不到一句回复——这类「假在线」在 Mac VPS 7×24 场景里极常见，根因却往往不在模型。本文把排障拆成三层：IM 与 Bot 策略（pairing、requireMention、intents、Slack 安装范围）、网关投递与鉴权（probe、doctor、18789、Token）、模型与配额（429、长上下文）。你将拿到一张现象对照表、六步可复现 Runbook、三条可写进评审的硬指标，以及 FAQ；并与站内 mention/pairing 清单、heartbeat 静默、429 分流 形成互补阅读。
1. 三类痛点：为什么「在线」不等于「能回复」
许多团队把「通道已连接」理解成整条链路畅通，但在 OpenClaw 架构里，IM 平台是否把消息交给 Bot、网关是否把会话交给模型、模型是否成功返回是三个可独立失败的阶段；Dashboard 上的绿灯通常只证明其中一段。
- 策略层静默丢弃：
requireMention、群白名单、或「仅处理线程内回复」类规则会让消息在到达模型前被吃掉；私聊无 @ 约束时常表现为「私聊正常、群聊装死」。若同一 Bot 在多群表现不一致，还要怀疑分房间覆盖配置是否遗留旧值。 - pairing 与信任边界：新成员或新会话可能停在 pending；在未
pairing approve或等效放行前，网关不会向下游投递。连接测试仍可通过，因为握手与心跳走的是另一路径。升级后默认值漂移时，这类问题会突然「集体复发」。 - 平台权限与 intents 缺口：Discord 未开启
Message Content Intent、Bot 未加入频道、Slack 重授权遗漏事件订阅范围时，常出现「入站偶现、出站失败」或平台侧静默丢包。与网关崩溃不同，CPU 与内存曲线往往仍很平稳，容易误判为模型抽风。
若你已在 Mac 云上跑 launchd，还要额外警惕环境变量切片：手工 SSH 登录后执行的 openclaw 与守护进程读取的 HOME、PATH 不一致时，会出现「命令行全绿、守护进程旧配置」的假一致。
2. 现象—根因—验证：对照表
先把现象钉在层位上，再选工具；避免一上来换模型或清缓存。
| 现象 | 优先层位 | 首选验证 | 可先排除 |
|---|---|---|---|
| 仅群聊无回 | 策略层（mention/房间规则） | 群内带 @ 短句 A/B | 整站 API Key 吊销 |
| 新成员无回、老人正常 | pairing 队列 | pairing list / approve 演练 | 磁盘满 |
| Discord 仅服务器频道无声 | intents / 角色 / 可见性 | 开发者门户对照表 | 网关端口随机占用 |
| Slack 偶发「已读不回」 | 事件订阅 URL / Workspace 安装范围 | 重授权 + 事件投递日志 | 模型 temperature |
| 全通道无回且日志含 429 | 模型与配额 | Provider 控制台与降级策略 | pairing 全量清空 |
3. 六步 Runbook：从 probe 到模型分流
建议在变更窗口单变量执行，每步记录时间戳与命令输出片段，便于次日对照。
- 通道探针：执行
openclaw channels status --probe，确认 RPC 与通道握手；若此处失败，先停在下文「网关层」。 - pairing 审计：
pairing list查看 pending；对新协作流明确「谁有权 approve」，避免把审批链绑在单人日历上。 - 策略核对：导出当前 messaging 相关配置，显式标注
requireMention、群白名单与线程策略；与产品文档对齐「群内必须 @」的运营承诺。 - 平台权限矩阵：Discord 勾选必要 intents，Slack 校验
chat:write、事件订阅与重定向 URL 是否指向当前网关公网入口。 - 网关自检：
openclaw doctor与openclaw gateway status（必要时--deep）对照官方 command ladder；Mac VPS 上同时核对 launchd plist 的EnvironmentVariables是否与交互 shell 一致。 - 模型分流：若前五步无异常，再查看 Provider 429、长上下文与工具调用门禁日志，与 429 分流文 对齐降级策略，避免把配额问题误装成「通道坏了」。
openclaw channels status --probe
openclaw pairing list
openclaw doctor
openclaw gateway status
4. 三条可引用指标
- probe 失败率：在固定窗口内
channels status --probe失败次数上升，而 CPU 平稳，优先怀疑 Token / URL / 平台侧限流，而非模型。 - pending pairing 深度：pending 队列长期大于零说明审批或通知链路与人因耦合过大，需要制度化而不仅是临时清队列。
- 群/私聊成功率差：若群消息到达率显著低于私聊，九成可收敛到 mention 与可见性，而非「再买一台 Mac」。
5. FAQ
问：要不要先重启网关？ 若 probe 与 doctor 均无红项，盲目重启往往只重置短时缓存，掩盖未保存的配置漂移；先完成表格分层更省时间。
问：多通道并行时如何缩小爆炸半径？ 先在非生产 Slack/Discord 工作区复现，再切流量；保留一份「仅启用单通道」的最小配置用于对照。
问：和 Matrix 插件混布会干扰判断吗？ 会。建议排障期暂时只保留一条 IM 通道作为金线，确认无回消失后再逐步打开其它通道。
6. 结论
「在线但不回」多数是策略与权限在网关之前拦截，而不是模型突然变笨；把三层拆清，才能把 Mac VPS 上的 7×24 值班从「玄学重启」变成可审计流程。
仅依赖桌面会话或临时容器很难稳定复现 launchd 与 IM 回调的组合边界；在自家笔记本上「好像能跑」也不等于生产网关配置已对齐。要在可预测的 Apple Silicon 环境里把网关、通道与模型日志钉在同一套路径上，租赁 VPSMAC 的 Mac 云节点，用 SSH 与 plist 固化运行身份，通常比在通用笔记本或混用环境里反复试错更接近问题本质。