写在前面
平台接入失败时，不要因为“平台没回复”就立刻怀疑整套安装。
你现在先做的是通道层分诊：
- 看渠道状态；
- 看消息有没有进入日志；
- 看问题卡在平台侧、入口规则，还是主进程。
第一步：先看渠道状态
执行：
openclaw channels status --probe
openclaw status --deep你现在要先回答：
- 当前渠道到底有没有连上；
- 链路是不是至少可读；
- 当前异常是单个渠道问题，还是整体运行状态就已经不稳。
如果连状态都读不清，就不要急着判断平台行为。
第二步：再区分入口规则问题
很多“已连接但不回复”的问题，其实不在主程序，而在入口规则。
尤其是私聊和群组混着测试时，更容易把这些问题混成一类：
- pairing 没批准；
- DM 策略没放开；
requireMention、allowlist 或其他门控没对齐；- 私聊和群组的预期行为本来就不同。
如果你还没有先把测试入口收缩到一个最小场景，现在先不要继续扩展。
第三步：看平台侧权限或事件设置
如果 OpenClaw 侧状态大致正常，但平台仍然不收、不发或行为异常，就优先怀疑平台侧。
这类问题在 Discord、飞书等变量更多的平台更常见，例如：
- Bot 权限不足；
- 平台事件或订阅没开；
- 回调条件不满足；
- 入口本身和你的测试场景不一致。
第四步：同步看日志
执行：
openclaw logs --follow重点不是看全量细节，而是看有没有这些信号：
- pairing 相关提示；
- allowlist 或 mention required 相关提示；
- 平台权限或
401、403类错误； - 主进程本身不稳定的信号。
如果平台侧没回复，但日志里已经有消息进入，问题多半不在“渠道根本没接上”。
如果日志里完全没有消息进入，优先回平台侧检查入口和事件。
一个够用的分诊原则
如果问题能压缩成“平台已连，但消息没闭环”，就继续留在通道层排查。
如果问题已经扩大成“状态本身都不稳定”，那就不要只盯平台页，应该回到启动或配置层继续查。
常见错误或风险
- 平台侧和 OpenClaw 侧同时改一大批设置；
- 私聊、群组、服务器三种场景一起测；
- 还没看最小日志就开始卸载；
- 把
connected误当成已经可用。
下一步
如果问题已经明确落在某个平台，回 渠道接入总览 下的对应页面。
如果你只想走更简洁的分诊入口，继续看 接入失败时怎么分类。