【论文阅读】Agent 记忆机制（33）：MemMachine——以原始对话为真相源的可追溯长期记忆

文章目录

• 前言
• 零、论文基本信息
• 一、背景与问题
• • 1. 上下文窗口不能替代长期记忆
  • 2. 传统 RAG 不完全适合对话记忆
  • 3. LLM 提取可能产生不可逆损失
  • • 信息遗漏
    • 事实漂移
    • 错误累积
  • 4. 多跳问题无法通过一次向量检索解决
• 二、相关工作
• • 1. 基于上下文管理的记忆
  • 2. 基于事实提取的长期记忆
  • 3. 图结构和时序记忆
  • 4. 压缩式观察记忆
  • 5. 记忆操作系统
• 三、记忆类型
• • 1. 短期记忆
  • 2. 情节记忆
  • 3. 语义记忆
  • 4. 程序记忆
  • 5. 情节记忆与语义记忆的区别
• 四、MemMachine 架构总览
• 五、原始 Episode：记忆的真相源
• • 1. 为什么以 Episode 为中心？
  • 2. Ground Truth 的准确含义
• 六、短期记忆
• • 1. 设计动机
  • 2. 主要功能
  • 3. 为什么仍然需要摘要？
• 七、长期情节记忆
• • 1. 句子级索引
  • 2. 元数据继承
  • 3. 来源映射
  • 4. Embedding 生成
  • 5. 存储
• 八、上下文化召回
• • 1. 传统向量检索的问题
  • 2. Nucleus Episode
  • 3. 相邻 Episode 扩展
  • 4. Cluster 重排
  • 5. 去重和时间排序
  • 6. 为什么时间排序很重要？
• 九、Profile Memory
• • 1. 设计动机
  • 2. 保存内容
  • 3. 冲突更新
  • 4. Profile 仍然具有提取风险
• 十、Retrieval Agent
• • 1. 查询路由
  • • 单跳直接查询
    • 单跳多实体查询
    • 多跳依赖查询
  • 2. SplitQuery
  • 3. ChainOfQuery
  • 4. Multi-Query Reranking
  • 5. Retrieval Agent 不是始终必要
• 十一、LLM 在系统中的作用
• • 1. 短期记忆摘要
  • 2. Profile 提取
  • 3. Agent Mode
• 十二、多租户与记忆隔离
• 十三、实验设置
• • 1. 数据集
  • • LoCoMo
    • LongMemEvalS
    • Retrieval Agent 数据集
  • 2. 评价指标
  • 3. 实验环境
  • 4. 对比方法
• 十四、实验结果与分析
• • 1. LoCoMo 结果
  • 2. 与其他记忆系统比较
  • 3. Token 成本
  • 4. Retrieval Agent 结果
  • 5. HotpotQA 的策略差异
• 十五、LongMemEvalS 消融实验
• • 1. 各项优化贡献
  • 2. Retrieval Depth
  • 3. 用户消息偏差修正
  • 4. Context 格式
  • 5. 句子级索引
  • 6. GPT-5-mini 反而优于 GPT-5
  • 7. 成本与准确率
• 十六、方法对比
• 十七、局限性与未来方向
• • 1. 保存原始记录不等于召回原始记录
  • 2. Profile Memory 仍然依赖 LLM
  • 3. 时间推理仍有不足
  • 4. Retrieval Agent 成本较高
  • 5. 基础设施复杂
  • 6. 不支持程序记忆
  • 7. 缺少记忆巩固与遗忘
  • 8. 评测可比性有限
• 十八、我的理解和启发
• • 1. 原始事件应该与派生记忆分离
  • 2. “记忆写得好”不等于“记忆用得好”
  • 3. 对话记忆需要邻域扩展
  • 4. 不同消息角色应该有不同检索权重
  • 5. Agent 检索应该按问题结构选择策略
  • 6. 最高分不一定是最佳部署配置
  • 7. Ground Truth 应该进一步扩展为证据链
  • 8. 记忆系统首先是数据系统
• 十九、总结
• 参考资料

前言

一个长期运行的个性化 Agent，需要记住很多内容：

• 用户有哪些稳定偏好；
• 过去发生过什么；
• 用户曾经做过哪些决定；
• 某个偏好是什么时候改变的；
• 当前问题与哪些历史对话有关。

现在许多 Agent 记忆系统采用的基本流程是：

接收一轮对话
↓
调用 LLM 提取事实
↓
判断新增、更新或删除
↓
只保存提取后的记忆

例如，用户说：

我以前喜欢靠窗座位，但最近因为要经常活动，现在更喜欢过道座位。

经过 LLM 提取后，记忆库可能只剩下：

用户喜欢过道座位。

对于一般的个性化推荐，这条记忆可能已经足够。

但如果用户之后问：

我以前喜欢什么座位？为什么后来改变了？

系统就需要知道：

• 原始偏好是什么；
• 新偏好是什么；
• 偏好什么时候发生变化；
• 用户给出的改变原因是什么。

如果记忆系统只保留最后一次提取结果，那么历史细节和变化过程可能已经永久丢失。

这里存在一个非常重要的架构问题：

