记忆系统：通过深度研究实现通用智能体记忆

文章链接：[2511.18423] General Agentic Memory Via Deep Research ↗

Summary#

记忆对于 AI 智能体至关重要，然而当前广泛采用的静态记忆机制（旨在预先创建随时可用的记忆）不可避免地存在严重的信息丢失问题。

为解决这一局限，作者提出了一种名为通用智能体记忆（GAM） 的新型框架。GAM 遵循即时编译（JIT） 原则，专注于在运行时为其客户端创建优化上下文，同时在离线阶段仅保留简单但有用的记忆。

为此，GAM 采用双组件设计：

1）记忆器（Memorizer），通过轻量级记忆突出关键历史信息，同时将完整历史信息保存在通用页面存储中；

2）研究者（Researcher），根据预先构建的记忆，从页面存储中检索并整合有用信息以响应在线请求。

这种设计使 GAM 能够有效利用前沿 LLMs 的智能体能力与测试时可扩展性，同时通过强化学习实现端到端的性能优化。在作者的实验研究中，GAM 在各种基于记忆的任务完成场景中，相较于现有记忆系统取得了显著改进。

概念对照表#

核心设计思路#

记忆系统的任务，是为当前任务构造一个尽可能短，但足够有用的上下文。

换句话说，不要把十万字历史全交给模型，但也不要因为过度压缩而丢失信息。

核心架构#

GAM 分为两层：Memory 层与 Page-store 层。

Memory 层（轻量索引）#

Memory 记录轻量摘要和导航信息，不是完整数据，而是：

• 重要人物
• 重要事实
• 决策
• 任务状态
• 关键事件
• 页面线索
• 可能的关联关系

它承担两个核心功能：

1. 让系统快速理解整体历史
2. 引导 Researcher 知道去哪里搜索

因此，Memory 类似于历史索引或导航地图。

Page-store 层（完整历史仓库）#

Page-store 保存更完整的信息，每一个 page 包括：

{
  "header": "上下文说明",
  "content": "原始 session 内容"
}

header 不是简单标题，而是为当前页面补充必要的语境。

例如，原始内容是：暂时不迁移，先解决兼容问题

加上 header 后变成：

项目：Agent Memory
主题：PostgreSQL 数据库迁移讨论
参与者：用户与后端开发者
阶段：迁移方案评审

这样向量搜索和关键词搜索更容易找到它，使每个页面具有更稳定、更完整的语义。

双 Agent 架构#

GAM 是一个双 Agent 架构：

历史 → Memorizer → Memory + Page-store
                        ↓
问题 → Researcher → 搜索、反思、整合 → 优化上下文

Memorizer（离线阶段）#

Memorizer 负责”离线阶段”的工作。这里的离线指：在没有具体查询请求时，随着历史不断产生，提前完成基础整理。

每来一个新的 session，Memorizer 做两件事：

1. 生成 Memo

根据新 session 和已有的 memory 生成一条新的 memo，加入整体 memory。

这里的设计是：新摘要不是只看当前信息，而是结合已有记忆理解当前信息。

例如用户说：还是之前那个方案

只看当前消息没法理解”之前的那个方案”。因此结合已有 memory，Memorizer 可能知道它指的是 PostgreSQL + pgvector 的存储方案，从而生成更自包含的 memo。

2. Paging（页面归档）

根据 session 和现有 memory 生成 header，再组成页面，放入 page-store。

因此 Memorizer 同时负责：摘要压缩和原文归档。

Researcher（在线阶段）#

Researcher 在用户真正提出请求时启动，执行一个循环：

规划 → 搜索 → 整合 → 检查完整性
                 ↑         ↓
                 └── 不完整 ┘

第一步：Planning（规划）#

Researcher 先不急着搜索，而是分析：要回答这个问题，我具体需要哪些信息？

例如用户问：为什么我们最后放弃了 Redis，改用 PostgreSQL？这个决定是谁提出的？

Researcher 会拆成几个信息需求：

• 最初为什么考虑 Redis？
• Redis 存在哪些问题？
• PostgreSQL 方案有什么优势？
• 最终决定是什么时候作出的？
• 谁提出了切换方案？
• 谁批准或确认了该方案？

这一步本质上是：把一个模糊问题拆成可检索的事实子问题。

第二步：Searching（搜索）#

有三种搜索工具：

1. Embedding / Vector Search

向量化，适合按语义搜索。

例如：关于长期记忆数据库技术选项的讨论，即使页面没有完全相同的关键词，也可能被找到。

2. BM25 / Keyword Search

