Harness the Memory: A Holistic Evaluation of Memory Substrates in Memory Agents

论文阅读：Harness the Memory——不同 Agent Memory 到底应该怎么选？

论文标题：Harness the Memory: A Holistic Evaluation of Memory Substrates in Memory Agents
作者：Wei-Chieh Huang, Weizhi Zhang, Yuchen Wu, Yankai Chen, Eric Hanchen Jiang, Wooseong Yang, Yiwei Yang, Henry Peng Zou, Hanrong Zhang, Ying Nian Wu, Haolun Wu, Kai-Wei Chang, Philip S. Yu, Xue Liu, Aylin Caliskan
发表位置：arXiv 预印本，当前版本未标注会议或期刊接收信息
arXiv 编号：2608.15008
原文链接：https://arxiv.org/abs/2608.15008
PDF：https://arxiv.org/pdf/2608.15008
主题：LLM Agent Memory、长期记忆、Memory Substrate、Memory Evaluation、Agent Harness
核心问题：面对向量库、知识图谱、层次树、技能记忆、LoRA、Full Context、KV Cache 等不同记忆形式，究竟哪一种更适合哪种 Agent 场景？

1. 这篇论文到底想解决什么问题？

过去几年关于 Agent Memory 的工作越来越多。

不同工作会采用完全不同的记忆形式，例如：

  • 把历史直接做 embedding，存进向量数据库；
  • 用 BM25 检索历史文本；
  • 把历史整理成 note；
  • 构建知识图谱；
  • 做层次化摘要树；
  • 从历史轨迹中提炼 strategy 或 skill；
  • 直接通过 LoRA 把记忆写进模型参数；
  • 什么都不压缩，直接把全部历史塞进 Context；
  • 或者围绕 KV Cache 保存和恢复历史 episode。

这些方法经常都会在各自论文的 benchmark 上证明自己有效。

问题是：

它们通常并不是在同一个实验条件下比较的。

一个方法可能用 GPT-4，另一个用开源模型；一个在 LoCoMo 上测，另一个在 ALFWorld 上测；有的只报告准确率，有的额外考虑 latency；有的 write 阶段调用大量 LLM，有的完全不调用。

因此，看完大量 Memory 论文之后，仍然很难回答一个很实际的问题：

如果现在真的要设计一个通用 Agent Memory，我到底应该选择什么记忆结构？

论文把这个底层的记忆表示与存储机制称为：

Memory Substrate，记忆基底。

这里的 substrate 不只是“数据库类型”。

它表示：

Agent 的历史信息最终以什么形式被保存、组织，并在之后重新提供给模型。

例如：

历史对话
   ↓
Dense Vector

和：

历史对话
   ↓
实体 / 关系抽取
   ↓
Knowledge Graph

以及：

任务轨迹
   ↓
总结经验
   ↓
Reusable Strategy

实际上对应三种非常不同的 memory substrate。

这篇论文的目标并不是提出第十二种新记忆，而是：

把已有的主要 Memory Substrate 放进同一个 Harness 中，在尽可能一致的条件下进行系统比较。

2. 为什么现有 Agent Memory Evaluation 不够？

作者首先调查了 52 个 2023～2026 年的 Memory-Augmented LLM 系统。

结果发现目前的评估存在三个明显问题。

2.1 Benchmark 高度集中

大约 62% 的 system-benchmark 组合集中在：

  • LoCoMo
  • LongMemEval

这两个以长对话记忆为核心的 benchmark 上。

Agent 真正需要连续执行动作的任务，例如：

  • 环境交互；
  • 多步规划；
  • Code Agent；

相对缺乏系统评估。

也就是说，目前大量 Memory 方法本质上主要回答的是：

“怎样从很长的历史中找到正确事实？”

但 Agent Memory 还存在另一个问题：

“过去的经验应该怎样帮助 Agent 做下一步动作？”

这两个问题并不完全相同。

2.2 大多数论文只关心准确率

作者统计发现：

几乎所有系统都会报告 accuracy，但只有约 21% 的系统报告至少一种 efficiency metric。

而对于真实 Memory 系统来说，下面这些因素同样重要：

写一条 Memory 要多久？
需要调用几次 LLM？
Read 一次 Memory 要多久？
需要读取多少 Token？
Memory 会膨胀到多大？
维护 Knowledge Graph 需要多少成本？
随着历史越来越长，Latency 怎么变化？

一个方法可能准确率高 2%，但一次检索需要几十甚至几百秒。

这种方法是否值得使用，就不能只看准确率。

2.3 Backbone 和 Benchmark 覆盖范围都很窄

调查中的大量工作只使用一个模型，并且约 81% 的系统只使用 GPT 系列模型作为 Backbone。

这样很难判断：

结果好
 ↓
究竟是 Memory 设计好？
还是 Backbone 本身强？

同时，大约一半系统只在一个 benchmark 上测试。

因此作者认为，现在真正缺少的是：

Controlled Evaluation：固定 Harness 中的其他条件，只改变 Memory Substrate。

3. Harness：把 Memory 当成唯一主要变量

论文构建了一个统一的 evaluation harness。

其中所有 Memory 都尽可能使用相同的：

  • Interaction History；
  • Backbone；
  • Prompt；
  • Auxiliary LLM；
  • Benchmark；
  • Metrics。

