AI 记忆系统怎么做：短期记忆、长期记忆与 Dream 自动整理
约 2463 字大约 8 分钟
2026-05-17
很多 AI 系统一开始都没有真正的“记忆系统”，只有上下文窗口。模型每次回答时带上最近几轮消息，看起来已经像是在“记住”用户了。但只要对话跨会话、跨天甚至跨设备继续发生，这种记忆感就会立刻消失。更麻烦的是，即便平台愿意把所有历史都塞进 prompt，成本和延迟也会很快不可接受。
所以 AI 记忆真正要解决的，从来不是“把聊天记录存下来”，而是三个更难的问题：
- 什么信息应该留在当前会话内即时使用
- 什么信息值得沉淀成跨会话长期记忆
- 什么旧记忆应该被整理、衰减、归档，而不是无限堆积
联犀当前的记忆系统，就是围绕这三个问题逐步演进出来的。它没有把记忆做成一个单表或一个大字段，而是把短期记忆、长期记忆和 Dream 自动整理拆成不同层次处理。
为什么上下文窗口不等于记忆
很多人第一次做 AI 应用时，都会把“多传几轮历史消息”当成记忆方案。这种做法当然能在短会话里提升连续性，但它有两个天然问题。第一，窗口再大也是暂时的。模型这轮看到的信息，下轮可能因为 token 预算被裁掉。第二，窗口里的内容没有结构。用户的偏好、历史事实、偶发事件和闲聊内容混在一起，平台并不知道哪些应该长期保留。
换句话说，上下文窗口只是运行时输入，不是记忆系统。它更像人短时间内的工作记忆，而不是可以跨场景复用的长期记忆。
如果平台不把这两类东西分开，最后通常会陷入两个极端：要么上下文越来越大，延迟越来越高；要么为了控 token 直接裁掉历史，用户感觉系统永远“记不住我”。
联犀当前记忆系统的第一步，就是承认短期记忆和长期记忆必须是两套机制，而不是一套消息列表的不同长度。
短期记忆解决的是“这一轮还要连得上”
短期记忆在联犀里更接近运行时结构，而不是一张独立业务表。它主要由最近轮次消息窗口和压缩摘要组成。
它的目标非常明确：
- 保留最近对话连续性
- 控制上下文长度
- 在窗口过长时做压缩，而不是无限追加
这里最关键的设计点，不是“保留多少轮”，而是承认短期记忆天然服务于当前会话。它需要足够快、足够轻，而且可以随着对话推进被裁剪或摘要化。
短期记忆因此更像一种为模型输入服务的运行时缓存，而不是最终知识资产。
这类设计的价值在于，系统终于可以把“本轮回答需要的即时上下文”和“值得长期沉淀的事实”分开。前者优先保障当前对话体验，后者则交给更慢、更重、但更稳定的长期记忆链路。
长期记忆解决的是“下次还应该知道什么”
长期记忆在联犀里围绕 clone 建模，这一点非常重要。
系统不是把所有用户历史抽象成一个公共记忆池，而是围绕特定 clone 存储事实、偏好、事件和摘要。这样做的好处是，记忆天然有归属，也更容易服务于“这个数字分身以后还应该记住什么”。
当前长期记忆的核心类型主要包括：
factpreferenceeventsummary
这说明联犀并没有把长期记忆理解成一段大文本，而是尝试让记忆具备最基础的语义分类。因为只有这样，后续检索、衰减和重排序才有机会建立在“这是什么信息”之上，而不是对所有历史一视同仁。
更进一步看，长期记忆并不是只存 content。它还会伴随：
keywordsimportanceaccess_count- 向量索引 key
这些字段的价值，在于让记忆不再只是被动存档，而是变成一类可检索、可打分、可治理的系统资产。
为什么提取链路必须单独存在
长期记忆如果只是把每轮对话原样塞进数据库，很快就会变成另一种低效日志。
真正有价值的记忆，应该经过提取。联犀当前的思路是：对话先进入 ai_session_summaries，再由提取链路筛选出值得沉淀的内容，之后再写入长期记忆层。
这件事的意义不在于“又多了一步处理”，而在于平台终于有机会决定：
- 哪些内容值得长期保留
- 哪些只是无信息量寒暄
- 哪些是错误回复或噪音
如果没有提取链路，长期记忆和原始会话记录之间就没有本质区别，只是换了一个表继续堆。
而一旦提取链路成立，平台就开始具备一种更像“整理记忆”而不是“备份聊天”的能力。
在当前 Memory V2 里，这条沉淀链路已经进一步从单一的 ai_clone_memories 扩展到 records / entities / profiles 这类更细的层次。它意味着系统开始尝试把长期记忆继续拆成“记录、实体、画像”三类更适合后续检索与治理的对象，而不是只保留一个扁平记忆池。
检索能力决定了记忆系统是不是“真的记得住”
有了长期记忆，并不等于系统就能稳定回忆。
很多所谓“有记忆”的系统失败，原因就在这里：写入很多，召回很乱。真正的记忆系统，必须同时解决“怎么存”和“怎么找”。
联犀当前的检索链路不是单一向量搜索，而是把几种能力叠加起来：
- embedding
- vector search
- keyword search
- MMR 重排
- temporal decay
这说明平台并没有把记忆召回完全押在某一种检索手段上。因为长期记忆这种对象本身就很复杂：有些事实适合向量相似度，有些偏好更适合关键词，有些内容虽然相似却已过时，有些则虽然陈旧但经常被访问。
只有把这些信号合并起来，系统才有机会让“真正应该被想起来的记忆”排到前面。
这里最值得强调的是，访问次数和时间衰减同时存在。它背后的判断非常符合真实记忆语义：不是越新越重要，也不是越常访问就永远不衰减，而是要在“新鲜度”和“被反复证明有价值”之间取得平衡。
Dream 自动整理为什么是必须的
记忆系统最容易被忽视的一件事，是记忆不会只增长，还会老化。
如果长期记忆只会写入不会整理，系统迟早会面对三类问题：
- 检索结果越来越噪
- 重要记忆被大量旧记录淹没
- 存储和召回成本持续上升
这就是 Dream 自动整理存在的原因。
联犀当前的 Dream 已经不是“人工触发一次记忆压缩”，而是后台按扫描周期检查 clone 的活跃 L1 记录，并在满足空闲阈值条件后自动执行整理。也就是说，平台开始承认记忆治理不只是人工运维动作，而应成为系统内建能力。
这个设计非常关键。因为它意味着记忆系统不再只是一个不断追加内容的数据库，而是一个具备“整理旧内容、生成更高层摘要、归档原始快照”的动态系统。
Dream 之后，活跃 L1 记忆会被归档，系统生成新的 L2 dream summary，并更新更稳定的 profile。这样做的结果，是记忆并不会随着时间无限膨胀成不可维护的大堆文本，而是逐渐形成更凝练、更可复用的长期画像。
从人的直觉看，这也更像真正的记忆：经历不会凭空消失，但会被总结、抽象、沉淀，而不是永远以最原始的细粒度占据前台。
记忆系统的真正难点，不是存，而是治理
如果把联犀的记忆系统压缩成一句话，它的核心不是“有短期和长期两层”，而是“把记忆治理当成一件长期工程问题”。
短期记忆解决即时连续性，长期记忆解决跨会话沉淀，提取链路解决噪音过滤，混合检索解决回忆精度，Dream 解决老化和整理。
这些能力放在一起，才使记忆系统开始像一个系统，而不是一个附加功能。
否则，所谓记忆往往只是：
- 一段越来越长的上下文
- 一个越来越大的历史表
- 一套越来越慢的召回逻辑
真正成熟的 AI 记忆系统，不是记得越多越好，而是要在“记住什么、怎么想起来、何时该整理”之间持续做取舍。联犀目前这套设计，最有价值的地方也正在这里：它已经不再把记忆当作聊天记录副产品，而是把它当作 AI 平台的一级基础设施。
更新日志
2026/5/18 10:48
查看所有更新日志
43ef3-docs(blog): 新增后端与架构系列技术博客 18 篇，更新原有 7 篇于
