ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory

论文阅读：ReasoningBank——用推理记忆让 LLM Agent 在测试时持续自我进化

论文标题：ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory
作者：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
发表位置：ICLR 2026
arXiv 编号：2509.25140
arXiv：https://arxiv.org/abs/2509.25140
PDF：https://arxiv.org/pdf/2509.25140
代码：https://github.com/google-research/reasoning-bank
主题：LLM Agent、Memory、Test-Time Learning、Test-Time Scaling、自我进化
核心问题：Agent 能否不修改模型参数，而是在持续执行任务的过程中，把成功和失败经历提炼成可复用的推理策略，并进一步让更多 test-time exploration 真正转化成长期能力提升？

1. 问题：Agent 做了很多任务，为什么还是没有真正“学会”？

LLM Agent 在 Web 浏览、软件工程、Computer Use 等任务中通常会持续与环境交互。

如果一个 Agent 长时间运行，它自然会积累大量历史轨迹。例如：

某次任务里，它发现必须进入完整订单历史，而不能只看 Recent Orders；
某次搜索中，它因为查询词太宽泛，翻了很多页仍然失败；
某次购物任务里，它发现应该先使用筛选器，而不是逐页浏览商品。

这些经验理论上都可以帮助之后的任务。

但传统 Agent 往往把每一个新任务当成一个独立问题：

Task 1 -> 执行 -> 结束
Task 2 -> 执行 -> 结束
Task 3 -> 执行 -> 结束
...

Task 1 中总结出来的经验，并不会自然变成 Task 2 的能力。

因此 Agent 会反复：

重新探索已经探索过的路径；
重复过去犯过的错误；
丢失已经得到的策略性知识。

论文希望构造的则是：

Task 1
  ↓
Experience
  ↓
抽象可复用策略
  ↓
Memory
  ↓
Task 2
  ↓
新的 Experience
  ↓
继续更新 Memory
  ↓
Task 3
...

也就是说，随着 Agent 执行越来越多任务，外部 Memory 也越来越成熟。

论文把这种测试阶段持续利用历史经验提升后续任务表现的设定称为 test-time learning（测试时学习）。

需要注意的是：

ReasoningBank 并没有通过这些经历继续训练 LLM 参数。

它的“学习”和“self-evolving”主要发生在 Memory 状态上，而不是模型权重上。

2. 为什么直接保存历史轨迹还不够？

一种最直接的 Memory 方法是：

做完一个任务以后，把完整 trajectory 保存下来，以后遇到类似问题再检索。

论文以 Synapse 作为这类 trajectory-based memory（轨迹型记忆）的代表。

但完整轨迹存在一个明显问题：信息太低层、太长，而且带有大量任务特有的执行细节。

例如，一段历史轨迹可能是：

<think>
我现在进入了 My Account 页面。
用户想知道自己的第一次购买日期。
Recent Orders 只显示最近订单，因此需要查看完整订单历史。
</think>

<action>
click('1530')
</action>

<think>
我现在位于 My Orders 页面……
</think>

真正值得迁移到未来任务的知识其实不是：

click('1530')

因为换一个网页以后，元素 ID 很可能完全不同。

真正有价值的是更抽象的经验：

如果用户询问最早、第一次等历史信息，
不要依赖仅展示最近记录的摘要页面，
应该寻找完整历史、分页或 View All 等入口。

ReasoningBank 的核心思想因此是：

不要把过去的 trajectory 本身作为最终 Memory，而是从 trajectory 中提炼 transferable reasoning strategy（可迁移推理策略）。

这也是论文标题中 Reasoning Memory 的含义。

3. ReasoningBank

3.1 Memory 的基本形式

ReasoningBank 中的一个 Memory Item 包含三个字段：

字段	作用
Title	用简短标题概括这个策略
Description	一句话说明这条 Memory 的用途
Content	保存具体推理步骤、决策依据或操作经验

例如一条 Memory 大致可能表达：

Title:
优先寻找用户账户中的完整历史页面

Description:
当任务询问历史个人数据时，不要只依赖摘要区域。

Content:
如果当前页面只展示 Recent Orders 等局部记录，
应该进一步寻找 View All、完整历史或分页入口，
避免把最近记录误认为最早记录。

重点并不是这个具体表述，而是 Memory Item 的粒度：

它位于“完整 trajectory”和“非常抽象的自然语言原则”之间。

它保留了足够具体的操作意义，同时试图去除网站名称、元素 ID、具体 query 等无法迁移的细节。

3.2 ReasoningBank 的完整闭环

ReasoningBank 与 Agent 的交互由三个主要步骤组成：

Memory Retrieval
Memory Extraction
Memory Consolidation

整体流程如下。