然后只改变：

Memory Substrate。

整个实验规模可以概括为：

项目 设置
Memory 方法 11 种
Substrate Family 7 类
Backbone 3 个
Benchmark 4 套
Metrics 26 个
任务类型 User-Centric + Agent-Centric

image

【Figure 2（Unified Evaluation Harness 总览图）。重点观察左侧 11 种 Memory 如何被划分为 External / Internal Memory，以及右侧统一的 Write、Read、Manage、Model、Benchmark 与 Evaluation 设置。】

这张图实际上非常重要，因为它展示了整篇论文真正比较的对象：

                      Memory
                         │
            ┌────────────┴────────────┐
            │                         │
     External Memory           Internal Memory
            │                         │
     ┌──────┼──────┐           ┌─────┴─────┐
     │      │      │           │           │
   Vector  Graph  Skill      Weight    Activation
     ...

下面具体来看这 11 种方法。

4. 七类 Memory Substrate

4.1 External Memory 与 Internal Memory

论文首先把 Memory 分成两个大类。

External Memory

Memory 保存在模型外部的数据结构中。

例如：

Vector DB
BM25
Text Record
Knowledge Graph
Tree
Strategy
Skill

使用时通常存在显式过程：

Write
  ↓
External Store
  ↓
Read / Retrieve
  ↓
Context
  ↓
LLM

Internal Memory

Memory 被编码进模型内部。

论文测试两种形式：

Model Weight

以及：

Activation / Context / KV Cache

这类 Memory 不一定需要传统意义上的“从数据库检索”。

5. Flat Index：最简单的检索式 Memory

5.1 M1：Dense Vector

这是最典型的 Vector RAG。

Write 时：

Utterance
   ↓
text-embedding-3-small
   ↓
1536-D Embedding
   ↓
Flat Index

Read 时：

Query
  ↓
Embedding
  ↓
Cosine Similarity
  ↓
Top-k Utterances

整个 Write / Read 过程都不需要额外调用 LLM。

而且没有复杂的 Memory Management：

新 Memory 只会不断 append。

因此 M1 是一种非常简单、便宜的基线。

5.2 M2：Sparse Vector

M2 使用 BM25。

Write：

Utterance
   ↓
Tokenization
   ↓
BM25 Inverted Index

Read：

Query
   ↓
BM25 Score
   ↓
Top-k

同样：

  • 不需要 Auxiliary LLM；
  • 不做 Memory 重写；
  • Memory 单调增长。

它是论文中非常重要的低成本 baseline。

后面会看到：

复杂 Memory 并不总能赢过这样简单的 BM25。

6. Text Record：先做 Gist，再找原文

6.1 M3：Gist Index

M3 对应 ReadAgent 的思想。

它不是直接给每段原文做向量检索，而是先生成一个短摘要：

Page
 ↓
Auxiliary LLM
 ↓
One-sentence Gist
 ↓
Gist Index

例如一整页内容可能被压缩成：

User relocated Tokyo -> SF; ML engineer

Read 时分成两步：

所有 Gist
   ↓
LLM 判断哪些 Page 相关
   ↓
展开对应 Page
   ↓
取回原始文本
   ↓
Final LLM

也就是说：

Gist 本身主要承担索引作用，真正回答问题时仍然可以回到完整原文。

它避免简单 chunk retrieval 完全依赖 embedding similarity，但代价是：

Read 阶段需要 LLM 阅读越来越多的 gist。

因此随着 Memory 越来越长，Read 成本也会明显增长。

7. Structural Memory：给 Memory 加关系

论文测试两种 Structural Memory。

7.1 M4：Evolving Notes

M4 实现的是 A-Mem 风格的 Memory。

每次写入新信息时，LLM 会生成结构化 Note：

Incoming Message
      ↓
Auxiliary LLM
      ↓
Structured Note
 ├── description
 ├── keywords
 └── tags

然后把这个 Note 和已有 Notes 做 embedding similarity，建立语义链接。

Memory 因此不再只是：

Note 1
Note 2
Note 3

而是：

Note 1 ─── Note 4
   │
   └──── Note 8

Read 时首先通过 embedding 找到 Top-k Notes，然后沿 Note 之间的链接继续扩展。

更加重要的是，它还有一个 Evolution Mechanism。

如果新信息显著改变已有信息：

旧 Note
   +
新信息
   ↓
Evolution Detector
   ↓
重写相关 Neighbor Notes

这样可以维持 Memory 的一致性。

8. M5：Dual-Level Graph

M5 对应 LightRAG 风格的 Dual-Level Graph。

它同时维护两种结构：

Knowledge Graph
+
Chunk Vector Index

Write 时：

Input
  ↓
LLM
  ↓
Entity + Relation Extraction
  ↓
Knowledge Graph

例如：

(User)
   │
 lives_in
   ↓
(San Francisco)

同时保存 chunk-level vector。

Read 时则执行 Hybrid Retrieval：

Query
 ├── Knowledge Graph Traversal
 └── Dense Vector Search
             ↓
     Reciprocal Rank Fusion
             ↓
        Retrieved Memory

因此它同时利用：

  • 实体关系；
  • 原始文本的语义相似度。

这也是为什么后面的长对话 factual QA 中，M5 表现非常强。

但这种结构同样意味着：

