MemoryArena: Benchmarking Agent Memory in Interdependent Multi-Session Agentic Tasks

论文阅读：MemoryArena——在相互依赖的多 Session Agent 任务中评测 Memory

论文标题：MemoryArena: Benchmarking Agent Memory in Interdependent Multi-Session Agentic Tasks
作者：Zexue He, Yu Wang, Churan Zhi, Yuanzhe Hu, Tzu-Ping Chen, Lang Yin, Ze Chen, Tong Arthur Wu, Siru Ouyang, Zihan Wang, Jiaxin Pei, Julian McAuley, Yejin Choi, Alex Pentland
发表位置：ICML 2026（当前 arXiv 页面仍为 v1 预印本）
arXiv 编号：arXiv:2602.16313
原文链接：https://arxiv.org/abs/2602.16313
项目主页：https://memoryarena.github.io/
代码：https://github.com/ZexueHe/MemoryArena
主题：LLM Agent Memory、Long-term Memory、Multi-session Agent、Agent Benchmark
核心问题：现有 Memory Benchmark 大多测试“能不能记住”，Agent Benchmark 大多测试“能不能完成当前任务”，但真正的长期记忆能力应该测试 Agent 能否把之前交互中的经验保存下来，并在之后的 Session 中实际用于行动。

1. 问题：会回答过去发生了什么，不代表会利用过去完成未来任务

这篇论文关注的是 Agent Memory 的评测问题。

作者首先指出，目前与 Agent Memory 有关的 Benchmark 大致分成两类。

第一类是传统的 Memory Benchmark，例如：

  • LoCoMo
  • LongMemEval
  • MemoryAgentBench
  • MemoryBench

它们通常提供很长的对话或者历史文本，然后询问：

之前某个人说过什么？
某件事情是什么时候发生的？
用户过去有什么偏好？

这种 Benchmark 主要测试的是 memorization / recall（记忆和回忆）。

问题在于，Agent 只需要：

历史信息
  ↓
Memory
  ↓
回答问题

Memory 最终被用于回答一个 QA 问题。

但在真正的 Agent 系统里，Memory 的最终用途往往不是“回答历史事实”，而是：

过去的行动
  ↓
环境反馈
  ↓
形成 Memory
  ↓
之后遇到新的任务
  ↓
利用 Memory 决定下一步 Action

也就是说：

Memory 应该影响未来的行为。

另一类 Benchmark，例如：

  • WebArena
  • WebShop
  • SWE-Bench
  • Mind2Web

确实要求 Agent 在环境中采取 Action。

但是这类任务大部分是 single-session（单 Session）。

Agent 从任务开始到结束一直拥有当前 Session 的 interaction history，因此很多时候根本不需要真正的 persistent memory（持久记忆）。

例如：

User Task
   ↓
Action 1
   ↓
Observation 1
   ↓
Action 2
   ↓
Observation 2
   ↓
...
   ↓
Task Finished

这些信息始终存在于当前 Context 中。

因此作者认为：

单纯测试 Memory Recall，无法证明 Memory 能帮助 Agent 行动；
单纯测试 Agent Action，又不一定真正需要长期 Memory。

MemoryArena 希望把这两件事情合起来。

2. MemoryArena 的核心思想：让后面的任务必须依赖前面的任务

MemoryArena 最核心的设计并不是简单地把任务变长。

关键在于：

不同 Session 之间存在明确的因果依赖关系。

假设一个任务由多个 Subtask 构成：

Session 1
    ↓
Subtask 1
    ↓
产生信息 A

Session 2
    ↓
Subtask 2
    ↓
必须使用 A
    ↓
产生信息 B

Session 3
    ↓
Subtask 3
    ↓
必须使用 A + B

Session 结束以后，完整的 interaction trace 不再天然保留在 Agent 当前上下文中。

因此 Agent 必须通过 Memory System：

Store
Retrieve
Update

保存之前的重要信息。

如果 Session 1 的信息没有被正确保存，那么 Session 3 很可能无法完成。

这与简单地：

Task A
Task B
Task C

按顺序执行三个互不相关任务是完全不同的。

作者特别强调 interdependent subtasks（相互依赖的子任务）。

这也是 MemoryArena 和一些“把多个 Agent Task 连续跑起来”的 Benchmark 之间的重要区别。

3. Memory-Agent-Environment Loop

作者将整个过程抽象为：

Memory-Agent-Environment Loop（Memory-Agent-环境循环）。

image

【Figure 1。该图展示 MemoryArena 的核心 Memory-Agent-Environment Loop：Agent 根据 Memory 采取 Action，Environment 返回 Feedback，交互结果继续更新 Memory，而更新后的 Memory 被带入后续 Session。】

