前言

在长期对话中，Agent 记住一个事实并不算特别困难，真正困难的是：事实会随时间发生变化。

例如，用户在一月份说：

我最喜欢的餐厅是 Italian Garden。

到了三月份，用户又说：

Italian Garden 已经关门了，我现在经常去 Sakura Sushi。

如果记忆系统采用简单覆盖策略，那么新的偏好会直接替换旧偏好。此时 Agent 可以回答“用户现在最喜欢哪家餐厅”，却未必还能回答：

• 用户以前喜欢哪家餐厅？
• 用户什么时候改变了偏好？
• 为什么不再去原来的餐厅？
• 某个时间点上哪条信息有效？

如果记忆系统不覆盖旧信息，而是把两条记录都放进向量数据库，那么检索时又可能同时召回两个互相冲突的答案。模型虽然看到了完整信息，却不知道哪一条才适用于当前问题。

因此，长期对话记忆需要解决的并不只是“能否召回”，还包括：

1. 如何识别不同对话中提到的是同一个实体；
2. 如何保存事实产生、变化和失效的时间；
3. 如何保留旧事实，而不是过早覆盖；
4. 如何在查询时根据问题的时间语义解决冲突；
5. 如何避免将整个对话历史重新塞回上下文。

APEX-MEM 的核心思路是：

写入记忆时，不急于判断哪条事实应该覆盖哪条事实，而是以追加方式保存事实的完整演化过程；等用户真正提问时，再由多工具检索 Agent 根据时间、实体、关系和证据决定哪条信息有效。

为此，APEX-MEM 将对话转换为带有时间信息的属性图，并使用 EntityLookup、GraphSQL、Search 等工具完成实体定位、图遍历、时间计算和语义检索。

这篇论文最值得关注的地方不是简单地“把对话存成知识图谱”，而是将以下三部分组合起来：

实体—事件混合本体
+
追加式事实存储
+
查询时冲突消解

---

零、论文基本信息

• 论文名称：APEX-MEM: Agentic Semi-Structured Memory with Temporal Reasoning for Long-Term Conversational AI
• 发表平台：ACL 2026 Main
• 代码仓库：论文当前版本未提供公开代码仓库
• 作者信息：Pratyay Banerjee、Masud Moshtaghi、Shivashankar Subramanian、Amita Misra、Ankit Chadha，Amazon AGI

---

一、背景与问题

1. 更长的上下文不等于更可靠的记忆

解决长期对话记忆最直接的方法，是把所有历史对话放入上下文。

但是，随着历史不断增长，模型面对的不只是更多有用信息，也包括更多噪声：

• 与当前问题无关的对话；
• 已经过期的个人偏好；
• 表述不同但实际相同的实体；
• 相互矛盾的事实；
• 重复出现的内容；
• 缺少明确时间锚点的信息。

即使上下文窗口足够大，模型也可能因为噪声过多而选错事实。

因此，长期记忆系统的目标不应该只是“保存尽可能多的内容”，而应该是：

在保留完整历史的同时，为当前问题提供规模较小、时间一致且证据明确的记忆上下文。

2. 传统 RAG 缺少实体和时间建模

传统对话 RAG 通常将历史切分为文本片段，然后通过语义相似度检索。

这种方法适合回答：

用户以前有没有提到过跑步？

但面对下面的问题时就会比较困难：

用户现在住在哪里？
用户搬家之前住在哪里？
用户什么时候换了工作？
用户换工作后通勤时间增加了多少？

原因在于，普通文本片段没有显式表示：

• 哪个实体是事实主体；
• 不同称呼是否指向同一个实体；
• 事实从什么时候开始有效；
• 事实什么时候失效；
• 多个事实之间是什么关系；
• 当前问题询问的是过去还是现在。

3. 覆盖式记忆会丢失事实演化过程

很多记忆系统会对新旧事实执行 UPDATE 或 DELETE。

例如：

旧记忆：用户住在上海
新记忆：用户住在北京

系统可能将旧记忆直接更新为：

用户住在北京

这种方式适合回答当前状态，却丢失了迁移过程。

如果之后用户询问：

我搬到北京之前住在哪里？

系统已经没有足够的信息回答。

APEX-MEM 因此选择追加式存储：

事实 1：用户住在上海，有效时间从 T1 开始
事实 2：用户住在北京，有效时间从 T2 开始

旧事实不会因为新事实出现而立即删除。查询时，Agent 再根据问题中的时间条件选择对应事实。

4. 本文要解决的问题

APEX-MEM 主要回答以下问题：

1. 如何把非结构化对话转换成可查询的半结构化记忆？
2. 如何同时表示实体、事件、事实、时间和原始证据？
3. 如何避免写入阶段的错误覆盖？
4. 如何让 Agent 根据问题自主选择不同检索工具？
5. 如何在超长历史中只为相关文档构建记忆图？

---

二、相关工作

1. 基于长上下文的对话记忆

这类方法直接将更多历史对话提供给模型。

优点是：

• 实现简单；
• 原始信息保存完整；
• 不需要额外记忆写入流程。

局限是：

• 输入成本随历史长度增加；
• 无关信息会干扰回答；
• 事实冲突需要模型在长文本中自行解决；
• 时间关系没有被显式表示。

2. 基于文本检索的记忆系统

