从 DSH 接入 QQ 到长期记忆：数据库、遗忘曲线与大模型记忆持久化实践

当 AI 不再只是一个聊天窗口，而是开始通过 QQ 持续参与我们的生活与开发工作时，一个新的问题出现了：我们怎样才能让它真正记住过去，而不是每次新建会话都从零开始？

一、从 DSH 接入 QQ 说起：为什么 AI 还是会失忆？

最近，随着 DSH 相关生态和 QQ 机器人接入方案受到关注，越来越多的人开始尝试将大模型接入 QQ，让 AI 能够在私聊和群聊中提供服务。

与传统的网页聊天相比，QQ 机器人有一个很明显的优势：它能够出现在用户日常使用的交流环境中。

我们可以在 QQ 中让 AI 帮忙编写代码、分析日志、管理项目，甚至让它持续跟进一项长期任务。

但当使用时间变长，一个问题就会逐渐暴露出来。

第一天，我们告诉机器人：

我正在开发一个 Minecraft PE 服务器管理系统，后端使用 Python，前端使用 Vue 3。我希望你在修改代码之前先检查现有架构，不要直接重写整个项目。

AI 理解了我们的要求，也给出了不错的建议。

第二天，我们新开一个会话，继续询问：

上次服务器管理软件的备份模块，我们最后确定了什么方案？

AI 却开始询问项目使用什么技术栈、备份模块有什么需求，甚至给出与此前讨论相矛盾的建议。

从用户的角度来看，这就是失忆。

但从技术角度来看，这个问题并不一定出在大模型本身，而可能是应用程序没有建立一套完整的记忆管理机制。

1. 上下文不等于记忆

大模型在生成回答时，需要根据当前提供的上下文进行推理。

这些上下文可能包含：

  • 系统指令。

  • 当前用户消息。

  • 当前会话中的部分历史记录。

  • 应用程序主动提供的用户信息。

  • 从外部知识库中检索到的资料。

如果之前的重要信息没有被重新提供给模型，那么模型通常无法仅凭一次新的请求，可靠地恢复那些没有出现在当前上下文中的内容。

即使模型拥有很大的上下文窗口，也不意味着它会自动永久保存所有历史信息。

上下文窗口决定一次推理可以处理多少信息，持久化记忆决定过去的信息能否被保存、检索和重新使用。

这两个概念并不相同。

2. 保存聊天记录，也不等于拥有长期记忆

假设 QQ 机器人将所有聊天记录写入数据库。

那么，即使用户几个月后重新打开系统，只要数据仍然存在，程序就有可能读取过去的聊天记录。

但这不代表 AI 能够有效使用它们。

如果用户创建了一个全新的会话，而程序没有从旧记录中提取相关信息，那么这些聊天记录依然只是存档。

这意味着，一个完整的长期记忆系统至少需要解决四个问题：

  1. 如何从聊天中提取值得长期保留的信息？

  2. 如何将这些信息可靠地保存下来？

  3. 如何在未来的会话中找回相关信息？

  4. 如何判断找回的信息是否仍然有效？

前两个问题与数据存储密切相关，第三个问题属于信息检索，第四个问题则涉及记忆管理和知识更新。

而这正是 DSH + QQ 机器人值得进一步探索的方向。

二、DSH + QQ：消息接入只是第一步

以通过 QQ 机器人和 OneBot 等方式接入 DSH 的系统为例，消息处理流程可以简化为：

QQ 用户
   │
   ▼
QQ 机器人 / OneBot
   │
   ▼
DSH 消息接入插件
   │
   ▼
会话识别与路由
   │
   ▼
Agent 与大模型
   │
   ▼
生成回答
   │
   ▼
QQ 机器人
   │
   ▼
QQ 用户

这里需要明确：具体消息通道、插件名称和接口形式，应当以实际使用的 DSH 版本及其插件文档为准。

无论采用什么接入方式，消息能够成功送达大模型，都不代表长期记忆已经实现。

真正需要建立的是一条独立的记忆处理链路：