在一个普通的单 Session Agent 中，Agent 在第 t 步根据：

当前任务 instruction
+
本 Session 之前的 observation
+
本 Session 之前的 action

决定下一步行动。

可以抽象成：

action_t =
    Agent(
        instruction,
        previous_actions,
        previous_observations
    )

由于整个 Session 的历史通常还在 Context 里，所以这里并不一定需要 persistent memory。

3.1 多 Session 情况

MemoryArena 将一个完整任务拆成：

s_1 -> s_2 -> ... -> s_n

每个 s_i 都是一个独立 Session。

例如购买一个完整的相机套装：

Session 1:
购买 Camera Body

Session 2:
购买 Lens

Session 3:
购买 Camera Case

问题是：

购买 Lens 时，必须知道之前买的 Camera Body 是什么型号。

购买 Case 时，又可能需要知道：

Camera Body
+
Lens

的尺寸或者兼容关系。

因此不同 Session 之间需要持续存在某种状态。

MemoryArena 为 Agent 增加一个 persistent memory system：

M

在每个 Action step 中首先进行 Memory Retrieval：

m_i,t =
Retrieve(
    M,
    current_subtask,
    current_actions,
    current_observations
)

然后 Agent 根据：

当前 Subtask
+
当前 Session History
+
Retrieved Memory

产生下一步 Action：

action =
Agent(
    current_subtask,
    session_history,
    retrieved_memory
)

当一个 Subtask 完成后：

M =
Update(
    M,
    subtask_interaction_trace
)

随后这个更新后的 Memory 会被带入下一个 Session。

整个过程因此变成：

           Retrieve
Memory ----------------> Agent
  ↑                        |
  |                        |
Update                   Action
  |                        |
  |                        ↓
  +---------------- Environment
             Feedback

作者把这种完整闭环称为：

Memory-Agent-Environment Loop

这里 Memory 不再是一个任务结束以后接受 QA 查询的数据库，而是 Agent 决策过程的一部分。

4. MemoryArena 与已有 Benchmark 的区别

论文给出了一组 Benchmark 对比。

简化如下：

Benchmark Memory 评测 Agent Action Environment Feedback Multi-session Interdependent Subtasks
LoCoMo ✓ × × ✓ ×
LongMemEval ✓ × × ✓ ×
MemoryAgentBench ✓ × × ✓ ×
MemoryBench ✓ × × ✓ ×
WebArena × ✓ ✓ × ×
WebShop × ✓ ✓ × ×
Evo-Memory ✓ ✓ ✓ ✓ ×
AgencyBench × ✓ ✓ ✓ ✓
MemoryArena ✓ ✓ ✓ ✓ ✓

这里一个很重要的区别是 cross-task causal dependency（跨任务因果依赖）。

例如 Evo-Memory 也会连续运行多个任务，并让 Agent 从过去任务中学习。

但论文指出，这些任务本身仍然来自原本独立的 Agent Benchmark：

Task 1
Task 2
Task 3

Task 3 并不会在数据设计层面强制要求：

必须使用 Task 1 得到的某个具体信息才能完成。

MemoryArena 则显式构造这种依赖。

因此 MemoryArena 测试的不只是：

Memory 里有没有过去的信息？

而是：

这些过去的信息有没有被正确保存，并在未来真正改变 Agent 的行动？

5. MemoryArena 的四类任务环境

MemoryArena 包含四种主要 Agentic Environment：

  1. Bundled Web Shopping
  2. Progressive Web Search
  3. Group Travel Planning
  4. Sequential Formal Reasoning

其中 Formal Reasoning 又包含 Math 和 Physics 两部分。

image

【Figure 2。该图分别展示 Bundled Web Shopping、Group Travel Planning、Progressive Web Search、Math Formal Reasoning 和 Physics Formal Reasoning 中 Session 之间的依赖方式，可以直观看出后续 Subtask 如何依赖此前产生的信息。】

论文报告的规模如下：

Environment 最少 Session 最多 Session 平均 Trace 长度 Task 数量
Bundled Web Shopping 6 6 41.5k tokens 150
Group Travel Planning 5 9 40.6k tokens 270
Progressive Web Search 2 16 122.4k tokens 256
Math Formal Reasoning 2 16 18.1k tokens 40
Physics Formal Reasoning 2 12 14.1k tokens 20

需要注意，论文 v1 的 Table 1 报告 MemoryArena 总 Task 数为 766，但 Table 2 中上述五部分数量相加为 736。两个表在 v1 中存在这一数字不一致，因此这里保留 Table 2 给出的各环境原始统计，不自行推断具体原因。

6. Bundled Web Shopping：后面的商品必须兼容前面购买的商品