适合精确关键词，例如：Redis、PostgreSQL、pgvector、数据迁移。

论文实验中，BM25 单独使用的表现明显好于仅使用 embedding，说明在包含大量明确实体、变量名和关键词的历史中，精确词匹配非常重要。

3. Page-ID Retrieval

如果 memory 已经指向某些具体页面，就直接读取对应页面。

例如 memory 中写着：数据库技术选型见: page132、page145，Researcher 可以直接读取这些页面。

为什么需要三种工具？

不同问题需要不同的检索方式：

论文的消融实验显示：

• 只使用一种工具效果较差
• 两种工具组合通常更好
• 三种工具一起使用效果最好

这说明检索问题存在不同匹配模式，单一检索器很难覆盖。

第三步：Integration（整合）#

搜索得到的不是最终答案，而是一批页面。Researcher 需要把它们整合为一个临时结果 I，类似于研究笔记。

例如，第一轮可能得到：

Redis 曾被考虑作为会话缓存；
主要担忧是持久化和复杂查询能力。

第二轮搜索后更新为：

Redis 曾被考虑作为会话缓存，但项目还需要保存长期对话、
用户关系和向量数据，因此 PostgreSQL + pgvector 更适合作为主存储。
该方案由后端负责人提出，并在技术评审中确认。

整合过程不是每轮推导重来，而是在已有研究结果上不断补充和修正。

第四步：Reflection（反思完整性）#

Researcher 检查：当前信息是否足以回答用户的问题？

例如当前结果已经解释”为什么换数据库”，但没有回答”谁提出”，反思模块就会产生一个新查询：搜索首次提出 PostgreSQL 迁移建议的人，以及相关页面，然后开始下一轮。

论文默认最大反思深度为 3，也测试了深度 1 到 5，结果表明允许更多反思通常能提高性能，但提升逐渐变小。

完整流程示例#

假设历史中有以下内容：

Session 1#

我们先用 Redis 存会话，开发速度比较快。

Memorizer 生成：项目初期计划使用 Redis 作为会话存储，以降低开发复杂度。 并保存完整页面。

Session 2#

后面需要复杂查询、用户关系和长期持久化，单靠 Redis 不够。

Memorizer 生成：随着需求扩大，Redis 无法独立满足复杂查询、关系数据和长期持久化需求。 完整 session 仍保存在 page-store。

Session 3#

小王建议改成 PostgreSQL，向量数据先使用 pgvector。

Memorizer 生成：小王建议将主存储迁移到 PostgreSQL，并使用 pgvector 存储向量数据。

用户后来提问#

问：当初为什么不用 Redis 了？是谁建议换数据库？

Researcher 先读轻量 memory，知道：Redis、持久化、复杂查询、PostgreSQL、pgvector、小王。

然后规划搜索：

信息需求：
1. Redis 被放弃的具体原因
2. PostgreSQL 的替代优势
3. 提议者身份

并行执行：

• BM25 搜索 Redis、PostgreSQL、小王
• 向量搜索”数据库架构变更原因”
• 根据 memory 中的页面编号读取相关页面

整合结果后检查：原因、提议者都有了，但决策最终是否采纳还不明确。于是再搜索：PostgreSQL 方案何时被正式确认？

最终输出给 Client Agent 的上下文：

项目最初使用 Redis 以降低开发复杂度，但后续需要复杂查询、
关系数据、长期持久化和向量检索，Redis 无法作为唯一主存储。
小王提出迁移到 PostgreSQL，并使用 pgvector 管理向量数据；
该方案随后在技术评审中被确认。

Researcher 输出的不是直接面向用户的聊天回答，而是给下游 Client Agent 使用的优化上下文，Client Agent 再基于这份上下文组织最终回答。

为什么叫”Deep Research”#

普通 RAG 通常是：

用户问题 → 搜索一次 → Top-K 文档 → LLM 回答

GAM 是：

用户问题
↓
分析信息需求
↓
选择多个工具
↓
第一次搜索
↓
整合证据
↓
判断是否完整
↓
缺什么再搜什么
↓
返回定制上下文

它的关键不是”用了向量库”，而是：检索过程由 Agent 主动控制。所以它更接近一个小型研究 Agent，而不是固定的 RAG pipeline。

AOT vs JIT 的本质区别#

GAM 并没有实现物理意义上的无损压缩，它所谓的 lossless 更准确地说是：原始数据没有因摘要而被删除，因此在理论上仍可重新检索。如果 Researcher 没有搜到正确页面，系统依然会表现为信息丢失。

所以 GAM 解决的是”数据是否还存在”，但不能完全保证：

