把 OpenClaw 接进飞书这件事，我第一次跑通的时候，心里最大的感受其实是“原来这么简单”，但回头看，前前后后折腾掉的时间，几乎全浪费在几个特别不起眼的细节上：回调验证地址多写了一个斜杠、app_secret 复制的时候带着空格、权限里少勾了一个 scope。这些坑如果不写出来，后来的人大概率还要再踩一遍。所以我干脆把这套从零到一接入的完整过程整理成一篇实操记录，目标是让你照着做，最快半小时内把一个 24 小时在线的 AI 助手挂到飞书群里。
这篇文章面向的对象说得很直接：一是想在团队飞书里搭一个能查数据、能跑命令、能回答问题的内部 AI 助手的开发者；二是对开源个人 AI 助手框架感兴趣、想自己掌控数据和工具链的人。阅读全文不需要懂算法训练，只需要会基本命令行操作，有一点 Docker 或 systemd 的基础就更好了。我会按“原理 → 配置 → 实操 → 排错 → 运维扩展”的顺序来讲，把每一步背后的为什么也讲清楚，让你不仅会照着做，还能在遇到问题时自己定位。
1. 为什么把 OpenClaw 接到飞书：24 小时助手的架构思路
1.1 先明确需求
OpenClaw 本质上是一个开源的个人 AI 助手框架，核心设计理念是“多渠道接入 + 工具调用 + 持久记忆”。它把大语言模型、工具插件和消息渠道解耦开，用户只需要通过配置文件把三者组合起来。换句话说，OpenClaw 不只是一个聊天机器人，它更是一个能调用其他工具的智能体：可以读文件、查数据库、执行脚本，也可以对接各种 MCP（模型上下文协议）服务。飞书在这里的角色，则是一个“交互入口”，把人跟这个智能体连接起来。
选择飞书作为入口，有几个很实际的理由。第一，飞书在企业团队里的渗透率很高，消息、文档、审批、会议都在一个生态里，AI 助手接进来之后可以跟数据天然打通。第二，飞书开放平台提供完善的机器人 API 和事件订阅机制，支持机器人在群聊和单聊里收发消息，这正好满足“助手”的交互需求。第三，飞书的事件订阅支持长连接模式，这意味着并不一定需要公网域名也能接收消息，对很多个人开发者和小团队来说门槛明显更低。
真正要实现的“24 小时在线”，本质上不是 AI 模型一直在运行，而是 OpenClaw 服务进程作为常驻后台程序持续监听飞书事件流。只要进程在跑、网络通畅、凭证有效，用户随时在飞书里发消息，消息都会被转发给大模型处理，再通过机器人身份把结果发回聊天窗口。整个过程对用户来说是无感的，感受上就是一个随叫随到的助手。
1.2 消息链路全景
在配置之前，先要把一条消息从用户输入到 AI 回复的完整路径理清楚。假设用户在飞书群里 @ 了机器人，并发送了一段文本，这条消息会经历这样的链路：
- 飞书客户端把消息上传到飞书服务器。
- 飞书服务器根据应用配置的事件订阅规则，把
im.message.receive_v1事件推送给 OpenClaw 服务。 - OpenClaw 收到事件后，解析出消息内容、发送者、会话 ID，调用配置好的大模型接口生成回复。
- OpenClaw 调用飞书机器人发消息 API，把回复内容以机器人的身份发送到对应会话。
- 用户看到回复。
这里有一个关键认知：OpenClaw 和飞书之间是“被动接收 + 主动发送”的双向关系。接收消息靠事件订阅，发送消息靠机器人 API。很多新手在配置时只配置了机器人 API 凭据，忘了开事件订阅，结果机器人能“说话”但“听不见”，这就是典型的半通状态。
搞清楚链路之后，排错思路也就清晰了：消息没反应，要么是事件没推送到服务，要么是服务收到了但没调用模型，要么是模型结果没发送回去。下文第 4 节会按这个链路逐步排查。
1.3 为什么是这两个组合
有人会问，飞书自己也有 AI 机器人，为什么还要 OpenClaw？我的理解是，开放平台提供的机器人更像是一个“消息中转容器”，它本身没有智能，也没有生态；而 OpenClaw 的价值在于把“智能”和“工具”真正注入到这个容器里。可以把它理解成：飞书提供了一条通道和一个前台窗口，OpenClaw 是后面真正干活的脑子和手。
另一个优势是自托管。OpenClaw 是开源框架，跑在自己的服务器上，聊天记录、工具调用链路、模型路由都由自己控制。这对一些数据敏感的场景很重要。相比之下，订阅制云端助手虽然省事，但数据路径不可控。如果所在团队对数据边界有要求，自托管方案是绕不开的选项。
至于为什么不直接用命令行，也很好理解：命令行适合开发者自己用，但团队成员不可能人人开终端。飞书作为已经存在的协作界面，不需要额外学习成本，拉个群、发条消息就能和 AI 交互。这就是“渠道层”存在的意义。组合起来，OpenClaw 提供能力，飞书提供入口，最终形成的是一个所有人可用的团队助手。
2. 动手前必须搞懂的工程细节：飞书机器人原理与 OpenClaw 渠道配置
在动手点任何按钮之前，我建议先花五分钟理解飞书机器人的几个核心概念。这一步能帮你省掉后面至少一个小时的排错时间。飞书的机器人体系，本质上是一个“应用”的延伸：你在飞书开放平台创建一个企业自建应用，给应用开启机器人能力，然后通过 API 和事件订阅机制与用户交互。理解清楚这几个概念，配置 OpenClaw 时心里就有底了。
2.1 飞书自建应用的三个核心凭证
在飞书开放平台创建应用之后，你会获得一组关键凭证。这组凭证是 OpenClaw 和飞书通信的身份凭证，配置错误是大多数接入失败的根源。
| 凭证 | 作用 | 对应 OpenClaw 字段 |
|---|---|---|
| App ID | 应用的唯一标识，通常以cli_开头 | app_id |
| App Secret | 应用的访问密钥，用于获取 tenant_access_token | app_secret |
| Verification Token | 事件订阅的校验令牌，用于验证事件来源 | verification_token |
| Encrypt Key | 事件内容的加密密钥，开启加密后必填 | encrypt_key |
这四者的关系可以类比成：App ID 是门牌号，App Secret 是钥匙，Verification Token 是访客口令，Encrypt Key 是信件加密锁。飞书推送事件时，会把事件发送到你的服务器；Verification Token 用来确认这确实是飞书发的，而不是别人伪造的；如果开启了加密，事件体本身还会被 Encrypt Key 加密，OpenClaw 需要用它来解密。
配置 OpenClaw 时，这四个值必须严格保持一致，尤其是复制粘贴时不能带多余空格或换行。我见过太多因为复制时吞掉最后几个字符导致鉴权失败的情况。可以把它们先写在一个临时本地文件里，再逐个填入配置文件，尽量避免手动键入。
2.2 事件订阅的两种投递模式
飞书的事件订阅支持两种模式，选哪种取决于你的部署环境。理解这两者的区别，有助于你判断自己是不是被“公网回调地址”卡住了。
第一种是 Webhook 回调模式。你在飞书开放平台填写一个公网可达的 HTTPS 地址，飞书服务器会向该地址推送事件。这种方式部署最直观，但要求你的服务器必须有一个公网 IP，或已配置好域名解析和证书。
第二种是长连接模式。应用通过 WebSocket 与飞书服务器保持长连接，事件通过连接直接推送到本地，不需要公网回调地址，也不需要在网关层处理加解密。对个人开发者来说，这种方式规避了最麻烦的公网暴露问题。
在 OpenClaw 的接入实践中，两种模式都能对接。我的建议是：如果你有一台带公网 IP 的云服务器，用 Webhook 回调模式，链路清晰且便于在网关层做额外鉴权；如果你仅在本机调试或服务器没有公网入口，优先尝试长连接模式，能少踩很多网络配置的坑。两种模式在 OpenClaw 侧的差异，通常只体现在渠道配置的mode字段。
2.3 OpenClaw 渠道配置核心字段
OpenClaw 的渠道配置一般集中在配置文件的channels或integrations节点下。不同版本的框架字段名可能略有差异，但核心字段是稳定的。下面是一个典型的飞书渠道配置示例：
channels: feishu: enabled: true mode: webhook # webhook 或 long_connection app_id: cli_xxxxxxxxxxxxxxxx app_secret: xxxxxxxxxxxxxxxxxxxxxxxx verification_token: xxxxxxxxxxxxxxxxxxxx encrypt_key: xxxxxxxxxxxxxxxxxxxxxxxx event_path: /feishu/event # webhook 模式下的事件接收路径这里强调几个容易出错的地方。enabled必须是true，把配置写好但忘了启用渠道，是最常见的问题，没有之一。mode的取值必须和你在飞书开放平台选择的事件订阅方式一致，两边不一致就会出现“飞书推了事件但 OpenClaw 不处理”的怪现象。event_path只影响 Webhook 模式，它是 OpenClaw 服务内部暴露给飞书的事件接收路径，飞书开放平台填写的回调地址，要完整包含这个路径。
如果 OpenClaw 是通过环境变量方式配置的，对应的常见变量名也差不太多，一般是在配置文件名上画蛇添足地加个前缀。具体以你使用的版本文档为准，但无论如何，配置完成后第一步一定是重启服务，确保新配置生效。这个动作简单，却经常被忘记。
2.4 权限清单：少配一个 Scope 都收不到消息
飞书机器人的权限控制比较细致，需要在应用的“权限管理”页面手动开启。我整理了一份接入 OpenClaw 时最常用的权限清单，建议直接对照勾选。
| 权限名称 | 权限代号 | 用途 |
|---|---|---|
| 获取与发送单聊、群组消息 | im:message 或 im:message:send_as_bot | 机器人发送消息 |
| 读取用户发给机器人的单聊消息 | im:message:readonly 或 im:message:read | 读取消息内容 |
| 读取群组消息 | im:message.group_msg 或同类权限 | 读取群聊中的消息 |
| 获取群组信息 | im:chat | 获取会话基本信息 |
需要特别提醒的是，飞书开放平台的权限体系会随着版本演进调整，具体权限名称可能在界面上有所变化。我的建议是直接用权限搜索框搜“消息”关键词，把和“读取消息”“发送消息”“接收群消息”相关的都勾上。权限配置完成后，在飞书开放平台的操作中心通常需要进行一次版本发布或更新，新权限才会真正生效。另一件容易忽略的事：如果应用处于“开发中”状态且可用范围设置过窄，部分成员可能无法正常使用机器人。
关于为什么少配一个读取权限会导致收不到消息，这里有个关键：事件推送和读取消息其实是两件事。事件推送负责通知你“有一条消息进来了”，但如果应用没有读取或获取消息内容的权限，推送过来的事件里就不携带完整消息内容，OpenClaw 自然也就拿不到可用的文本。这个机制和直觉不符，却是飞书比较常见的限制——通知是一回事，内容读取权限是另一回事。
3. 完整实操：从创建应用到跑通第一条消息
下面进入真正的动手环节。我会按顺序逐步操作，并把每一步的目的和动作都写清楚。整个流程分为四段：创建飞书应用、配置事件订阅、部署 OpenClaw、上线验证。建议准备一个记事本，把每一步得到的凭证先记录下来，避免反复切换页面。
3.1 第一步：创建飞书自建应用并开启机器人能力
首先打开飞书开放平台，登录后进入“开发者后台”，在“企业自建应用”区域创建一个新应用。名称可以随便起，比如“团队 AI 助手”，描述如实填写即可。创建完成后进入应用详情页，左侧菜单可以看到“凭证与基础信息”“权限管理”“事件订阅”“机器人”等分类。
先进入“应用能力”或“机器人”设置页，开启机器人能力。这一步会为应用绑定一个机器人账号，后续 OpenClaw 将使用这个身份来收发消息。机器人开启后，在“凭证与基础信息”页面记下 App ID 和 App Secret，这两个值是 OpenClaw 与飞书通信的基础。
在继续之前，建议顺手把“安全设置”里的 IP 白名单和重定向 URL 等选项先留空，等一切跑通之后再按需收紧。过早配置安全限制，反而可能把自己拦住，延长排错时间。当然，这只适合在开发调试阶段这么做，生产环境必须配置合理的安全策略。
3.2 第二步：配置事件订阅并完成回调验证
进入“事件订阅”页面，选择事件投递模式。如果选择 Webhook 回调模式，需要填写事件接收回调地址；如果选择长连接模式，则不需要填地址，直接添加事件即可。两种模式的核心步骤都是相同的：添加事件im.message.receive_v1，也就是“接收消息”事件。
添加事件之后，飞书会要求验证你的回调地址。它会向指定地址发送一个验证请求，内含challenge参数。你的服务端程序收到验证请求后，需要把challenge原样返回才能通过验证。OpenClaw 内部已经实现了这个逻辑，所以你只需要确保回调地址可以访问到 OpenClaw 服务，并且verification_token与encrypt_key配置正确即可。
如果你用的是自己搭的 Nginx 网关，注意两点：一是必须转发 HTTPS 请求到 OpenClaw 监听端口，证书缺失会导致飞书直接拒绝连接；二是不要在自己的网关层对事件 body 做多余的重组或格式化，尽量保持原始请求完整转发。验证失败时，先看 OpenClaw 的访问日志，确认飞书有没有真的把请求打进来，这一步就能定位是网络问题还是验签问题。
3.3 第三步：部署 OpenClaw 并写入飞书配置
OpenClaw 的部署方式有很多种，最省心的是用 Docker。官方仓库通常提供编排文件，把配置挂载到容器内即可。一个最小化的部署过程大概是：
- 在服务器上准备一个工作目录，比如
/opt/openclaw。 - 将 OpenClaw 的编排文件或二进制文件放入目录，并创建配置文件。
- 把上一节记录的凭证填入配置文件的
channels.feishu节点。 - 启动服务，观察启动日志，确认飞书渠道被正确加载。
以 Docker 编排方式为例，运行起来之后可以用docker logs查看启动日志。如果看到类似“feishu channel started”这类信息，说明渠道加载成功；如果看到鉴权失败或事件订阅连接错误，优先检查凭证是否复制完整、mode是否和飞书侧一致。
个人建议在正式环境使用 systemd 或 Docker 的restart: always策略来管理进程，这样即使进程崩溃或服务器重启，OpenClaw 也能自动拉起。这一步对“24 小时在线”至关重要，没有守护策略的常驻服务，早晚会因为一次意外掉线而让你错过重要消息。
3.4 第四步：验证链路，从“收到消息”到“回复成功”
服务启动后，先做一个最基础的验证：在飞书里找到应用机器人，发起一条单聊消息，比如“你好”。正常情况下，OpenClaw 会接收到事件，调用大模型，然后以机器人身份回复。
如果这条消息回复成功了，再测试群聊场景：创建一个测试群，把机器人拉进群，@ 机器人发送消息。这里要留意，群聊和单聊的事件结构与权限略有差异，群聊通常需要额外的读取群消息权限。如果单聊通了但群聊没反应，大概率不是 OpenClaw 的问题，而是权限列表少勾了一项。
在验证过程中，可以同时打开 OpenClaw 的日志观察事件流。你会发现，每收到一条消息，日志中会出现一条事件记录，随后出现模型调用记录和消息发送记录。把这三条日志和实际效果对照着看，能帮你快速定位问题到底出在哪一层。
3.5 一条完整的验收清单
为了让整个上线过程可预期，我把自己每次接入新环境都会执行的验收清单放在这里，可以按顺序打勾：
- 飞书后台凭证已记录，App ID、App Secret 完整无误
- 机器人能力已开启，应用状态可用
- 事件订阅已添加
im.message.receive_v1，回调验证通过 - 所需权限均已勾选，并已发布或更新版本
- OpenClaw 配置中飞书渠道为
enabled: true - 服务已重启，日志显示渠道加载成功
- 单聊消息已收到机器人回复
- 群聊 @ 机器人已收到回复
- 进程守护已配置，重启后自动拉起
这套清单看着简单，但每一步都能拦住不少人。我自己在给同事搭测试环境时，至少有三次卡在第七步之前，原因各不相同，但大招都在清单的前几项。
4. 常见问题与排查技巧实录
这一节的素材都来自真实踩坑现场。我把它整理成“问题 → 现象 → 原因 → 解决”的结构，希望能帮你快速定位。同时我也会分享一套通用的排查顺序，比零散地找问题更高效。
4.1 问题：保存回调地址时验证一直失败
现象是：在飞书开放平台填写回调地址，点击保存，系统提示验证失败。这是接入飞书时遇到的第一个大坑。
原因基本集中在四类：第一，回调地址不是 HTTPS，飞书只接受 HTTPS；第二，地址指向的服务没有启动或端口不通，飞书请求打不进来；第三，verification_token或encrypt_key配置错误，服务端无法完成验签；第四，反向代理层把请求体改写或丢弃，导致 OpenClaw 拿不到校验参数。
排查时我的顺序是：先在服务端看访问日志，确认飞书的验证请求有没有到达 OpenClaw。如果完全没到，就是网络或地址问题，检查证书、域名解析、端口；如果到了但日志里出现鉴权失败，就是凭证问题，重点检查verification_token是否和飞书后台完全一致。还有一个细节：有的版本要求回调地址路径必须与 OpenClaw 内部路由完全匹配。我见过有人把event_path设成/feishu/event，但在飞书后台填地址时漏掉了/event，验证自然失败。
4.2 问题：消息发出去，机器人完全没有反应
这个现象比验证失败更隐蔽，因为配置界面看起来一切正常，事件订阅也添加了，但用户发消息之后机器人像没看见一样。
我从经验里总结出的原因主要三个。第一个是机器人能力没开启，应用本身没有机器人身份，当然无法收发消息。第二个是事件订阅没有添加im.message.receive_v1，飞书压根没有把消息事件推给 OpenClaw。第三个是权限不足，事件推送了但 OpenClaw 解析不到消息正文，自然也无法回复。
还有一种容易忽略的情况：应用虽然创建了，但版本从未发布或更新。在企业自建应用里，修改权限和事件订阅之后，通常需要点击“创建版本”或“发布”，让配置生效。很多人在开发者后台改了配置就觉得万事大吉，其实飞书还在跑旧版本配置。建议每次修改配置后，都回到版本管理页面完成一次发布动作，再回来测试。
4.3 问题：机器人回复乱码或解密失败
如果你开启了事件加密，OpenClaw 侧也配置了encrypt_key，但消息还是乱码或日志里报解密错误，那基本是 Encrypt Key 没对齐。
这里有一个很容易踩的细节：飞书后台的 Encrypt Key 支持手动输入，也可以自动生成。如果你在飞书后台点击“自动生成”，页面会新生成一个 Key，但旧配置不会自动同步到你的服务器。如果 Key 是在配置好 OpenClaw 之后又重置过一次，两边就会不一致。解决办法很简单，重新复制最新的 Encrypt Key 到配置文件，重启服务。
另外，如果使用 Webhook 模式且前面套了 Nginx，要确保原始请求体没有被改变。飞书的事件加密是基于原始 body 的解密流程，如果反向代理层对 body 做了压缩、转义或重组，解密就会失败。我的建议是在 Nginx 配置里对事件回调路径单独关闭 gzip，并保持proxy_pass的完全透传。
4.4 问题：一条消息被回复了两遍
遇到这个现象的人不多，一旦遇到就会很困惑。原因是飞书的事件订阅有重试机制：如果服务端没有在超时时间内返回成功响应，飞书会认为推送失败，并重新推送同一事件。
OpenClaw 内部通常会对短时间内的重复事件做去重，但你如果在前面加了自己的消息处理逻辑，或者在网关层做了超时重试，就可能破坏它的幂等性。排查时先看日志中是否存在两条相同message_id的事件记录，如果有，就是重复推送。解决思路是保证事件处理接口能快速返回 200，不要在事件回调里做耗时操作；如果必须做，也应该先用异步队列接收事件，再在后台处理。
这里还有一个经验：如果你自己实现了中间件，注意保存已处理的message_id集合，做一次简单的幂等判断，能从根本上避免重复回复。
4.5 一套通用的排查顺序
当机器人表现异常时，我建议按下面这个顺序排查，而不是凭感觉乱试：
- 看 OpenClaw 日志：渠道是否启动、事件是否到达、报错信息是什么。
- 看飞书事件订阅状态：事件是否成功投递、投递记录里是否有失败。
- 验证鉴权配置：
app_id、app_secret、verification_token、encrypt_key四者是否匹配。 - 验证权限范围：所需权限是否勾选、版本是否已发布、应用可用范围是否包含测试账号。
- 验证服务状态：进程是否存活、端口是否监听、依赖的服务（如数据库）是否正常。
这套顺序几乎能覆盖 90% 的接入问题。特别强调第一点：OpenClaw 日志是最直接的信息来源，很多问题根本不用猜，日志里写得明明白白。养成先看日志再下结论的习惯，能帮你少走很多弯路。
提示：无论遇到什么问题，先看日志再下结论，这是所有排错工作的第一原则。
5. 安全、运维与进阶扩展
把机器人跑通只是开始，真正让一个 AI 助手稳定、安全地长期运行，还需要一些运维上的思考。这个章节我会分享一些安全红线、日常运维建议，以及让助手从“能用”变成“好用”的扩展方向。
5.1 安全红线：密钥管理与可用范围
飞书应用的app_secret相当于机器人账号的最终控制权，一旦泄露，别人可以冒充你的应用收发消息。OpenClaw 配置文件里明文保存密钥，所以文件权限一定要收紧。我用 Docker 部署时，习惯把配置文件挂载为只读，宿主机上把文件权限设为600。不要把配置文件提交到代码仓库，哪怕仓库是私有的，也尽量避免。
在飞书开放平台侧，建议把“安全设置”里的 IP 白名单配置好，只允许 OpenClaw 所在服务器的出口 IP 调用 API。虽然多一步配置，但能显著缩小密钥泄露后的影响范围。应用的“可用范围”也值得认真设置，开发阶段可以先设为仅自己和测试账号，稳定后再扩展到整个团队。
还有一条和 AI 助手相关的安全原则：不要给机器人配置过高的工具权限。OpenClaw 的价值在于工具调用，但工具越多，被滥用的面越大。对于高风险执行类工具，比如删除服务器文件、执行任意脚本，一定要在配置层加限制或二次确认。AI 可能会被 prompt 注入诱导，这点在接入飞书之后更值得警惕，因为入口从你一个人变成了所有能接触机器人的群成员。
5.2 运维：进程守护、日志与更新
“24 小时在线”不是把进程启动就不管了。机器人的稳定性取决于三件事：进程是否常驻、网络是否畅通、凭证是否过期。
进程守护，推荐两种方式：systemd 服务或 Docker Restart 策略。systemd 适合裸机二进制部署，通过Restart=always保证崩溃自动拉起；Docker 则在编排文件里配置restart: always，两者效果相同。这里要注意，守护策略不能替代健康检查，建议在 OpenClaw 服务里开一个简单的健康检查接口，配合监控工具定期探测，接口无响应时自动告警。
日志管理也是长期运行的必修课。OpenClaw 的日志会包含消息内容、模型调用参数等敏感信息，建议定期轮转和清理，避免日志文件膨胀占满磁盘。配置日志轮转时，可以按天或按大小拆分，保留最近 30 天即可。如果日志中出现大量解密失败或鉴权失败记录，说明有异常调用，值得关注。
凭证方面，部分飞书应用的密钥支持轮换。建议把轮换机制纳入运维流程，定期更换app_secret，更换后同步更新 OpenClaw 配置并重启服务。这虽然不能直接预防泄露，但能有效压缩泄露后的风险窗口。
5.3 进阶扩展：让这个助手真正好用
接入完成后的下一步，才是发挥 OpenClaw 价值的开始。这里分享几个我实测过比较高价值的扩展方向。
第一个是给助手接知识库。通过 MCP 挂载一个向量检索服务，把团队的文档、FAQ、历史工单灌进去，机器人就能自动从知识库里检索答案，而不是每次都靠模型瞎猜。对内部助手来说，这一步带来的体验提升是最明显的。
第二个是让助手能主动触发任务。利用飞书的事件订阅，不止接收消息事件，还可以接收审批事件、日程事件。比如在审批流里加入一个 AI 审核节点，让机器人在审批通过之后自动执行一些后续操作。这个场景下，OpenClaw 不再只是被动回答问题，而是真正嵌入到团队工作流中。
第三个是定时任务。OpenClaw 支持配置定时触发的能力，比如每天早上九点自动往运营群里推送昨天的数据简报。这个功能特别适合“日报机器人”场景，搭配飞书的消息卡片，效果比纯文本好得多。
第四个是多机器人分工。你可以部署多个 OpenClaw 实例，每个实例使用不同的飞书应用或不同的系统提示词，分别负责技术答疑、行政助理、数据分析等不同角色。虽然运维成本会上去，但职责清晰之后，单个机器人的效果通常比一个万能机器人更好。
最后，如果你对消息格式有要求，飞书的消息卡片是一个绕不开的话题。OpenClaw 在回复中支持富文本卡片，但需要你在配置里显式开启卡片模式。实测下来，带标题、状态标签和按钮的卡片，在群里比纯文本醒目得多，也更容易被团队成员接受。
我自己接入完这套体系后最深的一个体会是：技术方案的复杂度往往不来自框架本身，而来自两侧系统的配置细节。飞书的权限逻辑、回调验证机制、事件重试策略，单独看都不难，但组合在一起，确实需要一份完整的“避坑地图”才能一次走通。
最后分享一个我后来一直在用的小技巧：在飞书开放平台的“事件订阅”页面，飞书会保留最近的事件投递记录。当你怀疑消息没有送达时，别急着改代码，先去这里看记录。它能明确告诉你事件是否成功推送、失败原因是什么。把这里当作排错的第一现场，很多问题能节省一半的排查时间。希望这篇指南能帮你少踩几个坑，尽快把属于你自己的 24 小时助手跑起来。