MemGPT、ReadAgent、MemoryBank 等方法通过分层记忆、摘要或检索减少输入内容。

这类方法的核心是：

保存对话文本或摘要
↓
根据当前问题检索
↓
将相关文本放入上下文

它们缓解了上下文增长问题，但文本检索仍然难以稳定处理实体对齐、多跳关系和事实演化。

3. 结构化长期记忆

Mem0、A-MEM、Zep、MIRIX 等方法开始使用图结构、记忆链接或多个专用记忆库。

这些方法分别关注：

• Mem0：事实记忆的写入、更新和删除；
• A-MEM：记忆之间的动态关联和演化；
• Zep：带有时间信息的知识图谱；
• MIRIX：通过多个专用记忆模块管理不同信息。

APEX-MEM 与这些方法最重要的区别在于：

它把对话事件当作一等对象，并将事实变化完整保存在追加式事件图中，在查询阶段再执行时间解析和冲突消解。

4. APEX-MEM 的定位

方法	主要记忆表示	旧事实处理方式	时间推理方式
普通 RAG	文本片段	全部保留	依赖模型阅读文本
Mem0	事实或关系	ADD、UPDATE、DELETE	以当前事实为主
A-MEM	动态关联笔记	更新与链接	依赖记忆内容
Zep	时间知识图谱	部分保留时间演化	图检索与文本检索
MIRIX	多种专用记忆库	状态合并	多 Agent 路由
APEX-MEM	实体—事件属性图	追加式保存	查询时使用时间图遍历和 SQL

---

三、方法总览

为了理解 APEX-MEM 的完整数据流，可以先看论文 Figure 1。

图源：论文 Figure 1。
该图展示了对话或外部文档如何经过事件提取、实体解析和事实抽取写入属性图，以及查询 Agent 如何通过多个工具访问图数据库并回答问题。

APEX-MEM 可以分为两个阶段。

1. 记忆构建阶段

对话或文档
↓
按时间排序
↓
提取事件、实体和事实
↓
实体与属性消歧
↓
将事实关联到时间事件
↓
追加到属性图

2. 记忆查询阶段

用户问题
↓
识别实体和时间条件
↓
选择 EntityLookup、GraphSQL 或 Search
↓
检索事实、事件和原始证据
↓
解决事实冲突
↓
生成紧凑记忆摘要和最终答案

其中，底层属性图在论文实现中由 SQLite 表结构承载，包括：

• sessions；
• turns；
• events；
• entities；
• properties；
• facts；
• evidence；
• event_participants。

因此，APEX-MEM 虽然在概念上是属性图，但当前实现并不是专用图数据库，而是通过 SQLite 表和只读 SQL 模拟图查询。

---

四、核心模块详解

4.1 时间属性图

1. 设计动机

普通知识图谱通常使用三元组表示事实：

$$\left(\text{subject},\text{relation},\text{object}\right)$$

例如：

Alice --favorite_restaurant--> Italian Garden

但这个表示没有说明：

• Alice 从什么时候开始喜欢这家餐厅；
• 这条事实现在是否仍然有效；
• 事实来自哪一次对话；
• 模型为什么相信这条事实；
• 新事实出现后旧事实如何处理。

APEX-MEM 因此使用带属性的有向图。

2. 图的形式化定义

论文将 APEX-MEM 定义为：

$$G=(V,E,\Pi ,\Lambda )$$

其中：

• $V$ 表示节点集合，包括实体、事件和事实等；
• $E\subseteq V\times V$ 表示带类型和标签的有向边；
• $\Pi$ 为节点和边附加键值属性；
• $\Lambda$ 为每个节点和边指定本体类型。

对于每个输入文档 $d_i$，系统会构建一个局部子图 $g_i$，然后逐步合并到全局图中：

$$G^{(t+1)}\leftarrow \mathrm{Merge}\left(G^{(t)},g_t\right)$$

合并过程中不会简单地把所有节点重复插入，而是先执行实体和属性解析，判断新提及是否应该链接到已有实体。

3. 属性图相比普通三元组的优势

属性图可以为事实保存更多信息，例如：

主体：Alice
属性：favorite_restaurant
值：Italian Garden
数据类型：string
开始时间：2024-01-15
结束时间：未知
置信度：0.96
证据：Session 1，Turn 8

这些属性使系统能够进一步回答：

• 当前值是什么？
• 某个时间点的值是什么？
• 事实何时发生变化？
• 哪段原始对话支持该事实？

---

4.2 实体—事件混合本体

1. 为什么不能只围绕实体建图

如果记忆图只存储实体之间的关系，那么下面两句话可能被压缩成两个静态事实：

Alice 喜欢 Italian Garden。
Alice 喜欢 Sakura Sushi。

系统知道 Alice 与两家餐厅都有关系，却不知道：

• 两件事发生的先后顺序；
• 后一个偏好是否替代前一个偏好；
• 变化发生在哪次对话；
• 用户为什么改变偏好。

因此，APEX-MEM 同时建模实体和事件。

2. 实体表示

一个实体表示为：

$$e=(n,\tau ,\rho ,\mathrm{id})$$

其中：

• $n$ 表示实体名称；
• $\tau$ 表示实体类型；
• $\rho$ 表示它在对话中的角色；
• $\mathrm{id}$ 表示可选的外部标识符。