• 数据是否一定能被找到
• 找到以后是否一定被正确整合

实验在验证什么#

论文提出了三个研究问题：

1. GAM 是否优于现有的记忆系统
2. GAM 在不同任务中表现如何
3. 哪些技术因素影响 GAM

使用了四类数据集：

LoCoMo：长期对话记忆#

考察：

• Single Hop：单条事实问答
• Multi Hop：多个事实组合
• Temporal：时间关系推理
• Open Domain：开放式问题

这比较接近我们通常理解的：Agent 是否记得以前谈过什么。

以 GPT-4o-mini 为例，GAM 在四类任务中都优于其他方法：

• Single Hop F1：57.75
• Multi Hop F1：42.29
• Temporal F1：59.45
• Open Domain F1：33.30

这说明 GAM 不只是找单条事实，在需要组合、时间推理时也相对更强。

HotpotQA：多跳检索#

HotpotQA 要求把分散在多个文档中的事实连接起来。论文使用了 56K、224K、448K 三个上下文长度。

以 GPT-4o-mini 为例，GAM 的 F1 分别为 63.22、64.56、59.81，相比普通 RAG（52.71、51.84、54.01）有显著提升。

普通 Top-K RAG 很容易只找到问题链条中的一半，而 Researcher 可以发现缺口后继续搜索。

RULER：长上下文能力#

包含：Retrieval、Multi-hop Tracing、Aggregation 和 QA。

其中 Multi-hop Tracing 的结果尤为显著，使用 GPT-4o-mini 时：

原因在于 Multi-hop Tracing 不是找到某个相似段落就结束，而是需要沿着多个步骤持续追踪信息。GAM 的多轮规划和检索更适合这种任务。

NarrativeQA：整本书或剧本问答#

平均长度约为 87K，GAM 同样取得最好结果，但领先幅度没有 RULER Multi-hop Tracing 那么夸张——说明对于较开放的叙事理解，检索只是问题的一部分，最终理解和生成能力仍然十分重要。

重要结论#

结论一：长上下文不等于有效记忆#

论文发现，即使模型拥有 128K 上下文，把全部历史直接塞进去，效果仍不一定好。原因包括：

• 干扰信息太多
• 重要事实埋在中间
• 模型注意力被分散
• 长上下文存在 context rot

能装下，不代表能准确使用。

这也是为什么”直接扩大 context window”不能完全取代记忆系统。

结论二：普通 RAG 擅长显式事实#

RAG 在以下场景表现不错：

• 明确实体
• 单条事实
• 相关文本与问题措辞接近

但在以下任务中容易失败：

• 多跳推理
• 变量追踪
• 聚合
• 需要先找到 A，再根据 A 找 B

固定的一次性 RAG 不足以处理复杂记忆查询。

结论三：Researcher 比 Memorizer 更依赖强模型#

论文分别替换了 Memorizer 和 Researcher 的模型大小，结果非常明显：

Memorizer 使用小模型：即使使用 Qwen2.5-0.5B，平均 F1 仍达到 48.83。

Researcher 使用小模型：Qwen2.5-0.5B 时，平均 F1 只有 9.08。

原因是：

• Memorizer 主要做信息抽取和摘要
• Researcher 需要规划、工具选择、搜索、整合和反思

因此工程上可以得到一个非常重要的结论：

便宜的小模型负责写记忆，强模型负责查记忆。

这是一种很实际的模型路由设计。

结论四：更多测试时计算通常能换取更好结果#

论文增加了两类 test-time computation：

1. 最大反思深度
2. 每轮读取的页面数量

通常都能提高效果，但存在边际收益递减。

给 Researcher 更多时间和搜索预算，它更可能补全证据；但简单问题不需要无限搜索。

这与推理模型中的 test-time scaling 思路相似：

更长推理 / 更多候选 / 更多验证
          ↓
通常更高性能，但成本更高

消融实验告诉我们什么#

1. Memory without Research 很差#

只用 memory，不读取 page-store，平均 F1 为 27.50。说明提前生成的压缩记忆会丢失大量细节。

2. Research without Memory 还可以，但不如完整 GAM#

只使用 Researcher，没有轻量 memory，平均 F1 为 48.27；完整 GAM 为 53.18。

说明 page-store 本身已很有价值，但 memory 可以作为：全局地图、查询扩展信息、重要实体清单和页面线索。

三个模块分工明确：

• Page-store 提供事实
• Memory 提供方向
• Researcher 提供搜索能力

三者不能完全互相替代。

3. 返回原始证据可以继续提高性能#

论文比较了三种输出：

