Mem2ActBench: A Benchmark for Evaluating Long-Term Memory Utilization in Task-Oriented Autonomous Agents

论文阅读：Mem2ActBench——从“记住事实”到“用记忆执行任务”的 Agent Memory Benchmark

论文标题：Mem2ActBench: A Benchmark for Evaluating Long-Term Memory Utilization in Task-Oriented Autonomous Agents
作者：Yiting Shen, Kun Li, Wei Zhou, Songlin Hu
发表位置：ACL 2026 Main Conference，Long Papers
ACL Anthology ID：2026.acl-long.370
arXiv 编号：arXiv:2601.19935
arXiv 链接：https://arxiv.org/abs/2601.19935
ACL 正式版：https://aclanthology.org/2026.acl-long.370/
代码与数据：https://github.com/Cantaloupe-M/Mem2ActBench
主题：LLM Agent、Long-term Memory、Tool Use、Memory Benchmark
核心问题：现有 Agent Memory Benchmark 大多测试“能否从记忆中回答问题”，而 Mem2ActBench 进一步测试 Agent 能否主动判断需要哪些历史记忆，并将这些记忆转化为正确的 Tool Call 参数。

1. 论文要解决什么问题？

这篇论文关注的并不是一种新的 Memory 架构，而是一个 Agent Memory Benchmark。

作者认为，目前很多长期记忆评测实际上测试的是一种相对“被动”的能力：

历史记忆
   ↓
明确问题：我的预算是多少？
   ↓
检索相关 Memory
   ↓
回答：500 美元

问题已经直接告诉 Agent：

“去找我的预算。”

因此 Agent 的主要任务是：

Question → Retrieval → Answer

但现实中的长期运行 Agent 往往不是这样。

用户可能在很早之前说过：

我的预算最多是 500 美元。

后来又说：

我只坐直飞航班。

过了很久以后，用户只说：

帮我订下周去纽约的机票。

这时候用户并不会重新把全部约束再说一遍。

一个真正使用长期记忆的 Agent 应该主动意识到：

当前任务：订机票

需要的历史信息：
预算 → $500
航班偏好 → nonstop

当前请求：
目的地 → NYC
时间 → next week

然后生成类似：

search_flights(
    destination="NYC",
    max_price=500,
    non_stop=True,
    time="next week"
)

这里发生了一个关键变化：

Memory 不再只是用来回答关于过去的问题，而是成为当前 Action 的隐式输入。

因此，Mem2ActBench 想评估的是：

当当前请求信息不完整时，Agent 能否自己判断哪些 Tool 参数需要从长期记忆里寻找，并把检索到的历史信息正确地 Ground 到工具参数中？

这也是论文所说的 memory-driven task execution（记忆驱动的任务执行）。

2. 与传统 Memory Benchmark 的区别

论文将已有 Memory Benchmark 与 Mem2ActBench 做了对比。

Benchmark	Session	Turns	Tokens	QA Pairs	主要推理形式	Memory Evolution	Tool Use
MSC	4	53	564	-	Retrieval	×	×
MemoryBank	10	38	3,094	7	Retrieval	✓	×
LoCoMo	27.2	21.6	16,618.1	199	Retrieval	✓	×
DialSim	1,313	1,310	352k	1,056	Retrieval	✓	×
LongMemEval	48 / 500	10.34	115k / 1.5M	500	Retrieval	✓	×
Mem2ActBench	2,029	12	3,238	400	Inference	✓	✓

这里最重要的区别不是 Context 更长，而是 任务形式发生了变化。

传统 Benchmark 往往给 Agent 一个明确的问题：

What is the user's budget?

需要寻找的 Memory 类型已经由问题暴露出来。

而 Mem2ActBench 给出的可能是：

Help me book a flight to New York for next week.

这个 Query 本身并没有说：

请检索我的预算。
请检索我的直飞偏好。

Agent 必须首先根据 Tool Schema 判断：

这个 Tool 需要哪些参数？
哪些参数当前 Query 没有？
这些缺失信息是否可能存在于长期记忆？
应该检索哪部分 Memory？

然后才能进一步完成参数填充。

因此这里评估的是一条更长的能力链：

Task Understanding
       ↓
Determine Missing Constraints
       ↓
Memory Retrieval
       ↓
Memory Reasoning
       ↓
Parameter Grounding
       ↓
Tool Invocation

作者认为，单纯测试“Memory 能不能被检索出来”，不足以覆盖这种场景。

3. Mem2ActBench 整体构造方法

Mem2ActBench 的数据构造主要分成三个阶段：

异构数据整合
    ↓