论文定义了 35 种领域无关的实体类型，包括：

• Person；
• Organization；
• Place；
• Event；
• Time；
• Product；
• Device；
• Software；
• Dataset；
• Document；
• Medication；
• Disease；
• Topic；
• Task。

对话角色包括：

• Speaker；
• Listener；
• Agent；
• Mentioned。

3. 事实表示

一个事实表示为：

$$f=(s,p,v,\delta ,[t_{\mathrm{from}},t_{\mathrm{to}}],c,\mathcal{E})$$

其中：

• $s$ 表示事实主体；
• $p$ 表示属性或关系；
• $v$ 表示属性值；
• $\delta$ 表示值的数据类型；
• $[t_{\mathrm{from}},t_{\mathrm{to}}]$ 表示事实有效时间；
• $c\in [0,1]$ 表示置信度；
• $\mathcal{E}$ 表示支持该事实的证据集合。

4. 事件表示

所有事实都会关联到一个对话事件：

$$\epsilon =(\mathrm{type},T,L,P,F,{\mathcal{E}}_{\epsilon })$$

其中：

• $\mathrm{type}$ 表示事件类型；
• $T$ 表示事件时间；
• $L$ 表示地点；
• $P$ 表示参与实体；
• $F$ 表示事件包含的事实；
• ${\mathcal{E}}_{\epsilon }$ 表示事件的原始文本证据。

通过把事实挂载到事件上，系统能够同时保留：

谁
在什么时候
参与了什么事件
产生了什么事实
事实由哪段文本支持

---

4.3 实体与属性解析

1. 设计动机

长期对话中，同一个实体可能有多种表述：

Sakura Sushi
那家寿司店
我常去的日本餐厅
上次说的餐厅

如果系统把这些表述全部创建成不同实体，图中就会出现大量重复节点，多跳查询也会断裂。

2. 实体解析流程

对于对话中的实体提及 $m$，系统首先通过向量索引检索已有候选实体：

C = { c 1 , c 2 , … , c k } C=\{c_1,c_2,\ldots,c_k\} C={c1​,c2​,…,ck​}

每个候选实体包含：

• 实体 ID；
• 文本表示；
• 相似度分数。

然后，结构化 LLM 根据当前提及、上下文和候选实体作出三类决策：

choose_existing：链接到已有实体
propose_new：创建新实体
none：当前内容不需要形成实体

输出还包括：

• 标准化名称；
• 实体类型；
• 别名；
• 置信度；
• 判断理由。

3. 属性解析

属性解析采用类似流程，将不同表述归一化为统一属性。

例如：

最喜欢的餐厅
常去的餐厅
favorite restaurant

可能统一为：

favorite_restaurant

属性值还会被识别为不同数据类型：

• string；
• integer；
• float；
• boolean；
• date；
• datetime；
• enum；
• URL；
• list。

4. 工程意义

实体解析是图记忆系统最基础、也最容易出错的环节。

如果实体链接错误，那么后续即使 SQL 完全正确，也只能在错误的图结构上推理。

论文案例中就出现了这种失败：

问题：Bob 上个月去了几次巴黎的餐厅？

系统识别出了餐厅实体，但没有从“Eiffel Tower”等上下文线索推断餐厅位于巴黎，导致空间关系缺失，最终无法正确统计。

---

4.4 事实与事件抽取

1. 输入

系统将每个对话轮次表示为：

$$u=(s,l,\mathrm{text},t_{\mathrm{anchor}},\mathrm{ctx})$$

其中：

• $s$ 是说话者；
• $l$ 是接收者；
• $\mathrm{text}$ 是当前文本；
• $t_{\mathrm{anchor}}$ 是当前对话时间；
• $\mathrm{ctx}$ 是最近对话上下文。

2. 处理流程

系统使用带少样本示例的 LLM，从当前对话中抽取：

• 参与实体；
• 事件类型；
• 事件地点；
• 事实；
• 数据类型；
• 时间表达；
• 置信度；
• 原始证据位置。

相对时间会根据锚点时间转换为 ISO 8601 时间。

例如：

我昨天报名了一个陶艺课。

如果当前对话发生在 2023 年 5 月 8 日，那么“昨天”可以归一化为：

2023-05-07

3. 输出示例

实体：用户
类型：PERSON

事件：报名陶艺课
事件时间：2023-05-07

事实：
- enrolled_activity = pottery class
- activity_benefit = therapy
- emotional_outlet = true

证据：
- Session 3
- Turn 12
- 原始文本片段

4. 为什么需要保留证据

结构化抽取可能出错，因此不能只保留最终三元组。

APEX-MEM 会将事实链接回原始对话证据，使检索 Agent 可以：

• 检查事实是否被正确抽取；
• 在冲突时比较原始表述；
• 为回答提供可追溯依据；
• 避免完全依赖图中某个简化字段。

---

4.5 追加式事实存储

1. 设计动机

很多记忆系统在发现新事实后立即更新旧事实：

UPDATE favorite_restaurant
SET value = 'Sakura Sushi'
WHERE user = 'Alice';

APEX-MEM 认为，这种写入时合并可能过早丢失信息。

新事实并不一定代表旧事实错误，它也可能表示：

