---

前言

前面已经阅读了 A-MEM、Mem0、RMM、TrustMem、GAM、HORMA 等不同类型的 Agent 记忆方法。

这些方法分别从不同角度改进 Agent 的长期记忆：

A-MEM：
将记忆组织为能够动态建立链接的记忆卡片。

Mem0：
从交互中提取事实，并执行新增、修改、删除和忽略。

RMM：
按照主题组织长期对话，并根据记忆是否被回答引用优化排序。

TrustMem：
逐步验证记忆更新，减少遗漏、破坏和幻觉。

GAM：
保存轻量 Memo 和完整 Page，
通过 Deep Research 动态构造当前任务需要的上下文。

HORMA：
将历史组织成可导航、可追溯的层级工作空间，
再训练召回 Agent 寻找最小但充分的上下文。

这些方法主要在解决三个问题：

什么信息值得保存？
记忆应该如何组织和更新？
如何从大量记忆中召回当前任务需要的信息？

但是，在命令行操作、代码调试和多轮工具调用等长时任务中，还存在另一类问题。

某条重要信息可能仍然保存在执行轨迹里，甚至仍然处于模型的上下文窗口中，但它已经无法继续影响 Agent 的下一步行动。

例如，一个代码 Agent 可能经历下面的过程：

1. Agent 在任务开始时识别到：
   不能修改公共接口的函数签名。

2. Agent 在后续调试中遇到一个 Bug。

3. 为了快速修复 Bug，
   Agent 修改了公共接口的函数签名。

4. 局部测试通过，
   但最终隐藏测试失败。

这里的问题不是 Agent 没有看到任务要求。

真正的问题是：

这条要求虽然仍然存在于历史中，却没有在关键决策时继续约束 Agent 的行为。

类似的问题还包括：

Agent 已经尝试过一条失败命令，
几轮后却再次执行几乎相同的命令。

Agent 已经定位到一个错误模式，
之后看到相同现象时却重新从头诊断。

Agent 已经验证了某个环境事实，
后续行动时却重新使用未经验证的假设。

Agent 知道还有一个子目标没有完成，
但在局部调试中逐渐偏离了原始任务。

本文将这种现象称为：

Behavioral State Decay，行为状态衰减。

行为状态衰减说明，长期记忆不仅需要解决“保存”和“召回”问题，还需要解决：

什么时候需要重新激活一条记忆？
这条记忆是否会影响下一步行动？
应该以什么形式提醒行动 Agent？
什么时候应该保持沉默？

为了解决这个问题，本文提出了 Proactive Memory Agent。

该方法在原有行动 Agent 之外增加一个独立的记忆 Agent。

记忆 Agent 会：

观察近期执行轨迹；
维护结构化记忆库；
判断哪条执行状态正在失去作用；
决定是否向行动 Agent 插入一条具体提醒；
在不需要提醒时保持沉默。

可以用一句话概括本文：

将 Agent 记忆从被动存储和检索，扩展为能够在关键决策前选择性介入的控制机制。

---

零、论文基本信息

• 论文名称：Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents
• 发表平台：arXiv preprint，2026
• 代码仓库：yifannnwu/proactive-memory-agent
• 作者信息：Yifan Wu、Lizhu Zhang、Yuhang Zhou、Mingyi Wang、Bo Peng、Serena Li、Xiangjun Fan、Zhuokai Zhao，Meta AI

---

一、什么是行为状态衰减？

长时 Agent 通常按照下面的方式执行任务：

接收任务
    ↓
观察环境
    ↓
分析当前状态
    ↓
生成行动
    ↓
调用工具
    ↓
获得新的环境反馈
    ↓
继续下一轮决策

在短任务中，Agent 主要关注当前观察即可。

但在长时任务中，下一步行动可能同时受到几十轮之前信息的约束。

这些信息包括：

任务要求；
环境事实；
已经失败的尝试；
错误诊断；
中间发现；
用户或工具验证的状态；
仍未完成的子目标。

论文将这些仍然需要影响未来行动的信息统称为：

Execution State，执行状态。

例如，在一个代码修复任务中，执行状态可能包含：

任务要求：
不能修改公开接口。

环境事实：
当前容器没有 sudo 权限。

失败尝试：
升级到 package 2.0 后出现 Python 版本冲突。

错误诊断：
问题来自配置加载顺序，而不是网络连接。

开放子目标：
修复完成后还需要运行完整测试。

随着执行轨迹不断增长，这些信息可能被后续的命令输出、错误日志和局部推理淹没。

最终出现：

信息仍然存在
≠
信息仍然影响行为

这就是本文所说的行为状态衰减。

---

二、为什么长上下文不能直接解决问题？

一种直接方案是将完整执行轨迹都放入上下文窗口。

例如：

系统提示词
+
任务要求
+
全部历史观察
+
全部工具调用
+
全部错误日志
+
全部行动和结果

只要上下文窗口足够长，理论上 Agent 就可以访问所有历史信息。

但“能够访问”并不代表“能够稳定使用”。

随着上下文变长，会出现：

早期要求被大量新信息稀释；
模型更加关注最近的局部问题；
失败尝试难以与当前行动建立联系；
相同错误被当成新的错误重新处理；
开放子目标逐渐失去显著性。

已有长上下文研究也表明，大模型对不同位置的信息利用能力并不稳定。

即使某条信息仍然处于上下文窗口中，模型也可能因为它的位置、周围噪声以及当前局部任务而低估其作用。

因此：

上下文更长
≠
记忆更可靠