收到消息
   │
   ├──► 更新当前会话
   │
   ├──► 生成模型回答
   │
   └──► 分析是否存在值得保存的信息
                    │
                    ▼
               记忆候选
                    │
                    ▼
             去重、校验与分类
                    │
                    ▼
               持久化存储
                    │
                    ▼
               建立检索索引

当未来出现新会话时，系统再通过另一条链路找回记忆：

新会话中的用户问题
          │
          ▼
     分析问题主题
          │
          ▼
     检索相关记忆
          │
          ▼
     检查权限与有效性
          │
          ▼
     排序并控制数量
          │
          ▼
     注入模型上下文
          │
          ▼
       生成回答

这才构成了从信息产生到信息保存，再到信息重新利用的完整过程。

因此，本文讨论的重点不是如何把聊天记录存进文件，而是如何设计一个能够长期运行、可以恢复、可以纠错的大模型记忆系统。

三、数据库能不能让 AI 的记忆保存十年？

答案是可以，但必须理解数据库究竟解决了什么问题。

数据库能够帮助我们可靠地保存信息，却不能保证 AI 在十年后一定能正确理解这些信息。

例如，一条记录可以在数据库中保存十年，但它所描述的项目可能早在三年前就已经停止使用。

所以，我们必须区分两个概念：

数据持久性，是信息还在不在；记忆有效性，是这些信息现在还对不对。

1. SQLite：个人 AI 记忆系统的起点

对于个人部署的 DSH + QQ 机器人，我建议优先考虑 SQLite。

SQLite 是一种嵌入式关系型数据库，不需要单独部署数据库服务器，数据通常保存在本地数据库文件中。

它支持事务，能够通过明确的提交和回滚机制管理一组相关的数据操作。

相关文档：

假设你的机器人平均每天产生 100 条值得长期保存的记忆：

时间

记忆记录数量

一年

36,500 条

五年

182,500 条

十年

365,000 条

这个规模并不意味着 SQLite 一定无法胜任。

实际性能取决于单条记录的大小、索引设计、查询方式、并发访问情况和硬件条件，而不是简单地由记录总数决定。

因此，对于一个个人长期使用的 AI 助手，SQLite 往往已经足够作为第一阶段的存储基础。

不过，要想让记忆真正保存多年，还需要考虑以下问题。

数据库文件不能代替备份

如果硬盘损坏，数据库文件可能无法恢复。

如果用户误删文件，数据库也不会自动找回数据。

因此，系统需要定期备份，并且定期进行恢复测试。

对于 SQLite，可以使用适当的数据库备份机制，而不是在所有情况下都简单地复制正在写入的数据库主文件。

尤其是在启用 WAL 模式时，数据库状态可能涉及主数据库文件和 WAL 文件。使用 SQLite 提供的备份机制通常更稳妥。

事务不能代替所有可靠性措施

数据库事务能够保证相关操作的原子性，但数据在异常情况下的持久性还与同步设置、文件系统和硬件行为有关。

例如，SQLite 的 WAL 模式可以配合 synchronous=FULL，在每次事务提交时执行额外的同步操作，以增强对系统崩溃或突然断电的保护。

但任何存储方案都不应该仅凭一个配置参数就宣称绝对不会丢失数据。

数据库还需要升级机制

如果记忆系统准备长期运行，那么数据库结构不可能永远不变。

今天只有记忆内容和创建时间，未来可能还需要：

  • 记忆来源。

  • 记忆版本。

  • 作用域。

  • 置信度。

  • 复核时间。

  • 归档状态。

  • 删除状态。

因此，应该通过数据库迁移脚本逐步升级数据结构，而不是在程序升级时随意覆盖旧数据库。

如果希望记忆系统能够持续使用很多年，除了数据持久化，还必须保证数据可以被未来的软件版本继续读取。

2. PostgreSQL：什么时候值得升级？

当系统从个人使用扩展到多用户、多设备或者多服务器部署时，可以考虑 PostgreSQL。

