一、背景与意义

1.1 什么是 AI 记忆系统

你和 AI 聊了一周，告诉它你在学 Python、最近在减肥、不喜欢被催——下次打开对话框，它对这些一无所知，你得从头介绍自己。这不是 AI 不够聪明，而是它的架构里本来就没有"记性"。

没有记忆系统，AI 永远只是个工具——每次对话都是第一次，功能再强也只能处理当前输入，对面前这个人一无所知。记忆系统要解决的，是让 Agent 从工具进化为搭档：随着交互积累，越来越懂你，越来越能在你没有明说的情况下给出你真正需要的东西。

1.1.1 在智能体通用架构中的位置

❝

记忆不是智能体的一个附属功能，而是让它从"每次都是第一天"变成"越用越懂你"的关键基础设施。

要理解记忆系统的价值，得先看清楚它在智能体（AI Agent）整体架构里处于什么位置。

图中可以看到一个典型的智能体架构全貌。智能体居于中心，向四个方向延伸出四大核心模块：

• 右侧是决策（想），负责反思、任务规划和过程推理；
• 左侧是执行（做），对接搜索、编程、外部工具调用等能力；
• 底部是感知（看），连接其他智能体，接收来自外部环境的信息输入；
• 顶部是记忆（记），是跨越时间的，它把过去发生的一切沉淀下来，随时为当下的决策提供背景信息

❝

这个共识正在被整个行业验证：2024～2025 年，记忆相关的学术论文数量大幅增长，主要 AI 厂商相继推出自有记忆产品，专注 Agent 记忆的第三方独立创业公司也越来越多。

围绕记忆的讨论，衍生出一个新说法：上下文工程。它的核心命题是：智能体每次执行任务所需的所有输入——历史对话、用户偏好、可用工具、参考资料、执行规范——都属于"上下文"的范畴。

上下文工程就是研究如何为智能体的每一步行动，精准地准备"恰到好处"的信息来填充上下文窗口，既不遗漏关键内容，又不浪费宝贵的Token。记忆系统，正是上下文工程中管理"历史信息"这一维度的核心组件。

1.1.2 记忆系统 vs 上下文窗口

AI 记忆系统是插在 AI 应用与大语言模型之间的一层专用软件，专门负责跨会话地存储、整理和调取历史信息。它相当于给 AI 配了一本持续更新的私人笔记本——不只是当次对话的草稿纸，而是能在多次对话之间保留的长期档案。

理解记忆系统，需要先区分两个经常被混淆的概念：

上下文窗口是 LLM 每次回答时能"看到"的内容范围。记忆系统是给它提供更长时间跨度信息的基础设施。没有记忆系统，再聪明的 AI 也只是一个失忆的天才——每次会话都是它的第一天。

从架构上看，有没有记忆系统，对应的是两种截然不同的智体状态：

这个区别，正是记忆系统存在的意义。

1.1.3 狭义与广义的记忆系统

"记忆系统"这个词本身有宽窄之分。狭义的记忆系统，只指跨会话存储和检索用户相关事实——比如"用户不吃辣"、"正在学 React"——Mem0、MemoryOS 等开源框架都属于这个范畴。广义的记忆系统范围更大，RAG 也算其中一种——它从外部知识库检索文档片段注入上下文，本质是无状态的知识增强：

• 事实：用户偏好、历史对话、个人背景
• 知识库：智能体执行任务所需的领域知识、参考资料、企业内部文档
• 技能：可复用的操作规则和工作流，比如发周报的固定步骤、常用工具的调用模板

1.2 人类记忆模型：AI 设计的底层灵感

AI 记忆系统的设计，大量借鉴了认知科学（Cognitive Science）对人类记忆的研究。理解人是怎么记东西的，有助于理解 AI 记忆系统为什么要这样设计。

1.2.1 三阶段记忆模型

心理学家阿特金森和谢夫林（Atkinson & Shiffrin）在 1968 年提出，信息在人脑中经历三个存储阶段：

三个阶段各有职责，核心差异如下：

1.2.2 长期记忆的内部分类

长期记忆不是一个大仓库，而是按内容性质分成两大类、四种形式：

外显记忆是可以主动说出来的记忆，有两种：

• 情节记忆：对具体事件的回忆，有时间线和场景。比如"上周三在咖啡馆和朋友聊起了那本书"——你能回忆起是哪天、在哪里、和谁，整个场景历历在目。这是心理学家恩德尔·图尔文（Endel Tulving）在 1972 年的重要发现。
• 语义记忆：从大量经历中提炼出的稳定事实和规律。比如"北京是中国首都"、"我不喜欢吃辣"——你不需要想起是什么时候学到的，直接就知道了，和具体事件无关。

内隐记忆是在无意识状态下影响行为的记忆：