【Figure 2。该图展示 ReasoningBank 的核心闭环：当前任务从 ReasoningBank 检索相关 Memory，引导 Agent 与环境交互；任务结束后由 LLM-as-a-Judge 判断成功或失败，再从 trajectory 中提取新的 reasoning memory，最后写回 ReasoningBank。】

可以把整个系统理解为：

             ┌──────────────────┐
             │  ReasoningBank   │
             └────────┬─────────┘
                      │
                Memory Retrieval
                      │
                      ↓
Query ─────────────→ Agent
                      │
                      ↓
                 Environment
                      │
                      ↓
                  Trajectory
                      │
                      ↓
                LLM-as-a-Judge
                      │
             Success / Failure
                      │
                      ↓
                Memory Extraction
                      │
                      ↓
              New Memory Items
                      │
                      ↓
             Memory Consolidation
                      │
                      └────→ ReasoningBank

于是 Memory 不再只是一个静态数据库，而是会随着任务流持续增长。

4. Step 1：Memory Retrieval

假设 Agent 当前收到一个新的 query：

Tell me the status of my latest order and when it will arrive.

ReasoningBank 首先需要找到历史中与它相关的经历。

论文采用的是一个非常简单的实现：

当前 Query
    ↓
Embedding
    ↓
与历史 Query 的 embedding 计算 cosine similarity
    ↓
Top-k experiences
    ↓
取出这些 experience 对应的 Memory Items

实现中使用：

gemini-embedding-001

生成 Query embedding。

默认：

top-k = 1

也就是说，找到最相似的一条历史 experience，再把这条 experience 对应的 Memory Items 提供给 Agent。

这些 Memory 会被直接拼进 Agent 的 system instruction。

论文使用的提示思想大致是：

下面是过去与环境交互时积累的一些 Memory Items。

它们可能对当前任务有帮助。

每一步行动之前，
先判断这些 Memory 是否与当前情况相关，
然后再决定是否使用。

因此 Memory 并不是强制执行规则，而是给 Agent 增加额外的 reasoning hints（推理提示）。

5. Step 2：Memory Extraction

任务完成以后，ReasoningBank 需要回答另一个问题：

这条 trajectory 里面，到底有什么值得记住？

这是论文真正重点研究的部分。

作者首先通过一个 LLM-as-a-Judge 判断 trajectory：

Success
或者
Failure

Judge 的输入包括：

用户 Query；
Agent trajectory；
网站最终状态；
Agent 最终回答。

然后输出一个二元判断。

论文实现中 Judge 使用与 Agent 相同的 backbone LLM，并把 temperature 设为：

temperature = 0

以得到比较稳定的判断。

这里非常重要的一点是：

测试过程中并不存在 ground-truth feedback。

因此 ReasoningBank 不能在每个任务之后直接读取 benchmark 的正确答案来构造 Memory。

它需要利用 Agent 自己能够获得的信息，通过 LLM-as-a-Judge 构造一个 proxy correctness signal（代理正确性信号）。

6. 成功轨迹和失败轨迹分别怎么学习？

这是 ReasoningBank 与许多历史 Experience Memory 方法的重要区别。

6.1 从成功轨迹学习

如果 Judge 判断：

Success

Memory Extractor 会分析：

为什么这条 trajectory 成功？

然后提炼出可迁移策略。

作者要求 Memory Extractor：

最多提取 3 个 Memory Item；
不要生成重复或高度重叠的 Memory；
不要记录具体网站、具体 Query、具体字符串；
尽量提炼能够用于未来相似任务的策略。

也就是：

Successful Trajectory
        ↓
分析为什么成功
        ↓
提取成功策略
        ↓
Memory Items

例如：

成功原因：
Agent 没有停留在 Recent Orders，
而是继续进入完整订单历史并检查分页。

↓

Memory：
处理“第一次”“最早”等历史查询时，
必须确认已经覆盖完整历史，而不能只检查默认展示的最近记录。

6.2 从失败轨迹学习

ReasoningBank 不会简单丢掉失败 trajectory。

如果 Judge 判断：

Failure

Memory Extractor 会反过来分析：

为什么失败？

然后提炼：

pitfall（陷阱）；
failure cause（失败原因）；
preventive strategy（避免再次失败的策略）。

例如论文中的案例中，一个 Agent 在寻找 Sony 蓝牙耳机时不断翻页。

失败的原因并不只是：

最终没有得到答案。

而是更具体的：

搜索 Query 不够精确
    ↓
返回大量无关商品
    ↓
Agent 开始不断翻页
    ↓
消耗大量 interaction budget
    ↓
任务失败

从中可以形成：

