7.1 渠道实战:接管 Telegram 与 WhatsApp

本节按官方接入方式分别说明 Telegram 与 WhatsApp 的接入模型、配置结构与安全边界,并给出一条从“可跑”到“可控”的落地路径:先用门控策略收敛触发面,再用探针与日志验证连通性,最后用绑定与工具策略把高风险能力固定在受控入口。

7.1.1 Telegram:机器人令牌与私聊、群聊策略

Telegram 渠道通常基于机器人令牌接入。官方文档给出了 channels.telegram 的配置字段,以及私聊与群聊策略入口,建议以白名单和提及门控作为安全起步:https://docs.openclaw.ai/channels/telegramarrow-up-right

示例配置:

{
  channels: {
    telegram: {
      botToken: 'ENV:TELEGRAM_BOT_TOKEN',
      dmPolicy: 'allowlist',
      allowFrom: ['tg:987654321'],
      groupPolicy: 'allowlist',
      groupAllowFrom: ['tg:987654321'],
      groups: { '*': { requireMention: true } },
    },
  },
  messages: {
    groupChat: {
      mentionPatterns: ['@openclaw'],
    },
  },
}

配置完成后,建议先用渠道探针验证连通性,再进入路由与工具层治理:

7.1.2 WhatsApp:运行在自己的账号上,优先收敛触发面

WhatsApp 渠道运行在自身账号上,风险点在于触发面天然更大。官方文档给出了 dmPolicygroupPolicy 与配对流程,建议通过配对、允许列表与提及门控收敛入口:https://docs.openclaw.ai/channels/whatsapparrow-up-right

示例配置:

配对流程建议纳入运维验收:

7.1.3 从渠道到路由:用绑定固定高确定性来源

渠道策略解决入口门控与默认接管,但对管理员账号、关键群或固定业务号码,建议进一步用绑定固定接管,以减少模型路由的不确定性。绑定机制与优先级见官方文档:https://docs.openclaw.ai/concepts/multi-agent#routing-rules-how-messages-pick-an-agentarrow-up-right

绑定生效与否建议用命令验证,而不是只靠对话观察:

7.1.4 验收与排障:先探针后回放

渠道相关问题的排障顺序建议固定为:

  1. 自检与状态:用 doctorstatus --deep 确认依赖与配置被加载。

  2. 渠道探针:用 channels status --probe 确认渠道在线。

  3. 链路回放:用结构化日志按 traceId 回放一次请求链路。

当出现“群聊不触发”时,优先检查 groups.*.requireMentionmessages.groupChat.mentionPatterns;当出现“越权执行”时,优先检查工具策略是否默认拒绝高风险工具组。

最后更新于