信息仍然可见
≠
信息仍然具有行为约束力

本文关注的不是信息是否还存在，而是它是否仍然能够控制 Agent 的下一步决策。

---

三、为什么传统记忆检索还不够？

传统 Agent 记忆系统通常采用下面的流程：

历史交互
    ↓
提取记忆
    ↓
写入外部存储
    ↓
根据当前查询进行检索
    ↓
返回 Top-K 记忆

这种方式主要回答：

哪些历史记录与当前输入在语义上相关？

但在长时任务中，语义相关性并不等于决策相关性。

假设一个客服 Agent 正在处理机票补偿请求。

历史中已经出现：

用户自述：
我是 Gold 会员。

工具查询结果：
该用户的会员等级是 Regular。

几轮之后，Agent 准备发放只有 Gold 会员才能获得的补偿。

此时，最需要被重新激活的不是与“补偿”语义最相似的对话，而是：

经过工具验证的会员等级是 Regular，
后续操作应当以系统记录为准。

这条记忆的重要性来自：

它即将约束一次状态变更操作。

而不仅是它与当前文本具有较高的语义相似度。

因此，长时任务中的记忆还需要回答：

当前是否需要提醒 Agent？
哪条记忆会改变下一步行动？
提醒应该如何表达？
什么时候不应该插入任何记忆？

---

四、相关工作

论文主要从四个方向讨论相关工作：

1. 长时语言模型 Agent；
2. Agent 长期记忆；
3. 可学习的记忆策略与上下文管理；
4. 反思、批评和 Advisor 模型。

1. 长时语言模型 Agent

ReAct 等方法将推理、行动和环境反馈组织成多轮循环。

随着 Terminal-Bench、MLE-Bench 和 τ-Bench 等基准出现，Agent 开始处理更接近真实环境的任务：

在终端中检查文件；
执行命令；
修改代码；
调试测试失败；
完成机器学习工程；
根据领域规则调用工具；
与用户进行多轮协调。

这些任务需要的不只是单步推理能力，还包括跨步骤维护任务状态。

如果 Agent 无法持续利用早期信息，就容易：

重复失败操作；
违反任务要求；
丢失错误诊断；
忽略未完成目标；
对错误实体执行操作。

2. Agent 长期记忆

传统长期记忆系统主要用于：

保存用户偏好；
维护跨会话状态；
存储历史事件；
检索相关事实；
复用过去获得的经验。

例如，Mem0 强调用户、会话和 Agent 层面的持久化记忆，并支持记忆的新增、更新、删除和检索。

Voyager 等方法则会保存能够在未来任务中复用的技能。

本文并不否定这些方法，而是研究一个不同的问题：

在一次仍然进行的长时任务中，什么时候应该让某条执行记忆重新影响下一步行动？

3. 可学习的记忆策略与上下文管理

另一类方法开始让 Agent 主动管理上下文。

例如：

Memory-as-Action：
将工作记忆管理表示为显式编辑动作。

Context-Folding：
将子任务轨迹折叠为简短摘要。

Mem-α：
通过强化学习优化记忆构建操作。

这些方法共同说明：

记忆和上下文管理应该根据最终任务结果进行优化，而不能只优化摘要质量或检索相似度。

本文与这些方法的区别在于：

不训练行动 Agent 自己编辑上下文；
不将重点放在后续问答准确率；
不只压缩已经完成的子任务；
而是使用独立记忆 Agent 观察正在运行的任务，
并判断是否需要介入下一步行动。

4. 反思、批评和 Advisor 模型

Reflexion、Self-Refine 和 Advisor 模型会通过第二个模型为行动 Agent 提供反馈或建议。

例如：

重新检查当前方案；
尝试另一条实现路径；
批评行动 Agent 的计划；
提出后续推理建议。

本文的记忆 Agent 同样使用辅助模型影响行动 Agent，但它受到更严格的约束：

输出必须来自已经维护的执行状态，而不是开放式战略建议。

合适的提醒包括：

即将被违反的任务要求；
已经验证的环境事实；
不应再次尝试的失败方案；
仍然有效的错误诊断；
正在被忽略的子目标。

不合适的提醒包括：

宽泛地要求 Agent 更认真；
代替行动 Agent 完成整体规划；
提出没有记忆依据的新猜测；
重复当前观察中已经很明显的信息。

5. 本文的定位

不同方法关注的问题可以对比如下：

方法类型	核心问题	典型输出
RAG	哪些历史内容与当前输入相似	检索记录
长期记忆系统	哪些信息需要持续保存	事实、事件或经验
上下文管理	如何压缩和组织历史	摘要或上下文片段
Advisor 模型	行动 Agent 接下来应该怎么做	通用策略建议
Proactive Memory Agent	哪条执行状态应该在此刻重新影响行动	定向提醒或保持沉默

本文的关键问题不是单纯的“记住什么”，而是：

是否、何时以及如何让记忆重新进入 Agent 的控制循环。

---

五、Proactive Memory Agent 方法总览

为了理解记忆 Agent 如何接入现有 Agent，可以先看论文 Figure 1。

图源：Wu et al., 2026，Figure 1(a)：System Integration。
行动 Agent 继续与环境交互；记忆 Agent 在独立流程中观察近期轨迹、维护记忆库，并决定是否向下一次行动调用插入提醒。

记忆 Agent 的内部流程如下：

图源：Wu et al., 2026，Figure 1(b)：Memory Agent Internals。
每个记忆步骤包含两个阶段：第一阶段管理结构化记忆库，第二阶段决定生成提醒或保持沉默。