Agent 记忆应该只保存模型提取出的结论，还是应该同时保留产生这些结论的原始经历？

MemMachine 选择了后者。

它把原始对话 Episode 作为可追溯的情节记忆保存下来，同时构建：

• 保存近期上下文的短期记忆；
• 保存原始历史记录的长期情节记忆；
• 保存用户稳定特征的 Profile Memory；
• 根据查询复杂度选择检索方式的 Retrieval Agent。

当系统进行回忆时，不只是返回向量最相似的一句话，而是先定位一个核心 Episode，再把它前后的对话一起召回，从而恢复完整语境。

因此，MemMachine 最重要的增量不是增加了一种数据库，而是确立了一个记忆架构原则：

原始情节是事实依据，摘要和用户画像是派生视图；即使派生信息出现错误，系统仍然可以回到原始对话重新验证。

不过，这里的“Ground Truth”也需要谨慎理解。

MemMachine 保存的是“用户或 Agent 当时确实说过什么”，并不代表对话内容一定符合客观世界事实。它保留的是交互记录层面的 Ground Truth，而不是自动验证所有陈述的真实性。

零、论文基本信息

• 论文名称：MemMachine: A Ground-Truth-Preserving Memory System for Personalized AI Agents
• 发表平台：arXiv
• 代码仓库：MemMachine/MemMachine
• 作者信息：Shu Wang、Edwin Yu、Oscar Love、Tom Zhang、Tom Wong、Steve Scargall、Charles Fan

一、背景与问题

1. 上下文窗口不能替代长期记忆

大语言模型只能在有限上下文窗口内处理信息。

一种直接做法是把全部历史对话都放入提示词中，但随着交互不断增加，会出现：

• 输入 Token 持续增长；
• 推理成本不断上升；
• 响应延迟增加；
• 超出模型上下文长度；
• 重要信息被大量无关内容淹没；
• 出现 Lost in the Middle 问题。

即使历史对话还没有超过上下文窗口，全部输入也不一定是最优方案。

Agent 真正需要的不是“看到所有历史”，而是：

在当前问题下，看到足够完整且真正相关的历史。

2. 传统 RAG 不完全适合对话记忆

传统 RAG 通常面向相对静态的文档集合。

一个文档 Chunk 往往具有一定独立语义，例如：

某产品的退款期限为购买后30天。

但对话中的一轮消息经常无法独立理解。

例如：

用户：周六晚上的怎么样？
助手：那家已经订满了。
用户：那就选第二家吧。

如果只检索到：

那就选第二家吧。

系统并不知道：

• 第二家指的是哪家餐厅；
• 讨论的是哪个日期；
• 为什么没有选择第一家；
• 当时有哪些约束条件。

因此，对话记忆的检索单元不能只考虑语义相似度，还需要恢复相邻轮次和原始顺序。

3. LLM 提取可能产生不可逆损失

很多记忆系统会让 LLM 对每轮对话执行：

• 事实提取；
• 去重；
• 冲突判断；
• UPDATE；
• DELETE；
• 摘要合并。

这样做的优点是记忆紧凑，但存在三个风险。

信息遗漏

LLM 可能认为某个细节不重要，没有将其写入记忆。

事实漂移

在多次摘要和更新后，记忆可能逐渐偏离用户最初的表达。

错误累积

如果某次提取发生错误，后续更新又以错误结果作为输入，错误会不断传递。

更严重的是，如果系统没有保存原始对话，这些错误就无法重新审计和修复。

4. 多跳问题无法通过一次向量检索解决

考虑下面的问题：

Acme 公司 CEO 的配偶目前在哪家公司工作？

回答这个问题需要依次找到：

Acme 的 CEO 是谁
↓
CEO 的配偶是谁
↓
配偶目前的雇主是谁

第一次检索前，系统并不知道中间人物的姓名，因此无法提前构造最后一步查询。

论文将这个问题称为 Late Binding：

后续检索需要使用前一步才得到的实体，无法在最开始通过一个完整查询一次性解决。

这不是简单更换 Embedding 模型就能解决的问题，而是信息依赖结构造成的。

二、相关工作

1. 基于上下文管理的记忆

MemGPT 将 Agent 记忆类比为操作系统中的虚拟内存，通过在主上下文和外部存储之间移动信息，扩展模型能够访问的历史范围。

这类方法的价值是将上下文管理变成显式机制，但也会增加：

• 内存调度逻辑；
• 多轮 LLM 决策；
• 延迟；
• 系统实现复杂度。

2. 基于事实提取的长期记忆

Mem0 会从对话中提取事实，并通过 ADD、UPDATE、DELETE 等操作维护长期记忆。

它更适合保存：

• 用户偏好；
• 稳定事实；
• 个人资料；
• 跨会话状态。

但如果把提取结果作为唯一记忆，可能丢失原始表达和完整交互过程。

MemMachine 与 Mem0 的核心区别可以概括为：

Mem0：
原始对话 → LLM提取 → 事实记忆

MemMachine：
原始对话 → 永久保存的情节记忆
↘ 用户画像等派生记忆

3. 图结构和时序记忆