例如：

  • 多个 QQ 机器人共享同一套记忆服务。

  • 用户通过网页查看和管理记忆。

  • 多个 Agent 需要访问经过授权的项目知识。

  • 系统需要更完善的集中式数据管理。

  • 并发读写需求逐渐增加。

PostgreSQL 支持事务、约束以及丰富的数据类型，可以为复杂系统提供更完善的数据库能力。

官方文档：

但这里有一个容易被忽略的问题：

更换数据库，不会自动提高记忆质量。

如果系统仍然把所有聊天总结无条件地保存下来，仍然无法判断新旧事实是否冲突，那么 PostgreSQL 也无法从根本上解决 AI 失忆或者记错的问题。

因此，我建议先使用 SQLite 完成记忆系统的整个闭环。

只有在真实需求出现时，再考虑 PostgreSQL。

3. 是否需要向量数据库？

不一定。

很多大模型记忆方案会引入向量数据库，但它解决的是语义检索问题，而不是基础持久化问题。

例如，记忆中保存的是：

用户希望修改现有项目时优先进行增量式改造。

用户之后却问：

为什么你总想推倒重做？

这两句话的文字差异很大，但语义高度相关。

向量检索可以帮助系统找到这条记忆。

然而，如果用户问：

项目最后确定使用什么数据库？

系统需要准确区分：

  • 最初计划使用 SQLite。

  • 后来讨论过 PostgreSQL。

  • 最终确认迁移到 PostgreSQL。

这时候，仅仅找到语义相似的记录是不够的，还需要检查时间、状态和决策版本。

因此，比较合理的技术路线是：

  1. 使用 SQLite 保存结构化记忆。

  2. 使用 SQL 和全文检索完成初步检索。

  3. 根据测试结果引入向量检索。

  4. 在需要时增加重排序模型。

  5. 通过版本和状态管理保证当前事实的正确性。

不要因为向量数据库很流行，就让它承担本来应该由关系数据库和业务逻辑解决的问题。

四、长期记忆应该如何设计数据结构？

如果只是将聊天摘要写入 MEMORY.md，系统很容易遇到重复信息、错误信息和新旧信息冲突的问题。

我更建议采用结构化记忆。

一条记忆不应该只有一段文字，还应该包含它的来源、作用范围、当前状态和时间信息。

例如：

{
  "id": "mem_0001",
  "owner_id": "user_001",
  "scope": "project",
  "scope_id": "minecraft-manager",
  "category": "technical_decision",
  "content": "项目当前使用 SQLite 保存本地数据",
  "importance": 0.9,
  "confidence": 0.95,
  "status": "active",
  "version": 1,
  "created_at": "2026-10-30T20:00:00+08:00",
  "updated_at": "2026-10-30T20:00:00+08:00",
  "last_verified_at": "2026-10-30T20:00:00+08:00"
}

这里的字段可以分成几组。

身份与作用范围

id 是记忆的唯一标识。

owner_id 表示这条记忆属于哪个用户。

scope 和 scope_id 用于区分个人、项目、会话和群聊等不同作用范围。

例如，一条项目记忆不应该自动被其他项目使用，一条私聊记忆也不应该自动对群聊开放。

内容与可信度

category 表示记忆的类型。

content 保存记忆内容。

importance 表示记忆的重要程度。

confidence 表示系统对该记忆内容的可信度评估。

需要注意，置信度不是事实正确率的保证。模型认为一条记忆很可信，并不代表它一定正确。

时间与版本

created_at 表示创建时间。

updated_at 表示最近一次更新时间。

last_verified_at 表示最近一次确认该信息的时间。

version 用于记录当前版本。

这些字段能帮助系统区分当前有效信息和历史信息。

为什么需要记忆来源？

假设机器人保存了这样一条信息：

项目计划使用 PostgreSQL。

过了一段时间，机器人开始把这条信息当成已经完成的技术迁移。

这就是典型的记忆错误。

如果系统能够追踪原始消息，就可以发现这句话来自一次讨论，而不是最终决策。

因此，建议额外保存记忆来源，例如：

  • 来源会话 ID。

  • 来源消息 ID。

  • 提取时间。

  • 提取方式。

  • 是否经过用户确认。