Entity Extraction、Relation Extraction、Graph Construction 与 Graph Update 都会产生显著成本。

论文后面会看到，M5 经常可以获得很好的准确率，但 latency 也可能是简单方法的几十倍。

9. Hierarchical Memory：M6 Hierarchical Tree

M6 对应 RAPTOR 风格的 Hierarchical Tree。

底层是原始 Memory：

Raw Memory

然后把相似内容聚类并总结：

Raw Entries
    ↓
 Cluster
    ↓
Summary

继续向上重复：

                    High-Level Summary
                         /     \
                    Summary   Summary
                    /   \      /   \
                 Raw   Raw   Raw   Raw

低层保存细节，高层保存抽象信息。

论文采用 collapsed-tree retrieval：

将不同层级的节点放进同一个 Dense Index 中，然后统一进行 Top-k 检索。

因此一次检索可能拿到：

  • 原始 Memory；
  • 局部摘要；
  • 更高层摘要。

值得注意的是，论文的实现采用 Lazy Construction：

Write
 ↓
只进行 Embedding + Append

第一次 Read
 ↓
真正构建 Tree

因此第一次 Read 会承担一次较大的 Tree Build 成本。

10. Refinement Memory：不保存全部经历，而是提炼经验

这一类 Memory 与前面的方法有一个很大的区别。

前面的思路基本都是：

保存经历，然后想办法把经历找回来。

Refinement Memory 更接近：

经历发生之后，先把经历提炼成以后可以复用的东西。

论文测试 M7 和 M8。

11. M7：Distilled Strategies

M7 实现 ReasoningBank 风格的 Strategy Memory。

它主要适用于包含完整 trajectory 的 Agent 任务。

一个任务完成之后：

Trajectory
   ↓
Judge
   ↓
Success / Failure Analysis
   ↓
Distill
   ↓
Reusable Strategy

最终 Memory 中保存的不是整条轨迹，而可能是：

If relocation-related task:
1. identify source
2. identify destination
3. identify time
4. verify updated location

也就是说：

把具体 experience 转换成更加抽象、可复用的 reasoning strategy。

这些 Strategy 再进行 Dense Embedding。

Read 时：

Current Task
   ↓
Dense Retrieval
   ↓
Top-1 Strategy

而 Management 阶段会：

  • 判断轨迹；
  • 合并重复 Strategy；
  • 删除被替代的 Strategy。

因此 M7 是一个很典型的：

Read 少一点
Write 时想得更多

的设计。

12. M8：Skill Bundles

M8 实现 MemSkill 的核心思想。

它并不是把所有经历一条一条保存，而是：

Experiences
    ↓
Clustering
    ↓
Skill Bundles

然后不断：

Summarize
Merge
Prune

从而让 Memory 逐渐变成一组 Skills。

不过论文这里有一个重要实现差异。

原始 MemSkill 使用一个经过 PPO 训练的 controller，在 Read 时选择 Skill。

为了避免：

只有 M8 使用额外 RL Training，导致不同方法的训练成本无法公平比较，

作者把这个 Controller 改成：

Zero-shot LLM Controller。

并且把所有已经 refinement 的 Skill Bundles 放进 Prompt。

所以论文里的 M8：

保留了 MemSkill 的 online skill evolution pipeline，但并不是完全复现原论文的 PPO Controller。

这一点也是论文自己在 Limitations 中明确指出的。

13. Internal Memory：直接把 Memory 放进模型内部

接下来是内部记忆。

14. M9：Adapter Tuning

M9 不再保存可以显式查询的 Memory Record。

它首先从新信息中生成 QA Pair。

例如：

Input:
User moved to San Francisco.

        ↓

Q: Where does the user live?
A: San Francisco.

然后利用这些 QA Pair 训练 LoRA Adapter。

论文使用：

LoRA rank = 8

并采用 answer-only loss。

于是 Memory 最终被写进：

Model + LoRA Adapter

Read 时：

Query
  ↓
Base Model + Adapter
  ↓
Answer

不再存在显式：

Retrieve Top-k Memory

这个阶段。

这带来一个很明显的问题：

Memory 不再容易 inspect。

对于 Test-Time Learning 这类要求明确访问新知识的任务，这种方式的表现并不好。

15. M10：Full Context

M10 是最直接的方案：

什么 Memory System 都不做，把全部历史留下来。

Write：

New Message
     ↓
Append
     ↓
History Buffer

Read：

Full History
+
Current Query
   ↓
LLM

唯一的 Management 是：

超过 Context Window
        ↓
删除最旧内容

它是论文用来衡量：

“完全不压缩历史到底能做到什么程度”

的参考点。

不过在 ALFWorld 和 BigCodeBench-Hard 中，累积历史会超过实验模型的 Context Window。

因此 M10 没有参与两个 Agent-Centric Benchmark 的主比较。

这本身其实也体现了 Full Context 的扩展性限制。

16. M11：Episode-Clustered Re-prefill

M11 基于 EpiCache 思路。

过去的 turn 首先被分成不同 Episode：

Turns
  ↓
Episode Clustering
  ↓
Episode 1
Episode 2
Episode 3
...

每个 Episode 只保留约 25% Token Budget。

Read 时：

Current Query
   ↓
Match Episode Centroid
   ↓
Best Episode
   ↓
Re-prefill
   ↓
Generation

