龙虾翻车实录:AI助手突然不回消息,排查半天发现是它偷换了频道
明明在 Telegram 或者 Discord 上跟 AI bot 聊得好好的，突然它就不搭理你了。你跑去看 Dashboard，发现消息全跑到 WebChat 里去了——bot 没挂，但它不跟你说活了。
这事我在 OpenClaw 上踩了不下三次坑。今天把整个来龙去脉扒一扒，顺便告诉你最新版到底修好没。
OpenClaw 这玩意儿，能同时接 Discord、Telegram、WhatsApp、Signal 一堆通道。它用 sessionKey（会话键）来记”这条消息该回给谁”。
你在 Discord 发消息 → 系统记住：这人是 Discord 的 → 回复也发回 Discord ✅
如果你顺手在 Dashboard（网页后台）看了一眼同一个会话，系统就会犯傻：
你在 Dashboard 看了一眼 Telegram 会话 → 系统发现：哦，这是个"内部会话" → 二话不说，把回复通道改成 webchat ❌ → 你的 Telegram bot：行，我不说话了
专业术语叫“静默回落”（silent fallback）。翻译成人话就是：系统偷偷把回复通道换了，谁也没告诉你。
你等回复，等不到。你以为是 bot 挂了。实际上它在你 Dashboard 里自言自语呢。
说实话，这类问题在 OpenClaw 历史上至少反复出现过三轮，修了又犯，犯了又修。
早期 OpenClaw 对 legacy 格式的会话键处理有问题——明明有外部通道，回复却莫名其妙 fallback 到 webchat。
🐛 Issue #2034 #2035 #2036 — 后来修了
你从 TUI（终端界面）发了条消息，结果 bot 跑去回复 Discord 私聊了。
原因：系统没判断发送方是不是内部客户端，直接继承了上一个外部通道。
修复前：内部会话？直接返回 webchat（简单粗暴） 修复后：是内部客户端 → 走内部通道 是外部用户 → 走外部通道
🐛 Issue #35321 #35356 #43918 — 修了
Agent A 通过 sessions_send 给 Agent B 发消息 → B 的会话被标记为 channel=webchat → B 下一条回复……发到 webchat 去了 ❌ → Discord 用户：我消息呢？
更离谱的是，如果你的 cron 定时任务也在反复发 sessions_send，这个路由污染是持续累积的——每跨一次 Agent 就覆盖一次路由。到最后，你的 bot 在 Discord 上基本就是废的。
🐛 Issue #54441 — 一堆人报告这问题 ✅ Issue #58013 — 2026.4.9 修复，加了 isInterSession 标志位
你只是看了一眼 Dashboard 上的外部会话，路由也会被污染。不是发消息，是看一眼。
Dashboard 查看 Telegram 会话 → 系统记录：deliveryContext.channel = "webchat"（应该是 telegram） → 子 Agent 完成 → 通知发 Dashboard → Telegram 用户：继续等
🐛 Issue #47745 #47797 — 2026.4.5 修复
老实说，这一波修复挺全面的。之前的边界模糊问题，基本都给堵上了。
1用 [[reply_to_current]]：强制回复到触发消息的通道（不是万能药，但管用大部分场景）
2在出问题的通道执行 /reset：能恢复正确路由，就是每次都得手动来
3少用 sessions_send：特别是 cron 任务多的场景，能不跨 Agent 就不跨
OpenClaw 的 sessionKey 路由问题，说白了就是内部操作和外部通道的边界没做好隔离。内部操作（WebChat 查看、sessions_send）不该去碰外部用户的路由。2026.4.9 版本基本把这个大半年历史遗留问题给收拾了。
夜雨聆风
