飞书机器人接入 5 步走:踩过 OU 跨 App 隔离坑后总结的通用方法论
让openclaw助手自动接飞书机器人,总结的通用方法论
引言
飞书机器人在 OpenClaw 里越来越多:英语、新闻、政治、学习、……接入新机器人时反复踩同一个坑:99992361 open_id cross app。
问题根源是 OU 跨 App 隔离 ——同一个账号在飞书机器人 App A 和 App B 两个上下文里被分配完全不同的 open_id。你不能从 A 的 OU 列表里挑一个写到 B 的配置里。
2026-06-13 数学机器人接入闭环(22:24 CST),把整套流程沉淀成 5 步走 SOP。本文讲清楚这 5 步是什么、坑在哪里、怎么验证。
1. 接入前的认知:OU 命名空间隔离
核心事实:飞书每个机器人 App 是独立的 open_id 命名空间。
| 机器人 | accountId | 飞书 OU(实测) |
|---|---|---|
| feishu 主 bot | feishu |
ou_dc3ad... |
| 英语助手 | feishu-english |
ou_d849c8... |
| 学习助手 | feishu-408 |
ou_dc3ad... + ou_8592f7... |
| 新闻助手 | feishu-politics |
ou_dc3ad... + ou_8592f7... |
| 数学助手 | feishu-math |
ou_600e2cb...c956e |
数学助手 OU 和英语、政治都不一样——OU 跨 机器人App 不可复用。
2. 5 步走 SOP
步骤 1:配置子账户
在 /root/.openclaw/openclaw.json 的 channels.feishu.accounts 下新建子账户。allowFrom 先填临时占位 OU(或空数组),关键是不阻塞入站日志产生。
步骤 2:触发入站事件
在飞书 App 找到新机器人,发 1-3 条任意消息(”测试”就行)。目的是触发 openclaw 飞书插件的入站事件,让真实 OU 出现在日志里。
步骤 3:逆向抓 OU
查 openclaw 日志:
1 | |
输出会带 ou_xxxxxxxx,那就是该 App 命名空间下杰哥的真实 open_id。
步骤 4:双点修复
把抓到的真实 OU 写入两处:
点 1:channels.feishu.accounts.feishu-<name>.allowFrom
点 2:bindings[].peer.id(路由到 agent 的配置项)
只改一个地方会失败——这是踩坑最频繁的点。
步骤 5:真送达验证
出站:触发一次推送,看飞书后端返回的 messageId。没有 messageId 不算闭环。
入站:在飞书 App 给机器人发 3 条消息,期望 openclaw 收到 3 次 received message from ou_xxx,不能出现 blocked unauthorized sender (dmPolicy=allowlist)。
3. 数学机器人实战复盘(22:13 → 22:24)
时间线浓缩:
- 22:13-22:14:用主 bot 命名空间的 OU 推数学机器人,❌
99992361 open_id cross app - 22:14-22:18:在飞书 App 给数学机器人发 3 条消息触发入站
- 22:24:从日志抓到数学 App 真实 OU
ou_60...f2c956e,双点修复 - 22:24:27:重发消息,✅ 出站
om_x100b6de2c....babbc5c0 - 22:24:50:飞书上回复「收到」,✅ 闭环
整个过程 11 分钟,其中 8 分钟踩坑、3 分钟修复。
4. 4 个高频避坑
| 坑 | 症状 | 根因 | 修复 |
|---|---|---|---|
| OU 跨 App 复用 | 99992361 open_id cross app |
每个 App 独立命名空间 | 逆向抓该 App 专属 OU |
| allowFrom OU 错 | blocked unauthorized sender |
allowFrom 不是该 App 真实 OU | 替换为逆向抓的 OU |
| bindings peer.id 漏改 | 插件不报错但消息路由不到 agent | 只改了 allowFrom,没改 bindings | 双点同步 |
| 改完未验证出站 | 入站通了但出站没回执 | appSecret 错 / 机器人未发布 / 权限缺失 | 必须抓到 messageId |
5. 复用模板
下一个新机器人的接入流程:
1 | |
总结
接入飞书机器人 App 的核心不是”配置对不对”,而是 OU 跨 App 隔离。任何一个 App 都有独立的 open_id 命名空间,必须逆向从入站事件抓真实 OU,不能凭记忆或复用。
5 步走 SOP 的本质:配置 → 触发事件 → 逆向抓 OU → 双点修复 → 真送达验证。最后一步的”真送达验证”是闭环判据——没有出站 messageId + 入站无 blocked,就不算接入成功。
未来接入第 6/7/N 个机器人,先读本笔记再做,避免再踩同一个坑。