原始 EpiCache 会直接对 KV Cache 做定制化操作。

但是 Qwen3 使用 Hybrid Attention，原论文公开的 custom kernel 无法直接支持。

因此这里的 M11 做了修改：

不直接修改 KV Cache，而是选择整个 utterance，然后重新 prefill 到 Context 中。

因此论文认为它保留了：

Episodic Selection
+
Budget-Constrained Memory

这一核心思想，但 Read-Time 实现与原始 EpiCache 不完全一致。

17. 11 种方法放在一起看

ID Family 方法 Memory 保存什么 Read 方式 需要额外 LLM
M1 Flat Dense Vector 原始文本 + Embedding Dense Top-k 否
M2 Flat Sparse Vector 原始文本 + BM25 Index Sparse Top-k 否
M3 Text Gist Index Gist + 原文 LLM 选 Page 后展开 是
M4 Structural Evolving Notes Structured Notes + Links ANN + Link Expansion 是
M5 Structural Dual-Level Graph KG + Vector Chunks Graph + Vector Hybrid 是
M6 Hierarchical Hierarchical Tree 多层摘要树 Collapsed-tree Top-k 是
M7 Refinement Distilled Strategies 可复用 Strategy Dense Top-1 是
M8 Refinement Skill Bundles Refined Skills Skill Context 是
M9 Weight Adapter Tuning LoRA 参数 直接生成 是
M10 Activation Full Context 完整历史 全量 Context 否
M11 Activation Episode Re-prefill 压缩后的 Episode Episode Matching + Re-prefill 否

18. 实验设计

18.1 三个 Backbone

论文测试：

Qwen3-8B
Qwen3-32B-AWQ
Gemma-4-26B-A4B-IT

推理使用：

4 × H200 GPU

对于需要 Auxiliary LLM 的 Memory，统一使用：

GPT-4o-mini

LLM-as-a-Judge 同样使用 GPT-4o-mini。

这样尽可能减少不同 Memory 方法因为辅助模型不同而带来的影响。

19. 两种完全不同的 Memory Regime

论文最关键的一项实验设计，是把 Benchmark 分成：

User-Centric
Agent-Centric

两种 regime。

19.1 User-Centric Memory

包括：

  • LoCoMo；
  • MemoryAgentBench。

这类任务的核心是：

从过去的大量历史中找回相关信息。

例如：

几十轮之前用户说：
"I moved to San Francisco."

现在问：
"Where does the user live?"

答案就在历史 Memory 里。

此时 Memory 的首要目标通常是：

Recall。

19.2 MemoryAgentBench 的四项能力

MAB 又进一步划分成四种能力：

Capability 含义
Accurate Retrieval 从超长历史中找到目标信息
Long-Range Understanding 随 Context 变长仍然保持信号
Test-Time Learning 使用运行过程中刚学到的新模式
Conflict Resolution 面对新旧冲突信息时找到最新事实

其中 Accurate Retrieval 使用 LongMemEval-S 子集。

Conflict Resolution 还被论文用于后面的 Scalability Test。

20. Agent-Centric Memory

Agent-Centric 使用：

  • ALFWorld；
  • BigCodeBench-Hard。

20.1 ALFWorld

ALFWorld 是 embodied planning 任务。

Agent 不只是回答问题，而是：

Observation
    ↓
Choose Action
    ↓
New Observation
    ↓
Choose Action
    ↓
...

共测试 134 个 valid-unseen task。

此时 Memory 可能提供过去任务的经验。

但问题在于：

Agent 下一步行动往往主要取决于当前 Observation 和当前可执行 Action，而不是过去 Memory 中某段文字。

因此 Memory 太多可能反而成为干扰。

20.2 BigCodeBench-Hard

BigCodeBench-Hard 包含 148 个 Code Task。

历史 Memory Bank 中包含其他任务的：

SUCCESSFUL Solution
FAILED Solution

当前任务可以检索与之相关的代码。

这里过去代码往往可以直接成为：

当前问题的 reusable scaffolding。

所以虽然它同样属于 Agent-Centric Benchmark，但 Memory 的作用与 ALFWorld 并不完全相同。

这也是后面非常关键的一点：

“Agent-Centric”并不代表“检索一定有害”。

真正重要的是：

Retrieved Memory 会不会和当前任务最关键的信息争夺模型注意力。

21. 26 个 Metric：不只看 Accuracy

论文共记录 26 个指标。

大体分成两类：

Performance

包括：

Exact Match
Token F1
BLEU-1
LLM Judge
Compression Ratio
Recall@k
Task Success
Goal-Condition Success
Steps to Goal
Pass@1
Substring Exact Match

Efficiency

包括：

Memory Size
Inference Time
Write Latency
Retrieval Latency
Write Tokens
Write Calls
Retrieved Tokens
Read Tokens
Read Calls
Management Tokens
Management Calls
Total Tokens
Total Calls
Total Wall-clock
Per-query Latency

论文主表尤其关注：

Performance
+
Per-query Latency

因为一个真实 Memory System 不能脱离成本讨论。

22. User-Centric 结果：没有任何一种 Memory 全面获胜

实验的第一个重要结果就是：

No single substrate wins every capability.

不同任务中最佳方法不断发生变化。

22.1 LoCoMo 与 LongMemEval-S：M5 Dual-Level Graph 最强

