feat: 添加长期记忆整理功能

[Rvosy]

目前长期记忆可能会因为多次总结或重复写入，产生语义相同或高度相似的记忆。

希望增加一个长期记忆整理功能，用于：

• 删除完全重复的记忆
• 合并语义相似的记忆
• 简化过长或表达不清的记忆
• 检查可能冲突或过期的记忆
• 在写入新记忆前检查是否已有相似记忆

初期可以先生成整理建议，由用户确认后再执行修改，避免误删重要记忆。

[Nothing1596]

我看到桌宠目前无法感知到用户打开桌宠和隐藏桌宠的操作，这会导致用户体验的缺失。我查看了源码发现上下文是无缝衔接上次关闭的历史上下文。我决定借助检测舞台事件的方式实现该功能。由于涉及到桌宠设计，希望佬同意后我再提交，我会提交一个pr draft。

[Nothing1596]

另：之前似乎看到了temperature等超参数会影响表现的问题，我想对用户开放高级选项，直接调整超参数是不是可以多一些样本和问题的排查，也给用户更多的选择，我会提交另一个draft，up来决定一下

[Nothing1596]

以下内容由我使用codex探索完成：总体架构是硬编码检索+llm裁判

主流实现

1. Mem0

   • 写入时让 LLM 抽取长期事实，并结合已有记忆做重复/冲突处理。
   • infer=True 适合自动整理聊天历史；infer=False 更像原文直写，容易绕过去重和冲突处理。
   • 参考：https://docs.mem0.ai/core-concepts/memory-operations/add

2. LangGraph / DeepAgents

   • 区分 semantic / episodic / procedural memory。
   • 推荐把记忆整理放到后台 consolidation agent 中，而不是让主聊天链路承担全部整理工作。
   • 参考：https://docs.langchain.com/oss/python/concepts/memory

3. Zep / Graphiti

   • 保留原始 episode 作为证据来源，再从中抽取 facts。
   • facts 带时间有效性，例如 valid_at / invalid_at，冲突时不一定删除旧事实，而是标记过期。
   • 参考：https://help.getzep.com/facts 和 https://help.getzep.com/v3/episodes

4. Letta / MemGPT

   • 使用记忆分层：核心记忆常驻上下文，归档记忆按需检索。
   • Agent 可以自我编辑记忆，但重要编辑仍应可观察、可回滚。
   • 参考：https://docs.letta.com/guides/core-concepts/memory/archival-memory

分析

这个问题不太适合只用 RAG 或 embedding 解决。embedding 能找到语义接近内容，但对“同主题但不等价”“轻微冲突”“时间过期”“否定关系”并不稳定。反过来，如果完全交给 LLM 判断，又容易误删或过度合并。

比较稳的方式是：硬编码算法负责召回候选，subagent 负责裁判和生成整理建议。也就是硬编码层只回答“哪些记忆可疑”，不要直接决定“该删哪条”。

可以把长期记忆分成两层看：

• episodic evidence：原始聊天片段或来源记录，尽量保留，用于追溯。
• semantic memory：当前真正注入/检索的长期事实，需要简洁、去重、可更新。

这样即使语义记忆被合并或标记过期，仍然能追溯来源，降低误删风险。

建议实现

建议新增一个 MemoryOrganizer / MemoryReviewService：

1. 候选召回

   • normalized hash：检测完全重复。
   • char n-gram / shingle Jaccard：检测轻微改写重复，中文尤其有效。
   • SimHash / MinHash：用于批量 near-duplicate 扫描。
   • BM25 / TF-IDF：补充专有名词、路径、日期、人名等词面相似。
   • embedding similarity：检测语义相似。
   • entity/relation key：检测同一主体、关系、对象的重复或冲突。
   • time/status rules：检测过期、完成、取消、偏好变化。
   • negation rules：检测“喜欢/不喜欢”“使用/不再使用”等潜在冲突。

2. subagent 裁判
   对召回的小候选集合输出结构化建议：

   {
     "action": "merge | delete_duplicate | rewrite | expire | keep | ask_user",
     "memory_ids": ["..."],
     "confidence": 0.87,
     "reason": "...",
     "proposed_content": "...",
     "risk": "low | medium | high"
   }

写入前检查
新增记忆前先调用 review_new_memory(content)：

完全重复：提示已有记忆，不写入。
高相似：建议更新/合并。
潜在冲突：要求用户确认。
无相似：正常写入。
批量整理
在设置页增加“生成整理建议”按钮：

先只生成建议，不自动执行。
用户勾选后再应用 update/delete/expire。
所有操作写入审计日志，方便回滚。
保守策略

完全重复可以强建议删除副本。
语义相似只建议 merge/update，不自动删。
冲突优先标记旧记忆过期，而不是直接删除。
过长记忆只做 rewrite 建议，保留原来源。
总体建议：第一版不要追求全自动。先实现“写入前查重 + 手动生成整理建议 + 用户确认执行”，这样最符合长期记忆的安全性和可控性。

[Rvosy]

我看到桌宠目前无法感知到用户打开桌宠和隐藏桌宠的操作，这会导致用户体验的缺失。我查看了源码发现上下文是无缝衔接上次关闭的历史上下文。我决定借助检测舞台事件的方式实现该功能。由于涉及到桌宠设计，希望佬同意后我再提交，我会提交一个 pr draft。

是的，这个方向是对的，我这两天刚好也在考虑这个问题。

不过我这边想要设计的是一个完整的 系统事件感知框架，不只是针对：

隐藏到托盘 → 重新显示 → 下一次用户发消息时注入 reopen context

这种单一场景做专项处理。

我想要的是后续能统一接入更多桌宠事件，例如：

• 用户启动桌宠
• 用户隐藏桌宠
• 用户重新显示桌宠
• 用户关闭桌宠
• 用户点击桌宠
• 用户拖动桌宠
• 用户中断 Sakura 回复
• 事件日志统一结构化记录
• 事件上下文与普通聊天历史分离
• 后续与情绪 / 好感 / 精力状态机联动

这部分会影响 Sakura 的上下文注入方式、历史记录设计和后续桌宠人格连续性，所以我倾向于由主仓统一设计一套 Runtime Event System，而不是先合入单独的 reopen context 实现。

相关设计我会在 #40 中继续跟进。