• 用户偏好发生了变化；
• 事实只在某段时间有效；
• 两条信息来自不同视角；
• 新信息只是对旧信息的补充；
• 当前还无法判断哪条更可信。

2. 追加式策略

APEX-MEM 不直接覆盖旧事实，而是保存两条时间记录：

事实 1：
Alice.favorite_restaurant = Italian Garden
from = 2024-01-15

事实 2：
Alice.favorite_restaurant = Sakura Sushi
from = 2024-03-20

查询当前偏好时，Agent 可以按照时间排序，选择最新有效事实。

查询历史偏好时，旧事实仍然存在。

3. 查询时冲突消解

APEX-MEM 将冲突处理从写入阶段推迟到查询阶段：

写入阶段：
保留事实及其时间、证据和置信度

查询阶段：
根据问题时间
+ 事实有效期
+ 事件顺序
+ 原始证据
决定使用哪条事实

这个设计可以概括为：

Write everything with provenance, resolve only when the question provides context.

4. 示例

用户历史：

2024-01-15：
我最喜欢 Italian Garden，那里的意面最好吃。

2024-03-20：
Italian Garden 上个月关门了，我现在每周都去 Sakura Sushi。

APEX-MEM 不删除第一条事实。

当问题是：

Alice 现在最喜欢哪家餐厅？

系统选择时间最新的 Sakura Sushi。

当问题是：

Italian Garden 关门前，Alice 最喜欢哪家餐厅？

系统仍然能够找到 Italian Garden。

当问题是：

Alice 的餐厅偏好是什么时候变化的？

系统可以比较两个事件的时间并回答变化发生在 2024 年 3 月前后。

---

4.6 多工具图检索 Agent

APEX-MEM 使用 ReAct 风格的问答 Agent。

在第 $t$ 步，Agent 根据问题和历史生成推理轨迹与动作：

$$\left(r_t,a_t\right)\sim {\pi }_{\theta }(\cdot \mid x,h_t)$$

其中：

• $x$ 表示用户问题；
• $h_t$ 表示当前工具交互历史；
• $r_t$ 表示推理过程；
• $a_t$ 表示工具调用或最终回答。

Agent 可以选择四种工具。

1. SchemaViewer

设计动机

LLM 不一定知道数据库有哪些表、字段以及它们之间的关系。

如果直接生成 SQL，容易出现：

• 使用不存在的字段；
• 混淆事实时间与事件时间；
• 连接错误的表；
• 不知道应该先查实体还是查事件。

功能

SchemaViewer 返回：

• 数据库结构；
• 查询示例；
• 工具使用说明；
• 时间推理建议。

它相当于 Agent 的元级规划辅助工具。

2. EntityLookup

设计动机

很多问题首先需要把自然语言中的称呼链接到图中的标准实体。

流程

自然语言实体名称
↓
语义检索 + 关键词检索
↓
候选实体 ID
↓
返回实体最新事实、历史事实和时间锚点

EntityLookup 适合：

• 查询人物属性；
• 定位实体 ID；
• 获取实体近期状态；
• 为后续 GraphSQL 提供规范化标识。

3. GraphSQL

设计动机

语义检索擅长寻找相关内容，却不擅长精确计算和多跳关系推理。

GraphSQL 提供只读 SQLite 查询接口，只允许：

SELECT ...

或：

WITH ... SELECT ...

并禁止 UPDATE、DELETE 和 DDL 操作。

GraphSQL 适合：

• 多表连接；
• 多跳实体关系；
• 时间排序；
• 有效期过滤；
• 时长计算；
• 数量统计；
• 聚合分析。

例如，问题：

Bob 的经理的职位是什么？

可以转化为：

Bob
↓ reports_to
Sarah Chen
↓ job_title
VP of Engineering

4. Search

设计动机

并不是所有问题都适合先生成精确 SQL。

开放式问题或表述模糊的问题更适合先进行语义检索，快速获得相关子图。

Search 返回的上下文包括：

$$T_{\mathrm{search}}(q)=(E_q,P_q,{\mathcal{V}}_q,{\mathcal{T}}_q)$$

其中：

• $E_q$ 是候选实体；
• $P_q$ 是候选属性；
• ${\mathcal{V}}_q$ 是相关事件和证据；
• ${\mathcal{T}}_q$ 是相关原始对话轮次。

5. 四种工具如何配合

SchemaViewer
→ 理解图结构和查询策略

EntityLookup
→ 定位标准实体并查看实体快照

Search
→ 快速检索相关子图和文本证据

GraphSQL
→ 执行精确的时间、多跳和聚合推理

这种组合避免了两种极端：

• 只使用语义检索，缺少精确推理；
• 只使用 SQL，需要大量调用探索图结构。

---

4.7 在线图构建

1. 设计动机

当历史文档超过 $10^3$ 时，为所有内容完整构建图的成本可能过高，而且很多文档与用户问题无关。

2. 在线构建方法

给定文档集合 $D$ 和问题 $Q$，系统先执行语义和关键词检索，只选择相关性超过阈值的文档：

D r e l = { d i ∈ D ∣ R e l e v a n c e ( d i ∣ Q ) > Θ r e l } D_{\mathrm{rel}}=\{d_i\in D\mid \mathrm{Relevance}(d_i\mid Q)>\Theta_{\mathrm{rel}}\} Drel​={di​∈D∣Relevance(di​∣Q)>Θrel​}

