MAGMA: A Multi-Graph based Agentic Memory Architecture for AI Agents

论文阅读：MAGMA——面向 AI Agent 的多图 Agentic Memory 架构

论文标题：MAGMA: A Multi-Graph based Agentic Memory Architecture for AI Agents
作者：Dongming Jiang, Yi Li, Guanpeng Li, Bingzhe Li
发表位置：ACL 2026 Main Conference, Volume 1: Long Papers
ACL Anthology ID：2026.acl-long.1709
arXiv：2601.03236
原文链接：https://aclanthology.org/2026.acl-long.1709/
PDF：https://aclanthology.org/2026.acl-long.1709.pdf
代码：https://github.com/FredJiang0324/MAGMA
主题：Agent Memory、Memory-Augmented Generation、Graph Memory、Long-Horizon Reasoning
核心问题：现有 Agent Memory 往往主要依赖语义相似度检索，将时间、因果和实体等不同关系混在同一个记忆空间中；MAGMA 希望显式拆分这些关系，并根据 Query 的推理需求选择不同关系图进行检索。

1. 问题背景：Memory 不只是“找语义相似的历史”

LLM 的上下文窗口始终有限，而且模型本身并不会天然跨 Session 持久保存历史状态。

因此，近年来出现了大量 Memory-Augmented Generation（MAG）方法：把长期信息存入外部 Memory，在收到新 Query 时检索相关历史，再放回 Prompt 中供模型推理。

可以将这种模式简单表示为：

当前 Query
    ↓
从 Memory 中检索历史
    ↓
Query + Retrieved Memory
    ↓
LLM 生成答案
    ↓
新的交互继续写回 Memory

与经典 RAG 相比，这里的一个关键区别是：

Memory 本身会随着 Agent 的交互不断更新。

论文将这个过程表示为一个循环：

output_t = LLM(query_t, Retrieve(query_t, Memory_t))

Memory_(t+1) = Update(Memory_t, query_t, output_t)

因此，Agent Memory 面临的不只是“如何检索一个静态知识库”，而是：

如何存储不断增长的经历；
如何组织这些经历；
如何根据不同问题检索不同类型的关系；
如何持续更新 Memory；
又如何避免 Memory 越来越大后检索延迟和 Token 消耗失控。

2. 现有方法的问题：Memory 中存在不同类型的“关系”

论文认为，现有很多 Memory 系统虽然已经开始使用结构化 Memory，但检索仍然高度依赖：

embedding semantic similarity；
recency；
heuristic score；
top-k vector retrieval。

例如，一个 Query：

Why did Alice cancel the trip?

真正重要的信息可能是：

Alice became ill
    ↓ causes
Alice cancelled the trip

这里需要的是因果关系。

但如果只做向量相似度检索，系统很可能找到很多与：

Alice
trip
cancel
travel

语义相似的内容，却无法区分：

什么事情和“取消旅行”主题相似？

与：

什么事情真正导致了“取消旅行”？

同样，如果问题是：

When did Alice go hiking?

此时真正重要的是时间关系。

而如果问题是：

What instruments does Melanie play?

则可能需要围绕 Melanie 这个 Entity，将分散在多个 Session 的事件连接起来。

因此论文提出：

Semantic、Temporal、Causal、Entity 本质上是不同类型的关系，不应该全部压缩为一个统一的“语义相似度”。

这就是 MAGMA 的核心出发点。

3. MAGMA：将 Memory 表示为多个关系图

MAGMA 的全称为：

Multi-Graph based Agentic Memory Architecture

其核心思想是：

同一个 Memory Event 可以同时参与多个不同类型的 Relation Graph，而每种 Graph 分别表达一种关系。

MAGMA 使用四种主要关系：

Relation Graph	中文理解	表达的信息
Semantic Graph	语义关系图	哪些事件语义上相似
Temporal Graph	时间关系图	哪些事件先发生、哪些后发生
Causal Graph	因果关系图	哪些事件可能导致另一些事件
Entity Graph	实体关系图	哪些事件涉及相同的人、物体、地点等 Entity

因此，MAGMA 并不是建立四套完全独立的 Memory。

更准确地说：

底层 Event 是统一的，但 Event 之间存在多种不同类型的 Edge。

论文将整个 Memory 表示成一个随时间变化的有向多重图：

G_t = (N_t, E_t)

其中：

N_t：Memory Event；
E_t：不同类型的 Relation Edge。

同一个事件节点可以同时拥有：

Semantic Edge
Temporal Edge
Causal Edge
Entity Edge

从而允许系统从不同关系视角访问同一段历史。

4. MAGMA 整体架构

MAGMA 整体由三层组成：

Query Process；
Data Structure Layer；
Write / Update Process。

【Figure 2，MAGMA 的整体架构图。重点观察上方 Query Process、中间四种 Relation Graph 与 Vector Database、以及下方 Fast Path / Slow Path 两条 Memory 更新路径。】

三个部分之间的职责可以概括为：

