---

前言

之前在自己的 Agent 项目中使用过 Mem0，但当时更多是把它当作一个现成的长期记忆组件：知道它可以存储和检索用户信息，也调用过相关接口，却没有系统了解它背后的方法设计。

因此，这次想通过 Mem0 的原始论文，进一步理解这个被广泛使用的 Agent 记忆框架究竟是如何工作的。

人类智能在很大程度上依赖记忆。记忆塑造我们的身份，影响我们的决策，也让我们能够从过去的经历中学习、适应环境，并维持长期的人际关系。

在与他人持续交流的过程中，我们会自然地记住：

• 对方的身份和经历；
• 对方表达过的偏好；
• 过去共同做出的决定；
• 已经讨论过的问题；
• 某些信息随时间发生的变化。

但是，大模型本身并不具备这种跨会话持续存在的状态。

当历史信息离开上下文窗口后，模型通常无法继续使用这些信息。即使把上下文窗口扩展到数十万甚至数百万 token，也只是推迟问题出现的时间，并没有真正解决长期记忆问题。

现实中的长期交互主要面临两个困难。

第一，随着用户和 Agent 的交互不断增加，历史内容最终仍然会超过任何固定的上下文窗口。

第二，更重要的是，现实对话并不是围绕一个主题连续展开的，而是具有明显的跳跃性。用户可能先提到自己的饮食偏好，接着讨论大量编程和论文问题，几天后才再次询问餐厅推荐。

在这种情况下，即使相关信息仍然位于上下文窗口中，也可能被大量无关内容淹没。更长的上下文并不意味着模型一定能够准确找到并利用其中的信息。

因此，一个实用的长期记忆系统不应该只是不断扩大 prompt，而应该具备三种能力：

1. 从持续对话中选择性提取重要信息；
2. 根据新旧信息之间的关系维护记忆；
3. 在后续任务中只召回真正相关的记忆。

这篇论文提出了 Mem0，一种面向生产级 AI Agent 的可扩展长期记忆架构。它能够从持续产生的对话中动态提取、整合和召回重要信息。

在 Mem0 的基础上，论文还提出了图增强版本 Mem0^g。Mem0^g 使用图结构表示记忆，将实体作为节点、关系作为边，从而更好地处理跨实体关系和时间变化。

简单来说：

Mem0 关注如何把对话转化为简洁、可维护的自然语言记忆；Mem0^g 则进一步把这些信息组织为实体关系图。

---

零、论文基本信息

• 论文名称：Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
• 发表平台：arXiv preprint
• 代码仓库：mem0ai/mem0
• 作者信息：
  • Prateek Chhikara
  • Dev Khant
  • Saket Aryan
  • Taranjeet Singh
  • Deshraj Yadav

---

一、为什么长上下文不能替代长期记忆？

在介绍 Mem0 之前，需要先明确一个问题：

既然现在大模型的上下文窗口越来越长，为什么还需要单独设计记忆系统？

论文认为，长上下文只能缓解问题，不能替代长期记忆。

1. 交互历史最终仍会超过上下文窗口

用户和 Agent 的长期关系可能持续数周、数月甚至数年。

随着对话不断积累，历史信息总量迟早会超过任何固定上下文窗口。即使上下文窗口非常长，也无法无限保存持续增长的交互历史。

而且，把全部历史内容反复发送给模型，会带来明显的工程成本：

• token 消耗持续增长；
• 首 token 延迟增加；
• 推理速度下降；
• 请求价格不断上升；
• 大量无关信息干扰模型判断。

2. 现实对话具有主题跳跃性

现实交互通常不会一直围绕同一个主题。

例如：

第一天：
用户说自己是素食主义者，而且不食用乳制品。

之后：
用户和 Agent 讨论了大量编程、论文和旅行问题。

几天后：
用户让 Agent 推荐晚餐。

真正与晚餐推荐相关的，只是很早之前提到的两个饮食约束：

素食
不食用乳制品

如果把全部历史记录都放进上下文，模型需要从大量无关内容中重新寻找这些信息。

因此，问题不只是“信息能不能放进上下文”，还包括：

模型能否在大量无关内容中稳定找到、理解并正确使用关键历史信息？

3. 更长的上下文不等于更好的召回

当关键事实被埋在大量文本中时，模型可能出现：

• 忽略较早的信息；
• 混淆不同时间出现的事实；
• 使用已经过时的偏好；
• 被近期但无关的信息干扰；
• 无法判断哪些历史内容更重要。

因此，可靠的长期记忆系统需要主动进行信息筛选，而不是把筛选压力完全交给大模型。

论文 Figure 1 使用一个饮食推荐案例展示了长期记忆的重要性。

图源：Chhikara et al., 2025，Figure 1。

左侧系统没有持久化记忆，因此在后续会话中忘记了用户“素食且不食用乳制品”的偏好，给出了不合适的建议。右侧系统保留了这些信息，因此能够生成符合用户约束的推荐。

这张图说明，长期记忆并不只是让 Agent “知道更多”，而是直接影响系统的一致性、个性化能力和用户信任。

---

二、这篇论文提出了什么？

论文提出了两种互补的长期记忆架构：

1. Mem0
2. Mem0^g

1. Mem0：自然语言事实记忆

Mem0 使用简洁的自然语言事实作为主要记忆表示，并采用增量式处理流程。

每当新的交互发生时，系统会：

