私聊配对
这是在问:“这个陌生人能不能和机器人说话?”也就是 DM pairing。
Channels 导读
Pairing 是 OpenClaw 的“所有者审批”机制,分两路:DM 配对控制哪些人能私聊机器人,节点配对控制哪些设备能加入网关网络。最容易搞错的是:批准了 DM 配对并不等于允许该用户在群组中执行命令——群组授权需要单独配置 allowlist。
先讲这一页到底在解决什么
Pairing 是 OpenClaw 的“所有者审批”机制,分两路:DM 配对控制哪些人能私聊机器人,节点配对控制哪些设备能加入网关网络。最容易搞错的是:批准了 DM 配对并不等于允许该用户在群组中执行命令——群组授权需要单独配置 allowlist。
第一站
官方一上来就把 pairing 分成两类。别嫌它啰嗦,因为这两类看起来都叫“配对”,但守的是两扇完全不同的门。
这是在问:“这个陌生人能不能和机器人说话?”也就是 DM pairing。
这是在问:“这台新手机、新节点能不能加入网关大家庭?”也就是 node pairing。
一个是给“人”发门票,一个是给“设备”发门票。人和设备的风险不一样,所以不能混成一锅。
Pairing 不是在加新功能,而是在防止“谁都能进来”。
第二站
当某个陌生人第一次私聊机器人,而你的 dmPolicy 设成了 pairing,OpenClaw 不会立刻处理他的消息。它会先发一个短短的配对码。
像一张临时入场券。人先拿着这张票站在门口,等你看过、点头、批准了,后面的聊天才会开始。
因为门票不该一直有效。官方把它做成会过期,就是怕旧票被拿来反复乱试。
默认一个通道最多堆 3 个待审批请求。你可以把这理解成门口等候区只有 3 个座位,再来的人先别挤进来。
陌生人发来的第一条消息,不会被真的处理。它更像一声“有人敲门了”,真正放不放,要你来决定。
第三站
很多人一看到命令就脑袋一紧。其实这里最关键的就两条,翻成人话非常简单。
openclaw pairing list telegram像翻 Telegram 这扇门口的登记簿,看看现在有哪些人拿着临时票在外面等。
openclaw pairing approve telegram <CODE>像把某一张票递回门卫,说:“对,就是这个人,放他进来。”这里的 <CODE> 不是备注文字,而是那张临时票上的编号。
官方说这些状态会放在 ~/.openclaw/credentials/ 里。你可以把这里想成“门卫的抽屉”,里面一份是待审批名单,一份是已经放行的名单。
因为它们不是普通日志,而是“谁有资格进门”的名单。名单一旦被乱改,机器人就可能把错的人也放进去。
第四站
这一段不是在给“聊天的人”开门,而是在给“来连网关的新设备”开门,比如 iPhone、Android 节点、macOS 节点。
你先在 Telegram 里说 /pair,机器人给你一张 setup code。你把这串东西贴进 OpenClaw app,然后回到 Telegram 看有哪些新设备举手申请,最后再批准它。
/pair像你对机器人说:“给我一张新设备入场券。”
像一张临时密码纸条,里面装着网关地址和一次性的 bootstrap token。官方明确提醒:这东西要当密码看。
/pair pending像回到门卫台,看现在有哪些设备已经拿着纸条来报道了。
给设备 pairing 时,你不是在聊天窗口里随便点按钮,而是在把一台新设备正式拉进 OpenClaw 的设备网络。
第五站
设备配对这边的命令,逻辑和私聊配对其实很像,只是对象从“人”变成了“设备”。
openclaw devices list像看看现在有哪些手机、节点、电脑正排队等你批准。
openclaw devices approve <requestId>像把这台设备从等待区领进门,并正式发给它通行证。
openclaw devices reject <requestId>像告诉门卫:“这个不对,不准进。”
~/.openclaw/devices/pending.json 像等待区名单,paired.json 像已经正式办好证件的设备册。
第六站
这页虽然不长,但特别容易把几个概念混成一团。这里直接帮你拆开。
批准了某个人来私聊你,不代表他在群里就自动有什么特别权限。群的规则还得另外看。
一个是在放聊天访客,一个是在放节点设备。名字像,但门不一样。
如果同一台设备又拿着不同资料重新来敲门,旧申请会被顶掉,新的 requestId 才是现在该看的那张票。
Pairing 就是把“陌生人直接进来”改成“先领票、再点头、再放行”。