feat(im): 消息读取带上服务端发送者名称（with_sender_name=true） - #480
Merged
Conversation
消息 list/get 全部读路径带上 with_sender_name=true，服务端直接返回 sender_name（user 和 bot 都给），parseApiMessage 透出为 senderName： - botmux history / quoted 输出发送者名字，多 bot 群里 agent 不用再猜 哪条消息是谁发的；第三方 bot（不在 bots.json / 观察名册里）也有名字 - 合并转发展开的 <participants> 带 name 属性（渲染器本就支持，之前 没有数据源） - dashboard 会话历史：本地花名册/contact 解析不到时兜底用服务端名字； 本地解析到的名字优先级不变 影响面：仅 API 读消息路径（history/quoted/合并转发/dashboard 历史）。 实时事件路径（receive_v1）不带 sender_name，不受影响；daemon 现有的 contact/花名册解析逻辑保持原样，服务端名字只作补充兜底。
deepcoldy
added a commit
that referenced
this pull request
Jul 26, 2026
PR #480 只给「API 读消息路径」(history/quoted/合并转发/dashboard 历史) 加了 with_sender_name=true，但实时事件路径 receive_v1 注入进 CLI prompt 的 <sender type=... open_id=... /> 完全没受影响——那条路径的名字只靠 identity-cache 的 contact.v3.user.get 现补，contact 缺权限/可见范围/超时 或发送方是 bot 时就降级成没有 name 属性（用户实测反馈的正是这个）。 本 PR 在 resolveSender 增加最后一层兜底：cache/hint、contact API 都没拿到 名字、且调用方带了 messageId 时，用 getMessageDetail(with_sender_name=true) 反查一次 sender_name。它同时覆盖 user 和 bot，且不依赖 contact scope （服务端直接返回这条消息发送方的显示名），解析到的名字写回 identity 缓存， 后续同发送方的消息命中缓存不再重复请求。 - src/im/lark/identity-cache.ts：新增 resolveNameViaMessage（复用 #480 已 带 with_sender_name 的 getMessageDetail，套同一 RESOLVE_BUDGET_MS 预算， 失败静默降级 undefined）；resolveSender 的 hint 增加可选 messageId，仅在 前两步无名时触发；IdentityRecord.source 增加 'message_api' - src/daemon.ts：4 个 <sender> 注入点（p2p 冷启动/命令、新话题、话题回复） 把入站 messageId 透给 resolveSender；订阅/定时等无入站消息的调用点不传， 行为不变 影响面：仅 Lark 实时事件的 <sender> 名字解析链路。名字优先级不变（hint > cache > contact > message.get 兜底），纯增量：不带 messageId 时行为与之前 完全一致。跨 CLI/跨后端无涉。 测试： - 新增 test/identity-cache-message-fallback.test.ts，7 例全绿（bot 兜底、 user contact miss 后兜底、缓存命中不再请求、无 messageId 不请求、hint 已 有名字不请求、无 sender_name/抛错静默降级） - 回归 message-parser/merge-forward/dashboard-history-senders 共 86 例全绿 - pnpm build：改动文件 tsc 无报错（src/desktop 的 electron 报错在干净 master 上同样存在，与本 PR 无关） Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
改了什么
lark-cli v1.0.69 的 #1829 揭示了一个服务端 API 能力：消息 list/get 带
with_sender_name=true时，服务端直接返回发送者显示名（user 和 bot 都给）。本 PR 让 botmux 的 API 读消息路径全部用上：src/im/lark/client.ts：5 个消息读取调用点（listByThread/listChatMessages/listChatMessagesUntil/listByChatFilter/getMessageDetail）统一带上with_sender_name=truesrc/im/lark/message-parser.ts：parseApiMessage读取sender.sender_name，透出为可选字段senderName（空白视为无）src/types.ts：LarkMessage增加可选senderNamesrc/im/lark/merge-forward.ts：合并转发展开时把sender_name填进ForwardedNode.senderName—— 渲染器的<p name=…>支持早就存在，之前一直没有数据源dashboard-ipc-server.ts+history-senders.ts）：服务端名字随消息透传，本地花名册 / contact 解析不到时兜底用它；本地解析到的名字优先级不变（...message展开在前，本地名仅在存在时覆盖）为什么
之前
botmux history/quoted/ 合并转发展开的输出里发送者只有 open_id + sender_type：现在服务端一把给全，第三方 bot 也有名字，还省 contact 往返。
影响面
仅 API 读消息路径（history / quoted / 合并转发展开 / dashboard 会话历史）。实时事件路径（
receive_v1）不带sender_name，不受影响；daemon 现有 contact / 花名册解析逻辑原样保留，服务端名字只作补充。senderName为可选字段，纯增量，旧消费方无感。跨 CLI / 跨后端无涉——改动都在 Lark API 读链路和纯函数渲染层。
测试验证
pnpm build✅parseApiMessage透出 sender_name / 空白时省略（message-parser.test.ts）npx vitest run定向 4 个受影响文件：94/94 通过pnpm test：8261 passed / 5 failed——失败的 5 个（scheduler 时区 ×3、dashboard popover、restore limit session）在干净 master 上同样失败，与本 PR 无关（已用git stash对照验证）node dist/cli.js history --limit 4打真实 Lark API——bot 消息（sender id 为cli_a9f66d03be385ceb，本地花名册无法匹配的形态）返回"senderName": "Premium(Claude)"，用户消息返回"senderName": "申晗"，未调用 contact API