7.2 渠道绑定与多账号隔离

当系统从单入口扩展到多渠道、多群、多对端后，最大风险往往来自边界漂移：低可信入口触发高权限能力，或者不同入口共用同一策略导致责任难以追溯。本节基于 OpenClaw 官方的渠道策略、多账号配置与绑定机制，说明如何把入口治理前置到配置层，并提供一组可用于验收与排障的命令。

7.2.1 入口治理：私聊与群聊分开配置

入口治理的第一原则是把私聊与群聊分开。官方渠道文档普遍提供 dmPolicy 与 groupPolicy 的策略入口，用于分别定义允许列表与提及门控：

• WhatsApp：https://docs.openclaw.ai/channels/whatsapp

• Telegram：https://docs.openclaw.ai/channels/telegram

建议采用“谨慎起步”默认：群聊默认只在被提及时响应，私聊默认收敛到允许列表或配对审批。

7.2.2 多账号隔离：把外部入口与内部入口拆开

多账号的价值不在“多开”，而在隔离：把外部支持入口与内部运维入口拆开，让不同入口具备不同的门控策略。例如可通过 channels.whatsapp.accounts 提供多账号隔离。

下面示例展示了两个账号的配置骨架：

{
  channels: {
    whatsapp: {
      accounts: {
        support: {
          dmPolicy: 'pairing',
          allowFrom: ['[phone]'],
          groupPolicy: 'allowlist',
          groupAllowFrom: ['[phone]'],
          groups: { '*': { requireMention: true } },
        },
        ops: {
          dmPolicy: 'allowlist',
          allowFrom: ['[phone]'],
          groupPolicy: 'allowlist',
          groupAllowFrom: ['[phone]'],
          groups: { '*': { requireMention: true } },
        },
      },
    },
  },
  messages: {
    groupChat: {
      mentionPatterns: ['@openclaw'],
    },
  },
}

多账号落地后建议在日志与告警中把账号标识作为一等维度，便于审计与责任归因。

7.2.3 绑定：为高确定性来源固定接管

多账号解决入口隔离，绑定解决精确路由。对于管理员对端、关键群或固定业务号码，建议优先用绑定固定接管，减少模型路由的不确定性。绑定机制与优先级见：https://docs.openclaw.ai/concepts/multi-agent#routing-rules-how-messages-pick-an-agent。

绑定生效与否可用命令直接验证：

openclaw agents list --bindings

7.2.4 验收与排障：用探针与日志回放收敛问题层级

入口治理相关问题建议按层级收敛：

1. 自检：用 doctor 确认依赖与配置结构。

2. 状态：用 channels status --probe 确认渠道在线与策略加载。

3. 回放：用结构化日志按 traceId 定位是门控、绑定还是工具策略导致的行为差异。

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

当出现“群聊误触发”时，优先检查提及门控与允许列表；当出现“越权执行”时，优先检查工具策略是否默认拒绝高风险工具组。