- 优化 Search Query；
- 优先使用 Filter；
- 如果页面允许调整每页商品数量，应优先使用；
- 避免无目的地连续翻页。

于是：

Failed Trajectory
       ↓
诊断失败原因
       ↓
提取防错策略
       ↓
Memory Items

失败 experience 从“没用的数据”变成了 negative / counterfactual signal（负向或反事实信号）。

这也是论文后续实验重点验证的设计。

7. Memory Consolidation：作者反而故意做得很简单

通常 Agent Memory 论文还会研究：

Merge；
Deduplication；
Forgetting；
Memory Update；
Memory Pruning；
Hierarchical Memory。

ReasoningBank 在这里反而故意没有做复杂设计。

任务结束以后：

New Memory Items
      ↓
直接 Append
      ↓
ReasoningBank

也就是简单增加进去。

没有额外：

合并；
删除；
遗忘；
层次化整理。

作者这样设计是为了尽量隔离变量：

如果同时设计一个复杂 Retrieval、复杂 Consolidation 和复杂 Memory Extraction，就很难确定最终提升到底来自哪里。

因此论文把主要变量集中在：

Memory 中究竟保存什么内容。

实际存储采用 JSON。

每一条 Experience 保存：

Query
Original Trajectory
Memory Items

Memory Item 则遵循：

{
    title,
    description,
    content
}

Query embedding 单独预计算并保存，用于之后的相似度检索。

8. 所以 ReasoningBank 与 trajectory / workflow memory 的区别是什么？

论文主要比较三类系统。

方法	保存内容	核心思想
No Memory	无	每个任务独立执行
Synapse	历史 trajectory	直接复用历史交互轨迹
AWM	Workflow	从成功轨迹中抽象可复用工作流
ReasoningBank	Reasoning Strategy	从成功与失败经历中提炼推理策略与操作经验

ReasoningBank 关注的不是简单的：

以前我是怎么操作的？

而是：

为什么以前这样操作有效？

为什么那一次失败？

以后遇到类似问题应该采用什么策略？

论文还特意控制了 baseline：

不同方法使用相同的 Retrieval 和 Consolidation，主要差异集中在 Memory Extraction。

这样可以更直接地研究 memory formulation / memory content 的作用。

9. 从 ReasoningBank 进一步走向 MaTTS

ReasoningBank 建立以后，作者提出了第二个问题：

如果更多 Experience 能让 Memory 变得更好，那么能不能在一个任务上主动产生更多 Experience？

这就连接到了 Test-Time Scaling，TTS（测试时扩展）。

传统 Test-Time Scaling 可以简单理解为：

同一个问题
   ↓
投入更多 inference compute
   ↓
生成更多 solution / trajectory
   ↓
从里面选择更好的结果

例如：

Best-of-N

但传统 TTS 通常关注的是：

当前这一个任务能不能因为生成更多次而做得更好？

ReasoningBank 则把问题进一步改成：

这些额外生成的 trajectories，能不能同时成为未来任务的学习材料？

于是作者提出：

MaTTS：Memory-aware Test-Time Scaling

即：

让 Test-Time Scaling 不仅产生更多答案，而且产生更好的 Memory。

10. 为什么普通 TTS + Memory 还不够？

最简单的方法当然是：

同一个 Query
   ↓
生成 N 条 trajectory

Trajectory 1 -> Memory 1
Trajectory 2 -> Memory 2
Trajectory 3 -> Memory 3
...

论文把它称为近似的 Vanilla TTS。

问题是：

这些 trajectory 明明是在解决同一个问题，却被彼此独立地处理了。

这样浪费了很重要的信息：

Trajectory A 成功了
Trajectory B 失败了
Trajectory C 虽然成功但绕了很多步骤

如果把它们放在一起比较，就能得到比单独分析某一条 trajectory 更强的学习信号。

这就是 MaTTS 的出发点。

11. MaTTS 的两种形式

论文设计了两种 Memory-aware Scaling：

Parallel Scaling
Sequential Scaling

【Figure 3。该图对比 Vanilla TTS、MaTTS Parallel Scaling 和 MaTTS Sequential Scaling。阅读重点是 Vanilla TTS 将多条 trajectory 分别提取成 Memory，而 Parallel MaTTS 会先进行跨 trajectory self-contrast；Sequential MaTTS 则通过多轮 self-refinement 将中间修正过程也转化为 Memory。】

12. Parallel MaTTS：同一个任务多做几次，然后互相对照

Parallel Scaling 的流程是：

             Query
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
Trajectory 1 Trajectory 2 Trajectory 3
     │         │         │
     └─────────┼─────────┘
               ↓
          Self-Contrast
               ↓
        Better Memory

Agent 在同一个 Query 上产生多条 trajectory。