完整流程可以表示为：

行动 Agent 接收任务
    ↓
行动 Agent 与环境交互
    ↓
记忆 Agent 读取近期轨迹
    ↓
Phase 1：更新结构化记忆库
    ↓
Phase 2：判断是否需要主动介入
    ↓
需要介入？
    ├── 是：生成一条具体提醒
    │       ↓
    │   插入行动 Agent 的下一次调用
    │
    └── 否：保持沉默
            ↓
        行动 Agent 正常执行

这里有三个重要设计：

第一：
行动与记忆分离。

第二：
记忆维护与记忆使用分离。

第三：
保持沉默也是一种显式动作。

---

六、问题定义

行动 Agent 与环境交互形成一条轨迹：

$$\tau =(o_1,a_1,o_2,a_2,\dots ,o_T)$$

其中：

• $o_t$ 表示时间步 $t$ 的环境观察；
• $a_t$ 表示时间步 $t$ 的行动；
• $\tau$ 表示完整任务轨迹。

给定任务描述 $x$ 和此前的执行轨迹，行动 Agent 按照策略 ${\pi }_A$ 生成下一步动作：

$$a_t\sim {\pi }_A(a_t\mid x,{\tau }_{<t})$$

其中：

• ${\pi }_A$ 是行动 Agent 的策略；
• $x$ 是任务描述；
• ${\tau }_{<t}$ 是时间步 $t$ 之前的执行轨迹。

在真实 Agent 框架中，行动 Agent 实际看到的内容可能已经经过：

截断；
摘要；
上下文折叠；
消息过滤；
工具结果压缩。

因此，并不是轨迹中的每条信息都会持续出现在行动 Agent 的上下文里。

本文增加一个独立的记忆 Agent ${\pi }_M$。

在记忆时间步 $t$，记忆 Agent读取：

任务描述 x；
最近的轨迹窗口 w_t；
当前记忆库 B_(t-1)。

近期轨迹窗口定义为：

$$w_t=W_k({\tau }_{<t},o_t)$$

其中，$W_k$ 表示从当前轨迹中提取最近 $k$ 条消息。

记忆 Agent 首先更新记忆库：

$$B_t\sim {\pi }_M^{\mathrm{edit}}(\cdot \mid x,w_t,B_{t-1})$$

然后决定是否介入：

$$i_t\sim {\pi }_M^{\mathrm{intervene}}(\cdot \mid x,w_t,B_t)$$

介入动作满足：

i t ∈ { ∅ , text reminder } i_t\in\{\varnothing,\text{text reminder}\} it​∈{∅,text reminder}

其中：

• $B_t$ 是更新后的记忆库；
• ${\pi }_M^{\mathrm{edit}}$ 是记忆编辑策略；
• ${\pi }_M^{\mathrm{intervene}}$ 是记忆介入策略；
• $\varnothing$ 表示不介入；
• text reminder 表示向行动 Agent 插入一条文本提醒。

因此，记忆 Agent 不仅要决定：

什么值得保存？

还要决定：

保存的内容现在是否值得重新进入行动循环？

---

七、结构化记忆库

记忆库是对任务执行状态的紧凑、结构化表示：

$$B_t=(s_t,K_t,P_t)$$

其中：

• $s_t$ 是记忆 Agent 的私有状态；
• $K_t$ 是知识记忆集合；
• $P_t$ 是过程记忆集合。

1. Status：私有状态

Status 用于记录：

当前任务进度；
尚未解决的问题；
潜在风险；
未完成子目标；
记忆 Agent 对当前任务的内部判断。

这部分内容只对记忆 Agent 可见，不会直接展示给行动 Agent。

例如：

当前状态：
正在修复日志解析逻辑。

开放问题：
IPv4 边界条件仍未通过测试。

后续要求：
修改正则表达式后需要运行完整测试。

私有状态可以让记忆 Agent 持续维护整个任务的视图，又不会把所有内部判断都塞进行动 Agent 的上下文。

2. Knowledge Memory：知识记忆

知识记忆保存任务期间相对稳定的事实。

例如：

任务要求；
环境属性；
文件路径；
配置细节；
用户验证的事实；
工具验证的事实；
评测相关约束。

一个知识记忆可能是：

ID：
task_requirement_01

内容：
不能修改公共接口的函数签名。

来源：
任务初始描述。

或者：

ID：
environment_02

内容：
当前容器使用 Python 3.10，并且没有 sudo 权限。

来源：
环境查询结果。

知识记忆记录的是：

Agent 已经确认了什么。

3. Procedural Memory：过程记忆

过程记忆保存行动 Agent 已经执行的尝试及其结果。

例如：

失败的命令；
成功的修复；
已经排除的假设；
错误模式；
诊断信号；
性能变化。

一个过程记忆可能是：

ID：
failed_attempt_03

尝试：
安装 package==2.0。

结果：
安装失败。

原因：
package==2.0 要求 Python 3.12，
当前环境为 Python 3.10。

结论：
不应在当前环境中重复尝试该版本。

过程记忆记录的是：

Agent 尝试过什么，以及结果怎么样。

这类记忆对于代码和终端 Agent 很重要。

如果系统只保存事实，不保存尝试及结果，行动 Agent仍然可能：

重复失败命令；
重新验证已经排除的假设；
丢失此前建立的错误诊断；
在相同调试循环中反复移动。

4. 标识符和元数据

每条记忆还包含：

简短标识符；
自然语言内容；
创建时间；
访问次数等元数据。