• 程序记忆：骑车、打字、开车——十年不练上去就会，从来不需要主动"回忆"动作步骤。
• 启动效应：看到"医生"这个词，处理"护士"的速度会加快，是一种无意识的影响，你自己感知不到。

❝

情节记忆和语义记忆的区别对 AI 系统设计很关键：情节记忆对应"保留原始对话和事件"（你能回溯当时说了什么），语义记忆对应"从中提炼出稳定的用户事实"（只记结论，不记过程）。存哪种、怎么存，是记忆系统最核心的设计决策之一。

1.2.3 短期记忆与长期记忆之间：遗忘曲线

信息如何从短期记忆进入长期记忆，以及为什么会遗忘？德国心理学家艾宾浩斯（Hermann Ebbinghaus）在 1885 年给出了答案——他以自己为实验对象，记录在不同时间间隔后能回忆多少内容，发现了著名的遗忘曲线：

其中  是记忆保留率， 是经过时间， 是记忆强度（强度越高，遗忘越慢）。

遗忘有三个核心规律：

• 先快后慢：学习后 1 小时内，大部分遗忘已经发生；之后衰减速度逐渐放缓
• 间隔效应：把练习分散在较长时间内，比集中突击效果好得多
• 复习强化：在快要遗忘前复习，效率最高，每次复习都能延长记忆的半衰期

语言学习平台多邻国基于这套理论，开发了半衰期回归模型（Half-Life Regression，HLR）——用机器学习为每个用户的每个单词预测"何时该复习"，使平台日留存率提升了 12%。

1.2.4 对 AI 记忆系统设计的映射

人类记忆的这几种类型，不是每种都能在 AI 里找到对应——有的能，有的没有：

❝

感觉记忆和启动效应的"缺席"并不是遗漏，而是 AI 架构的真实边界：记忆系统管理的是可以显式存储和检索的信息，而模型参数里的隐式知识不在它的管辖范围之内。

1.3 大模型自身的记忆限制

有人会问：现在模型能力越来越强，上下文窗口越来越大，甚至往后一兆Token的上下文窗口可能成为主流——有了这么长的上下文，是不是就可以不需要记忆系统了？

答案是不行。即使支持百万Token的上下文窗口，仍然面临四个根本解决不了的问题，这是上下文窗口架构本身的天花板，不是把窗口扩大就能突破的：

1. 物理容量的硬上限
2. 注意力分布不均导致的准确度下降
3. 历史越长越贵的成本爆炸
4. 散落信息无法整合的认知碎片化。

1.3.1 物理容量：窗口再大也有硬上限

上下文窗口是 LLM 每次回答时能读到的内容总量，以 Token 计量——大致一个汉字对应 1.5 个Token，一篇 1000 字的文章约 1500 个Token。即使是目前上限最高的百万Token窗口，换算成实际对话量，大约等于一个每天与 AI 交流 1000 字的用户连续 18 个月的完整历史。对重度用户或企业 Agent 场景，这个上限来得比想象中快。

更根本的问题不是"多久会超出"，而是上下文窗口本身的结构性质：它是每次请求独立的临时工作台。每次调用大模型，必须把所有需要参考的内容重新塞进去——上周的对话、上个月的决策、早期建立的用户画像，每次都要原封不动地"带上"，模型才能看到。这意味着：

• 历史越积越多，每次请求的负载就越来越重
• 会话结束后上下文立刻清空，下次从零开始——这不是 bug，而是当前架构的基本特性
• 超出上限后，必须强制截断或压缩，哪部分被丢掉，取决于系统策略，而非内容重要性

扩大窗口并不能解决这个结构性问题，只是在延缓它。窗口扩大 10 倍，只是让上限晚来 10 倍，持续积累的历史迟早还是会超出。

1.3.2 准确度下降："迷失在中间"与压缩失真

学术论文《迷失在中间：语言模型如何使用长上下文》（Lost in the Middle）揭示了一个反直觉的规律：即使上下文窗口足够大，模型对其中不同位置信息的注意力严重不均匀——对开头和结尾表现很好，对中间部分会出现系统性遗漏。这和人类记忆的"首因效应"和"近因效应"高度相似。

这意味着：单纯靠扩大上下文窗口无法解决记忆问题，窗口越大，中间被忽视的内容越多。

长上下文带来的准确度问题，在 Agent 执行长程任务时还有一种更隐蔽的失效形式：上下文压缩（Compaction）引发的信息失真。当 Agent 运行过程中上下文接近Token上限，系统会强制对历史内容做压缩摘要。但压缩不是无损的——关键的技术约束（如接口认证参数、特定配置值、早期确认的边界条件）极易在压缩中丢失，导致 Agent 在任务后期做出与前期决策完全矛盾的行为。这个问题在调试 AI 应用时尤其难以定位，因为从最终输出看不出压缩发生在哪一步。