第一个环境是：

Bundled Web Shopping（组合式网页购物）。

它建立在 WebShop 环境上。

普通 WebShop 可能要求：

帮我买一个符合条件的电视。

这是一个独立任务。

MemoryArena 则可能构造：

Session 1:
购买电视

Session 2:
购买 Soundbar

Session 3:
购买 TV Mount

Session 4:
购买其他配件
...

而后面的商品必须和之前购买的商品兼容。

例如：

Session 1:
购买了一台 75 inch TV

Session 2:
需要购买 TV Stand

Constraint:
Stand 必须能够支撑之前购买的电视尺寸

因此 Agent 不能只看当前 Session。

它必须知道：

Previously Purchased TV:
75 inch

6.1 如何构造商品依赖

作者首先利用 WebShop 的 category hierarchy（商品类别层次结构）找到可能存在兼容关系的商品。

例如：

Electronics
└── Television & Video
    └── Televisions
        ├── TVs
        └── TV Mounts / Stands

随后从商品 description 中抽取关键属性，并构建：

accept map
reject map

用于描述商品之间的兼容关系。

例如：

75-inch TV
    ↓
Accept:
70-inch compatible stand

Reject:
50-inch stand

这些规则用于形成跨 Session 的 compatible product chain（兼容商品链）。

同时作者加入 negative distractor（负例干扰项）。

于是每个 Session 都不是简单查找历史商品名称，而需要：

  1. 回忆之前买了什么；
  2. 找到关键属性；
  3. 推导当前兼容条件；
  4. 排除 incompatible candidates；
  5. 根据当前额外要求选择最终商品。

最终得到 150 个多 Session Shopping Task。

7. Progressive Web Search：搜索条件逐步增加

第二类环境是：

Progressive Web Search（渐进式网页搜索）。

作者基于 BrowseComp-Plus 构建这一部分。

普通 Search Benchmark 往往一次给出完整问题：

Find a person satisfying:
condition A
condition B
condition C
condition D

MemoryArena 将它拆成多个 Session。

例如：

Session 1:
找到满足条件 A 的对象

Session 2:
在之前结果基础上再满足 B

Session 3:
再加入条件 C

Session 4:
再加入条件 D

于是每一次 Search 得到的信息都会成为后续 Search 的条件。

可以理解成：

C1
 ↓
candidate set 1

C1 + C2
 ↓
candidate set 2

C1 + C2 + C3
 ↓
candidate set 3

C1 + C2 + C3 + C4
 ↓
final answer

Agent 如果忘掉前面某个条件，就可能得到完全错误的最终答案。

7.1 数据构造

作者从 BrowseComp-Plus 的 830 个样本出发。

首先使用具有 Web Search Tool 的 LLM Agent 测试这些问题。

如果某个问题能够：

在单次 interaction 中直接回答正确

那么它会被删除。

原因是这种问题不需要 Memory。

剩下的问题再被拆分为多个具有递进条件的 subquery。

之后由人工检查：

  • 分解是否合理；
  • 是否存在重复条件；
  • 每一步是否只依赖此前已经出现的信息；
  • 是否出现“当前问题需要未来 Session 才提供的信息”。

如果存在违反因果顺序的情况，整个样本都会被删除。

最终保留：

256 个 Progressive Web Search Task。

其平均 interaction trace 长度达到：

122.4k tokens。

这是 MemoryArena 中上下文最长的一类任务。

8. Group Travel Planning：新成员不断加入，约束引用过去成员

第三类环境是：

Group Travel Planning（群体旅行规划）。

它基于 TravelPlanner 构建。

任务开始时首先存在一个基础 Traveler 和已经确定的行程。

随后新的 Traveler 不断加入。

例如：

Traveler 1:
Rebecca

Traveler 2:
Jasmine

Traveler 3:
Eric
...

后来加入的人可以引用之前成员的行程。

作者定义了两种主要约束。

8.1 JOIN Constraint

JOIN 表示：

某个人希望和之前某个人参加同一个活动。

例如：

I want to have dinner with Rebecca
on the second day.

那么 Agent 必须找到：

Rebecca
Day 2
Dinner

对应的活动，然后给当前 Traveler 安排同样的活动。

8.2 RELATION Constraint

RELATION 则更加复杂。

当前 Traveler 的选择与过去成员之间存在相对关系。

例如：

I want a hotel
whose rating is at least
two levels higher than Rebecca's.

Agent 首先需要：

retrieve Rebecca's hotel

然后获得：

rating = X

再计算：

required rating >= X + 2

然后才能搜索当前 Traveler 的酒店。

这些关系可以涉及：

  • price
  • rating
  • cuisine
  • room type
  • house rules

等属性。