Zep 使用时序知识图谱维护实体关系和事实变化，适合处理：

• 关系演化；
• 时间约束；
• 实体关联；
• 事实版本。

但图结构需要额外的信息抽取、关系构建和维护流程，也会增加工程复杂度。

MemMachine 虽然支持 Neo4j，但论文的核心并不是把所有对话转换成知识图谱，而是保存原始 Episode，并保留句子到原始对话的来源关系。

4. 压缩式观察记忆

Mastra Observational Memory 使用 Observer 和 Reflector 将历史压缩成带时间信息的观察日志，并让这些观察长期保留在上下文中。

它的优点包括：

• 不需要每次进行外部检索；
• 上下文前缀更加稳定；
• 更适合 Prompt Cache；
• 能够大幅压缩工具轨迹。

但压缩后的观察不能完全替代原始记录。

MemMachine 选择另一条路线：

• 用摘要提供整体背景；
• 用检索返回原始 Episode；
• 在需要精确事实时回到原始对话。

5. 记忆操作系统

MemOS 将记忆扩展为跨越文本、KV Cache 和模型参数的统一资源，关注记忆调度、生命周期和跨类型转换。

相比之下，MemMachine 更接近应用层基础设施：

• 通过标准文本 API 工作；
• 不要求访问模型参数；
• 不要求控制 KV Cache；
• 可以连接闭源或开源模型；
• 更容易接入现有 Agent 框架。

三、记忆类型

MemMachine 参考认知科学中的记忆分类，将 Agent 记忆划分为不同层次。

1. 短期记忆

短期记忆保存最近发生的对话，为当前交互提供即时上下文。

适合回答：

我们刚才讨论到哪里？

它具有容量限制，内容超过窗口后会进行摘要和迁移。

2. 情节记忆

情节记忆保存具体交互：

• 谁说了什么；
• 发生在什么时间；
• 属于哪个会话；
• 前后有哪些相关对话。

它适合回答：

我上周具体是怎么说的？

情节记忆承担的是可追溯的历史记录角色。

3. 语义记忆

语义记忆保存从多次交互中概括出的稳定知识。

MemMachine 将其实现为 Profile Memory，例如：

用户偏好素食餐厅。
用户从事金融行业。
用户喜欢简洁、技术化的回答。

它适合回答：

这个用户通常喜欢什么？

4. 程序记忆

程序记忆保存：

• 工具使用方式；
• 工作流步骤；
• 行动策略；
• 可复用技能。

论文讨论了程序记忆，但当前版本的 MemMachine 并没有真正实现程序记忆。

因此，不能将 MemMachine 描述成已经覆盖所有记忆类型的完整认知架构。

5. 情节记忆与语义记忆的区别

两者不是替代关系。

一个个性化 Agent 既需要知道“用户是谁”，也需要在必要时找到“这个结论来自哪次交互”。

四、MemMachine 架构总览

为了理解系统组成，可以先看官方项目文档中的架构图。

图源：MemMachine 官方项目文档。 Agent 可以通过 REST API、Python SDK 或 MCP Server 接入。系统内部包含短期工作记忆、长期情节记忆和个性化语义记忆，并由图数据库和 SQL 数据库提供持久化支持。论文 Figure 1 展示了对应的系统分层。

整体流程可以概括为：

用户与 Agent 产生对话
↓
构建原始 Episode
↓
保存原始内容和元数据
↓
分发到短期记忆、长期情节记忆和 Profile Memory
↓
为句子生成 Embedding
↓
建立句子到原始 Episode 的来源映射
↓
查询时联合召回短期和长期记忆
↓
扩展相邻 Episode
↓
去重、重排并按时间排序
↓
提供给回答模型

系统对外提供：

• REST API；
• Python SDK；
• MCP Server。

底层主要使用：

• PostgreSQL；
• pgvector；
• SQLite；
• Neo4j。

五、原始 Episode：记忆的真相源

1. 为什么以 Episode 为中心？

MemMachine 将每一轮对话组织为一个 Episode。

Episode 不只包含消息文本，还包含：

• Producer：消息来自用户、Agent 还是系统；
• Timestamp：消息产生时间；
• Session ID：所属会话；
• Custom Metadata：业务自定义字段。

例如：

{
"producer": "user",
"timestamp": "2026-08-08T10:20:00",
"session_id": "session_001",
"content": "我最近更喜欢过道座位",
"metadata": {
"category": "travel"
}
}

这里的核心设计是：

后续的句子、Embedding、用户画像和摘要，都不能替代原始 Episode。

原始 Episode 始终保留，用于：

• 事实回查；
• 来源追踪；
• 时间推理；
• 合规审计；
• 重新生成派生记忆。

2. Ground Truth 的准确含义

如果用户说：

太阳围绕地球旋转。

MemMachine 可以准确保存：

用户曾经说过“太阳围绕地球旋转”。

但这不意味着系统验证了这句话符合科学事实。

因此，MemMachine 保存的是：

• 对话事实；
• 交互事实；
• 用户陈述的原始记录。

它不是一个自动事实核验系统。

六、短期记忆

1. 设计动机