然后按照时间顺序，仅为 $D_{\mathrm{rel}}$ 构建局部 APEX-MEM 图。

论文在 LongMemEval 和 SealQA-Hard 中采用在线构建，并设置：

$${\Theta }_{\mathrm{rel}}>0.2$$

3. 在线构建的取舍

优点：

• 避免为全部历史支付抽取成本；
• 降低图规模；
• 减少无关信息。

局限：

• 如果预检索阶段漏掉关键文档，后续图推理无法恢复；
• 图结构受当前问题影响，不再是完整全局记忆；
• 不同问题可能重复构建相似局部图。

因此，在线 APEX-MEM 本质上是：

先通过传统检索缩小范围，再对相关内容进行结构化和时间推理。

---

五、实验设置

5.1 数据集

1. LOCOMO

LOCOMO 用于评估跨多次会话的长期对话记忆，问题分为：

• Single-Hop；
• Multi-Hop；
• Temporal；
• Open-Domain；
• Adversarial。

其中 Adversarial 是不可回答问题，用于测试系统能否抵抗无关或误导性信息。

2. LongMemEval

LongMemEval 关注：

• 超长输入；
• 跨会话事实召回；
• 时间推理；
• 多会话知识整合；
• 对上下文长度变化的泛化。

3. SealQA-Hard

SealQA-Hard 面向带有冲突和噪声的搜索增强问答。

每个问题包含 30 篇网页检索文档，其中只有 1 到 2 篇是金标准相关文档，并且位置不固定。

论文按照文档发布时间排序，将每篇文档视为一次 Agent 与世界的交互，用来测试追加式记忆面对冲突信息时的表现。

5.2 模型配置

APEX-MEM 的不同阶段使用不同模型：

• 事实抽取：Claude Sonnet 4.5；
• 实体与属性解析：Claude Haiku 4.5；
• 问答 Agent：Claude 4.5 Haiku、Claude 4.5 Sonnet、Claude 3.5 Sonnet、GPT-5、GPT-4o 等。

之所以没有全部使用同一个模型，是为了在效果和成本之间平衡：

• 事实抽取需要更强的结构化理解能力；
• 实体解析任务相对简单，可以使用成本更低的模型；
• 问答阶段则测试不同模型后端的泛化能力。

5.3 其他设置

• ReAct 工具调用上限：40 次；
• 推理温度：0；
• LLM-as-a-Judge：报告 3 次评估均值；
• 标准差小于 $\pm 1$；
• LOCOMO：为每组完整会话构建全量图；
• LongMemEval、SealQA-Hard：使用在线图构建；
• LongMemEval 检索基线：返回 Top-5 相关 Session。

---

六、实验结果与分析

6.1 记忆图构建质量

论文从 LOCOMO 和 LongMemEval 中随机选择 500 个对话轮次，使用 GPT-5 作为 Judge，评价：

• Fact Extraction：抽取事实的准确性；
• Schema Coverage：合理属性是否被完整覆盖；
• Entity/Property Resolution：实体与属性是否被正确链接。

Table 2 的结果如下：

构建模型	事实抽取	Schema 覆盖	实体/属性解析
GPT-4o	94.2%	75.7%	98.1%
Claude Sonnet 4.5	97.3%	91.1%	98.2%
Claude Haiku 4.5	95.8%	90.3%	95.4%
Qwen3-14B	95.4%	88.9%	92.5%

Claude Sonnet 4.5 在事实抽取和 Schema 覆盖上最好，因此论文使用它执行事实抽取。

Claude Haiku 4.5 的实体解析达到 95.4%，同时成本相对较低，因此用于实体和属性解析。

这里也说明，APEX-MEM 的最终效果并不只取决于图结构，还高度依赖前置抽取模型。图构建阶段一旦漏掉事实，后续检索 Agent 无法查询到不存在的节点和关系。

6.2 LOCOMO 主要结果

Table 1 中的关键结果如下：

方法	Single-Hop	Multi-Hop	Temporal	Open-Domain	Adversarial	Overall
APEX-MEM + GPT-5	89.88%	86.29%	90.63%	91.68%	86.77%	88.88%
APEX-MEM + Claude 4.5 Sonnet	89.36%	86.92%	90.63%	87.75%	86.10%	88.41%
APEX-MEM + GPT-4o	88.47%	85.46%	83.49%	86.46%	84.98%	86.35%
MIRIX	85.11%	83.70%	65.62%	88.39%	N/A	85.38%
Nemori	84.90%	75.10%	77.60%	51.00%	N/A	79.40%
Mem0	65.71%	47.19%	75.71%	58.13%	N/A	68.44%
Zep	61.70%	41.35%	76.60%	49.31%	N/A	75.14%
Full Context + GPT-4o	88.53%	77.70%	71.88%	92.70%	N/A	87.52%

APEX-MEM 使用 GPT-5 时总体准确率为 88.88%，比此前表现较强的 MIRIX 高 3.50 个百分点。

其中最明显的是时间问题：

• APEX-MEM + GPT-5：90.63%；
• MIRIX：65.62%；
• Mem0：75.71%；
• Zep：76.60%。

这说明保留事实演化和时间证据，确实有助于回答“之前”“现在”“何时改变”等问题。

不过，这组结果需要谨慎解读。

