3.4 配对、群聊策略与访问边界

想象一下若未做安全配置，智能体被拉进一个有 500 人的大群，有人 @ 它问了个敏感问题，它直接回复了公司内部机密数据，那就麻烦了。

核心目标是给智能体上把安全锁：私聊配对拦截陌生人；群聊必须 @ 门槛；以及限制它能进哪些群。

3.4.1 私聊策略：谁能和智能体说话

OpenClaw 支持三种私聊策略（dmPolicy），通常建议使用 pairing 或 allowlist。

1. pairing（配对，最推荐）：陌生用户必须先发送任意消息申请配对。消息会被拦截并给出一个 Pairing code，管理员在后台执行批准（openclaw pairing approve <CODE>）后，该用户才能开始对话。

2. allowlist（白名单）：只有提前录入配置列表的 ID 可以跟机器人对话。

3. all（公开）：任何人都能对话（极度危险，可能导致 API 账单刷爆）。

配置示例（以飞书、WhatsApp 为例，私聊配对 + 允许列表）：

{
  channels: {
    feishu: {
      dmPolicy: 'pairing',
      allowFrom: ['ou_123456789'],
    },
  },
}

操作示例：列出并批准配对请求。

openclaw pairing list feishu
openclaw pairing approve feishu <CODE> --notify

3.4.2 群聊三道边界：群组开关、提及门控与能力收敛

群聊风险很大，最致命的就是输入噪声和越权副作用。在配置中强烈建议遵循这三道门槛：

1. 群组开关（groupPolicy）：如果不是必要，配置 disabled。若开启，务必配合允许列表（allowlist / groupAllowFrom）。

2. 提及门控（requireMention）： 这是群聊最重要的保险栓。强制要求只有明确 @ 机器人的消息才会被当成指令处理，无视其他群内闲聊。

3. 能力收敛 ：在群聊默认采用更保守的工具策略，避免高风险写入。

配置示例（以飞书为例，允许列表 + 提及门控）：

{
  channels: {
    feishu: {
      groupPolicy: 'allowlist',
      groupAllowFrom: ['group_123456'],
      groups: { '*': { requireMention: true } },
    },
  },
  messages: {
    groupChat: {
      mentionPatterns: ['@openclaw', '@AI助手'],
    },
  },
}

3.4.3 群聊验收用例：五分钟定位配置是否正确

建议做三组用例：

1. 不提及不触发：群里发普通消息，系统不应回应。

2. 提及触发：提及后消息应触发回应。

3. 白名单拦截：不在允许列表的群聊不应触发。

排障要点：先用 channels status --probe 确认渠道本身连通，再看日志确认消息是否被识别为群聊，以及是否命中门控规则。

openclaw channels status --probe
openclaw logs --follow --json

3.4.4 多群组上下文隔离：按场景分流

除了安全访问控制，群组还有一个容易被忽略的工程价值： 上下文隔离 。

当所有话题都在同一个会话中进行时，记忆文件会越来越长、越来越杂，智能体在回复时需要处理大量无关信息，回复质量和响应速度都会下降。通过创建多个群组，可以按场景将上下文天然隔离：

• 每个群组拥有独立的会话（Session），记忆只包含该场景的相关内容。

• 智能体在不同群组中的表现更精准，不会被其他话题的上下文干扰。

• 用户也更容易管理历史：工作内容在工作群里翻，写作素材在写作群里找。

典型的群组分流方案

群组	用途	上下文特点
主对话（私聊）	日常使用、个人记忆	长期记忆、个性化配置
工作群	专项工作任务	只包含工作相关的上下文
写作群	写作、内容创作	只包含写作风格、素材模板
测试群	测试新功能、调试配置	可随时清空，不影响正式记忆

操作方法：新建群聊，把你和智能体拉到同一个群里即可。每个群的 sessionKey 天然不同，上下文自动隔离。

[!TIP] 多群组分流的性价比远高于频繁使用 /new 开新会话。/new 会丢弃当前上下文重新开始，而群组隔离是持久的——每个群组各自积累记忆，互不干扰。