Memory Evolution Chain 构造
    ↓
Memory-anchored Task 构造

【论文 Figure 2（Mem2ActBench 整体数据构造框架）。该图从左到右展示 Heterogeneous Data Integration、Memory Evolution Chain Construction 和 Memory-anchored Q&A Construction 三个阶段，是理解整个 Benchmark 构造流程的核心框架图。】

整个思路可以简单理解成：

作者不是先随便生成一个问题，再去寻找它可能依赖什么 Memory。

而是反过来：

先构造可靠的长期 Memory
        ↓
从 Memory 中确定一个完整的 Tool Call
        ↓
再故意把关键参数从用户 Query 中删掉
        ↓
生成一个必须借助 Memory 才能完成的任务

这是论文非常关键的 reverse generation（反向生成） 思路。

4. 第一阶段：构造长期、多 Session 的对话历史

4.1 为什么不能直接使用普通 Tool Dataset？

现有 Tool-use Dataset 通常更关注：

User Query
    ↓
选择 Tool
    ↓
生成参数

但这些数据通常没有很长的用户历史。

而长期 Memory Dataset 虽然有长历史，又往往缺少真实的 Tool Call。

所以作者把多个来源组合起来：

数据来源	在 Mem2ActBench 中的作用
ToolACE	提供 Tool-use 任务和调用轨迹
BFCL v3	提供 Tool Schema、Function Calling 和任务数据
OASST1	提供自然聊天内容，作为 Conversational Noise

其中 ToolACE 和 BFCL 提供任务相关内容。

OASST1 则负责模拟现实中大量和当前任务无关的聊天。

于是，一个长期历史就不再是：

旅行
旅行
旅行
旅行
旅行

而可能变成：

旅行
↓
闲聊
↓
账户设置
↓
电影
↓
旅行
↓
天气
↓
餐厅
↓
旅行

这使得与当前任务有关的信息被分散在大量历史交互中。

4.2 ToolACE 与 BFCL 如何处理？

对于 ToolACE，作者处理约 8,000 个样本。

原始 Tool Trace 会先被解析，然后使用 LLM 重构为自然的多轮对话。

BFCL v3 中原本较静态的 Query / Tool Call 数据，同样被转换成动态的多轮交互。

论文附录中进一步说明，数据生成使用：

Qwen3-Next-80B-A3B-Instruct
temperature = 0.0

目标是让生成结果更加稳定，同时保留原始 Tool Execution Logic。

4.3 OASST1 作为对话噪声

OASST1 是一个树状对话数据集。

作者只保留 rank=0 的高质量回答，并沿树结构恢复完整对话线程。

这些内容不一定与 Tool Task 有关。

它们的主要作用就是制造现实中的：

interruption-heavy history（充满话题中断的长期历史）。

因此 Memory Retriever 不仅需要搜索很长的历史，还要从大量无关内容中找到少数真正重要的信息。

5. 第二阶段：Fact Evolution Chain

将大量对话拼起来之后还有一个问题：

长期历史中的事实会变化。

例如用户可能先说：

我喜欢吃鱼和蔬菜。

后来变成：

我是素食主义者。

再后来变成：

我现在严格吃 Vegan。

如果直接把所有内容全部作为同等有效的 Memory，Agent 就无法判断当前到底应该采用哪个状态。

所以作者没有简单地把历史对话当成 Memory Ground Truth，而是进一步构造：

Fact Evolution Chain（事实演化链）。

5.1 Fact Extraction

首先使用 LLM 从每个 Dialogue 中抽取原子事实。

每个 Fact 表示为：

(attribute, fact, source_id)

例如：

attribute:
Dietary Preference

fact:
User prefers vegetarian food.

source_id:
dialogue_123

其中：

attribute 表示事实属于什么属性；

fact 是实际事实；

source_id 用来定位这个事实来自哪段原始对话。

5.2 为什么 Attribute 不能太泛？

如果所有内容都使用类似：

Preference

这种过于宽泛的 Attribute，就很容易错误地把不同实体混在一起。

例如：

YouTube Account Preference
Restaurant Preference
Flight Preference

显然不能因为都叫“Preference”就认为它们之间发生了状态更新。

因此作者要求 LLM 尽量产生 entity-bound attribute（与具体实体绑定的属性）。

例如：

Account Modification (YouTube)

而不是简单写成：

Account Modification

这样可以减少不同实体之间的错误冲突。

5.3 对 Attribute 进行语义聚类

即使两个事实描述的是同一个概念，Attribute 文本也可能不同。

例如：

Diet Preference
Dietary Preference
Food Preference

因此作者进一步使用：

BGE-M3 embedding
      ↓
