渠道问题最容易让人误判。因为很多时候你会看到“机器人已经在群里”或“Bot 已经创建好了”，但它仍然不回消息。真正的根因往往不在“OpenClaw 完全坏了”，而是在登录、权限、提及规则、allowlist 或路由边界上。
推荐先跑的两个命令
openclaw channels status --probe
openclaw logs --follow
它们分别适合确认：
- 渠道当前是否真的在线
- 收到消息后 Gateway 到底发生了什么
先按“现象”判断问题在哪层
渠道问题看起来都像“不回消息”，但根因层级差很多。你可以先这么分：
- 根本收不到消息：优先看登录、token、会话
- 能收到但不回：优先看权限和触发规则
- 私聊能回，群里不回：优先看
requireMention、allowlist、群组策略 - 之前能回，后来突然不回：优先看凭据过期、会话失效或服务重连
先把问题归类，后面排查会清晰很多。
渠道问题最常见的根因
最常见的几类问题包括：
- 登录或 token 没完成
- 渠道凭据已失效
- 群组 / 频道权限不够
requireMention导致机器人在未被提及时不响应allowlist或pairing还没放行- Gateway 虽在运行，但没有正确接到该渠道事件
为什么“机器人在群里”不等于“机器人能回”
这只是说明它被加进去了，不代表：
- 它真的在线
- 它有权读取消息
- 它被允许回复
- 当前消息满足触发条件
例如在很多渠道里，默认就可能要求：
- 私聊先配对
- 群组必须
@提及 - 只允许特定用户或群组
所以“它已经在群里”只能证明接入流程走了一部分，不能证明回复链路已通。
排查时应该先分清哪一层出问题
第一层：在线状态
先确认渠道进程、token、会话和 Gateway 是否都正常。
第二层：权限
确认机器人是否真的能读消息、发消息、读取成员或读取内容。
第三层：触发规则
确认是不是当前群组配置要求：
@提及- allowlist
- pairing
- 特定 group policy
很多“它不回”的问题，最终其实都卡在第三层。
一个很实用的排查顺序
当你在某个群里发消息机器人不回时，建议按这个顺序：
openclaw channels status --probeopenclaw logs --follow- 确认群组 / 频道是否被允许
- 确认是否需要
@提及 - 确认私聊是否还在配对阶段
这个顺序能很快把“没登录”和“已登录但被规则拦住”区分开。
三个典型场景，怎么最快定位
场景一：私聊正常，群里不回
这种情况一般优先怀疑：
- 群组未进 allowlist
- 需要
@提及 - 当前群策略要求更严格
这时不要再去重配 token，重点看群规则。
场景二：昨天能用，今天突然不回
优先怀疑：
- 登录态失效
- token 过期
- 渠道连接掉线
- Gateway 重启后没有正确恢复会话
这类问题更像“连接状态变化”，不是“配置从一开始就错”。
场景三：日志里根本没有收到消息
那重点就不在回复逻辑，而在更前面：
- 渠道是否在线
- Webhook 或会话是否有效
- Bot 是否真的有读消息权限
一个很容易忽略的点：权限和触发条件不是一回事
很多人会把“我已经给它发消息了，它不回”全部归到权限问题，但有时候权限没问题，只是条件没满足。比如：
- 机器人可以读消息，但要求被
@ - 机器人可以回复私聊，但陌生用户未完成 pairing
- 机器人在线，但当前群不在 allowlist
这类情况本质上不是“坏了”，而是规则还没放行。
渠道排障时不要先改太多配置
更稳的方式是一次只验证一个变量：
- 先看渠道是否在线
- 再看单个聊天对象是否被允许
- 再看是否需要提及
- 最后才改群组策略和大范围 allowlist
如果一口气改很多项，后面很难知道到底是哪一步起了作用。
一个常见误区
不要把所有渠道都当成“加进去就会自动回复”的默认开放模式。OpenClaw 在很多渠道上的默认设计其实是偏保守的，这正是长期运行更安全的原因。
渠道问题的核心，不是盯着“为什么它没回”发愁，而是先问：消息有没有进来、它有没有权限、当前规则允不允许回。只要按“在线状态 -> 权限 -> 触发规则”这个顺序查，大多数渠道问题都能很快收敛到正确层级。