1. 结合全局对话摘要和近期消息；
2. 从最新交互中提取候选记忆；
3. 检索语义相似的已有记忆；
4. 判断应该新增、更新、删除还是忽略；
5. 将操作结果写入记忆数据库。

它的重点是：

用相对较低的成本，把持续对话转化为紧凑、去重且能够动态更新的长期记忆。

2. Mem0ᵍ：图结构记忆

Mem0^g 在此基础上加入图结构表示。

在 Mem0^g 中：

• 节点表示实体；
• 边表示实体之间的关系；
• 标签表示实体的语义类型；
• 时间戳等元数据用于支持时间推理。

Mem0 可能把信息保存为：

Alice 住在旧金山。
Alice 喜欢意大利菜。

Mem0^g 则可以将其组织成：

Alice --lives_in--> San Francisco
Alice --prefers--> Italian Food

它的重点是：

不只保存孤立事实，还显式保存事实中实体之间的关系。

---

三、Mem0 方法总览

Mem0 采用一种增量式处理方式，可以随着对话持续运行，而不需要每次重新分析全部历史记录。

论文 Figure 2 展示了 Mem0 的完整架构。

图源：Chhikara et al., 2025，Figure 2。

整个流程可以分成两个阶段：

1. 提取阶段 Extraction Phase
2. 更新阶段 Update Phase

可以概括为：

新交互
→ 结合全局摘要与近期上下文
→ 提取候选事实
→ 检索相似旧记忆
→ 判断 ADD / UPDATE / DELETE / NOOP
→ 更新记忆数据库

这两个阶段分别解决两个问题：

提取阶段：什么信息值得记住？
更新阶段：这条信息应该如何写入已有记忆？

---

四、Mem0 的提取阶段

提取阶段的目标是：

从最新一轮交互中识别哪些信息具有长期保存价值。

假设系统收到一对新消息：

m(t-1)：上一条消息
m(t)：当前消息

这通常是一组完整的用户—助手交互，也可以是两个用户之间的交互。

Mem0 不会只把这两条消息直接交给模型，而是同时加入两类历史上下文：

1. 全局对话摘要；
2. 最近若干条消息。

1. 全局对话摘要

系统会从数据库中获取一份对话摘要。

这个摘要用于概括整个历史对话的主要语义，例如：

用户正在准备秋招，目标主要是 AI Agent 开发岗位；
目前没有正式实习经历；
正在完善 Agent 项目并练习算法。

全局摘要的作用是为模型提供长期背景。

例如，当前用户突然说：

我决定下周先开始投实习，不再继续增加项目功能。

如果模型知道用户之前一直在准备秋招，就更容易判断“求职安排发生变化”是一条值得长期保存的信息。

2. 近期消息窗口

除了全局摘要，系统还会取最近 m 条历史消息。

近期消息用于提供更细粒度的局部上下文，因为全局摘要可能没有包含：

• 最近出现的具体数字；
• 尚未被摘要覆盖的新决定；
• 当前话题中的条件；
• 新旧信息之间的细微变化。

因此，Mem0 同时使用：

全局摘要：提供长期语义背景
近期消息：提供局部细节和时间连续性

3. 构造提取输入

为了便于理解，可以把提取输入简化表示为：

$$P=(S,H_{\mathrm{recent}},m_{t-1},m_t)$$

其中：

• S 表示全局对话摘要；
• H_recent 表示近期消息；
• m(t-1) 和 m(t) 表示最新消息对；
• P 表示交给记忆提取模型的完整输入。

随后，LLM 从中提取候选事实集合：

Ω = { ω 1 , ω 2 , … , ω n } \Omega=\{\omega_1,\omega_2,\ldots,\omega_n\} Ω={ω1​,ω2​,…,ωn​}

其中，每个 ω 都代表一条候选记忆。

例如，输入为：

用户：
我以前考虑去上海实习，但现在决定秋招期间只考虑北京的岗位。

助手：
明白了，后续我会优先从北京岗位出发给你建议。

系统可能提取出：

用户秋招期间优先考虑北京岗位。

而下面这些低信息量内容通常不需要长期保存：

好的。
谢谢。
我知道了。

4. 异步摘要更新

论文还设计了异步摘要生成模块。

对话摘要会被周期性刷新，但这一过程独立于主要记忆流水线运行。

这样做有三个好处：

• 提取阶段可以使用相对新的全局摘要；
• 摘要生成不会阻塞当前请求；
• 可以降低在线记忆写入延迟。

这一设计体现了 Mem0 的生产化思路：不仅关注记忆质量，也考虑真实请求链路中的响应效率。

---

五、Mem0 的更新阶段

候选事实被提取出来后，并不能直接全部追加到记忆数据库中。

如果只做新增，记忆库很快就会出现：

• 大量重复记忆；
• 相互矛盾的记忆；
• 已经过时的信息；
• 表述不同但语义相同的条目；
• 新旧状态同时存在的问题。

因此，Mem0 还需要判断候选事实和已有记忆之间的关系。

1. 检索相似旧记忆

对于每条候选事实 ω_i，系统首先计算其向量表示，然后从数据库中召回语义最相似的 Top-s 条记忆。

可以简化表示为：

$$M_i=\mathrm{TopS}({\omega }_i,M)$$

其中：

