Repository navigation
[Bug] lastDistilledSeq 为进程内存态：宿主重启后蒸馏窗口从头重放，已蒸馏历史被重复处理 #229
Description
问题
collectMessages 的增量游标 lastDistilledSeq 只存在于进程内存（#226 引入的按事件序增量蒸馏依赖它）。宿主重启后游标归零，蒸馏管线把已经蒸馏过的历史窗口整段重放。
后果：
- 重启后的第一次 autoSummarize 会把旧事件再蒸馏一遍——重复消耗 LLM 预算；
- 依赖 saveWithDedupe 兜底去重（type+title+scope 三元组），但摘要措辞稍有漂移就产生近重复条目，正好落进 autoSummarize 每个
turn/end都触发且无产出上限——建议新增节流、条数上限与同会话主题抑制（实测单会话日铸 198 条） #127 讨论的「去重门与矛盾检测次序」雷区。
期望
游标随库持久化，重启后从上次推进位置继续。
实现约束
- schema 变更：新表或 meta 表新键，配幂等迁移（PRAGMA 检查 + ALTER，存量库启动即建）——防御段，改动保守；
- 游标语义要定义清楚：按 session 还是全局、窗口部分蒸馏完成时（混合数组只存了有效条目）游标推进到哪；
- 与 [Bug] 蒸馏从不采集工具结果与子会话交付：tool/result 与 tool/code-dispatch 读了不存在的 data.output，且 switch 未覆盖 agent/inbox/spliced #211 的数组边界修复有交互（全无效数组不推进游标），建议 [Bug] 蒸馏从不采集工具结果与子会话交付：tool/result 与 tool/code-dispatch 读了不存在的 data.output，且 switch 未覆盖 agent/inbox/spliced #211 合入后再动本 issue。
认领
@z2Ace0107 在 #211 评论里已表达意向，届时优先由你接。
Activity
z2Ace0107 commentedon Sep 19, 2026
感谢在 #229 中优先邀请我继续负责。我确认认领这个 Issue，并计划单独提交一个 PR，只处理
lastDistilledSeq的持久化，不混入其他 Issue 的改动。初步设计如下：
distill_cursors表，以session_id为主键，保存last_seq和更新时间，不复用user_settings；seq增量蒸馏的语义，读取seq > last_seq的事件，宿主重启后从持久化游标继续；src/与lib/。开始实现前想请确认三个边界：
session.id持久化？seq保存为last_seq？modusensus commentedon Sep 19, 2026
@z2Ace0107 三个边界都确认：
按
session.id持久化——是。现状内存游标lastDistilledSeq（src/summarize.js的Map）就是以session.id为键，持久化沿用同一键才能跨重启续上既有会话；新增distill_cursors表（session_id主键）比复用user_settings干净，同意。存量会话接受一次性补蒸——同意你的倾向，正确性优先。去重有双重兜底：三元组精确键（type+title+scope）拦完全同键的，
summarizeDedupeMinSim的向量近重档拦「同源内容二次蒸馏」的近似产出，残余漏网属可接受成本。首次启动那批补蒸会照实写进llm_audit_logs，量大会显眼——可见即可排查，不需要专门静音。同一事务 + 记窗口末尾
seq——同意，这正是 [Bug] 蒸馏取样方向反了：maxChars 上限用 slice(0, n) 取【会话开头】，长会话/复制来的会话会每轮反复提炼同一段 #210 定下的「完整成功才推进」语义的持久化版。一个实现提醒：事务保持短——蒸馏 / LLM 调用留在事务外，「写记忆 + 推游标」在同一短事务里提交；store 的 WAL +busy_timeout已为多进程就绪，别在事务里做慢调用即可。边界确认完毕，可以开工。
fix(summarize): persist distillation cursor (#229) (#274)
chore(release): v0.8.6 发布说明与路线图补齐
release: v0.8.6 发布准备 (#282)