在三个 Backbone 上：

M5 都在 LoCoMo 和 LME-S 的 LLM-Judge Score 上表现最好。

例如 LoCoMo：

Backbone M5 P4
Qwen3-8B 0.648
Qwen3-32B-AWQ 0.683
Gemma-4-26B 0.719

这说明长对话 factual retrieval 很适合：

Entity-Level Graph
+
Chunk-Level Vector Search

这种组合。

因为问题可能需要：

  • 找某个人；
  • 找某个实体；
  • 跨多段历史连接关系；
  • 同时重新获得原始文本。

Structural Graph 在这里有明显优势。

22.2 但是 M5 非常贵

性能强不等于综合最优。

M2 BM25 通常非常便宜。

而 M5 的 per-query latency 可能比简单 Flat Retrieval 高 10～100 倍。

所以论文强调：

Structural Memory 的额外复杂度只有在它真的对应任务瓶颈时才值得。

如果一个普通 Dense / Sparse Retrieval 已经够用，那么 Knowledge Graph 带来的成本可能没有必要。

23. 不同 Memory Capability 对结构的要求不同

在 MemoryAgentBench 中，情况进一步分化。

Long-Range Understanding

Loss 较少、能够保留更多原始信息的方法表现较好。

例如：

  • Qwen3-8B 上 M10 Full Context 最好；
  • Qwen3-32B 上 M3 Gist Index 表现很好。

Test-Time Learning

M3 与 M8 表现突出。

而 M9 Adapter Tuning 表现较差。

作者解释：

刚刚学习到的信息被编码进权重以后，不容易被显式 inspection 和 selective query。

Conflict Resolution

M5 在三个模型中的两个上取得最佳结果。

这是因为 Conflict Resolution 要求：

旧事实
+
新事实
 ↓
判断哪个是当前有效版本

显式的：

  • Entity；
  • Relation；
  • Update Semantics；

对于这种任务更加有帮助。

所以 User-Centric 实验已经说明：

即使都叫“长期记忆”，Accurate Retrieval、Long-Range Understanding、Test-Time Learning、Conflict Resolution 对 Memory 的要求也并不一样。

24. Agent-Centric：结果开始发生反转

接下来是这篇论文最重要的发现之一。

同样一种 retrieval：

在有些任务里帮助 Agent，在另一些任务里反而会伤害 Agent。

25. ALFWorld：真正重要的是去掉噪声

在 ALFWorld 上，表现最突出的 Memory 往往具有一个共同特征：

在把历史送给 Agent 之前，先过滤或抽象掉大量无关内容。

例如 Qwen3-8B：

No Memory TSR = 5.7%
M11 TSR       = 11.9%

M11 大约将 Task Success 翻倍。

原因是 M11 不把整条历史轨迹重新塞进去，而是：

很多过去 Turn
      ↓
Episode Clustering
      ↓
选择匹配 Episode
      ↓
只 Re-prefill 相关部分

25.1 Qwen3-32B 上 M7 达到 32.1%

在 Qwen3-32B-AWQ 上：

No Memory = 22.4%
M7        = 32.1%

M7 成为 ALFWorld 表中的最佳方法。

M7 做的是：

Raw Trajectory
      ↓
Judge
      ↓
Distill
      ↓
Compact Strategy

它没有试图让 Agent 重新阅读完整经历，而是给 Agent：

一条经过提炼、可以直接指导当前行动的经验。

因此 M7 和 M11 虽然技术实现完全不同，但共享一个操作：

Denoising。

M7：

Trajectory
 ↓
Reasoning Template

M11：

Many Turns
 ↓
Matched Episode

本质上都在减少无关 Token。

26. 为什么 Raw Retrieval 在 ALFWorld 中可能有害？

因为 Agent 当前真正需要看的东西是：

Current Observation
Current State
Admissible Actions
Next-action Cue

假设 Prompt 是：

[System]

[Retrieved Memory]
过去任务轨迹……
过去任务轨迹……
过去任务轨迹……

[Current Observation]
You are in the kitchen...

[Admissible Actions]
open fridge
go to table
take cup

[Next Action?]

如果 Retrieved Memory 越来越长：

模型会把越来越多 Attention 分配给过去经历。

于是当前：

Observation
+
Action List

得到的注意力下降。

这对需要精准做“下一步动作”的 Agent 是致命的。

27. BigCodeBench-Hard：情况又反过来了

如果“Retrieval 越多会干扰 Agent”是一条普遍规律，那么 BigCodeBench 应该也下降。

但实验并不是这样。

BigCodeBench 上：

Retrieval 普遍是有帮助的。

例如：

Current Task:
实现某段程序

Retrieved Memory:
过去类似问题的一段成功代码

这里 Retrieved Memory 并不会与 Current Task 冲突。

相反：

它扩展了 Current Prompt。

一段类似问题的正确代码本身就是 reusable scaffolding。

因此：

  • Qwen3-8B：M5 Pass@1 = 15.5%，最高；
  • Gemma-4：M5 Pass@1 = 20.9%，最高；
  • Qwen3-32B：非常便宜的 M2 BM25 达到 19.6%，反而超过更昂贵的 M5 16.2%。

所以真正的结论不是：

Agent Task -> 少 Retrieval

而是：

Retrieved Memory 中是否包含解决当前任务的 Load-Bearing Information？