1.3.3 成本爆炸：历史越长越贵

以一个有 1000 轮对话历史的用户为例（每轮约 500 Token，历史总量约 50 万Token），如果每次回答都把所有历史塞进上下文：

这个问题正在变得更紧迫——主流模型的定价在持续上涨，越好用的模型越贵。把所有历史信息一股脑塞给大模型，成本必然随用户历史积累持续上涨。

❝

长上下文带来的三个问题——准确度下降、成本飙升、性能变慢——互相咬合。为了提高准确率而保留更多历史，会同步推高成本和延迟；为了压成本而做上下文压缩，又会损失准确度。

记忆系统要做的，不是在三者中间做取舍，而是从根本上打破这个约束——精炼存储和精准检索，用极少的Token携带最有价值的信息。

1.3.4 认知碎片：有数据也看不出全貌

上面三个问题——窗口装不下、中间内容被遗忘、全量历史成本高——本质上都是"容量和成本"层面的限制，只要能塞进去就能用。但还有第四类问题，即使历史全在、数据完整，照样存在：认知碎片化。

用户的偏好、决策、习惯散落在数十次会话的各个角落，彼此之间没有连接。AI 每次处理的只是当前输入，它不知道这个人是谁，不知道他在乎什么，更无法把零散的信息串成一个完整的人物画像。结果就是：装不下是一个问题，记不住是一个问题，但即使装得下、记得住，串不起来也是同样致命的问题。

❝

装不下、记不住、串不起——这三句话准确概括了没有记忆系统时 AI 面临的三类本质困境。前两类是容量与持久性问题，第三类是认知整合问题，也是最难用简单工程手段绕过去的那一类。

1.4 记忆系统的技术价值

❝

记忆系统 = 认知引擎 + 检索引擎。前者决定"存什么、怎么理解"，后者决定"找什么、何时用"。两者缺一不可：认知做得再好，检索跟不上等于白存；检索再精准，认知没提炼，找出来的也是噪声。

1.4.1 RAG 的局限：有知识，没记忆

Agent 开发早期，一个非常自然的过渡方案是：给大模型外挂一个检索增强生成（RAG）服务。把文档、历史对话、知识库等内容存入向量数据库，用语义向量支持查询，作为大模型专业知识的补充。从某种角度说，这也是一种"记忆"——它确实解决了"没有相关知识"的问题。

但随着 Agent 场景越来越复杂，RAG 的局限逐渐暴露出来：它只解决了"找知识"的问题，并没有解决"记忆"的问题。

❝

RAG 是「无状态的知识检索」，不是记忆。RAG 是图书馆——知识写进去就定在那，不会进化；Memory 是大脑——它随时间演化，不是一成不变的东西。

RAG 的局限集中在四个方面：

真正的记忆系统需要在 RAG 的基础上额外解决：时序感知（知道什么先发生、什么后发生）、冲突消解（新信息优先，或保留演变轨迹）、信念追踪（记录观点如何变化，而不只是记录事实），以及跨会话的统一用户画像。这四点恰好是向量检索架构本身解决不了的。

1.4.2 四个维度的技术收益

1.5 记忆系统的业务价值

Agent 的「失忆困境」在企业场景里普遍存在，共性问题只有一个：会话结束 = 记忆归零。靠扩大上下文窗口（128K / 1M）无法根本解决，因为跨会话记忆、时序与关系推理、信念演化这三类能力不是上下文窗口能提供的，且成本会随历史积累线性攀升。

二、记忆系统概览与选型对比

❝

行业背景：不同于数据库领域已有 SQL 这样被广泛采用的事实标准，Agent 记忆目前还没有统一的实施规范——"用什么方案设计出来的记忆服务就一定是最好的"，业界尚无定论。这也是为什么当前出现了多个路线并行、各有侧重的开源方案，各自探索自己认为最合理的设计取舍。

用两个维度可以大致给现有方案做个分类：

1. 纵轴是存储结构，从结构化（提炼成事实、图谱、时序）到扁平（原始文本直接存）；
2. 横轴是管理方式，从被动存取（系统隐式处理，用户感知不到）到主动管理（Agent 显式读写，行为可控可审计）。

2.1 记忆系统的核心能力模型

一个完整的记忆系统，必须回答四个基本问题：怎么存、记什么、怎么找、怎么维护。每项能力的缺失都会导致不同类型的失效——存储不好，成本失控；写入不好，垃圾进垃圾出；检索不好，有记忆也用不上；更新不好，记忆库越来越乱。

2.1.1 记忆存储：怎么存决定成本与保真的平衡