这样，系统就能够在必要时追溯记忆的依据。

五、遗忘曲线：它真的适用于大模型记忆吗？

接下来讨论一个更有意思的问题。

心理学中的遗忘曲线，通常描述学习后信息保持情况随时间发生的变化。

但如果直接把这个概念套用到大模型记忆系统中，很容易产生误解。

人类可能会逐渐忘记信息，但数据库中的一条记录不会因为很久没有被读取，就自动变得不可靠。

因此，我们不能简单地规定：

每过一天，记忆的重要性下降 10%。

也不能因为某条记忆三个月没有被使用，就直接把它删除。

因为不同类型的信息，其有效性变化速度完全不同。

例如：

记忆内容

是否应该随时间自动衰减

用户长期偏好

通常不应该明显衰减

项目当前技术栈

应结合项目变化判断

临时任务状态

应根据任务进度和截止时间处理

历史技术决策

应保留历史，另行标记当前有效性

一次性的临时信息

可以设置较短的保留期限

这说明，遗忘曲线不能直接决定所有记忆的生死。

但它仍然有值得借鉴的地方。

1. 从遗忘曲线转向记忆维护

我认为，遗忘曲线对大模型长期记忆最大的启发，不是让数据库自动删除信息，而是帮助我们思考：

  • 哪些信息应该经常被检索？

  • 哪些信息需要定期重新确认？

  • 哪些信息可能随着时间而过时？

  • 哪些信息虽然暂时没有使用，但仍然值得保留？

这与人类记忆研究并不完全相同。

在人类学习中，间隔重复和主动提取练习有助于长期保持知识。

相关研究可以参考：

但在 AI 系统中，我们没有必要为了保持一条数据库记录的存在，而反复让模型重新学习它。

更实用的方式是将这类研究转化为记忆检索和复核策略。

例如，当系统发现项目数据库的记忆很久没有确认，而且最近出现了配置变更，就应该重新检查这条记忆。

如果系统发现用户的回答风格偏好长期稳定，那么即使它最近没有被调用，也没有必要要求用户重新确认。

2. 为不同记忆设计不同的衰减策略

可以为每条记忆配置不同的时间衰减参数。

例如，使用以下形式计算时间相关性：

F(m)=e^{-\lambda_m\Delta t}

其中：

  • F(m) 表示记忆的新鲜度评分。

  • \Delta t 表示距离上次确认经过的时间。

  • \lambda_m表示根据记忆类型配置的衰减参数。

如果某类记忆不适合进行时间衰减，就可以让它的衰减参数为零。

但这个公式只是一个工程上的启发式，并不是人类遗忘曲线的直接复刻，也不是经过验证的通用最优公式。

它只能帮助系统调整优先级，不能单独证明某条信息已经过时。

3. 记忆重要性不等于记忆新鲜度

假设系统保存了两条记忆：

A：

用户长期偏好简洁、清晰的技术回答。

B：

用户今天正在排查一次构建失败。

A 可能已经保存一年，但仍然非常重要。

B 可能只保存了十分钟，却对当前任务至关重要。

因此，记忆系统至少需要区分三个维度：

  • 重要性：这条信息长期有多大价值？

  • 新鲜度：这条信息是否可能已经过时？

  • 相关性：这条信息与当前问题有多大关系？

这三个维度应该分别计算，而不是压缩成一个简单的时间衰减公式。

六、一个更实用的方案：让记忆具有生命周期

相比让所有记忆统一衰减，我更推荐为记忆设计明确的生命周期。

例如：

          提取记忆
              │
              ▼
          候选记忆
              │
              ▼
       去重、校验与分类
              │
              ▼
          有效记忆
              │
       ┌──────┴──────┐
       │             │
       ▼             ▼
   持续有效       需要复核
       │             │
       │       ┌─────┴─────┐
       │       │           │
       │       ▼           ▼
       │    确认有效     确认过时
       │       │           │
       └───────┘           ▼
                       历史归档
                           │
                           ▼
                      必要时检索