APEX-MEM + GPT-4o 的总体结果为 86.35%，略低于 Full Context + GPT-4o 的 87.52%。

APEX-MEM 的主要优势体现在：

• 时间问题从 71.88% 提升到 83.49%；
• 多跳问题从 77.70% 提升到 85.46%；
• 可以输出更聚焦、结构化的记忆结果。

但在开放域问题上，Full Context + GPT-4o 的 92.70% 高于 APEX-MEM + GPT-4o 的 86.46%。

因此，论文最高的 88.88% 不应全部归因于记忆架构，问答模型从 GPT-4o 更换为 GPT-5 也会影响最终结果。

6.3 LongMemEval

Table 4 的结果如下：

方法	问答模型	Overall
APEX-MEM Online	Claude 4.5 Sonnet	86.2%
APEX-MEM Online	GPT-5	85.2%
APEX-MEM Online	Claude 4.5 Haiku	82.8%
APEX-MEM Online	GPT-4o	75.0%
Nemori	未注明	74.6%
Session Search Top-5	Claude 4.5 Sonnet	72.5%
Mem0	未注明	71.3%
Zep	未注明	71.2%
A-MEM	未注明	59.3%
Full Context	Claude 4.5 Sonnet	62.2%

APEX-MEM Online + Claude 4.5 Sonnet 达到 86.2%，比：

• Nemori 高 11.6 个百分点；
• Session Search Top-5 高 13.7 个百分点；
• Full Context + Claude 4.5 Sonnet 高 24 个百分点。

相比 LOCOMO，这组结果更能体现结构化记忆的价值，因为 APEX-MEM 与 Full Context 使用了相同的 Claude 4.5 Sonnet 问答模型。

这说明在超长、多会话环境中，先筛选相关文档、再构建时间属性图，能够比直接输入完整历史更好地抑制噪声。

6.4 工具消融实验

Table 3 比较了不同工具组合：

工具组合	Single-Hop	Multi-Hop	Temporal	Open-Domain	Adversarial	Overall
SchemaViewer + EntityLookup	80.85%	76.64%	72.92%	76.34%	77.80%	77.19%
+ GraphSQL	80.78%	79.75%	82.29%	78.00%	81.16%	79.45%
+ Search	85.46%	84.74%	79.17%	89.18%	87.22%	87.00%

加入 GraphSQL 后：

• 总体准确率从 77.19% 提升到 79.45%；
• 多跳问题从 76.64% 提升到 79.75%；
• 时间问题从 72.92% 提升到 82.29%。

这说明 SQL 的连接、排序和时间计算能力主要帮助结构化推理任务。

进一步加入 Search 后：

• 总体准确率提升到 87.00%；
• 开放域问题从 78.00% 提升到 89.18%；
• 多跳问题提升到 84.74%；
• 对抗问题提升到 87.22%。

不过，完整系统的时间准确率为 79.17%，反而低于 GraphSQL 组合的 82.29%。

这说明 Search 虽然提高了总体覆盖率，却可能引入更多文本噪声。对于精确时间问题，GraphSQL 有时比混合检索更稳定。

6.5 为什么不能只使用 GraphSQL

论文统计发现，只使用 GraphSQL 的系统需要 27282 次工具调用，而完整混合系统只需要 8260 次，前者约为后者的 3.3 倍。

原因是 GraphSQL Agent 需要反复完成：

查看 Schema
↓
寻找实体
↓
确认属性名称
↓
生成 SQL
↓
处理 SQL 错误
↓
重新查询

而 Search 可以先快速提供相关子图，EntityLookup 可以直接返回实体快照，再由 GraphSQL 完成必要的精确推理。

因此，不同工具的职责是互补的：

• Search 负责提高召回；
• EntityLookup 负责实体定位；
• GraphSQL 负责精确推理；
• SchemaViewer 负责降低查询错误。

6.6 SQL 执行与错误恢复

附录 Table 11 显示：

问答模型	SQL 成功率
Claude Sonnet 4.5	97.6%
GPT-5	93.4%
Claude Haiku 4.5	95.4%
Claude Sonnet 4.5（GraphSQL Only）	98.8%

Agent 能够从约 87% 的 SQL 失败中恢复，主要方式包括：

• 45%：重新调用 SchemaViewer 检查表结构；
• 28%：退回 EntityLookup 获取实体信息；
• 14%：退回 Search 使用语义检索。

这说明多工具架构不仅是为了提高召回，也形成了工具级错误恢复机制。

6.7 SealQA-Hard

Table 5 的关键结果如下：

方法	模型	Accuracy
APEX-MEM Online	GPT-5	40.1%
APEX-MEM Online	Claude 4.5 Sonnet	35.2%
普通搜索 Agent	GPT-5	38.6%
普通搜索 Agent	O3	34.6%
APEX-MEM Online	GPT-4o	19.0%
普通搜索 Agent	DeepSeek-R1	15.4%
普通搜索 Agent	GPT-4o	15.0%

APEX-MEM + GPT-5 达到约 40.1%，比普通 GPT-5 搜索 Agent 的 38.6% 高约 1.5 个百分点，比 O3 高 5.5 个百分点。

虽然取得了最好结果，但 40.1% 本身仍然不高。

这说明面对大量互相冲突、只有少数文档真正相关的开放式搜索环境，追加式属性图仍然不能完全解决：

