WhatsApp 是 OpenClaw 官方首页示例里直接展示的主渠道之一，也是很多人最先想接入的消息入口。
先理解 WhatsApp 接入方式
官方说明目前只支持基于 Baileys 的 WhatsApp Web 模式：
- Gateway 持有 WhatsApp 会话。
- 通过
openclaw channels login扫码，把当前 OpenClaw 实例关联成一个设备。 - 不是 Twilio，也不是 WhatsApp Cloud API。
官方推荐：尽量使用独立手机号
官方文档明确把“独立号码”列为推荐方案，原因很实际：
- 路由更清晰
- 不容易出现“自己给自己发消息”的怪异行为
- 更适合长期运行
理想形态是：
- 给 OpenClaw 单独准备一个手机号
- 最好放在备用 Android 设备或使用 eSIM
- 设备保持联网和供电
- 用二维码把它关联到 OpenClaw
如果你不想影响个人日常聊天，这个方案最稳。
最小可用配置
官方给出的新手最小配置是：
json
{
"channels": {
"whatsapp": {
"dmPolicy": "allowlist",
"allowFrom": ["+15551234567"]
}
}
}
这份配置的含义是：
- 私聊访问策略为
allowlist - 只有
allowFrom里的号码可以直接和 OpenClaw 通话
如果你是单人自用，这通常是最合适的初始方案。
标准接入步骤
按官方顺序来：
- 在
~/.openclaw/openclaw.json中配置 WhatsApp。 - 执行扫码登录：
bash
openclaw channels login
- 扫描二维码，把 OpenClaw 关联到你的 WhatsApp 设备。
- 启动 Gateway：
bash
openclaw gateway --port 18789
为什么 onboarding 会问你的手机号
官方解释是：
- 向导会用这个号码帮你初始化允许列表或所有者设置。
- 它不是拿来自动发送消息的。
如果你在“个人号码模式”下运行 OpenClaw，官方建议使用同一个号码，并启用 selfChatMode。
私聊访问是怎么控制的
官方 WhatsApp 文档说明，私聊访问由 channels.whatsapp.dmPolicy 控制，默认值是 pairing。
常见思路：
pairing：陌生发送者先收到配对码，审批后才能继续使用allowlist：只允许allowFrom中的号码- 更开放的场景则需要你显式配置允许策略
官方还强调了一点：
- 你绑定的 WhatsApp 自己的号码会被隐式信任
- 自己发给自己的消息不会再经过普通陌生人访问检查
如果你在个人号码上运行 OpenClaw
官方支持这种模式，但明确把它定义为“备选方案”。
它需要注意：
- 启用
channels.whatsapp.selfChatMode - 出站私信不会触发配对回复
- 未知发送者仍受
dmPolicy约束 - 自聊天模式会影响已读回执和提及判断
如果你只是想稳定长期运行，还是更建议用独立号码。
群组接入时要注意什么
官方总览里说明，群组行为和提及门控是单独控制的。WhatsApp 群聊常见做法是：
- 对公开群保留提及触发
- 只允许指定群组或指定成员
- 通过 allowlist 和 mention 策略控制噪音
如果你准备把 OpenClaw 放到真实工作群里，建议一开始不要全开自动回复，而是先采用“仅提及回复”的保守策略。
已读回执默认是开启的
官方文档说明：
- Gateway 默认会把收到的 WhatsApp 消息标记为已读
- 如果你不想自动发送蓝勾，可以关闭
示例配置：
json
{
"channels": {
"whatsapp": {
"sendReadReceipts": false
}
}
}
常见问题
为什么要扫码登录
因为当前支持的是 WhatsApp Web 渠道，OpenClaw 需要通过网页设备配对的方式持有会话。
为什么官方不建议直接用个人主号
因为个人主号更容易出现：
- 路由混淆
- 自聊天行为异常
- 日常聊天与机器人行为混在一起
如果我重新部署或状态丢了怎么办
优先检查：
~/.openclaw状态目录是否还在- 当前设备配对是否有效
- 必要时重新执行：
bash
openclaw channels login
一个稳妥的上线建议
如果你要把 WhatsApp 真正作为主入口使用，我建议按官方思路这样部署：
- 准备一个独立号码
- 使用
allowlist且只开放给你自己的号码 - 完成扫码登录后再启动 Gateway
- 确认私聊稳定后，再考虑开放群组或更多联系人