BERTopic
      ↓
HDBSCAN

把语义相近的 Attribute 聚到同一组。

附录给出的 HDBSCAN 设置包括：

min_cluster_size = 2
metric = euclidean
cluster_selection_method = leaf
epsilon = 0.01

之后，每个 Cluster 选取一个 canonical attribute，Cluster 中其他 Attribute 都映射到这个统一表示。

最终得到一组组：

Fact Group（事实组）。

6. Local Conflict Resolution：先解决局部冲突

同一个 Attribute Group 内部可能包含很多相互更新甚至冲突的信息。

因此作者让 LLM 对每个 Fact Group 单独处理。

这里主要做三件事情。

操作	作用
Chronological Ordering	判断这些事实之间真实的时间演化顺序
Conflict Elimination	删除过时、重复或无法与其他事实共存的信息
Narrative Synthesis	总结这一属性是如何随时间变化的

这里作者特别区分：

Update（更新） 和 Refinement（细化）。

例如：

喜欢运动
↓
喜欢篮球

后者可以看成前者的 Refinement，并不一定需要删除“喜欢运动”。

又例如用户曾经：

住在北京
↓
后来搬到上海

这里两个状态都可以作为历史事实保留，只是需要明确时间顺序。

因此论文不是简单采用：

新 Memory 出现 → 老 Memory 全部删除

而是试图构造一个逻辑上合理的状态演化过程。

6.1 论文中的饮食偏好例子

论文附录展示了一个较直观的例子。

原始 Memory 包括：

用户喜欢鱼和蔬菜
用户是 vegetarian
用户现在要求所有午餐必须 vegan
用户喜欢蔬菜
用户摄入很多蛋白质

系统最终判断：

fish + vegetables

与当前的：

strict vegan

发生冲突，因此对应 Fact 被丢弃。

而曾经是 Vegetarian 的信息仍然可以作为历史状态保留。

最终形成的 Narrative 描述的是：

Vegetarian
    ↓
逐渐转向 Vegan
    ↓
当前严格 Vegan，同时偏好蔬菜和高蛋白饮食

这就是所谓的 Memory Evolution。

它不是一个静态 KV Store，而是带有状态变化关系的历史。

7. Global Evolution Sequence：把局部时间线合成全局 Memory

局部 Fact Group 已经分别排好顺序之后，还需要把所有 Topic 合并成一个全局时间序列。

作者把问题转换为一个图：

Fact = Node
Temporal Constraint = Directed Edge

例如：

fact_A → fact_B

表示：

A 必须出现在 B 之前。

然后使用基于 Kahn Algorithm（Kahn 拓扑排序） 的方法进行排序。

7.1 为什么会出现 Cycle？

不同局部 Fact Group 的约束合并后可能产生：

A → B
B → C
C → A

此时无法进行正常的拓扑排序。

作者将这种 Cycle 视为不同数据来源之间存在无法同时满足的冲突。

处理方式是：

找到当前 Cycle 中的 Deadlocked Nodes，然后删除其中：

out-degree 最大的 Node

作者的理由是：

一个节点的 Out-degree 越大，它对后续 Fact 施加的排序约束越多。

删除它可以一次解除较多约束，从而恢复拓扑排序。

如果多个节点 Out-degree 相同，则采用 Lexicographical Order 作为 Tie-breaker，使整个算法保持确定性。

最终得到：

Global Fact Evolution Sequence

+

Discarded Conflicting Facts

这条 Global Sequence 就作为后面生成 Benchmark Task 时使用的 Ground-truth Memory。

8. 第三阶段：从 Memory 反向生成 Tool Task

这是 Mem2ActBench 数据构造中最关键的一步。

传统数据生成思路容易是：

先生成问题
↓
再寻找答案

Mem2ActBench 则反过来：

Memory Evolution Chain
        ↓
完整 Tool Call
        ↓
隐藏部分参数
        ↓
生成 Underspecified Query

这样作者可以控制：

最终缺失的信息确实存在于 Memory 中。

9. 先构造一个完整的 Gold Tool Call

给定一条 Memory Evolution Chain，作者先构造一个完整的 Tool Invocation。

可以表示成：

C = (target_tool, parameters)

例如长期 Memory 中存在：

Default city = Austin, TX
Restaurant preference = gluten-free

那么可以先构造：

PlacesSearchAPI(
    location="Austin, TX",
    dietary_preference="gluten-free"
)

这里 Tool 的选择由：

BM25
+
BGE-M3
+
LLM decision

共同完成。

而参数值必须满足一个很严格的要求：