标识符使记忆 Agent 能够明确更新或删除过期内容。

例如：

原记忆：
environment_02
当前环境使用 Python 3.10。

环境升级后：
删除 environment_02，
再保存新的 Python 3.12 环境事实。

从工程角度看，记忆系统不能只支持 ADD。

它至少还需要：

UPDATE；
DELETE；
NOOP。

否则，长期运行后很容易同时保留互相冲突的新旧状态。

---

八、第一阶段：记忆库管理

每次记忆 Agent 被触发时，首先执行记忆库管理。

输入包括：

任务描述；
最近轨迹窗口；
当前记忆库。

记忆 Agent 不会直接自由重写整个记忆库，而是返回一组预定义的工具调用。

论文定义了四类记忆操作：

工具	作用
memory_update_status	更新任务进度、开放问题和风险
memory_save_knowledge	保存任务要求、环境事实、路径和约束
memory_save_procedural	保存失败尝试、诊断经验和成功修复
memory_delete	删除错误或过期的记忆

系统按照顺序执行这些工具调用。

如果记忆 Agent 没有返回任何工具调用，记忆库保持不变。

完整过程可以表示为：

任务描述
+
近期轨迹
+
当前记忆库
    ↓
记忆 Agent 分析
    ↓
生成零个或多个记忆操作
    ↓
系统依次执行操作
    ↓
得到更新后的记忆库

这种显式工具接口具有两个优点。

第一，它限制记忆 Agent 只能执行明确的记忆操作：

不是生成一段自由文本摘要，
而是决定更新哪一类状态。

第二，它允许系统保存不同类型的信息：

任务要求进入知识记忆；
环境属性进入知识记忆；
失败命令进入过程记忆；
任务进度进入私有状态。

例如，行动 Agent 执行：

pip install package==2.0

环境返回：

安装失败：
该版本要求 Python 3.12，
当前环境为 Python 3.10。

记忆 Agent 可以执行：

memory_save_knowledge：

当前运行环境为 Python 3.10。

同时执行：

memory_save_procedural：

package==2.0 因要求 Python 3.12 而安装失败，
当前环境下不应重复尝试。

同一个工具结果由此被拆分为：

稳定环境事实
+
带有结果的历史尝试

---

九、第二阶段：主动干预

更新完记忆库后，记忆 Agent 进入第二阶段：

判断哪条记忆是否应该在当前时刻重新影响行动 Agent。

该阶段不会继续修改记忆库。

它只做一个选择：

生成提醒
或
保持沉默

如果记忆 Agent 生成提醒，系统会将提醒作为独立的临时记忆上下文，插入行动 Agent 的下一次调用。

行动 Agent 的以下内容都保持不变：

基础系统指令；
工具集合；
模型参数；
解码过程；
原有 Agent 框架。

唯一变化是：

下一次调用可能多出一条记忆提醒。

1. 什么情况下应该介入？

论文认为，合适的干预包括：

行动 Agent 即将违反一条任务要求；
环境事实能够解释当前观察；
Agent 准备重复已经失败的尝试；
此前的错误诊断仍然有效；
某个开放子目标正在被忽略。

例如：

当前行动：
Agent 准备再次安装 package==2.0。

历史执行状态：
该版本此前已经因 Python 版本不兼容而失败。

记忆提醒：
package==2.0 要求 Python 3.12，
当前环境仍为 Python 3.10，
不要重复此前的安装方案。

这个提醒具有三个特点：

具体；
有历史依据；
会直接影响下一步行动。

2. 什么情况下不应该介入？

记忆 Agent 不应该：

给出宽泛的战略建议；
重复当前观察中已经存在的信息；
提出没有记忆依据的新推测；
代替行动 Agent 完成全部规划；
为了展示记忆能力而强制发言。

例如，下面的提醒没有太大价值：

请仔细思考，并结合历史信息采取正确行动。

它没有指出：

哪条历史状态重要；
为什么当前需要使用；
它应该如何改变下一步行动。

---

十、为什么保持沉默也是一种动作？

传统检索系统通常默认：

只要检索到相关内容，
就把内容加入上下文。

本文则将不介入表示为显式动作：

<no_intervention/>

这是因为提醒并不总是有益。

如果每一步都向行动 Agent 注入记忆，可能产生：

Token 消耗增加；
推理延迟增加；
行动 Agent 被无关信息干扰；
历史状态压过当前观察；
Agent 对不确定提醒进行额外验证；
局部任务推进速度下降。

因此，记忆 Agent需要学习两个方向的能力：

什么时候应该提醒；
什么时候应该保持沉默。

这也是本文相比一般检索式记忆最重要的增量：

记忆系统不再以“召回得越多越好”为目标，而是需要校准自身对行动循环的介入。

---

十一、如何触发记忆 Agent？

论文使用触发函数 $g(t)$ 决定何时运行记忆 Agent。

通用方法采用：

任务第一步触发；
后续按照固定间隔触发。

作者也讨论了更有针对性的触发条件：

工具调用报错；
测试失败；
检测到重复命令；
上下文发生较大变化；
Agent 长时间没有推进任务。

不过，论文为了单独研究记忆介入策略，没有在主实验中使用复杂的动态触发器。

需要区分论文中的两个设置。

1. 通用架构

方法章节描述的是：

第一步调用；
之后每隔 N 步调用。

2. 主实验配置

主实验实际采用：

第一步调用；
后续每一步都调用；
每次读取最近 8 条消息。

因此：