但是不同于独立提取 Memory，MaTTS 会把这些 trajectories 一起比较。

例如：

Trajectory A:
成功，而且先用了 Search

Trajectory B:
失败，因为连续翻页

Trajectory C:
成功，但步骤很多

模型可以由此发现：

Search / Filter 可能是稳定有效策略

连续翻页可能是失败模式

某些成功路径虽然正确，但是不够高效

论文把这个过程称为：

self-contrast（自对比）

它要求模型关注：

哪些策略持续带来成功；
哪些行为出现在失败轨迹中；
哪些策略能够跨页面、跨具体 Query 泛化；
哪些操作只是偶然成功。

相比：

1 trajectory -> 1 memory

Parallel MaTTS 变成：

N trajectories
      ↓
Cross-Trajectory Comparison
      ↓
Contrastive Signal
      ↓
Generalizable Memory

并且 parallel self-contrast 最多从多条 trajectory 合计提取 5 个 Memory Item。

13. Sequential MaTTS：不是重新做，而是不断检查和修正

另一种方案是 Sequential Scaling。

它不是从头独立运行 N 次，而是在一条 trajectory 上持续：

执行
 ↓
检查
 ↓
修正
 ↓
再检查
 ↓
再修正

也就是 self-refinement（自我改进）。

例如：

第一次：
我认为答案是 X。

↓

重新检查：
这个页面可能只是 Recent Orders。

↓

修正：
需要进入完整订单历史。

↓

再次检查：
还存在分页，需要继续检查。

↓

最终答案

传统方法可能只保存最终结果。

MaTTS 则认为：

中间修正过程本身也是很有价值的 Experience。

因为诸如：

“我刚才为什么错？”

“哪里需要重新检查？”

“当前信息是否真的足够？”

这些信息可能不会出现在最终答案中，却非常适合形成推理型 Memory。

因此 Sequential MaTTS 会把 intermediate notes（中间反思记录）也作为 Memory Extraction 的信号。

14. Scaling Factor k

论文统一使用 k 表示 test-time scaling 的规模。

对于 Parallel Scaling：

k = trajectory 数量

例如：

k = 5

表示同一个任务独立生成 5 条 trajectory。

对于 Sequential Scaling：

k = refinement 次数

因此两种 Scaling 增加计算量的方式不同：

Parallel:
增加搜索广度

Sequential:
增加单条 trajectory 的修正深度

15. Memory 和 Test-Time Scaling 为什么会形成正反馈？

这实际上是论文第二个核心观点。

作者认为 Memory 与 TTS 存在两个方向的作用。

15.1 更好的 Memory -> 更有效的 Scaling

如果完全没有 Memory：

多生成几条 trajectory

虽然增加了 sampling 数量，但是这些 trajectory 仍然可能反复探索错误区域。

而有了 ReasoningBank：

Memory
  ↓
告诉 Agent 哪些方向值得探索
  ↓
生成的 N 条 trajectory 整体质量更高

因此相同的 inference compute 能产生更有价值的探索。

15.2 更多 Scaling -> 更好的 Memory

反过来：

同一个任务产生更多 trajectory

意味着 Memory Extraction 得到了：

成功路径
失败路径
不同搜索策略
不同错误模式
不同修正过程

它们构成了天然的 contrastive signal。

于是：

更多、更丰富的 trajectories
        ↓
更好的 Memory Extraction
        ↓
更高质量 Memory

最终形成：

Better Memory
      ↓
Better Exploration
      ↓
More Diverse Experience
      ↓
Better Memory
      ↓
...

这就是论文所谓：

Memory 与 Test-Time Scaling 的双向协同。

16. 实验设置

论文主要在三个 benchmark 上进行实验。

Benchmark	类型	主要测试内容
WebArena	Web Agent	真实风格网站中的交互与导航
Mind2Web	Web Agent	跨任务、跨网站、跨领域泛化
SWE-Bench-Verified	Software Engineering Agent	Repository-level issue resolving

WebArena 中使用 BrowserGym。

SWE-Bench-Verified 使用类似 mini-SWE-Agent 的 Bash-Only 设置。

主要 backbone 包括：

Gemini-2.5-Flash
Gemini-2.5-Pro
Claude-3.7-Sonnet

另外作者还在：

Gemma-3-12B-Instruct

上进行了额外实验。

Web Agent 采用 ReAct 风格运行。

WebArena 每个 Query 最大交互步数为：

30 steps

主要评价两个方向：

Effectiveness:
Success Rate

Efficiency:
Average Steps

Mind2Web 还包括：

Element Accuracy（EA）
Action F1（AF1）
Step Success Rate（SSR）
Task Success Rate（SR）

17. WebArena：ReasoningBank 的整体结果

