先补排序#

一个聊天机器人最早的记忆系统通常并不复杂：

1
聊天记录 -> JSONL
2
显式记忆 -> memories.jsonl
3
群体画像 -> Markdown
4
定期总结 -> 候选记忆

这套东西的优点很明显：本地文件可读、可备份、可人工检查，也不需要额外服务。出问题时打开文件就能知道机器人到底记了什么。

但它的短板也很明显。

全文子串匹配能找到“原话”，却很难处理近义表达；所有记忆权重一样，昨天确认的规则和一年前的闲聊被放在同一个池子里；显式记住的事实和临时总结出的候选，如果没有评分，也很难决定谁更可信。

所以第一步我不会急着换数据库，会先给记忆排序。

这里容易被忽略的是：大家常问怎么记得更多，但机器人更常出问题的地方，是旧话被不合时宜地翻出来。一个机器人如果每次都把旧话翻出来，并不会显得更聪明，只会显得没有分寸。

三个分数比一个黑盒更适合起步#

计划里最实用的一点，是把检索拆成三个可解释分数：

• recency：这条记忆有多新。
• importance：这条记忆本身有多重要。
• relevance：它和当前问题有多相关。

这套思路来自 Generative agents 一类工作的三因子检索，但落地时不一定非要立刻调用模型评分。对一个自用机器人来说，先用规则做一版反而更稳。

比如重要性可以按 kind 先粗分：规则最高，偏好次之，项目事实再次，普通备注最低。显式 /记住 的内容可以比自动候选更可信。带有规则、风格、项目这类标签的记忆也可以被抬高。

这样做不够“智能”，但足够可解释。

当机器人把一条记忆拿出来时，我能知道它为什么靠前：是因为刚发生，是因为属于规则，还是因为和当前问题有明确关键词或标签重合。这比一个无法解释的相似度分数更适合早期调试。

相关性不一定先靠向量库#

语义检索当然值得记，但它不是第一天就必须引入的基础设施。

在资源有限、部署路径又已经比较复杂的机器人项目里，多维度规则相关性可以先顶住一段时间：

• 精确文本匹配。
• 中文字符或词片段匹配。
• 标签匹配。
• 记忆类型匹配。
• 主体匹配。

这些规则看起来朴素，但胜在便宜、透明、可测试。更重要的是，它们不需要额外进程，也不会把每次聊天都变成一次 embedding 调用。

对群聊机器人来说，这个取舍很现实。机器人不是离线知识库，它还要处理消息路由、图片、提醒、插件、健康检查和发送失败。记忆系统不能把整条消息链路拖慢。

主动注入要有阈值#

长期记忆影响回复，通常发生在组装上下文的时候。

原本的链路可能只注入机器人风格、最近对话和当前消息。升级后，可以在回复前根据当前消息检索相关长期记忆，再把少量高分结果放进上下文。

关键是“少量”和“高分”。

如果每次都把一堆似是而非的记忆塞进去，机器人会变得更自信，但不一定更准确。尤其是群聊里，很多内容只是当时的上下文，不该永久影响后面的判断。

所以主动注入应该有门槛：

• 消息太短时不检索。
• 总分低于阈值时不注入。
• 注入条数有上限。
• 注入内容只保留摘要，不贴原始聊天。
• 低置信度记忆宁可不放。

这些门槛会直接影响回复质量。RAG 检索不到会出问题，检索到太多无关记忆同样会污染上下文。

衰减不是删除#

记忆系统还需要处理时间。

一条很久以前的普通闲聊，不该和刚确认的项目规则拥有同样权重。不过这不代表要物理删除旧记忆。更稳的做法是在检索时做衰减：越久没被访问、重要性越低的记忆，排序自然往后掉。

如果一条旧记忆反复被命中，可以通过访问计数稍微抬回来。这样就形成一个轻量的强化机制：

1
重要 + 最近 + 被反复用到 -> 更容易进入上下文
2
普通 + 久远 + 从未命中 -> 慢慢淡出

这比定期删除文件安全。原始记录还在，排序权重会变，后面要审计或回溯也有依据。

自动压缩要低优先级#

很多记忆系统一开始就想做自动总结、自动压缩、自动画像更新。这个方向很诱人，但也最容易出错。

我更认同计划里的分层：

• 先做零成本的确定性整理：去重、合并相似候选、清理过期待办。
• 再做轻量反思：更新风格和稳定事实。
• 最后才做深度反思：整理知识、画像和长期偏好。

换句话说，能用规则解决的，先用规则解决。需要模型参与的，尽量放在低频、可审计、可回滚的位置。

聊天机器人不该每收到一条消息就把自己改写一遍。自动反思的频率越高，越要小心它把一次偶然聊天写成长期设定。

关联图谱可以先运行时计算#

计划里还有一个我觉得很实际的取舍：记忆关联图谱先不急着持久化。

如果只给新记忆写 related 字段，很容易形成单向关系。旧记忆不会自动知道新记忆的存在，图谱反而变得不一致。

第一版可以运行时计算关联：

• 同主体。
• 同标签。
• 同时间窗口。
• 同类型和同 scope。

检索到一条高分记忆后，再按保守规则拉几条关联记忆作为补充。这样既能得到一点图谱效果，又不用一开始维护复杂的持久化关系。

等规则稳定后，再考虑写入 append-only 的关系日志也不迟。

先写清楚不做什么#

这份计划最让我放心的地方，是它明确写了不做什么。

不引入向量数据库，不为每条消息调用模型，不自动跨群共享，不自动改代码，不依赖外部记忆服务，不存原始 embedding 向量。

这些限制不是单纯保守，主要是贴合这个项目的现实环境。长期记忆功能少一点还能慢慢补，规则太松才麻烦：跨群共享、自动反思、向量召回、画像更新，每一项单独看都合理，叠在一起就可能把一个本地助手变成难以审计的黑盒。

chatbot-qq 本身已经有 NapCat、OneBot、cc-connect、插件、图片、提醒和部署脚本。记忆系统如果再引入一整套外部服务，维护成本会快速超过收益。

对自用机器人来说，升级路线不该是“论文里有什么我都做”。我更关心能不能把论文里的思想拆成能在本地稳定运行的小块。

我会怎么落地#

如果让我给这类机器人排优先级，我会按这个顺序做：

1. 先做三因子排序，让 /记忆 结果可解释。
2. 再做主动注入，但加严格阈值和条数上限。
3. 同时补 canary 测试，固定排序、阈值和空结果行为。
4. 然后加访问计数和时间衰减，让旧记忆自然退场。
5. 最后再考虑反思压缩和关联图谱。

这条顺序比较朴素，但调试成本低，后面也容易回滚。

我现在越来越觉得，机器人记忆最难的是判断触发时机。先把排序、阈值、衰减和审计做好，再谈向量库和图谱，系统会更可控。