本页内容
本页内容
区域平台
Feishu 设置
运行通道设置向导，然后了解 OpenClaw 如何持久接受入站 Feishu 事件。
快速开始
运行通道设置向导
如果缺少 @openclaw/feishu 插件，则会安装它，然后进入设置流程：
- 手动设置：粘贴来自Feishu开放平台（
https://open.feishu.cn）或Lark开发者（https://open.larksuite.com）的应用程序ID和应用程序密钥。 - QR setup：扫描Feishu应用程序中的QR代码以自动创建机器人。此流程将 DM 锁定到您自己的帐户（
dmPolicy: "allowlist"与您的open_id）。
该向导还要求提供 API 域（Feishu 与 Lark）和组策略。如果国内 Feishu 移动应用程序对 QR 代码没有反应，请重新运行设置并选择手动设置。
设置后验证通道
配置更改遵循 [hot reload](/gateway/configuration/hot-reload)。检查 Feishu 是否准备就绪： ```bash openclaw channels status --probe ``` 如果网关离线，请启动网关。入站持久性
在代理调度之前，OpenClaw 将经过身份验证的 im.message.receive_v1 和 drive.notice.comment_add_v1 信封持久排队。 webhook模式下，耐用的200携带x-openclaw-delivery-accepted: durable；验证挑战、非持久事件类型和错误响应省略了标记，因此反向代理可以要求它区分持久接受和通用 200。待处理或可重试的事件在网关重新启动后仍然存在，保持每个聊天或文档的序列化，并使用 Feishu 的事件 ID 来抑制重复的队列条目，同时存在活动或保留的完成记录。
如果 WebSocket 事件在有界重试后无法持久，则 OpenClaw 会关闭该套接字并强制建立新的经过身份验证的连接，而不是继续经过未提交的轮次。其他 Feishu 事件类型（包括反应和 VC 会议邀请）使用其正常事件路径，并且不会收到此持久队列保证。
当 Feishu 帐户停止时，OpenClaw 关闭消息、菜单、卡片、会议和反应处理程序的准入，并等待接受的处理程序和重放防护写入在释放帐户资源之前解决。每聊五分钟的队列限制释放了点餐槽位；它不会取消原始处理程序，也不会在该处理程序仍在运行时完成帐户清理。
Webhook 传递窗口
Feishu 在发送时对每个 Webhook 传递进行签名，因此捕获的签名回调将永远保持有效签名。因此，在解析正文之前，Webhook 模式会拒绝任何 x-lark-request-timestamp 早于或晚于网关主机时钟一小时以上的签名回调。这是一种重播防御：它与每条消息的重播防护（24 小时窗口）一起工作，因此重新传递的签名回调无法重新触发相同的操作。
实际后果：
- 保持网关主机时钟同步（NTP）。与 Feishu 服务器偏差超过一小时的主机时钟会拒绝新的交付。
- Feishu 交付在发送时进行签名，因此普通重新交付带有新的时间戳并且不受影响。
- WebSocket 模式不受此窗口的影响。
- 该窗口没有配置密钥；它是故意固定的。