设置

运行通道设置向导，然后了解 OpenClaw 如何持久化接受入站 Feishu 事件。

快速开始¶

1. 运行通道设置向导

openclaw channels login --channel feishu

• 手动设置：粘贴来自 Feishu 开放平台（https://open.feishu.cn）或 Lark 开发者（https://open.larksuite.com）的 App ID 和 App Secret。
• 二维码设置：在 Feishu 应用中扫描二维码以自动创建机器人。此流程会将 DM 锁定到你自己的账户（使用你的 open_id 的 dmPolicy: "allowlist"）。

向导还会询问 API 域（Feishu 或 Lark）和群组策略。如果国内 Feishu 移动应用未响应二维码，请重新运行设置并选择手动设置。

2. 设置后验证通道

配置更改遵循 热重载。检查 Feishu 是否就绪：

openclaw channels status --probe

入站持久性¶

OpenClaw 会在智能体分发之前，对已认证的 im.message.receive_v1 和 drive.notice.comment_add_v1 事件信封进行持久化排队。在 webhook 模式下，持久化 200 会携带 x-openclaw-delivery-accepted: durable；验证质询、非持久化事件类型和错误响应会省略该标记，因此反向代理可以要求该标记，以区分持久化接受与通用 200。待处理或可重试事件在 Gateway 重启后仍然存在，按聊天或文档保持串行化，并在活动或保留的完成记录存在时，使用 Feishu 事件 ID 抑制重复队列条目。

如果 WebSocket 事件在有限次重试后仍无法持久化，OpenClaw 会关闭该套接字并强制建立新的已认证连接，而不是继续越过未提交的回合。其他 Feishu 事件类型（包括表情回应和 VC 会议邀请）使用其正常事件路径，并且不获得此持久化队列保证。

当 Feishu 账户停止时，OpenClaw 会关闭消息、菜单、卡片、会议和表情回应处理器的准入，并等待已接受的处理器和重放防护写入完成后再释放账户资源。每聊天五分钟队列限制会释放排序槽位；它不会取消原始处理器，也不会让账户清理在该处理器仍在运行时完成。

Webhook 投递窗口¶

Feishu 在发送时对每个 webhook 投递进行签名，因此捕获的已签名回调会永远保持有效签名。因此，webhook 模式会在解析正文之前，拒绝任何 x-lark-request-timestamp 比 Gateway 主机时钟早或晚一小时以上的已签名回调。这是一种重放防御：它与按消息的重放防护（24 小时窗口）协同工作，使重新投递的已签名回调无法再次触发同一操作。

实际影响：

• 保持 Gateway 主机时钟同步（NTP）。如果主机时钟与 Feishu 服务器漂移超过一小时，新的投递将被拒绝。
• Feishu 投递在发送时签名，因此普通重新投递携带新的时间戳，不受影响。
• WebSocket 模式不受此窗口影响。
• 此窗口没有配置键；它是有意固定的。