存储解决的是"以什么形式保管记忆"的问题，核心是在压缩率和信息保真度之间找平衡。压缩越重，成本越低，但细节丢失越多；保留越完整，准确率越高，但成本和噪声也越高。

这个权衡体现在三个关键选择上：

1. 结构化还是非结构化——是保留自然语言原文，还是提炼成事实条目、标签、图谱节点；
2. 原文还是事实——存原文真值永久保留但噪声大，存提炼后的事实检索干净但一旦提炼出错就不可逆；
3. 分层与分类的粒度——所有系统都同时涉及按热度/时效分层（管理记忆的生命周期）和按内容性质分类（隔离不同类型的记忆），差别只在深浅，有的只有一层几个类，有的多达三层十几个类型。

这三个选择直接决定了系统在准确率、Token 消耗和部署复杂度上的表现差异。

2.1.2 记忆写入：记什么决定质量上限

一次对话可能有几十轮，真正值得长期保留的信息往往只占少数，其余都是过渡性的闲聊、重复确认、一次性事件。写入要解决的问题就是：从这堆原始内容里，把有价值的东西准确识别出来。

写入的设计分歧主要集中在三点：

1. 要不要提炼——用大语言模型把对话蒸馏成精炼的事实条目，检索时干净利落；或者原文全部保留，把"判断哪些有用"的压力留给检索侧处理；
2. 提炼粒度——每条记忆只记一个独立事实，检索最精准，但信息容易过碎；保留段落粒度，上下文更完整，但噪声也更高；
3. 写入时机——对话结束后同步提炼会增加响应延迟，异步处理流程更流畅，但刚说过的内容在写入完成前有短暂的"盲窗"。

❝

写入是整个系统的质量上限——进去的是噪声，后面再精妙的存储和检索也救不回来。

2.1.3 记忆检索：怎么找决定记忆能不能被用上

存得再好，找不到也是白费。检索的麻烦在于：用户问问题的方式，和记忆当初存进去的方式，往往对不上——"我说过不喜欢辣的"对应的记忆可能是"用户饮食禁忌：辣"，字面差很远但意思一样；而"GoLand 那个问题"里的专有名词，语义向量又容易识别不准。

检索的主要设计权衡有三个：

1. 检索路数——语义向量擅长理解同义词，关键词匹配擅长精确命名实体，两者各有盲区；主流方案是两路并行加实体加权，融合打分后取最优；
2. 单次还是多轮迭代——简单问题一次检索就够，但"当初那个项目后来怎样了"这类需要跨多条记忆推理的问题，一次往往答不全；多轮迭代准确率更高，代价是延迟和成本随轮次上升；
3. 每轮都查还是按需触发——每轮对话都触发检索，召回稳定但消耗高；只在系统判断"这个问题需要查历史"时才触发，节省成本但可能漏掉隐性关联。

❝

检索不只是"找到"，而是"找对"——上下文窗口有限，塞进去的每一条记忆都要值这个位置。

2.1.4 记忆维护：怎么更新决定长期可靠性

记忆库不是写完就不动的数据库。用户状态会变，同一件事会在不同对话里被反复提到，新旧信息之间会产生矛盾。不做维护，库只会越来越乱——同一个用户"想换工作"和"已经入职"同时存在，系统根本不知道该信哪条。

维护涉及的核心问题有三个：

1. 只增不减还是允许删改——永远追加是最保守也最安全的策略，旧记忆不会被误删，但会持续堆积干扰检索；允许更新和删除能保持库整洁，但大语言模型判断失误的代价是信息永久丢失；
2. 矛盾信息怎么处理——新旧冲突时，是让两条并存靠时间戳区分优先级，还是主动判断哪条更新、让旧的降权或作废；
3. 要不要设衰减——长期不被命中的记忆永久保留会让库无限膨胀，引入遗忘曲线自动淘汰可以控制规模，但阈值调不好会把有用的东西也清掉。

维护是各方案设计差异最大的一环，也往往是系统上线后最先出问题的地方。

2.2 核心评测方法

记忆系统的设计选择多、取舍复杂，光看架构描述很难判断好坏。评测的意义在于把记得准不准、成本高不高、够不够快这几个核心问题量化出来，让不同方案之间可以横向比较，也让选型有数字依据而不只是定性判断。评测的基本思路是固定底座、换记忆方案，在标准数据集上对比结果。

2.2.1 主流评测数据集

评测记忆系统，核心是用标准数据集检验它"记得准不准、记得住多久"。目前行业里常用的有两个：一个考单次超长对话内的记忆能力，一个考跨多次会话的事实积累。

长对话建模数据集（LoCoMo） 模拟持续数月的真实人际对话，内容涵盖工作进展、个人爱好、家庭变化等多条话题线，对话轮数通常在 300 轮以上。给定这段超长对话历史，要求回答关于其中内容的问题——从"用户职业是什么"这样的单步事实，到"当年那个项目后来结果如何"这样的跨时间多跳推理，难度逐级递增。