固定间隔是方法允许的通用机制，而每一步调用是主实验选择的具体间隔。

---

十二、学习记忆介入策略

Proactive Memory Agent 不要求重新训练模型。

主实验可以直接使用提示词驱动的前沿模型作为记忆 Agent。

但这种方式存在两个工程问题：

每个记忆步骤都增加一次模型调用；
提示词模型的介入判断未必经过良好校准。

因此，作者进一步探索：

能否训练一个开放权重模型，让它学习记忆管理和介入策略？

训练时保持行动 Agent 不变：

行动 Agent：
冻结的 Qwen3.5-122B-A10B。

记忆 Agent：
可训练的 Qwen3.5-27B。

训练数据：
SETA 终端 Agent 任务。

迁移评测：
Terminal-Bench 2.0。

训练分为两个阶段。

1. SFT：学习记忆接口

SFT 从提示词记忆 Agent 生成的轨迹中进行蒸馏。

训练内容包括：

如何执行记忆库操作；
如何简洁写入记忆；
如何更新过时状态；
如何删除错误记忆；
如何选择提醒或保持沉默。

SFT 主要让模型学会：

如何按照本文定义的接口管理记忆。

2. GRPO：校准介入时机

仅仅模仿提示词模型，不能保证提醒真正改善最终任务结果。

因此，作者进一步使用 GRPO，根据任务验证器奖励优化记忆 Agent。

优化目标不是：

写入更多记忆；
生成更多提醒；
让记忆库更加详细。

而是：

哪条记忆能够改善下一步行动？
什么时候需要介入？
什么时候保持沉默更好？

由于最终任务奖励比较稀疏，而一次任务中可能包含很多次记忆调用，作者重点训练离线轨迹中可能影响最终结果的关键转折步骤，即 Pivot Turns。

这说明训练记忆介入策略的难点在于：

最终任务成功或失败，究竟与哪一次记忆操作或提醒有关？

---

十三、实验设置

论文使用两个长时 Agent 评测基准：

Terminal-Bench 2.0；
τ²-Bench。

1. Terminal-Bench 2.0

Terminal-Bench 2.0 评估 Agent 在真实命令行环境中的任务执行能力。

Agent 需要：

检查文件；
运行命令；
修改代码；
调试错误；
满足隐藏验证器测试。

该基准中的行为状态衰减主要表现为：

忘记早期任务要求；
重复失败命令；
忽略环境观察；
丢失错误诊断；
在局部调试中偏离最终目标。

完整基准包含 89 个任务。

论文排除了 4 个与 Agent 行为无关的 Docker 失败任务，最终在 85 个有效配对任务上报告结果。

2. τ²-Bench

τ²-Bench 评估对话式工具 Agent 在动态服务环境中的表现。

论文使用三个领域：

领域	任务数量
Airline	50
Retail	114
Telecom	114
合计	278

这类任务要求 Agent：

维护多轮对话状态；
记住用户提供的信息；
使用工具验证用户状态；
遵守领域政策；
按照正确顺序执行工具；
在状态变更前检查资格条件。

3. 模型配置

论文评测了两种行动 Agent：

Claude Sonnet 4.5；
Claude Opus 4.6。

除开放权重模型训练实验外，默认记忆 Agent 为：

Claude Opus 4.6。

行动 Agent 在基线组和记忆组之间保持不变。

因此，实验主要比较：

相同的行动 Agent
+
是否增加记忆 Agent

4. 评测指标

论文使用 pass@1。

对于 Terminal-Bench 2.0：

最终通过任务验证器
→ 任务成功。

对于 τ²-Bench：

完整对话满足任务评估器
→ 任务成功。

---

十四、主实验结果

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

1. Terminal-Bench 2.0

行动模型	Baseline	+ Memory	提升
Sonnet 4.5	37.6%	45.9%	+8.3 pp
Opus 4.6	43.5%	45.9%	+2.4 pp

加入记忆 Agent 后：

Sonnet 4.5：
37.6% → 45.9%，提升 8.3 个百分点。

Opus 4.6：
43.5% → 45.9%，提升 2.4 个百分点。

2. τ²-Bench

领域	行动模型	Baseline	+ Memory	提升
Airline	Sonnet 4.5	68.0%	78.0%	+10.0 pp
Retail	Sonnet 4.5	49.1%	58.8%	+9.6 pp
Telecom	Sonnet 4.5	55.3%	57.9%	+2.6 pp
任务加权平均	Sonnet 4.5	55.0%	61.8%	+6.8 pp
Airline	Opus 4.6	76.0%	76.0%	+0.0 pp
Retail	Opus 4.6	64.9%	69.3%	+4.4 pp
Telecom	Opus 4.6	63.2%	64.9%	+1.8 pp
任务加权平均	Opus 4.6	66.2%	68.7%	+2.5 pp

3. 我的理解

记忆 Agent 对 Sonnet 4.5 的提升明显高于 Opus 4.6。

这说明能力较弱的行动 Agent 更容易出现行为状态衰减。

但在更强的 Opus 4.6 上，两个基准仍分别提高：

Terminal-Bench 2.0：
+2.4 pp。

τ²-Bench：
+2.5 pp。

这说明本文方法并不只是：

使用一个强模型补偿弱模型的推理能力。

即使行动 Agent 本身更强，跨步骤维护执行状态仍然具有独立价值。

不同领域的提升也不一致。

例如：

Sonnet 4.5 在 Airline 上提升 10.0 pp；
在 Retail 上提升约 9.6 pp；
在 Telecom 上只提升 2.6 pp。

