OpenClaw 飞书机器人权限清单｜哪些必须开，哪些别一上来全放开

发布时间

2026-03-14

作者

BUMA 内容组

资料来源

OpenClaw Feishu 文档、OpenClaw FAQ、Clawdbot 中文文档。

适合谁看

准备把 OpenClaw 接入飞书做咨询分发、提醒、内容审核、群协同或一人公司消息入口的人。

Quick Judgment

先说结论：OpenClaw 飞书接入要先追求“最小可用权限”，不是“权限越全越专业”

官方文档已经把路径写得很清楚：先把 Gateway 跑起来，再创建飞书应用，补权限、启用 Bot、添加长连接事件，最后做消息与 pairing 测试。真正影响成功率的，是这个顺序有没有走对。

01

先保证能收、能回、能配对

第一阶段最重要的不是把所有扩展能力都开完，而是先让机器人能收到 im.message.receive_v1，能以机器人身份回消息，并能完成 pairing 配对批准。

02

Bot 能力和事件订阅缺一不可

只有权限不够，只有凭证也不够。官方 Feishu 文档明确要求启用 Bot 能力，并在 Event Subscription 中选择长连接接收事件，再添加 im.message.receive_v1。

03

群聊权限要保守开

OpenClaw 官方给了 groupPolicy、requireMention 和 allowFrom，就是为了避免机器人一进群就乱回。刚接入时默认保守，反而更稳。

OpenClaw 飞书机器人权限清单，第一轮至少看懂这 5 组

1. 应用身份：App ID 和 App Secret

这是最基础的一层。你需要在飞书开放平台创建企业应用，拿到 App ID 与 App Secret，再在 OpenClaw 渠道配置里填进去。它们不是“权限”，但属于一切权限生效之前的前提。App Secret 泄露后要及时重置，不能把它当普通备注随便发到群里。

2. 消息读取相关权限

OpenClaw 官方文档给出的批量导入示例里，和消息接收直接相关的权限包括 im:message、im:message:readonly、im:message.p2p_msg:readonly、im:message.group_at_msg:readonly 等。这一组的核心作用，是让机器人能看见飞书里真正投递过来的消息内容，尤其是私聊与群里 @ 机器人的消息。

3. 消息发送相关权限

如果你经常遇到“消息收到了，但回不去”，最先核对的就是 im:message:send_as_bot。中文文档的故障排查里也明确提到：消息发送失败时，先看这个权限有没有开，再看应用是不是已经发布，再看日志里有没有更具体的错误。

4. 资源与成员信息相关权限

像 im:resource、im:chat.members:bot_access 这类权限，主要用于更完整的消息与群成员处理能力。不是说第一天必须全部深度用到，但如果你要做群聊消息、附件、图片或成员相关判断，它们就很重要。第一轮至少要知道：少了这些，某些媒体类或群成员相关行为可能不完整。

5. 事件订阅不是“权限名”，但和权限一样关键

很多人会把权限和事件订阅混为一谈。实际上，im.message.receive_v1 是你在飞书后台事件订阅里要添加的事件，不是权限字段。官方 Feishu 文档特别提醒：在设置长连接事件订阅前，要先跑好 OpenClaw 渠道并确保 Gateway 正在运行，否则长连接配置可能保存失败。也就是说，哪怕你的权限清单没问题，只要事件没订上，机器人照样收不到消息。

最小闭环怎么配：建议按“能收消息、能回消息、能控范围”三层来做

第一层：先把消息接进来

先确保 OpenClaw 已经完成安装与基础启动，再看 openclaw gateway status。OpenClaw 官方文档和中文文档都强调，在飞书这条链路里，Gateway 是底座；底座没起来，后面的权限、长连接和 pairing 都谈不上。接着启用 Bot 能力、选择长连接接收事件、添加 im.message.receive_v1，这一步完成后，机器人才具备“收到消息”的条件。

第二层：再确认它能回去

能收不等于能回。除了 im:message:send_as_bot 之外，还要确认应用已经发布。很多人测试时只做到“后台都填了”，但应用并没有实际发布，或者管理员审批还没通过，于是前面看起来都正常，真实发消息时却没有回执。官方页已经把“发布应用”单独列成了一个步骤，这不是走形式，而是消息能力真正生效的前提之一。

第三层：最后再控谁能触发

OpenClaw 在飞书上的默认思路并不是“一开就全员畅聊”，而是先通过 dmPolicy: "pairing" 让未知私聊用户拿到配对码，等批准后再建立稳定会话。这套默认逻辑很适合第一阶段先控风险。如果你要上群聊，建议继续用保守策略：groupPolicy 先维持 open 但默认 requireMention: true，或者直接用 allowlist 只放指定群；如果群里只有少数成员需要触发，再用 groups.<chat_id>.allowFrom 限成员范围。