最近几轮对话通常与当前问题高度相关，如果每次都进行向量检索，会增加不必要的延迟。

因此，MemMachine 将最近的 Episode 保存在短期记忆中，作为随时可用的工作区。

2. 主要功能

短期记忆会：

• 保留预设数量的近期 Episode；
• 生成会话级压缩摘要；
• 在内容超过窗口后压缩旧内容；
• 将退出短期窗口的 Episode 转入长期记忆。

因此，短期记忆返回的不只有最近对话，还可能包含一份此前内容的摘要。

3. 为什么仍然需要摘要？

MemMachine 强调保存原始记录，并不意味着它拒绝摘要。

它反对的是：

用摘要完全替代原始记录。

摘要可以用于快速提供整体背景，原始 Episode 则用于提供精确证据。

这两者可以形成：

摘要：告诉模型大致发生了什么
原始 Episode：告诉模型具体说过什么

七、长期情节记忆

1. 句子级索引

退出短期窗口的 Episode 会进入长期记忆。

MemMachine 首先使用 NLTK Punkt Tokenizer 将 Episode 划分为句子。

例如：

我以前经常坐靠窗。最近因为腿不舒服，我更喜欢过道座位。

可以拆分为：

句子1：我以前经常坐靠窗。
句子2：最近因为腿不舒服，我更喜欢过道座位。

每个句子分别生成 Embedding。

这样可以避免一条较长消息包含多个主题时，整体向量掩盖其中某个局部事实。

2. 元数据继承

每个句子会继承父 Episode 的：

• 时间戳；
• 消息来源；
• 会话 ID；
• 自定义元数据。

同时，句子拥有唯一标识符。

3. 来源映射

句子不会独立于原始 Episode 存在，而是保留：

句子 → 原始 Episode

的映射。

检索命中句子后，系统可以回到完整对话，而不是只返回一个脱离语境的文本片段。

4. Embedding 生成

每个句子都会生成语义向量，用于近似最近邻搜索。

系统支持可配置的 Embedding 模型，因此可以针对不同领域选择模型。

5. 存储

论文实验环境使用：

• PostgreSQL + pgvector：向量相似度搜索；
• Neo4j：关系存储和遍历；
• SQL：Profile Memory 等结构化信息。

八、上下文化召回

1. 传统向量检索的问题

假设历史对话是：

用户：推荐一家适合周六晚餐的餐厅，要安静一点。
助手：A餐厅环境安静，但周六已经订满。B餐厅还有位置。
用户：那就选第二家吧。

当前问题是：

我最后选择了哪家餐厅？

最相似的句子可能是：

那就选第二家吧。

但它无法独立回答“第二家是谁”。

真正需要返回的是一组连续对话。

2. Nucleus Episode

MemMachine 首先通过句子级向量搜索找到最相关的核心 Episode，论文称为 Nucleus Episode。

假设命中的核心 Episode 是

e

i

e_i

ei​。

3. 相邻 Episode 扩展

系统会额外取出：

• 前一个 Episode；
• 当前核心 Episode；
• 后两个 Episode。

可以表示为：

C

(

e

i

)

=

{

e

i

−

1

,

e

i

,

e

i

+

1

,

e

i

+

2

}

C(e_i)=\\{e_{i-1},e_i,e_{i+1},e_{i+2}\\}

C(ei​)={ei−1​,ei​,ei+1​,ei+2​}

其中：

• $e_i$
• $C(e_i)$

这个窗口不是对整个历史进行固定分块，而是在检索命中后，沿着原始对话顺序恢复局部上下文。

4. Cluster 重排

扩展得到多个 Episode Cluster 后，系统使用 Cross-Encoder 或其他 Reranker 重新评分。

与只对单句话重排相比，Cluster 重排能够评估：

• 核心事实是否相关；
• 前后语境是否能形成完整证据；
• Cluster 是否足以回答当前问题。

5. 去重和时间排序

多个核心 Episode 的相邻扩展可能产生重复内容。

系统会：

完整召回流程对应论文 Figure 2：

用户查询和过滤条件
↓
短期记忆搜索
↓
长期记忆向量搜索
↓
扩展相邻 Episode
↓
去重
↓
重排
↓
按时间排序
↓
返回结果

6. 为什么时间排序很重要？

向量相似度排序只表示“哪条信息更像当前查询”，不表示事情发生的先后顺序。

如果用户偏好发生变化：

2025年：喜欢靠窗座位
2026年：改为喜欢过道座位

仅按相似度返回可能让模型误判当前偏好。

按时间恢复原始顺序，可以帮助回答模型理解：

• 哪个事实更早；
• 哪个事实更新；
• 哪次对话推翻了旧信息。

九、Profile Memory

1. 设计动机

并不是每个个性化问题都需要回查具体对话。

例如：

请按照我喜欢的回答方式解释这个问题。

这时，直接获取用户画像比检索大量历史更加高效。

2. 保存内容

Profile Memory 会提取和维护：

• 用户主动提供的人口属性；
• 稳定偏好和兴趣；
• 跨会话行为模式；
• 职业背景；
• 专业水平；
• 沟通风格。