模块	作用
Query Process	根据 Query 决定去 Memory 的哪些关系图中检索
Data Structure Layer	保存 Event、Vector Index 和四种 Relation Graph
Write / Update Process	将新交互写入 Memory，并持续补充图结构

其中 Query Process 又包含：

Intent-Aware Router
        ↓
Adaptive Topological Retrieval
        ↓
Context Synthesizer

Write / Update Process 则分为：

Fast Path：Synaptic Ingestion
Slow Path：Asynchronous Consolidation

这两个设计分别解决：

怎么读 Memory？
怎么写和维护 Memory？

下面分别展开。

5. Data Structure Layer：Memory 中到底存什么？

5.1 Event Node

MAGMA 中最基础的 Memory 单元是 Event Node。

论文将一个 Event Node 表示为：

n_i = <c_i, tau_i, v_i, A_i>

其中：

字段	含义
`c_i`	Event 的内容，例如 Observation、Action 或 State Change
`tau_i`	Event 的时间戳
`v_i`	Event 的 Dense Embedding
`A_i`	Entity、Temporal Cue、Context Descriptor 等结构化属性

也就是说，一个 Event 并不仅仅是一段文本。

它同时包含：

原始内容
+
时间
+
向量表示
+
结构化 Metadata

其中 Dense Embedding 会被加入 Vector Database，用于后续 Semantic Retrieval。

5.2 Temporal Graph：时间关系

Temporal Graph 使用有向边表示 Event 之间的时间顺序：

event_i --> event_j

要求：

time_i < time_j

论文将这条结构称为一个相对稳定的 Temporal Backbone（时间骨架）。

例如：

09:00 Alice 到达机场
        ↓
09:30 航班延误
        ↓
11:00 Alice 取消行程

时间图解决的是：

哪些事情先发生，哪些事情后发生？

因此它主要帮助：

WHEN Query；
Timeline Reasoning；
relative time resolution；
sequence reasoning。

5.3 Causal Graph：因果关系

Causal Graph 保存 Event 之间推断出的因果关系。

例如：

Heavy rain
    ↓ causes
Flight cancelled
    ↓ causes
Alice changes travel plan

它重点服务于：

Why ... ?
What caused ... ?
Why did X happen ... ?

这也是 MAGMA 与纯 Vector Memory 非常重要的区别。

Vector Retrieval 更容易表达：

A 和 B 很相似

Causal Graph 则显式表达：

A 可能导致 B

论文认为，在 Long-Horizon Reasoning 中，仅仅知道“发生了什么”是不够的，还需要知道“为什么发生”。

需要注意的是，这些因果边并不是全部由确定性的规则得到。

MAGMA 在后台的 Asynchronous Consolidation 阶段使用 LLM 对局部 Memory 进行推理，从而补充 Causal Edge。

因此，Causal Graph 的质量会依赖底层 LLM 的推理质量，这一点也是论文后来明确列出的局限之一。

5.4 Semantic Graph：语义关系

Semantic Graph 与传统 Vector Memory 最接近。

如果两个 Event 的 embedding 相似度超过阈值，就可以建立 Semantic Edge：

Event A -------- Event B
       semantic

Semantic Graph 使用无向连接，表达：

哪些 Event 在概念或主题上相近？

因此 MAGMA 并没有抛弃 Semantic Similarity。

它做的是：

保留 Semantic Retrieval，同时不再让 Semantic Similarity 承担所有关系建模任务。

5.5 Entity Graph：跨 Session 保持实体连续性

Entity Graph 将 Event 与抽象 Entity Node 连接。

例如：

           [Melanie]
           /       \
          /         \
Event: plays violin  Event: started clarinet
          \
           \
        Event: son had an accident

这样一来，即使同一个人物的信息分散在很远的不同 Session 中，也可以通过 Entity 找回来。

论文将这一能力与 Object Permanence（对象持续性）联系起来。

其目标是解决：

同一个 Entity 出现在不同时间、不同上下文甚至不同表达中时，系统仍然能够把这些事件关联起来。

6. Query Process：Memory 如何被检索？

MAGMA 的 Query Process 是论文方法中的另一个核心。

它不是：

Query
  ↓
embedding
  ↓
Vector DB Top-K

而是一个四阶段流程：

Query
  ↓
Stage 1: Query Analysis
  ↓
Stage 2: Anchor Identification
  ↓
Stage 3: Adaptive Graph Traversal
  ↓
Stage 4: Graph Linearization
  ↓
LLM

【Figure 3，MAGMA 的 Adaptive Hybrid Retrieval 流程。重点观察 Query Intent Analysis 如何控制不同 Graph View 的 traversal，以及 Anchor Node 如何从 Vector / Keyword / Temporal 信号中产生。】

7. Stage 1：Query Analysis & Decomposition

首先，MAGMA 不立即检索 Memory，而是先分析 Query。

系统提取三类主要控制信号。

7.1 Intent Classification

Router 首先判断 Query 的主要意图，例如：

WHY
WHEN
ENTITY

这个 Intent 会直接影响后续 Graph Traversal 的权重。

例如：

Why did Alice cancel the trip?

会提高：