每一个参数都必须能够从 Memory Evolution Chain 中显式得到，或者根据其中的信息合理推导出来。

作者还使用：

Fuzzy Matching
+
LLM Verifier

验证每个 Parameter 是否确实能够追溯到 Memory。

这样做是为了避免生成一个看起来合理、实际上并没有历史依据的 Tool Call。

10. Reverse Implicit Query Generation

有了完整答案之后，再反向生成 Query。

假设 Ground Truth 已经是：

PlacesSearchAPI(
    location="Austin, TX",
    dietary_preference="gluten-free"
)

作者希望生成的用户问题类似：

I want to go out to eat tonight.
Can you help me find some suitable places?

注意这里没有出现：

Austin
gluten-free

这两个参数只能从历史 Memory 中恢复。

10.1 Reverse Query 的三个约束

作者要求生成的 Query 满足三个条件。

条件	含义
Parameter Omission	Tool Call 中关键参数不能直接出现在 Query 中
Reference Dependency	Query 应通过“之前那个”“按我的偏好”等方式依赖历史
Intent Preservation	虽然隐藏参数，但当前任务意图不能改变

例如：

Find a flight that fits the budget I mentioned earlier.

就是一个典型的 Memory-dependent Query。

这里：

price = ?

必须去过去的 Memory 中寻找。

11. 最关键的数据质量控制：保证 Query 真的需要 Memory

这是 Benchmark 构造中非常重要的一部分。

因为一个问题即使表面上没有直接写参数，也可能实际上不需要 Memory。

例如历史 Memory 是：

User prefers Italian food.

生成 Query：

Find me a place that serves pasta and pizza.

虽然没有出现：

Italian

但模型根据 Pasta 和 Pizza 就很容易推断出 Italian。

那么这个样本实际上并没有真正测试 Memory。

因此作者设计了两层过滤。

11.1 Lexical Leakage Filtering

第一层使用规则检测直接的信息泄露。

主要检查：

泄露形式	示例
Exact Match	Memory 中是 Seattle，Query 直接出现 Seattle
Numeric Leakage	Memory 中预算是 500，Query 直接出现 500
Token Overlap	`Hotel California` 中泄露 `California`
Structured Identifier	ID、Email 等字符串部分出现在 Query

如果发现这些情况，样本直接删除。

11.2 Blinded LLM Discriminator

规则只能发现词面泄露，却不能发现语义泄露。

因此作者又使用一个 Blinded LLM Discriminator（盲判 LLM 判别器）。

它只能看到：

User Query
+
Tool Schema

不能看到：

Long-term Memory

然后让它尝试恢复正确 Tool Call。

如果这个 Discriminator 在没有 Memory 的情况下仍然能够预测出正确参数：

Query + Tool Schema
    ↓
Correct Tool Call

那么说明这个任务其实：

Solvable Without Memory

因此该样本会被删除。

只有：

没有 Memory → 无法解决
有 Memory → 可以解决

的样本才会进入最终 Benchmark。

11.3 论文给出的过滤案例

Memory	Generated Query	Target	结果
用户想去 Seattle	Help me book a flight to Seattle.	`city=Seattle`	Reject：Direct Leakage
Account ID 是 AX-9920	Check my account status, it ends in 9920.	`id=AX-9920`	Reject：Partial Leakage
用户喜欢 Italian Food	Find me a place that serves pasta and pizza.	`cuisine=Italian`	Reject：Semantic Leakage
Memory 没有时间	Book the ticket for tomorrow morning.	`time=09:00`	Reject：Unsupported Constraint
Turn 1 中预算为 $500	Find a flight that fits the budget I mentioned earlier.	`price=500`	Accept

最后一种就是 Mem2ActBench 真正想保留的任务。

Query 明确告诉模型：

需要某个历史预算

但是没有告诉模型具体是多少。

Agent 必须自己从 Memory 中把 $500 找出来。

12. 数据规模与人工验证

最终作者构造了：

2,029 个长期 Conversation Sessions
400 个 Memory-dependent Tool-use Tasks

论文摘要与 Table 1 报告平均约 12 Turns，而方法部分正文写为平均 13 Turns；核心的数据规模均为 2,029 Sessions 和 400 个评测任务。

除了自动 Pipeline，作者还使用 5 名具有 NLP / Computer Science / AI 背景的 Expert Annotators 对三个阶段进行人工验证。

验证项目	抽样数量	Validated
Fact Extraction Accuracy	200	96.5%
Conflict Resolution Quality	150	86.7%
Memory Dependency Validity	200	91.3%

其中最后一个尤其重要。

