【论文阅读】Agent 记忆机制（26）：Infini Memory——将长期记忆维护成可读写的主题文档

文章目录

前言
零、论文基本信息
一、背景与问题
- [1. 长上下文不等于长期记忆](#1. 长上下文不等于长期记忆)
- [2. 传统原子记忆的问题](#2. 传统原子记忆的问题)
- [3. 单一摘要的问题](#3. 单一摘要的问题)
二、相关工作
- [1. 持久记忆表示与维护](#1. 持久记忆表示与维护)
- - [1.1 外部记忆与上下文管理](#1.1 外部记忆与上下文管理)
  - [1.2 结构化记忆](#1.2 结构化记忆)
- [2. Agent 长期记忆检索与评估](#2. Agent 长期记忆检索与评估)
[三、Infini Memory 方法总览](#三、Infini Memory 方法总览)
四、主题文档表示
- [1. 设计动机](#1. 设计动机)
- [2. 主题文档结构](#2. 主题文档结构)
- - [2.1 文档级元数据](#2.1 文档级元数据)
  - [2.2 层次化正文](#2.2 层次化正文)
- [3. 为什么需要条目级元数据](#3. 为什么需要条目级元数据)
- - [3.1 判断新旧顺序](#3.1 判断新旧顺序)
  - [3.2 保留信息来源](#3.2 保留信息来源)
  - [3.3 支持可追踪修订](#3.3 支持可追踪修订)
五、缓存式记忆写入与固化
- [1. 为什么不在每轮对话后直接更新主题文档](#1. 为什么不在每轮对话后直接更新主题文档)
- [2. CURRENT 缓冲区](#2. CURRENT 缓冲区)
- [3. 何时触发固化](#3. 何时触发固化)
- [4. 从 CURRENT 到 REWRITE_CURRENT](#4. 从 CURRENT 到 REWRITE_CURRENT)
- [5. 更新已有主题或创建新主题](#5. 更新已有主题或创建新主题)
- [6. 文档拆分与合并](#6. 文档拆分与合并)
- - [6.1 拆分大文档](#6.1 拆分大文档)
  - [6.2 合并小文档](#6.2 合并小文档)
- [7. 新记忆尚未固化时能否检索](#7. 新记忆尚未固化时能否检索)
- [8. 完整写入流程](#8. 完整写入流程)
[六、主题文档上的 Agentic Retrieval](#六、主题文档上的 Agentic Retrieval)
- [1. Infini Memory-H：摘要选择 + BM25](#1. Infini Memory-H：摘要选择 + BM25)
- [2. Infini Memory-A：Agent 主动读取记忆](#2. Infini Memory-A：Agent 主动读取记忆)
- [3. 为什么要扩展局部上下文](#3. 为什么要扩展局部上下文)
- [4. 检索什么时候停止](#4. 检索什么时候停止)
- [5. Hybrid 与 Agentic 的区别](#5. Hybrid 与 Agentic 的区别)
七、部署与扩展性
- [1. 使用结构化文本作为默认后端](#1. 使用结构化文本作为默认后端)
- [2. Backend-light 不等于没有成本](#2. Backend-light 不等于没有成本)
- [3. 扩展专业检索后端](#3. 扩展专业检索后端)
八、实验设置
- [1. MemoryAgentBench](#1. MemoryAgentBench)
- [2. 模型与评价方式](#2. 模型与评价方式)
- [3. 对比方法](#3. 对比方法)
- [4. Infini Memory 配置](#4. Infini Memory 配置)
九、主要实验结果
- [1. 四项能力的总体结果](#1. 四项能力的总体结果)
- [2. 为什么主题文档有助于准确检索](#2. 为什么主题文档有助于准确检索)
- [3. Agentic Retrieval 带来的提升](#3. Agentic Retrieval 带来的提升)
- [4. Agentic Retrieval 并非所有子任务都更好](#4. Agentic Retrieval 并非所有子任务都更好)
- [5. 多跳选择性遗忘仍然困难](#5. 多跳选择性遗忘仍然困难)
十、消融实验
- [1. 结构维护消融](#1. 结构维护消融)
- [2. 检索策略消融](#2. 检索策略消融)
- [3. 文档拆分阈值](#3. 文档拆分阈值)
十一、局限性与未来方向
- [1. 跨文档一致性不足](#1. 跨文档一致性不足)
- [2. 文档重写依赖 LLM](#2. 文档重写依赖 LLM)
- [3. Agentic Retrieval 成本较高](#3. Agentic Retrieval 成本较高)
- [4. 扩展性主要是架构描述](#4. 扩展性主要是架构描述)
- [5. 评测范围有限](#5. 评测范围有限)
十二、我的理解和启发
- [1. 长期记忆更像一个持续维护的 Wiki](#1. 长期记忆更像一个持续维护的 Wiki)
- [2. 写入和维护应该解耦](#2. 写入和维护应该解耦)
- [3. 摘要不能替代证据](#3. 摘要不能替代证据)
- [4. 文件系统也可以成为 Agent 的记忆接口](#4. 文件系统也可以成为 Agent 的记忆接口)
- [5. 可以如何应用到自己的 Agent](#5. 可以如何应用到自己的 Agent)
- [6. 与其他记忆方法的联系](#6. 与其他记忆方法的联系)
十三、总结
参考资料

前言

长期运行的 Agent 会不断积累用户偏好、任务事实、工具观察和历史决策。

最直接的做法，是将每次交互提取成独立记忆，再存入向量数据库。用户提出问题时，系统通过语义相似度召回若干条相关记录。

这种方式能够解决基本的"记住和召回"，但随着记忆持续增长，会逐渐暴露出四类问题。

第一类问题是记忆碎片化。

例如，用户可能在不同时间提到：

正在开发代码审查 Agent；
项目使用 Python；
代码仓库托管在 GitHub；
最近准备增加自动修复能力。

如果这些内容被存成四条独立记忆，一次 Top-K 检索未必能将它们全部找回来。即使找到了某一条，也可能缺少理解该信息所需的上下文。

第二类问题是记忆冲突。

例如：

text 复制代码

旧记忆：用户使用 PostgreSQL。
新记忆：项目已经迁移到 MySQL。

如果系统只执行追加写入，两条记录会同时存在。检索阶段可能召回旧信息，也可能将新旧信息一起交给模型，导致 Agent 使用已经失效的配置。

第三类问题是压缩损失。

将大量历史压缩成一条摘要可以节省 Token，但摘要可能丢失：

事实发生的时间；
信息来自用户还是模型；
新旧事实之间的更新关系；
支持结论的原始证据；
局部上下文中的限定条件。

第四类问题是单次检索证据不足。

向量检索或关键词检索通常只返回若干孤立片段，但长期记忆问题经常需要：

查看命中内容的前后文；
搜索同一主题的其他记录；
判断哪一条事实更新；
组合不同位置的证据；
进行多跳推理。

Infini Memory 对这些问题给出了一种很有工程味道的回答：

不再把长期记忆主要表示为一组孤立向量，而是将其维护成一组可读、可编辑、可重写的主题文档。

在写入阶段，新记忆先进入 CURRENT 缓冲文档，积累到一定程度后再统一整理、纠错、拆分和合并。

在读取阶段，Agent 不只执行一次 Top-K 检索，而是像查看文件一样，通过搜索、定位和读取局部行等工具逐步收集证据。

因此，Infini Memory 的核心创新不是某一种新的相似度算法，而是重新定义了长期记忆的基本维护单元：

记忆不是孤立事实的集合，而是一组需要持续修订的主题文档。

零、论文基本信息

论文名称：Infini Memory: Maintainable Topic Documents for Long-Term LLM Agent Memory
发表平台：arXiv，2026
代码仓库：infinigence/Infini-Memory
作者信息：Suozhao Ji、Baodong Wu、Zehao Wang、Lei Xia、Qingping Li、Ruisong Wang、Wenbo Ding、Zhenhua Zhu、Boxun Li、Guohao Dai、Yu Wang；作者来自 Infinigence AI、清华大学和上海交通大学

一、背景与问题

1. 长上下文不等于长期记忆

扩展模型上下文窗口，只能增加单次推理可以输入的信息数量，却不能自动解决：

哪些信息应该长期保留；
新事实如何更新旧事实；
相关信息应该如何组织；
已经过期的内容如何处理；
面对问题时应该读取哪些证据。

长期记忆是一种持续存在于模型外部的可编辑状态。

它需要支持三个相互关联的操作：

text 复制代码

Write：将交互中的有效信息写入记忆
Maintain：组织、更新、合并和修订已有记忆
Read：根据当前问题读取足够的相关证据

很多记忆系统重点研究 Write 和 Read，却低估了 Maintain。

Infini Memory 的主要出发点正是：

长期记忆首先是一个生命周期维护问题，其次才是一个相似度检索问题。

2. 传统原子记忆的问题

Mem0、A-MEM 等方法通常将事实或事件表示为比较紧凑的原子记忆。

原子化有明显优势：

每条记忆表达一个明确事实；
容易生成 Embedding；
便于更新和删除单条内容；
可以控制注入上下文的 Token 数量。

但是，原子化也会拆散原本连续的上下文。

例如：

text 复制代码

记忆 1：用户正在开发日志分析 Agent。
记忆 2：该项目使用 Elasticsearch。
记忆 3：当前主要问题是索引成本过高。
记忆 4：用户准备尝试冷热数据分层。

如果只召回记忆 3，模型知道"索引成本过高"，却未必知道它属于哪个项目，以及用户准备采用什么方案。

Infini Memory 并不否定原子记忆，而是将相关原子信息重新组织到同一主题文档中，使检索结果可以向周围扩展。

3. 单一摘要的问题

另一种方案是持续维护一份用户摘要或任务摘要。

这种方法能够减少碎片，但也容易产生两个问题：

文档越来越大，任何更新都可能需要重写大量无关内容；
压缩过程中可能丢失时间、来源和局部证据。

因此，Infini Memory 没有选择"每条事实一个文档"，也没有选择"所有历史一个文档"，而是选择了中间粒度：

text 复制代码

一个主题
  ↓
一份可维护文档
  ↓
文档中保留多条相关事实、时间和来源

主题文档成为记忆维护的边界。

二、相关工作

1. 持久记忆表示与维护

1.1 外部记忆与上下文管理

MemGPT 将有限上下文和外部存储类比为操作系统中的内存层次，通过显式操作在不同存储区域之间移动信息。

MemoryBank 引入长期用户记忆，并借鉴遗忘曲线调整记忆强度。

Mem0 进一步强调事实的提取、更新、合并和删除，并提供图结构版本表达记忆关系。

这些方法证明了外部记忆的有效性，但很多系统仍然以独立事实、摘要或索引片段作为主要存储单元。当证据分散在多次交互中时，后续修订和上下文重建仍然比较困难。

1.2 结构化记忆

HippoRAG-v2、REMem 等方法利用图结构表达实体、事件或记忆之间的关系。

A-MEM 借鉴卡片盒笔记法，将记忆组织成包含属性和动态链接的原子笔记。

LightMem 将记忆处理拆分为感知过滤、短期主题整理和离线长期更新，降低在线维护成本。

Infini Memory 与这些方法的区别在于：

不将向量数据库作为必须组件；
不将知识图作为主要记忆载体；
使用普通文本主题文档作为共享记忆状态；
强调文档的改写、拆分、合并和版本更新；
保留人类可直接检查和编辑的内容。

2. Agent 长期记忆检索与评估

传统记忆检索通常使用：

向量相似度；
关键词匹配；
固定 Top-K；
文档摘要选择。

这类方法效率较高，但一次检索通常只能返回若干候选片段。

REMem 等工作开始让 Agent 主动调用检索工具，通过多轮搜索完成证据组合。

Infini Memory 将这种 Agentic Retrieval 应用于结构化文本记忆：

text 复制代码

搜索整个记忆库
  ↓
定位候选主题文档
  ↓
在文档内精确搜索
  ↓
读取命中位置的前后文
  ↓
检查证据是否充分
  ↓
继续检索或生成答案

在评测方面，LoCoMo 和 LongMemEval 主要关注长期对话中的事实回忆、时间推理和知识更新。

本文使用的 MemoryAgentBench 更强调一个记忆 Agent 在增量交互中的四项能力：

准确检索；
测试时学习；
长程理解；
选择性遗忘。

三、Infini Memory 方法总览

为了说明长期记忆系统中的常见问题，可以先看论文 Figure 1。

图源：论文 Figure 1。

该图总结了记忆碎片、记忆冲突、历史压缩损失和检索证据不足四类问题。

Infini Memory 的整体流程可以分为四个部分：

text 复制代码

用户交互
  ↓
提取候选记忆
  ↓
写入 CURRENT 缓冲文档
  ↓
达到 Token 或时间阈值
  ↓
重写并整理近期记忆
  ↓
更新、新建、拆分或合并主题文档
  ↓
形成可维护的主题文档库
  ↓
Agent 通过工具多轮读取
  ↓
组合证据并回答问题

其中：

主题文档解决记忆应该如何表示；
CURRENT 解决高频写入成本；
Consolidation 解决冲突、碎片和文档膨胀；
Agentic Retrieval 解决单次检索证据不足；
文本后端解决可读性、可编辑性和部署复杂度。

四、主题文档表示

1. 设计动机

主题文档不是简单的对话摘要。

它代表一个相对稳定的维护范围，例如：

用户的饮食偏好；
某个持续开发项目；
一段旅行计划；
某台服务器的配置信息；
某项长期研究任务。

把相关记忆放进同一文档后，系统可以在局部范围内完成：

事实聚合；
新旧信息对比；
冲突修订；
时间排序；
上下文扩展；
文档级检索。

这样避免了两个极端：

text 复制代码

粒度过小：
每个事实都是孤立记录，记忆容易碎片化。

粒度过大：
所有记忆都在一份文档中，更新和检索范围过宽。

2. 主题文档结构

论文 Figure 2 给出了主题文档的基本格式。

图源：论文 Figure 2。

主题文档由文档级元数据和层次化正文组成，每条记忆还保留序号、时间和来源等条目级元数据。

每份主题文档由两部分组成。

2.1 文档级元数据

文档头部包含：

text 复制代码

id
summary
token_count
created_time
update_log
aux

其中：

id：文档唯一标识；
summary：主题文档摘要，也用于文档级路由；
token_count：当前文档大小；
created_time：创建时间；
update_log：文档更新记录；
aux：可扩展元数据。

2.2 层次化正文

正文使用 Markdown 标题和子标题组织记忆：

markdown 复制代码

# 用户的数据库项目

## 技术栈

- <seq=12, time=2026-05-03, source=USER>
  项目最初使用 PostgreSQL。

## 数据库迁移

- <seq=48, time=2026-06-18, source=USER>
  项目已从 PostgreSQL 迁移到 MySQL。

## 当前状态

- <seq=63, time=2026-07-02, source=USER>
  MySQL 迁移已经完成，当前正在优化慢查询。

每条记忆至少具有递增的 seq 序号，还可以包含：

time：内容对应的时间；
source：信息来自用户还是模型；
实体类型；
命名空间；
机器标识；
IP 地址；
敏感级别；
访问权限；
保留策略。

3. 为什么需要条目级元数据

条目级元数据解决了普通摘要难以处理的三个问题。

3.1 判断新旧顺序

当两个事实冲突时，可以根据 seq 和 time 判断哪条信息更新。

例如：

text 复制代码

seq=12：用户使用 PostgreSQL。
seq=48：用户已经迁移到 MySQL。

系统不需要猜测哪条事实更可信，而是可以显式记录后者覆盖前者。

3.2 保留信息来源

source=USER 和 source=AI 可以区分：

用户明确提供的事实；
模型自己生成或推断的信息。

生产级记忆系统不应该将模型推测和用户事实以相同可信度长期保存。

3.3 支持可追踪修订

文档在改写、拆分和合并时，条目元数据会随内容一起移动。

这使系统可以保留：

事实从哪里来；
什么时候写入；
什么时候更新；
被哪条新事实替代；
是否应该删除。

因此，主题文档不是纯自然语言摘要，而是"文本内容 + 可解析元数据"的组合。

五、缓存式记忆写入与固化

1. 为什么不在每轮对话后直接更新主题文档

记忆提取可能每轮交互都会发生，但完整维护不适合每轮都执行。

如果每出现一条新记忆，就立即：

判断属于哪个主题；
扫描已有文档；
检查冲突；
更新摘要；
判断是否拆分；
重写文档；

写入成本会非常高。

而且，连续几轮对话经常围绕同一件事情展开。如果过早固化，系统可能在信息尚不完整时反复修改长期记忆。

因此，Infini Memory 将高频写入和低频维护分开。

2. CURRENT 缓冲区

新提取的记忆首先追加到名为 CURRENT 的缓冲文档。

text 复制代码

新交互
  ↓
提取候选记忆
  ↓
追加到 CURRENT

这个阶段不需要扫描和修改整个主题文档库，因此成本较低。

将近期记忆暂时放在一起还有一个好处：相邻交互通常具有较强的局部连续性。

例如：

text 复制代码

第 1 轮：用户说正在迁移数据库。
第 2 轮：用户补充目标数据库是 MySQL。
第 3 轮：用户纠正说只迁移分析业务。
第 4 轮：用户说明核心交易仍保留 PostgreSQL。

如果每轮立即固化，记忆会经过多次不稳定更新。

先写入 CURRENT，再统一处理，更容易看清完整状态。

3. 何时触发固化

当缓冲区达到 Token 阈值，或者持续时间超过阈值时，系统触发固化：

f l u s h ( C ) = ( ∣ C ∣ ≥ τ t o k ) ∨ ( Δ t ( C ) ≥ τ t i m e ) \mathrm{flush}(C)=\bigl(|C|\geq\tau_{\mathrm{tok}}\bigr)\lor\bigl(\Delta t(C)\geq\tau_{\mathrm{time}}\bigr) flush(C)=(∣C∣≥τtok)∨(Δt(C)≥τtime)

其中：

C C C 表示当前缓冲文档；
∣ C ∣ |C| ∣C∣ 表示缓冲区 Token 数量；
τ t o k \tau_{\mathrm{tok}} τtok 表示 Token 阈值；
Δ t ( C ) \Delta t(C) Δt(C) 表示缓冲区持续时间；
τ t i m e \tau_{\mathrm{time}} τtime 表示时间阈值。

实验中默认 Token 阈值为 5000。

这是一种"容量或时间任一满足就触发"的策略：

交互密集时，由 Token 数量触发；
交互稀疏时，由时间触发；
避免少量新记忆长期停留在缓冲区。

4. 从 CURRENT 到 REWRITE_CURRENT

触发固化后，系统不会直接将 CURRENT 写入长期文档，而是先生成中间结果 REWRITE_CURRENT。

REWRITE_CURRENT 负责：

将局部相关条目归到一起；
删除完全重复的信息；
合并相邻的同类事实；
保留时间和来源元数据；
标记可能更新旧事实的内容；
将近期对话整理成更稳定的候选记忆块。

例如：

text 复制代码

CURRENT：

用户的项目使用 PostgreSQL。
用户准备迁移到 MySQL。
迁移将在下周开始。
用户补充只迁移分析业务。

重写后可能变为：

text 复制代码

主题：数据库迁移

- 当前核心交易仍使用 PostgreSQL。
- 用户计划将分析业务迁移到 MySQL。
- 迁移预计下周开始。

REWRITE_CURRENT 只是固化过程中的中间草稿，不是永久记忆库。

5. 更新已有主题或创建新主题

系统会根据已有文档的 id + summary 目录，判断每个候选记忆块应该：

更新已有主题文档；
创建新的主题文档。

如果新内容扩展已有主题，就插入对应文档的局部位置。

如果新内容修改旧事实，就记录更新关系，并重写受影响的局部上下文。

如果没有匹配的维护范围，就创建新的主题文档。

这里的主题路由和事实更新是一起完成的，因为：

一条记忆应该被写入哪个主题，取决于它未来需要和哪些事实一起维护。

6. 文档拆分与合并

随着长期运行，主题文档库本身也会出现结构问题。

6.1 拆分大文档

实验中，超过 5000 Token 的主题文档会成为拆分候选。

文档过大通常说明：

主题范围过于宽泛；
混入多个子主题；
局部检索会返回过多无关内容；
每次更新需要重写太多文本。

系统会优先按照 Markdown 标题拆分；如果标题结构无法有效拆分，再使用递归降级策略。

6.2 合并小文档

低于 1000 Token 的小文档会根据摘要相似度判断是否应该合并。

小文档过多意味着同一主题可能被错误分散到不同文件中。

合并后，系统还需要刷新：

文档摘要；
Token 数量；
更新时间；
文档目录信息。

7. 新记忆尚未固化时能否检索

可以。

虽然 CURRENT 还没有进入长期主题文档，但检索模块会同时访问：

已固化的主题文档库；
当前的 CURRENT 缓冲区。

这避免了一个常见问题：

text 复制代码

记忆已经提取
  ↓
还没达到固化阈值
  ↓
检索系统暂时读不到

因此，缓冲写入不会牺牲新信息的即时可用性。

8. 完整写入流程

论文 Figure 3 展示了完整过程。

图源：论文 Figure 3。

该图展示了记忆提取、CURRENT 缓冲、REWRITE_CURRENT 重写、主题路由、文档更新、新建、拆分和合并之间的关系。

整体可以总结为：

text 复制代码

交互内容
  ↓
提取结构化记忆
  ↓
追加到 CURRENT
  ↓
达到 Token 或时间阈值？
  ├─ 否：继续追加，同时允许检索 CURRENT
  └─ 是：
       ↓
       生成 REWRITE_CURRENT
       ↓
       去重、整理并标记更新关系
       ↓
       更新已有主题文档或创建新文档
       ↓
       拆分过大文档
       ↓
       合并相关小文档
       ↓
       刷新摘要和元数据
       ↓
       清空 CURRENT

六、主题文档上的 Agentic Retrieval

Infini Memory 提供两种读取方式：

Infini Memory-H：混合检索；
Infini Memory-A：Agentic Retrieval。

1. Infini Memory-H：摘要选择 + BM25

混合检索首先让 LLM 根据文档 id + summary 选择候选主题文档。

与此同时，BM25 会在未被选中的文档分区中进行关键词检索，补充可能遗漏的局部证据。

text 复制代码

用户问题
  ├─ LLM 根据摘要选择候选文档
  └─ BM25 从其他文档中检索相关分区
             ↓
          合并证据
             ↓
          生成答案

这种方式结合了：

摘要层面的语义判断；
BM25 的精确词面召回。

摘要适合定位大致主题，但容易遗漏：

准确数值；
时间戳；
人名；
配置项；
文档正文中的局部细节。

BM25 可以补充这些细粒度信息。

2. Infini Memory-A：Agent 主动读取记忆

Agentic Retrieval 将记忆文档暴露为一组工具。

论文默认提供：

工具	作用
`list_docs`	查看主题文档目录和摘要
`search`	在整个记忆库中执行搜索
`grep`	全局匹配关键词或模式
`grep_doc`	在指定文档中精确搜索
`read_lines`	读取指定行及其局部上下文

Agent 可以根据中间结果决定下一步操作。

例如：

text 复制代码

用户问题：
我的数据库迁移最终采用了什么方案？

Agent：
1. list_docs：找到"数据库项目"主题文档
2. grep_doc：搜索"迁移"
3. read_lines：读取命中位置前后内容
4. 发现"只迁移分析业务"的更新
5. 再搜索"核心交易"
6. 组合两条证据
7. 生成答案

这种读取方式不再假设一次检索就能找到完整答案，而是将记忆读取变成一个短程调查过程。

3. 为什么要扩展局部上下文

关键词或向量命中的通常只是一条片段。

例如，系统命中：

text 复制代码

迁移到 MySQL。

如果只返回这一句，就可能误以为整个项目都迁移到了 MySQL。

读取同一标题下的局部内容后，才能看到：

text 复制代码

仅分析业务迁移到 MySQL；
核心交易仍然保留 PostgreSQL。

因此，Infini Memory 会尽量把片段级结果扩展到最近的完整标题块，而不是只返回命中的一行。

这正是主题文档相较原子记忆的重要优势：

命中的事实周围天然保留了一组相关上下文。

4. 检索什么时候停止

Agentic Retrieval 不会无限调用工具。

检索循环会在以下条件下终止：

Agent 判断证据已经充分；
达到最大工具调用轮数；
达到证据预算；
连续检索没有获得新的有效信息；
触发其他运行限制。

实验中最多允许七轮工具调用。

如果 Agent 最终没有返回足够证据，系统会执行保守的 BM25 补充检索，作为召回率保护。

5. Hybrid 与 Agentic 的区别

图源：论文 Figure 4。

混合检索通过文档摘要选择和 BM25 分区检索一次性构建上下文。

图源：论文 Figure 5。

Agentic Retrieval 让模型多轮调用搜索和文件读取工具，逐步搜索、验证并扩展证据。

两种方式的主要区别是：

维度	Infini Memory-H	Infini Memory-A
检索流程	基本固定	由 Agent 动态决定
工具调用	较少	最多七轮
上下文扩展	预定义分区	根据证据按需展开
推理成本	较低	较高
复杂问题能力	较强	更适合多步证据检查
可预测性	更高	受 Agent 决策影响

七、部署与扩展性

1. 使用结构化文本作为默认后端

Infini Memory 默认使用普通文本文件和词法索引，不强制依赖：

向量数据库；
图数据库；
专用记忆服务；
复杂的数据基础设施。

这种方式带来几个优点：

文档可以直接阅读；
用户或开发者可以手动编辑；
容易进行版本控制；
数据可以在不同环境间迁移；
可以使用普通文件工具调试；
记忆状态不依赖某个特定数据库产品。

官方实现还提供文档的增删改查、用户隔离、统计和操作历史等接口。

2. Backend-light 不等于没有成本

论文特别强调，这种设计应该被理解为：

text 复制代码

Backend-light

而不是：

text 复制代码

Computation-free

虽然系统不要求部署向量或图数据库，但仍然需要：

LLM 提取记忆；
LLM 重写 CURRENT；
LLM 规划主题更新；
定期拆分和合并文档；
Agent 多轮调用检索工具；
LLM 综合最终证据。

因此，Infini Memory 降低的是基础设施复杂度，并不意味着推理 Token、延迟和维护成本一定更低。

3. 扩展专业检索后端

主题文档是共享记忆状态，不代表系统只能使用关键词检索。

可以继续增加：

向量搜索；
知识图遍历；
数据库查询；
权限检查；
敏感信息过滤；
记忆保留策略；
多租户命名空间。

这些能力可以被封装成新的 Agent 工具，而无需改变主题文档这一基础表示。

因此，Infini Memory 的设计更接近：

text 复制代码

主题文档：事实源与维护层
搜索工具：可替换的检索层
Agent：检索策略与控制层

八、实验设置

1. MemoryAgentBench

论文使用 MemoryAgentBench 评估四项能力。

能力	缩写	主要问题
Accurate Retrieval	AR	能否从长历史中准确找回事实
Test-Time Learning	TTL	能否在推理阶段学习新规则
Long-Range Understanding	LRU	能否理解长篇叙事并组合远距离信息
Selective Forgetting	SF	能否使用新事实替代过期信息

具体子任务包括：

单跳文档问答；
多跳文档问答；
LongMemEval 多会话对话；
EventQA 时间事件推理；
多分类；
电影推荐；
小说摘要；
侦探推理；
单跳事实更新；
多跳事实更新。

2. 模型与评价方式

所有方法统一使用：

text 复制代码

主干模型：gpt-5-mini
输入分块：4096 Token
评审模型：gpt-5

系统输出通过 LLM-as-a-Judge 进行二元正确性判断。

这一设置有利于统一比较，但实验结果仍然可能受到：

主干模型能力；
Judge 模型偏好；
提示词设计；
工具调用稳定性；

等因素影响。

3. 对比方法

论文比较了七种基线：

RAPTOR；
MemoRAG；
HippoRAG-v2；
Mem0；
MemGPT；
LightMem；
REMem。

基线使用 MemoryAgentBench 提供的官方集成，并保留各自原有的索引和检索逻辑。

4. Infini Memory 配置

实验中的主要参数为：

text 复制代码

CURRENT 重写阈值：5000 Token 或时间阈值
主题文档拆分阈值：5000 Token
小文档合并候选阈值：1000 Token
Agent 最大工具调用轮数：7
检索回退策略：BM25

九、主要实验结果

1. 四项能力的总体结果

方法	AR	TTL	LRU	SF	Overall
RAPTOR	39.4	35.4	35.5	9.0	29.8
MemoRAG	37.6	45.4	34.4	16.5	33.5
HippoRAG-v2	68.7	38.8	43.2	31.5	45.5
Mem0	35.4	23.2	27.4	14.0	25.0
MemGPT	41.8	40.0	25.6	17.5	31.2
LightMem	49.9	35.4	34.2	17.5	34.2
REMem	51.9	46.6	35.5	20.5	38.6
Infini Memory-H	78.0	48.4	67.8	51.0	61.3
Infini Memory-A	81.2	51.0	68.6	58.0	64.7

Infini Memory-A 的总体得分为 64.7，超过最强基线 HippoRAG-v2 的 45.5，提升 19.2 个百分点。

四项能力上，相比各自最强基线分别提升：

AR：12.5 个百分点；
TTL：4.4 个百分点；
LRU：25.4 个百分点；
SF：26.5 个百分点。

2. 为什么主题文档有助于准确检索

Infini Memory-A 在 AR 上达到 81.2。

其子任务结果包括：

text 复制代码

单跳问答：83.0
多跳问答：79.0
LongMemEval：79.3
EventQA：83.6

主题文档将相关证据放在同一局部上下文中，降低了只命中孤立事实的风险。

Agentic Retrieval 又可以在命中后继续读取前后内容，因此对多跳和时间类问题更有帮助。

3. Agentic Retrieval 带来的提升

Infini Memory-H 总体得分为 61.3，Infini Memory-A 为 64.7。

也就是说，Agentic Retrieval 在相同主题文档表示上增加了约 3.4 个百分点。

最大增益来自 Selective Forgetting：

text 复制代码

Infini Memory-H：51.0
Infini Memory-A：58.0

这是因为选择性遗忘问题需要检查：

哪条事实更新；
新旧记录的时间顺序；
更新后的局部上下文；
不同证据是否仍然一致。

多轮工具调用能够比一次性检索更充分地检查这些信息。

4. Agentic Retrieval 并非所有子任务都更好

在长程理解任务中，Agentic Reader 更适合摘要类问题，而 Hybrid Reader 在部分细节问答上反而更好。

例如 Detective QA：

text 复制代码

Infini Memory-H：78.4
Infini Memory-A：77.2

这反映了两种检索方式的权衡：

Agentic Retrieval 擅长针对性调查；
BM25 分区检索可能获得更广的细节覆盖；
Agent 的主动选择也可能过早缩小搜索范围。

因此，Agentic Retrieval 不应该被简单理解为在所有场景下都优于固定检索。

5. 多跳选择性遗忘仍然困难

Infini Memory-A 在单跳和多跳事实更新上的结果分别为：

text 复制代码

FC-SH：81.0
FC-MH：35.0

两者相差 46 个百分点。

单跳更新通常可以在写入阶段解决：

text 复制代码

旧事实
  ↓
同一主题中出现新事实
  ↓
根据时间和序号覆盖旧事实

多跳更新则可能跨越多个主题文档。

例如：

text 复制代码

文档 A：用户当前使用项目 X。
文档 B：项目 X 原来依赖数据库 Y。
文档 C：数据库 Y 已经被数据库 Z 替代。

如果一次固化只更新其中一份文档，就无法自动保证所有文档之间的一致性。

因此，Infini Memory 目前能够较好地处理文档内部的新旧事实，却仍然缺少跨文档的全局一致性维护。

这是论文最值得注意的限制之一。

十、消融实验

1. 结构维护消融

在 LongMemEval 子集上，保持混合检索不变，移除文档拆分、更新规划和小文档合并后：

text 复制代码

完整 Infini Memory-H：76.0
移除结构维护：69.3

下降 6.7 个百分点。

下降主要集中在：

Knowledge Update；
Multi-session。

这些任务需要整合相隔较远的证据，并正确处理新旧事实。

如果没有结构维护：

相关事实会停留在不同文档；
旧事实和新事实可能同时存在；
文档主题会逐渐变得混乱；
检索阶段需要承担更多一致性推理。

这说明长期记忆的效果不只来自读取策略，写入后的持续维护更加重要。

2. 检索策略消融

在使用相同主题文档的情况下：

检索方式	LongMemEval Accuracy
只根据摘要选择文档	41.7
摘要选择 + BM25	76.0
Agentic Retrieval	79.3

只使用文档摘要时，准确率只有 41.7。

原因是摘要无法保留所有：

准确数值；
人名；
时间戳；
局部条件；
细粒度事件。

加入 BM25 后，准确率提高到 76.0，说明大部分提升来自正文级细粒度检索。

Agentic Retrieval 在此基础上进一步提高到 79.3。

因此，这组实验揭示了一个很重要的结论：

主题文档提供了可维护的记忆结构，但检索仍然必须进入正文，不能只依赖文档摘要。

3. 文档拆分阈值

拆分阈值	文档数量	Accuracy
1000 Token	762	74.0
3000 Token	319	74.3
5000 Token	322	76.0
7000 Token	280	70.7
9000 Token	255	69.7

较低阈值会产生更多小文档，但准确率下降有限。

较高阈值虽然减少了文档数量，却导致准确率明显下降。

这说明：

主题文档过大比主题文档稍微碎片化更危险。

原因是检索系统仍然可以通过摘要和 BM25 找回多个小文档，但如果一份文档同时混入多个不相关子主题，主题路由和局部检索都会受到影响。

默认 5000 Token 略高于实验中的 4096 Token 分块大小，使拆分更像一种防止文档持续膨胀的安全阀。

十一、局限性与未来方向

1. 跨文档一致性不足

当前固化过程主要在单个主题文档内部处理事实更新。

如果一个事实变化会影响多份文档，系统缺少全局依赖传播机制。

未来可以增加：

文档之间的显式引用；
事实 ID；
跨文档更新图；
反向依赖索引；
全局一致性检查 Agent。

2. 文档重写依赖 LLM

记忆提取、重写、主题路由和文档更新均依赖 LLM。

这可能产生：

事实遗漏；
错误合并；
过度概括；
元数据丢失；
将两个不同主题错误合并；
将同一主题拆成多个文档。

论文通过提示词约束模型忠实于原文，并要求保留元数据，但没有完全消除重写错误。

3. Agentic Retrieval 成本较高

Agent 最多可以执行七轮工具调用。

这意味着复杂问题可能产生更多：

LLM 推理 Token；
工具调用延迟；
中间上下文；
检索失败分支。

论文证明了准确率提升，但没有系统报告：

平均工具调用次数；
端到端延迟；
单次查询 Token 成本；
固化成本；
长期存储增长速度。

因此，目前还不能直接判断其生产环境成本是否优于向量数据库方案。

4. 扩展性主要是架构描述

论文强调文本后端便于部署和扩展，但实验主要验证记忆效果，没有充分验证：

百万级主题文档检索；
高并发用户写入；
多进程同时修改文档；
分布式存储一致性；
大规模权限管理；
文档版本冲突；
故障恢复。

因此，"可扩展"更多指架构容易增加新工具，而不是已经证明具有大规模服务性能。

5. 评测范围有限

论文只使用 MemoryAgentBench，并统一采用 gpt-5-mini 作为主干模型。

未来还需要验证：

不同规模和类型的模型；
长期工具调用 Agent；
软件工程 Agent；
多模态记忆；
真实用户长期交互；
数月或数年的持续运行；
更严格的隐私和删除要求。

十二、我的理解和启发

1. 长期记忆更像一个持续维护的 Wiki

Infini Memory 给我的最大启发是：

Agent 长期记忆不一定要从数据库结构出发，也可以从"可维护文档"出发。

主题文档很像一个由 Agent 自动维护的个人 Wiki：

每个主题有独立页面；
页面内部保留多个事实；
新事实可以修订旧内容；
页面过大时拆分；
页面过小时合并；
查询时可以先看目录，再进入正文。

这种表示非常适合需要人工检查的 Agent。

2. 写入和维护应该解耦

很多 Agent 在每轮对话结束后立即执行复杂的长期记忆更新。

这会导致：

写入延迟高；
LLM 调用次数多；
相邻事实被重复处理；
信息尚未完整就过早固化。

Infini Memory 的 CURRENT 设计可以直接应用到实际项目：

text 复制代码

在线阶段：
只提取和追加近期记忆。

异步阶段：
批量去重、纠错、路由和固化。

这与数据库中的 Write Buffer、日志结构存储以及批处理思想比较相似。

3. 摘要不能替代证据

文档摘要适合做目录和初步路由，但不适合作为最终证据。

实验中，摘要检索只有 41.7，加入正文 BM25 后提高到 76.0。

这说明实际 Agent 记忆系统应该区分：

text 复制代码

摘要：帮助找到可能相关的文档
正文：提供准确事实和局部上下文
原始记录：用于验证和审计

不能因为已经生成了摘要，就删除所有原始证据。

4. 文件系统也可以成为 Agent 的记忆接口

现在很多 Agent 已经能够使用：

搜索文件；
列出目录；
匹配文本；
读取指定行；
修改 Markdown。

如果记忆本身就是结构化文档，就可以直接复用这些工具，而不需要为每种记忆后端设计专门接口。

这尤其适合：

个人知识助手；
编程 Agent；
研究 Agent；
本地优先应用；
强调数据可控的企业 Agent。

5. 可以如何应用到自己的 Agent

在自己的 Agent 项目中，可以实现一个简化版本：

text 复制代码

memory/
├── CURRENT.md
├── user_preferences.md
├── active_projects.md
├── environment_config.md
├── failed_attempts.md
└── successful_procedures.md

每条记忆保留：

text 复制代码

seq
time
source
status
supersedes
sensitivity
evidence_id

写入阶段：

text 复制代码

近期交互
  ↓
提取候选事实
  ↓
追加到 CURRENT.md

离线阶段：

text 复制代码

CURRENT 达到阈值
  ↓
去重和冲突分析
  ↓
更新对应主题文档
  ↓
记录替代关系
  ↓
清空 CURRENT

读取阶段：

text 复制代码

先搜索文档目录
  ↓
在候选文档中搜索关键词
  ↓
读取命中位置的完整标题块
  ↓
不足时继续搜索
  ↓
返回带来源的证据

6. 与其他记忆方法的联系

方法	核心思想	与 Infini Memory 的区别
Mem0	事实级写入、更新和删除	以紧凑事实为主要单元
A-MEM	原子笔记与动态关联	更强调记忆链接和自主组织
LightMem	分阶段处理与离线更新	同样解耦在线与离线，但不是以可维护文档为核心
H-Mem	时间语义树与知识图	强调时间演化和多跳关系
REMem	时间感知的情节图与 Agentic Retrieval	图结构是主要记忆载体
Infini Memory	主题文档、缓冲固化和工具化读取	强调文本可维护性和基础设施简化

在我看来，这些方法并不完全冲突。

一个更完整的系统可以采用：

text 复制代码

Infini Memory：
作为可读、可编辑的主题事实源。

Mem0：
管理细粒度事实的写入和删除。

H-Mem 或知识图：
提供跨文档实体关系和多跳索引。

Agentic Retrieval：
决定何时搜索、读取多少以及是否继续检索。

十三、总结

Infini Memory 提出了一种以主题文档为核心的长期 Agent 记忆架构。

它的主要设计包括：

将相关事实、偏好和事件组织到同一主题文档；
为每条记忆保留序号、时间和来源等元数据；
使用 CURRENT 缓冲区处理高频写入；
达到 Token 或时间阈值后统一固化；
通过改写、更新、新建、拆分和合并维护文档库；
让尚未固化的近期记忆仍然可以被检索；
使用摘要选择和 BM25 实现混合检索；
让 Agent 通过文件搜索和行读取工具多轮收集证据；
使用结构化文本作为默认后端，同时允许接入向量和图检索。

实验中，Infini Memory-A 在 MemoryAgentBench 上取得 64.7 的总体得分，相比最强基线提高 19.2 个百分点。

消融实验进一步说明：

主题文档的结构维护贡献大于 Agentic Retrieval 带来的增量；
只根据文档摘要检索远远不够；
BM25 正文检索恢复了大部分细粒度证据；
Agentic Retrieval 能进一步改善复杂证据组合；
过大的主题文档比适度碎片化更加危险。

不过，该方法仍然存在明显限制：

文档重写依赖 LLM；
跨文档事实更新不一致；
Agentic Retrieval 会增加推理成本；
大规模部署能力缺少定量验证；
多跳选择性遗忘得分仍然较低。

这篇论文最值得借鉴的观点是：

长期记忆的核心不是把更多内容存下来，而是让已经存储的内容可以持续组织、修订、检查和重新使用。

从工程角度看，Infini Memory 将 Agent 记忆从"检索数据库"进一步推向了"可维护的外部知识状态"。

这也说明，一个成熟的 Agent 记忆系统至少需要同时考虑：

text 复制代码

如何写入
如何维护
如何读取
如何修订
如何追踪来源
如何处理过期信息

记忆只有能够被持续维护，才有可能真正支持长期运行的 Agent。

参考资料

Suozhao Ji, Baodong Wu, Zehao Wang, et al. Infini Memory: Maintainable Topic Documents for Long-Term LLM Agent Memory. arXiv, 2026.
Infini Memory 官方代码仓库