• ω_i 是当前候选事实；
• M 是已有记忆库；
• M_i 是与候选事实最相关的旧记忆集合。

论文实验中设置：

m = 10：使用最近 10 条消息作为局部上下文
s = 10：召回最相似的 10 条已有记忆

所有 LLM 操作均使用 GPT-4o-mini。

2. 由 LLM 选择更新操作

候选事实和相似旧记忆会一起交给 LLM。

LLM 通过 function calling 判断应该执行以下四种操作中的哪一种：

操作	含义	适用场景
ADD	新增记忆	当前信息是新的，没有等价旧记忆
UPDATE	更新记忆	当前信息补充或修改了已有记忆
DELETE	删除记忆	当前信息明确推翻了已有记忆
NOOP	不执行操作	当前信息重复、无关或无需修改

ADD：新增记忆

已有记忆：

用户的目标岗位是 AI Agent 开发。

新信息：

用户希望优先投递北京的岗位。

两条信息并不冲突，可以新增：

ADD：
用户求职城市优先考虑北京。

UPDATE：更新记忆

已有记忆：

用户计划八月去上海。

新信息：

用户将上海行程改到了九月。

系统可以执行：

UPDATE：
用户计划九月去上海。

DELETE：删除记忆

已有记忆：

用户正在考虑上海的实习。

新信息：

用户已经明确不再考虑上海实习。

旧记忆已经被推翻，因此可以删除。

NOOP：不做处理

已有记忆：

用户本科专业是德语。

新信息：

用户本科读的是德语专业。

两条信息语义基本一致，不需要重复写入。

3. 为什么由 LLM 决定操作？

Mem0 没有额外训练一个四分类器，而是直接利用 LLM 的语义理解和推理能力判断新旧事实之间的关系。

这样做的优势是：

• 不需要额外标注分类数据；
• 可以处理较复杂的语义冲突；
• 能结合对话上下文理解用户意图；
• 容易通过 prompt 和工具定义扩展。

但它也意味着，记忆更新质量较依赖：

• LLM 本身的判断能力；
• 提示词质量；
• 结构化输出稳定性；
• 采样参数；
• 相似旧记忆是否被正确召回。

---

六、用一个完整例子理解 Mem0

假设 Agent 已经保存了两条记忆：

记忆 1：
用户计划在七月集中准备秋招。

记忆 2：
用户正在考虑前往上海进行三个月实习。

随后用户说：

我还是不去上海了，接下来优先留在北京准备秋招。

1. 提取阶段

结合历史摘要和近期消息，系统可能提取出：

候选事实 1：
用户不再考虑上海实习。

候选事实 2：
用户接下来优先留在北京准备秋招。

2. 更新阶段

对于候选事实 1，系统召回：

用户正在考虑前往上海进行三个月实习。

LLM 判断二者冲突，执行：

DELETE：
用户正在考虑前往上海进行三个月实习。

对于候选事实 2，数据库中不存在完全等价的信息，因此执行：

ADD：
用户接下来优先留在北京准备秋招。

最终记忆库变为：

用户计划在七月集中准备秋招。
用户接下来优先留在北京准备秋招。

这个例子体现了 Mem0 和普通向量数据库的区别。

普通向量数据库通常只是：

写入 → 检索

Mem0 增加了一层记忆管理：

提取 → 检索旧记忆 → 判断关系 → 更新记忆

因此，Mem0 不只是一个检索系统，也是一套记忆生命周期管理机制。

---

七、Mem0ᵍ：基于图的长期记忆

Mem0 使用自然语言事实表示记忆，适合直接检索和阅读。

但是，自然语言事实通常是相对独立的。例如：

Alice 住在旧金山。
Alice 在 Acme 公司工作。
Bob 也在 Acme 公司工作。

如果问题是：

谁和 Alice 在同一家公司工作？

系统需要识别三条事实之间的关系。

因此，论文在 Mem0 的基础上提出了 Mem0^g，使用图结构显式表示实体和关系。

论文 Figure 3 展示了 Mem0^g 的整体架构。

图源：Chhikara et al., 2025，Figure 3。

Mem0^g 的流程可以概括为：

自然语言对话
→ 提取实体
→ 生成关系三元组
→ 对齐已有节点
→ 检测和处理冲突
→ 写入知识图谱

---

八、Mem0ᵍ 的图结构定义

Mem0^g 将记忆表示为一个有向标签图：

$$G=(V,E,L)$$

其中：

• V 表示实体节点集合；
• E 表示实体之间的关系边；
• L 表示实体的语义类型标签。

例如：

Alice --lives_in--> San Francisco

可以表示为：

• 节点 Alice，类型为 Person；
• 节点 San Francisco，类型为 City；
• 关系边 lives_in。

每个实体节点还包含三类信息：

1. 实体类型
   例如 Person、Location、Event。

2. 向量表示
   用于语义匹配和相似节点检索。

3. 元数据
   例如创建时间和其他辅助信息。

关系使用三元组表示：

$$r=(v_s,p,v_d)$$

其中：

• v_s 是源实体；
• p 是关系类型；
• v_d 是目标实体。

例如：

(Alice, lives_in, San Francisco)

---

九、Mem0ᵍ 的实体与关系提取

Mem0^g 使用一个两阶段流程，把非结构化对话转换为结构化图。

1. 节点提取器

节点提取器首先从对话中识别重要实体及其类型。

实体可以包括：