Causal Edge

的权重。

而：

When did Alice go hiking?

则更加重视：

Temporal Edge

因此 Intent Classification 可以理解为整个检索过程的“方向盘”。

7.2 Temporal Parsing

如果 Query 包含：

last Friday
yesterday
three days ago
after the trip

MAGMA 会解析这些 Temporal Expression，并转换成更明确的时间约束。

例如：

"yesterday"
+
Session timestamp = 2023-10-20

→ 2023-10-19

得到时间范围之后，可以直接过滤不符合时间条件的 Event。

7.3 Semantic + Lexical Representation

MAGMA 同时为 Query 生成：

Dense Embedding

以及：

Sparse Keywords

Dense Embedding 用于 Semantic Search。

Keyword 则用于 Exact Lexical Matching。

因此第一阶段最终得到：

Intent Signal
Temporal Signal
Dense Semantic Signal
Lexical Signal

而不是只有一个 Embedding。

8. Stage 2：Multi-Signal Anchor Identification

在 Graph Traversal 开始之前，MAGMA 需要先找到一组：

Anchor Nodes（锚点节点）

Anchor 可以理解为：

从 Memory Graph 的哪些位置开始向外搜索？

如果起点完全错误，后面 Graph Traversal 再精细也没有意义。

MAGMA 因此同时执行：

Vector Search
Keyword Search
Temporal Filtering

然后使用 Reciprocal Rank Fusion（RRF）融合多个排名。

直观来说，一个 Event 如果：

Semantic Search 排名高；
Keyword Search 也找到它；
时间又满足 Query；

那么它成为 Anchor 的概率就更高。

这里的关键思想是：

Graph Retrieval 不是取代传统 Retrieval，而是在传统 Retrieval 找到入口之后，再利用 Graph Structure 扩展证据。

9. Stage 3：Adaptive Traversal Policy

找到 Anchor 后，MAGMA 开始在 Multi-Graph 上进行 Traversal。

论文使用的是一种：

Heuristic Beam Search（启发式束搜索）

关键问题变成：

当前在 Event A，接下来应该沿哪条 Edge 走到哪个 Event？

MAGMA 为候选 Transition 计算一个分数。

这个分数主要由两部分组成：

Transition Score
=
Structural Alignment
+
Semantic Affinity

其中：

Structural Alignment

看当前 Edge Type 是否符合 Query Intent。

例如：

WHY Query
→ Causal Edge 权重大

Semantic Affinity

看目标节点本身与 Query 的语义是否相关。

因此 Graph Traversal 并不是：

只沿因果关系一直走。

也不是：

只选择语义最相似的节点。

而是同时考虑：

这个 Edge 类型是否符合当前推理需求？
+
这个目标 Event 是否仍然与 Query 相关？

10. 为什么需要 Adaptive Policy？

假设 Memory 中存在：

Alice caught a cold
    ↓ causal
Alice cancelled meeting

Alice likes travelling
    -- semantic --
Alice booked a hotel

Alice
    -- entity --
Alice attended a conference

Query 是：

Why did Alice cancel the meeting?

如果没有 Intent-aware Policy，Graph Traversal 可能沿着所有关系扩展：

cold
travel
hotel
conference
meeting
...

结果虽然很多节点都与 Alice 有关，但大量信息对“为什么取消 meeting”没有帮助。

MAGMA 则会提高：

Causal Edge

的优先级。

因此更可能得到：

caught a cold
    ↓
cancelled meeting

论文的 Adaptive Policy 主要解决的就是：

不同 Query 应该采用不同的 Graph Traversal Strategy，而不是使用固定的 Graph Walk。

11. Beam Search 如何限制图检索范围？

MAGMA 并不会无限扩展 Graph。

在每一轮 Traversal 中：

从当前 Frontier 找 Neighbor；
给 Neighbor 计算 Transition Score；
放入 Priority Queue；
只留下得分最高的一部分节点；
继续下一 Hop；
达到最大深度或 Budget 后停止。

论文实验中的主要配置包括：

参数	设置
Vector Top-K	20
RRF Constant	60
Max Traversal Depth	5 hops
Max Nodes	200
Drop Threshold	0.15
Structure Coefficient	1.0
Semantic Coefficient	0.3–0.7

因此 MAGMA 的目标不是：

把整个 Graph 都送给 LLM。

而是：

根据 Query 从 Graph 中构造一个小而相关的 Subgraph。

12. Stage 4：把 Graph 重新变成 LLM 能读的 Context

经过 Traversal 后，系统得到的是：

Retrieved Subgraph

但 LLM 最终需要的仍然是一段 Sequence。

因此 MAGMA 最后需要将 Graph Linearize（线性化）。

论文采用三个步骤。

12.1 Topological Ordering

不同 Query 使用不同排序逻辑。

对于 Temporal Query：

按照 timestamp 排序

例如：

Event A -> Event B -> Event C

对于 Causal Query：

按照 Causal Graph 进行拓扑排序

确保：

Cause
↓
Intermediate Event
↓
Effect