先只看整个 WebArena 的 Overall 结果。

Backbone	方法	Success Rate ↑	Avg. Steps ↓
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

两个现象比较明确。

第一，ReasoningBank 相比 No Memory 和两种 Memory baseline 都有稳定提升。

第二，加入 MaTTS 后性能还能继续提高。

也就是说：

No Memory
   ↓
普通 Experience Memory
   ↓
ReasoningBank
   ↓
ReasoningBank + MaTTS

整体表现逐步上升。

18. ReasoningBank 不只是提高成功率，还减少步骤

作者还特别关注 Efficiency。

因为一种 Memory 系统可能：

成功率提高

但是为了使用 Memory，又增加大量交互和推理步骤。

ReasoningBank 的实验却显示，它通常能够减少环境交互步骤。

论文报告 WebArena 中，与 No Memory 相比：

最多减少约 1.4 个平均交互步骤

与其他 Memory baseline 相比最多减少：

约 1.6 steps

在 SWE-Bench-Verified 上也观察到了类似趋势。

论文对这一现象的解释是：

Memory 提供的不是单纯额外信息，而是减少无效探索的 reasoning hints。

例如不知道商品筛选入口在哪里的 Agent 可能需要不断：

scroll
click
back
scroll
...

而历史 Memory 已经告诉它：

先进入特定 category
再使用 filter

它就可以明显缩短搜索路径。

19. SWE-Bench-Verified

软件工程任务同样出现提升。

Backbone	方法	Resolve Rate ↑	Avg. Steps ↓
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

这说明 ReasoningBank 的设计并不只适用于固定 Web UI 操作。

在 Bash command、代码修改和 repository-level issue solving 中，从历史经验中提取策略同样能够产生收益。

20. Mind2Web：更重要的是泛化能力

Mind2Web 进一步考察：

Cross-Task
Cross-Website
Cross-Domain

其中 Cross-Domain 对 Memory 的迁移要求最高。

以 Gemini-2.5-Flash 为例：

方法	Cross-Task SR	Cross-Website SR	Cross-Domain SR
No Memory	3.3	1.7	1.0
Synapse	3.5	1.9	1.1
AWM	3.5	2.1	0.7
ReasoningBank	4.8	2.3	1.6

以 Gemini-2.5-Pro 为例：

方法	Cross-Task SR	Cross-Website SR	Cross-Domain SR
No Memory	3.5	3.4	1.4
Synapse	3.6	3.2	1.5
AWM	3.7	2.3	1.2
ReasoningBank	5.1	3.8	1.7

这里也能看到一个现实情况：

Mind2Web 的 task-level SR 绝对值依然很低。

因此论文展示的是 相对基线的持续提升，并不意味着这些 Agent 已经把跨域 Web Agent 问题解决得很好。

21. MaTTS：增加 test-time compute 是否真的有效？

作者在 WebArena-Shopping 上重点研究 scaling factor k。

使用：

Gemini-2.5-Flash

比较：

MaTTS w/o Memory
MaTTS w/o Aggregation
MaTTS

其中：

MaTTS w/o Memory

表示只有 TTS，没有 Memory。

MaTTS w/o Aggregation

相当于 Vanilla TTS：

多条 trajectory 分别生成 Memory，但不进行 self-contrast / self-refinement aggregation。

完整 MaTTS 则会把多个探索结果作为一个整体来提炼 Memory。

22. Parallel Scaling 的结果

完整 MaTTS 从：

k = 1:
49.7

增长到：

k = 5:
55.1

而没有 Memory 的 Parallel Scaling 只在：

39.0 ~ 42.2

之间变化。

在 k = 5 时：

Vanilla TTS: 52.4
MaTTS:       55.1

说明提升并不只是：

“多采样几次自然就变好了”。

跨 trajectory 的聚合和 Memory Extraction 本身带来了额外收益。

23. Sequential Scaling 的结果

Sequential MaTTS 从：

49.7

提高到：

54.5

但论文发现 Sequential Scaling 存在比较明显的 saturation（饱和）。

原因是：

第一次检查：
发现错误

第二次检查：
修正错误

第三、第四次继续检查：
可能已经没有多少新信息

因此随着 k 增大：

self-refinement 能够继续提供的新信息越来越有限。

Parallel Scaling 则可以持续产生不同 exploration path。

论文中 k = 5 时：

Parallel:   55.1
Sequential: 54.5

作者因此观察到：

小规模 scaling 时，Sequential Refinement 很有用；
scale 较大以后，Parallel Exploration 提供的 diversity 更有价值。

24. Memory × Scaling 的双向协同实验

论文进一步专门验证：

Memory 和 TTS 到底是不是相互促进，而不是两个独立模块简单叠加。