Opus 4.6 在 Airline 上没有提升。

这说明记忆介入不是在所有任务中都能获得固定收益。

它更适合存在以下特征的任务：

跨轮次业务规则；
延迟生效的任务约束；
需要工具验证的用户状态；
不可逆或高风险的状态变更；
容易重复出现的失败循环。

---

十五、消融实验和方法对比

论文在 τ²-Bench 上比较了多个变体。

变体	记忆管理	介入方式	Macro	Micro
Sonnet 4.5 Baseline	无	无	57.5%	55.0%
Full Memory Agent	结构化记忆库	选择提醒或沉默	64.3%	61.2%
Full-bank Context	结构化记忆库	每步暴露完整记忆库	61.5%	58.6%
Always Inject	结构化记忆库	每步强制生成提醒	63.5%	61.5%
Injection-only	无持久记忆库	选择性指导或沉默	61.0%	60.8%
Mem0	Mem0 ADD	Vector + BM25 Top-10	62.1%	60.8%

其中：

Macro：
三个领域等权平均。

Micro：
根据不同领域的任务数量加权。

需要注意的是，论文 Table 2 中完整记忆 Agent 的部分结果与 Table 1 不完全相同。

例如：

Table 1 的 Retail 和任务加权平均：
58.8% 和 61.8%。

Table 2 中完整记忆 Agent：
57.0% 和 61.2%。

论文没有进一步解释这一差异。

因此，更稳妥的分析方式是：

在各自表格内部比较不同方法，而不直接跨表计算差值。

1. Full-bank Context：直接暴露完整记忆库

该变体保留第一阶段的记忆管理，但移除第二阶段的选择策略。

每一步都把完整记忆库交给行动 Agent：

维护结构化记忆
    ↓
不选择当前最重要的记忆
    ↓
直接暴露完整记忆库

结果表明：

Macro：
64.3% → 61.5%。

Micro：
61.2% → 58.6%。

这说明：

维护记忆是有用的，但让所有记忆始终可见仍然不够。

行动 Agent 仍然需要从完整记忆库中判断：

哪条记忆与当前行动有关；
哪条约束即将被违反；
哪条失败经验不应该重复。

这又可能重新引入信息稀释问题。

2. Always Inject：每一步强制提醒

该变体保留结构化记忆库和提醒生成能力，但取消保持沉默的选项。

它必须在每一步生成提醒。

结果为：

Full Memory Agent：
Macro 64.3%，Micro 61.2%。

Always Inject：
Macro 63.5%，Micro 61.5%。

Always Inject 在 Micro 上高出 0.3 个百分点，但完整方法在 Macro 上高出 0.8 个百分点。

论文认为，Micro 上的微小差距可能处于运行方差范围内。

因此，不能简单得出：

选择性介入在所有指标上都超过强制提醒。

更准确的结论是：

强制提醒有时也能产生较高收益；
选择性介入在不同领域之间更加均衡；
保持沉默可能减少不必要干扰；
二者的稳定差异仍需要更多重复实验验证。

3. Injection-only：只有 Advisor，没有记忆库

该变体移除持久记忆库，只让辅助模型根据近期轨迹生成指导。

它类似于 Advisor 模型：

近期轨迹
    ↓
辅助模型分析
    ↓
生成建议或保持沉默

该方法在 Telecom 上表现较好，但在 Airline 上从 68.0% 降到 62.0%。

这说明：

辅助模型即使能力较强，如果缺少持续维护的执行状态，其建议也可能不稳定。

它只能根据近期窗口判断，而无法可靠访问更早的：

工具验证事实；
领域规则；
失败尝试；
开放子目标。

4. 与 Mem0 的对比

Mem0 通过 ADD 接口写入记忆，再使用向量与 BM25 混合检索返回 Top-10 结果。

其流程为：

写入持久记忆
    ↓
Vector + BM25 检索
    ↓
返回 Top-10
    ↓
加入行动 Agent 上下文

Mem0 的 Macro 和 Micro 都高于基线，说明通用持久记忆和检索确实有效。

但它在 Airline 上没有超过基线，Macro 也低于完整记忆 Agent。

两者的主要区别是：

Mem0：
检索哪些历史记录？

Proactive Memory Agent：
当前是否需要介入？
应该使用哪条执行状态？
应该如何把它表达成定向提醒？

因此，本文不是否定检索式记忆，而是在存储和检索之上增加一层：

面向下一步行动的介入策略。

---

十六、质性分析

论文 Table 3 总结了五类典型的记忆干预机制。

机制	典型记忆内容	作用
任务要求或政策重新激活	允许或禁止某项操作的规则	防止违反约束
环境事实重新激活	路径、工具限制和运行环境	避免错误环境假设
避免失败循环	已尝试方案及其失败原因	防止重复无效尝试
延续错误诊断	Bug 根因或负面信号	保持调试连续性
进度与实体跟踪	用户、订单、分支或子目标	防止操作错误对象或遗漏步骤

1. Terminal-Bench：维持调试连续性

在 Terminal-Bench 中，记忆主要用于保持调试过程的连续性。

例如，在 regex-log 任务中，记忆 Agent 会重新激活：

正则表达式的边界要求；
此前发现的错误模式；
当前实现仍然遗漏的特殊输入。

论文提到，提醒指出当前正则表达式遗漏了单数字 IPv4 字段等边界情况。

在 adaptive-rejection-sampler 任务中，记忆 Agent 保存了：

哪些文件修改已经失败；
失败与环境之间的关系；
后续可以尝试的环境特定替代方案。

