【论文阅读】Agent 记忆机制(31):MemAgent——通过强化学习让固定长度记忆处理百万级长文本

文章目录

  • 前言
  • 零、论文基本信息
  • 一、背景与问题
    • [1. 超长上下文的三个目标](#1. 超长上下文的三个目标)
    • [2. 长上下文不等于有效记忆](#2. 长上下文不等于有效记忆)
    • [3. 固定记忆带来的新问题](#3. 固定记忆带来的新问题)
  • 二、相关工作
    • [1. 扩展模型上下文窗口](#1. 扩展模型上下文窗口)
    • [2. 稀疏注意力与线性注意力](#2. 稀疏注意力与线性注意力)
    • [3. 上下文压缩与外部记忆](#3. 上下文压缩与外部记忆)
    • [4. 强化学习训练 Agent](#4. 强化学习训练 Agent)
  • [三、MemAgent 方法总览](#三、MemAgent 方法总览)
  • 四、核心模块详解
  • [五、从自回归建模角度理解 MemAgent](#五、从自回归建模角度理解 MemAgent)
  • [六、Multi-Conv DAPO](#六、Multi-Conv DAPO)
    • [1. 为什么普通强化学习训练方式不够?](#1. 为什么普通强化学习训练方式不够?)
    • [2. Multi-Conv DAPO 的核心思想](#2. Multi-Conv DAPO 的核心思想)
    • [3. 可验证结果奖励](#3. 可验证结果奖励)
    • [4. 奖励分配的局限](#4. 奖励分配的局限)
  • 七、训练策略
  • 八、实验设置
  • 九、实验结果与分析
    • [1. RULER-HQA:长度外推能力](#1. RULER-HQA:长度外推能力)
    • [2. NIAH:关键信息能否长期保留](#2. NIAH:关键信息能否长期保留)
    • [3. LongBench-QA:高信息密度任务](#3. LongBench-QA:高信息密度任务)
    • [4. LongBench-SUM:能否迁移到总结任务](#4. LongBench-SUM:能否迁移到总结任务)
  • 十、消融实验
    • [1. 强化学习是否必要?](#1. 强化学习是否必要?)
    • [2. 记忆长度](#2. 记忆长度)
    • [3. 关键信息位置](#3. 关键信息位置)
  • 十一、效率分析
  • 十二、方法对比
  • 十三、局限性与未来方向
    • [1. 覆盖式记忆是有损的](#1. 覆盖式记忆是有损的)
    • [2. 奖励主要适用于可验证任务](#2. 奖励主要适用于可验证任务)
    • [3. 3.5M 结果主要来自合成任务](#3. 3.5M 结果主要来自合成任务)
    • [4. 推理延迟仍然会增长](#4. 推理延迟仍然会增长)
    • [5. 固定记忆容量不适合所有任务](#5. 固定记忆容量不适合所有任务)
  • 十四、我的理解和启发
    • [1. 记忆管理可以被视为策略学习](#1. 记忆管理可以被视为策略学习)
    • [2. "保留全部历史"不是唯一方案](#2. “保留全部历史”不是唯一方案)
    • [3. 最终奖励可以监督中间记忆](#3. 最终奖励可以监督中间记忆)
    • [4. 记忆不是越多越好](#4. 记忆不是越多越好)
    • [5. MemAgent 与长期记忆系统可以互补](#5. MemAgent 与长期记忆系统可以互补)
  • 十五、总结
  • 参考资料

前言

随着大语言模型上下文窗口不断扩展,很多人会自然地认为:只要上下文足够长,模型就能记住并利用所有信息。

但在实际的 Agent 系统中,"能够放进去"和"能够有效使用"是两件不同的事情。

当上下文从几万 Token 增长到几十万甚至上百万 Token 时,通常会出现三个问题:

  1. 计算成本快速增长

    标准 Transformer 的注意力计算复杂度会随着序列长度增加而迅速上升。即使模型理论上支持超长上下文,推理延迟和显存占用也可能难以接受。

  2. 信息利用能力下降

    重要信息虽然仍然位于上下文窗口中,但模型不一定能稳定找到并使用,尤其容易受到信息位置、无关内容和"Lost in the Middle"现象的影响。

  3. 上下文长度难以外推

    一个在 32K 或 128K 长度上训练的模型,并不意味着它能在 1M 长度上保持同样的表现。上下文窗口的理论容量,不等于有效上下文长度。

对于 Agent 来说,这个问题会更加明显。长时 Agent 需要持续读取网页、代码、日志、工具返回结果和环境状态。如果把所有历史信息不断追加到上下文中,最终一定会遇到上下文膨胀问题。

一种自然的解决思路是:不要让模型始终携带完整历史,而是像人阅读长文档一样,一边阅读,一边维护一份固定长度的笔记。

但是,这里又出现了一个新的问题:

当记忆空间有限时,模型应该保留什么、删除什么,以及如何通过最终任务结果反向学习这种记忆策略?

MemAgent 给出的答案是:将记忆更新本身视为一种需要学习的策略,并通过最终答案是否正确,对整个记忆轨迹进行端到端强化学习。

它不依赖外部向量数据库,也不修改 Transformer 的底层结构,而是让模型反复执行:

text 复制代码
读取一个文本块
    ↓
结合旧记忆生成新记忆
    ↓
覆盖旧记忆
    ↓
继续读取下一个文本块

最终,模型只根据问题和最后保留下来的记忆生成答案。

因此,MemAgent 的核心贡献并不只是"对长文本进行分块",而是:

通过 Multi-Conv 强化学习,让模型学会在固定记忆容量下持续压缩信息,从而将有限上下文窗口外推到远长于训练长度的文本。

需要提前说明的是,MemAgent 更接近一种面向当前任务的流式工作记忆机制,而不是 Mem0、A-MEM 等系统所关注的跨任务、跨会话长期记忆。


零、论文基本信息


一、背景与问题

1. 超长上下文的三个目标

作者认为,一个真正可用的长上下文系统需要同时满足三个要求:

  1. 能够处理非常长、甚至理论上不受限制的输入;
  2. 输入长度增加后,任务性能不会快速下降;
  3. 计算成本能够随文本长度近似线性增长。

现有方法通常只能解决其中一部分问题。

例如,扩大位置编码范围可以延长模型能够接收的序列,但无法保证模型能够稳定利用远距离信息;稀疏注意力可以降低计算量,但往往需要改变模型结构;上下文压缩可以缩短输入,却可能引入额外模块,并且难以保证压缩后仍然保留任务真正需要的信息。

2. 长上下文不等于有效记忆

假设一个 Agent 已经读取了大量日志,并在第一个文本块中发现:

text 复制代码
服务崩溃的原因是数据库连接池耗尽。

后续又读取了几十万个 Token 的监控数据、配置文件和代码。

即使最早的诊断结果仍然位于上下文窗口中,模型也可能因为信息距离过远、干扰信息过多而忽略它。

因此,问题不只是"历史是否还在",而是:

与当前任务相关的信息,能否在后续决策中持续保持活跃?

MemAgent 不要求模型一直携带完整历史,而是要求模型把与最终问题相关的信息压缩到一块固定长度的记忆中。

3. 固定记忆带来的新问题

固定长度记忆虽然能够控制上下文规模,但也意味着记忆空间有限。

当新信息不断到来时,模型需要做出选择:

  • 哪些旧信息仍然重要?
  • 哪些信息可以合并?
  • 哪些信息已经不再相关?
  • 新信息是否会推翻旧结论?
  • 如何避免重要细节在多次改写中逐渐丢失?

如果只通过提示词要求模型"保留重要信息",模型未必知道什么信息会在最终回答中真正有用。

因此,作者将记忆管理转化为强化学习问题:最终答案正确,说明此前的记忆更新整体有效;最终答案错误,则说明某些关键信息可能在记忆过程中被遗漏、覆盖或错误压缩。


二、相关工作

1. 扩展模型上下文窗口

一类方法通过修改位置编码或继续预训练扩展上下文长度,例如 Position Interpolation、NTK-aware Scaling、YaRN 等。

这类方法的优点是:

  • 保留标准 Transformer 结构;
  • 模型可以直接接收更长序列;
  • 不需要显式维护外部记忆。

但它们仍然面临两个问题:

  • 注意力计算成本随序列长度快速增长;
  • 理论上下文窗口不等于模型能够有效利用的上下文长度。

MemAgent 没有继续扩大单次输入窗口,而是让模型通过多个固定窗口顺序处理长文本。

2. 稀疏注意力与线性注意力

另一类方法通过稀疏注意力、线性注意力、状态空间模型等方式降低长序列的计算复杂度。

这类方法直接从模型结构层面解决效率问题,但通常需要:

  • 修改原有网络结构;
  • 从头训练或进行大量继续训练;
  • 设计特定的注意力模式;
  • 处理新结构与现有推理框架的兼容问题。

MemAgent 的区别是,它将记忆表示为普通 Token,不改变基础模型内部的注意力结构。

3. 上下文压缩与外部记忆

上下文压缩方法会删除、摘要或重写历史信息;外部记忆方法则把信息保存到向量数据库、知识图谱或其他存储系统中,并在需要时检索。

这些方法通常回答的是:

如何把历史存下来,以及如何从大量历史中找回相关内容?

MemAgent 关注的则是另一个问题:

在顺序读取长文本的过程中,模型如何持续维护一份固定长度、面向当前任务的状态?

它没有构建可随机访问的长期记忆库,而是让记忆随着文本流不断演化。

4. 强化学习训练 Agent

GRPO、DAPO 等强化学习方法通常根据最终回答的奖励优化模型输出。

但传统强化学习轨迹一般位于同一个连续上下文中。MemAgent 的每一次记忆更新都是一个相对独立的会话:

text 复制代码
第一个会话:文本块1 + 初始记忆 → 记忆1
第二个会话:文本块2 + 记忆1 → 记忆2
第三个会话:文本块3 + 记忆2 → 记忆3
......
最后一个会话:问题 + 最终记忆 → 答案

如何把最后答案的奖励传递给前面所有记忆更新会话,是本文 Multi-Conv DAPO 需要解决的关键问题。


三、MemAgent 方法总览

为了理解 MemAgent 的完整流程,可以先看论文 Figure 2。

图源:论文 Figure 2。

上半部分表示传统长上下文模型一次性读取全部文本,下半部分表示 MemAgent 将文档划分为多个文本块,并在每一步更新固定长度记忆,最后根据记忆生成答案。

假设原始长文档被划分为:

c 1 , c 2 , ... , c K c^1,c^2,\ldots,c^K c1,c2,...,cK

其中, c k c^k ck 表示第 k k k 个文本块。

MemAgent 维护一块固定长度的记忆:

m k ∈ V M m^k\in\mathbb{V}^{M} mk∈VM

其中:

  • V \mathbb{V} V 表示模型的 Token 词表;
  • M M M 表示固定的记忆长度;
  • m k m^k mk 表示读取第 k k k 个文本块之后的记忆。

整个推理过程可以概括为:

text 复制代码
输入问题 q
    ↓
初始化空记忆 m⁰
    ↓
读取文本块 c¹,生成记忆 m¹
    ↓
读取文本块 c²,结合 m¹ 生成 m²
    ↓
......
    ↓
读取文本块 cᴷ,生成最终记忆 mᴷ
    ↓
根据问题 q 和最终记忆 mᴷ 生成答案

这里最重要的设计是:

每次生成的新记忆都会覆盖旧记忆,而不是继续在旧记忆后面追加内容。

因此,无论原始文档多长,模型在任意一个处理步骤中看到的内容始终只有:

  • 当前问题;
  • 上一步记忆;
  • 当前文本块;
  • 本轮输出空间。

四、核心模块详解

1. 文本分块

设计动机

如果一次性输入完整长文档,模型的计算和显存开销会随着序列长度迅速增加。

MemAgent 将长文档划分为固定大小的文本块,让每次模型调用都保持在基础模型原有的上下文窗口内。

论文默认将 8K 上下文空间大致划分为:

内容 Token 预算
问题 1024
当前文本块 5000
上一步记忆 1024
本轮输出 1024
对话模板等内容 剩余空间

其中:

  • 文本块长度约为 5000 Token;
  • 记忆长度固定为 1024 Token;
  • 整个模型仍然只需要处理约 8K 的局部上下文。

方法流程

text 复制代码
超长文档
    ↓
按照固定长度切分
    ↓
c¹、c²、c³......cᴷ
    ↓
按照原始顺序逐块处理

这种设计保留了文档的顺序结构,但不会让所有原文同时进入模型上下文。

2. 覆盖式记忆更新

设计动机

如果每次读取新文本后都把摘要追加到历史中,记忆仍然会不断增长,最终重新变成长上下文问题。

因此,MemAgent 不采用追加式记忆,而是采用覆盖式更新:

m k ∼ π θ ( ⋅ ∣ q , m k − 1 , c k ) m^k\sim\pi_\theta(\cdot\mid q,m^{k-1},c^k) mk∼πθ(⋅∣q,mk−1,ck)

其中:

  • q q q 表示当前问题;
  • m k − 1 m^{k-1} mk−1 表示旧记忆;
  • c k c^k ck 表示当前文本块;
  • m k m^k mk 表示覆盖旧记忆的新记忆。

模型需要同时完成三件事:

  1. 从当前文本块中提取与问题相关的信息;
  2. 保留旧记忆中仍然重要的信息;
  3. 删除已经冗余、无关或被新证据推翻的信息。

提示词结构

论文使用的记忆更新提示词大致包含:

text 复制代码
问题:
{problem}

上一轮记忆:
{memory}

当前文本块:
{chunk}

请阅读当前文本块,在保留上一轮相关信息的同时,
更新一份有助于回答问题的新记忆。

这说明 MemAgent 的记忆不是通用文档摘要,而是受到问题条件约束的任务记忆。

同一份文档面对不同问题,最终形成的记忆可能完全不同。

举例说明

假设问题是:

text 复制代码
为什么系统最终没有采用 Redis 缓存?

第一个文本块提到:

text 复制代码
团队最初计划使用 Redis。

记忆可能更新为:

text 复制代码
初始方案:团队计划使用 Redis 缓存。

后面的文本块又提到:

text 复制代码
压力测试发现跨区域访问 Redis 的延迟过高,
最终改用本地缓存与消息队列。

新记忆不能只是追加信息,而应该重新组织为:

text 复制代码
团队最初计划使用 Redis,但压力测试发现跨区域访问延迟过高,
因此最终改用本地缓存和消息队列。

这就是覆盖式记忆的核心:记忆不是历史片段的简单堆积,而是持续更新的任务状态。

3. 最终答案生成

当所有文本块处理完毕后,MemAgent 不再读取原始文档,而是只根据:

  • 原始问题;
  • 最终记忆;

生成答案。

可以表示为:

y ^ ∼ π θ ( ⋅ ∣ q , m K ) \hat{y}\sim\pi_\theta(\cdot\mid q,m^K) y^∼πθ(⋅∣q,mK)

这意味着此前丢弃的信息无法在最后阶段重新访问。

因此,最终回答是否正确,直接依赖整个记忆更新轨迹是否成功保留了必要证据。

这也是为什么 MemAgent 不能只依赖普通提示词,而需要对记忆策略进行端到端优化。


五、从自回归建模角度理解 MemAgent

为了进一步解释 MemAgent,作者将记忆视为一个固定长度的潜变量。

传统自回归模型将序列概率分解为:

p ( x 1 : N ) = ∏ n = 1 N p ( x n ∣ x 1 : n − 1 ) p(x_{1:N})=\prod_{n=1}^{N}p(x_n\mid x_{1:n-1}) p(x1:N)=n=1∏Np(xn∣x1:n−1)

这意味着模型在预测后续 Token 时,需要依赖此前的完整历史,或者至少依赖由完整历史形成的缓存状态。

MemAgent 则用固定长度记忆替代无限增长的历史:

p ( x 1 : N ) = ∑ m 1 : K − 1 ∏ k = 1 K p ( c k ∣ m k − 1 ) p ( m k ∣ c k , m k − 1 ) p(\mathbf{x}{1:N})=\sum{\mathbf{m}^{1:K-1}}\prod_{k=1}^{K}p(\mathbf{c}^k\mid\mathbf{m}^{k-1})p(\mathbf{m}^k\mid\mathbf{c}^k,\mathbf{m}^{k-1}) p(x1:N)=m1:K−1∑k=1∏Kp(ck∣mk−1)p(mk∣ck,mk−1)

其中:

  • p ( c k ∣ m k − 1 ) p(\mathbf{c}^k\mid\mathbf{m}^{k-1}) p(ck∣mk−1) 表示基于上一轮记忆读取当前文本块;
  • p ( m k ∣ c k , m k − 1 ) p(\mathbf{m}^k\mid\mathbf{c}^k,\mathbf{m}^{k-1}) p(mk∣ck,mk−1) 表示根据当前文本块和旧记忆写入新记忆;
  • 初始记忆为 m 0 = ∅ \mathbf{m}^0=\varnothing m0=∅。

为了理解这种读写关系,可以看论文 Figure 4。

图源:论文 Figure 4。

该图将记忆表示为潜在状态。模型每读取一个文本块,就生成下一轮记忆,从而把一个超长序列分解为多次固定上下文的读取与写入过程。

从 Agent 的角度看,这个过程可以被视为一个马尔可夫决策过程:

  • 当前状态:旧记忆和当前文本块;
  • 动作:生成新的记忆内容;
  • 状态转移:新记忆进入下一轮;
  • 最终奖励:答案是否正确。

强化学习的目标,就是让模型学习一条能够最大化最终奖励的记忆轨迹。


六、Multi-Conv DAPO

1. 为什么普通强化学习训练方式不够?

对于普通问答任务,一条样本通常只有一次完整生成:

text 复制代码
问题 → 推理过程 → 最终答案

但 MemAgent 的一条样本会产生多个上下文相互独立的会话:

text 复制代码
会话1:问题 + 文本块1 + 空记忆 → 记忆1
会话2:问题 + 文本块2 + 记忆1 → 记忆2
......
会话K:问题 + 文本块K + 记忆K-1 → 记忆K
最终会话:问题 + 记忆K → 答案

每一次记忆更新都是模型生成的结果,但只有最后一个会话能够得到明确的答案奖励。

因此,训练需要解决:

如何根据最终答案,把奖励分配给前面所有记忆更新?

2. Multi-Conv DAPO 的核心思想

为了理解训练过程,可以看论文 Figure 3。

图源:论文 Figure 3。

上半部分是传统 GRPO,每个样本主要对应一次完整生成;下半部分是 Multi-Conv DAPO,一条样本会生成多个独立会话,最终答案的奖励会用于优化此前所有会话。

传统 DAPO 的损失主要按照:

text 复制代码
样本组 × Token

计算。

MemAgent 将其扩展为:

text 复制代码
样本组 × 会话 × Token

假设同一个问题采样得到 G G G 条完整记忆轨迹,第 i i i 条轨迹最终获得奖励 R i R_i Ri,其优势函数为:

A ^ i , j , t = R i − mean ⁡ ( { R i } i = 1 G ) \hat{A}{i,j,t}=R_i-\operatorname{mean}(\{R_i\}{i=1}^{G}) A^i,j,t=Ri−mean({Ri}i=1G)

其中:

  • i i i 表示组内第 i i i 条采样轨迹;
  • j j j 表示该轨迹中的第 j j j 个会话;
  • t t t 表示会话中的第 t t t 个 Token;
  • R i R_i Ri 表示第 i i i 条轨迹最终答案的奖励。

可以看到,同一条轨迹中的所有记忆更新会话共享最终优势值。

也就是说:

  • 如果最终答案正确,此前产生这条记忆轨迹的多个会话都会得到正向优化;
  • 如果最终答案错误,导致错误记忆轨迹的多个会话都会受到负向反馈。

3. 可验证结果奖励

论文使用规则验证器判断预测答案和标准答案是否等价:

R ( y ^ , y ) = 1 is_equiv ( y , y ^ ) R(\hat{y},y)=\mathbf{1}_{\texttt{is\_equiv}(y,\hat{y})} R(y^,y)=1is_equiv(y,y^)

其中:

  • y ^ \hat{y} y^ 表示模型预测答案;
  • y y y 表示标准答案;
  • 答案等价时奖励为 1,否则为 0。

这种奖励不需要额外训练奖励模型,也不需要为每一步人工标注意义。

模型只根据最终答案是否正确,自主学习:

  • 哪些事实应该写入记忆;
  • 哪些干扰信息应该删除;
  • 多跳证据应该如何整合;
  • 记忆应该保持多详细;
  • 新证据应该如何修改旧结论。

4. 奖励分配的局限

这种方式虽然简单,但存在明显的信用分配问题。

当最终答案错误时,系统只能知道整条记忆轨迹有问题,却不知道具体是哪一步:

  • 没有识别到关键信息;
  • 正确写入后又被覆盖;
  • 合并信息时产生错误;
  • 最终回答阶段没有正确使用记忆。

因此,Multi-Conv DAPO 提供的是轨迹级监督,而不是精确到单次记忆操作的局部监督。


七、训练策略

1. 基础模型

论文使用以下模型作为基础模型:

  • Qwen2.5-7B-Instruct;
  • Qwen2.5-14B-Instruct。

整个 Multi-Conv 训练框架基于 verl 实现。

2. 两阶段课程学习

作者采用两阶段强化学习训练。

第一阶段:学习基础记忆能力

第一阶段使用 32768 条合成长文本问答数据,每条数据大约为 32K Token。

数据基于 HotpotQA 构建,主要方式是:

  1. 选择包含答案的黄金段落;
  2. 加入大量来自同一数据集的干扰文档;
  3. 把关键段落随机放置在长上下文中;
  4. 要求模型经过多轮记忆更新后回答多跳问题。

这一阶段的目标是让模型学习最基本的能力:

  • 从大量干扰内容中识别关键信息;
  • 在多轮覆盖中保留关键事实;
  • 整合分散在不同文本块中的证据。

第一阶段大约训练 400 个 Step 后收敛。

第二阶段:提高任务泛化能力

第二阶段使用 2560 条更困难的长文本问答数据,最长约为 60K Token。

数据由以下两部分混合组成:

  • DocQA-RL-1.6K 中的高质量长文本问答;
  • 第一阶段的部分合成数据。

第二阶段的目的不是单纯增加文本长度,而是让模型把记忆能力迁移到信息密度更高、文本类型更多样的任务中。

3. 主要训练参数

论文给出的主要训练设置包括:

参数 设置
强化学习算法 DAPO
KL 系数 1 × 10 − 3 1\times10^{-3} 1×10−3
学习率 1 × 10 − 6 1\times10^{-6} 1×10−6
优化器 AdamW
Warm-up Step 20
Rollout Batch Size 256
Group Size 16
默认记忆长度 1024 Token
默认文本块长度 5000 Token
模型上下文窗口 8K

这里最值得关注的是:

模型训练时只使用约 32K~60K 的长文本数据,但测试时被外推到了 3.5M Token。


八、实验设置

1. 数据集

论文使用四类长上下文任务。

RULER-HQA

这是基于 HotpotQA 合成的多跳问答任务。

它可以通过增加干扰文档数量,精确控制上下文长度,用于测试模型的长度外推能力。

论文测试长度从约 7K 一直扩展到 3.5M Token。

LongBench-QA

包含:

  • 2WikiMultihopQA;
  • HotpotQA;
  • MuSiQue;
  • NarrativeQA;
  • Qasper。

这些任务的文本长度没有 RULER-HQA 那么夸张,但信息密度更高,能够测试模型是否真正学会了灵活的记忆管理,而不是只会在低密度文本中寻找少量关键词。

NIAH

NIAH,即 Needle in a Haystack,用于测试模型能否在超长干扰文本中找到并长期保留少量关键信息。

论文使用了 RULER 中三个难度不断增加的 NIAH 变体,并测试到 512K Token。

LongBench-SUM

包括:

  • GovReport;
  • QMSum。

这一组任务用于判断 MemAgent 学到的是否只是问答检索能力,还是能够迁移到长文本总结任务。

2. 对比方法

主要对比模型包括:

  • Qwen2.5-Instruct;
  • Qwen2.5-Instruct-1M;
  • DeepSeek-R1-Distill-Qwen;
  • QwenLong-L1。

对比覆盖普通指令模型、长上下文模型和推理模型。

3. 评价指标

不同任务使用不同指标:

任务 指标
RULER-HQA Accuracy
LongBench-QA Accuracy
NIAH Accuracy
LongBench-SUM ROUGE-1、ROUGE-2、ROUGE-L

九、实验结果与分析

1. RULER-HQA:长度外推能力

论文 Table 1 给出了从 7K 到 3.5M Token 的结果。

下面保留部分代表性长度:

模型 7K 112K 448K 896K 1.75M 3.5M
QwenLong-L1-32B 72.66 31.25 13.28 11.72 - -
Qwen2.5-14B-Instruct-1M 60.16 50.00 8.59 0.00 - -
DeepSeek-R1-Distill-Qwen-32B 70.31 23.44 7.81 7.03 - -
RL-MemAgent-14B 80.47 81.25 79.69 75.78 78.91 71.09
RL-MemAgent-7B 81.25 79.69 76.56 74.22 77.34 71.88

从表中可以看到:

  • 普通长上下文模型随着长度增加出现明显下降;
  • Qwen2.5-14B-Instruct-1M 虽然标称支持 1M 上下文,但在 896K 测试中下降到 0;
  • MemAgent 在 448K 和 896K 时仍然保持 70% 以上准确率;
  • 两个 MemAgent 模型在 3.5M 时仍然达到约 71%。

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

7B 模型从 7K 的 81.25% 下降到 3.5M 的 71.88%,绝对下降约 9.37 个百分点;14B 模型从 80.47% 下降到 71.09%,绝对下降约 9.38 个百分点。

因此,比较准确的结论是:

MemAgent 在特定的合成多跳问答任务中表现出了非常强的长度外推能力,但不能简单理解为在所有 3.5M Token 的真实文档任务上都能近乎无损工作。

2. NIAH:关键信息能否长期保留

为了观察不同长度和难度下的表现,可以看论文 Figure 5。

图源:论文 Figure 5。

该图展示了不同模型在多个 NIAH 难度和上下文长度下的准确率。MemAgent 在上下文扩展到 512K 后仍然保持较高准确率,而多数对比模型出现明显下降。

在 512K 长度下,RL-MemAgent 在多个 NIAH 变体上的结果大多仍然超过 95%。

由于每个文本块约为 5000 Token,512K 输入意味着模型需要进行超过 100 次记忆更新。

这说明经过强化学习后,模型能够让某些关键事实经历上百次覆盖式更新后仍然保留下来。

我的理解是,这个实验验证的不是"模型能不能找到 Needle",而是:

模型能否识别出 Needle 值得长期保留,并在后续大量无关信息到来时持续保护它。

3. LongBench-QA:高信息密度任务

论文 Table 3 的平均结果如下:

模型 2Wiki HQA MuSiQue NQA Qasper 平均
QwenLong-L1-32B 83.0 69.5 51.0 26.0 24.0 50.7
DeepSeek-R1-Distill-Qwen-32B 83.5 69.0 47.5 24.0 21.0 49.0
MemAgent-14B 79.0 73.0 52.0 25.0 26.0 51.0
MemAgent-7B 74.0 69.5 47.0 21.5 29.0 48.2

MemAgent-14B 取得了 51.0 的最高平均分,略高于 QwenLong-L1-32B 的 50.7。

这组实验比 RULER-HQA 更重要,因为 LongBench-QA 的信息密度更高、文本类型更加多样。

结果说明,MemAgent 学到的并不只是"在大量干扰文档中保存两个答案段落",而是具备一定的真实长文档记忆泛化能力。

但也要看到,它并不是在每一个子任务上都最好。例如在 2Wiki 上,QwenLong-L1 和 DeepSeek-R1-Distill-Qwen-32B 仍然更高。

4. LongBench-SUM:能否迁移到总结任务

在 GovReport 和 QMSum 上,MemAgent-14B 的平均 ROUGE 分别为:

模型 GovReport 平均 QMSum 平均
Qwen2.5-14B-Instruct 19.04 29.09
Qwen2.5-14B-Instruct-1M 19.34 29.84
RL-MemAgent-14B 21.80 31.39
RL-MemAgent-7B 19.34 31.27

MemAgent-14B 在两个数据集上都取得了较好的结果。

这说明强化学习得到的记忆策略能够在一定程度上从问答迁移到总结任务:

  • 问答要求保存与问题直接相关的少量证据;
  • 总结要求覆盖文档中的多个核心主题。

不过,二者对记忆的要求并不完全相同。总结任务更容易受到固定记忆容量限制,因为需要保留的信息范围更广。


十、消融实验

1. 强化学习是否必要?

论文比较了:

  • 直接使用提示词执行 MemAgent 流程;
  • 使用强化学习训练后的 RL-MemAgent。

实验发现,没有经过强化学习时,分块加记忆的流程有时也能优于直接输入长上下文,但随着文本长度增加,性能仍然明显下降。

在 LongBench-QA 上,直接使用 MemAgent 工作流甚至可能只带来很小提升,或者产生负面影响。

经过 Multi-Conv DAPO 训练后,模型在 RULER-HQA、NIAH 和 LongBench-QA 上均有明显改善。

这说明 MemAgent 的核心增量不是"文本分块"本身,而是:

通过最终任务奖励,让模型学会什么信息值得在多次覆盖中持续保留。

2. 记忆长度

作者测试了从 256 到 4096 Token 的不同记忆长度。

结果表明,记忆并不是越长越好:

  • 记忆太短,无法保存完成任务所需的全部证据;
  • 记忆太长,容易产生冗余,也会增加模型管理记忆的难度;
  • 更长的记忆还会增加每一轮推理的计算成本。

论文最终选择 1024 Token 记忆和 5000 Token 文本块作为默认配置,认为这是容量、压缩率和推理成本之间较合理的平衡点。

这说明记忆容量本身也是需要与任务信息密度匹配的系统参数。

3. 关键信息位置

作者还将关键证据放置在文档的不同位置,例如:

  • 开头与前部;
  • 开头与结尾;
  • 中间区域;
  • 后部与结尾。

结果与随机分布相比没有出现一致的大幅下降。

这说明经过端到端训练后,MemAgent 对信息位置具有一定鲁棒性,没有表现出非常明显的"Lost in the Middle"。

不过,这并不意味着覆盖式记忆不会遗忘,而是说明在当前评测任务中,模型学会了较稳定地跟踪与问题相关的关键证据。


十一、效率分析

设:

  • 原始文本长度为 N N N;
  • 每个文本块长度为 C C C;
  • 固定记忆长度为 M M M;
  • 文本块数量约为 K = N / C K=N/C K=N/C。

每一步只处理当前文本块和固定长度记忆,因此当 C C C 和 M M M 固定时,总步骤数随 N N N 线性增长:

K ≈ N C K\approx\frac{N}{C} K≈CN

从完整输入长度的角度看,总体复杂度可以写为:

O ( N ) O(N) O(N)

但这里需要避免一个容易产生的误解。

MemAgent 并没有把 Transformer 单次注意力的内部复杂度变成线性。每个局部窗口内部仍然使用标准 Transformer 注意力。

它的线性复杂度指的是:

当文本块大小和记忆大小固定时,文档长度每增加一个文本块,只增加一次固定规模的模型调用。

因此,MemAgent 的总运行时间仍然会随着文本长度线性增加。

3.5M Token 文档大约需要数百次模型生成,并不是一次普通 8K 推理就能完成。它解决的是上下文容量和复杂度增长形式,而不是消除超长文本处理成本。


十二、方法对比

方法类型 核心思想 优点 主要限制
长上下文模型 一次性把完整文本放入上下文 保留原始信息,可直接全局注意 成本高,长度外推后可能失效
RAG 从外部文档中检索相关片段 适合大规模随机访问 检索可能遗漏跨片段关系
传统摘要压缩 定期对历史进行摘要 简单,容易接入现有系统 摘要目标与最终任务可能不一致
Mem0/A-MEM 类长期记忆 保存跨会话事实和经验 适合用户画像与长期 Agent 需要写入、检索和更新机制
MemAgent 顺序读取文本并覆盖固定记忆 固定窗口、线性扩展、无需修改模型结构 记忆有损,无法重新访问被删除内容
Memex 类经验记忆 索引并检索完整历史经验 可以回到原始证据 需要索引、存储和检索系统

MemAgent 与传统长期记忆最大的区别是:

它不是把所有经历长期保存下来,而是为当前问题维护一份持续演化的任务状态。

因此,MemAgent 更适合:

  • 超长文档问答;
  • 长日志分析;
  • 代码仓库顺序扫描;
  • 长轨迹状态压缩;
  • 工具调用结果的阶段性整理。

而对于需要跨会话保留用户偏好、历史事件和可追溯证据的系统,仅使用 MemAgent 并不充分。


十三、局限性与未来方向

1. 覆盖式记忆是有损的

一旦某条信息没有进入新记忆,或者在后续更新中被删除,最终回答阶段就无法重新访问它。

这与外部数据库不同:数据库中的原始记录仍然存在,可以在之后重新检索。

因此,MemAgent 面临不可逆的信息丢失风险。

2. 奖励主要适用于可验证任务

论文主要使用答案是否正确作为规则奖励。

这种方式适合:

  • 有标准答案的问答;
  • 数学问题;
  • 可自动验证的任务。

但对于开放式总结、代码质量、长期规划等任务,最终结果很难用简单的 0/1 规则准确评价。

如何为这些任务设计可靠奖励,仍然是落地时的重要问题。

3. 3.5M 结果主要来自合成任务

RULER-HQA 可以精确控制长度,适合测试外推能力,但它仍然是通过黄金段落和干扰文档构建的合成任务。

真实的百万 Token 任务可能包含:

  • 大量相互矛盾的信息;
  • 不明确的任务目标;
  • 表格、代码和多模态内容;
  • 需要回看原文细节的问题;
  • 随着阅读过程动态变化的问题。

因此,不能把 3.5M 的实验结果直接等价为通用百万 Token 理解能力。

4. 推理延迟仍然会增长

虽然总体复杂度对文档长度是线性的,但每个文本块都需要生成一次新记忆。

当文档达到百万 Token 时,模型需要执行大量串行记忆更新,前一步的记忆又是下一步的输入,因此不容易完全并行化。

实际系统还需要关注:

  • 首次处理延迟;
  • GPU 推理成本;
  • 多轮生成吞吐量;
  • 中途失败后的恢复机制;
  • 记忆状态的持久化。

5. 固定记忆容量不适合所有任务

1024 Token 对低信息密度问答可能足够,但对于:

  • 多主题长文总结;
  • 大规模代码依赖分析;
  • 需要保留大量精确数字的财务文档;
  • 多约束长期规划;

固定记忆可能形成明显的信息瓶颈。

未来可以探索:

  • 动态记忆长度;
  • 分层记忆;
  • 多块并行记忆;
  • 结构化记忆;
  • 记忆与外部检索结合;
  • 在低置信度时回读原始证据。

十四、我的理解和启发

1. 记忆管理可以被视为策略学习

过去设计 Agent 记忆时,我们通常会通过提示词规定:

  • 请提取关键信息;
  • 请压缩历史内容;
  • 请保留用户偏好;
  • 请删除无关信息。

但什么是"关键",本质上由未来任务决定。

MemAgent 提供了一个很重要的视角:

记忆写入、压缩和遗忘不是固定规则,而是一种可以根据最终任务结果学习的策略。

对于不同任务,理想的记忆策略可能完全不同:

  • 问答任务需要保存证据;
  • 编程任务需要保存约束、错误和已经尝试的方法;
  • 规划任务需要保存目标、资源和未完成步骤;
  • 用户助手需要保存稳定偏好和重要事件。

因此,未来 Agent 的记忆模块不一定只是一个独立组件,也可以被纳入端到端策略优化。

2. "保留全部历史"不是唯一方案

MemAgent 说明,即使只有固定长度的记忆,只要模型能够学会正确更新,也可能处理远长于上下文窗口的任务。

对于自己的 Agent 项目,可以把完整轨迹和活跃记忆分开:

text 复制代码
完整事件日志
    ↓
按阶段生成活跃记忆
    ↓
当前决策只读取活跃记忆
    ↓
必要时再回查完整日志

其中:

  • 完整日志用于审计和恢复;
  • 活跃记忆用于控制当前上下文成本;
  • 外部检索用于弥补覆盖式记忆不可逆的问题。

这种"流式记忆 + 外部存档"的组合,比单独使用某一种记忆机制更适合工程系统。

3. 最终奖励可以监督中间记忆

在长时 Agent 中,我们通常很难标注每一步应该写入什么记忆。

但如果任务结果可以验证,就可以借鉴 MemAgent:

text 复制代码
多轮行动和记忆更新
    ↓
得到最终任务结果
    ↓
根据成功或失败生成奖励
    ↓
反向优化此前的记忆决策

例如,在代码修复 Agent 中:

  • 最终测试通过,说明某些问题诊断和修改经验值得保留;
  • 最终测试失败,说明记忆中可能保留了错误假设,或者遗漏了关键约束;
  • 多次任务后,可以学习哪些日志、报错和修改记录最有助于后续决策。

4. 记忆不是越多越好

MemAgent 的记忆长度消融说明,更大的记忆容量不一定必然带来更好结果。

记忆过长会导致:

  • 冗余信息增加;
  • 关键事实被淹没;
  • 维护成本上升;
  • 模型更难判断哪些状态仍然有效。

这与实际 Agent 开发经验一致:

好的记忆系统不是保存尽可能多的信息,而是让当前决策所需的信息保持清晰、紧凑和可操作。

5. MemAgent 与长期记忆系统可以互补

我认为 MemAgent 最适合被放在 Agent 记忆架构的"工作记忆层",而不是替代所有长期记忆。

一种可行的组合架构是:

text 复制代码
原始交互和工具轨迹
    ↓
MemAgent:维护当前任务的活跃工作记忆
    ↓
长期记忆系统:保存稳定事实、经验和完成结果
    ↓
检索系统:在需要时重新访问原始证据

其中:

  • MemAgent 解决当前长任务中的上下文膨胀;
  • Mem0 类系统负责跨会话事实维护;
  • A-MEM 类系统负责记忆关联和演化;
  • Memex 类系统负责原始经验索引与回查。

从这个角度看,MemAgent 不是一个完整的长期记忆操作系统,而是一个经过强化学习训练的流式上下文压缩器。


十五、总结

MemAgent 提出了一种不修改基础模型结构的长上下文处理方法。

它将超长文档划分为多个固定长度文本块,并让模型在每一步根据当前文本块和旧记忆生成新的固定长度记忆。旧记忆随后被覆盖,最终模型只根据问题和最后一轮记忆生成答案。

其核心创新主要包括:

  1. 使用固定长度、覆盖式 Token 记忆处理超长文本;
  2. 将记忆更新建模为一系列独立上下文会话;
  3. 提出 Multi-Conv DAPO,把最终答案奖励传递给此前所有记忆更新;
  4. 在不修改 Transformer 结构的情况下,实现相对于总文档长度的线性扩展;
  5. 在 RULER-HQA、NIAH、LongBench-QA 和 LongBench-SUM 上验证记忆策略的外推和泛化能力。

这篇论文给我的最大启发是:

长上下文问题不一定只能通过扩大上下文窗口解决,也可以转化为一个"模型应该如何持续维护任务状态"的策略学习问题。

不过,MemAgent 的记忆是有损、面向当前问题且不可随机回查的。它在 3.5M Token 上的结果主要来自合成多跳问答任务,实际应用时仍然需要与原始日志、外部检索、长期记忆和恢复机制结合。

如果把它放到完整的 Agent 记忆体系中,我更愿意将 MemAgent 定位为:

一种通过最终任务奖励训练出来的流式工作记忆机制。

它真正值得关注的,不只是"能够处理多长的文本",而是第一次比较系统地展示了:记忆的写入、压缩和遗忘策略,可以通过强化学习端到端获得。

参考资料

相关推荐
阿部多瑞 ABU1 小时前
新-潘多拉降临操场
人工智能
小妖同学学AI1 小时前
拒绝手动SSH:用战斗机与AI混沌构建的硬核Homelab架构
人工智能
江畔柳前堤1 小时前
YOLO 目标检测全流程深度剖析
人工智能·yolo·目标检测·计算机视觉·unity·面试·vllm
jikemaoshiyanshi1 小时前
业务部门想了解开箱即用 AI Agent,AWS 中国峰会有哪些案例展示?
大数据·人工智能
2401_832298101 小时前
绿色AI发展新赛道:算力优化与低碳智能的双向赋能
人工智能
ClouGence1 小时前
CloudDM:开源免费!一站式数据库访问、SQL审核、权限与脱敏管控平台
数据库·sql·开源
依然鸣1 小时前
PTA团体程序设计天梯赛L2真题讲解L2-045-048
数据结构·c++·经验分享·学习·算法·pat考试·pat
Z-D-K2 小时前
一个AI的真实日记(3)
人工智能·ai·aigc·人机交互·agent·agi
ivywriter2 小时前
【数字孪生】到底能解决什么实际问题?
大数据·人工智能·机器人
(轻舟已过万重山)2 小时前
第39章 评估迭代:上线只是开始,迭代才是关键
大数据·数据库·人工智能