在 Prompt 中仍然按照这种顺序出现。

也就是说：

Graph 在 Memory 内部负责保存结构，而 Linearization 负责尽可能把这种结构保留到最终文本 Prompt 中。

12.2 Context Scaffolding with Provenance

每个 Retrieved Node 都会被序列化成带来源信息的结构。

大致类似：

<timestamp>
event content
<reference id>

这样生成模型不仅获得 Event 内容，还知道：

事件是什么时候发生的；
它来自哪个 Memory Node。

论文希望通过这种 Provenance 信息，让最终 LLM 更像：

根据已有证据进行解释。

而不是根据模糊的 Memory Context 自由生成。

12.3 Salience-Based Token Budgeting

即使已经检索出了一个 Subgraph，LLM Context Window 仍然有限。

MAGMA 因此继续根据前面的 Relevance Score 分配 Token Budget。

高 Salience 节点：

保留完整信息

低 Salience 节点：

压缩成简短表示

例如论文给出的形式类似：

...3 intermediate events...

因此，Graph Retrieval 最终并不是无条件把所有访问过的节点塞进 Prompt，而是继续进行一次基于重要性的压缩。

13. Memory Evolution：Memory 如何持续更新？

仅仅设计 Retrieval 还不够。

Agent 每产生一次新的 Interaction，Memory 都需要更新。

问题在于：

如果每收到一条 Message，都立即调用 LLM 去：

提取 Event；
判断 Entity；
推断 Causal Relation；
建立 Graph；
更新所有结构；

那么每一轮对话的延迟都会很高。

MAGMA 因此采用：

Dual-Stream Memory Evolution（双流 Memory 演化）

将 Memory Update 分成：

Fast Path
+
Slow Path

14. Fast Path：Synaptic Ingestion

Fast Path 位于用户交互的关键路径上，因此目标非常明确：

快。

收到新的 Interaction 后，Fast Path 只执行必要操作：

New Interaction
      ↓
Event Segmentation
      ↓
创建 Event Node
      ↓
连接到 Temporal Backbone
      ↓
生成 Embedding
      ↓
写入 Vector DB
      ↓
加入 Async Queue

可以概括成：

new event
    ↓
Temporal Edge
    ↓
Vector Index
    ↓
Queue

这里最关键的一点是：

Fast Path 不执行阻塞式的 LLM Reasoning。

因此，诸如：

这个 Event 与历史上的哪个 Event 存在因果关系？
这个人是不是前面提到的某个 Entity？

这种昂贵的推理并不会阻塞当前用户请求。

Fast Path 只先确保：

新事件立即可以被保存和基础检索。

15. Slow Path：Asynchronous Consolidation

更加复杂的 Memory Structure 在后台异步完成。

后台 Worker 从 Queue 中取出新 Event：

Queue
 ↓
New Event
 ↓
找到局部 Neighborhood
 ↓
LLM Reasoning
 ↓
推断新的 Causal / Entity Relation
 ↓
更新 Graph

论文使用最近 Event 的局部 Neighborhood，例如两跳范围，然后调用 LLM 推断潜在关系。

最终产生新的：

Causal Edge
Entity Edge

并写回 Graph。

因此 MAGMA 的 Memory 不是在 Event 写入瞬间就完全构建好的。

而是：

先快速写入
      ↓
随后后台逐渐 Consolidate
      ↓
Graph Structure 越来越丰富

这种设计的核心权衡是：

在线响应速度
vs.
Memory 结构深度

MAGMA 将二者拆开：

Latency-sensitive operations → Fast Path
Compute-intensive reasoning → Slow Path

16. 为什么 Dual-Stream 很重要？

如果没有这个机制，每次用户说一句话，系统都可能需要先完成：

LLM Event Extraction
LLM Entity Resolution
LLM Causal Inference
Graph Update

再返回 Response。

随着 Memory 增长，这会直接增加在线延迟。

MAGMA 的做法是：

用户当前请求
    ↓
只执行轻量写入
    ↓
立即继续交互

       同时

后台 Worker
    ↓
慢慢完善 Graph

因此，Graph Memory 的复杂度被更多转移到后台 Memory Construction 阶段，而不是 Query Critical Path 上。

17. Prompt 与实现细节

论文附录还给出了 MAGMA 的 Prompt Library。

主要分为三类。

Prompt	职责
Event Extraction Prompt	从原始 Conversation 中提取结构化 Event Metadata
Query-Adaptive QA Prompt	根据 Router 判定的 Query 类型动态改变 Answer Instruction
Evaluation Prompt	使用 LLM-as-a-Judge 对答案进行语义评分

17.1 Event Extraction

Event Extraction 使用严格 JSON Schema。

主要抽取：

entities
topic
relationships
semantic_facts
dates_mentioned
summary

也就是说，Memory Construction 本身不只是：

conversation -> chunk

而是：

conversation
    ↓
structured event metadata
    ↓
graph construction

论文强调使用结构化 JSON 输出，以减少解析错误并保持 Graph Integrity。

17.2 Query-Adaptive QA