不同 Traveler 还可以继续引用更早的 Traveler，因此最终形成 dependency chain（依赖链）。

论文构造：

270 个 Group Travel Planning Instance，

依赖深度最高达到 4。

这也是实验中最困难的一类任务。

9. Sequential Formal Reasoning：前面的 Lemma 成为后面证明的一部分

第四类任务是：

Sequential Formal Reasoning（顺序形式推理）。

包含：

  • Mathematics
  • Physics

作者希望模拟论文中的真实理论推导。

一个研究论文中的最终 Theorem 往往不是：

Question
↓
直接推导
↓
Answer

而是：

Definition
 ↓
Lemma 1
 ↓
Lemma 2
 ↓
Proposition
 ↓
Lemma 3
 ↓
Main Theorem

后面的结论依赖前面的中间结果。

因此这种结构天然适合测试：

Agent 能不能保留之前推理中得到的知识，并在之后继续使用。

9.1 数据如何构造

论文邀请了理论数学和理论物理方向的高年级 PhD 专家进行人工标注。

专家首先选择：

中心结论确实依赖较长推导链

的研究论文。

随后根据原论文结构将主要证明拆成：

Intermediate Statement 1
Intermediate Statement 2
Intermediate Statement 3
...
Final Statement

其中主要包括：

  • Lemma
  • Proposition
  • Intermediate Result

专家还记录每一步所需要的：

  • notation
  • definition
  • remark
  • algorithm
  • necessary background

如果一个中间结论需要依赖未来才出现的信息，则该样本会被丢弃，以保证严格的 causal consistency（因果一致性）。

最终得到：

类型 Problem 数
Mathematics 40
Physics 20

每个 Problem 本身又由多个顺序依赖的问题构成。

10. Memory System 在 Benchmark 中如何接入 Agent

MemoryArena 并不要求使用某一种特定 Memory 架构。

作者把 Memory System 抽象成两个最基本的操作：

Retrieve()
Update()

因此不同 Memory 方法都可以接入同一个 Agent-Environment Loop。

论文主要测试三大类方法。

10.1 Long-Context Memory

最直接的方法就是：

什么都不总结，把过去完整 interaction history 全塞进 Context。

即：

Session 1 History
+
Session 2 History
+
Session 3 History
+
Current Task

作者将这种 Memory 归类为：

0D Memory

也就是原始历史，没有 consolidation（整合）或者 abstraction（抽象）。

实验包括：

  • GPT-5.1-mini
  • GPT-4.1-mini
  • Gemini-3-Flash
  • Claude-Sonnet-4.5

10.2 External Memory Agent

第二类是真正的独立 Memory System。

Memory System 会对历史进行：

  • abstraction
  • consolidation
  • organization
  • retrieval

例如：

  • Letta
  • Mem0
  • Mem0-g
  • ReasoningBank

论文正文 Section 4.1 中使用了 MemGPT 的名称，而主实验 Table 3 中对应结果以 Letta 名称呈现，因此本文按照实验结果表中的名称记录。

作者进一步将 Memory 结构分为：

类型 含义
0D 原始历史，没有抽象
1D 对信息进行总结、整合，但 Memory 仍是平面结构
2D 使用 Tree / Graph 等关系结构组织 Memory

例如：

Mem0
    -> 1D

Mem0-g
    -> 2D

10.3 RAG

第三类是标准 Retrieval-Augmented Generation。

过去 interaction 被存入 document store。

当前 Agent 根据 Query 检索相关历史信息。

论文测试：

  • BM25
  • Text-Embedding-3-Small
  • MemoRAG
  • GraphRAG

其中：

BM25
Embedding RAG

更接近原始 Chunk Retrieval。

而：

MemoRAG
GraphRAG

会进行更复杂的信息组织。

11. Evaluation Metric

作者使用两个主要指标。

11.1 Task Success Rate（SR）

SR 表示：

整个 Task 是否成功。

例如一个任务有：

Subtask 1 ✓
Subtask 2 ✓
Subtask 3 ✓
Subtask 4 ✗
Subtask 5 ✓

那么整个任务：

SR = 0

因为没有完整完成。

11.2 Process Score（PS）

由于 SR 非常严格，作者又设计了：

Task Progress Score（PS）。

对于某个 Task：

PS =
passed_subtasks / total_subtasks

例如：

5 个 Subtask
4 个完成

PS = 4 / 5 = 0.8

最终对所有任务取平均。

所以：

SR

衡量的是最终有没有完成整个任务；

而：

PS

衡量的是：

虽然任务没完全成功，但到底走到了多远。

Group Travel 的 soft PS

Group Travel Planning 实在太困难，很多方法：

SR ≈ 0
PS ≈ 0