这类案例说明，编程 Agent 的记忆不应该只保存代码内容。

它还需要保存：

尝试了什么；
观察到了什么；
为什么失败；
当前证据支持什么结论；
还有哪些约束没有满足。

2. τ²-Bench：重新激活规则和交互状态

在一个 Airline 案例中：

用户声称：
自己是 Gold 会员。

工具查询结果：
实际会员等级为 Regular。

基线 Agent 根据用户自述发放了补偿。

记忆增强 Agent 则在操作前收到提醒：

应当使用经过工具验证的会员记录，
不能只依赖用户自述。

另一个案例中，记忆 Agent 重新激活了：

Basic Economy 航班不能执行当前修改操作。

从而避免了一次不符合政策的状态变更。

这些案例说明：

最有价值的提醒往往发生在 Agent 即将执行状态变更工具之前。

---

十七、开放权重记忆 Agent 的训练结果

论文 Table 4 首先报告了 SETA 验证结果。

设置	平均奖励	解决任务数	相对变化
仅行动 Agent，无记忆	0.709	56	—
基础 Qwen3.5-27B 记忆 Agent	0.693	54	-0.016
SFT 记忆 Agent	0.720	58	+0.011
GRPO 记忆 Agent	0.734	58	+0.025

未经训练的基础记忆 Agent 反而使平均奖励下降：

0.709 → 0.693

解决任务数也从 56 降到 54。

这说明：

增加一个记忆 Agent 并不天然有益。

如果记忆 Agent：

写入错误信息；
频繁插入无关提醒；
把推测当成事实；
重复行动 Agent 已知的内容；
在不需要时要求额外验证；

它就可能干扰行动 Agent。

SFT 后，平均奖励提高到：

0.720

说明模型首先需要学习：

结构化记忆接口；
基本的记忆管理纪律；
提醒和沉默之间的选择。

GRPO 将平均奖励进一步提高到：

0.734

说明强化学习主要改善了介入时机的校准。

1. 迁移到 Terminal-Bench 2.0

迁移结果如下：

设置	Pass@1	提升
Qwen3.5-122B-A10B 行动 Agent	37.6%	—
+ 训练后的 Qwen3.5-27B 记忆 Agent	41.1%	+3.5 pp

训练后的记忆 Agent 在未参与训练的 Terminal-Bench 2.0 上，将 Pass@1 从 37.6% 提高到 41.1%。

这提供了初步证据：

记忆管理接口可以通过 SFT 学习；
介入时机可以通过强化学习校准；
训练得到的记忆策略可以跨任务迁移。

不过，这仍然只是初步实验。

开放权重记忆 Agent 的提升低于部分前沿模型记忆 Agent 结果，也没有展示更大范围的跨领域迁移。

---

十八、本文方法的局限性

1. 记忆 Agent 仍然可能产生错误提醒

论文的质性分析显示，记忆 Agent 有时会：

把推测当成确定事实；
重复行动 Agent 已经知道的信息；
提出合理但没有必要的担忧；
触发额外验证；
干扰当前局部任务。

因此，系统的瓶颈已经从：

能否保存信息

逐渐转向：

能否正确判断介入时机

2. 记忆内容仍由语言模型生成

知识记忆和过程记忆都依赖语言模型提取。

如果模型错误理解工具结果，错误内容可能被：

写入记忆库；
长期保留；
在之后以提醒形式再次强化。

实际系统还需要增加：

记忆置信度；
信息来源；
工具验证状态；
冲突检测；
过期时间；
事实与推测的明确区分。

3. 每一步调用的成本较高

主实验使用 Claude Opus 4.6 作为记忆 Agent，并在后续每一步运行。

这意味着几乎每个行动步骤都增加一次额外模型调用。

生产环境还需要评估：

总 Token 消耗；
平均任务延迟；
单次任务成本；
记忆 Agent 调用次数；
实际介入比例；
每次有效介入带来的收益。

论文主要报告任务成功率，没有完整展示这些成本指标。

4. 双 Agent 系统增加工程复杂度

虽然行动 Agent 不需要修改，但整个系统仍然需要处理：

两个 Agent 的调度；
记忆库持久化；
记忆操作日志；
错误记忆回滚；
并发更新；
记忆版本管理；
提醒内容审计。

因此：

行动 Agent 无需修改
≠
系统没有额外集成成本

5. 当前评测场景有限

论文主要评测：

命令行任务；
客服领域的多轮工具调用。

尚未充分验证：

超长周期的软件开发；
Web 浏览和研究任务；
多 Agent 协作；
多模态环境；
跨会话任务；
持续数小时或数天的 Agent。

---

十九、未来方向

论文提出了几个未来方向：

联合训练记忆 Agent 和行动 Agent；
学习什么时候触发记忆 Agent；
比较原始事实提醒和抽象提醒；
进一步训练开放权重记忆策略。

结合实际 Agent 开发，我认为还可以继续研究：

根据工具错误动态触发记忆；
检测重复行动和失败循环；
为记忆增加来源和置信度；
学习不同记忆类型的过期策略；
在高风险工具调用前执行强制检查；
让多个 Agent 共享经过验证的过程经验；
将终端、文件、网页和图片统一为多模态执行记忆。

---

二十、我的理解和启发

1. 记忆不是向量数据库，而是控制系统的一部分

在实现 Agent 记忆时，我们很容易把问题简化为：

找一个向量数据库；
将历史消息切块；
计算 Embedding；
检索 Top-K；
拼接到 Prompt。