这三层配法的核心好处，是你不会一开始就把机器人放到所有群、所有人、所有消息里裸跑。对一人公司、小团队、内容协同和咨询分发场景来说，这种保守起步通常更省排障时间，也更符合白名单式管理习惯。

Common Scenarios

OpenClaw 飞书权限配好后，最适合先落地的 3 个场景

先从高频、好验收、风险低的入口开始，更容易把接入做成真正有价值的动作。

私聊咨询承接

先允许已配对用户在飞书私聊里发起咨询，机器人只处理经过 pairing 的会话。这是最稳的第一阶段路径，因为边界清晰、日志清晰、问题也容易定位。

群里 @ 机器人答疑

如果业务确实需要群协同，建议保持 requireMention: true。这样机器人只在被明确 @ 时响应，既能保证存在感，也能避免打断正常群讨论。

内容审核与提醒

当 OpenClaw 负责生成内容草稿、FAQ、标题或日报时，把结果回投到飞书给人工审核，通常是权限最容易发挥价值的场景：机器人不必替代人，但能把流程串起来。

Pitfalls

为什么很多人觉得“OpenClaw 飞书权限都开了”，系统还是不好用

高频问题通常不在“少一个冷门权限”，而在顺序和验收没有做好。

只看权限，不看 Gateway 状态

Feishu 文档明确提示：长连接事件订阅前，Gateway 要先运行。很多人前面都填了，但 openclaw gateway status 一看就是没起来，自然谈不上真实收消息。

只看后台配置，不做 pairing 验收

默认私聊策略是 pairing。也就是说，未知用户第一次发来消息，拿到配对码只是中间态；你还需要批准，之后才算会话真正打通。跳过这一步，容易误判成机器人无响应。

群范围开太大

一开始就把群聊全开放，最常见的结果不是“自动化更强”，而是机器人被大量无关消息淹没，甚至影响体验。群聊策略最好从少量群、默认 @ 触发开始。

把 Lark 和飞书域名混用

官方文档提醒：国际版 Lark 需要设置 domain: "lark"。如果租户环境搞错，后面很多现象都会很像“权限有问题”，实际上是域配置不对。

应用没发布就急着测试

权限、Bot、事件都配置完，不代表能力已经对外生效。飞书应用仍然需要发布，部分企业环境还要审批。没有这一步，消息回发很容易失败。

不知道用户 ID 和群 ID 从哪找

当你需要做 allowFrom 或 groupAllowFrom 时，文档建议通过日志、私聊消息、群内 @ 机器人或 pairing 列表去确认 ou_xxx 和 oc_xxx。ID 没拿准，白名单配置就会失效。

如果你现在就要排查“为什么飞书机器人发不出消息”

建议你按这个顺序看：第一，应用是不是已经发布；第二，im:message:send_as_bot 有没有开；第三，Gateway 当前是不是运行中；第四，事件订阅是不是已经保存为长连接并包含 im.message.receive_v1；第五，日志里有没有更具体的报错。这个顺序不是拍脑袋定的，而是官方文档和中文文档中最反复出现的排查主线。

如果是群里不回，还要加看两项：一是有没有 @ 机器人，因为默认要求提及；二是 groupPolicy 和群级别配置有没有把这个群挡掉。很多时候系统不是坏了，而是它正在按你自己配置的边界工作。

这篇清单怎么用，最省时间

最好的用法不是把每个权限词都背下来，而是拿它对照你当前的接入进度：底座是否已跑通、应用是否已建好、Bot 是否已启用、事件是否已订阅、消息能不能发回、配对是否已批准、群边界是否已收紧。只要这 7 个点有一项没过，系统都可能表现得像“权限没开对”。

一句话总结：OpenClaw 飞书机器人权限清单的真正价值，不是把权限堆得更满，而是先把一条最小可验证链路接稳——能收、能回、能控范围。只有这条链路稳定了，后面再扩展到群协同、附件处理、更多岗位、多账号和多 Agent 路由，才会越做越顺。

如果你已经卡在权限、事件订阅或 pairing 上，先把当前卡点告诉我。

比如“能收不能回”“群里不触发”“应用已发布但消息没回来”。先定位是哪一层出问题，再补权限和配置，会比盲目重装更省时间。

加微信 bm8150 电话 15550927555

OpenClaw 飞书机器人权限清单：哪些必须开，哪些别一上来全放开