说明整合摘要仍可能丢失细节，但直接附带完整页面会明显增加 token 成本。比较合理的折中是：整合结论 + 少量原始证据片段。

效率分析#

GAM 的离线构建速度并不是最快的，在线查询也明显慢于其他记忆系统。

例如在 HotpotQA 56K 中：

448K 时，GAM 在线服务约为 18.49 秒。

因此论文所说的”competitive efficiency”，需要结合效果理解：它不是延迟最低，而是用更高在线计算成本换取明显更高的准确率。

GAM 更适合：

• 深度研究
• 复杂历史问答
• 软件工程 Agent
• 高价值任务
• 对准确性要求高、允许等待十几秒的场景

不一定适合：

• 即时聊天
• 高频低价值请求
• 每秒大量并发请求
• 强实时语音交互

论文的核心贡献#

1. 改变了记忆系统的目标#

过去常见的目标是：如何生成更好的摘要？

GAM 的目标是：如何在任务到来时构造最有用的上下文？

这是从存储中心转向任务中心。

2. 把 Memory 从答案变成索引#

Memory 不应该承担保存全部事实的责任，而应该承担导航责任。因此它可以更短，也不用害怕遗漏所有细节，因为细节仍在 page-store。

3. 把检索从函数升级为 Agent#

传统系统中：

documents = retriever.search(query)

GAM 中更像是：

while not enough:
    needs = planner.analyze(question, current_result)
    plans = planner.choose_tools(needs)
    pages = search(plans)
    current_result = integrate(current_result, pages)
    enough = reflect(question, current_result)

这使检索成为一个可迭代决策过程。

4. 提供了清晰的模型分工#

• 小模型 Memorizer：摘要、标注、页面上下文化
• 强模型 Researcher：规划、搜索、整合、反思

这对实际系统成本控制很有启发。

局限性#

1. 原始数据保留不等于检索无损#

作者强调完整历史保存在 page-store，因此可以避免摘要导致的不可逆损失。但真实系统仍有多个失败点：

问题理解错误
→ 搜索计划错误
→ 关键词选择错误
→ Top-K 没召回正确页面
→ 整合时遗漏
→ 反思误判"信息已经足够"

因此它是”存储层无损”，不是”使用过程严格无损”。

2. 在线成本较高#

GAM 在线查询需要多轮 LLM 调用、多种检索、多页阅读、信息整合、完整性判断，实验中在线耗时达十几秒。

如果用于百万用户产品，必须考虑：并发、token 成本、缓存、超时、最大搜索预算、低价值请求降级策略。

3. Page-store 会持续膨胀#

GAM 保留完整历史，因此随着时间增加：

• 存储量持续增长
• 搜索空间持续增大
• 重复内容变多
• 旧信息与新信息冲突
• 页面之间可能相互矛盾

4. 反思器可能过早停止#

论文使用一个二元判断：enough = true / false，但 LLM 可能在信息不完整时自信地判断”已经足够”。

更稳健的方案可能需要：

• 原子信息需求清单
• 每项证据覆盖检查
• 引用支持度
• 独立 verifier
• 不确定性评分
• 最大搜索预算

5. 实验仍以问答任务为主#

论文覆盖了多个长上下文和记忆 benchmark，但最终任务主要还是查事实、多跳问答、长文本理解。

它尚未充分证明在真实 Agent 任务中同样有效，例如：

• 长期软件开发
• 多轮工具执行
• 浏览器自动化
• 用户偏好长期演化
• 多 Agent 协作
• 错误恢复
• 状态更新和回滚

6. 与更强 Agentic RAG 的比较仍不充分#

论文比较了普通 RAG 和多个记忆系统，但 GAM 本身已经是一个 agentic retrieval system。更有挑战性的基线应包括：

• 多轮迭代 RAG
• query decomposition
• self-RAG
• corrective RAG
• graph-based retrieval
• planner-retriever-verifier pipeline
• 具备反思功能的 deep research agent

否则一部分提升可能来自：

“GAM 是多轮 Agent，而基线是固定单轮流程。“

与普通 Agent 记忆架构的关系#

可以把 Agent 记忆粗略分成四层：

第一层：原始事件日志
Session、Message、Tool Call、Observation

第二层：结构化长期存储
数据库、Page-store、对象、时间、来源

第三层：轻量记忆与索引
摘要、实体、偏好、任务状态、页面引用

第四层：查询时上下文编译
规划、检索、重排、证据整合、反思

许多系统重点做第三层：如何生成更好的长期记忆。

GAM 的主要贡献在强调第四层：

记忆的真正价值，要通过运行时的上下文编译体现出来。