• 人物；
• 地点；
• 物品；
• 概念；
• 事件；
• 日期；
• 属性；
• 用户偏好。

例如，对话为：

Alice 计划九月和 Bob 一起去京都旅行。

可能提取出：

Alice：Person
Bob：Person
Kyoto：City
September：Time
Travel：Event

节点提取不仅是普通的命名实体识别，还需要判断哪些信息具备未来的记忆价值。

2. 关系生成器

关系生成器分析实体之间的语义联系，并生成关系三元组。

例如：

(Alice, travels_with, Bob)
(Alice, plans_to_visit, Kyoto)
(Travel, happens_in, September)

关系生成器既可以识别明确表达的关系，也会结合上下文和一定的领域知识判断隐含联系。

这种显式关系表示更适合处理：

• 多实体查询；
• 人物关系；
• 时间变化；
• 事件顺序；
• 关系型多跳推理。

---

十、Mem0ᵍ 如何更新图记忆？

新关系三元组到来后，Mem0^g 需要将它合并到已有图中。

1. 实体对齐

对于新三元组中的源实体和目标实体，系统分别生成 embedding，并查找语义相似度超过阈值的已有节点。

根据检索结果，可能出现三种情况：

1. 两个实体都不存在：创建两个新节点；
2. 只有一个实体存在：复用旧节点，创建另一个节点；
3. 两个实体都存在：直接复用已有节点。

随后，系统在相应节点之间建立新的关系边。

2. 冲突检测

新关系可能与已有关系发生冲突。

例如，图中已有：

Alice --lives_in--> London

新对话出现：

Alice 现在搬到了 Paris。

系统需要判断：

• 这是对原关系的补充；
• 还是用户当前状态已经发生变化。

3. Update Resolver

Mem0^g 使用基于 LLM 的 update resolver 处理关系冲突。

值得注意的是，系统不会直接物理删除被替代的关系，而是将旧关系标记为失效。

例如：

Alice --lives_in--> London
状态：invalid

Alice --lives_in--> Paris
状态：active

这样做可以保留历史轨迹，支持时间推理。

如果用户询问：

Alice 以前住在哪里？

系统仍然可以利用失效的历史关系回答。

---

十一、Mem0ᵍ 的双路召回

Mem0^g 使用两种互补的检索策略。

1. 以实体为中心的召回

系统首先从查询中识别关键实体，然后在图中找到对应节点。

接着，沿这些节点的入边和出边扩展，构建相关子图。

例如，查询是：

Alice 现在住在哪里，她和谁在同一家公司工作？

系统可以定位 Alice 节点，再沿关系扩展：

Alice --lives_in--> Paris
Alice --works_at--> Acme
Bob --works_at--> Acme

这种方式适合：

• 查询中存在明确实体；
• 需要沿关系寻找相关信息；
• 需要进行图路径推理。

2. 基于语义三元组的召回

系统还会把整个查询编码成向量，并与图中关系三元组的文本表示计算相似度。

例如，将三元组转化为文本：

Alice lives in Paris

再与查询进行语义匹配。

这种方式适合：

• 查询中没有完全一致的实体名称；
• 用户使用了别名或指代表达；
• 查询更加概念化；
• 单纯实体匹配无法覆盖需求。

两路检索结合后，Mem0^g 既可以处理精确实体查询，也可以处理更模糊的自然语言问题。

---

十二、Mem0 与 Mem0ᵍ 的区别

维度	Mem0	Mem0g
记忆表示	自然语言事实	有向实体关系图
核心流程	提取候选事实并执行增、改、删	实体抽取、关系生成和图更新
检索方式	向量相似度检索	实体扩展 + 三元组语义检索
优势	简单、快速、token 成本较低	显式建模实体关系和状态变化
更适合	单跳事实、普通多跳、低延迟场景	时间推理、关系密集型查询
代价	隐式关系表达能力有限	图构建、存储和检索成本更高

需要注意的是：

Mem0^g 并不是在所有任务上都一定优于 Mem0。

图结构只有在关系信息真正重要时才可能带来明显收益。对于简单事实检索，额外的实体和关系结构反而可能引入冗余。

---

十三、实验设置

1. 数据集：LoCoMo

论文使用 LoCoMo 评估长期对话记忆能力。

LoCoMo 包含：

• 10 组长期对话；
• 每组约 600 个对话单元；
• 每组平均约 26000 tokens；
• 对话分布在多个 session 中；
• 每组平均约 200 个问答问题。

问题主要分为四类：

1. Single-Hop
   答案可以从一个对话片段中直接找到。

2. Multi-Hop
   需要组合分散在多个 session 中的事实。

3. Temporal
   需要理解事件的时间、顺序或持续时间。

4. Open-Domain
   除对话记忆外，还可能需要结合外部常识。

原数据集还包含 adversarial 问题，但论文没有纳入这一类别，因为缺少可直接用于本文评估的标准答案。

2. 评测指标

论文同时评估回答质量和部署效率。

回答性能指标

• F1
• BLEU-1
• LLM-as-a-Judge

F1 和 BLEU-1 主要衡量词汇重合，但不一定能准确判断事实是否正确。

例如，标准答案是：

Alice 出生于三月。

模型回答：

Alice 出生于七月。

两句话的大部分词都相同，因此词汇指标可能较高，但核心事实明显错误。

