渠道
消息从哪儿来、最后回到哪儿去。比如飞书、Telegram、Discord、QQ、企业微信。
一句话总结
渠道只是入口，Gateway 才是总控。回复走哪、会话怎么分、哪个 agent 来答，以及为什么有时不回复，核心都和 Gateway 的确定性路由有关。把这层想清楚，后面的平台接入和排障会顺很多。
Gateway Logic
看懂 Gateway 以后，很多“为什么不回复”都会一下变清楚。
很多用户不是不会接平台，而是没把“渠道”“Gateway”“会话”“工作区”“回复策略”这几件事分开。结果就是平台明明连上了，却不知道为什么不回、为什么群聊和私聊表现不一样、为什么消息会落进不同会话。这篇就是把消息流一次讲清楚。
消息流解释页
最适合看懂排障逻辑
先理解再接平台
In One Sentence
先用一句话理解 Gateway
如果你只记住一句话，就记这个。
Gateway 是消息总控层
所有外部消息入口、会话归属、路由决策和回复出口，最后都由 Gateway 来统一决定。
模型不决定回到哪个平台
模型只负责思考和生成回复；决定消息去哪、落在哪个会话里的是 Gateway。
渠道只是入口
飞书、钉钉、Telegram、Discord 这些平台，本质上只是把消息送进 Gateway 的入口。
很多“不回复”其实是路由或策略问题
平台 connected 并不等于会自动回复，pairing、mention 和 policy 同样关键。
Core Concepts
先把 4 个最容易混的词分开
只要这 4 个词你分清了，后面几乎所有接入文档都会更好读。
Gateway
接住消息、做路由、维护连接状态和回复出口，是整个消息系统的总控层。
模型
负责理解消息和生成回复内容，但不负责决定“回哪个平台、进哪个会话”。
Skill / Tool
负责让回复具备能力，比如搜索、浏览器、自动化和扩展流程，但它们本身不是消息入口。
Message Flow
一条消息到底是怎么走完的
你把下面这个流程看懂，以后大多数问题都知道应该查哪一层。
第一步：平台发来消息
- 飞书私聊发来一条消息
- Discord 频道里提到 Bot
- Telegram 群里有人对机器人说话
第二步：Gateway 接住并路由
- 识别这是哪个渠道进来的
- 判断应该落到哪个 agent 和会话
- 把消息送到对应的 workspace / session store
第三步：生成回复并回原平台
- 模型和 Skills 处理消息
- Gateway 把结果发回原来的渠道
- 用户在原平台里看到回复
最关键的一点是：回复会回到消息原本来自的平台。它不是模型自己“猜测应该回哪里”，而是 Gateway 按确定性路由回去。
Session Logic
为什么私聊、群聊、线程不会混成一锅
这件事对实际使用体验影响非常大，也是很多用户第一次接触时最容易忽略的点。
私聊
通常会折叠进某个 agent 的主会话，所以它更像一个持续的对话窗口。
群聊
会按渠道和群组 ID 隔离，不会天然和私聊混上下文。
频道 / room
通常会按平台和频道 ID 单独分会话，避免不同房间互相串线。
线程
还会在基准会话 key 上继续细分，所以同群不同线程也能分开维护。
这就是为什么同一个机器人在私聊、A 群、B 群、同群不同线程里可以有不同上下文，而不会自动混在一起。
Routing
Gateway 到底是怎么决定“让谁来答”
这一层是确定性路由，不是模型拍脑袋做决定。
Channel
先识别这条消息来自哪个平台。
AccountId
如果同一渠道挂了多个账号，还会继续区分到底是哪个账号在收发消息。
AgentId
这是 OpenClaw 里真正的“脑子编号”，一个 agent 对应一套独立 workspace 和 session store。
SessionKey
这是会话落桶编号，决定上下文怎么延续，也决定不同入口如何隔离。
对中文用户来说，不需要一开始就把所有路由规则写满，但一定要先知道：同一个 Gateway 完全可以根据不同平台、不同群、不同账号，把消息送进不同 agent 和不同 workspace。
Why No Reply
为什么很多“机器人没回复”，其实不是平台坏了
这是最值得提前理解的一段，因为它直接决定你以后排障效率高不高。
DM policy 没放开
如果私聊策略是 pairing 或 allowlist，用户没通过配对前就不会正常聊天。
群聊默认要求 mention
很多群聊场景要求必须 @ 机器人，没 mention 时，看起来就像它不说话。
平台权限没给全
即使状态显示 connected，权限不完整时也可能收不到或发不出消息。
模型本身没连通
消息已经进 Gateway 了，但模型不可用，最后也会表现成“没回复”。
China Tips
对中国用户最有用的 3 个判断
如果你只记住很少几件事，我最建议记下面这三条。
先把 Gateway 当成消息总线
不要把“我在接飞书”理解成“我在配一个飞书小功能”，更准确是你在给统一 Gateway 增加一个消息入口。
先看策略，再看平台
机器人不回消息时，先检查 pairing、allowlist、mention requirement，再去怀疑 App ID、Token 或平台事件。
先接通一个入口，再做多渠道
一个平台彻底跑通之前，不要急着同时接好几个入口，不然很难判断到底是哪一层出问题。
Useful Commands
最值得记住的排查命令
真正排障时，这几条命令比重装、删配置和重建机器人有用得多。
openclaw channels list
openclaw channels status --probe
openclaw gateway status
openclaw status --deep
openclaw logs --follow
openclaw doctor如果是私聊不通，再补一条：
openclaw pairing list <channel>