但向量数据库主要解决：

哪些历史信息与当前输入相似？

长时任务还需要解决：

哪条历史状态应该在此刻约束 Agent 的行动？

因此，一个完整的 Agent 记忆系统至少包含：

记忆写入
    ↓
记忆更新和删除
    ↓
记忆检索
    ↓
决策相关性判断
    ↓
介入时机判断
    ↓
提醒内容生成
    ↓
行动结果反馈

传统记忆系统更多关注前半部分。

本文主要补充了后半部分。

2. 事实记忆和过程记忆需要分开

事实记忆可以告诉 Agent：

项目使用 Python 3.10；
配置文件位于某个路径；
用户不允许修改某个接口。

过程记忆则告诉 Agent：

哪个安装方案已经失败；
哪个错误假设已经排除；
哪次修改减少了测试失败数量；
哪个环境限制导致普通方法不可行。

如果只保存事实，不保存尝试及结果，Agent 仍然可能反复进入同一个失败循环。

对于代码 Agent、终端 Agent 和研究 Agent，过程记忆可能与事实记忆同样重要。

3. 记忆写入和提醒必须解耦

本文给我最直接的工程启发是：

值得保存，不等于现在就应该出现在上下文中。

一条任务约束可能需要保存几十步，但只在 Agent 即将执行危险操作时才需要提醒。

因此，可以将记忆设计成两层：

持久层：
保存未来可能有用的执行状态。

激活层：
决定当前真正需要进入上下文的信息。

这种设计既能保留长期状态，又能避免把完整记忆库变成越来越长的系统提示词。

4. 如何应用到自己的 Agent 项目？

如果在自己的代码或工具调用 Agent 中实现类似机制，我会先从简化版本开始。

第一步：划分结构化执行记忆

至少包含：

constraints：
任务约束。

environment：
环境事实。

attempts：
历史尝试和结果。

diagnoses：
错误诊断。

open_goals：
尚未完成的子目标。

每条记忆增加：

唯一 ID；
来源步骤；
创建时间；
最后验证时间；
置信度；
是否经过工具验证；
当前是否仍然有效。

第二步：支持完整生命周期

记忆操作不应只有 ADD。

还需要：

UPDATE；
DELETE；
MERGE；
INVALIDATE；
NOOP。

否则，同一个事实发生变化后，记忆库可能同时保留互相冲突的新旧版本。

第三步：优先使用事件触发

初期不一定每一步都调用记忆 Agent。

可以优先在以下事件发生时触发：

测试失败；
工具报错；
检测到重复命令；
即将修改重要文件；
即将执行不可逆操作；
即将调用状态变更工具；
连续多步没有推进任务；
上下文即将被压缩。

第四步：让提醒保持短小、具体

一个有效提醒最好包含：

当前即将忽略的状态；
该状态的证据；
它为什么与下一步行动相关。

例如：

检测到你准备再次安装 package==2.0。

该版本此前已因要求 Python 3.12 而失败，
当前环境仍然是 Python 3.10。

而不是：

请认真回顾历史信息并采取更好的策略。

5. 与其他记忆方法的联系

不同方法可以理解为解决记忆系统中的不同层次：

方法	核心关注点
Mem0	如何维护可持久化的事实记忆
A-MEM	记忆之间如何动态建立关联
TrustMem	如何提高记忆更新的可靠性
LightMem	如何降低长期记忆运行成本
HORMA	如何组织并主动导航层级工作记忆
Proactive Memory Agent	记忆何时应该重新进入行动控制循环

这些方法并不完全互斥。

一个更完整的生产级 Agent 记忆系统可以采用：

Mem0 类方法：
管理持久化事实。

A-MEM 或 HORMA 类方法：
组织记忆关系和层级结构。

TrustMem 类方法：
验证记忆更新过程。

Proactive Memory Agent：
判断哪些记忆应该在当前步骤被激活。

---

二十一、总结

本文提出 Proactive Memory Agent，用独立的记忆 Agent 解决长时任务中的行为状态衰减问题。

它的核心流程为：

观察近期执行轨迹；
维护结构化执行状态；
区分知识记忆和过程记忆；
通过工具调用更新或删除记忆；
判断某条记忆是否会影响下一步行动；
必要时生成具体提醒；
不需要时保持沉默。

实验表明，该方法在 Terminal-Bench 2.0 和 τ²-Bench 上均能提高任务成功率。

消融实验进一步说明：

只暴露完整记忆库不够；
只使用 Advisor 模型不够稳定；
通用记忆检索本身有用；
每一步强制提醒可能带来干扰；
结构化记忆与选择性介入的组合更加均衡。

不过，该方法也增加了模型调用、推理延迟和系统复杂度。

记忆 Agent 还可能因为错误推断、重复提醒或过度介入而降低性能。

因此，未来更重要的问题可能不再是：

如何让 Agent 记住更多？

而是：

如何以更低的成本，准确判断哪条记忆应该在什么时刻重新获得对 Agent 行为的控制力？

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

Agent 记忆不应该只是一个等待查询的历史数据库，而应该成为一套能够维护执行状态、识别决策风险，并在关键时刻主动介入的控制机制。

---

参考资料

• Yifan Wu, Lizhu Zhang, Yuhang Zhou, Mingyi Wang, Bo Peng, Serena Li, Xiangjun Fan, Zhuokai Zhao. Remember When It Matters: Proactive Memory Agent for Long-Horizon Agents. arXiv, 2026.
• Proactive Memory Agent 代码仓库