在 WebArena-Shopping、Parallel k = 5 的实验中：

Memory	No Scaling	Best-of-5
No Memory	39.0	42.2
Synapse	40.6	44.4
AWM	44.4	47.6
ReasoningBank	49.7	55.1

Memory 越好，Best-of-5 Scaling 带来的最终效果也越强。

也就是说：

弱 Memory
   ↓
即使生成很多 trajectory
   ↓
仍然容易在低质量区域探索

强 Memory
   ↓
把探索引导到更有希望的位置
   ↓
Scaling 更有效

这是：

Memory -> Scaling

的方向。

25. Scaling 也会反过来改善 Memory

作者随后不看 Best-of-5，而看 Pass@1。

原因是，如果只看 Best-of-N：

多采样 N 次

本来就可能因为“撞中一个正确答案”而提高。

Pass@1 更适合观察：

Scaling 以后产生的 Memory，是否真的让后续单次 rollout 变好了？

实验中：

ReasoningBank:
49.7 -> 53.0

而较弱的 Memory mechanism 提升很有限：

Synapse:
40.6 -> 41.2

AWM:
44.4 -> 45.5

作者据此认为：

如果 Memory 本身不能有效利用多条 trajectory 之间的 contrastive signal，单纯增加 rollout 数量并不会自然产生高质量学习。

因此第二个方向是：

Scaling
   ↓
更多 Diverse Experience
   ↓
更丰富的 Contrastive Signal
   ↓
Better Memory

两者组合成为一个闭环。

26. 消融：失败轨迹到底有没有用？

这是 ReasoningBank 最关键的消融实验之一。

在 WebArena-Shopping + Gemini-2.5-Flash 上：

方法	Success Only	Success + Failure
Synapse	40.6	41.7
AWM	44.4	42.2
ReasoningBank	46.5	49.7

这里非常有意思。

直接把失败 trajectory 加入传统 Memory，不一定有效。

例如 AWM：

44.4 -> 42.2

反而下降。

原因在于失败 trajectory 本身就是带噪的。

如果系统仅仅“记住失败经历”，未来 Agent 也可能学到错误操作。

ReasoningBank 做的是：

Failure
   ↓
Reflection
   ↓
诊断为什么失败
   ↓
只保存避免失败的 Strategy

因此真正有效的不是：

“保存失败”。

而是：

把失败转化成可执行的防错经验。

27. LLM-as-a-Judge 判断错了怎么办？

ReasoningBank 的另一个明显风险来自：

LLM-as-a-Judge

因为 Memory Extraction 需要首先判断：

Success / Failure

如果 Judge 判断错了：

错误 trajectory
   ↓
被当作 Success
   ↓
提炼成错误策略

理论上可能污染 Memory。

作者因此专门测量了 Judge。

在 WebArena-Shopping + Gemini-2.5-Flash 上，原始 Judge 与 ground truth 对比后的判断准确率为：

72.7%

随后作者人工模拟：

100%
90%
80%
70%
...
50%

不同 Judge accuracy。

模拟方法例如：

90% Judge:
90% 使用 Ground Truth Label
10% 将 Label 翻转

结果显示在大约：

70% ~ 90%

的合理准确率范围中，ReasoningBank 的 Success Rate 整体比较稳定。

当然：

100% ground-truth verifier

仍然得到最好的结果。

因此论文认为 ReasoningBank 对一定程度的 Judge noise 具有鲁棒性，但这并不意味着 Judge 完全不重要。

28. Memory 是不是越多越好？

不是。

论文专门改变 Retrieval 时取出的 historical experiences 数量。

WebArena-Shopping 上：

Retrieved Experiences	Success Rate
0	39.0
1	49.7
2	46.0
3	45.5
4	44.4

最明显的现象是：

0 -> 1:
39.0 -> 49.7

加入相关 Memory 带来巨大提升。

但继续增加：

1 -> 2 -> 3 -> 4

性能反而下降。

论文给出的解释是：

太多 experiences 会带入冲突或噪声。

因此 Memory 系统不能简单追求：

More Memory = Better

真正重要的是：

Relevant Memory
+
High-Quality Memory

这也是作者默认采用：

top-k = 1

的原因。

29. ReasoningBank 中出现的“策略演化”

作者还观察了 Memory 随任务不断积累之后产生的变化。

论文给出了一个关于：

User-Specific Information Navigation

的案例。

最初的 Memory 可能只是很具体的 procedure：

寻找导航链接
检查下一页
点击 View All

随着更多 Experience 出现，Memory 开始包含：

操作前重新确认 element identifier

进一步则变成：

优先利用搜索和 Filter
确认结果完整性

最终进一步抽象成：