因此，论文加入 LLM-as-a-Judge，从以下维度综合判断答案：

• 事实准确性；
• 相关性；
• 完整性；
• 上下文适当性。

由于 LLM Judge 具有一定随机性，论文对每种方法执行 10 次评估，并报告均值和标准差。

部署指标

论文还统计：

• 召回内容的 token 数；
• 搜索延迟；
• 总响应延迟；
• p50 延迟；
• p95 延迟；
• 长期记忆存储规模；
• 记忆构建和可用时间。

其中：

• p50 可以理解为中位数延迟；
• p95 反映较慢请求的尾部延迟，更适合衡量在线系统稳定性。

3. 对比方法

论文将 baseline 分为六类。

LoCoMo 已有方法

• LoCoMo；
• ReadAgent；
• MemoryBank；
• MemGPT；
• A-Mem。

开源记忆系统

• LangMem。

普通 RAG

论文将完整对话切分为不同大小的 chunk：

128、256、512、1024、2048、4096、8192 tokens

并分别召回 Top-1 或 Top-2 个 chunk。

全上下文方法

直接把平均约 26000 tokens 的完整对话交给模型。

专有模型记忆

使用 OpenAI 的记忆功能生成用户记忆，再用于问答。

Memory Provider

• Zep。

---

十四、不同问题类型上的实验结果

论文 Table 1 比较了各记忆系统在四类问题上的表现。

表源：Chhikara et al., 2025，Table 1。

1. 单跳问题

单跳问题只需要定位一个对话片段中的事实。

Mem0 的结果为：

F1：38.72
BLEU-1：27.13
Judge：67.13

Mem0^g 的结果为：

F1：38.09
BLEU-1：26.03
Judge：65.71

Mem0 略高于 Mem0^g。

这说明对于简单事实检索，自然语言记忆已经足够有效，图结构没有带来明显收益，反而可能因为额外关系信息增加噪声。

2. 多跳问题

多跳问题需要整合分散在多个会话中的事实。

Mem0 的结果为：

F1：28.64
BLEU-1：21.58
Judge：51.15

Mem0^g 的结果为：

F1：24.32
BLEU-1：18.82
Judge：47.19

这个结果比较值得注意。

直觉上图结构应该更适合多跳推理，但实验中 Mem0 反而表现更好。

论文认为，自然语言记忆已经能够保存相对丰富的上下文，而图结构在复杂信息整合中可能带来额外冗余和检索开销。

这说明：

图结构是否有用，不只取决于问题是否需要多跳，还取决于实体和关系抽取是否完整，以及召回路径是否覆盖真正需要的事实。

3. 开放域问题

在开放域问题中，Zep 的表现最好：

F1：49.56
BLEU-1：38.92
Judge：76.60

Mem0^g 紧随其后：

F1：49.27
BLEU-1：40.30
Judge：75.71

Mem0 为：

F1：47.65
BLEU-1：38.72
Judge：72.93

因此，不能简单地说 Mem0 和 Mem0^g 在所有类型上都超过全部 baseline。

在开放域问题上，Zep 仍然略有优势。不过 Mem0^g 和它的差距很小，说明图结构对于整合对话关系和外部知识具有一定帮助。

4. 时间推理问题

Mem0^g 在时间推理中表现最好：

F1：51.55
BLEU-1：40.28
Judge：58.13

Mem0 为：

F1：48.93
BLEU-1：40.51
Judge：55.51

图结构能够显式保存：

• 事件之间的关系；
• 实体状态变化；
• 关系创建时间；
• 已失效的历史关系。

因此，在涉及事件顺序、状态变化和时间条件的问题中，Mem0^g 的优势更明显。

---

十五、跨类型分析：图记忆并非越复杂越好

Mem0 和 Mem0^g 的实验揭示了一个重要结论：

记忆结构应该和问题类型匹配，而不是越复杂越好。

可以总结为：

问题类型	更有优势的方法	可能原因
单跳	Mem0	直接检索自然语言事实更简单
多跳	Mem0	自然语言记忆保留了更完整的语义
开放域	Zep / Mem0g	结构化关系有助于知识整合
时间推理	Mem0g	图结构能够表示关系变化和历史状态

Mem0 更像一种紧凑的事实记忆系统。

Mem0^g 则更像一种关系型和时序型记忆系统。

因此，在实际项目中，不一定需要默认启用图记忆。更合理的方案可能是：

• 普通偏好和事实使用自然语言记忆；
• 人物关系、任务依赖和状态变化使用图记忆；
• 根据查询类型选择不同召回路径。

---

十六、Mem0、RAG 和全上下文的比较

论文 Table 2 同时比较了回答质量、搜索延迟、总延迟和输入 token 数。

表源：Chhikara et al., 2025，Table 2。

1. 和普通 RAG 相比

不同 RAG 配置中，最好的 LLM Judge 分数约为：

60.97

Mem0 达到：

66.88

Mem0^g 达到：

68.44

相较最佳 RAG：

• Mem0 的相对提升约为 10%；
• Mem0^g 的相对提升约为 12%。

原因在于，普通 RAG 检索的是固定长度的原始文本块，其中可能包含大量无关信息。

Mem0 检索的则是已经抽取和整理过的显著事实。

可以理解为：

普通 RAG：
问题 → 检索原始对话片段 → 模型自行寻找关键事实

Mem0：
问题 → 检索已经提炼的长期记忆 → 模型直接使用

