【论文阅读】Agent 记忆机制（82）：ReasoningBank——从成功与失败经验中沉淀可复用的推理记忆

文章目录

前言
零、论文基本信息
一、背景：为什么"保存轨迹"还不等于拥有经验
- [1. Trajectory Memory 的问题](#1. Trajectory Memory 的问题)
- [2. Workflow Memory 的边界](#2. Workflow Memory 的边界)
- [3. 失败为什么也可能是一种高质量监督](#3. 失败为什么也可能是一种高质量监督)
二、问题定义：流式测试阶段中的自我进化
[三、ReasoningBank 方法总览](#三、ReasoningBank 方法总览)
四、核心模块一：从轨迹中抽取推理记忆
- [1. 为什么不直接摘要轨迹](#1. 为什么不直接摘要轨迹)
- [2. 成功轨迹：抽取被验证过的策略](#2. 成功轨迹：抽取被验证过的策略)
- [3. 失败轨迹：抽取反事实与防错规则](#3. 失败轨迹：抽取反事实与防错规则)
- [4. LLM-as-a-Judge：没有标签时如何获得成败信号](#4. LLM-as-a-Judge：没有标签时如何获得成败信号)
五、核心模块二：检索、注入与更新
- [1. 检索](#1. 检索)
- [2. Consolidation](#2. Consolidation)
- [3. 为什么只检索一条经验](#3. 为什么只检索一条经验)
[六、核心模块三：Memory-aware Test-Time Scaling](#六、核心模块三：Memory-aware Test-Time Scaling)
- [1. 并行扩展：Self-Contrast](#1. 并行扩展：Self-Contrast)
- [2. 串行扩展：Self-Refinement](#2. 串行扩展：Self-Refinement)
- [3. 并行与串行的差别](#3. 并行与串行的差别)
七、实验设置
- [1. 数据集](#1. 数据集)
- [2. 对比方法](#2. 对比方法)
- [3. 模型与指标](#3. 模型与指标)
八、主实验：记住"推理原则"是否真的更有效
- [1. WebArena](#1. WebArena)
- [2. SWE-Bench Verified](#2. SWE-Bench Verified)
- [3. Mind2Web 的跨分布泛化](#3. Mind2Web 的跨分布泛化)
九、MaTTS：记忆与测试时扩展是否形成双向增益
十、消融、效率与鲁棒性
- [1. 失败轨迹并非天然有益](#1. 失败轨迹并非天然有益)
- [2. Judge 噪声](#2. Judge 噪声)
- [3. 成功与失败样本的步数](#3. 成功与失败样本的步数)
- [4. Token 成本](#4. Token 成本)
- [5. 小模型泛化](#5. 小模型泛化)
十一、案例与失败分析
- [1. 记忆让 Agent 从"最近记录"走向"完整历史"](#1. 记忆让 Agent 从“最近记录”走向“完整历史”)
- [2. 从 29 步降到 10 步](#2. 从 29 步降到 10 步)
- [3. 仍然存在的反例](#3. 仍然存在的反例)
[十二、与 Agent Memory 系列方法的横向比较](#十二、与 Agent Memory 系列方法的横向比较)
[十三、对 Coding Agent、Tool Agent 与 Multi-Agent 的启发](#十三、对 Coding Agent、Tool Agent 与 Multi-Agent 的启发)
- [1. Coding Agent：从 patch 日志中提炼调试策略](#1. Coding Agent：从 patch 日志中提炼调试策略)
- [2. Tool Agent：记住选择工具的条件，而不是调用字符串](#2. Tool Agent：记住选择工具的条件，而不是调用字符串)
- [3. Multi-Agent：让多条轨迹成为天然的 Self-Contrast](#3. Multi-Agent：让多条轨迹成为天然的 Self-Contrast)
- [4. 更可落地的记忆写入门槛](#4. 更可落地的记忆写入门槛)
十四、局限性
- [1. 研究集中于内容，没有系统比较记忆架构](#1. 研究集中于内容，没有系统比较记忆架构)
- [2. 检索仍然过于简单](#2. 检索仍然过于简单)
- [3. 记忆池缺乏遗忘、合并和版本控制](#3. 记忆池缺乏遗忘、合并和版本控制)
- [4. Judge 仍可能形成自我确认偏差](#4. Judge 仍可能形成自我确认偏差)
- [5. MaTTS 的收益伴随额外推理成本](#5. MaTTS 的收益伴随额外推理成本)
- [6. 实验领域仍然有限](#6. 实验领域仍然有限)
十五、我的理解与启发
- [1. ReasoningBank 的本质是"经验编译器"](#1. ReasoningBank 的本质是“经验编译器”)
- [2. Test-Time Scaling 获得了"跨任务剩余价值"](#2. Test-Time Scaling 获得了“跨任务剩余价值”)
- [3. 失败经验需要翻译，而不是归档](#3. 失败经验需要翻译，而不是归档)
- [4. 下一代 Agent Memory 应把内容、结构和控制器分开](#4. 下一代 Agent Memory 应把内容、结构和控制器分开)
十六、总结
参考资料

前言

在 Agent Memory 这条研究线上，前面的工作大多在回答两个问题：记忆应该以什么结构存在，以及面对新任务时应该怎样取回它。

A-MEM 强调记忆之间的动态关联，MAGMA 将不同粒度、不同功能的记忆组织起来，CoM 关注记忆压缩与长程上下文管理，ReMemR1 让 Agent 在写入记忆时能够回看历史，Mem²Evolve 则进一步讨论记忆如何随经验持续演化。它们共同推动 Agent 从"把历史对话存下来"，走向"维护一个能够被更新、检索和重组的长期记忆系统"。

但还有一个更基础的问题经常被忽略：

即使存储结构和检索机制都已经存在，Agent 究竟应该从一次执行中记住什么？

直接保存整条轨迹，信息完整但冗长、带有大量页面状态和偶然动作；抽取固定工作流，更短也更容易复用，却容易把一次成功路径误当成普适模板。更棘手的是失败轨迹：它没有给出一条可照抄的正确答案，但里面往往包含"以后不该再怎么做"的高价值信号。

ReasoningBank 将研究重点从 memory structure 转向 memory content。它不把轨迹本身当作记忆，而是让模型对成功和失败轨迹进行反思，从中提炼可以跨任务迁移的推理策略、决策依据与防错规则。随后，论文提出 Memory-aware Test-Time Scaling（MaTTS），让并行探索或连续自我修正产生的多条经验反过来改善记忆。

本文的唯一核心增量可以概括为：

ReasoningBank 把成功与失败轨迹蒸馏为可迁移的推理记忆，并通过 MaTTS 将测试时扩展产生的多样化经验持续沉淀为未来任务可复用的能力，从而把"一次任务上的额外计算"转化为"跨任务的持续自我进化"。

这不是一个更复杂的记忆数据库。它真正改变的是经验进入记忆之前的"抽取"环节，以及 test-time scaling 结束之后经验是否能够被保留下来。

零、论文基本信息

论文名称：ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory
发表平台：The Fourteenth International Conference on Learning Representations（ICLR 2026）
代码仓库 ：google-research/reasoning-bank
作者：Siru Ouyang, Jun Yan, I-Hung Hsu, Yanfei Chen, Ke Jiang, Zifeng Wang, Rujun Han, Long T. Le, Samira Daruki, Xiangru Tang, Vishy Tirumalashetty, George Lee, Mahsan Rofouei, Hangfei Lin, Jiawei Han, Chen-Yu Lee, Tomas Pfister

一、背景：为什么"保存轨迹"还不等于拥有经验

1. Trajectory Memory 的问题

最直接的做法是把历史任务的完整轨迹存下来：用户目标、每一步观察、思考、动作和最终结果全部保留。面对新任务时，再检索一条相似轨迹作为 in-context example。

这种方法的优点是没有丢失信息，问题却同样明显：

轨迹很长，页面元素、临时状态和重复动作会消耗大量上下文；
一条轨迹通常绑定具体网站、具体按钮和具体查询，迁移性有限；
成功轨迹也可能包含绕路，照搬并不等于高效；
失败轨迹如果原样放入上下文，可能让模型重复错误。

因此，trajectory memory 更接近"日志"，而不是已经加工过的"经验"。

2. Workflow Memory 的边界

AWM 一类工作会从轨迹中抽取固定操作流程，例如"进入订单页 → 翻页 → 找到最早记录"。相较于原始轨迹，workflow 更短，也更容易复用。

但工作流仍然假设任务存在相对稳定的动作模板。当动作空间开放、页面结构变化，或任务要求推理而不是重复操作时，固定序列容易失效。SWE-Bench 就是典型例子：不同代码库、不同 bug 所需的 Bash 命令与修改路径差异很大，很难抽出一条稳定工作流。

3. 失败为什么也可能是一种高质量监督

一次失败至少能提供三类信息：

错误诊断：失败发生在目标理解、检索、规划、工具调用还是验证阶段；
反事实策略：如果重新执行，哪个决策应被替换；
防错约束：今后遇到相似状态时，先检查什么、不要做什么。

关键不在于保存失败，而在于把失败转写成正向、可执行的 guardrail。比如"搜索结果太多"不是一条有用记忆；"当结果数量过大时，先收紧关键词并使用类别过滤器，再开始逐页浏览"才是。

在阅读 Figure 1 时，需要重点看三种记忆单位的差异：原始轨迹保存"发生了什么"，workflow 保存"动作顺序"，ReasoningBank 保存"为什么这样做，以及什么情况下应该这样做"。

Figure 1：Trajectory、Workflow 与 Reasoning Memory。 对比三种记忆内容，并展示 ReasoningBank 随任务推进获得更持续的累计成功收益。

图中的关键并不是 ReasoningBank 记得更多，而是它把单次任务中的偶然动作压缩成了可跨任务迁移的决策原则。随着已处理任务增加，这类原则能够在后续任务中反复复用，因此累计收益不容易像原始轨迹那样迅速饱和。

二、问题定义：流式测试阶段中的自我进化

论文考虑一串按时间到达的测试任务：

Q = { q 1 , q 2 , ... , q N } Q=\{q_1,q_2,\ldots,q_N\} Q={q1,q2,...,qN}

任务只能顺序看到，Agent 在处理 q i q_i qi 时不能访问未来任务，也拿不到人工标注的正确答案。这使问题不同于离线训练：系统必须一边解决当前任务，一边从自己的执行结果中生成可供未来使用的经验。

Agent 的策略写作：

π L ( ⋅ ∣ M , A ) \pi_L(\cdot\mid M,A) πL(⋅∣M,A)

其中， L L L 是基础大模型， M M M 是当前记忆库， A A A 是可用动作空间。执行到时刻 t t t 时，Agent 根据观察历史 o 0 : t o_{0:t} o0:t、动作历史 a 0 : t a_{0:t} a0:t 和记忆生成下一步动作：

a t + 1 ∼ π L ( o 0 : t , a 0 : t ; M , A ) a_{t+1}\sim\pi_L(o_{0:t},a_{0:t};M,A) at+1∼πL(o0:t,a0:t;M,A)

环境再依据转移函数更新状态：

s t + 1 ∼ T ( s t + 1 ∣ s t , a t ) s_{t+1}\sim T(s_{t+1}\mid s_t,a_t) st+1∼T(st+1∣st,at)

这一定义暴露出两个互相依赖的问题：

怎样从本次轨迹中提取既短又有迁移性的记忆；
怎样使用已有记忆提高当前任务表现，同时避免重复探索。

ReasoningBank 解决第一个问题，MaTTS 则把两个问题连接成闭环。

三、ReasoningBank 方法总览

阅读 Figure 2 时，应沿着"检索---执行---判断---抽取---写入"的方向看，而不是把它理解成普通 RAG。

Figure 2：ReasoningBank 总体框架。 Agent 检索历史推理记忆完成任务，再根据成功或失败结果抽取新的结构化记忆并写回记忆库。

对于每个新任务，系统执行五步：

用当前任务查询记忆库，取回最相关的历史经验；
将记忆注入 Agent 的系统提示，生成任务轨迹；
用 LLM-as-a-Judge 判断轨迹成功或失败；
根据结果使用不同反思方向，抽取结构化 reasoning memory；
将新条目加入记忆库，供未来任务检索。

每条 memory item 由三部分组成：

Title：策略的短名称，便于识别；
Description：一句话概括适用场景和主要作用；
Content：1～3 句可执行的推理步骤、决策依据或防错规则。

例如，一次购物任务中 Agent 只查看"Recent Orders"，误把最近订单当作第一次购买。原始轨迹包含大量点击细节，而高质量的 reasoning memory 可以被写成：

当问题要求"第一笔""最早"或完整历史时，不要把首页的最近记录当作全集；应进入完整列表，并检查分页或排序后再回答。

这条记忆不再绑定某个网站，也不要求复现原动作序列，却保留了真正影响正确性的判断。

四、核心模块一：从轨迹中抽取推理记忆

1. 为什么不直接摘要轨迹

普通摘要倾向于复述"Agent 做了什么"，而 ReasoningBank 要提炼"为什么成功或失败，以及以后应怎样决策"。论文因此在提示词中加入三项约束：

最多抽取 3 条 memory item；
不允许条目之间重复；
不得写入具体网站、查询文本或页面字符串，而要保留可迁移行为。

这一约束很重要。没有它，所谓 reasoning memory 很容易退化成短一点的 trajectory memory。

2. 成功轨迹：抽取被验证过的策略

对成功轨迹，抽取器先解释成功原因，再生成可复用策略。真正值得记住的不是"点击了哪个按钮"，而是类似以下原则：

面对需要全局最值的问题，先确认当前列表是否完整；
修改状态后重新读取页面，避免使用过期观察；
在执行不可逆操作之前核对对象、数量和目标状态。

成功提供的是正向证据：某种决策在当前环境中已经被执行结果验证。

3. 失败轨迹：抽取反事实与防错规则

对失败轨迹，系统不要求复述错误，而是要求回答：

失败的关键原因是什么；
哪个决策点本可以改变结果；
如何把教训表达成未来可执行的策略。

例如，在查找某品牌蓝牙耳机及价格范围的任务中，Agent 使用过宽的搜索词，随后在大量无关商品中不断翻页，最终耗尽步数。ReasoningBank 抽取出的不是"翻页失败"，而是"优化查询、调整每页显示数量、优先使用筛选器"。

这说明失败记忆的正确形式不是 negative demonstration，而是经过反事实加工后的正向行为约束。

4. LLM-as-a-Judge：没有标签时如何获得成败信号

测试阶段没有 ground truth，论文使用与 Agent 相同的 backbone LLM 作为二分类 Judge。它接收：

用户意图；
完整执行轨迹；
网页最终状态；
Agent 最终回复。

然后输出 success 或 failure。为了提高稳定性，Judge 温度设为 0；记忆抽取器温度为 1.0，以保留一定策略多样性。

这一设计让系统可以在线运行，但也产生了一个依赖链：

Judge 标签 → 反思方向 → 记忆内容 → 未来行为 \text{Judge 标签}\rightarrow\text{反思方向}\rightarrow\text{记忆内容}\rightarrow\text{未来行为} Judge 标签→反思方向→记忆内容→未来行为

一旦 Judge 将失败误判为成功，系统可能把错误策略当作正例写入长期记忆。因此论文后续专门测试了标签噪声鲁棒性。

五、核心模块二：检索、注入与更新

1. 检索

系统用 gemini-embedding-001 对当前任务和历史任务编码，以余弦距离检索最相似经验，默认只取 top- k = 1 k=1 k=1。

如果查询向量为 e q e_q eq，某历史任务向量为 e i e_i ei，相似度可以写成：

sim ⁡ ( q , i ) = e q ⊤ e i ∥ e q ∥ ∥ e i ∥ \operatorname{sim}(q,i)=\frac{e_q^\top e_i}{\|e_q\|\,\|e_i\|} sim(q,i)=∥eq∥∥ei∥eq⊤ei

这里检索的是与 memory item 关联的任务经验。被取回的条目以 title 和 content 形式注入系统提示，并要求 Agent 在每一步先判断该记忆是否适用，再决定是否采用。

这个显式判断可以减少"检索到了就照做"的机械复用，但它并不能彻底解决语义相似而操作条件不同的问题。

2. Consolidation

论文采用非常克制的更新策略：新抽取的条目直接追加到 JSON 记忆池，不做合并、遗忘、层级化或冲突消解。

表面上看这是系统的简陋之处，实验上却是一个有意控制变量：如果在这种简单存储和检索机制下，ReasoningBank 仍优于 Synapse 与 AWM，增益就更可能来自记忆内容的改变，而不是复杂记忆架构。

3. 为什么只检索一条经验

附录的敏感性实验给出一个反直觉结果：WebArena-Shopping 上，无记忆成功率为 39.0%，检索 1 条经验时达到 49.7%；继续增加到 2、3、4 条后，成功率反而依次降到 46.0%、45.5% 和 44.4%。

Figure 13：检索经验数量敏感性。 单条高相关经验效果最好，继续增加经验会引入冲突和噪声。

这表明 memory scaling 不能简单理解为"检索越多越好"。对于 Agent，额外记忆会同时增加条件判断负担、冲突概率和提示长度。真正稀缺的是高相关、高质量且条件清晰的经验。

六、核心模块三：Memory-aware Test-Time Scaling

传统 test-time scaling（TTS）为同一个任务采样多条轨迹，或者让模型多轮自我修正，以增加当前任务成功概率。但任务完成之后，这些额外计算通常被丢弃。

MaTTS 的关键变化是：把 scaling 产生的多轨迹或多轮修正视为一组训练信号，并将其聚合成未来可复用的记忆。

阅读 Figure 3 时，需要区分"多跑几次"与"从多次运行的差异中学习"。前者只是 vanilla TTS，后者才是 MaTTS。

Figure 3：Vanilla TTS 与 MaTTS。 并行模式用多轨迹自对比抽取共同规律，串行模式利用连续自我修正中的中间经验更新记忆。

1. 并行扩展：Self-Contrast

并行模式针对同一任务独立生成 k k k 条轨迹：

τ i ( 1 ) , τ i ( 2 ) , ... , τ i ( k ) \tau_i^{(1)},\tau_i^{(2)},\ldots,\tau_i^{(k)} τi(1),τi(2),...,τi(k)

系统比较这些轨迹，寻找：

多个成功轨迹共同采用的稳定策略；
成功与失败轨迹之间的关键分歧；
只在单次采样中出现的偶然动作；
跨轨迹都应避免的低效循环。

聚合器最多从全部轨迹中生成 5 条 memory item。与独立抽取每条轨迹相比，自对比能够过滤"碰巧成功"的路径，并利用成功/失败之间的差异定位真正的因果决策点。

串行模式先生成一条轨迹，然后反复要求模型重新检查：页面元素是否正确、动作是否与用户目标一致、答案是否完整。如果发现不一致就修正，否则确认答案。

它的价值不只在最后一版答案。初始错误、检查理由和后续修正形成了一条天然的反事实链：

初始决策 → 发现矛盾 → 修正策略 → 结果变化 \text{初始决策}\rightarrow\text{发现矛盾}\rightarrow\text{修正策略}\rightarrow\text{结果变化} 初始决策→发现矛盾→修正策略→结果变化

这些中间状态比单独的最终成功轨迹更容易暴露"为什么必须这样做"。

3. 并行与串行的差别

并行扩展强调多样性，适合发现多种解法并进行对比；
串行扩展强调纠错，较少采样时收益更快，但容易沿最初路径局部修补；
当 k = 5 k=5 k=5 时，并行 MaTTS 在 WebArena-Shopping 达到 55.1%，略高于串行的 54.5%。

Figure 4：MaTTS 扩展曲线。 并行与串行扩展都受益于推理记忆，串行前期增长更快，并行在较大 k k k 下更有潜力。

七、实验设置

1. 数据集

WebArena：684 个真实网页交互任务，覆盖 Shopping（187）、Admin（182）、GitLab（180）、Reddit（106）和 Multi-site（29）；
Mind2Web：1341 个离线网页操作任务，包括 Cross-Task（252）、Cross-Website（177）和 Cross-Domain（912）；
SWE-Bench Verified：500 个经人工核验的代码仓库级 bug 修复任务。

2. 对比方法

No Memory：只使用基础 Agent；
Synapse：检索原始历史轨迹作为示例；
AWM：从历史轨迹中抽取可复用 workflow；
ReasoningBank：抽取成功与失败中的推理策略；
ReasoningBank + MaTTS ：在 ReasoningBank 上加入并行记忆感知扩展， k = 5 k=5 k=5。

为隔离变量，各方法共享相同的检索和 consolidation 机制，主要差别是 memory extraction。

3. 模型与指标

网页实验使用 Gemini-2.5-Flash、Gemini-2.5-Pro 和 Claude-3.7-Sonnet，生成温度为 0.7。WebArena 采用 BrowserGym 与 ReAct，单任务最多 30 步。

WebArena 报告成功率：

S R = 1 N ∑ i = 1 N isSuccess ⁡ ( q i ) SR=\frac{1}{N}\sum_{i=1}^{N}\operatorname{isSuccess}(q_i) SR=N1i=1∑NisSuccess(qi)

以及平均交互步数：

A S = 1 N ∑ i = 1 N Steps ⁡ ( q i ) AS=\frac{1}{N}\sum_{i=1}^{N}\operatorname{Steps}(q_i) AS=N1i=1∑NSteps(qi)

Mind2Web 使用 Element Accuracy、Action F1、Step Success Rate 和完整任务 Success Rate。SWE-Bench Verified 报告 Resolve Rate、Patch Apply Rate 与平均步数。

八、主实验：记住"推理原则"是否真的更有效

1. WebArena

Backbone	方法	Overall SR（%）	平均步数
Gemini-2.5-Flash	No Memory	40.5	9.7
	Synapse	42.1	9.2
	AWM	44.1	9.0
	ReasoningBank	48.8	8.3
	ReasoningBank + MaTTS	51.8	7.9
Gemini-2.5-Pro	No Memory	46.7	8.8
	Synapse	47.7	8.5
	AWM	47.6	8.7
	ReasoningBank	53.9	7.4
	ReasoningBank + MaTTS	56.3	7.1
Claude-3.7-Sonnet	No Memory	41.7	8.0
	Synapse	42.6	7.9
	AWM	40.8	8.9
	ReasoningBank	46.3	7.3
	ReasoningBank + MaTTS	48.8	7.2

Table 1：WebArena 总体结果。 ReasoningBank 和 MaTTS 在三种 backbone 上同时提高成功率并减少平均交互步数。

最强结论不是某一个模型上的绝对最高分，而是趋势跨模型家族保持一致：

Flash 上 ReasoningBank 相对无记忆提升 8.3 个百分点；
Pro 上提升 7.2 个百分点；
Claude 上提升 4.6 个百分点，而 AWM 反而下降 0.9 个百分点。

这说明固定 workflow 对模型和环境更敏感，而推理原则的迁移范围更广。加入 MaTTS 后三个模型分别再提升 3.0、2.4 和 2.5 个百分点，支持"扩展产生的多样经验可以继续改善记忆"的判断。

需要注意，平均步数是所有任务上的均值，单独下降并不必然代表更聪明：Agent 也可能更早失败。因此论文进一步拆分成功和失败样本，后文再分析。

2. SWE-Bench Verified

Backbone	方法	Resolve Rate（%）	平均步数
Gemini-2.5-Flash	No Memory	34.2	30.3
	Synapse	35.4	30.7
	ReasoningBank	38.8	27.5
Gemini-2.5-Pro	No Memory	54.0	21.1
	Synapse	53.4	21.0
	ReasoningBank	57.4	19.8

Table 2：SWE-Bench Verified 结果。 ReasoningBank 在开放式 Bash 动作空间中提高修复率并减少执行步数。

这一结果比网页任务更能说明 reasoning memory 与 workflow memory 的区别。代码修复没有稳定的按钮序列，AWM 因难以抽取固定流程而未被纳入对比；ReasoningBank 仍可以保存"先复现失败、定位最小责任范围、修改后运行针对性测试、最后检查回归"这类策略。

但提升幅度仍是 3.4～4.6 个百分点，而不是把旧任务解法直接迁移到新仓库。它证明的是通用调试原则有价值，并不意味着记忆可以替代代码理解。

3. Mind2Web 的跨分布泛化

Backbone	方法	Cross-Task EA / SSR / SR	Cross-Web EA / SSR / SR	Cross-Domain EA / SSR / SR
Flash	No Memory	46.0 / 40.3 / 3.3	39.8 / 31.7 / 1.7	35.8 / 31.9 / 1.0
Flash	Synapse	47.0 / 41.2 / 3.5	40.3 / 32.1 / 1.9	36.3 / 32.4 / 1.1
Flash	AWM	46.3 / 41.0 / 3.5	39.1 / 31.7 / 2.1	33.3 / 30.1 / 0.7
Flash	ReasoningBank	52.1 / 44.9 / 4.8	44.3 / 33.9 / 2.3	40.6 / 36.6 / 1.6
Pro	No Memory	49.3 / 44.4 / 3.5	41.2 / 34.8 / 3.4	37.9 / 35.0 / 1.4
Pro	Synapse	50.1 / 44.7 / 3.6	41.8 / 35.0 / 3.2	38.5 / 35.6 / 1.5
Pro	AWM	48.6 / 44.4 / 3.7	41.9 / 34.8 / 2.3	37.3 / 34.4 / 1.2
Pro	ReasoningBank	53.6 / 45.6 / 5.1	46.1 / 36.9 / 3.8	42.8 / 38.1 / 1.7

Table 3：Mind2Web 跨任务、跨网站与跨领域结果。 表中依次给出 Element Accuracy、Step Success Rate 和完整任务 Success Rate。

Cross-Domain 是最值得看的部分。环境表面形式变化越大，记住具体轨迹和固定流程越难复用；ReasoningBank 仍在 Flash 上把 EA 从 35.8 提到 40.6，在 Pro 上从 37.9 提到 42.8。这与论文主张一致：抽象到"决策原则"的记忆比动作模板更抗分布变化。

不过完整任务 SR 依然很低，最高只有 1.7%。原因是 Mind2Web 的任务需要所有中间步骤都正确，单步小误差会连乘。ReasoningBank 改善了局部决策，却没有解决长链执行中的误差累积。

九、MaTTS：记忆与测试时扩展是否形成双向增益

Figure 5：WebArena-Shopping 上的记忆---扩展协同。 更强的记忆提高 Pass@1 与 Best-of-5，ReasoningBank 与 MaTTS 的组合收益最大。

在并行 k = 5 k=5 k=5 设置中：

无记忆：不扩展/Pass@1 为 39.0%，Best-of-5 为 42.2%；
Synapse：40.6% / 41.2% / 44.4%；
AWM：44.4% / 45.5% / 47.6%；
ReasoningBank：49.7% / 53.0% / 55.1%。

它展示了两个方向的协同：

memory → scaling：高质量记忆让每条 rollout 的起点更好，Pass@1 已经提升；
scaling → memory：多条轨迹提供对比信号，聚合后的 memory 又优于"分别抽取但不聚合"的 vanilla TTS。

附录的 Pass@ k k k 结果进一步显示， k = 5 k=5 k=5 时完整 MaTTS 达到 62.1%，无记忆扩展只有 52.4%。因此 MaTTS 不是单纯靠"抽奖式采样"抬高上界，而是在改善每次采样的质量和多样性。

Figure 14：并行 MaTTS 的 Pass@ k k k。 记忆感知聚合在较小 k k k 时提高样本效率，并在 k k k 增大时保持更强增长。

十、消融、效率与鲁棒性

1. 失败轨迹并非天然有益

Figure 7：失败轨迹消融。 对比只用成功轨迹和同时使用失败轨迹时，三类记忆方法在 WebArena-Shopping 上的变化。

加入失败轨迹后：

Synapse：40.6% → 41.7%；
AWM：44.4% → 42.2%；
ReasoningBank：46.5% → 49.7%。

这是全文最有解释力的消融之一。失败经验并不会自动带来改进。AWM 试图从失败轨迹中抽 workflow，可能固化错误动作，因此性能下降；ReasoningBank 先诊断原因，再把失败转为防错策略，才能真正利用负向信号。

所以论文证据支持的准确说法是：经过反事实蒸馏的失败经验有价值，而不是"存更多失败案例有价值"。

2. Judge 噪声

Figure 8：LLM-as-a-Judge 噪声实验。 模拟不同判断准确率，观察错误成败标签对 ReasoningBank 的影响。

Judge 100% 准确时成功率为 52.4%，准确率降至 90%、80%、70%、60%、50% 时，结果分别约为 50.6%、49.7%、48.7%、47.6%、47.6%。论文实际测得 Gemini Judge 准确率为 72.7%。

系统对中等噪声有一定鲁棒性，50% 模拟准确率下仍高于无记忆的 39.0%。但曲线也证明 Judge 并非无关紧要：从完美标签到 70% 标签，性能损失 3.7 个百分点。更重要的是，随机翻转实验未必覆盖系统性偏差，例如 Judge 持续误判某类隐性约束。

3. 成功与失败样本的步数

方法	Shopping 成功/失败	Admin 成功/失败	GitLab 成功/失败	Reddit 成功/失败
No Memory	6.8 / 8.7	8.4 / 10.4	8.6 / 15.7	6.1 / 7.6
ReasoningBank	4.7 / 7.3	7.0 / 9.5	7.6 / 15.5	5.0 / 6.8

Table 4：成功与失败任务的平均步数。 ReasoningBank 在四个 WebArena 域中普遍减少交互，Shopping 成功任务降幅最大。

Shopping 成功样本从 6.8 步降到 4.7 步，减少 2.1 步，即 26.9%。失败任务的步数也没有明显增加，说明总体步数下降不是"更早放弃"造成的。

4. Token 成本

方法	动作生成	Judge	记忆抽取	总 Token
No Memory	50847.4	---	---	50847.4
Synapse	55920.5	2594.2	---	58514.7
AWM	53819.6	2479.1	3074.1	59372.8
ReasoningBank	49306.1	2186.3	1562.1	53054.5

Table 5：单任务平均 Token 成本。 ReasoningBank 增加 Judge 与抽取开销，但通过更短轨迹降低动作生成成本，总开销仅比无记忆高约 4.3%。

论文报告在约 4.3% 总 Token 增量下获得约 20.5% 的相对性能提升。值得注意的是，这只是 token 账，不等于完整部署成本：向量存储、检索延迟、多次 TTS rollout 和外部工具调用仍需要单独计算。

5. 小模型泛化

方法	Success Rate（%）	平均步数
No Memory	17.1	13.7
Synapse	16.0	14.0
AWM	21.4	12.5
ReasoningBank	24.1	11.8

Table 6：Gemma-3-12B-Instruct 上的 WebArena-Shopping 结果。 ReasoningBank 在较小开源模型上仍保持成功率和效率优势。

这说明方法并非只能依靠 frontier model 生效，但 24.1% 的绝对成功率也提醒我们：记忆主要放大基础模型已有能力，不能凭空补齐感知、规划和工具执行能力。

十一、案例与失败分析

1. 记忆让 Agent 从"最近记录"走向"完整历史"

Figure 15：首次购买日期案例。 无记忆 Agent 误用 Recent Orders，ReasoningBank 根据历史推理提示进入完整订单列表并继续翻页。

这类案例说明 reasoning memory 的价值常常不在提供答案，而在改变信息搜集范围。记忆告诉 Agent "当前可见表格不一定是全集"，最终答案仍需要重新浏览当前环境得到。

2. 从 29 步降到 10 步

Figure 16：男鞋筛选案例。 ReasoningBank 复用类别过滤策略，将导航过程从 29 步缩短到 10 步。

无记忆 Agent 在页面中反复滚动，ReasoningBank 则先通过类别导航到 Men，再按价格与评论数筛选。这里复用的是"先利用站点信息架构缩小搜索空间"的策略，而不是固定坐标或按钮文本。

3. 仍然存在的反例

论文结果中至少能看到三类边界：

检索经验从 1 条增加到 4 条，成功率下降 5.3 个百分点，表明记忆冲突尚未解决；
AWM 加入失败轨迹后性能下降，说明错误经验若未正确抽象会污染行为；
Mind2Web 的完整任务成功率仍只有个位数，说明局部策略改进无法消除长链误差累积。

这些反例共同指向：ReasoningBank 提高了 memory content 的质量，但没有自动解决记忆路由、冲突管理和长程信用分配。

十二、与 Agent Memory 系列方法的横向比较

方法	主要记忆对象	核心关注点	与 ReasoningBank 的差别
A-MEM	原子记忆及其动态链接	记忆关联与结构演化	A-MEM 更关注记忆如何组织；ReasoningBank 更关注轨迹应被蒸馏成什么内容
MAGMA	多粒度、多类型记忆	分层组织与协同检索	MAGMA 解决异构记忆架构；ReasoningBank 的推理条目可以成为其中一种记忆类型
CoM	压缩后的长期上下文	在信息保留与上下文成本之间平衡	CoM 强调压缩已有内容；ReasoningBank 强调从执行结果提取可操作策略
ReMemR1	可回访的历史记忆	写入时主动回看，修复不可逆信息损失	ReMemR1 改变 memory update 的历史访问方式；ReasoningBank 改变轨迹到记忆的内容抽取方式
Mem²Evolve	可持续演化的记忆	让记忆随新经验迭代	两者都强调演化；ReasoningBank 用成功/失败反思与 TTS 经验给出具体在线信号
Synapse	原始轨迹 exemplar	用相似过去示范当前行动	信息完整但冗长、容易过拟合具体界面
AWM	可复用动作 workflow	从轨迹提取固定操作程序	对稳定流程有效，对开放动作空间和失败经验较脆弱
ReasoningBank	推理策略、决策依据与防错规则	决定什么经验值得进入长期记忆	结构简单，但内容抽象程度更高，并与 TTS 形成闭环

ReasoningBank 与这些方法更像正交关系，而不是全面替代关系。它采用的 JSON 存储、top-1 向量检索和直接追加都很基础；A-MEM/MAGMA 的结构化组织、ReMemR1 的历史回访机制、CoM 的压缩能力，理论上都可以与 reasoning memory 组合。

真正值得保留的分工是：

ReasoningBank 决定记什么 + 结构化记忆方法决定怎么组织和取用 \text{ReasoningBank 决定记什么}\quad+\quad \text{结构化记忆方法决定怎么组织和取用} ReasoningBank 决定记什么+结构化记忆方法决定怎么组织和取用

十三、对 Coding Agent、Tool Agent 与 Multi-Agent 的启发

以下内容是基于论文机制的工程推演，不是论文已经完成的实验结论。

1. Coding Agent：从 patch 日志中提炼调试策略

Coding Agent 不应只保存最终 diff。更可迁移的记忆包括：

失败测试与责任模块之间的定位线索；
哪类修改曾导致回归，以及提交前需要补跑哪些测试；
某类仓库约定、构建入口和最小复现流程；
"症状相似但根因不同"时应验证的分叉条件。

失败 patch 尤其有价值，但必须转换成 guardrail。例如"改 parser 失败"没有帮助；"遇到嵌套语法时，先检查 tokenizer 是否已丢失边界，再修改 parser"才可复用。

2. Tool Agent：记住选择工具的条件，而不是调用字符串

工具调用日志往往包含具体参数和临时 ID，不适合直接复用。Reasoning memory 应记录：

什么任务条件下选择哪个工具；
调用前必须验证哪些前置条件；
何种错误意味着重试，何种错误意味着换工具；
高风险操作之前需要怎样的只读检查。

这会把"工具使用历史"提升为"工具路由策略"。

3. Multi-Agent：让多条轨迹成为天然的 Self-Contrast

多个 Agent 对同一任务给出不同计划，本身就是 MaTTS 的并行轨迹。与简单投票相比，可以进一步抽取：

多个成功方案中的共同不变量；
失败方案缺少的关键检查；
各方案适用的边界条件；
冲突出现时需要补充的证据。

这样，多 Agent 的额外计算不只服务本次决策，还能沉淀为团队共享的 reasoning memory。

4. 更可落地的记忆写入门槛

生产系统可以在写入前增加四个字段：

applicability：适用条件；
evidence：来自成功、失败还是多轨迹共识；
confidence：验证强度；
counterexample：已知不适用情况。

它们可以缓解论文当前"直接追加"带来的冲突与污染问题。

十四、局限性

1. 研究集中于内容，没有系统比较记忆架构

作者明确说明，论文刻意采用简单检索和 consolidation，以隔离 memory content 的贡献。因此它没有回答 episodic、hierarchical、graph 或 working memory 与 ReasoningBank 结合后孰优孰劣。

2. 检索仍然过于简单

只按任务 query 的 embedding 相似度取 top-1，无法显式建模任务阶段、工具状态、时间、成本和不确定性。附录已经证明多取几条会产生噪声，说明系统需要的是更好的 router 与冲突消解，而不是扩大 context。

3. 记忆池缺乏遗忘、合并和版本控制

新条目直接追加，长期运行后会出现重复、过时和互相矛盾的策略。论文的流式实验尚不足以证明该机制能在数月或数年的生产环境中稳定扩展。

4. Judge 仍可能形成自我确认偏差

Agent、Judge 和抽取器使用相同 backbone，错误模式可能相关。随机标签噪声实验说明系统有鲁棒性，却不能排除模型把自己的错误解释为合理行为。更强 verifier、环境反馈、模型集成或人工抽检仍然必要。

5. MaTTS 的收益伴随额外推理成本

论文的 token 成本表主要分析单轨迹 ReasoningBank。并行 k = 5 k=5 k=5 或多轮 self-refinement 会显著增加延迟和调用成本。对于高频 Tool Agent，是否值得扩展应由任务价值、失败代价与历史复用概率共同决定。

6. 实验领域仍然有限

主要证据来自网页导航和软件工程。它们适合验证长程行动与工具使用，但还不能直接推断到具身机器人、医疗决策或开放世界多智能体协作。

十五、我的理解与启发

1. ReasoningBank 的本质是"经验编译器"

原始轨迹像运行日志，reasoning memory 像从日志编译出的可复用规则。一个好的经验编译器必须同时完成：

去除偶然细节 + 保留决策因果 + 明确适用条件 + 生成可执行规则 \text{去除偶然细节}+\text{保留决策因果}+\text{明确适用条件}+\text{生成可执行规则} 去除偶然细节+保留决策因果+明确适用条件+生成可执行规则

ReasoningBank 已经完成前两步，但对适用条件和冲突管理仍然较弱。这也是后续工作最值得补上的部分。

2. Test-Time Scaling 获得了"跨任务剩余价值"

以往 TTS 的计算预算只改善当前任务，任务结束后价值归零。MaTTS 让这些 rollout 产生第二份回报：它们之间的差异可被压缩为未来经验。

因此，同样的额外计算不再只是 inference cost，也可以被视为在线数据采集成本。只有当提取出的经验未来能多次复用时，这笔成本才真正摊薄。

3. 失败经验需要翻译，而不是归档

Figure 7 给出的结果非常重要：失败轨迹对 AWM 有害、对 ReasoningBank 有益。决定价值的不是数据标签，而是表示方式。

成功可以被抽象为 procedure，失败通常不能；失败更适合被抽象为 diagnosis、counterfactual 和 guardrail。不同结果需要不同的"经验语法"。

4. 下一代 Agent Memory 应把内容、结构和控制器分开

一个更完整的系统可以由三层组成：

内容层：ReasoningBank 负责把轨迹转成推理策略；
结构层：MAGMA/A-MEM 一类机制组织粒度、类型和关联；
控制层：学习型 router 根据任务阶段、置信度与成本决定检索、组合、更新或遗忘。

这三层分别回答"记什么""怎么放""何时用"。把它们混在一个 prompt 中，很难长期维护，也很难定位错误。

十六、总结

ReasoningBank 没有发明更复杂的记忆数据库，而是把 Agent Memory 的焦点拉回到一个更根本的问题：一次执行之后，哪些内容才配被称为经验？

它从成功轨迹中提炼已验证策略，从失败轨迹中提炼反事实教训和防错规则，再通过 MaTTS 把并行探索或串行修正产生的多样经验聚合为未来可复用的记忆。WebArena、Mind2Web 和 SWE-Bench Verified 的结果表明，这种 reasoning memory 在不同模型、不同分布和开放动作空间中都比原始轨迹或固定 workflow 更稳定。

同时，论文也清楚暴露出下一步问题：简单 embedding 检索会受噪声影响，直接追加缺少冲突与遗忘机制，同源 Judge 可能产生系统性偏差，MaTTS 还必须面对真实成本。

一句话总结：

ReasoningBank 的核心贡献，是把 Agent 的成功、失败与测试时探索统一编译成可迁移的推理记忆，让测试阶段的额外计算不只解决当前任务，还能积累成未来任务的持续能力。