最终 QA Prompt 也会受到 Router 控制。

例如：

Multi-hop

要求模型：

连接不同 Node 中的相关事实

Temporal

要求：

解析 relative date
使用 Event Timestamp
必要时计算 duration

Open-Domain / Inference

允许基于已有 Memory Evidence 做一定推理。

Single-hop

要求：

直接提取具体 Fact
避免额外解释

因此 Query Intent 不仅控制：

Graph Retrieval

也继续影响：

最终 Answer Generation

18. 实验设置

论文主要在两个 Long-Term Memory Benchmark 上实验。

18.1 LoCoMo

LoCoMo 包含长时间、多 Session 的 Conversation。

论文使用的平均 Conversation 长度约为：

9K tokens

测试的 Question Category 包括：

类别	样本数
Single-Hop Retrieval	841
Adversarial	446
Temporal Reasoning	321
Multi-Hop Reasoning	282
Open Domain	96
总计	1,986

18.2 LongMemEval

LongMemEval 用于测试更加极端的 Long-Context Memory。

论文指出其平均上下文长度超过：

100K tokens

因此主要用于测试：

Long-Horizon Memory Retention；
Retrieval Precision；
Scalability。

19. Baseline

MAGMA 与以下方法比较：

方法	特点
Full Context	直接把整个 Conversation History 输入 LLM
A-MEM	自演化 Agent Memory，组织相互连接的 Memory
MemoryOS	Semantic-oriented Hierarchical Memory
Nemori	使用 Predict-Calibrate 机制进行 Episodic Memory 建模
MAGMA	Multi-Graph + Intent-aware Retrieval

为了减少 Backbone 差异，论文统一使用：

gpt-4o-mini

用于各系统的 Retrieval Reasoning 与 Response Generation。

Full Context 最多使用 gpt-4o-mini 的 128K Context。

Retrieval-based Baseline 使用作者公开实现中的默认超参数和存储设置。

20. 评价指标：主要使用 LLM-as-a-Judge

论文的主要指标并不是 F1 或 BLEU，而是：

LLM-as-a-Judge

Judge 同样使用：

gpt-4o-mini
temperature = 0

给 Candidate Answer 一个：

0.0 ~ 1.0

的连续评分。

大致评分原则为：

分数	含义
1.0	关键信息完全匹配
0.8	主要内容正确，仅缺少次要细节
0.6	部分正确，但缺少关键约束
0.4	与主题有关，但没有回答核心问题
0.2	大部分错误，仅存在少量表面相关
0.0	矛盾、错误或 Hallucination

对于 Adversarial Question，如果 Gold Answer 是：

Unanswerable

Candidate 必须明确表示没有足够信息，否则产生虚构事实时评分为 0。

论文同时报告：

Token-level F1
BLEU-1

作为补充指标。

21. LoCoMo 主实验结果

论文的 LoCoMo 主结果如下。

Method	Multi-Hop	Temporal	Open-Domain	Single-Hop	Adversarial	Overall
Full Context	0.468	0.562	0.486	0.630	0.205	0.481
A-MEM	0.495	0.474	0.385	0.653	0.616	0.580
MemoryOS	0.552	0.422	0.504	0.674	0.428	0.553
Nemori	0.569	0.649	0.485	0.764	0.325	0.590
MAGMA	0.528	0.650	0.517	0.776	0.742	0.700

MAGMA Overall Judge Score 为：

0.700

高于：

Nemori     0.590
A-MEM      0.580
MemoryOS   0.553
Full       0.481

不过 MAGMA 并不是所有子任务都最高。

在 Multi-Hop 上：

Nemori = 0.569
MAGMA  = 0.528

Nemori 更高。

MAGMA 优势最明显的是：

Adversarial

达到：

0.742

而其他系统最高为 A-MEM 的：

0.616

论文将这一结果归因于 Adaptive Traversal Policy：系统不仅寻找 Semantic Similarity，还能够根据 Causal 和 Entity Structure 排除语义相似但结构上不相关的 Distractor。

Temporal 部分 MAGMA 为：

0.650

Nemori 为：

0.649

二者非常接近。

22. LongMemEval：超过 100K Context 下的表现

LongMemEval 的结果如下。

Question Type	Full Context	Nemori	MAGMA
Single-session Preference	6.7%	62.7%	73.3%
Single-session Assistant	89.3%	73.2%	83.9%
Temporal Reasoning	42.1%	43.0%	45.1%
Multi-session	38.3%	51.4%	50.4%
Knowledge Update	78.2%	52.6%	66.7%
Single-session User	78.6%	77.7%	72.9%
Average	55.0%	56.2%	61.2%

MAGMA 平均 Accuracy：

61.2%

高于：

Nemori       56.2%
Full Context 55.0%

不过从分项结果同样可以看到：

MAGMA 并不是每种 Question Type 都超过 Full Context。

例如：

Single-session Assistant
Full Context = 89.3%
MAGMA        = 83.9%

以及：

Knowledge Update
Full Context = 78.2%
MAGMA        = 66.7%

论文强调的优势主要来自：