几乎无法区分。

因此作者又报告：

soft Process Score（sPS）。

它根据一个 Subtask 内满足了多少条 constraint 给部分分数。

12. 主实验结果：现有 Agent Memory 在真正的跨 Session 行动中表现仍然很低

下面只整理 Table 3 中最直观的 Success Rate。

方法 Shopping SR Travel SR Search SR Math SR Physics SR Avg SR
GPT-5.1-mini Long Context 0.01 0.00 0.06 0.26 0.45 0.16
GPT-4.1-mini Long Context 0.00 0.00 0.02 0.19 0.40 0.12
Gemini-3-Flash Long Context 0.12 0.00 0.07 0.16 0.50 0.17
Claude-Sonnet-4.5 Long Context 0.12 0.00 0.02 0.29 0.50 0.19
Letta 0.00 0.00 0.16 0.13 0.45 0.15
Mem0 0.00 0.00 0.24 0.19 0.25 0.14
Mem0-g 0.00 0.00 0.15 0.19 0.25 0.12
ReasoningBank 0.00 0.00 0.10 0.23 0.25 0.12
BM25 0.00 0.00 0.28 0.23 0.45 0.19
Text Embedding RAG 0.00 0.00 0.23 0.32 0.60 0.23
MemoRAG 0.00 0.00 0.22 0.23 0.50 0.19
GraphRAG 0.00 0.00 0.04 0.26 0.55 0.17

最明显的现象是：

所有方法的整体成功率都很低。

即使某些 Memory 方法已经能够在传统长上下文 Memory Benchmark 上取得很高的 Recall Performance，它们在 MemoryArena 中仍然无法稳定完成跨 Session 的 Agent Task。

13. PS 很高但 SR 很低：局部做对，不代表能把整个任务做对

一个值得注意的现象是：

很多方法的：

PS >> SR

例如 GPT-5.1-mini 在 Bundled Web Shopping 中：

SR = 0.01
PS = 0.58

也就是说：

Agent 能完成相当一部分 Subtask。

但真正完成全部购物链的概率只有：

1%

这说明失败往往不是：

Agent 从第一步开始什么都不会做。

而是：

前面做对
↓
某一步 Memory / Reasoning 出错
↓
状态开始偏移
↓
后面的决策建立在错误状态上
↓
最终整个 Task 失败

因此这类任务的困难在于：

长期维护一个全局一致的任务状态。

14. Group Travel Planning 几乎把所有方法打到 0

Group Travel Planning 是论文中最困难的一项。

所有方法：

Task SR = 0

原因是它不是简单记住：

Rebecca 喜欢什么

而是要处理大量类似：

Jasmine 的 Day 2 Breakfast
价格必须在 Rebecca Day 3 Lunch 的 ±10% 内
并且 Rating 更高

这样的跨 Session relative constraints。

同时一个完整 Travel Plan 包含大量 Activity Slot。

因此 Agent 同时要完成：

Memory Retrieval
+
Constraint Tracking
+
Numerical / Relational Reasoning
+
Planning

任何一个环节出现错误，都可能导致整个行程不满足约束。

15. 一个重要结果：External Memory 并不一定比 Long Context 更好

论文一个比较重要的实验发现是：

给强大的 Long-Context LLM 增加 External Memory，并不会稳定提高性能。

也就是说：

Strong LLM
+
Memory System

并不自动产生：

1 + 1 > 2

的效果。

作者提出了两个可能的原因。

15.1 Representation Mismatch

Long Context 中，Agent 看到的是：

原始、连续、完整的 interaction history

例如：

Action
Observation
Action
Observation
Action
Observation

这些信息具有原本的时间顺序和上下文关系。

而 External Memory 返回的可能是：

compressed summary
+
retrieved chunk
+
reordered information

原始 trajectory 的结构被改变了。

于是 Agent 原本擅长的：

in-context reasoning

未必能够直接适应这种 Memory Representation。

作者将这种情况称为：

representation mismatch（表示不匹配）。

15.2 Training Mismatch

第二个问题是：

Task Agent 和 Memory System 通常是分别设计的。

Task Agent 并没有被专门训练去学习：

什么时候 query memory？
query 应该怎么写？
retrieved memory 哪部分可信？
如何把 memory 与当前 observation 结合？

因此即使 Memory 检索出了正确的信息：

Memory
   ↓
Retrieved Information
   ↓
Agent

Agent 也未必能够正确利用。

作者将这一问题称为：

training mismatch（训练不匹配）。

也就是说，现有很多系统实际是在做：

一个已经训练好的 LLM
+
一个独立设计的 Memory Module

两者之间并没有真正 joint optimization（联合优化）。

16. External Memory 什么时候有帮助？

