用 message CLI 和命令入口时，怎么避免发到错误会话

很多人开始用 openclaw message 或其他命令式消息入口后，会遇到一个很隐蔽的问题：

• 目标发对了
• 但上下文桶不一定是你以为的那个

这不是 bug，而是因为 OpenClaw 里“发到哪里”和“落进哪个 session”本来就不是同一回事。

先把两层东西分开

更稳的理解方式是：

• target 决定消息送到哪个渠道对象
• session key 决定这条消息落到哪个上下文桶

如果你把这两层混成一层，后面最容易出现：

• 同一个频道里为什么有不同上下文
• WebChat 为什么能看到某些历史
• CLI 发出去的消息为什么没接上你以为的线程

openclaw message 更像什么

官方文档当前给出的定位很清楚：

• 它是统一的出站命令入口

它更适合：

• 单次通知
• 自动化广播
• 明确的渠道测试

这意味着它首先是：

• 发送层能力

而不是：

• 一个天然“继承当前聊天上下文”的入口

reply routing 为什么值得和它一起看

官方 Channel Routing 文档已经明确说了：

• reply routing 是 deterministic 的，由 host config 决定

这说明命令入口并不会因为“操作者心里觉得这是同一话题”，就自动落到你想要的 session。

你真正要看的仍然是：

• 当前 binding
• 当前 target 对应的 peer / channel / thread
• 由此生成的 session key

哪些目标最容易让人误以为“应该共用上下文”

同一个频道，不同线程

在 Slack / Discord 这类场景里，thread id 会进 key。
所以“同一频道”并不等于“同一上下文”。

同一个人，不同渠道

如果没配 identityLinks，同一用户跨 Telegram / Discord 找你，也未必会共用一个 DM 上下文。

同一个 agent，不同入口

WebChat 默认附着到 agent 主会话；而 CLI / 外部渠道是否落进同一桶，还要看 routing 和 dmScope。

为什么 operator 入口更容易踩这个坑

因为 operator 常常会在几个入口之间切换：

• WebChat
• Dashboard
• openclaw message
• 外部聊天渠道

如果这时只凭“这是同一个 agent”来判断上下文，会非常容易误判。

更稳的做法是始终问自己两件事：

1. 这条消息最终发到了哪个 target
2. 这个 target 会生成什么 session key

哪些场景里更适合只把 message 当通知层

更适合的通常是：

• 发布完成通知
• 运维告警
• 明确的单次外发
• 不需要承接复杂上下文的消息

这些场景里，你不必强行把 message 看成会话入口。

哪些场景里更应该先确认 session target

更需要小心的通常是：

• 想接着某个线程继续说话
• 想让机器人在群聊里承接刚才的任务上下文
• 想确认 CLI 发出去的消息是否属于某个已有 DM 会话

这时最好先确认：

• 渠道对象
• thread / room / peer 结构
• dmScope / identityLinks / bindings

中文用户最容易踩的坑

1. 觉得“agent 相同 = 会话相同”

实际上中间还隔着 routing 和 session key。

2. 用 openclaw message 做复杂上下文承接

它更像命令式出站层，不是天然的上下文续写入口。

3. 忘了 thread 会改变 session key

团队频道里这特别常见。

一条更稳的使用路径

建议按这个顺序判断：

1. 先决定目标是“通知”还是“对话续写”
2. 如果只是通知，用 openclaw message 很合适
3. 如果要续写上下文，先查清 target 对应的 session key 形状
4. 再决定是 WebChat、外部渠道，还是命令入口更合适

下一步推荐

• 频道与 Session 路由怎么决定上下文边界
• WebChat 与 message CLI
• dmScope 和 identityLinks 应该怎么一起用