例如：

用户从事软件开发。
用户偏好简洁回答。
用户熟悉 Python。
用户不喜欢乳制品。

3. 冲突更新

当新信息与已有 Profile 冲突时，系统可以更新用户画像，以反映最近状态。

例如：

旧信息：用户喜欢靠窗座位
新信息：用户现在喜欢过道座位

Profile Memory 可以更新为新偏好，而原始情节记忆仍然保留完整变化过程。

这形成了两层结构：

Profile Memory：当前有效结论
Episodic Memory：结论如何演化

4. Profile 仍然具有提取风险

MemMachine 减少了日常记忆操作中的 LLM 使用，但并没有完全消除 LLM。

Profile Memory 仍然依赖 LLM 提取，因此可能出现：

• 错误推断；
• 把短期行为当成长期偏好；
• 忽略限定条件；
• 更新不及时。

其优势在于：即使 Profile 出错，原始 Episode 仍然存在，可以重新生成和纠正。

十、Retrieval Agent

基础向量检索适合单跳问题，但不适合所有查询。

MemMachine v0.3 因此增加了可选的 Retrieval Agent。

为了理解其工作方式，可以看官方文档中的检索流程图。

图源：MemMachine 官方项目文档。 ToolSelectAgent 会把查询分发到直接检索、并行拆分或迭代多跳检索。论文 Figure 3 给出了简化后的 Tool Tree。

1. 查询路由

ToolSelectAgent 使用一次 LLM 调用，将问题分成三类。

单跳直接查询

例如：

用户喜欢什么座位？

这种问题只需要一次事实查找，直接调用基础 MemMachine 检索。

单跳多实体查询

例如：

Alice、Bob 和 Carol 分别在哪家公司工作？

多个实体互不依赖，可以拆成多个查询并行执行。

系统将其路由到 SplitQuery。

多跳依赖查询

例如：

Acme CEO 的配偶在哪家公司工作？

后一步依赖前一步结果，需要迭代检索。

系统将其路由到 ChainOfQuery。

2. SplitQuery

SplitQuery 会将问题拆分为 2～6 个相互独立的子查询。

例如：

Alice和Bob分别喜欢什么饮料？

拆分为：

Alice喜欢什么饮料？
Bob喜欢什么饮料？

这些子查询通过异步方式并行执行，最后合并证据。

为避免错误拆分，系统要求：

• 每个子查询都能通过单一事实查找回答；
• 不直接拆分比较、排序和差值计算；
• 问题结构不明确时，默认不拆分。

3. ChainOfQuery

ChainOfQuery 用于依赖链问题。

每一轮执行：

使用当前查询检索
↓
判断证据是否充分
↓
如果不足，根据已检索实体重写查询
↓
累积新证据

最多执行三轮。

当证据充分度置信分数达到 0.8 时，可以提前停止。

查询重写只能使用已经出现在检索证据中的实体，避免模型利用外部知识凭空构造下一跳。

4. Multi-Query Reranking

普通 Reranker 只根据原始问题给候选记忆打分。

但在多跳检索中，中间证据可能没有直接出现于原始问题。

因此，MemMachine 会将：

• 原始问题；
• 所有改写问题；
• 所有拆分后的子问题；

拼接起来，作为最终重排查询。

这样，虽然某个 Episode 与原问题不够相似，只要它对某个中间步骤重要，仍然可能获得较高分数。

5. Retrieval Agent 不是始终必要

Agent Mode 会增加：

• 路由 LLM 调用；
• 查询拆分调用；
• 多轮查询改写；
• 更多输入和输出 Token；
• 更高延迟。

因此，它适合：

• 多跳推理；
• 多实体查询；
• 指代消解；
• 合规调查；
• 复杂研究问题。

对于简单偏好查询，直接使用基础检索通常更加划算。

十一、LLM 在系统中的作用

MemMachine 并没有完全去除 LLM，而是限制 LLM 的使用范围。

LLM 主要用于三个地方。

1. 短期记忆摘要

短期窗口溢出时，LLM 生成会话摘要。

2. Profile 提取

LLM 从原始对话中提取用户事实和偏好。

3. Agent Mode

Retrieval Agent 使用 LLM：

• 判断查询类型；
• 拆分问题；
• 判断证据充分性；
• 重写下一跳查询。

MemMachine 不使用 LLM 执行：

• 每条消息的常规事实提取；
• 日常记忆去重；
• 原始 Episode 的保存；
• 常规长期记忆管理。

这正是其降低 Token 成本和减少提取误差的主要原因。

十二、多租户与记忆隔离

生产环境中的记忆系统必须避免不同用户和 Agent 之间的数据串扰。

MemMachine 使用：

org_id / project_id
↓
user_id
↓
agent_id
↓
session_id

建立命名空间。

这样可以实现：

• 不同组织之间隔离；
• 同一组织内不同项目隔离；
• 不同用户记忆隔离；
• 多个 Agent 使用不同记忆；
• 同一用户的多个会话保持关联。

这说明 MemMachine 不只是在论文中设计了一个检索算法，也在尝试解决实际 Agent 基础设施中的部署问题。