虽然 Memory 并不总能提高结果，但论文发现，在某些环境中 External Memory 和 Retrieval 更有帮助。

主要包括：

  • Progressive Web Search
  • Formal Reasoning

原因是这些任务的 Context 本身已经非常长。

尤其 Progressive Web Search：

Average Trace Length:
122.4k tokens

当大量历史内容直接塞入 Context 时，会出现：

  • attention saturation
  • context noise
  • earlier error accumulation
  • relevant information 被大量无关信息淹没

此时 Memory 的：

select
compress
retrieve

能力反而有价值。

例如 Progressive Web Search：

GPT-5.1-mini Long Context
SR = 0.06

BM25
SR = 0.28

Embedding RAG
SR = 0.23

Mem0
SR = 0.24

在这一环境中，把历史信息有选择地重新取出来明显更有帮助。

17. 更复杂的 Memory Structure 并不自动更好

论文还比较了：

0D
1D
2D

Memory。

直觉上可能会认为：

Raw Memory
<
Summarized Memory
<
Graph Memory

但实验并没有支持这种简单关系。

例如总体平均 SR：

Text Embedding RAG: 0.23
GraphRAG:           0.17

Mem0 和 Mem0-g 也没有表现出：

Graph Structure

必然带来更好的任务成功率。

这说明在 MemoryArena 中，更重要的问题并不只是：

Memory 存储结构够不够复杂？

而是：

Memory 有没有保留当前任务未来真正需要的状态，并且在正确的时候重新提供给 Agent。

18. Interdependent Subtask 越深，性能越差

作者进一步定义：

SR@k

表示：

到第 k 个 Subtask 时，仍然能够正确完成该 Subtask 的比例。

实验中所有方法基本都表现出：

k 增加
↓
SR@k 下降

而且没有哪一种方法能够长期保持平坦曲线。

这说明随着 Session 增加：

Memory Error
+
Retrieval Error
+
Reasoning Error
+
Action Error

会不断积累。

最终造成：

long-horizon performance decay（长程性能衰减）。

18.1 Progressive Web Search 中 Long Context 衰减更快

Progressive Web Search 每个 Session 会产生非常长的 reasoning trace。

因此随着 k 增加：

Accumulated Context
    ↓
越来越长
    ↓
Long Context Agent
    ↓
性能下降

相比之下，External Memory / Retrieval 可以重新从过去历史中取出相关信息，因此衰减更慢。

18.2 精确信息复用时，Retrieval 往往比重度总结更可靠

某些任务要求保存的是非常具体的信息。

例如：

之前购买的商品型号
某个人 Day 3 Lunch 的具体价格
某个 Lemma 的中间结论
某个 Activity 的具体时间

此时如果 Memory System 进行了太强的 abstraction：

raw history
    ↓
summary
    ↓
summary of summary

一些具体属性可能被丢失。

论文发现，在这些需要 exact reuse（精确复用）的任务中：

Retrieval-based Method 往往比进行大量 abstraction / consolidation 的 Memory Agent 更稳定。

19. Case Study：RAG 也可能因为没检索到一个属性而彻底失败

论文 Appendix 给出了一个 Bundled Web Shopping 的例子。

Agent 此前已经购买：

Step 1:
LED TV

Step 2:
Sony Soundbar
Attribute:
Compact

Step 3 要购买：

TV Wall Mount

其中 Compatibility Rule 包含：

Compact
    -> Articulating

Compact
    -> Avoid Low Profile

Long Context Agent 可以直接看到完整历史，因此知道：

Soundbar = Compact

最后购买：

Articulating TV Wall Mount

任务成功。

BM25 RAG 则只检索到了：

Compatibility Rules

却没有检索回来：

Step 2:
Soundbar = Compact

于是 Agent 虽然知道规则：

Compact avoids Low Profile

却不知道自己之前买的 Soundbar 是否是 Compact。

最后选择了：

Low Profile Mount

造成整个 Bundle incompatible。

这个 Case 很好地说明了 MemoryArena 想测试的问题：

Memory 中“存在”某条历史信息并没有意义。
真正关键的是，在某个未来 Action 需要它的时候，这条信息有没有被正确 retrieval，并最终改变 Agent 的 Action。

20. 另一个 Case：Long Context 也会因为信息太多而失败

论文在 Group Travel Planning 中展示了一个相反案例。

Jasmine 的要求是：

Day 2 Breakfast

价格需要在
Rebecca Day 3 Lunch
价格的 ±10% 以内

并且 Rating 更高

Rebecca 之前的信息是：

Day 3 Lunch:
Chawla Snacks

Price:
$48

Rating:
2.9

因此 Jasmine 的目标价格范围应该是：