这个机制有几个优点。

第一，它不会因为记忆很久没有被访问，就自动删除重要信息。

第二，它允许系统主动发现过期的项目状态。

第三，它可以保留历史决策，避免未来再次讨论时失去背景。

第四，它为用户提供了纠正错误记忆的机会。

哪些信息适合自动过期？

例如：

今天正在排查的问题。

如果任务已经完成，那么系统可以把它标记为已完成。

又例如：

明天下午需要检查服务器。

在任务完成或者超过有效期后，系统可以重新评估这条记忆。

但对于：

项目曾经使用 SQLite。

即使项目已经迁移到 PostgreSQL，这条历史记录也未必需要删除。

更好的方式是将它标记为历史事实，而不是当前状态。

真正合理的遗忘机制，不是让所有信息逐渐消失，而是让过时信息不再自动影响当前回答，同时保留必要的历史背景。

七、如何让系统判断记忆是否应该更新？

这是整个记忆系统最重要的部分之一。

假设机器人过去保存了：

项目当前使用 SQLite。

后来，用户在 QQ 中说：

我们已经完成数据库迁移，现在改成 PostgreSQL 了。

如果系统只会追加记忆，就可能同时保存两条相互冲突的信息。

此后，用户每次询问项目使用什么数据库，模型都可能选错。

因此，记忆系统应该具有更新机制。

1. 先判断新信息的性质

系统需要区分：

  • 新增事实。

  • 对旧事实的补充。

  • 对旧事实的纠正。

  • 尚未确定的计划。

  • 已经完成的决策。

例如：

我们可以考虑迁移到 PostgreSQL。

这只是一个建议。

而：

数据库已经迁移完成，现在使用 PostgreSQL。

则表达了明确的状态变化。

系统不应该把这两句话处理成完全相同的记忆更新。

2. 查找可能冲突的旧记忆

新信息进入系统后，可以先检索同一项目、同一类别的现有记忆。

如果发现存在潜在冲突，就进入进一步判断。

例如：

旧记忆：
项目当前使用 SQLite。

新消息：
项目已经迁移到 PostgreSQL。

系统判断：
同一项目、同一事实类别，存在状态变化。

处理结果：
将 PostgreSQL 标记为当前有效状态。
将 SQLite 保留为历史状态。
记录来源与更新时间。

对于语义不明确的信息，可以暂时保存为待确认内容，而不是直接覆盖旧记录。

3. 保留来源与历史版本

当系统更新一条重要记忆时，应当记录：

  • 原始内容。

  • 新内容。

  • 修改原因。

  • 来源消息。

  • 更新时间。

  • 是否经过确认。

这样，用户就能够查看记忆为什么发生变化。

这不仅能减少错误，也方便开发者排查模型为什么得出了某个结论。

八、从数据库到记忆检索：如何让新会话找到正确的信息？

假设用户在 QQ 中问：

上次我们讨论的服务器管理软件，为什么要采用两阶段备份？

系统不能把所有历史聊天记录都发送给大模型。

正确的方式是先根据问题检索相关记忆。

可以将整个过程分成三个阶段。

第一阶段：结构化过滤

首先，根据当前用户的权限和项目标识，确定可以访问哪些记忆。

例如：

用户：user_001
项目：minecraft-manager
类别：technical_decision
状态：active 或 archived

这样可以先缩小检索范围。

第二阶段：相关性检索

接下来，可以使用关键词检索和向量检索寻找相关记录。

关键词检索适合明确的项目名称、技术术语和版本号。

向量检索适合表达方式不同但含义相近的问题。

例如，记忆中写的是：

本地备份完成后，再将备份文件复制到远程存储。

用户却问：

为什么不能一开始就把数据传到另一台机器？

系统仍然有机会找到这条记忆。

第三阶段：状态检查与排序

检索到记忆之后，还需要判断它是否适用于当前问题。

可以先使用一个简单的评分模型：

S(m,q)= w_rR(m,q)+ w_iI(m)+ w_cC(m)+ w_fF(m)