因此，Mem0 的召回上下文通常更紧凑，也更加聚焦。

2. 和全上下文相比

全上下文方法的 Judge 分数最高：

72.90

Mem0^g 为：

68.44

Mem0 为：

66.88

这说明在平均约 26000 tokens、且模型窗口能够完整容纳对话的情况下，全上下文保留了最多原始信息，因此回答质量略高。

但是，它的部署成本明显更大。

全上下文的总 p95 延迟为：

17.117 秒

Mem0 的总 p95 延迟为：

1.440 秒

Mem0^g 的总 p95 延迟为：

2.590 秒

相较全上下文：

• Mem0 的 p95 延迟降低超过 91%；
• Mem0^g 也显著降低了尾部延迟。

因此，论文并不是证明 Mem0 在绝对准确率上一定超过完整上下文，而是说明：

Mem0 在接近全上下文效果的同时，大幅降低了 token 和延迟成本。

这才是论文标题中“Production-Ready”的核心含义。

---

十七、延迟分析

论文 Figure 4 展示了不同方法的搜索延迟和总响应延迟。

图源：Chhikara et al., 2025，Figure 4。

1. Mem0 的搜索延迟最低

Mem0 的搜索延迟为：

p50：0.148 秒
p95：0.200 秒

总响应延迟为：

p50：0.708 秒
p95：1.440 秒

这使它更适合对响应时间敏感的在线 Agent。

2. Mem0ᵍ 存在额外图检索开销

Mem0^g 的搜索延迟为：

p50：0.476 秒
p95：0.657 秒

总响应延迟为：

p50：1.091 秒
p95：2.590 秒

它比 Mem0 更慢，但仍然明显快于全上下文和部分复杂记忆系统。

额外延迟主要来自：

• 实体定位；
• 图关系扩展；
• 子图构建；
• 三元组语义检索。

因此，Mem0^g 用适度的延迟成本换取了更强的关系和时间建模能力。

3. LangMem 的延迟较高

在论文的实验配置中，LangMem 的搜索延迟为：

p50：17.99 秒
p95：59.82 秒

总 p95 延迟超过 60 秒。

在这一实验环境下，这种延迟很难满足实时交互需求。

不过，这里反映的是论文采用的特定版本和配置，不能直接代表 LangMem 在所有部署方案中的表现。

4. OpenAI 对比需要谨慎理解

论文中的 OpenAI 方案总响应时间较低，但其记忆是提前抽取后整体提供给模型的。

记忆提取过程的成本没有被计入对应的在线延迟指标。

因此，不能只根据最终响应时间，直接认为其端到端记忆系统成本一定更低。

---

十八、Token 消耗与记忆构建成本

论文还分析了不同系统构建长期记忆后的平均存储规模。

方法	每组对话的平均记忆规模
Mem0	约 7000 tokens
Mem0g	约 14000 tokens
完整原始对话	约 26000 tokens
Zep	超过 600000 tokens

1. Mem0 为什么更加紧凑？

Mem0 只保存从对话中提取出的重要事实，而不是完整对话日志。

因此，它可以把约 26000 tokens 的原始对话压缩成约 7000 tokens 的自然语言记忆。

2. Mem0ᵍ 为什么比 Mem0 更大？

Mem0^g 同时保存：

• 实体节点；
• 关系边；
• 元数据；
• 图关系的文本表示。

因此，它的记忆规模大约是 Mem0 的两倍。

3. Zep 为什么占用更多 token？

论文认为，在其测试版本中，Zep 会在多个节点中缓存完整摘要，同时又在边上保存事实，导致同一知识被重复表示。

这说明：

使用图结构并不天然意味着更加节省空间。

图记忆是否高效，还取决于：

• 节点中保存什么；
• 边中保存什么；
• 是否重复保存相同内容；
• 是否为每个节点生成摘要；
• 图关系如何索引。

4. 新记忆多久可以被使用？

论文观察到，在其测试环境中，Zep 新增记忆后，立即检索有时不能获得正确结果，等待数小时后效果才有所改善。

作者推测，这可能与其图构建中的异步 LLM 调用和后台处理有关。

相比之下，论文报告 Mem0^g 的图构建即使在最差情况下也能在一分钟内完成，新记忆可以较快参与后续查询。

这部分属于作者在特定系统版本和实验环境中的观察，不应直接推广到所有后续版本。

---

十九、Mem0 的优势

综合方法和实验，Mem0 具有几个比较突出的优点。

1. 方法简单直接

Mem0 的核心逻辑可以概括为：

从新对话中提取事实
→ 找到相关旧记忆
→ 判断增、改、删或不处理

相比复杂的层级图、强化学习控制器或多 Agent 记忆系统，它的工程逻辑较为清晰。

2. 支持增量处理

Mem0 不需要每次重新处理全部历史，而是随着新交互持续维护记忆库。

3. 显式处理重复和冲突

通过 ADD、UPDATE、DELETE 和 NOOP，Mem0 不只是不断增加记忆，还能够维护记忆的一致性。

4. 召回上下文更加紧凑

相比普通 RAG 返回完整 chunk，Mem0 返回的是已经提炼过的事实，因此可以减少噪声和 token 消耗。

5. 注重生产部署指标

Mem0 并非只追求 benchmark 上的最高准确率，而是在以下指标之间进行权衡：