91.3% Memory Dependency Validity 表示人工标注者认为这些抽样任务中，绝大部分确实无法仅依靠当前 Query 和 Tool Schema 完成，而需要访问长期 Memory。

13. 实验设置

作者测试了 7 种代表性的 Memory System：

Long-term Memory / RAG
Generative Agents
SCM
LangMem
MemTree
Mem0
A-Mem

为了控制 Backbone 的影响，所有 Memory System 分别搭配三个 Qwen2.5 模型：

Qwen2.5-7B-Instruct
Qwen2.5-32B-Instruct
Qwen2.5-72B-Instruct

所有模型设置：

temperature = 0.0

对于需要 Embedding Retrieval 的系统统一使用：

BGE-M3

主实验还直接提供 Ground-truth Tool，从而尽可能控制 Tool Selection Error，把关注点集中到：

Memory-based Parameter Grounding。

14. Evaluation Metrics

作者主要使用三个指标。

Metric	含义
F1	参数级别 Precision / Recall
BLEU-1	生成参数与 Reference 的 unigram overlap
TA	Tool Accuracy，完整调用是否匹配

在后面的 Tool Selection Robustness 实验中，还进一步使用：

Metric	含义
TSA	Tool Selection Accuracy，只看工具选得对不对
EM	End-to-end Exact Match，Tool 和全部参数都正确
Arg_F1	在 Tool 选择正确的条件下计算参数 F1

因此论文可以把两个问题分开：

Tool 有没有选对？

和：

Tool 选对以后，参数有没有从 Memory 中填对？

15. 主实验结果

论文 Table 3 的主要结果如下。

Memory Method	72B F1	32B F1	7B F1	Average F1
LTMemory	35.32	33.87	26.71	31.97
SCM	22.73	17.35	14.99	18.36
Generative Agents	22.38	17.81	14.44	18.21
MemTree	33.21	31.89	24.60	29.90
Mem0	28.95	24.52	14.21	22.56
LangMem	24.01	18.72	17.06	19.93
A-Mem	35.93	33.72	30.99	33.55

最直接的现象是：

即使在 Qwen2.5-72B 上，最高 Parameter F1 仍然只有约：

35.9

也就是说，在这种“从长期 Memory 中恢复 Tool 参数”的任务上，现有 Memory Framework 仍存在很大的提升空间。

15.1 更大的模型确实有帮助

所有框架整体都随着 Backbone 变大而有所提高。

作者计算出的平均 F1 大致为：

7B   → 20.4
32B  → 25.4
72B  → 28.9

但从 32B 到 72B 的提升开始变小。

因此仅依靠扩大 Backbone 并不能解决全部问题。

特别值得注意的是 Mem0：

7B  F1 = 14.21
72B F1 = 28.95

提升约 14.7 F1。

作者认为，这说明当 Memory Organization 本身不够强时，更大的模型可以通过更好的跨轮推理能力弥补一部分问题。

16. Retrieval 到底是不是主要瓶颈？

为了判断 Agent 到底是：

Memory 找不到

还是：

Memory 找到了但不会用

作者专门进行了 Retriever Analysis。

实验比较：

No Retrieval

BM25

Dense Retrieval

Hybrid Retrieval

Oracle Retrieval

结果如下：

Retrieval	k	F1	BLEU	TSA
No Retrieval	-	10.0	8.9	73.8
BM25	1	29.0	28.0	87.0
BM25	5	26.9	26.2	90.2
BM25	10	27.6	26.7	87.5
Dense	1	25.6	25.3	83.0
Dense	5	29.9	29.1	90.0
Dense	10	28.7	28.3	88.8
Hybrid	1	24.9	24.3	85.0
Hybrid	5	30.7	29.7	86.0
Hybrid	10	30.3	29.5	88.8
Oracle	-	53.8	53.7	88.2

这里出现了一个非常大的差距：

Best Passive Retrieval:
F1 = 30.7

Oracle Retrieval:
F1 = 53.8

相差超过：

23 F1

Oracle Retrieval 意味着系统直接获得真正相关的 Supporting Memory。

因此这个实验说明，在 Mem2ActBench 上相当大的一部分性能损失发生在：

Evidence Retrieval / Evidence Hitting 阶段。

换句话说，Agent 很多时候并不是完全不会根据 Memory 生成参数，而是一开始就没有把正确的 Memory 找回来。

16.1 为什么 top-k 越大不一定越好？

从结果也可以看到：

BM25 k=1 → 29.0
BM25 k=5 → 26.9
BM25 k=10 → 27.6

以及：

Dense k=5 → 29.9
Dense k=10 → 28.7

检索更多内容并不必然提高性能。