在只检索较小 Context 的情况下获得更好的整体平均性能。

表中给出的 Context 大小约为：

Full Context: 101K tokens
Nemori:       3.7K–4.8K tokens
MAGMA:       0.7K–4.2K tokens

23. 系统效率

论文还比较了 Memory Build Time、Token Consumption 和 Query Latency。

Method	Build Time	Tokens / Query	Latency
Full Context	N/A	8.53K	1.74s
A-MEM	1.01h	2.62K	2.26s
MemoryOS	0.91h	4.76K	32.68s
Nemori	0.29h	3.46K	2.59s
MAGMA	0.39h	3.37K	1.47s

几个结果需要分别看。

Memory Build Time

最快的是：

Nemori = 0.29 h

MAGMA 为：

0.39 h

因此 MAGMA 并不是 Memory Construction 最快的方法。

Token Consumption

最低的是：

A-MEM = 2.62K

MAGMA：

3.37K

论文指出 A-MEM 更激进的 Summarization 降低了 Token Cost，但其 LoCoMo Overall Judge Score 低于 MAGMA。

Query Latency

MAGMA：

1.47 s

是 Retrieval-based 方法中最低的。

论文将这一点主要归因于：

Adaptive Traversal
+
Background Asynchronous Consolidation

前者减少 Query 时需要访问的无关 Subgraph，后者把昂贵的 Structure Construction 移到后台。

24. Ablation：哪个组件最重要？

论文分别移除：

Adaptive Policy；
Causal Links；
Temporal Backbone；
Entity Links。

结果如下。

MAGMA Configuration	Judge	F1	BLEU-1
w/o Adaptive Policy	0.637	0.413	0.357
w/o Causal Links	0.644	0.439	0.354
w/o Temporal Backbone	0.647	0.438	0.349
w/o Entity Links	0.666	0.451	0.363
Full MAGMA	0.700	0.467	0.378

其中影响最大的是：

Adaptive Policy

从：

0.700

下降到：

0.637

这说明 MAGMA 的关键并不只是：

建四张 Graph。

还包括：

Query 来了之后，根据 Query Intent 决定 Graph 应该怎么走。

否则即使有 Graph，固定 Traversal 仍然容易把大量结构上无关的信息带回来。

25. Causal 与 Temporal 是互补关系

移除 Causal Edge：

0.700 → 0.644

移除 Temporal Backbone：

0.700 → 0.647

两者带来的性能损失非常接近。

论文据此认为：

Causal Structure
+
Temporal Structure

提供的是两种互补、不可完全替代的 Reasoning Dimension。

一个回答：

Why?

另一个更擅长回答：

When?

这也正是论文使用 Multi-Graph 而不是单一 Graph Relation 的原因。

26. Entity Graph 的作用相对更小，但仍然有效

移除 Entity Links 后：

0.700 → 0.666

下降幅度比 Causal 和 Temporal 更小。

论文认为 Entity Graph 主要帮助：

保持 Entity Permanence；
聚合同一 Entity 在不同 Session 中的历史；
减少 Entity-centric Query 中的 Hallucination。

因此四种 Relation 并不是贡献完全相同。

27. Single-Graph Ablation

论文进一步只保留一种主要 Relation Graph。

Graph Configuration	Multi-Hop	Temporal	Open-Domain	Single-Hop	Adversarial	Overall
Causal Only	0.470	0.460	0.430	0.650	0.680	0.590
Temporal Only	0.440	0.620	0.450	0.650	0.520	0.577
Entity Only	0.485	0.420	0.460	0.640	0.450	0.531
Full MAGMA	0.528	0.650	0.517	0.776	0.742	0.700

三个 Single-Graph Variant 的 Overall 都没有超过：

0.60

其中：

Causal Only   = 0.590
Temporal Only = 0.577
Entity Only   = 0.531

Full MAGMA：

0.700

因此实验支持论文最核心的设计假设：

Long-Term Memory 中不同 Relation Type 解决不同类型的 Reasoning，单独依赖一种 Relation 很难覆盖所有 Query。

其中 Causal Only 的 Overall 最好，而 Temporal Only 在 Temporal Question 上表现最好。

28. 一个具体案例：为什么 Multi-Graph 有用？

论文附录用 Melanie 的 Conversation 做了一个完整例子。

历史中分散存在三个信息：

Session A:
Melanie plays violin

Session B:
Melanie also plays clarinet

Session C:
Melanie mentions her family and hiking yesterday

这些信息写入 MAGMA 后会形成：

Temporal Structure
+
Semantic Relation
+
Entity Relation
+
Normalized Time Attribute

因此面对不同 Query，可以走不同路径。

28.1 “Melanie 会什么乐器？”

Query：

What instruments does Melanie play?

系统围绕：

Entity: Melanie

访问 Entity / Semantic Neighborhood。

从两个分散 Session 找到：

violin
clarinet

论文中的 MAGMA 最终回答：

Clarinet and Violin.

相比之下，MemoryOS 只检索到：

Clarinet

A-MEM 则没有返回具体乐器。