• 回答质量；
• 检索延迟；
• 总响应延迟；
• token 成本；
• 记忆存储规模；
• 新记忆生效速度。

---

二十、Mem0 的局限性

虽然 Mem0 强调 production-ready，但从方法和实验中仍然可以看到一些局限。

1. 记忆提取依赖 LLM

哪些信息值得保存，由 LLM 根据 prompt 进行判断。

这可能导致：

• 漏掉重要信息；
• 保存不必要内容；
• 把不确定表达写成确定事实；
• 错误理解用户意图。

例如：

用户：
我可能考虑去上海，但还没有决定。

如果模型提取成：

用户决定去上海。

记忆在写入阶段就已经产生错误。

2. 更新决策依赖 LLM 的稳定性

ADD、UPDATE、DELETE 和 NOOP 也由 LLM 判断。

同一组新旧记忆在不同模型或不同采样下，可能得到不同操作。

生产系统通常还需要加入：

• 低温度生成；
• 结构化输出校验；
• 失败重试；
• 操作日志；
• 高风险信息确认；
• 记忆版本管理。

3. Top-s 检索可能漏掉冲突记忆

更新阶段只比较 Top-s 个语义相似的已有记忆。

如果旧记忆和新信息的表述差异较大，就可能无法被召回，也就无法正确更新或删除。

例如：

旧记忆：
用户目前不食用任何动物制品。

新信息：
用户最近恢复了普通饮食。

如果向量检索没有把两者匹配起来，系统可能同时保留相互冲突的信息。

4. 缺少完整的来源和置信度建模

基础 Mem0 主要保存自然语言事实，但论文没有重点建模：

• 信息来自谁；
• 用户是否明确确认；
• 信息置信度；
• 记忆有效期；
• 适用条件；
• 证据来源；
• 是否由模型推断而非用户陈述。

真实系统中，不同记忆的可信程度通常并不相同。

5. Mem0ᵍ 的图抽取可能传播错误

Mem0^g 需要依赖 LLM 完成：

• 实体抽取；
• 类型判断；
• 关系生成；
• 冲突解析。

任何一步出现错误，都可能影响后续图检索。

图结构虽然更可解释，但也可能把抽取错误固化成显式节点和关系边。

6. 实验场景仍然有限

论文主要在 LoCoMo 长期对话问答任务上进行评估。

尚未充分验证：

• 代码 Agent；
• 浏览器 Agent；
• 软件操作 Agent；
• 多模态 Agent；
• 超长期真实用户交互；
• 多 Agent 共享记忆；
• 程序性经验记忆；
• 真实生产环境中的长期稳定性。

---

二十一、未来方向

论文提出了几个后续方向。

1. 降低 Mem0ᵍ 的图操作开销

Mem0^g 的关系表示有助于时间推理，但会增加构建、存储和检索成本。

后续可以进一步优化：

• 实体去重；
• 图索引；
• 子图召回；
• 关系压缩；
• 增量图更新；
• 图节点过期和合并。

2. 构建层级化记忆

未来可以进一步结合：

• 低层原始事件；
• 中层事实记忆；
• 高层用户画像；
• 实体关系图；
• 可复用任务经验。

这样既能保留具体细节，又能支持高层抽象推理。

3. 更接近人类的记忆固化

当前 Mem0 的更新主要是逐条事实级别的增、改、删。

后续可以研究：

• 多条记忆聚合；
• 周期性反思；
• 经验抽象；
• 重要度评估；
• 主动遗忘；
• 记忆巩固；
• 随时间形成稳定用户模型。

4. 扩展到对话之外

未来还可以把 Mem0 扩展到：

• 程序性任务；
• 具身 Agent；
• 工具调用经验；
• 多模态输入；
• 长期任务规划；
• 多 Agent 协作。

---

二十二、和 A-Mem、LightMem、AgeMem、GAM 的区别

方法	关注点	核心问题
A-Mem	动态链接和自进化记忆	记忆如何自动建立关联并演化
LightMem	轻量记忆构建	如何降低 token、API 和时间成本
AgeMem	LTM 与 STM 统一管理	如何让 Agent 学会主动调用记忆工具
GAM	层级图和语义固化	如何隔离临时信息并保护全局记忆
Mem0	生产级事实记忆流水线	如何增量提取、更新并召回长期记忆
Mem0g	图结构长期记忆	如何显式保存实体、关系和状态变化

1. Mem0 和 A-Mem

A-Mem 强调记忆节点之间的动态关联与自进化。

Mem0 更偏向生产系统中的事实生命周期管理：

提取 → 相似记忆检索 → 增改删判断

它的流程更加直接，实现和部署也相对简单。

2. Mem0 和 LightMem

Mem0 关注如何提取、更新和召回记忆。

LightMem 更进一步关注这套流程的运行成本，采用预压缩、主题缓冲和离线更新减少 LLM 调用。

可以理解为：

Mem0：
怎样构建一套可用的长期记忆流水线。

LightMem：
怎样让长期记忆流水线更加轻量和高效。

3. Mem0 和 AgeMem

Mem0 的记忆流程主要由系统预定义，LLM 在更新阶段选择具体操作。

AgeMem 则把长期记忆和短期记忆操作都设计成 Agent 可以主动调用的工具，并通过强化学习学习何时调用。

Mem0：
系统驱动的记忆流水线。

