在使用 OpenClaw 对接飞书等 IM 渠道时，很多人会遇到一个典型问题：

为什么 pairing approve 成功了，但访问控制仍然不生效？

核心就在于：pairing.json 和 allowFrom 是两套完全不同层级的机制。

本文从架构层、加载流程、代码实现三个维度，彻底讲清楚它们的区别。

---

一、核心结论（先说人话版）

方案	是否可靠	原因
allowFrom	✅ 强烈推荐	网关级配置，启动即生效
pairing.json	❌ 不推荐	插件可能根本不读
pairing approve 命令	⚠️ 不稳定	临时状态，易丢失

👉 一句话总结：

allowFrom = 权威访问控制
pairing = 辅助机制（甚至可能是摆设）

---

二、架构层对比（本质区别）

1️⃣ 配置归属层级

项目	pairing.json	allowFrom
层级	插件级	网关级
控制权	插件实现	OpenClaw 核心
可靠性	不确定	稳定

👉 关键点：

• allowFrom 属于 核心配置（openclaw.json）

• pairing.json 属于 插件私有实现

---

2️⃣ 存储位置

# pairing.json（插件私有）
~/.openclaw/extensions/feishu/pairing.json

# allowFrom（核心配置）
~/.openclaw/openclaw.json

👉 这直接决定了：

• pairing.json → 可能没人读

• allowFrom → 启动必读

---

3️⃣ 加载时机（决定生死）

allowFrom

网关启动
↓
加载 openclaw.json
↓
allowFrom 进入内存 ✅

pairing.json

插件加载
↓
是否读取 pairing.json ❓（取决于实现）

👉 本质差异：

allowFrom 是“启动即生效”
pairing.json 是“看插件心情”

---

三、源码行为分析（关键点）

从飞书插件（channel.js）可以看到：

pairing: {
idLabel: "feishuUserId",
normalizeAllowEntry: (entry) => entry.replace(/^(feishu|user|open_id):/i, ""),
notifyApproval: async ({ cfg, id }) => {
await sendMessageFeishu({ cfg, to: id, text: PAIRING_APPROVED_MESSAGE });
},
}

👉 注意几点：

✔ 已实现的能力

• 发送“配对成功通知”

• ID 格式标准化

❌ 没实现的能力（关键）

• ❌ 没看到读取 pairing.json

• ❌ 没看到持久化配对数据

• ❌ 没看到用于权限校验

👉 结论：

pairing 在飞书插件中更像“通知机制”，而不是“权限机制”

---

四、访问控制真实流程

OpenClaw 实际的权限判断路径如下：

消息进入（飞书）
↓
channel (feishu)
↓
检查 dmPolicy
↓
┌────────────────────────────┐
│ allowlist → 查 allowFrom ✅ │
│ pairing → 查配对 ❌ │
│ open → 全放行 │
└────────────────────────────┘

---

五、为什么 pairing.json 不生效？

总结成 3 个工程级原因：

---

1️⃣ 插件未实现读取逻辑

这是最核心问题：

pairing.json 不是标准接口的一部分

也就是说：

• 插件作者可以实现

• 也可以完全不实现（飞书就是这种）

---

2️⃣ pairing approve 命令的局限

openclaw-cn pairing approve feishu EWZTJ3YC

可能发生的情况：

行为	结果
写入内存	✅
写入 pairing.json	❌ 不一定
被插件读取	❌ 不一定

👉 典型问题：

重启后全部失效

---

3️⃣ 配置优先级问题

优先级链路：

openclaw.json（最高）
↓
插件运行时逻辑
↓
pairing.json（如果存在）

👉 这意味着：

allowFrom 永远覆盖 pairing

---

六、为什么 allowFrom 一定可靠？

示例配置：

"feishu": {
"dmPolicy": "allowlist",
"allowFrom": [
"ou_50cc257c81601199950693287ed699a9"
]
}

其优势在于：

---

✅ 1. 核心模块直接读取

• 通过 resolveAllowFrom

• 在网关层统一处理

---

✅ 2. 生命周期稳定

• 启动即加载

• 不依赖插件

• 不依赖命令

---

✅ 3. 持久化天然保证

• 文件即状态

• 不存在“丢失”

---

✅ 4. 权限链路最短

消息 → 网关 → allowFrom → 直接判定

👉 没有中间不确定环节

---

七、最佳实践（工程建议）

推荐方案（生产可用）

{
"channels": {
"feishu": {
"dmPolicy": "allowlist",
"allowFrom": ["你的用户ID"]
}
}
}

---

不推荐方案

方案	原因
pairing.json	不可控
pairing approve	不持久
dmPolicy=open	无安全性

---

八、最终结论

在 OpenClaw 中：

• allowFrom 是“权限系统”

• pairing 只是“辅助交互”

---

九、一个更本质的理解（架构视角）

可以把两者理解为：

机制	类比
allowFrom	防火墙规则
pairing	加好友提示

👉 你不会用“加好友”来做安全控制，对吧？

---

🔚 总结一句话

想要稳定控制访问权限，只用 allowFrom，不要依赖 pairing。