OpenClaw 飞书 pairing 怎么批准：配对码过期、approve 不生效时这样排查

发布时间

2026-03-14

作者

BUMA 内容团队

资料来源

OpenClaw 官方 Pairing / Feishu 文档、Clawdbot 中文文档

适合谁看

正在做 OpenClaw 飞书私聊接入、批准 pairing、收口 DM 访问权限和排查配对码失效的人

OpenClaw 飞书 pairing 到底在拦什么？

这一步拦的不是模型调用，也不是消息发送权限，而是“未知发信人能不能先进入私聊处理链路”。OpenClaw 官方 Pairing 文档把 DM pairing 写得很直接：当某个渠道配置成 pairing 策略时，陌生发信人先收到一串短码，这条原始消息不会被处理，直到所有者批准为止。对飞书来说，这意味着机器人已经在运行、长连接也可能正常，但系统依然会故意把未批准私聊挡在门外。

这就是为什么很多人会误判：看到机器人回出了 pairing code，就以为“接入没问题了”；实际上只能说明入口拦截机制已经生效，离真正放行还差最后一步批准。你如果直接拿这段表现去查 message.send、去查群聊策略、甚至去改模型，方向往往是偏的。因为 Pairing 处理的是访问控制，不是群聊提及规则，也不是发送接口报错。

从白帽 SEO 搜索意图看，搜“OpenClaw 飞书 pairing 怎么批准”的人，基本都不缺概念，缺的是一条能直接执行的判断线：先看是不是 DM pairing，再看码是否过期，再看当前渠道有没有挂起请求，最后才是 approve 命令和后续验证。

官方文档里最关键的 4 个 pairing 事实

第一，配对码是 8 位大写字符，且去掉了容易混淆的字符，比如 0 / O / 1 / I。这不是一次性密码风格的随手码，而是为了避免你抄错。

第二，有效期只有 1 小时。官方写得很明确：pending DM pairing request roughly once per hour per sender，配对码 1 小时后过期。如果你今天上午拿到码，下午再去 approve，大概率就不是同一条有效请求了。

第三，每个渠道默认只保留 3 个待处理请求。官方 Pairing 页提到 pending 请求默认 cap 为 3，新的请求在旧请求未过期或未批准前可能被忽略。所以如果多人轮流试，看到“怎么没有新码”，未必是机器人没工作，而是挂起请求已满。

第四，批准后写入的是 allowlist。官方说明待处理请求和批准后的 allowlist 会分别落到本地凭证文件里，这也是为什么 pairing 处理完后，后续再私聊通常不会重复要求批准，除非你换账号、换渠道或清理了相关存储。

为什么 approve 了还是感觉“不生效”？

最常见的第一种情况，就是你批准的是过期码。OpenClaw 官方写的是 1 小时有效，而不是永久有效。如果用户拿到码后隔了很久才处理，或者中间又触发过新的 pairing 请求，旧码就很容易失效。第二种情况，是你看错了问题层级：当前其实是群聊不回、必须 @ 才回、群或成员白名单没放开，但你一直在私聊 pairing 这条线上排查，自然会觉得“approve 没效果”。

第三种情况，是挂起请求过多。因为每个渠道默认只保留 3 个 pending 请求，新的尝试可能不会持续生成新码，导致你手上拿到的是旧状态。第四种情况，是批准之后消息已经放进来了，但发送链路还有别的问题，这时表面上也会像“没通过 pairing”。所以最关键的不是反复 approve，而是把问题拆成访问控制、群聊边界、发送权限三层分别看。

什么时候该继续用 pairing，什么时候该改白名单？

如果你希望陌生人首次私聊时先经过你确认，pairing 很合适，尤其适合内部工具、半公开测试和不想被陌生人直接打穿 DM 的场景。官方文档也把它当作默认安全入口之一。它的好处是安全、明确、可审批；代价是每个陌生发信人第一次都要走一轮批准。

如果你的飞书机器人只面向固定几个人，或者你已经很清楚允许谁私聊，那直接维护 allowFrom 往往更省事。因为 pairing 解决的是首次批准，而 allowlist 解决的是稳定放行。两者不是谁高级谁低级，而是不同阶段的策略。测试阶段、陌生来源较多时，先 pairing 更稳；正式投入固定团队使用时，白名单更省心。