论文将这一差异解释为：

单纯 Top-K Semantic Retrieval 容易漏掉距离较远、表面 Context 不相似的 Memory；Entity-centric Traversal 则可以通过相同人物把这些 Event 聚合起来。

28.2 “Melanie 有几个孩子？”

这个问题需要跨多个 Event 组合信息。

历史中的某个照片描述出现：

two children

而另一个 Event 还提到：

son

如果只做局部抽取，很容易回答：

MAGMA 则通过 Entity Resolution 将多个 Event 放到同一个 Evidence Set 中，论文案例给出的结果为：

At least three.

这个案例用于说明：

Retrieval 不只是找到一句最像 Query 的文本，有些问题需要将多个分散 Event 通过结构关系组合。

28.3 “她是什么时候徒步的？”

Conversation Session 的时间是：

20 October 2023

但用户说的是：

we just did it yesterday

直接使用 Session Timestamp 会得到：

20 October

而 MAGMA 在 Memory Construction 时解析：

yesterday

因此 Event 中保存：

date = 2023-10-19

最终回答：

19 October 2023

该案例体现 Temporal Graph / Temporal Parsing 的价值：

时间信息不是等到 Query Time 才完全依赖 LLM 临场解释，而是在 Memory Structure 中显式保留。

29. 为什么论文把 LLM-as-a-Judge 作为主要指标？

这一篇论文的主实验结果需要注意一个重要设置：

主指标 = LLM-as-a-Judge
Judge = gpt-4o-mini

而实验中的 Backbone 同样统一使用：

gpt-4o-mini

论文没有只给 Judge Score，还在附录报告了传统 F1 和 BLEU-1。

LoCoMo 的 Overall 结果为：

Method	F1	BLEU-1
Full Context	0.140	0.096
A-MEM	0.116	0.074
MemoryOS	0.413	0.355
Nemori	0.502	0.403
MAGMA	0.467	0.378

可以看到：

如果使用 F1 / BLEU-1，Nemori 的 Overall 分数实际上高于 MAGMA。

因此论文专门在 Appendix F 中解释为什么作者仍然选择 LLM Judge 作为主指标。

29.1 作者指出的第一个问题：False Reward

传统 Token-overlap Metric 可能给“表面文字接近但事实错误”的答案较高分。

论文给出的案例包括：

compatible

和：

not compatible

尽管语义相反，因为大量 Token 相同，F1 仍可能很高。

另一个案例是：

John

与：

Sarah

如果其他句子结构基本相同，F1 也可能得到较高分。

因此作者认为：

对需要严格判断 Entity、时间和因果关系的 Memory QA，仅使用词面重合度可能产生 False Reward。

29.2 第二个问题：False Penalty

相反，如果两个答案语义一致，但：

日期格式不同；
使用同义词；
输出格式不同；

F1 / BLEU 可能很低。

论文在七个控制案例中比较了这类情况，并认为 LLM Judge 更适合判断 Semantic Equivalence。

因此论文最终：

LLM-as-a-Judge → Main Metric

F1 / BLEU-1 → Supplementary Metrics

这里需要明确的是：

“MAGMA Overall 0.700 并显著超过 Nemori”这一结论对应的是论文采用的 LLM-as-a-Judge 指标；在 Appendix 中的 F1 / BLEU Overall 上，Nemori 则高于 MAGMA。

这两组结果衡量的侧重点不同。

30. MAGMA 的设计可以概括成什么？

如果把整个系统压缩成一条数据流：

                    Memory Write
                        │
                        ▼
Conversation → Event Segmentation
                        │
                        ▼
                  Event Nodes
                        │
              ┌─────────┴─────────┐
              │                   │
         Fast Path            Slow Path
              │                   │
    Temporal Backbone       LLM Consolidation
    Vector Index                  │
              │           Causal / Entity Links
              └─────────┬─────────┘
                        ▼
               Multi-Graph Memory
                        │
                        │ Query
                        ▼
                Intent Analysis
                        │
            Semantic / Lexical /
              Temporal Signals
                        │
                        ▼
                   Anchors
                        │
                        ▼
              Adaptive Traversal
                        │
                        ▼
                Relevant Subgraph
                        │
                        ▼
              Graph Linearization
                        │
                        ▼
                   LLM Answer

因此 MAGMA 实际包含三个相互配合的核心设计：

1. Multi-Relational Memory Representation

Semantic
Temporal
Causal
Entity

分别建模。

2. Intent-Aware Retrieval

Query 不同，Graph Traversal Strategy 也不同。

3. Dual-Stream Memory Evolution

在线阶段快速写入，后台异步建立复杂关系。

三者缺一不可。

31. 与普通 Vector Memory 的根本区别

传统 Vector Memory 更接近：

Memory Item
    ↓ embedding

Query
    ↓ embedding

Cosine Similarity
    ↓
Top-K

它回答的是：

哪些历史内容和这个 Query 最像？

MAGMA 则进一步问：

这个 Query 在问什么类型的问题？
        ↓
需要哪一种关系？
        ↓