不断将当前页面信息与任务约束进行交叉检查；
如果信息与预期不一致，
重新考虑 Search、Filter 或其他页面入口。

也就是大致出现：

Procedural Strategy
        ↓
Atomic Self-Reflection
        ↓
Adaptive Check
        ↓
Generalized Reasoning Strategy

作者将这种现象描述为一种类似 RL learning dynamics 的策略演化。

但需要注意：

这里并没有真正执行强化学习，也没有利用这些轨迹更新 LLM 权重。

所谓演化发生在不断积累和使用的 Reasoning Memory 中。

30. 一个直观案例：第一次购买是什么时候？

论文给出了一个很容易理解 ReasoningBank 作用的例子。

任务是：

What is the date when I made my first purchase on this site?

没有 Memory 的 Agent：

My Account
   ↓
Recent Orders
   ↓
看到日期
   ↓
直接回答

最终误把 Recent Order 当成 First Order。

ReasoningBank Agent 则从 Memory 中知道：

如果问题涉及 first / earliest 等历史信息，不能只检查最近记录，需要访问完整历史。

于是：

My Account
   ↓
My Orders
   ↓
完整 Order History
   ↓
Next Page
   ↓
找到最早订单

Baseline 最终回答：

3/11/23

ReasoningBank 找到：

March 2, 2022

这个案例非常直接地体现了 ReasoningBank 保存的并不是某个订单答案，而是：

如何验证“最早记录”这种任务的 reasoning strategy。

31. 另一个案例：29 步缩短到 10 步

论文还展示了一个购物任务：

找到 Men's shoe 类别中至少有 5 个评论、评分最高且价格最低的商品。

无 Memory Agent 因为找不到正确筛选入口：

不断导航
不断 Scroll
不断尝试 Filter

最终用了：

29 Steps

ReasoningBank 中已经存在有关 category filtering 的 reasoning hint。

Agent 可以更直接地：

进入正确 category
   ↓
Filter
   ↓
Price / Rating / Review Constraint
   ↓
完成任务

最后只使用：

10 Steps

这个案例对应论文对 Efficiency 的主张：

Memory 不只是帮助 Agent 做对，还能让 Agent 少走弯路。

32. 推理成本

增加 Memory Extraction 和 LLM-as-a-Judge 显然也需要额外模型调用。

作者因此统计了平均每条 trajectory 的 token consumption。

方法	Action Generation	LLM-as-a-Judge	Memory Extraction	Total
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

虽然 ReasoningBank 新增了：

Judge
+
Memory Extraction

两个过程，但由于 Agent 本身减少了无效探索，Action Generation 的 token 消耗反而降低。

作者报告：

相对 No Memory：
总 token consumption 约增加 4.3%

同时实验性能获得明显提升。

因此作者认为 ReasoningBank 的额外推理开销相对可控。

33. 小模型上是否仍然有效？

论文另外使用：

Gemma-3-12B-Instruct

测试 WebArena-Shopping。

结果如下：

方法	Success Rate	Average Steps
No Memory	17.1	13.7
Synapse	16.0	14.0
AWM	21.4	12.5
ReasoningBank	24.1	11.8

说明 ReasoningBank 的收益并不仅出现在 Gemini-2.5-Pro 这类较强 proprietary model 上。

在较小的 open-source model 上同样观察到了：

Success Rate ↑
Average Steps ↓

34. 论文真正研究的重点：Memory Content，而不是 Memory Architecture

ReasoningBank 很容易被理解成又一个复杂 Agent Memory 系统，但作者其实有意避免这种设计。

论文没有重点研究：

Memory Hierarchy
Memory Graph
Memory Forgetting
Memory Merge
Memory Routing
Memory Compression

它真正研究的是：

Agent 应该从 Experience 中记住什么？

因此整个系统故意使用：

简单 Embedding Retrieval
+
简单 Append Consolidation

从而把实验变量尽量集中在：

Raw Trajectory

vs.

Workflow

vs.

Reasoning Strategy

以及：

Success Only

vs.

Success + Failure Reflection

上。

这也是理解这篇论文最关键的定位之一。

35. Future Directions

论文在附录中明确提出了两个主要未来方向。

35.1 Modular and Compositional Memory

目前一条 Experience 可以提取多个 Memory Item。

但这些 Memory Item 基本仍然是独立被使用的。

作者提出未来可以把 Memory 进一步模块化，例如：

Planning Memory
Tool-Use Memory
Operational Memory
User-Centric Memory

检索时不再只是：

找最像当前 Query 的 Experience

而可以：

检索 Planning Strategy
+
检索 Tool-Use Strategy
+
检索 User-Specific Strategy
        ↓
组合
        ↓
