飞书插件 Patch Dashboard
base @larksuite/openclaw-lark@2026.5.12  +  自家 patches  ·  source c1a8461..HEAD
31
Patches
5
Future-proof
8
Modules
模块1 · Card lifecycle 6 patches
patch-1a ⭐ amend 不新加
出卡提前 + 蛋姐群闪屏豁免
干了啥
消息一来就立刻弹出空白的处理中卡片,不再等 bot 真正有内容才显示。蛋姐群等多 bot 活跃群除外,它们延迟出卡避免闪屏。
修了什么 Bug
用户发消息后屏幕上空了 1-2 秒,以为 bot 没收到
Bug 从哪来
官方版本是懒出卡,要等真有内容发时才创建卡片
涉及文件
reply-dispatcher.js, streaming-card-controller.js
建议操作
patch-1b
NO_REPLY stream leak — onIdle 空响应守卫
干了啥
防止 bot 没输出任何内容(配额耗尽或上游错误)时被误当成 NO_REPLY 静默处理,把本该显示的错误信息撤掉。
修了什么 Bug
bot 配额耗尽或空响应时,错误卡片被悄悄撤回,用户啥都看不到
Bug 从哪来
空字符串 startsWith 空字符串永远是 true,任何 0 token 的 run 都触发撤卡
涉及文件
streaming-card-controller.js onIdle()
建议操作
patch-1c
kill Done. fallback + 撤空卡
干了啥
bot 跑完但没有可见输出时,不再发 Done. 这种尴尬文案,改成静默撤回空卡。同时修了一个多余的等待操作。
修了什么 Bug
群里莫名其妙出现 Done. 这种冷冰冰的机器人文案
Bug 从哪来
飞书 5.x 升级后群聊 streaming 被吞,bot 用 Done. 兜底
涉及文件
reply-dispatcher-types.js, dispatch.js, streaming-card-controller.js
建议操作
patch-1d
recallCard 时序修复(底层)
干了啥
修复撤卡底层操作的时序问题。原来进入撤卡函数第一步就标为已取消,但 API 还在飞行中,时序打架导致卡片孤零零留在那里没有内容。
修了什么 Bug
用户连发两条消息或撤回重发时,卡片不出现,回复变成纯文字
Bug 从哪来
recallCard 进入时立即 transition aborted,但 cardkit API 还在 in-flight
涉及文件
streaming-card-controller.js recallCard()
建议操作
patch-1e
用户撤回消息 → abort run + 撤 reply 卡
干了啥
用户撤回自己发的消息后,bot 正在进行的处理任务跟着停,reply 卡片也一并撤回,不留僵尸卡。
修了什么 Bug
用户撤回消息后 bot 还在傻跑,reply 卡留在群里浪费 token
Bug 从哪来
官方版本没有监听消息被撤回这个事件
涉及文件
streaming-card-controller.js, dispatch.js, chat-queue.js, event-handlers.js, monitor.js
建议操作
patch-1f
Gateway restart drain streaming-card hooks
干了啥
Gateway 重启时,等正在进行的卡片操作全部完成后再关闭,不让卡片停在中间帧。
修了什么 Bug
gateway restart 后,部分卡片永久卡在流式输出中间帧,客户端显示一半内容
Bug 从哪来
官方只给 5 秒 drain 窗口,cardkit token re-fetch 可能超时被杀
涉及文件
plugin.js
建议操作
模块2 · Collect 消息合并 3 patches
patch-2a
plugin-layer 消息合并器
干了啥
bot 忙着处理时,用户快速连发的多条消息不再各自排队分别处理,而是攒在一起,等 bot 忙完一次性合并回复。
修了什么 Bug
用户连发 3 条消息,bot 傻乎乎一条条回,浪费 token 且体验割裂
Bug 从哪来
官方版本每条消息独立 dispatch,没有合并等待机制
涉及文件
chat-collector.js(新增), event-handlers.js
建议操作
patch-2b
/stop 等 slash 指令绕过合并器
干了啥
让 /stop、/reset 这类指令无视消息合并机制,立刻执行,不被攒进 buffer。
修了什么 Bug
bot 忙着时发 /stop 不生效,被合并成普通文本发出去了
Bug 从哪来
2a 的合并器把所有消息都攒起来,没有区分 slash command
涉及文件
event-handlers.js
建议操作
patch-2c
顶层群消息 ThreadId 归一化
干了啥
修正了消息合并时对话题 ID 的处理方式,让顶层群消息能被正确识别为同一来源并合并。
修了什么 Bug
顶层群消息合并失效,每条消息还是单独 dispatch
Bug 从哪来
飞书每条顶层消息的 threadId 等于自己的 message_id,SDK 把它们判成不同 key
涉及文件
dispatch.js
建议操作
模块3 · Dispatch/授权/白名单 5 patches
patch-3a
强制授权 + 6 个功能子群白名单
干了啥
两件事:① 强制所有消息都视为有权限,让群里的 thinking/reasoning 正常显示;② Yuhui 的 6 个功能小群(邮件处理/UX Hiring 等)加白名单,像私聊一样不用 @ 就响应。
修了什么 Bug
群里普通消息 thinking 不显示;Yuhui 功能子群发消息 bot 不理
Bug 从哪来
官方默认非 /! 开头消息 CommandAuthorized=false;群消息默认需要 @ 才响应
涉及文件
dispatch-builders.js
建议操作
patch-3b ⭐ amend 不新加
伪 DM 白名单 +3 扩展(future-proof)
干了啥
在 3a 基础上,把 rr×Yuhui 1v1 群、1v1 话题群、UX 日报群也加进白名单,同样免 @。以后新增白名单 amend 这个 patch。
修了什么 Bug
这三个群里发消息 bot 不响应
Bug 从哪来
3a 的白名单只有 6 个群,这 3 个遗漏了
涉及文件
dispatch-builders.js
建议操作
patch-3c
群消息 sender 加 [name](open_id) 标签
干了啥
群消息里每个发言人都带上稳定的 open_id 标签,让 LLM 准确知道是谁在说话,不只靠名字。
修了什么 Bug
多人群里 bot 张冠李戴,把 A 说的话当成 B 的
Bug 从哪来
官方只传名字不传 open_id,同名或相似名时 LLM 会混
涉及文件
dispatch-builders.js
建议操作
patch-3d
@ rr 时注入 MUST respond 提示
干了啥
有人 @ rr 同时还 @ 了别人时,系统在 prompt 里插一行提示 LLM「你被点名了,必须回」,防止 bot 误判自己不是主要对象而选沉默。
修了什么 Bug
@ rr 但同时 @ 了别人,rr 选了 NO_REPLY 不回应
Bug 从哪来
过滤掉自身 mention 后,LLM 看到消息像是发给别人的
涉及文件
dispatch-builders.js
建议操作
patch-3e
per-group replyInThread 配置生效
干了啥
让「每个群单独配置是否在话题里回复」这个功能真正生效。之前配了也是白配。
修了什么 Bug
openclaw.json 里配了 replyInThread 但 bot 照样不回话题
Bug 从哪来
配置读取逻辑根本没去看这个字段
涉及文件
reply-in-thread.js(新增), dispatch-context.js
建议操作
模块4 · Config/Schema/UX 4 patches
patch-4a ⭐ amend 不新加
feishu channelConfigs schema 补全(future-proof)
干了啥
给飞书插件配置补全了 schema 定义,让 openclaw.json 里写的所有高级设置(spinner短语、表情、话题回复、群分组等)不再被校验器删掉。以后加新配置字段 amend 这个 patch。
修了什么 Bug
openclaw.json 里配了一堆飞书设置,启动时全被 host 校验器 strip 掉,配置白写
Bug 从哪来
plugin.json 的 schema.properties 是空的,strict validator 不认识的字段全删
涉及文件
openclaw.plugin.json, config-schema.js
建议操作
patch-4b
91 条 spinner 短语内置
干了啥
把 91 条有 rr 风格的等待提示语内置进去,取代原来的 Processing...,每次处理时随机显示一条。
修了什么 Bug
bot 处理时卡片上只显示 Processing... 既单调又没 rr 的味道
Bug 从哪来
官方写死了这个文本,没有随机化机制
涉及文件
builder.js
建议操作
patch-4c
182 个 typing emoji 内置
干了啥
内置 182 个有效的「正在输入」表情符号,每次随机选一个,取代原来单个会报错的表情。
修了什么 Bug
typing 表情报 code:231001 错误,或者只有一种单调表情
Bug 从哪来
官方写死了单个 emoji 类型,飞书 API 不接受这个
涉及文件
typing.js
建议操作
patch-4d
yuhui-config 安装包(footer 配置)
干了啥
一个安装脚本,把卡片底部 6 个显示项(状态/耗时/模型/token/缓存/上下文)写入配置文件。跑过一次就不用管了。
修了什么 Bug
footer 不显示或配置太麻烦
Bug 从哪来
footer 是 per-profile 配置,需要手动写入配置文件
涉及文件
yuhui-config/install.sh, feishu-config.json, README.md
建议操作
模块5 · rr Message Tools 4 patches
patch-5a
message-tool Phase 3 — 读工具收编进 dispatcher
干了啥
把之前分散的「读消息历史」「查群成员」「看话题」等工具统一收进 feishu_im_user_message 一个工具里,用 action 参数区分。
修了什么 Bug
rr 想读群历史、查成员、查 thread,没有对应工具
Bug 从哪来
官方包只有 send/reply,读相关功能要用分散的 deprecated 独立工具
涉及文件
src/tools/oapi/im/*, src/tools/oapi/chat/*
建议操作
patch-5b
message-tool Phase 4 — mget/reactions/resolve_url/resolve_p2p
干了啥
补充了 4 个官方包完全没有的能力:批量获取消息、读表情回应、解析飞书链接、通过 open_id 查私聊 chat_id。
修了什么 Bug
这 4 个功能官方包完全没有
Bug 从哪来
官方 npm 包本来就没实现这些 API
涉及文件
im/*, url-parser.js(新增), chat.js
建议操作
patch-5c ⭐ amend 不新加
Phase 4 hotfixes(future-proof)
干了啥
5b 上线后发现的 3 个连锁问题:字段名对不上、reactions 的 URL 多了 /list 导致 404、reactions 人名 fallback 不完整。以后同类问题 amend 这个 patch。
修了什么 Bug
reactions/resolve_p2p 跑起来报错或拿到空数据
Bug 从哪来
5b 实现时字段名和 API endpoint 对照官方文档有偏差
涉及文件
message.js, chat.js, url-parser.js, name-resolver.js
建议操作
patch-5d ⭐ amend 不新加
name cache hotfixes(future-proof)
干了啥
修复了名字缓存被「污染」的两个问题:① 查询失败时不应该把空名字写进缓存;② 批量查用户时不能用空名字覆盖已有的真实名字。
修了什么 Bug
用户名字一直拿不到,始终显示 open_id 而不是名字
Bug 从哪来
sentinel(空结果标记)写得太宽,临时错误被当成这个人不存在永久缓存
涉及文件
user-name-cache.js, name-resolver.js
建议操作
模块6 · Name resolver 2 patches
patch-6a
name-resolver Phase 0 — 统一名字存储中心
干了啥
把原本散在 4 个地方的名字缓存逻辑合并成一个统一的名字查询中心,避免从不同地方查出不同结果。
修了什么 Bug
在 reactions 里显示的名字和其他地方显示的不一样;缓存命中率低
Bug 从哪来
UAT/TAT 缓存分散在 4 个文件,互不同步
涉及文件
name-resolver.js(新增), user-name-uat.js
建议操作
patch-6b
name-resolver Phase 1 — tool-layer 调用方迁移
干了啥
把 4 个老文件的名字查询都切换到 6a 建的统一查询中心,让改造真正生效。
修了什么 Bug
6a 建好了统一中心但没人用,旧的分散缓存还在跑
Bug 从哪来
迁移需要改所有调用方,6a 只建了中心,这个 patch 做迁移
涉及文件
format-messages.js, message-read.js, chat/chat.js, chat/members.js
建议操作
模块7 · Feishu-social 扩展 6 patches
patch-7a
feishu-social 安装 + 注册
干了啥
把 feishu-social 这个群上下文注入扩展从 Lucien fork 移植过来,让它在官方 npm 版本里也能用。
修了什么 Bug
官方 npm 包没有 feishu-social,切到官方后这个功能消失了
Bug 从哪来
feishu-social 是 Lucien 自己加的,官方 npm 包没有
涉及文件
src/extensions/feishu-social/*, index.js, openclaw.plugin.json
建议操作
patch-7b
feishu-social 群上下文缓存刷新
干了啥
每次 bot 发完消息后自动刷新群上下文缓存,下次取用的时候是最新的。
修了什么 Bug
bot 回复后群上下文还是旧的(比如新来的成员没出现)
Bug 从哪来
群上下文缓存没有主动失效机制
涉及文件
context.js, index.js
建议操作
patch-7c
feishu-social 成员名字解析链条加固
干了啥
三个改进:API 拿不到名字时从本地注册表兜底;成员信息通过 API 动态更新不再只靠静态文件;所有群都能预取成员信息。
修了什么 Bug
名字显示成 open_id;成员变动要手动改文件
Bug 从哪来
名字解析只有一条路,断了就没有
涉及文件
index.js, member-cache.js(新增), enrich.js
建议操作
patch-7d
feishu-social 中性化(opt-in + 无人格)
干了啥
把原本写死 Lucien 人格、默认开启的 feishu-social 改成默认关闭、可配置、人格中立。装上不等于启用,需要主动开启。
修了什么 Bug
官方版装上 feishu-social 就带了 Lucien 的人格和模板,和 rr 完全不搭
Bug 从哪来
原版 Lucien fork 是为他自己定制的,没做参数化也没有 opt-in 设计
涉及文件
feishu-social/*, openclaw.plugin.json
建议操作
patch-7e
feishu-social UAT-enrich 群上下文
干了啥
群上下文里注入成员信息时,额外用 UAT 查一份更完整的(中文名/别名/display_name),让 LLM 认人更准。
修了什么 Bug
多人群里 bot 叫错名字或者搞混人
Bug 从哪来
群上下文只有 OAPI batch 拿到的基本字段,有时不够准
涉及文件
context.js, index.js, uat-fetch.js(新增)
建议操作
patch-7f
feishu-social sender label + log source
干了啥
两个可观测性改进:① 名字查找时记录是从哪个来源拿到的,方便调试;② 群历史记录里的 sender 带上稳定的 open_id。
修了什么 Bug
调试时不知道名字从哪来的;群历史里没有 sender 的唯一标识
Bug 从哪来
原实现没考虑这些 debug 辅助信息
涉及文件
index.js, context.js, enrich.js
建议操作
模块8 · MailAgent/工具集成 1 patches
patch-8a
rem-review 工具 + MailAgent 按钮 handler + 卡片 ACK 即时回
干了啥
三件套:① 给 rr 加了 rem-review 工具(发邮件相关提醒的核心能力);② MailAgent 邮件卡片上的「完成」按钮点了之后真正有反应;③ 卡片按钮点击后立刻给飞书回一个「处理中」,不再超时报错。
修了什么 Bug
rem-review 工具缺失;「完成」按钮点了没反应;按钮 toast 报「回调超时」
Bug 从哪来
三件独立的缺失/bug:工具未实现、按钮无 handler、卡片 ACK 等 agent 跑完才回超过飞书 3s 限制
涉及文件
rem-review.js(新增), mailagent-btn-done.js(新增), event-handlers.js, interactive-dispatch.js, index.js
建议操作