❝

举个例子：对话里两个月前提到"准备换工作，投了几家公司"，一个月前说"终于拿到 Offer 了"，现在问"他现在在哪家公司"——需要跨多轮、跨时间线把信息串起来才能回答。

长记忆评测数据集（LongMemEval） 的思路完全不同——不是单个超长对话，而是多次独立会话中散落的事实积累。这更接近真实助手的长期使用场景。

❝

举个例子：用户在第一次对话里提到自己对花生过敏，隔了几天的第四次对话问"推荐个下午茶甜点"，AI 应该记得主动避开含花生的选项——没有记忆系统的话，两次会话之间什么都不留，推荐出问题也发现不了。它还有一个单会话变体，专门考察在同一次超长对话内的信息整合能力。

2.2.2 可以评测哪些指标

核心三个指标可量化、可横向对比，选型时最先看：

❝

三个指标要一起看——高准确率如果靠堆 Token 换来，不算好方案；低延迟如果是靠牺牲准确率，同样不可取。

其次还有两类难以量化但值得关注的维度：

• 使用成本：写入时是否调用 LLM 做提取（每条记忆都要花钱）、检索走向量库还是全量扫描、存储用什么数据库——这些策略决定了系统真实的运营成本，不只是回答时的 Token 数
• 架构复杂度：是否依赖图数据库、向量库等特殊组件，接入和维护的工程量有多大

2.2.3 怎么跑评测

固定一个底座，换不同记忆方案对比，有两种常见思路：

2.3 开源方案对比

本节对比五个开源方案：Mem0、MemMachine、MemoryOS、OpenViking、PowerMem。

• Mem0：写入侧用 LLM 一次提炼为结构化事实条目，只追加不删改；检索侧三路并行（语义向量 + BM25 + 实体加权）融合打分。设计上追求最小接入成本，没有分层、没有遗忘机制，记忆库随时间单向增长。

• MemMachine：核心取舍是完全不做 LLM 提炼，原文直接存储，避免写入引入失真，且历史数据可随时用更好的模型重新索引。代价是检索侧需要维护派生索引，并用检索 Agent 做多轮迭代定位答案，复杂度高于其他方案。

• MemoryOS：把记忆按热度分成三层（短期→中期话题聚类→长期抽象画像），层间流动由检索次数、内容量、时间衰减综合打分驱动。相比 Mem0 的扁平结构，话题边界更清晰，但热度阈值是系统行为的关键变量，需要针对场景调参。

• OpenViking：把记忆、资源、技能统一用文件系统范式管理，结构对开发者可见可编辑。写入侧是五方案中唯一强制"先读再写"的——ReAct 循环先读取现有记忆再生成精确增删改操作，避免重复写入；检索侧用三层语义索引（全局→目录→内容）逐级收窄范围，Token 消耗因此大幅低于传统平铺向量检索。

• PowerMem：把记忆从上下文剥离出来独立管理，引入 Ebbinghaus 遗忘曲线给每条记忆计算保留率，长期未命中的自动衰减淘汰。写入时做三层去重（哈希→语义→LLM 聚类）控制库膨胀，检索时只取高权重条目，是五方案中唯一做完整记忆生命周期管理的。

2.4 云厂商方案对比

❝

核心结论： 截止5.8调研的结果，可提供服务的厂商有三家：阿里、OceanBase 和百度，字节和腾讯暂未上线，综合比较：百度 > OceanBase > 阿里

• 成本上：阿里 >> 百度 ≈ OceanBase，阿里需要部署一套PorlarDB集群，其余都是开箱即用；
• 稳定性：百度 > 阿里 > OceanBase，百度有专人团队运维，阿里也是一套成熟的向量数据库集群，但需要专人运维，OceanBase由大数据和开源社区共同运维；
• 效果上： 由于测试数据、测试方法各家都不太一致，无法根据公开结果给结论；
• 技术上：百度 > OceanBase > 阿里，百度采用四层记忆和多维度存储，相比OceanBase和阿里策略更丰富，OceanBase参考阿里采用的Mem0 1.0开发，相比阿里更强。

三、记忆系统的核心工作机制

一个可以真正工作的记忆系统，必须回答四个问题：记忆放在哪里、什么值得被记住、怎么从历史里找到需要的信息、信息过时了怎么处理。四个问题对应四套机制，从外到内构成四层架构。

3.1 整体架构

在拆解每个机制之前，先把整个系统的层次看清楚。记忆系统要同时面对多种接入方式、驱动多条处理流程、对接多种底层存储——把这些功能堆在一起会让系统极难维护和扩展。分层的意义正在于此：让每一部分只负责自己的事，互不干涉。