因为增加 k 的同时，也会把更多无关 Memory 放进 Context。

于是问题从：

信息不够

逐渐变成：

正确证据 + 大量 Distractor

这也是长期 Memory 系统中的另一个问题：Retrieve More 不等于 Retrieve Better。

17. Memory Distance：长期 Memory 也存在 Lost in the Middle

作者进一步研究：

Supporting Memory 出现在历史中的不同位置，会不会影响 Tool Parameter Grounding？

对于每个样本，作者找到最早能够支持某个 Tool Parameter 的 Turn：

t_earliest

然后使用：

P_mem = t_earliest / conversation_length

将位置划分为：

0% - 25%
25% - 50%
50% - 75%
75% - 100%

实验发现，大多数框架表现出明显的位置偏差。

通常：

历史最前面
       ↑
表现较好

历史中间
       ↓
表现下降

非常接近当前 Query
       ↑
表现重新提高

也就是一个明显的 mid-context valley。

例如 A-Mem 在某些区间：

约 36% F1
↓
约 25% F1

而 LTMemory 的位置稳定性相对更强，各个区间基本保持在 30% F1 以上。

作者认为，这说明即使引入了 Memory Retrieval，类似 Lost in the Middle 的问题仍然会出现在长期 Memory Agent 中。

只是这里丢失的不再仅仅是普通 Context 信息，而是：

执行 Tool Call 所需要的关键参数依据。

18. Parameter Grounding 到底难在哪里？

作者进一步按照 Parameter 的来源和复杂度进行分析。

18.1 三种 Grounding Type

参数分成：

类型	含义	示例
Explicit	Memory 直接给出参数	`New York`
Inferred	需要做语义转换	`upcoming week → days=7`
Default	History 中没有，应使用 Tool Schema 默认值	默认参数

对于 72B 模型，Explicit 和 Inferred 之间差距并没有特别大。

这意味着：

一旦正确的证据真的被 Retriever 找到了，类似：

upcoming week
↓
7 days

这种语义转换本身并不是最严重的问题。

反而比较明显的问题出现在 Default Parameters。

模型经常会：

历史根本没有这个信息

但仍然自行补出一个“看起来合理”的参数。

也就是说：

No Evidence
↓
Plausible Guess

而正确行为应该是遵守 Tool Schema 或相应默认约束。

长历史中的 Distractor 还可能进一步诱导这种错误。

19. Value Complexity：复杂参数更容易损坏

作者还把参数值按照形式分成：

Simple String
Number
Boolean
Complex

其中 Complex 包括：

长字符串
URL
Address
特殊 Identifier
Nested Structure

结果表明，随着 Value Complexity 上升，Slot Accuracy 明显下降。

尤其是类似：

URL
Account ID
完整 Address
复杂 JSON

这样的值。

这里的问题并不是语义有没有理解，而是：

Lossless Retention（无损保留）能力。

例如 Agent 可能已经知道正确 ID，但生成过程中：

AX-99201

被变成：

AX-9921

只错一个字符，Tool Call 就已经无法正确执行。

因此 Agent Memory 不仅需要：

remember the meaning

有时候还必须：

remember the exact value

20. Tool Selection Robustness

主实验为了集中研究 Memory Grounding，控制了 Tool Selection。

作者随后单独测试：

如果候选 Tool 越来越多，会发生什么？

Candidate Set 设置为：

N = 1, 2, 5

Distractor 分为两类：

Random Negative
Hard Negative

Hard Negative 指与正确 Tool 在语义上非常接近的工具，例如：

search_flight
book_flight

这种区别。

结果如下：

Candidate Size	Random TSA	Random EM	Random Arg_F1	Hard TSA	Hard EM	Hard Arg_F1
1	94.50	18.25	29.88	94.50	18.25	29.88
2	95.50	18.00	29.98	78.00	16.50	27.17
5	93.50	17.00	28.27	69.75	14.25	22.64

Random Negative 对 Tool Selection 影响不大。

即使加入 5 个候选：

TSA ≈ 93.5%

但 Hard Negative 的影响非常明显：

94.50%
↓
78.00%
↓
69.75%

说明 Agent 对完全无关的工具区分得很好，但当多个 Tool 的语义和功能高度重叠时，Tool Selection 仍然存在困难。

另一方面，即使 Tool Selection Accuracy 超过 93%，End-to-end EM 仍然只有约：

14% - 18%

进一步说明最终失败的主要来源仍然是：

Argument Grounding。

21. Error Mode Diagnosis

为了进一步确定系统到底错在哪里，作者把错误分成五类。