其中：

  • R(m,q)：记忆 m 与当前问题 q 的相关性。

  • I(m)：记忆 m 的重要性。

  • C(m)：记忆 m 的可信度。

  • F(m)：记忆 m 的新鲜度或当前有效性。

  • w_r,w_i,w_c,w_f：分别对应相关性、重要性、可信度和新鲜度的可配置权重。

这只是一个初始排序框架。

实际使用时，还应该对当前状态、来源可信度、记忆类别和权限设置硬性约束，避免一条相关性很高但已经过时的记忆排到最前面。

最后，系统只选择有限数量的记忆，注入模型上下文。

这样既能减少无关信息，也能降低过时内容对回答的干扰。

九、一个可以直接开始开发的项目方案

如果目标是将这些思路真正用到 DSH + QQ 机器人中，我建议先做一个独立的记忆服务，而不是直接重写现有的 DSH 会话系统。

整个项目可以采用以下架构：

                 QQ 用户
                    │
                    ▼
              QQ / OneBot
                    │
                    ▼
                DSH Agent
                    │
          ┌─────────┴─────────┐
          ▼                   ▼
       会话管理            记忆服务
          │                   │
          ▼                   ├── 记忆提取
       聊天历史               ├── 去重与更新
                              ├── 权限检查
                              ├── 记忆检索
                              ├── 生命周期管理
                              └── 版本管理
                                      │
                                      ▼
                               SQLite 数据库
                                      │
                                      ▼
                                备份与恢复

记忆服务可以独立实现，并通过 DSH 实际支持的插件接口或工具调用方式接入。

这样做的优势是，未来即使更换 QQ 接入插件或大模型，也不需要重新设计整个记忆数据库。

第一步：建立数据库

首先创建以下几张表：

表名

用途

conversations

会话基本信息

messages

聊天历史

memories

当前有效及待处理的记忆

memory_versions

记忆历史版本

memory_events

记忆更新、归档等事件

其中，memories 保存当前状态，memory_versions 保存历史版本，memory_events 用于记录操作过程。

这三类数据的作用不同，不应该全部塞进一个不断追加的文本文件。

第二步：实现记忆提取

每当一段对话结束，或者某个任务产生重要结论时，系统可以触发记忆提取。

例如：

用户消息
   │
   ▼
判断是否存在值得长期保留的信息
   │
   ▼
生成结构化记忆候选
   │
   ▼
检查内容、类别和作用范围
   │
   ▼
查找重复或冲突记录
   │
   ▼
保存、更新或等待确认

注意，不需要把每条消息都交给大模型进行一次额外的记忆提取。

可以先通过简单规则筛选候选信息，再在适当的时机进行批量整理，从而控制调用成本。

第三步：实现跨会话检索

在生成回答之前，系统先判断当前问题是否需要长期记忆。

例如，用户询问：

你好。

通常不需要检索项目记忆。

但用户询问：

我们之前确定的服务器备份策略是什么？

就应该检索与服务器备份相关的历史决策。

这种按需检索的方式，可以避免每次回答都加载大量历史数据。

第四步：实现版本管理

当新信息与旧信息冲突时，不要简单地覆盖原有内容。

应该保留历史版本，并明确当前有效状态。

例如：

记忆版本 1：
项目数据库使用 SQLite。
状态：历史。

记忆版本 2：
项目已迁移到 PostgreSQL。
状态：当前有效。

以后用户询问当前数据库时，系统优先使用版本 2。

如果用户询问过去的迁移过程，则可以根据问题检索版本 1 和版本 2。

第五步：实现遗忘曲线启发式

最后再引入记忆优先级和复核机制。

例如：

  • 长期偏好：默认长期有效。

  • 项目状态：根据时间和变更情况复核。

  • 临时任务：根据任务状态自动归档。

  • 历史决策：保留版本，不自动删除。

  • 低可信度记忆：在影响回答前重新核实。

这样，遗忘曲线就不再是一个简单的删除公式，而是整个记忆维护系统中的一个辅助策略。

十、如何证明这套记忆系统真正有效？