十三、实验设置

1. 数据集

LoCoMo

LoCoMo 用于评估超长多会话对话记忆，论文评测包含：

• Single-hop：841 个问题；
• Multi-hop：282 个问题；
• Temporal：321 个问题；
• Open-domain：96 个问题。

共计 1540 个计分问题。

LongMemEvalS

LongMemEvalS 包含 500 个问题，每个问题对应约 115K Token 的聊天历史。

主要评估：

• 单会话用户信息提取；
• 单会话助手信息提取；
• 用户偏好推断；
• 时间推理；
• 知识更新；
• 多会话推理。

Retrieval Agent 数据集

Retrieval Agent 还在以下任务上进行评估：

• HotpotQA Hard；
• WikiMultiHop；
• MRCR；
• EpBench；
• LoCoMo。

2. 评价指标

LoCoMo 使用：

• LLM Judge Score；
• BLEU；
• F1。

主要比较指标为 LLM Judge Score。

LongMemEvalS 同样使用标准 LLM Judge 进行评分，Judge 模型为 GPT-4o-mini。

3. 实验环境

4. 对比方法

主要包括：

• Mem0；
• Zep；
• Memobase；
• LangMem；
• OpenAI 原生记忆基线。

需要注意，部分对比结果来自作者重新运行，部分来自其他系统公开结果。

因此，不同系统之间可能存在：

• Prompt 不同；
• 模型版本不同；
• 预处理不同；
• 数据库设置不同；
• 评测时间不同。

不能把所有分数都理解为完全控制变量下的公平对比。

十四、实验结果与分析

1. LoCoMo 结果

MemMachine 使用不同回答模型和模式的结果如下：

最高总体分数为 GPT-4.1-mini Agent Mode 的 0.9169。

但 Agent Mode 并不是每个类别都更好。

在 GPT-4.1-mini 下：

• Agent Mode 的时间推理更好；
• Memory Mode 的 Multi-hop 和 Open-domain 反而更高。

这说明 Retrieval Agent 的收益与问题类型有关，并不适合无条件开启。

2. 与其他记忆系统比较

论文使用 GPT-4o-mini 配置进行主要横向比较：

MemMachine 的总体分数比第二名 Memobase 高约 9.7 个百分点。

它在：

• Single-hop；
• Multi-hop；

上表现较强。

但在时间推理上，MemMachine 的 0.7352 低于 Memobase 的 0.8505。

这与架构特征一致：

• 原始 Episode 和句子索引有利于事实回忆；
• 相邻 Episode 扩展有利于恢复多轮语境；
• 仅依靠时间戳和排序，还不足以解决所有复杂时间推理。

3. Token 成本

论文在 LoCoMo、GPT-4.1-mini、Memory Mode 下比较 Token 消耗：

MemMachine 的输入 Token 约减少 78%，论文将其概括为约 80%。

但需要注意：

• 减少的是输入 Token；
• MemMachine 的输出 Token 在该设置下反而更多；
• 结果只适用于论文匹配的 LoCoMo 配置；
• 不能直接推导出所有生产任务都能节省 80% 总成本。

MemMachine 成本较低的主要原因是，它不会为每轮消息执行完整的 LLM 事实提取和记忆操作判断。

4. Retrieval Agent 结果

Retrieval Agent 在：

• HotpotQA；
• 随机噪声环境下的 WikiMultiHop；
• MRCR；

上有所提升。

但在：

• LoCoMo；
• GPT-5-mini 下的 EpBench；

没有提升，甚至略有下降。

这支持论文自己的部署结论：

Agent Mode 应该按查询复杂度选择，而不是把所有问题都强制变成多轮 Agent 检索。

5. HotpotQA 的策略差异

HotpotQA Hard 的策略结果如下：

ChainOfQuery 的准确率不是最高，但 Recall 达到 95.31%。

这说明迭代检索确实更容易收集完整的多跳证据，但更多证据不一定自动转化为更高最终回答准确率。

最终结果还会受到：

• 回答模型；
• Prompt；
• 证据组织方式；
• 干扰内容；

影响。

十五、LongMemEvalS 消融实验

1. 各项优化贡献

最值得关注的结论是：

检索阶段的优化整体上比写入阶段的句子切分带来了更大提升。

换句话说，只要底层保存了原始信息，系统效果更大程度取决于能不能正确把信息找回来、组织好并交给模型。

2. Retrieval Depth

在 GPT-5 配置下：

从 20 增加到 30，分数提高 4.2 个百分点；继续增加到 50，性能反而下降。

原因是：

• $k$
• $k$
• 更多记忆不等于更好的记忆。

但 GPT-5-mini 呈现不同趋势：

这说明最佳检索深度不仅与数据集有关，也与下游回答模型有关。

3. 用户消息偏差修正

Assistant 消息通常比用户消息更长，因此：

• 包含更多句子；
• 生成更多 Embedding Key；
• 更容易被向量检索命中。

但在用户记忆任务中，用户自己的陈述往往才是一手事实。

MemMachine 在查询前加入：

user:

前缀，使检索更偏向用户消息，带来 1.4 个百分点提升。