28. Performance-Latency：不同 Regime 的 Pareto Front 完全不同

作者进一步把：

Performance
vs.
Latency

画成 Pareto Frontier。

结果发现：

QA

Pareto Frontier 主要包含：

M5 Structural Graph
M6 Hierarchical Tree

Agentic

Pareto Frontier 则主要包含：

M2 Flat Retrieval      -> BigCodeBench
M7 Refinement Strategy -> ALFWorld

两边甚至没有共同的 substrate。

这意味着：

不存在一个简单的“最佳 Memory Family”。

甚至 Family 本身也不足以做 routing。

例如 Refinement Family：

M7

在 ALFWorld 上最好，

但同属 Refinement 的：

M8

在某些任务上却表现一般。

所以最终真正需要做的不是：

if Agent:
    use Refinement

而更可能是：

Current Regime
Current Query
History Length
Latency Budget
Attention Requirement
       ↓
选择具体 Substrate

29. Retrieval Top-k 消融：两个任务出现完全相反的趋势

为了确认问题到底是不是 Retrieval Breadth，论文直接改变 top-k。

LoCoMo：

k = 1, 2, 5, 10, 20

ALFWorld：

k = 1, 2, 3, 4, 5

结果非常清楚。

29.1 LoCoMo：k 越大，整体越好

在 LoCoMo 中：

随着 k 增大，P4 基本呈单调上升趋势。

原因很直观：

Retrieve More
      ↓
更可能把 Gold Evidence 找回来
      ↓
LLM 找到正确事实

即使额外找回来几段不相关内容：

对 factual QA 来说，模型通常可以忽略。

因为答案就在 Retrieved Memory 中。

29.2 ALFWorld：k 越大，反而越差

ALFWorld 上趋势反转。

例如 M7：

k = 1 : TSR = 32.1%
k = 5 : TSR ≈ 25%

Flat Retriever M1、M2 随 k 增大甚至会掉到 No-Memory Baseline 以下。

而且不仅 Task Success 下降：

Steps-to-goal 还会上升。

也就是说 Agent 并不是单纯“答错一次”。

而是：

开始在环境里乱走。

30. Attention Probe：为什么 Top-k 会产生相反效果？

作者进一步直接观察 Attention。

他们把 Prompt 分成四个区域：

System
Retrieved
Context
Cue

其中：

Retrieved

Memory System 找回来的历史。

Context

任务本身的重要上下文。

例如：

  • 对话 transcript；
  • Agent trajectory；
  • 当前 Observation；
  • Admissible Actions。

Cue

真正要求模型输出的提示。

例如：

Question

或者：

What is the next action?

31. Retrieval 增大以后，Attention 会发生什么？

作者发现两个任务中存在相同的底层现象：

随着 k 增大，Attention 从 Context 流向 Retrieved Memory。

例如 LoCoMo：

Retrieved Attention:
0.05 -> 0.66

Context Attention:
0.34 -> 0.10

也就是说模型越来越关注 Memory Retrieval Block。

这一现象本身在两个任务上是一致的。

真正不同的是：

答案到底在哪里。

31.1 LoCoMo：答案就在 Retrieved Memory

LoCoMo 中：

Question:
Where did Alice move?

Retrieved:
Alice moved to San Francisco.

答案就在 Memory。

因此：

Attention
Context -> Retrieved

实际上正是我们希望发生的事情。

所以 Recall 和最终准确率提高。

31.2 ALFWorld：答案在当前 Context

但 ALFWorld 中：

Retrieved:
过去类似任务怎么做

Current Observation:
现在 Agent 在哪里

Admissible Actions:
现在到底能执行什么

正确的下一步动作主要由：

Current Observation
+
Admissible Actions

决定。

此时同样发生：

Attention
Context -> Retrieved

结果就变成：

Agent 被过去经验吸走了注意力。

论文还观察到，随着 k=1 -> k=5，Cue 所获得的 Attention 也下降了大约 4%。

对于只有一个合法下一步动作的任务来说，这种变化已经足以导致行动错误。

32. 所以 Top-k 根本不是一个固定超参数

很多传统 RAG 系统会想：

top_k = 5

然后所有任务统一使用。

这篇论文认为这种做法对于 Agent Memory 并不合理。

因为：

Retrieval Breadth 应该由当前 Operating Regime 决定。

一个简单的判断方式是：

答案主要存在于过去 Memory？
          │
          ├── Yes -> 可以扩大 Retrieval
          │
          └── No
               ↓
当前 Context 是否承担关键决策？
               ↓
          更应该限制 Retrieval

因此：

top-k 本身也应该成为 Memory Routing 的一部分。

33. Scalability：历史从 6K 增长到 262K 后会发生什么？

前面的结果还没有考虑一个真实长期 Agent 必然遇到的问题：

Memory 会越来越大。

作者使用 MAB Conflict Resolution，把 Context Length 从：

6K
 ↓
32K
 ↓
262K

不断扩大。

此时不同 Memory 的扩展性差异开始非常明显。

34. Refinement Memory 的扩展性更好

例如 M8：

P4:
0.32 -> 0.51

与此同时，Latency 大约：

1s -> 10s

虽然增加，但仍然处于相对可控的范围。

原因是 M8 最终 Read 的不是全部历史，而是：

固定规模附近的 Skill Representation。

