OpenClaw channel routing 实战：私聊、群聊、mention 和多账户怎么分流

OpenClaw 集成 进阶 进阶 预计 18 分钟 发布于 2026/2/18 核验于 2026/3/6

为什么这篇值得先看

如果 OpenClaw 老是“该回的不回，不该回的乱回”，问题往往不在模型，而在 routing。消息没被正确地路由，后面一切都只是补丁。

先抓住这 3 个关键点

• 私聊和群聊不该共用同一套准入策略，否则要么太松，要么太死。
• mention 规则能帮你显著降低群聊误触发，是比“调模型提示词”更先做的事。
• 多账户不是高级玩法，而是很多团队走向稳定必经的一步。

实操步骤

1. 先按“私聊 / 群聊 / 特定群 / 特定用户”把消息源分层，不要用一把锁锁所有门。
2. 给私聊定义 dmPolicy，给群聊定义 groupPolicy，再单独决定是否 requireMention。
3. 如果你有多账户或多渠道，把高权限工作流和高噪声工作流拆开，别放在一个入口里。
4. 最后回到 Control UI 复盘日志，看看哪些消息被挡住、哪些消息本不该进来。

配置或命令示例

{
  channels: {
    telegram: {
      dmPolicy: "pairing",
      groups: {
        "*": { requireMention: true },
        "ops-room": { requireMention: false }
      }
    }
  }
}

常见坑

• 把私聊、群聊和多人协作都塞进同一种策略里，导致行为失控。
• 以为 routing 是“后面再优化”的事，结果前面所有使用数据都被噪声污染。
• 没有回看日志，最后只看到表层现象：为什么它今天又不回了。

完成检查

• 同一条消息是否会被助手处理，你现在能提前预测。
• 你已经能解释清楚 dmPolicy、groupPolicy 和 requireMention 的边界。
• 不同账户或不同群聊的消息噪声开始被主动隔离。

为什么建议把这篇收藏起来

• 这是把 OpenClaw 用“稳”的核心文章之一，不是锦上添花。
• 内容一旦做对，后面配 skills、automation、security 都会轻松很多。