$43.2 ~ $52.8

同时：

Rating > 2.9

Letta 返回了一条非常紧凑的 Memory：

Rebecca:
Day 3 Lunch
Chawla Snacks
$48
Rating 2.9

Jasmine:
references this price/rating
for Day 2 Breakfast

于是 Agent 成功找到满足条件的餐厅。

Long Context Agent 则拥有超过：

20k characters

的历史，其中混杂了多个 Traveler 的大量行程。

关键的：

Rebecca
Day 3 Lunch
$48

被埋在大量上下文中。

最终模型没有正确利用这个数字，违反了价格限制。

这个例子说明：

原始信息保留得越完整，并不意味着模型越容易利用它。

Memory 的价值之一就是：

大量历史
   ↓
筛选 Task-Relevant State
   ↓
只向 Agent 提供当前需要的信息

21. 但 Memory Compression 同样可能丢掉关键状态

论文紧接着又展示了反例。

在另一个 Group Travel Case 中，Memory Agent 虽然成功记住：

Zoey 的 Lunch 信息

却丢掉了基础 Traveler 的：

travel date
origin
destination

于是 Agent 后续调用 Flight Search 时出现了错误：

wrong date
wrong origin

并最终进一步导致后面的餐厅约束计算出错。

因此这里存在一个核心矛盾：

Memory 太完整
    ↓
Context Noise

Memory 压缩太强
    ↓
Critical State Loss

Memory System 真正需要解决的问题是：

怎样只保留未来决策真正需要的 sufficient information。

22. Latency：Memory 并不是免费的

论文还测试了不同方法的执行延迟。

总体趋势是：

Long Context
    最快

RAG
    居中

External Memory Agent
    最慢

原因并不难理解。

External Memory 往往需要额外执行：

Memory Extraction
Memory Updating
Memory Consolidation
Retrieval
Reranking
Summarization

这些操作本身可能继续调用 LLM。

因此 Agent Memory 的评测不能只讨论 Accuracy，还要考虑：

Performance
    vs
Latency

作者同时指出：

Memory Structure 越复杂，并不意味着 Latency 一定越高。

不同系统即使结构相似，实际实现方式也会造成非常大的延迟差异。

因此单纯使用：

0D / 1D / 2D

并不能直接预测运行开销。

23. 一个更深层的解释：MemoryArena 可以看成 POMDP

论文 Section 4.6 从 POMDP：

Partially Observable Markov Decision Process（部分可观测马尔可夫决策过程）

的角度重新解释 MemoryArena。

这是论文比较重要的一部分。

在一个 Multi-session Task 中，Agent 在当前 Session 并不能直接看到完整的真实任务状态。

例如 Shopping 中真正的 State 可能包含：

过去买过哪些商品
每个商品的型号
商品之间的兼容关系
预算还剩多少
当前 Bundle 的全部约束

但是 Agent 当前收到的 Observation 可能只有：

现在请购买一个 TV Mount

完整 State 是隐藏的。

因此这是一个典型的：

Partial Observation

问题。

23.1 Memory 实际上是在做 Belief State Estimation

从 POMDP 的角度看，Agent 需要根据过去 observation 和 action 推断：

当前真实任务状态是什么？

这个内部估计通常叫：

belief state（信念状态）。

作者因此提出一种解释：

External Memory 可以理解为一种显式的 Belief-State Estimation Mechanism。

理想情况下，Memory 不应该保存所有历史。

它应该保存：

足以恢复当前任务状态的 sufficient statistics（充分统计信息）。

例如购物任务真正需要的可能不是：

Session 1 完整的 10,000 token 浏览历史

而只是：

Purchased TV:
Model X
75 inch

Purchased Soundbar:
Model Y
Compact

Remaining Budget:
$99.52

如果 Memory 能够始终维护这些 task-relevant state variables，那么 Agent 就不需要重新阅读全部历史。

24. 为什么当前 Memory System 还做不到？

作者从两个方向总结瓶颈。

24.1 Memory-Side Bottleneck

当前很多 Memory System 的优化目标主要是：

Recall
Compression
Semantic Similarity Retrieval

但 Agent Task 真正需要的是：

Task State Tracking

两者并不完全一样。

例如：

“用户以前买过 Sony Soundbar”

可能语义上是一个重要事实。

但未来购买 TV Mount 时真正关键的是：

Soundbar Attribute = Compact

因此 Memory System 需要知道：

什么信息是未来 decision-relevant state。

而不是简单判断：

什么历史内容和当前 Query 语义相似。

24.2 Agent-Side Bottleneck

另一边，Task Agent 本身也存在问题。

现有 LLM 往往没有专门被训练：

