TaiLaa的blog

消息解析#

AstrBot 的消息组件里有三个和合并转发相关的类型：

• Forward：只携带一个 id，是 QQ 合并转发的引用，需要调接口才能拿到内容
• Nodes / Node：直接包含转发节点（少数场景）

检测到 Forward 组件后，调用 OneBot 的 get_forward_msg API，把完整的转发内容拉回来，解析成 发送者：内容 格式的对话文本。

核心设计：暂存 + 抖动合并#

最直觉的做法是：收到合并转发 → 立刻生成摘要 → 存入群聊上下文。但这样有个问题：摘要会缺少群友的反应和讨论，语义是不完整的。

更合理的处理方式：

1. 收到合并转发时，把解析出的内容暂存（_forward_pending），同时触发群聊 debounce 计时器重置
2. 群友看完聊天记录，开始讨论——这些消息正常流入 group_log
3. 群里静默下来，debounce 到期触发 flush
4. flush 时检查 _forward_pending：如果有未超时的暂存，把「聊天记录内容」作为前缀，拼上「群友的讨论」，一起生成摘要

生成的摘要上下文格式是：

1
【xxx 分享的聊天记录】
2
A：blabla
3
B：blabla
4
...
5

6
【群友随后的讨论】
7
群友1：这也太...
8
群友2：确实

这样 LLM 摘要出来的内容是完整的，能真正反映「这个群在聊什么」。

超时丢弃#

如果有人发了聊天记录，但群里之后各聊各的，跟聊天记录内容无关——这种情况让暂存超时（默认 5 分钟）自然清理，不会产生垃圾摘要。

不记个人记忆#

早期版本还给发合并转发的用户生成了一条个人记忆（「分享了聊天记录」）。后来想想意义不大——这条信息含量太低，还会占用用户的记忆配额。去掉了，合并转发只走群聊摘要这条路。

一个小细节#

flush 里顺手做了全局 _forward_pending 的过期扫描，防止某个群的暂存因为一直没有后续消息触发 flush 而永久留在内存里泄漏。