[Bug] Queued PDF loses original media payload when merged with a text follow-up

快速结论：这个报错通常出现在 LobeChat 自托管、使用 Redis 队列并发且通过微信机器人收发消息的场景：PDF 消息在 agent 回合进行中被排队，随后跟一条文字指令，两者被合并后 PDF 附件在提取阶段丢失。优先排查合并逻辑是否只保留了最新消息的 raw，导致早期 PDF 的下载描述符无法被提取器读取。

适用环境：Issue 已确认的场景为 LobeChat 自托管 canary.11、微信机器人、Redis 队列并发。Issue 未提供操作系统、Python、CUDA、显卡或依赖版本信息，本文不补充。

最快修复方案：升级到已包含上游修复 #19405 的发布版本 v2.2.18 或更高版本。该版本在合并消息时保留原始消息 payload（mergeBotMessages/getSourceMessages），并在 AgentBridgeService.resolveFiles 中从每个源消息提取附件和下载警告。

注意事项：Issue 中自托管微信部署方表示，对升级后版本的验收仍在进行中（acceptance … is still pending），因此升级后需自行验证附件是否完整可下载。另外，队列过期问题 #19253 与本 Issue 无关，不在本次修复范围内。

问题场景

在使用 LobeChat 自托管并接入微信机器人、开启 Redis 队列并发时，如果当前 agent 回合仍在执行某个工具任务（handler 保持活跃），用户先发送一个 PDF，再发送一条“读取它”之类的文字指令，队列中的两条消息会被一起 drain 并合并。此时合并后的新用户消息没有关联任何文件，模型只能找到历史同名文档，从而掩盖了当前附件缺失的问题。

报错原文

merged=2, mergedAttachments=1

随后日志显示仅提取了最新一条文字消息，且：

files=0

原因分析

根据 Issue 描述，BotMessageRouter.mergeSkippedMessages 在合并文本和附件时，只保留了最新消息的 raw。而微信提取器在提取时需要通过 raw.item_list 重新下载媒体，因为 Redis 序列化会丢失附件 buffer。这样，较早那条 PDF 消息的下载描述符在提取阶段已经不可用。其他平台的提取器同样依赖原始消息 payload，因此都可能出现同类问题。

可能原因：合并阶段未保留全部原始排队消息的 payload，导致提取器只能从最新消息解析附件。

需要区分的是，本问题与 #19253 不同：在本 Issue 的复现中，消息在队列中存活下来了，媒体是在合并之后的提取阶段丢失的。

环境排查

确认 LobeChat 版本：是否为 canary.11 或低于 v2.2.18 的版本。
确认部署方式：自托管部署，且启用了 Redis 队列并发。
确认接入渠道：微信机器人。
确认复现路径：在 agent 回合进行中先发 PDF、再发文字指令，让队列消息一起 drain。
查看日志中是否出现 merged=2, mergedAttachments=1 以及后续 files=0。
Issue 未提供 Python、CUDA、PyTorch、显卡或依赖版本，无需据本文补测这些项。

解决步骤

记录当前版本与复现日志，确认现象与 merged=2, mergedAttachments=1 后 files=0 一致。
升级到包含上游修复 #19405 的 v2.2.18 或更高版本。
升级后，合并逻辑会通过 mergeBotMessages/getSourceMessages 保留原始消息 payload；AgentBridgeService.resolveFiles 会从每个源消息中提取附件和警告。
该修复同时保留了 deferred replay 过程中的来源信息，并包含回归测试覆盖。
如你此前提交了对应补丁 PR #19369，注意它已被关闭（superseded），应改用上游实现，不要继续维护旧补丁。

验证方法

在相同的微信机器人 + Redis 队列并发环境下重复复现步骤：先发 PDF，再发文字指令，让队列消息一起 drain。确认新用户消息关联到新的 PDF 记录，且该附件可完整下载、字节数与 SHA-256 校验一致，agent 能够读取其页数和标题。Issue 中的最小补丁复现验证显示全部 44,403,719 字节可检索且 SHA-256 匹配。