• 错误事实抽取；
• 隐式关系缺失；
• 文档可信度判断；
• 复杂冲突消解；
• 长链条实体链接。

6.8 追加式存储的时间推理结果

附录 Table 12 给出了不同更新策略的时间问题结果：

系统	是否追加式	Temporal
APEX-MEM	是	90.63%
Zep	部分	76.60%
Mem0	否，事实合并	75.71%
MIRIX	否，状态合并	65.62%

APEX-MEM 比其他方法高 14 到 25 个百分点。

这支持了“保留旧事实有利于时间推理”的判断。

但需要注意，这不是严格控制变量的内部消融实验。不同系统在：

• 图结构；
• 抽取模型；
• 检索流程；
• 问答模型；
• 提示词；
• 工具数量

等方面都不完全相同。

因此，更准确的表述是：

实验结果与追加式存储的设计动机一致，但尚不能证明全部提升都来自追加式更新本身。

6.9 成本分析

APEX-MEM 的成本包含两部分：

1. 图构建成本：对话级的一次性成本；
2. 查询成本：每次问题产生的检索和 Agent 推理成本。

论文指出，图构建摊销后只占整体成本的一部分，更主要的成本来自：

• 记忆检索内容；
• 多轮 Agent 推理；
• 工具调用与返回格式；
• 系统提示词。

附录 Table 10 给出的平均每次查询 token 分解为：

组成	Token/Query	占比
图构建摊销	13557	16.6%
系统提示词	7854	9.6%
记忆检索	21745	26.6%
Agent 循环	16174	19.8%
工具格式开销	22274	27.3%
总计	81604	100%

工具格式和检索内容占比最高。

这说明 APEX-MEM 虽然减少了无关历史，却不是一个低成本的简单 RAG 系统。它将部分长上下文成本转化成了：

• 图构建成本；
• 多次工具调用；
• SQL 生成成本；
• Agent 规划成本。

在生产环境中，如果用户只偶尔查询一次，图构建成本可能难以摊销；如果同一份长期记忆会被频繁查询，结构化图的收益才更容易体现。

---

七、局限性与未来方向

1. 强依赖事实抽取质量

图数据库不会自动保证事实正确。

如果抽取模型：

• 漏掉隐式关系；
• 错误解析相对时间；
• 混淆实体；
• 错误判断属性类型；
• 将推测当成事实

那么后续 GraphSQL 只会更精确地查询错误数据。

2. 强依赖 Agent 的工具使用能力

论文发现 GPT-4o 更容易在 SQLite 查询和工具选择上出错。

这意味着 APEX-MEM 的最终能力不仅取决于记忆表示，还依赖问答模型能否：

• 理解 Schema；
• 生成正确 SQL；
• 判断应该使用哪个工具；
• 从工具错误中恢复；
• 知道何时停止检索。

因此，更换模型后，系统效果可能明显波动。

3. 工具调用次数较多

多数 Agent 需要大约 20 次工具调用才能接近性能上限。

这会带来：

• 更高延迟；
• 更多 token 消耗；
• 更多失败点；
• 更复杂的日志和监控；
• 更高推理成本。

论文提出的后续方向包括学习工具路由策略和停止条件，将平均调用次数从 20–30 次降低到 10–15 次。

4. 当前实现使用 SQLite 模拟图查询

APEX-MEM 在概念上是属性图，但实验实现使用 SQLite。

优点是：

• 部署简单；
• SQL 工具成熟；
• 便于实现只读安全限制；
• 时间计算和聚合方便。

局限是：

• 深层图遍历需要复杂 JOIN；
• Schema 发现成本较高；
• 大规模图查询效率未被充分验证；
• 图数据库是否能减少工具调用仍需实验。

5. 在线构建依赖预检索召回率

LongMemEval 和 SealQA-Hard 并没有为所有文档构建完整图，而是先检索相关文档。

如果关键文档在预检索阶段没有进入 $D_{\mathrm{rel}}$，后续再强的图推理也无法恢复。

因此，在线方案仍然继承了传统 RAG 的召回瓶颈。

6. 缺少多模态和生成任务验证

论文主要评估长期对话问答。

尚未覆盖：

• 对话摘要；
• 多模态长期记忆；
• 代码 Agent；
• 桌面操作 Agent；
• 长期任务规划；
• 主动个性化；
• 根据记忆生成长篇内容。

论文也将事件摘要和多模态对话生成列为未来方向。

7. 代码暂未公开

论文当前版本没有提供公开代码仓库。

这使得以下细节较难独立复现：

• 完整 SQLite Schema；
• 抽取和解析提示词；
• Search 混合检索权重；
• 实体合并阈值；
• LLM-as-a-Judge 提示词；
• token 成本统计口径。

---

八、我的理解和启发

1. 不要在写入阶段过早决定“真相”

很多记忆系统在写入时就必须选择：

ADD
UPDATE
DELETE
NOOP

这种设计适合稳定事实，却不一定适合随时间变化的事实。

例如：

用户喜欢跑步
用户因为受伤暂停跑步
用户恢复后重新开始跑步

这些记录不是简单的互相否定，而是一个完整的状态演化过程。

APEX-MEM 给我的最大启发是：