❝

四层架构的核心逻辑是关注点分离：每层只向相邻层说话，不跨层调用。换一套底层存储，不用改引擎；换一套检索算法，不用改服务接口。每层都可以独立演进。

从上到下，四层各有明确的定位：

服务层是外部请求的统一入口：HTTP 接口供开发者同步读写，管理控制台用于可视化管理，SDK 封装常用调用，MCP 让 AI Agent 直接读写记忆。

引擎层的四个流程各自独立运行：写入引擎提炼结构化记忆，检索引擎多路召回融合重排，遗忘引擎按热度衰减淘汰陈旧条目，巩固引擎去重合并防止无限膨胀。

能力层定义引擎依赖的四项策略：分层存放、三类路由写入、双路并行检索、跨用户作用域隔离。引擎只调用能力层接口，不直接操作存储。

存储层四类介质各司其职：向量数据库按语义余弦检索，实体索引精确命中专有名词，关系型数据库记录时间戳和热度分值，图数据库维护实体关联与知识图谱。

❝

四层从上到下是"离用户越来越远、离数据越来越近"的关系。服务层只管接入，不关心记忆存哪里；存储层只管持久化，不关心业务逻辑。引擎层和能力层是中间的粘合剂，把两端连起来。

3.2 存储：记忆放在哪里

3.2.1 两层设计：工作台与档案室

记忆系统把记忆分成两层：一层是当前对话的上下文，另一层是跨会话长期保留的个人历史。

短期记忆给系统一个"当下"：用户说"帮我继续完善那个方案"，短期记忆告诉系统"那个方案"是指什么；用户提到"他"，短期记忆告诉系统指代的是谁。没有这层上下文，系统每次回复都像是第一次见面。

长期记忆保存的是提炼后值得长期保留的内容：用户的偏好、经历过的事、做过的决策、执行过的任务步骤。以语义向量形式组织，检索时按意思而非关键词匹配——用户说"我对辛辣食物过敏"和"我不吃辣"在语义上是同一件事，都能被命中。容量没有上限，这正是为什么需要专门的遗忘和巩固机制来管理它的质量。

❝

举个例子：用户在一次对话里说了三件事——问了一道菜的做法、提到自己不能吃辣、又问了一个和辣椒无关的代码问题。三件事都进了短期记忆，系统回答时都能参照。但会话结束后，"不能吃辣"会被提炼进长期记忆，菜谱和代码问答则不一定——它们是一次性内容，没有跨会话保留的价值。

3.2.2 三类记忆内容：存什么决定怎么找

长期记忆里存放的内容按性质分为三类，分类决定了它们怎么被存、怎么被找到。

事实记忆不带时间戳——"用户不吃辣"、"职业是前端工程师"、"有两个孩子"，这类结论和什么时候说的无关，今天成立、明年也成立。检索时不需要考虑时间，按语义相似度找即可：问"用户有什么饮食限制"，就能命中"不吃辣"这条事实。

事件记忆的核心价值在于时间线索。"上个月提到正在学 React"、"上周告知已经拿到 Offer"——状态会变，学 React 可能已经学完，Offer 可能已经入职。如果去掉时间坐标，只保留"用户在学 React"，等到三个月后用户再次对话时，这条记忆就变成了误导。保留了时间信息，AI 才能追踪状态演变，回答"他现在在做什么"，而不是把过时信息当成当前事实。

程序记忆记录的是 Agent 执行任务的完整步骤历史。比如一个用来整理文件的 Agent 执行到一半被中断，这些已完成步骤的记录就是程序记忆——Agent 重启后能从中间继续，而不必从头来过。和前两类有一个根本区别：程序记忆不能被压缩或提炼，必须保留每一步的原始输出，因为任意一步的结果都可能是后续步骤的输入。

❝

快速判断方法：这条记忆能不能脱离时间独立成立？"用户不吃辣"永远成立 → 事实记忆；"上周用户说在学 React"依赖时间点 → 事件记忆；Agent 的执行步骤记录 → 程序记忆的专属领地。

3.3 写入：什么值得被记住

对话结束后，最直接的做法是把原文全部推进数据库——简单、无损、零延迟。但这条路走不通。

3.3.1 直接存原文的问题

真实对话充满噪声，比如：

❝

"嗯对，我之前说的那个，就是我不太喜欢辣，昨天去吃串串结果辣到不行，对了你帮我记一下我老家在成都。"

这段话里有情绪表达、一次性事件和真正值得长期保留的事实混在一起。如果原文直接存进去，下次检索"用户饮食偏好"时，整段话都会被拖出来——噪声极大。随着对话积累，同样的信息被反复提到，检索质量只会越来越差。