这个结果说明：

对话中不同角色的信息价值并不对称，记忆检索需要感知消息来源。

4. Context 格式

同一批检索结果，使用不同格式提供给回答模型，会产生约 2 个百分点差异。

如果把全部历史简单拼成一堵文本墙，模型很难识别：

• 消息边界；
• 角色；
• 时间；
• 会话关系。

因此，记忆系统不仅要返回正确内容，还要正确组织内容。

5. 句子级索引

句子级 Chunk 带来约 0.8 个百分点提升。

它的作用主要体现在：

• 长消息只包含一个相关句子；
• Episode 同时讨论多个主题；
• 精确信息被其他内容稀释。

不过，它的提升小于检索深度、格式和 Prompt 优化。

6. GPT-5-mini 反而优于 GPT-5

在相同优化 Prompt 下：

GPT-5：0.896
GPT-5-mini：0.922

GPT-5-mini 高出 2.6 个百分点。

论文认为，这可能来自模型与 Prompt 的匹配关系：为直接回答设计的简洁 Prompt 更适合 GPT-5-mini，而 GPT-5 内置的推理行为可能与显式推理指令发生干扰。

因此，不能简单认为更大的模型一定更适合记忆问答。

Prompt、检索结果格式和回答模型需要共同优化。

7. 成本与准确率

最高分为 GPT-5-mini、

k

=

100

k=100

k=100 的 0.930。

但从 0.922 提高到 0.930，只增加 0.8 个百分点，却需要约 3.8 倍输入 Token。

因此，更合理的性价比配置是：

GPT-5-mini + Top-20

它不追求最高绝对分数，但达到了更好的成本与准确率平衡。

十六、方法对比

MemMachine 的定位更适合：

• 需要审计历史的 Agent；
• 个性化助手；
• 医疗、法律和金融场景；
• 跨会话客服；
• 多 Agent 共享记忆；
• 需要回到原始证据的系统。

对于工具调用日志极长、但不要求保留每个原始细节的 Coding Agent，压缩优先方案可能更加合适。

十七、局限性与未来方向

1. 保存原始记录不等于召回原始记录

MemMachine 解决了“数据还在不在”的问题，但没有彻底解决“需要时一定能否找到”的问题。

即使原始 Episode 被完整保存，仍然可能因为：

• Embedding 不匹配；
• Top-k 太小；
• Reranker 判断错误；
• 时间过滤不准确；
• 查询改写失败；

而没有进入回答上下文。

因此，Ground-Truth-Preserving 主要描述存储属性，不代表端到端回答绝对正确。

2. Profile Memory 仍然依赖 LLM

用户画像仍然可能：

• 提取错误；
• 过度概括；
• 忽略时间范围；
• 将短期行为当成稳定偏好。

更完善的系统应该为 Profile 中的每条事实记录：

• 来源 Episode；
• 提取时间；
• 置信度；
• 有效期；
• 最近验证时间；
• 历史版本。

3. 时间推理仍有不足

在 GPT-4o-mini 的 LoCoMo 对比中，MemMachine 的时间推理低于 Memobase。

仅保存时间戳和按时间排序，不能自动解决：

• 相对时间；
• 持续时间；
• 多次更新；
• 周期性事件；
• 模糊时间表达。

未来需要专门的时序索引和查询扩展。

4. Retrieval Agent 成本较高

HotpotQA 中：

• Router 平均约消耗 1049 输入 Token、195 输出 Token；
• ChainOfQuery 总成本可达到约 5732 Token。

虽然最多三轮使成本有明确上限，但对于大量简单查询仍然不划算。

5. 基础设施复杂

MemMachine 可能需要：

• PostgreSQL；
• pgvector；
• Neo4j；
• Embedding 服务；
• Reranker；
• LLM 服务。

对于小型应用，这可能比一个简单的向量库或对话摘要方案更加复杂。

6. 不支持程序记忆

论文讨论了程序记忆，但当前系统主要实现：

• 工作记忆；
• 情节记忆；
• Profile Memory。

尚未真正保存 Agent 的：

• 工具调用策略；
• 成功工作流；
• 可复用技能；
• 操作经验。

7. 缺少记忆巩固与遗忘

保存所有原始 Episode 有利于审计，但数据会持续增长。

当前版本还没有完整解决：

• 低价值记忆淘汰；
• 重复 Episode 合并；
• 冷热数据分层；
• 重要记忆巩固；
• 法规要求下的删除；
• 用户主动纠正和遗忘。

8. 评测可比性有限

论文同时使用：

• 不同模型；
• 不同 Prompt；
• 作者重新运行的结果；
• 其他系统公开结果。

因此，实验能够说明 MemMachine 具有较强效果，但不能把所有提升都归因于单一架构设计。

十八、我的理解和启发

1. 原始事件应该与派生记忆分离

这是我认为 MemMachine 最值得借鉴的设计。

在自己的 Agent 系统中，可以把记忆分成两层：

事实层：
完整保存用户输入、工具输出、时间和任务结果

派生层：
用户画像、摘要、经验、标签和实体关系