写入阶段应该优先保存事实、时间和证据；是否覆盖、哪条有效，可以根据具体问题推迟到查询阶段判断。

2. 记忆需要区分“事实时间”和“写入时间”

实际 Agent 项目中至少应该保存：

created_at：记忆什么时候写入系统
event_time：事情什么时候发生
valid_from：事实从什么时候开始有效
valid_to：事实什么时候失效
source：事实来自哪段对话或文档

如果只有 created_at，系统无法正确处理用户回忆过去事件或补充历史信息的情况。

例如，用户今天说：

我去年在上海工作。

写入时间是今天，但事实时间是去年。这两个时间不能混为一谈。

3. 图结构最大的价值不是“关联更多”，而是支持计算

相比普通向量检索，图结构的优势不只在于找出相关实体，还在于能够执行：

• 多跳连接；
• 时间排序；
• 时间区间过滤；
• 数量统计；
• 聚合计算；
• 事实变化检测；
• 证据回溯。

因此，如果自己的 Agent 只需要召回一句偏好，向量库可能已经足够。

只有当任务经常出现下面的问题时，属性图才更有价值：

什么时候发生？
发生之前是什么状态？
两个事实之间相隔多久？
某个人的上级的职位是什么？
过去一个月出现了多少次？

4. 检索工具应该按问题类型分工

可以参考 APEX-MEM，将记忆查询分成不同通道：

问题类型	更适合的工具
查找某个实体的当前状态	EntityLookup
开放式回忆、表述模糊	Search
时间排序、数量统计	SQL
多跳关系	GraphSQL
不清楚图结构	SchemaViewer

这比所有问题都执行同一种向量检索更加灵活。

5. 应保留原始证据层

结构化记忆并不意味着可以删除原始对话。

一个更可靠的架构应该包含：

原始对话层
↓
事件与事实层
↓
实体关系层
↓
查询时生成的记忆摘要

其中：

• 原始对话用于审计和纠错；
• 事件层保存时间演化；
• 实体层支持跨会话链接；
• 摘要层服务当前 Agent 决策。

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

如果暂时不实现完整属性图，可以先设计一张追加式事实表：

memory_facts(
    id,
    subject,
    property,
    value,
    value_type,
    event_time,
    valid_from,
    valid_to,
    confidence,
    source_session,
    source_turn,
    evidence_text
)

写入时不直接覆盖旧记录。

查询“当前状态”时：

SELECT *
FROM memory_facts
WHERE subject = ?
  AND property = ?
ORDER BY valid_from DESC
LIMIT 1;

查询历史变化时：

SELECT *
FROM memory_facts
WHERE subject = ?
  AND property = ?
ORDER BY valid_from ASC;

这已经能够实现 APEX-MEM 最核心的思想：

追加保存
+
时间排序
+
证据追踪
+
查询时解析

7. 与其他记忆论文的联系

方法	主要关注点	适合解决的问题
Mem0	事实记忆生命周期	当前事实如何写入、更新和删除
A-MEM	动态链接记忆	记忆如何关联和演化
Zep	时间知识图谱	事实的时间关系
MIRIX	多种专用记忆	不同记忆类型如何路由
MEM1	滚动内部状态	当前长程任务如何控制上下文
APEX-MEM	追加式时间事件图	冲突事实如何保留并在查询时解析

我认为，APEX-MEM 更适合作为长期持久记忆层，而 MEM1 更适合作为当前任务的工作记忆层。

两者可以组合成：

当前工具反馈
↓
MEM1 风格滚动工作状态
↓
需要长期信息时查询 APEX-MEM
↓
返回时间一致的紧凑记忆
↓
继续下一步决策

---

九、总结

APEX-MEM 提出了一套面向长期对话的半结构化记忆系统。

它的核心流程是：

非结构化对话
↓
抽取实体、事件、事实和时间
↓
执行实体与属性解析
↓
以追加方式写入属性图
↓
用户提出问题
↓
多工具 Agent 检索图和原始证据
↓
在查询时解决事实冲突

论文的三个核心贡献是：

1. 使用实体—事件混合本体表示长期对话；
2. 使用追加式存储保存事实的完整时间演化；
3. 使用 SchemaViewer、EntityLookup、GraphSQL 和 Search 组成多工具检索 Agent。

实验中：

• APEX-MEM + GPT-5 在 LOCOMO 上达到 88.88%；
• APEX-MEM Online + Claude 4.5 Sonnet 在 LongMemEval 上达到 86.2%；
• 时间问题准确率达到 90.63%；
• 在 SealQA-Hard 上达到约 40.1%。

不过，APEX-MEM 的效果高度依赖：

• 前置事实抽取质量；
• 实体链接质量；
• 问答模型的 SQL 和工具调用能力；
• 多轮工具调用成本；
• 在线预检索的召回率。

对实际 Agent 开发而言，这篇论文最重要的启发是：

长期记忆中的新旧事实不一定需要在写入时立即合并。对于会随时间变化的信息，更可靠的方式是保留完整事实演化、时间范围和原始证据，并在具体问题到来时再判断哪条事实有效。

---

参考资料

• Banerjee P., Moshtaghi M., Subramanian S., Misra A., Chadha A. APEX-MEM: Agentic Semi-Structured Memory with Temporal Reasoning for Long-Term Conversational AI. ACL 2026 Main.