主流的解法是在写入前加一道提炼，把写入流程分成三个阶段：短期实时缓存、异步事实提炼、按类型路由写入长期存储。

图中三个阶段从上到下串联：第一阶段同步执行，把对话追加到短期缓冲队列；第二阶段在后台异步运行，调用 LLM 提取关键事实并去重，不阻塞主对话；第三阶段按事实 / 事件 / 程序三种类型分别路由，写入长期记忆库。

3.3.2 事实提炼：用大语言模型做一道蒸馏

主流的做法是在写入前加一道提炼步骤：用大语言模型从原始对话中提取真正有价值的信息，把上面那段话转化成：

• 用户不喜欢辣食
• 用户老家在成都

两条干净的事实，噪声消失，检索时也更精准。这个过程叫事实提炼，是写入环节最核心的一步。

3.3.2.1 提取什么：七类值得记录的信息

提示词把要记录的内容划分为七个类别：

提取范围不只是用户的话——助手消息同样扫描：用户消息揭示个人事实和偏好，助手消息包含用户之后可能引用的建议和计划（比如"助手推荐了哪家餐厅"）。

3.3.2.2 记忆质量标准

❝

具体细节是记忆有用的原因所在——把"航空运动"泛化成"运动"，这条记忆就废了。

3.3.2.3 时间词必须在写入时锚定

对话中的相对时间表达必须在写入时转换成绝对日期：

锚定时用对话发生的日期，不用系统当前日期——两者可能相差数月甚至数年。

3.3.2.4 提炼时的三条原则

3.4 检索：怎么从历史里找到对的记忆

记忆写入之后，"找"才是决定系统质量的关键一步。检索面临两个互相矛盾的挑战：用户提问时的措辞，和记忆当初存入时的表达，往往对不上；但专有名词（品牌名、技术术语）又要精确命中，不能被"按意思找"的逻辑稀释掉。任何单一检索策略都无法同时应对这两个场景，混合检索因此成为主流设计。

图中两个阶段：第一阶段语义向量检索和关键词匹配并行展开，各自产出候选集；第二阶段将两路结果加权合并，返回最相关的若干条记忆。

3.4.1 关键词搜索的盲区：字面不匹配就全漏

传统数据库按关键词精确匹配——匹配的是字符序列，不是语义。用户搜"饮食限制"，找不到"不吃辣"；搜"辣"，才能找到"不吃辣"；搜"饮食"，什么都找不到。这不是检索能力的问题，而是关键词匹配的设计本质决定的。

记忆系统的场景让这个问题更突出：记忆条目用自然语言写成，措辞随机；用户提问也是自然语言，换个说法全漏。系统召回率严重依赖用词是否碰巧一致，而这在真实对话中几乎无法保证。

❝

关键词搜索的短板不在精度，而在召回——字面不重叠的内容，它根本看不到。

3.4.2 语义向量检索的盲区：命名实体被稀释

语义向量检索解决了字面不匹配的问题。每条记忆存入时被转化为高维向量，这个向量捕捉的是文字的意思。"不吃辣"和"对辛辣食物过敏"字面完全不同，但在向量空间里距离很近——检索时按向量距离找最近邻，就是"按意思找"。

但语义向量的弱点恰好相反：命名实体。品牌名、产品名、技术术语在训练数据中出现频率远低于普通词汇，向量表示往往被"稀释"进周围相关词语构成的模糊区域。

比如用户问"GoLand 的那个配置怎么设"——向量检索可能把"IDE 配置"、"编辑器设置"相关的记忆一并召回，但"GoLand"这个精确词未必能命中包含它的那条记忆，因为它和"PyCharm"、"IntelliJ"这些同类工具名在向量空间里距离同样很近，无法精确区分。

❝

两种策略的失败模式刚好互补：关键词漏掉同义词，向量稀释专有名词。

3.4.3 混合检索：两路并行，各取所长

解法是两路并行：语义向量检索负责理解意思，关键词匹配负责精确命中专有名词。两路独立召回候选集后，按加权公式融合打分：

两个权重可以根据场景调整——日常对话倾向向量权重更高，精确名称查询时关键词权重更高。最终取综合得分最高的若干条返回。

3.5 更新：记忆怎么保持可靠

记忆库不是写完就不动的数据库。用户的状态会变，同一件事会被反复提到，新旧信息之间会产生矛盾。随着对话积累，库里会出现三类问题：

面对这三类问题，有两种取向截然不同的策略。

图示对比两种取向对同类问题的不同处置：激进策略追求记忆的整洁，但依赖模型判断是否删除；保守策略接受一定冗余，换取信息不丢失的安全性。

3.5.1 激进策略：自动清理，风险在误删

激进策略让系统自动判断哪些该删、哪些该合并，目标是保持库的干净和精简。