从哪些 Event 开始？
        ↓
沿什么 Edge 向外扩展？
        ↓
应该以什么逻辑顺序组织这些 Evidence？

因此 Retrieval 从：

Similarity Search

变成：

Intent-aware Structural Retrieval

这也是论文所谓：

Policy-Guided Graph Traversal

的核心含义。

32. MAGMA 与普通 Knowledge Graph Memory 的区别

MAGMA 虽然使用 Graph，但论文并不只是提出：

把 Conversation 转成 Knowledge Graph。

其设计重点还包括：

Relation Disentanglement

Semantic、Temporal、Causal、Entity 被显式区分。

Query-adaptive Routing

Query Intent 决定关系权重。

Anchor Retrieval

仍然结合 Vector / Keyword / Temporal Signal 找入口。

Adaptive Traversal

不是直接读取整个 Graph，而是 Query-dependent Search。

Graph Linearization

Retrieved Subgraph 最终按 Query Logic 重排并转成 Prompt。

Online Memory Evolution

新的 Interaction 不断进入 Graph。

因此 MAGMA 的完整设计横跨：

Memory Representation
+
Memory Construction
+
Memory Retrieval
+
Context Construction

而不只是一个 Graph Storage Format。

33. 论文的局限性

论文明确指出三个主要局限。

33.1 Graph 质量依赖 LLM

Slow Path 中的：

Causal Inference
Entity Relation Inference

需要依赖 LLM。

因此如果 LLM：

Extraction 错误；
推理错误；
Hallucinate Relation；

就可能产生错误的 Edge。

而错误 Graph Structure 又可能继续影响后续 Retrieval。

论文通过：

Structured Prompt；
Conservative Threshold；

尽量减少这种问题，但无法完全消除。

33.2 Multi-Graph 带来额外存储和工程复杂度

相比：

Flat Vector Database

MAGMA 需要维护：

Vector Index
Semantic Graph
Temporal Graph
Causal Graph
Entity Graph
Async Queue
Consolidation Worker

因此系统实现与 Memory Overhead 都更高。

论文指出，在资源高度受限的 Environment 中，这可能影响适用性。

33.3 实验场景仍然有限

论文主要测试：

LoCoMo
LongMemEval

这两个 Benchmark 都集中在：

Long-Context Conversation
Agent Memory
Temporal / Causal Reasoning

但真实 Agent Memory 还可能涉及：

Multimodal Input；
heterogeneous observation streams；
更复杂的 Environment Interaction。

论文认为，将 MAGMA 扩展到这些场景可能需要额外 Adaptation 与 Calibration。

34. 总结

MAGMA 关注的是 Agent Memory 中一个很基础的问题：

Memory 中不同 Event 之间究竟是什么关系？

传统方案往往将大量关系隐式压缩为 Semantic Similarity：

Query
→ 找语义相似 Memory

MAGMA 则显式区分：

Semantic
Temporal
Causal
Entity

并让 Query Intent 控制 Retrieval：

WHY    → 更重视 Causal
WHEN   → 更重视 Temporal
ENTITY → 更重视 Entity

检索流程也从单纯 Vector Top-K 扩展为：

Query Analysis
→ Multi-Signal Anchor Retrieval
→ Adaptive Graph Traversal
→ Subgraph
→ Structure-aware Linearization
→ LLM

与此同时，Memory Update 使用：

Fast Path
+
Asynchronous Slow Path

将 Event 的快速写入与昂贵的 LLM Structural Reasoning 分开。

从实验来看，MAGMA 在论文采用的 LLM-as-a-Judge 指标上取得：

LoCoMo Overall = 0.700

超过 A-MEM、MemoryOS、Nemori 和 Full Context。

在 LongMemEval 上平均 Accuracy 为：

61.2%

同时只使用约：

0.7K–4.2K tokens

的检索 Context，而 Full Context 约为 101K Tokens。

Ablation 进一步显示：

Adaptive Policy
Causal Structure
Temporal Structure
Entity Structure

都对最终性能有贡献，其中移除 Adaptive Policy 带来的下降最大。

因此，这篇论文的核心并不是单独提出某一种新的 Memory Graph，而是建立了一套完整的：

Multi-Relation Memory Representation
+
Intent-Aware Graph Retrieval
+
Dual-Stream Memory Evolution

框架，使 Agent 可以根据当前问题所需要的推理类型，以不同关系视角访问同一段长期历史。

参考

Dongming Jiang, Yi Li, Guanpeng Li, Bingzhe Li. MAGMA: A Multi-Graph based Agentic Memory Architecture for AI Agents. ACL 2026, Volume 1: Long Papers.
https://aclanthology.org/2026.acl-long.1709/
MAGMA PDF
https://aclanthology.org/2026.acl-long.1709.pdf
arXiv:2601.03236
https://arxiv.org/abs/2601.03236
MAGMA GitHub Repository
https://github.com/FredJiang0324/MAGMA

posted @ 2026-09-15 10:06 YourF4u1t 阅读(13) 评论(0) 收藏举报

刷新页面返回顶部