派生层负责提高检索和推理效率，事实层负责：

• 回查；
• 审计；
• 修正；
• 重新处理。

不要让一次 LLM 提取成为不可逆的数据转换。

2. “记忆写得好”不等于“记忆用得好”

LongMemEval 消融中：

• 句子切分提升 0.8%；
• 检索深度提升 4.2%；
• 格式优化提升 2.0%；
• Search Prompt 提升 1.8%。

这说明 Agent 记忆系统经常把太多精力放在：

如何提取更漂亮的记忆？

但真正影响回答的可能是：

如何找到正确记忆？
如何恢复上下文？
如何把记忆组织给模型？

因此，评估记忆系统时不应该只看写入后的内容质量，还要分别评估：

• Recall；
• Rerank；
• Context Assembly；
• 最终回答正确率；
• Token 成本。

3. 对话记忆需要邻域扩展

普通 RAG 的 Chunk 通常是预先确定的，而对话中的语义边界可能与消息边界不一致。

MemMachine 的思路是：

先精确定位
↓
再恢复上下文

这个机制可以应用于自己的 Agent：

• 命中一条工具结果后，返回调用它的动作和后续判断；
• 命中一条 Bug 结论后，返回前面的错误日志和后面的修复结果；
• 命中一个用户决定后，返回此前方案比较和限制条件。

4. 不同消息角色应该有不同检索权重

论文发现 Assistant 消息更长，会因为拥有更多句子 Embedding 而获得更多检索机会。

但用户消息往往更接近一手事实。

因此，可以在自己的记忆系统中加入角色感知：

5. Agent 检索应该按问题结构选择策略

不是所有问题都需要多轮 Agent。

可以先进行轻量分类：

简单单跳
↓
直接向量检索

多个独立实体
↓
拆分并行检索

存在依赖链
↓
迭代检索

这比让一个通用 Agent 对所有问题进行无界循环更容易控制：

• Token；
• 延迟；
• 错误范围；
• 最大调用次数。

6. 最高分不一定是最佳部署配置

LongMemEval 中：

Top-100：0.930，9.79M 输入 Token
Top-20：0.922，2.58M 输入 Token

为了 0.8 个百分点增加约 3.8 倍输入 Token，未必适合真实产品。

生产系统应该选择 Pareto 最优点，而不是单纯追求排行榜最高分。

7. Ground Truth 应该进一步扩展为证据链

在实际 Agent 项目中，我会为派生记忆增加如下结构：

{
"memory": "用户现在喜欢过道座位",
"type": "profile",
"valid_from": "2026-03-01",
"source_episode_ids": ["ep_1024", "ep_1088"],
"confidence": 0.92,
"supersedes": "memory_205",
"last_verified_at": "2026-08-08"
}

这样不仅可以回到原文，还能知道：

• 这条记忆来自哪里；
• 替代了哪条旧记忆；
• 当前是否仍然有效；
• 什么时候需要重新验证。

8. 记忆系统首先是数据系统

MemMachine 给我的另一个启发是：

生产级 Agent 记忆不只是 Prompt 工程，也是一套数据基础设施。

需要考虑：

• 数据模型；
• 来源关系；
• 时间；
• 权限隔离；
• 数据删除；
• 索引；
• 冷热分层；
• 版本；
• 审计；
• 成本。

向量数据库只是其中一个组件，不能代表完整的 Agent 记忆系统。

十九、总结

MemMachine 提出了一种以原始对话 Episode 为核心的 Agent 长期记忆架构。

它不依赖 LLM 对每条消息进行事实提取，而是完整保存原始交互，并在此基础上构建：

它的核心创新可以概括为：

先保存原始经历，再优化如何召回；摘要、画像和索引都只是原始情节之上的派生层。

实验中，MemMachine 使用 GPT-4.1-mini 在 LoCoMo 上达到 0.9169；LongMemEvalS 最佳配置达到 0.930；在匹配的 LoCoMo Memory Mode 中，输入 Token 相比 Mem0 减少约 78%。

更重要的是，消融实验表明：

• 检索深度；
• Context 格式；
• Search Prompt；
• 用户查询偏差修正；

带来的提升整体大于句子切分本身。

这说明 Agent 记忆的效果不仅取决于存了什么，还取决于：

• 能否找到；
• 是否恢复完整语境；
• 是否保持时间顺序；
• 如何把证据交给回答模型。

不过，MemMachine 仍然存在检索遗漏、Profile 提取错误、时间推理不足、基础设施复杂和 Agent Mode 成本较高等问题。其跨系统实验也不是完全统一配置，结果需要在具体设置下理解。

我认为这篇论文对实际 Agent 开发最重要的启发是：

不要让模型生成的摘要或事实列表成为唯一记忆。应当保留可追溯的原始事件，并把所有高级记忆视为可以重新生成、修正和审计的派生视图。

记忆系统真正需要保存的，不只是模型认为重要的内容，还包括模型未来可能需要重新理解的证据。

参考资料

• Shu Wang et al. MemMachine: A Ground-Truth-Preserving Memory System for Personalized AI Agents. arXiv.
• MemMachine 代码仓库