AgeMem：
Agent 策略驱动的记忆决策。

4. Mem0ᵍ 和 GAM

两者都使用图结构，但设计目标不同。

Mem0^g 使用实体—关系图表示事实：

人物 → 关系 → 地点或事件

GAM 使用主题图和事件图构建层级记忆，并通过语义边界控制何时固化。

Mem0 的图增强版本：
强调实体、关系和状态变化。

GAM：
强调局部叙事、全局主题和写入隔离。

---

二十三、我的理解和启发

Mem0 的方法本身并不复杂，但它对实际 Agent 项目很有参考价值。

它给我的最大启发是：

长期记忆并不是把历史文本放进向量数据库，而是要管理信息从产生、提取、冲突判断、更新到召回的完整生命周期。

1. 向量数据库不等于记忆系统

仅仅完成：

文本 → embedding → 向量数据库

只能称为外部存储或检索模块。

真正的记忆系统还需要解决：

• 哪些信息值得保存；
• 相同信息如何去重；
• 新信息如何修改旧信息；
• 冲突信息如何处理；
• 过时信息如何失效；
• 查询时应该返回什么粒度的内容。

Mem0 的四类操作正是在处理这些问题。

2. 全局摘要和近期上下文应该结合

只使用最近消息，可能缺少长期背景。

只使用全局摘要，又可能遗漏最新细节。

Mem0 将两者结合：

长期摘要 + 近期消息 + 最新交互

这种结构可以直接借鉴到自己的 Agent 项目中。

3. 记忆写入前需要冲突检查

自己实现记忆系统时，很容易只做“新增”，不做“更新”和“删除”。

长期运行后，记忆库中会逐渐出现：

• 同义重复；
• 时间冲突；
• 偏好变化；
• 多个状态版本并存；
• 已失效信息仍被召回。

因此，记忆写入不应该只是 append，而应该先召回潜在相关旧记忆，再决定具体操作。

4. 自然语言记忆不一定弱于图记忆

Mem0 在单跳和多跳问题上优于 Mem0^g，说明自然语言本身具有很强的表达能力。

图结构不是越多越好。它更适合：

• 关系明确；
• 实体较多；
• 时间变化重要；
• 需要关系路径推理的场景。

对于普通用户偏好和事实记忆，自然语言记忆可能更加直接和高效。

5. 生产系统不能只看准确率

全上下文方法的 Judge 分数最高，但 token 和延迟成本也最高。

真正部署 Agent 时，还需要同时考虑：

• p50 延迟；
• p95 延迟；
• token 消耗；
• 记忆构建时间；
• 新记忆多久能够生效；
• 数据库规模如何增长；
• 系统是否容易审计和维护。

Mem0 的核心价值就在于，它不是只追求 benchmark 上的最高分，而是在效果和成本之间寻找可部署的平衡。

6. 可以对自己的项目做进一步改造

结合 Mem0 的设计，自己的 Agent 记忆系统可以进一步加入：

1. 从最近交互中提取候选记忆；
2. 使用会话摘要补充长期背景；
3. 混合检索潜在相关旧记忆；
4. 让 LLM 输出 ADD / UPDATE / DELETE / NOOP；
5. 保存每次更新前后的版本；
6. 为记忆增加来源、时间、置信度和作用域；
7. 定期执行去重、合并和过期清理。

如果再结合后续论文，还可以扩展：

• A-Mem 的动态链接；
• LightMem 的主题缓冲和离线更新；
• GAM 的写入隔离；
• AgeMem 的主动工具决策。

---

二十四、总结

本文提出了两种面向长期对话 Agent 的记忆架构：Mem0 和 Mem0^g。

Mem0 采用增量式的两阶段流水线：

1. 提取阶段
   结合全局对话摘要、近期消息和最新交互，从新对话中提取具有长期价值的候选事实。

2. 更新阶段
   为每条候选事实召回语义相似的已有记忆，再由 LLM 选择 ADD、UPDATE、DELETE 或 NOOP 操作。

这种方法避免了把完整历史对话持续塞进上下文，也避免了记忆库只增不减、重复和冲突不断累积的问题。

Mem0^g 在此基础上使用有向标签图保存实体和关系，并通过实体中心召回与三元组语义召回支持更复杂的关系和时间推理。

实验结果表明：

• Mem0 在单跳和多跳问题上表现更好；
• Mem0^g 在时间推理中表现更强；
• Mem0 和 Mem0^g 整体优于多数传统记忆系统和普通 RAG；
• 全上下文方法的回答质量略高，但 token 和延迟成本明显更大；
• Mem0 相比全上下文将 p95 延迟降低超过 91%；
• Mem0^g 用适度额外延迟换取了更强的关系和时间建模能力。

整体来看，Mem0 的核心价值不只在于提出了一种新的记忆表示，而是给出了一套相对完整、容易理解且能够用于生产系统的长期记忆流水线：

从对话中提取重要事实，判断它们与旧记忆的关系，再以新增、更新、删除或忽略的方式持续维护记忆库。

对于 Agent 开发者来说，Mem0 是一个非常适合入门和落地的长期记忆框架。它让“记忆”从简单的向量检索，进一步变成了一个可以持续维护的信息生命周期系统。

---

参考资料

• Chhikara P, Khant D, Aryan S, et al. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv preprint, 2025.
• 代码仓库：https://github.com/mem0ai/mem0