历史越多：

Raw History
     ↓
Write-side Refinement
     ↓
Compact Skills

大量成本被提前消化在 Write / Management 阶段。

Read 并不需要重新扫描全部 262K 历史。

35. Structural Memory：质量可以提升，但成本迅速膨胀

M5：

P4:
0.28 -> 0.48

质量同样随着历史增长而提升。

长历史给 Knowledge Graph 提供了更多：

  • Entity；
  • Relation；
  • Update；

因此更容易判断某个事实到底哪个版本最新。

问题在于：

Graph Rebuild 和 Entity Extraction 的成本也随着输入规模增加。

到 262K Context 后，M4、M5 的 latency 显著上升。

于是 M5 在中等 Context 上的质量优势，可能逐渐被运行成本侵蚀。

36. Full Context：质量能继续增长，但 Read Cost 线性增长

M10 的情况也非常典型。

Conflict Resolution P4：

0.27 -> 0.47

原因很简单。

历史越完整：

模型越容易直接在 Context 中比较新旧事实。

但是每一次 Read 都必须：

重新读取越来越长的历史

所以 Read Cost 基本随着输入长度增长。

这意味着：

Full Context 在短期可能非常简单有效，但并不一定适合作为永久长期记忆。

37. Weight Memory：对 Recency-Sensitive Memory 并不理想

M9 Adapter Tuning 在 Conflict Resolution 上基本保持：

0.18 ~ 0.22

没有随着历史增长获得类似收益。

作者认为原因在于：

Adapter 缺少明确的 selective temporal update mechanism。

也就是说，如果历史是：

2025:
Alice lives in Tokyo.

2026:
Alice lives in Seattle.

External Memory 可以显式维护：

current_location = Seattle

或者利用 timestamp / graph update 判断旧事实失效。

但把两条信息都训练进 Weight 后：

很难显式控制模型到底应该保留哪个版本。

因此 Parameter Memory 在 Recency-Sensitive Conflict Resolution 上存在明显困难。

38. 第三个 Routing Axis：History Depth

前面已经得到两个 Routing 因素：

1. Task Regime
2. Retrieval Breadth

Scalability 实验又增加一个：

3. History Depth

同一个 Memory：

History = 6K

时可能很好，

到了：

History = 262K

时却可能变得非常昂贵。

所以 Memory Router 不能只问：

“用户现在问的是什么？”

还要问：

“这个 Agent 到现在已经积累了多少历史？”

39. 论文给出的设计原则：Trade Read Breadth for Write Depth

结合所有实验，论文提出一个非常核心的设计规则：

trade read breadth for write depth

可以理解成：

不要一味依靠 Read 阶段检索越来越多的历史，而应该考虑在 Write / Management 阶段花更多计算，把历史整理成更容易被利用的表示。

例如传统方式：

Write:
直接保存

Read:
Retrieve 20 条历史

另一种方式：

Write:
Trajectory
 ↓
Judge
 ↓
Distill
 ↓
Strategy

Read:
只 Retrieve 1 条 Strategy

后者把计算从 Read 转移到了 Write。

39.1 但这不代表“Memory 越少越好”

这里很容易产生误解。

论文同时明确发现：

LoCoMo 这样的 Factual QA 中，Retrieval 越宽通常越好。

所以：

trade read breadth for write depth

并不是说：

任何任务都应该少检索

而是说：

对于需要长期运行、并且当前 Context 承担关键决策的 Agent，不应该把不断扩大 Retrieval 当成唯一解决方案。

在：

Long-context Factual QA

中可以使用更加宽的 Retrieval。

而在：

Sequential Decision Making

中更适合：

更少、更精准的 Read
+
更强的 Write-side Distillation

因此真正的核心仍然是：

Regime-Aware Memory。

40. Universal Memory 不应该是一种 Memory

这也是整篇论文最后的落脚点。

作者认为：

不存在一个单独的 Memory Substrate，可以同时满足所有场景。

因为不同任务要求的是完全不同的操作。

例如：

场景 需要的 Memory 能力
长对话事实查询 高 Recall
Entity / Relation QA Structural Retrieval
多步行动 Compact Procedural Cue
Code Generation Related Example Retrieval
Conflict Resolution Explicit Update / Recency
超长生命周期 Agent Scalable Compression / Refinement

因此所谓：

Universal Agent Memory

更可能不是：

找到一个最强 Memory Database

而是：

                    Memory Router
                         │
       ┌─────────────────┼─────────────────┐
       │                 │                 │
   Structural         Refinement          Flat
   Fact Memory       Strategy Memory    Raw Memory
       │                 │                 │
       └─────────────────┼─────────────────┘
                         ↓
                       Agent

甚至可以进一步组成：

Multi-Substrate Memory System

或者：

Multi-Agent Memory System

不同 Memory 扮演不同角色：

Structural / Text
-> 保存事实

Refinement
-> 提炼抽象经验

Flat / Activation
-> 保留原始经历

再由 Harness 根据当前 regime 决定：

当前 Query 应该去哪个 Memory 中读，以及应该读多少。

41. 论文并没有提出一个完整的 Memory Router

需要注意：

这篇论文证明了 Routing 的必要性，但并没有进一步实现一个完整、自适应的 Universal Memory Router。

它提供的是：

Controlled Evaluation
        ↓