Error	含义
Retrieval Miss	所需 Memory 根本没有被检索出来
Retrieved-but-Unused	Memory 找到了，但模型没有正确使用
Hallucinated Default	不应该猜参数时自行生成了一个值
Lossless Retention Failure	URL、ID、长字符串等发生损坏
Tool Selection Error	选错 Tool

实验观察到一个比较有意思的变化。

较弱系统的主要错误集中在：

Retrieval Miss

随着 Memory System 变强：

Retrieval Miss
↓
Retrieved-but-Unused
↑

也就是说，当 Retriever 改善之后，问题会从：

“找不到”

逐渐变成：

“找到了，但是不会正确用”

因此 Memory Pipeline 中至少存在两个相对独立的问题：

Memory Accessibility
        ↓
Memory Utilization

而 Retrieval Miss 即使在较强系统中仍然是占比较大的错误来源。

这与前面的 Oracle Retrieval 实验是一致的：

先找到正确证据，仍然是当前长期 Memory Agent 的重要瓶颈。

22. Mitigation Strategies：作者尝试了三种缓解方法

ACL 正式版进一步加入了三个 Mitigation Strategy，用于研究这些失败能否通过简单机制缓解。

实验在：

200 个 Mem2ActBench Samples
Qwen2.5-72B-Instruct

上进行。

三种策略分别是：

方法	核心思想
Query Expansion	一次生成多个 Tool-specific Retrieval Query，提高 Recall
Self-Refine	如果发现参数缺失，则重新 Retrieval，而不是直接 Hallucinate
Interactive Clarification	允许 Agent 主动向用户询问缺失信息

结果：

Strategy	TA	F1	BLEU-1
LTMemory Baseline	92.00%	29.24	50.64
Query Expansion	91.50%	32.42	53.07
Self-Refine	94.00%	29.68	51.73
Interactive Clarification	87.25%	48.68	61.89

22.1 Query Expansion

Query Expansion 将一次 Retrieval Query 扩展为多个更具体的搜索 Query。

Parameter F1：

29.24
↓
32.42

获得了一定提升。

作者据此认为，前面的 mid-context failure 确实有相当一部分来源于：

Retriever 没有命中正确证据。

22.2 Self-Refine

Self-Refine 允许 Agent 在发现参数缺失时触发：

<SELF_REFINE>

然后重新检索。

结果 Tool Accuracy 从：

92.0
→
94.0

但 Parameter F1 只从：

29.24
→
29.68

提升非常有限。

论文给出的解释是：

如果 Agent 一开始就没有获得足够的信息，那么它也很难知道：

下一轮 Retrieval Query 应该怎么改。

也就是说：

“再想一次”

并不能自动解决：

“根本不知道应该去找什么”

的问题。

22.3 Interactive Clarification

第三种方式更直接：

如果 Memory 中无法可靠确定参数，Agent 可以主动问用户。

例如：

User:
帮我订之前提到的那家附近的餐厅。

Agent:
你指的是上次提到的 Austin 那家吗？

实验中 Parameter F1 从：

29.24

提升到：

48.68

提升幅度明显。

不过作者特别指出：

这并不能与原本的 Single-turn Setting 严格公平比较。

因为允许 Clarification 后，任务定义已经发生改变：

Static Memory Retrieval

变成了：

Interactive Decision Making

所以作者主要把它看成一个 Diagnostic Upper Bound。

这个实验说明：

当历史 Memory 本身存在 Retrieval Bottleneck 时，允许 Agent 主动询问用户，可以绕过一部分静态 Memory Retrieval 的困难。

23. 这篇论文最终揭示了什么？

Mem2ActBench 的实验将长期 Memory Agent 的问题拆得比较清楚。

完整链条实际上是：

Current Task
    ↓
发现当前信息不足
    ↓
判断需要哪些历史约束
    ↓
构造 Retrieval Query
    ↓
找到正确 Memory
    ↓
判断新旧状态和有效约束
    ↓
将 Memory 转化成 Tool Parameter
    ↓
精确保留参数值
    ↓
选择正确 Tool
    ↓
执行 Action

而传统的 Memory QA Benchmark 往往主要覆盖其中的一部分：

Question
    ↓
Retrieve Memory
    ↓
Answer

Mem2ActBench 的核心变化就是：

把 Memory 的终点从 Answer 改成 Action。

这使得很多以前不明显的问题变得突出：

Retrieval Miss
Retrieved-but-Unused
Parameter Hallucination
Exact-value Corruption
Tool Ambiguity

其中实验尤其显示：

第一，Oracle Retrieval 能把 F1 从约 30.7 提升到 53.8，说明 Retrieval Quality 是主要瓶颈之一。

