OpenClaw 群聊规则：提及触发、允许列表与上下文可见性

群聊是 OpenClaw 配置错误的重灾区，因为它同时受「群组允许列表」和「发送者允许列表」两层检查，很多新手只配了一层。这页把规则一次讲透。

两层检查，顺序固定

1. 允许哪些群：群组允许列表（如 channels.telegram.groups、channels.whatsapp.groups、Discord 的 guilds、Slack 的 channels）。配置了 groups 就相当于白名单；不配置时默认策略是全拒（故障关闭），直到你显式放行或写通配符。
2. 允许群里的谁触发：群组发送者白名单（groupAllowFrom，因渠道而异）。未设置时多数渠道回退到私信白名单 allowFrom，但私信配对批准永远不会自动继承给群组——这是官方写明的设计边界。

提及机制

• requireMention: true：群里只有 @机器人 的消息才触发，推荐永远开着。
• 提及来源有两种：原生 @用户名，或自定义提及模式（比如让它响应「@虾虾」这种自定义称呼）。
• 会话级临时开关：/activation always 与 /activation mention 可以在会话内切换，但持久行为以配置为准。
• 回复机器人的消息通常视为隐式提及，但它不会绕过发送者白名单。

最常见的三个配置错误

1. 群 ID 放错位置：Telegram 超级群组 ID 是负数（-100 开头），它属于 groups 键下的键名，不是 groupAllowFrom 的成员——groupAllowFrom 里放的是个人用户 ID。
2. 以为批准了私信配对 = 全局放行：配对只授予私信访问；群组授权必须显式配置。
3. 用 @用户名 当白名单条目：多数渠道要求数字 ID，旧的 @用户名条目会被 doctor 迁移或忽略。

上下文可见性（进阶）

群聊里「谁的内容能进模型上下文」由 contextVisibility 控制：all（默认，原样保留）、allowlist（只保留白名单发送者的内容）、allowlist_quote（白名单外内容被滤掉，但保留显式引用的那条）。在公开群里跑常驻机器人时，把它设为 allowlist 能显著减少提示词注入面——陌生人的引用文本、话题历史不再是不可信输入源。

群组隔离

每个群组会话天然按群 ID 隔离；论坛话题（如 Telegram 的 topic）会附加话题 ID 继续细分。多用户场景下若多人私信同一助手，配合会话隔离配置使用（见 信任模型）。

相关阅读：接入 Telegram、私信配对、渠道总览。