核心弱点在于：大语言模型在做删除决策时，倾向于把"最近没被提到"误判为"不再需要"。而用户的信息往往有长尾价值——六个月前提到的过敏史，不会因为近期没再说就失效。一旦删错，无法追回。

3.5.2 保守策略：只增不减，冗余优于缺失

主流系统的选择是保守策略，核心原则是绝不主动删除。

以冲突信息为例：用户三月说"想换工作"，六月又说"已经入职新公司了"。系统不删掉三月那条，两条都留——检索职业状态时优先返回六月那条，三月那条作为背景记录保留，方便追踪完整的经历轨迹。

❝

误删代价远高于冗余代价。存多了可以慢慢清，删错了无法追回——这是几乎所有生产系统都倾向保守策略的根本原因。

四、前沿探索

第三章描述的是记忆系统的共性基础架构——写入提炼、混合检索、保守更新。在这个共同基础之上，各方案都在不同维度做了深入探索：有的针对检索精度，有的引入认知科学模型，有的专注写入质量控制，有的解决记忆安全问题。这一章梳理各方案的独特设计，以及领域内更广泛的研究方向。

4.1 各方案的特色设计

4.1.1 MemMachine：写存分离与多跳检索

MemMachine 解决了一个核心矛盾：存原文意味着检索时要处理大量冗余噪声。它的做法是写存分离——存的时候不动原文，检索侧单独建立派生索引：把每条消息拆分成细粒度片段分别生成向量，检索时用细粒度向量精准定位，再回溯到完整的上下文片段。

除此之外，MemMachine 是目前唯一内置检索智能体的方案。遇到多跳问题（"用户当时提到的那个项目现在怎么样了"），不是一次检索就给答案，而是最多迭代 3 轮——每轮检索结果启发下一次检索方向，准确率从单次检索的 84.87% 提升到 91.69%。

4.1.2 MemoryOS：热度驱动的分层升降

MemoryOS 把操作系统的内存分层策略搬进了记忆系统：短期（10 条问答）→ 中期（按话题聚类，最多 2000 个话题）→ 长期（抽象画像，最多 100 条）。话题能否从中期升入长期，由一个综合热度分决定：

三个系数默认均为 1.0，时间衰减半衰期 24 小时，热度超过 5.0 触发提炼并重置热度。只有被反复访问、内容积累量大且最近仍有活跃的话题，才会沉淀进长期记忆——避免了单纯靠时间或频率判断带来的误升降。

4.1.3 OpenViking：分层索引与写入前读取

OpenViking 的核心是两个相互配合的创新。

检索侧

三层语义索引——第零层是全局摘要（约 100 个Token），第一层是目录级索引（约 2000 个Token），第二层才是具体记忆内容。检索时先扫第零层快速排除无关区域，再进第一层锁定目录，最后深入第二层。相当于查书先翻目录再找页面，Token消耗比全量扫描低 92%。

写入侧

写入前读取循环——大语言模型在写入新记忆前，必须先读一遍当前已有的相关记忆，再生成精确的增删改操作，而不是直接追加。配合三种字段保护策略（精确修改、数值累加、首次写入后锁定），防止历史数据被覆盖。

4.1.4 PowerMem：遗忘曲线与记忆生命周期

PowerMem 引入了艾宾浩斯遗忘曲线（Ebbinghaus forgetting curve），每条记忆写入时同时计算一个保留率：

重要性评分从 6 个维度综合打分（关联度、新颖性、情感强度、可行动性、事实性、个人相关性）。不同类型的记忆衰减速率不同：工作记忆衰减最快（0.20）、短期记忆居中（0.15）、长期记忆最慢（0.10）。

每次检索命中触发强化——访问次数累计超过阈值，记忆类型晋升一级，衰减速率随之降低；长期不被命中则保留率自然降到阈值以下，自动清除。记忆库还配备三层递进压缩（哈希去重 → 语义去重 → 大语言模型聚类压缩），防止无限膨胀。

4.1.5 Mem0：实体越热、加权越弱

Mem0 的实体加权有一个反常识之处：一个实体关联的记忆越多，加权效果越弱：

当  时加权系数为 0.5，当  时仅剩 0.046。原因是：像"Python"这样极常见的词如果同等加权，任何问题都会把大量记忆拉高，反而找不准。越具体的实体（如某个内部项目代号），关联记忆条数少，加权效果越强——精确命中比广撒网更重要。

4.2 更广泛的研究前沿

除了各方案的独特设计，记忆系统领域还有几个尚在验证阶段的探索方向，代表着下一阶段可能的演进路径。

❝

强化学习和多模态是离实用最近的两个方向：前者让系统从使用反馈中自我优化，后者拓展了记忆的信息边界；记忆安全则是生产部署前必须正视的风险。