第二，即使正确 Memory 已经被找到，Agent 仍可能出现 Retrieved-but-Unused，说明 Retrieval 本身并不能保证 Memory 被正确应用。

第三，复杂 ID、URL、Address 等参数对 Memory 的要求不只是语义保存，还包括 Lossless Retention。

第四，与当前 Query 距离较远、尤其位于中间位置的 Memory 更容易被忽略，表现出类似 Lost in the Middle 的现象。

24. 论文的局限性

作者明确指出了几个限制。

首先，Mem2ActBench 当前评估的是：

Offline Tool-call Generation。

它并没有真正连接外部环境执行 Tool，然后根据 Tool Response 继续调整行为。

因此并未覆盖完整的：

Action
↓
Environment Feedback
↓
New Observation
↓
Memory Update
↓
Next Action

这种闭环 Agent Interaction。

其次，为了控制变量，同时考虑 Agentic Memory Framework 每轮推理成本较高，实验主要使用同一 Qwen2.5 Model Family。

因此结果并不能直接代表所有不同模型家族。

第三，数据主要通过自动化方法从 ToolACE、BFCL 和 OASST1 等已有数据集重新组合、生成和过滤。

虽然进行了人工验证，但自动生成的对话仍然不能完全覆盖真实用户与长期 Assistant 交互时的复杂性。

第四，Human Verification 本身也可能在边界案例中引入判断偏差。

25. 论文给出的未来方向

论文最终强调，未来长期 Memory Agent 的研究不能只关注：

How to store memory?

或者：

How to retrieve memory?

还需要进一步研究：

How to actively utilize memory?

尤其是在当前任务信息不完整时，Agent 应当具备：

识别缺失信息
→
主动定位相关 Memory
→
结合分散历史信息进行推理
→
将结果 Ground 到具体 Action

论文实验表明，即使现有 Memory Framework 已经能够保存和检索相当多的信息，当最终任务要求 Agent 将这些信息转换成可靠 Tool Parameter 时，性能仍然明显下降。

因此作者将一个重要研究问题从：

Memory Retrieval

进一步推进到了：

Memory Utilization for Action

26. 总结

Mem2ActBench 是一个面向 长期 Memory + Tool-use Agent 的 Benchmark。

它针对现有 Memory Benchmark 主要采用：

Question → Retrieval → Answer

这一评测范式的问题，引入了：

Underspecified Task
        ↓
Infer Missing Constraints
        ↓
Retrieve Long-term Memory
        ↓
Ground Tool Parameters
        ↓
Tool Call

的数据形式。

为了构造这种任务，作者首先将 ToolACE、BFCL 和 OASST1 组合成长时间跨度、包含大量 Topic Interruption 的历史对话，再抽取 Fact 并通过 Semantic Clustering、Local Conflict Resolution 和 Global Topological Ordering 构造 Fact Evolution Chain。

随后从 Memory 出发先确定完整的 Gold Tool Call，再通过 Reverse Query Generation 隐去关键参数，并利用 Lexical Leakage Filter 和 Blinded LLM Discriminator 删除那些不需要 Memory 也能完成的样本。

最终得到 400 个 Memory-dependent Tool-use Tasks。

实验覆盖 7 种 Memory Framework 和 Qwen2.5 7B / 32B / 72B 三种 Backbone Scale。

结果表明，现有系统在普通事实检索之外仍面临几个明显问题：

Memory Retrieval 不稳定
Mid-context Memory 容易遗漏
检索到 Memory 后不一定正确使用
Default Parameter 容易被幻觉覆盖
复杂 Identifier 难以无损保存
语义相近的 Tool 容易混淆

其中，最佳 Passive Retrieval 的 F1 约为 30.7，而使用 Ground-truth Memory 的 Oracle Retrieval 可以达到 53.8，显示出较大的 Retrieval Gap。

因此，这篇论文将 Agent Memory 的评测重点从：

“Agent 能不能记得过去？”

进一步推进为：

“Agent 能不能在执行当前任务时，主动知道什么时候应该使用过去，并把过去的信息正确转化成 Action？”

这也是 Mem2ActBench 所要测试的核心能力。

参考

Yiting Shen, Kun Li, Wei Zhou, Songlin Hu. Mem2ActBench: A Benchmark for Evaluating Long-Term Memory Utilization in Task-Oriented Autonomous Agents. ACL 2026.
ACL Anthology：https://aclanthology.org/2026.acl-long.370/
arXiv：https://arxiv.org/abs/2601.19935
Project / Code：https://github.com/Cantaloupe-M/Mem2ActBench

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

刷新页面返回顶部