如何查询 Memory
如何解释 Retrieved Memory
如何根据 Memory 更新自己的 Belief State
如何发现 Retrieved Memory 缺少关键字段

因此即使 Memory System 本身已经提供信息，Agent 也可能：

under-utilize

或者：

mis-utilize

这些 Memory。

作者因此提出，未来工作需要：

jointly optimize memory representations and agent training objectives

也就是联合优化：

Memory Representation
+
Memory Retrieval
+
Agent Policy
+
Agent Training Objective

而不是继续把：

Frozen LLM
+
Independent Memory Module

简单拼接起来。

25. 从 MemoryArena 看，Agent Memory 的评测目标发生了什么变化

MemoryArena 所强调的 Memory 能力可以概括为三个阶段：

Acquire
   ↓
Store / Update
   ↓
Use for Future Action

传统 Memory Benchmark 更多集中在：

Store
+
Retrieve

最终评测：

Can you recall it?

MemoryArena 则把评测继续推进到：

Can you act correctly because of it?

因此它关心的不再只是：

Memory Accuracy

而是：

Memory
   ↓
State Tracking
   ↓
Decision Making
   ↓
Environment Action
   ↓
Future Consequence

从这个角度看，Memory 不只是一个知识库，而是 Agent Policy 的一部分。

26. 论文没有单独的 Limitations Section

论文正文没有单独设置 Limitations 章节。

作者主要通过实验和 POMDP 分析指出当前系统仍存在的两个瓶颈：

层面 问题
Memory Side 当前 Memory 更擅长 Recall、Compression、Semantic Retrieval，但不一定能够维护 task-relevant state
Agent Side Agent 没有被训练如何 Query、Interpret 和 Integrate Memory

论文最终提出的方向是：

将 Memory Representation 与 Agent Training Objective 联合设计，使 Memory 真正服务于长期任务中的 State Estimation 和 Decision Making。

因此论文并没有声称已经提出解决这些问题的新 Memory Method。

MemoryArena 本身主要是一套：

Benchmark + Evaluation Framework。

它的工作是把问题暴露出来。

27. 总结

MemoryArena 的出发点非常明确：

传统 Memory Benchmark 通常问：

过去发生了什么？

传统 Agent Benchmark 通常问：

你能不能完成这个任务？

MemoryArena 则试图问：

你过去经历过一些事情。

现在环境已经进入新的 Session。

你还能不能利用那些经历，
采取正确的 Action，
最终完成一个依赖过去信息的长期任务？

为此作者构造了四种具有明确跨 Session 依赖关系的 Agentic Environment：

Bundled Web Shopping
Progressive Web Search
Group Travel Planning
Sequential Formal Reasoning

并将整个评测过程组织成：

Memory
   ↓
Retrieve
   ↓
Agent
   ↓
Action
   ↓
Environment
   ↓
Feedback
   ↓
Update Memory
   ↓
Next Session

即：

Memory-Agent-Environment Loop。

实验表明，Long Context、External Memory Agent 和 RAG 都无法稳定解决这些任务。

尤其当 Subtask Dependency Depth 增加时，各类方法普遍出现性能下降。

同时论文发现：

  • External Memory 并不总比直接使用 Long Context 更好；
  • Long Context 会受到 Context Noise 和 Attention Saturation 影响；
  • Memory Compression 又可能丢失未来 Action 所需要的精确信息；
  • Graph / Structured Memory 并不会天然优于简单 Retrieval；
  • Task Agent 与 Memory Module 之间存在 Representation Mismatch 和 Training Mismatch；
  • 真正重要的问题可能不是“记住更多”，而是持续维护与当前任务有关的状态。

论文最终从 POMDP 的角度将 Agent Memory 解释为：

对隐藏 Task State 的 Belief-State Estimation。

理想的 Memory 因此不是简单保存尽可能多的历史，也不是把历史压缩成一段泛化摘要，而应该持续维护：

足以支持未来决策的 task-relevant sufficient state。

MemoryArena 的核心贡献也正在于把 Agent Memory 的评测目标，从：

Remembering

进一步推进到：

Remembering
    ↓
State Tracking
    ↓
Acting

即真正测试：

Memory 是否能够影响 Agent 的未来行为。

参考

  1. Zexue He et al. MemoryArena: Benchmarking Agent Memory in Interdependent Multi-Session Agentic Tasks. ICML 2026 / arXiv:2602.16313.
    https://arxiv.org/abs/2602.16313

  2. MemoryArena Project Page.
    https://memoryarena.github.io/

  3. MemoryArena GitHub Repository.
    https://github.com/ZexueHe/MemoryArena

posted @ 2026-09-17 20:41  YourF4u1t  阅读(11)  评论(0)    收藏  举报