解决当前任务

这会使 Memory 从：

Similarity-based Reuse

进一步发展为：

Compositional Reuse

35.2 Advanced Memory Architectures

当前 ReasoningBank 的 Memory stack 很简单。

作者认为未来可以结合：

Episodic Memory
Working Memory
Long-Term Memory

形成分层 Memory。

还可以加入：

Decay
Refresh
Adaptive Retrieval
Hierarchical Consolidation
Learning-based Router

当前 embedding similarity retrieval 也可以换成更复杂的 reasoning-intensive controller。

例如根据：

Uncertainty
Recency
Cost
Task Decomposition

决定应该从哪个 Memory tier 检索什么内容。

因此 ReasoningBank 更像是：

一种关于 memory content / experience learning 的设计思想，可以与更复杂的 Memory Architecture 组合。

36. 论文明确指出的局限性

36.1 没有系统比较复杂 Memory Architecture

ReasoningBank 主要研究：

what should be stored

而不是：

how memory should be structurally organized

因此并没有全面比较：

Episodic Memory；
Hierarchical Memory；
更复杂长期 Memory 系统。

这些属于与本文互补的研究方向。

36.2 Retrieval 和 Consolidation 都非常简单

当前 Retrieval：

Embedding Similarity
+
Top-k

当前 Consolidation：

Append

没有：

Adaptive Retrieval
Hierarchical Retrieval
Merge
Pruning
Forgetting

因此随着长期运行、Memory 数量持续增长以后，怎样管理越来越庞大的 Memory Bank，并不是本文解决的问题。

36.3 依赖 LLM-as-a-Judge

ReasoningBank 的成功 / 失败判断依赖：

LLM-as-a-Judge

Judge 一旦出错，就可能影响 Memory Extraction。

特别是：

任务本身有歧义；
最终状态难以判断；
Judge 模型本身出现 reasoning error；

都可能形成错误 label。

论文的噪声实验说明系统在一定误差范围内具有鲁棒性，但作者仍然提出未来可以加入：

Stronger Verifier
Human-in-the-loop
Ensemble Judgment

提高 Memory Induction 的可靠性。

37. 总结

ReasoningBank 研究的是一个很直接的问题：

如果 Agent 每天都在做任务，它为什么不能把以前做任务的经验真正变成以后可复用的能力？

论文认为，保存完整 trajectory 并不是最有效的方式。

真正应该保留的是：

为什么成功？
为什么失败？
以后应该采用什么策略？
以后应该避免什么错误？

因此 ReasoningBank 将 Experience 转换为结构化的 Reasoning Memory：

Experience
    ↓
Success / Failure Judge
    ↓
Reflection
    ↓
Generalizable Strategy
    ↓
ReasoningBank

Agent 在之后的任务中重新检索这些策略：

New Query
    ↓
Retrieve Relevant Reasoning Memory
    ↓
Agent Interaction
    ↓
New Experience
    ↓
Update ReasoningBank

在此基础上，作者进一步提出 MaTTS：

更多 Test-Time Compute
        ↓
更多 Diverse Trajectories
        ↓
Self-Contrast / Self-Refinement
        ↓
Better Memory
        ↓
Better Future Exploration

于是 Memory 与 Test-Time Scaling 形成：

Better Memory
    ↓
Better Scaling
    ↓
Better Experience
    ↓
Better Memory

的正反馈循环。

从方法结构上看，这篇论文并没有依靠复杂的 Memory Graph、复杂 Retrieval 或参数训练，而是把研究重点放在两个问题上：

1. 从历史 Experience 中，究竟应该提取什么作为 Memory？

2. 如何让更多 test-time experience 不只是提高当前任务的采样成功率，
   而是真正转化成之后任务可以复用的经验？

论文给出的答案分别是：

ReasoningBank:
将成功和失败 trajectory 提炼成 transferable reasoning strategy。

MaTTS:
利用 parallel self-contrast 和 sequential self-refinement，
把 test-time scaling 产生的额外 Experience 转化成更高质量 Memory。

因此这篇论文所描述的 self-evolving，并不是让模型在测试阶段不断更新参数，而是：

LLM 参数保持不变
        +
外部 Reasoning Memory 持续更新
        +
过去 Experience 持续影响未来决策
        =
Test-Time Self-Evolving Agent

参考

Siru Ouyang et al. ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory. ICLR 2026.
https://arxiv.org/abs/2509.25140
Paper PDF
https://arxiv.org/pdf/2509.25140
Official Code: Google Research ReasoningBank
https://github.com/google-research/reasoning-bank

posted @ 2026-09-17 21:28 YourF4u1t 阅读(18) 评论(0) 收藏举报

刷新页面返回顶部