找出不同 Substrate 的适用条件
        ↓
得到 Routing Signal

也就是说，它工作的重点更像是：

为未来 Multi-Substrate Memory Router 提供经验依据。

而不是直接提出一个已经解决所有问题的 Router。

42. 为什么没有把 Mem0、MemGPT、Zep 直接放进主表？

论文其实考虑过三个非常知名的 production-grade Memory：

  • MemGPT；
  • Mem0；
  • Zep。

但是最终没有把它们放进主要 controlled comparison。

原因是：

它们的 Auxiliary LLM Cost 太高。

一次完整 LoCoMo Run 中：

System Auxiliary LLM Calls Execution Time
MemGPT 2739 16.3 h
Mem0 8984 11.8 h
Zep 7624 23.1 h

相比之下，像 BM25：

Auxiliary LLM Call = 0

整体只需要大约十分钟量级。

如果直接把完整生产系统放进去：

实验的 Token、Latency、Wall-clock 几乎会完全被这些复杂 Pipeline 主导。

作者因此选择让主实验更集中在：

Memory Substrate 本身的结构差异。

同时论文认为这些系统的核心机制已经部分由主实验中的 lighter implementation 覆盖：

Mem0  -> M3 Text Distillation
Zep   -> M5 Graph
MemGPT -> M3 Record Store

不过这里只能理解成：

机制层面的近似覆盖，

而不能理解成论文完整评估了 Mem0、Zep、MemGPT 的生产系统。

43. 论文明确指出的局限性

论文在 Appendix G 中主要指出两类限制。

43.1 没有把完整 Production Memory System 放进主要比较

MemGPT、Mem0、Zep 因成本原因被排除。

因此主实验比较的是：

代表不同 substrate design 的 controlled implementation。

而不是：

所有现实 Memory 产品的完整系统能力排名。

43.2 M8 和 M11 与原论文存在实现差异

M8

MemSkill 原始 PPO Controller 被替换为 Zero-shot LLM Controller。

原因是为了避免只有 M8 需要额外 RL Training。

M11

原始 EpiCache 的 KV Cache in-place editing 被替换成 utterance-level re-prefill。

原因是公开 Kernel 不支持 Qwen3 Hybrid Attention。

因此在解释结果时，需要把它们理解成：

对核心 substrate 思想的受控实现，

而不是完全复刻原系统。

44. 论文最终得到的三个主要结论

整篇论文的实验最终可以收敛成三个结论。

44.1 不同任务需要不同 Memory Substrate

Dialogue QA
≠
Embodied Planning
≠
Code Generation

Structural Graph 在 Dialogue QA 很强，

但在 Agentic Task 中可能被更简单的方法 Pareto-dominate。

Refinement Memory 在 ALFWorld 很强，

却不是 QA 的统一赢家。

所以不存在：

Best Memory Substrate

只有：

Best Memory Substrate
under a particular operating regime

44.2 Retrieval 越多并不一定越好

对 Factual QA：

More Retrieval
-> More Recall
-> Better QA

对 Sequential Decision：

More Retrieval
-> Attention shifts to Memory
-> Current Observation receives less attention
-> Worse Action

因此：

Retrieval Breadth 必须动态调整。

44.3 Scalability 也是 Memory Routing 的核心因素

一个方法在：

6K History

表现很好，

并不能保证它在：

262K History

仍然适合。

特别是：

Graph Rebuild
Full Context Read

都可能随着历史增长产生明显成本。

相比之下：

Strategy
Skill

这类把大量工作放到 Write / Refininement 阶段的方法，更容易维持长期 Read Efficiency。

45. 总结

这篇论文不是再设计一种新的 Agent Memory，而是重新提出一个更基础的问题：

我们为什么默认一个 Agent 从头到尾都应该使用同一种 Memory？

论文通过：

11 Memory Methods
7 Substrate Families
3 Backbone Models
4 Benchmark Suites
26 Metrics

进行统一实验后发现：

                     不存在统一最优 Memory
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
       Task Regime       Retrieval Breadth    History Depth
          │                   │                   │
          └───────────────────┼───────────────────┘
                              ↓
                       Substrate Routing

对于长对话 factual QA：

更广的 Retrieval 往往可以提升 Recall，Structural Graph 尤其有效。

对于 ALFWorld 一类连续决策任务：

Memory 的核心价值不再是“记得更多”，而是“把过去经历压缩成不会干扰当前决策的高价值信息”。

对于 Code Agent：

一段相关历史代码又可以成为直接可复用的 scaffolding，因此 Retrieval 重新变得有利。

而随着 Agent 生命周期越来越长：

Memory 的读写成本和扩展性本身也必须进入 Routing 决策。

因此论文最终主张：

未来的 Universal Agent Memory 更可能是一个由多种 Memory Substrate 组成、根据任务状态动态 Routing 的系统，而不是找到一种足够复杂、足以替代其他所有 Memory 的单一结构。

参考

  1. Wei-Chieh Huang et al. Harness the Memory: A Holistic Evaluation of Memory Substrates in Memory Agents. arXiv:2608.15008, 2026.
    https://arxiv.org/abs/2608.15008

  2. Paper PDF:
    https://arxiv.org/pdf/2608.15008

posted @ 2026-08-23 16:29  YourF4u1t  阅读(4)  评论(0)    收藏  举报