很多 AI 系统会在界面上显示：

记忆已保存。

但这并不一定代表数据已经成功写入数据库，更不代表下一次新会话能够找回它。

因此，开发时应该设计完整的验证流程。

测试一：跨会话恢复

  1. 在 QQ 中告诉机器人一条测试信息。

  2. 确认记忆已经写入数据库。

  3. 创建一个独立的新会话。

  4. 提出与该信息相关的问题。

  5. 检查系统是否检索到了正确的记忆。

测试二：服务重启

  1. 创建测试记忆。

  2. 正常停止服务。

  3. 重新启动服务。

  4. 再次查询记忆。

如果数据消失，就需要检查数据库路径、提交过程和初始化逻辑。

测试三：新旧信息冲突

先保存：

项目使用 SQLite。

随后明确更新：

项目已经迁移到 PostgreSQL。

再询问当前使用的数据库。

系统应该返回当前有效状态，而不是随机选择其中一条。

测试四：遗忘曲线对比

准备一组包含用户偏好、项目事实、临时任务和历史决策的测试记忆。

比较三种策略：

方案

记忆管理方式

A

仅按相关性检索

B

相关性、重要性与可信度综合排序

C

在 B 的基础上加入时间衰减和复核机制

然后观察：

  • 正确记忆的检索率。

  • 过期事实的使用率。

  • 重要记忆的遗漏率。

  • 平均上下文消耗。

  • 用户被要求重新确认的次数。

如果方案 C 让重要信息更容易被遗漏，或者频繁打扰用户，就需要调整参数，甚至取消不适合的衰减规则。

不能因为使用了遗忘曲线，就默认系统一定会变得更聪明。必须通过实验来验证。

十一、最终建议：先解决记得住，再解决记得好

如果让我为这个项目确定一条实际的开发路线，我会分成四个阶段。

第一阶段：持久化。

使用 SQLite 保存聊天历史和结构化记忆，实现事务、备份与恢复。

目标是确保服务重启后，记忆仍然存在。

第二阶段：跨会话检索。

实现记忆提取、去重、作用域过滤和上下文注入。

目标是让新会话能够找到过去的重要信息。

第三阶段：记忆生命周期。

增加版本管理、冲突检测、归档、复核和删除机制。

目标是避免过时信息不断干扰当前回答。

第四阶段：记忆算法优化。

根据实际测试，引入语义检索、重排序和遗忘曲线启发式。

目标是提高检索质量，同时控制上下文成本。

这条路线的关键，是先把基础机制做正确，再逐步增加复杂度。

如果一开始就引入向量数据库、多个 Agent 和复杂的记忆评分模型，反而容易让问题变得难以定位。

结语：真正的长期记忆，不是永远不忘，而是知道什么时候该记住、什么时候该更新

从 DSH 接入 QQ 的实践出发，我们会发现，大模型应用真正缺少的，并不只是更大的上下文窗口。

当 AI 开始参与长期项目、持续交流和自动化任务时，它需要能够保存信息、恢复状态、追溯来源、更新事实，并在适当的时候重新检查自己的判断。

数据库让信息能够可靠地保存。

记忆检索让信息能够在未来被找回。

版本管理让系统能够区分当前事实和历史决策。

而遗忘曲线的思想，则可以帮助我们思考哪些信息应该优先使用、哪些信息需要重新确认，以及怎样减少过期信息对回答的干扰。

不过，真正可靠的系统不应该因为一条记忆很久没有被使用，就自动删除它；也不应该因为一条记忆经常被调用，就认定它一定正确。

长期记忆的目标不是保存一切，而是让有价值的信息在未来仍然能够被正确地使用。

对于正在探索 DSH + QQ 机器人开发的人来说，我认为最值得实践的方向，就是先建立一套基于 SQLite 的结构化记忆服务，再逐步加入跨会话检索、记忆版本管理和时间衰减策略。

先让 AI 真正记得住、找得到、分得清，再尝试让它学会管理自己的记忆。

这才是从一个能够聊天的机器人，走向一个能够长期协作的智能助手的重要一步。