Agent Memory Distillation: Empowering Small LLM Agents with Hierarchical Teacher Memory

Agent Memory Distillation：用层次化教师记忆增强小模型 Agent

论文：Agent Memory Distillation: Empowering Small LLM Agents with Hierarchical Teacher Memory
作者：Taeil Kim, Kangsan Kim, Sung Ju Hwang
机构：KAIST、DeepAuto.ai
时间：2026 年 8 月
关键词：LLM Agent、Agent Memory、Knowledge Distillation、Tool Use、Training-Free

1. 一句话总结

这篇论文研究的是一个很直接的问题：

强模型 Agent 已经积累了大量成功经验，能不能不训练小模型，而是直接把这些经验“蒸馏”成外部记忆，让小模型拿来用？

作者发现，直接把强模型的记忆塞给小模型并不好用。原因并不是教师经验质量不够，而是强模型总结出来的经验往往过于抽象，小模型即使“看懂了大概意思”，也未必有能力把它真正执行出来。

因此作者提出 Agent Memory Distillation（AMD），把教师模型的成功轨迹拆成三个层次：

  1. Workflow Memory：告诉学生整个任务应该怎么做；
  2. Subtask Memory：告诉学生某一个具体子任务以前是怎么执行成功的；
  3. Function Memory：当某个工具调用出错时，直接告诉学生这个函数应该怎么调用。

也就是说，作者没有把教师经验简单总结成一句“经验”，而是按照：

任务规划 → 子任务执行 → 具体函数调用

三个粒度进行保存和使用。论文将其称为一种无需训练的 Agent Memory Distillation。

2. 这篇论文要解决什么问题？

近年来很多 Agent Memory 工作的基本逻辑都是：

Agent 做任务 → 保存历史轨迹 → 从成功/失败经历中提取经验 → 以后遇到类似任务再召回。

例如 Reflexion、ExpeL、AWM、ReasoningBank、MemP 等工作，本质上都在研究：

过去的经验怎样帮助 Agent 未来做得更好？

但是，这些方法通常有一个隐含条件：

Agent 自己首先得有能力产生一些比较好的经验。

对于 GPT-4、Gemini 这一类强模型来说，这个条件通常不是大问题。

但如果 Agent 背后的模型只有 4B、8B 呢？

问题就出现了。

小模型本身成功率比较低，因此它跑出来的大量历史轨迹可能都是：

  • 调错工具；
  • 漏掉步骤；
  • 参数错误；
  • 不知道下一步干什么；
  • 在错误操作中反复循环。

那么从这些失败轨迹里面建立 Memory，质量自然不会很高。

作者因此提出一个很自然的想法：

既然学生自己没有高质量经验，那为什么不直接让更强的教师模型替它积累经验？

也就是：

Teacher Agent 负责产生成功经验，Student Agent 负责继承这些经验。

这已经开始非常接近传统 Knowledge Distillation 的“教师—学生”结构，只不过这里传递的并不是模型权重或者输出概率，而是 Agent 的外部 Memory。

3. 直接把教师 Memory 给学生不就行了吗？

作者一开始也尝试了这种最简单的方法。

例如教师模型解决过一个播放音乐的任务，然后总结出一条经验：

播放音乐之前需要先登录。

这句话对一个强模型来说可能已经足够了。

因为强模型看到：

“先登录”

它自己就知道：

  • 应该找哪个登录 API；
  • 需要什么参数；
  • 用户名是什么格式；
  • 密码从哪里获取；
  • 怎么判断登录是否成功。

但一个小模型可能看到这句话以后只会：

好，我知道要登录。

然后下一步：

……可是怎么登录？

这就是论文强调的 Teacher–Student Capability Gap。

教师提供的是一个高层次策略，而学生缺少把高层策略转换成正确底层操作的能力。

所以：

高质量的教师经验 ≠ 学生能够有效使用的经验。

论文实验也发现，简单采用已有的 Memory 方法进行教师到学生的经验迁移，提升并不稳定，有些情况下甚至会让性能下降。作者认为，其中一个重要原因就是教师记忆的复杂度超过了小模型的理解和执行能力。

image

【Figure 1：AMD 的研究动机——Student Memory、直接 Teacher Memory Transfer 与层次化 AMD 的区别】

4. AMD 的核心思想：把教师经验拆成三个层次

作者最终的解决办法其实很好理解：

既然小模型无法仅靠一个高层经验自行补全所有细节，那么就把经验拆细。

AMD 从教师模型的成功轨迹中生成三种 Memory：

Memory 粒度 解决的问题
Workflow Memory 整个任务 “这个任务总体应该怎么做？”
Subtask Memory 子任务 “其中某一步以前具体是怎么做成功的？”
Function Memory 单个函数 “这个 API 到底应该怎么调用？”

可以把它理解成：

Workflow Memory
    ↓
告诉 Student：整件事情应该分几步完成

Subtask Memory
    ↓
告诉 Student：每一步具体应该怎么执行

Function Memory
    ↓
如果执行过程中某个 API 调用失败，
直接提供正确调用方法

这就是论文所谓的 Hierarchical Teacher Memory。
image

【Figure 2：AMD 的完整框架——教师生成 Workflow / Subtask / Function 三层 Memory，学生分别主动或被动调用】

5. Workflow Memory：告诉学生“整件事情怎么做”

Workflow Memory 是最上层的记忆。

它并不会保存教师完整的执行轨迹，而是把成功轨迹总结成一个高层任务流程。

其中包含：

  • 涉及哪些应用；
  • 需要调用哪些工具；
  • 有哪些前置条件；
  • 大致执行顺序；
  • 有哪些判断规则；
  • 怎样判断任务完成；
  • 有哪些常见错误需要避免。

同时，作者还会把具体运行时数据替换掉。

例如：

user@example.com

不会直接保存在通用 Workflow 中，而可能变成：

<EMAIL>

类似的还有：

<ID>
<FILE_PATH>

这样 Memory 保存的就不是：

“上次那个具体任务是怎么完成的。”

而是：

“这一类任务一般应该怎么完成。”

论文中每一条 Workflow Memory 可以简单理解成：

$$
m^{wf}_i=(q_i,ins_i)
$$

其中：

  • $q_i$：描述这个任务是什么；
  • $ins_i$：教师从成功轨迹里总结出的解决策略。

之后再把它编码成向量，供未来进行相似度检索。

6. Subtask Memory：这篇论文真正最关键的一层

如果只看到 Workflow Memory，其实和很多已有的 Agent Memory 方法区别还没有那么大。

AMD 最重要的设计之一实际上是 Subtask Memory。

作者认为：

Workflow 太抽象，而 Function 又太细，因此中间需要一个“子任务级”的经验层。

例如一个完整任务可能是：

统计这个月我一共通过 Venmo 支付了多少钱。

整个任务可能需要：

登录 Venmo
↓
获取交易记录
↓
处理分页
↓
筛选当前月份
↓
筛选自己发送出去的钱
↓
求和

Workflow Memory 只告诉模型：

先认证，然后获取交易并遍历分页，最后对符合条件的交易求和。

但小模型还是可能不知道：

“获取全部交易记录”这一步具体应该怎么调用 API？

因此 AMD 会进一步把教师的成功轨迹切成若干个语义完整的子任务片段。

例如：

[authenticate to Venmo]
    教师真实执行过的一组 Tool Calls
    + 对应 Observation

以及：

[sum transactions and complete]
    教师真实执行过的一组 Tool Calls
    + 对应 Observation

注意，这里保存的不只是一个自然语言总结。

Subtask Memory 里面会保留教师实际执行成功的：

Tool Call / Code + Observation

也就是说，它已经很像一个可以直接参考的“小型成功案例”。

论文实验表明，Subtask Memory 是三个 Memory 中贡献最大的部分。

以 Qwen3-4B 在 AppWorld 上为例：

  • Zero-shot：14.88%
  • Workflow：22.02%
  • Workflow + Subtask：47.02%
  • 完整 AMD：49.40%

也就是说，仅仅加入 Subtask Memory，就从 22.02% 提升到了 47.02%。

这个结果实际上非常能说明作者的核心观点：

对于小模型来说，“告诉它原则”远没有“给它一个具体成功做法”有效。

7. 当前任务的 Subtask 是怎么召回的？

这里还有一个比较重要的细节。

学生开始一个新任务之后，并不是直接拿整个任务去搜索所有 Subtask Memory。

AMD 会首先让学生模型自己把当前任务拆成若干个子任务。

最多拆成 6 个。

例如：

任务：
统计这个月我通过 Venmo 发出了多少钱。

Student 分解：

1. authenticate to Venmo
2. retrieve sent transactions
3. filter transactions by date
4. aggregate transaction amounts

然后分别使用：

authenticate to Venmo

和：

retrieve sent transactions

这些子任务描述去 Subtask Memory 中进行向量检索。

每个子任务默认只取 Top-1 最相似的历史经验。

最终召回出来的多个子任务经验会与 Workflow Memory 一起放进 System Prompt，然后学生才正式开始执行任务。

所以这里实际上形成了一个两阶段过程：

当前 Task
    ↓
Student 先进行任务分解
    ↓
得到多个 Subtask
    ↓
每个 Subtask 独立检索历史成功经验
    ↓
把这些具体经验交给 Student
    ↓
正式执行任务

8. Function Memory：出错了再查说明书

第三层是最细粒度的 Function Memory。

这一层记录的是：

某一个具体函数以前是怎样正确调用的。

例如：

venmo.show_transactions

Function Memory 中可能保存：

  • 函数名称；
  • 教师实际成功调用的例子；
  • 调用前后的上下文；
  • API 参数格式；
  • 返回值结构。

但作者并没有在任务开始的时候把所有 Function Memory 都塞进去。

原因也很直接：

太多了，而且绝大多数时候根本用不上。

因此 Function Memory 使用了一种被动触发式机制。

只有当 Student 调用某个函数发生错误时：

venmo.login(
    username="student",
    password="a1234"
)

→ Error

系统才会根据失败函数：

venmo.login

去 Function Memory 中寻找教师以前的正确调用案例，再把它附加到当前错误信息后面。

于是模型可能得到类似的信息：

venmo.login 的 username 必须是 email address

然后重新尝试。

因此三个 Memory 的触发时间其实并不相同：

Memory 使用时间
Workflow 任务开始前
Subtask 任务开始前
Function 工具调用失败之后

前两个属于 Proactive Injection，Function 属于 Reactive Injection。

9. 把整个 AMD 流程串起来

现在可以把整个框架完整串起来。

第一阶段：Teacher 跑任务

首先使用强 Teacher Agent 执行任务集合：

Task
 ↓
Teacher Agent
 ↓
Trajectory
 ↓
判断成功 / 失败

只有成功轨迹进入后续 Memory 构建。

第二阶段：从成功轨迹提取三层 Memory

对于同一条 Teacher Trajectory：

Teacher Successful Trajectory
        │
        ├── Workflow Memory
        │      整个任务的通用解决流程
        │
        ├── Subtask Memory
        │      把轨迹切成多个子任务成功片段
        │
        └── Function Memory
               提取具体函数调用案例

最终形成三个 Memory Bank：

$$
M=M^{wf}\cup M^{st}\cup M^{fn}
$$

第三阶段：Student 开始执行新任务

首先：

当前 Task
 ↓
检索 Workflow Memory
 ↓
Student 自己拆分 Subtask
 ↓
分别检索 Subtask Memory
 ↓
全部加入 System Prompt

然后 Student 开始正式调用工具。

第四阶段：执行过程中动态纠错

如果调用成功：

继续执行

如果出现函数错误：

Error
 ↓
识别出错 Function
 ↓
检索 Function Memory
 ↓
提供教师正确调用案例
 ↓
重新执行

直到：

任务完成

或者：

达到最大步数

这就是 AMD 的完整工作流程。

10. 实验设置

作者选择了三个 Tool-Use Agent Benchmark。

10.1 AppWorld

AppWorld 模拟大量现实应用，例如：

  • 邮件；
  • 支付；
  • 消息；
  • 日历等。

Agent 需要通过 Python API 完成多步骤任务。

论文使用 test_normal 中的 168 个任务。

10.2 BFCL V3

BFCL 主要测试模型的 Function Calling 能力。

不仅要求选对函数，还要求：

  • 参数正确；
  • 多轮调用顺序正确；
  • 最终状态正确。

论文使用 200 个 multi-turn base 任务。

10.3 ToolSandbox

这是一个带状态的多轮 Tool-Use 环境。

前面的工具调用会改变环境，从而影响后续步骤。

论文测试 129 个场景。

11. Teacher 和 Student

主要实验中的 Teacher 为：

GPT-5-mini

Student 则包含四个 4B～8B 模型：

  • Qwen3-4B
  • Qwen3-8B
  • Gemma4-E4B
  • Llama3.1-8B

Memory 的向量表示使用：

OpenAI text-embedding-3-small

三个 Memory 默认都采用：

$$
k=1
$$

也就是只召回最相似的一条经验。

12. 主实验：提升到底有多大？

结果非常明显。

四个 Student 相比 Zero-shot 的平均绝对准确率提升分别为：

  • AppWorld：+27.2 个百分点
  • BFCL V3：+11.2 个百分点
  • ToolSandbox：+3.4 个百分点

其中提升最大的情况之一是：

Qwen3-4B + AppWorld

Zero-shot：14.88%
AMD：49.40%

直接提升：

+34.52 个百分点。

在 BFCL V3 上：

Zero-shot：15.50%
AMD：38.50%

提升：

+23.00 个百分点。

相比之下，ReasoningBank、MemP、SASM 等已有 Memory 方法迁移到 Teacher→Student 场景后表现并不稳定，部分实验甚至低于 Zero-shot。

例如 Qwen3-4B 的 AppWorld：

Zero-shot       14.88
ReasoningBank   10.71
MemP            16.67
SASM            15.48
AMD             49.40

作者据此认为：

对小模型来说，关键并不是“有没有教师经验”，而是教师经验是否以学生能够理解和执行的形式组织起来。

13. 一个有意思的现象：学生甚至可以超过教师

GPT-5-mini 在 AppWorld 上的准确率为：

50.00%

但是使用 AMD 后：

Gemma4-E4B：54.17%
Qwen3-8B：51.79%

都超过了 Teacher。

在 BFCL V3 上也出现了类似现象。

作者因此强调：

Student 并不是简单地复制 Teacher 的原始轨迹，而是在利用教师提供的可迁移经验后，结合自身模型能力重新完成任务。

所以这里的“蒸馏”并不等于：

Teacher 做什么
↓
Student 原样照抄什么

而更接近：

Teacher 提供可复用经验
↓
Student 把经验应用到当前状态
↓
产生自己的执行轨迹

这也是为什么 Student 最终结果存在超过 Teacher 的可能。

14. AMD 不只是提高正确率，还减少了乱试

论文还统计了 Agent 完成任务所需要的交互步数。

例如 AppWorld 中的 Qwen3-4B：

Teacher：10.1 steps

Zero-shot Student：23.8 steps

AMD Student：14.9 steps

Zero-shot 小模型实际上会进行大量无效探索。

而得到教师 Memory 后，Agent 的执行路径明显更加接近教师。

因此作者认为 AMD 迁移的不只是：

“该做什么”。

还包含：

“怎样更高效地做”。

15. 消融实验：真正有用的是哪一层 Memory？

这是整篇论文非常重要的一组实验。

以 AppWorld 的 Qwen3-4B 为例：

方法 Accuracy
Zero-shot 14.88
Workflow 22.02
Workflow + Function 24.11
Workflow + Subtask 47.02
Workflow + Subtask + Function 49.40

可以明显看到：

Workflow 有用

14.88 → 22.02。

说明提前告诉小模型整体任务流程确实能够减少一部分探索。

Function 有用，但提升不算特别大

Workflow：

22.02

加入 Function：

24.11。

它更像一个兜底纠错模块。

Subtask 才是提升的核心

Workflow：

22.02

加入 Subtask：

47.02。

直接提升 25 个百分点。

这也是论文最值得注意的实验结论之一：

对于复杂长程 Agent Task，小模型真正缺少的往往不是一句高层“经验总结”，而是足够具体、可以直接参考的中间执行案例。

16. Teacher 越强越好吗？不一定

作者还专门换了不同 Teacher：

  • GPT-5.5
  • DeepSeek V4 Pro
  • GPT-5-mini
  • Qwen3-32B

结果出现了一个很有意思的现象。

对于 Qwen3-8B：

Teacher 越强
↓
通常 Student 效果也越好

例如：

GPT-5.5 Teacher Accuracy：91.08%
→ Qwen3-8B：58.93%

DeepSeek V4 Pro：81.55%
→ Qwen3-8B：57.14%

GPT-5-mini：50.00%
→ Qwen3-8B：51.79%

基本符合预期。

但是到了 Qwen3-4B：

GPT-5.5 → 47.02
DeepSeek V4 Pro → 38.10
GPT-5-mini → 49.40

反而是明显更弱的 GPT-5-mini Teacher 效果最好。

这说明 Teacher 的选择不能单纯看：

“谁最强？”

还要看：

“谁产生的经验更适合这个 Student？”

作者将其归因于 Teacher 与 Student 之间的兼容性问题。

换句话说：

一个强到离谱的老师写出来的“学霸笔记”，不一定是基础较弱学生最好用的笔记。

17. Student 多大最适合这种 Memory Distillation？

作者又测试了 Qwen3 系列：

  • 1.7B
  • 4B
  • 8B
  • 14B

AMD 后 AppWorld Accuracy 分别达到：

1.7B：21.43%
4B：49.40%
8B：51.79%
14B：52.68%

模型越大，最终性能总体越高。

但如果看相对于 Zero-shot 的提升幅度：

最高的却是 4B：

+34.52 个百分点。

作者认为原因是：

1.7B 太弱

即使给它经验，它可能也没有足够能力理解和执行。

8B / 14B 本身已经比较强

它们 Zero-shot 就能够完成相当多的任务，因此继续提升的空间变小。

4B 正好处于一个“甜点区间”

它：

  • 本身还有大量能力缺口；
  • 但又已经强到足够理解教师 Memory。

所以收益最大。

18. Memory 是不是召回越多越好？

答案恰恰相反。

作者测试：

$$
k=1,2,3,4,5
$$

发现最好的选择基本就是：

$$
k=1
$$

特别是 Subtask Memory。

当召回数量从 1 增加到 5 时，AppWorld 准确率从：

49.40%

一路下降到：

33.34%。

原因并不难理解。

Top-1 通常是最相关的。

继续加入：

Top-2
Top-3
Top-4
Top-5

就越来越可能出现：

  • 相似但其实不适用的任务；
  • 不相关操作；
  • 多套互相冲突的解决方式。

对于本身上下文理解能力就有限的小模型来说：

更多 Memory 并不代表更多帮助，也可能意味着更多干扰。

因此 AMD 的结论是：

精准地给一条最相关经验，比一次塞进去大量经验更加重要。

19. 不同粒度的 Memory，最佳表达形式也不同

作者还做了一个很有意思的实验：

Memory 到底应该写成自然语言，还是直接保存 Code？

结果表明，三个层次并不一样。

Workflow：自然语言更好

Code：44.05%
Text：49.40%

因为 Workflow 本身表达的是抽象规划。

例如：

登录 → 获取数据 → 过滤 → 聚合。

自然语言更容易泛化。

Subtask：Code 明显更好

使用具体 Code：

49.40%

只保存自然语言描述：

23.21%

几乎直接腰斩。

因为 Subtask 本身需要回答的是：

“这一步具体怎么做？”

此时告诉模型：

“正确处理日期格式。”

远不如直接给它：

一个曾经正确执行成功的代码片段。

Function：同样更适合具体调用案例

Function Memory 换成纯文本后：

49.40% → 47.62%

如果三种 Memory 全部变成自然语言：

49.40% → 26.19%

因此 AMD 得到一个很值得记住的结论：

高层经验适合自然语言，底层执行经验适合具体代码或 Tool Call。

换句话说，并不存在一种 Memory 表示形式适合所有粒度。

20. 一个很重要的实验问题：会不会“偷看自己的答案”？

读到这里其实很容易产生一个疑问。

论文的主要实验中：

Teacher 在 benchmark 上执行任务并建立 Memory，然后 Student 又在同一个 benchmark 上进行测试。

那么就有可能发生：

Teacher 做过 Task A
↓
Task A 的成功轨迹进入 Memory
↓
Student 现在又做 Task A
↓
刚好把 Task A 自己的经验召回出来

这样的话，实验提升就可能被高估。

作者也意识到了这个问题，并且专门在附录进行了两种额外实验。

20.1 Cross-Split

把整个数据集按照：

7 : 3

拆开。

前 70%：

只用于 Teacher 建立 Memory

后 30%：

只用于 Student 测试

二者完全不重叠。

Qwen3-4B 在 AppWorld 上：

Zero-shot：16.07%
Workflow：21.43%
WF + ST：39.29%
完整 AMD：41.07%

依然存在非常明显的提升。

20.2 Self-Excluded Retrieval

第二种实验允许从整个 benchmark 建 Memory，但是：

Student 执行某个任务时，禁止召回由这个任务自身产生的 Memory。

结果 AppWorld：

Zero-shot：14.88%
WF：23.21%
WF + ST：40.48%
完整 AMD：46.43%

同样明显高于 Zero-shot。

因此虽然主实验允许 Memory 和测试任务来自同一个 benchmark，附录实验说明：

AMD 的提升并不完全依赖“召回当前任务自己的答案”，其他任务中的教师经验确实能够迁移到新任务。

不过从数值也可以看到，严格 Cross-Split 下 AppWorld 的 41.07% 仍低于主实验的 49.40%。

因此阅读主实验结果时，最好还是把这一实验设置区别记清楚。

21. 为什么作者的方法有效？

现在回头看，其实整篇论文的逻辑非常统一。

小模型的问题不是简单的：

“没有经验。”

而是同时存在两层问题：

问题 1：
自己的成功经验太少。

问题 2：
即使拿到强模型的经验，
也不一定能够理解并执行。

AMD 分别解决这两个问题。

首先：

Student 自己的经验
        ↓
换成
        ↓
Teacher 的成功经验

解决经验质量问题。

然后：

一整块复杂 Teacher Memory
        ↓
拆成
        ↓
Workflow
Subtask
Function

解决小模型难以消化教师经验的问题。

所以这篇论文真正的重点其实并不只是：

“用强模型给小模型生成 Memory。”

更加重要的是：

教师经验必须按照学生能够使用的粒度进行重新组织。

从实验来看，中间粒度的 Subtask Memory 恰好处于一个非常关键的位置：

Workflow
太抽象
    ↓
Subtask
既具体，又有一定泛化能力
    ↓
Function
过于局部

这也是为什么它带来的性能提升最大。

22. 这和传统 Knowledge Distillation 有什么区别？

传统知识蒸馏通常是：

Teacher
↓
生成软标签 / 推理数据 / Trajectory
↓
训练 Student
↓
Student 权重发生变化

AMD 则是：

Teacher
↓
成功 Trajectory
↓
提取外部 Memory
↓
Student 推理时检索
↓
Student 权重完全不变

因此它虽然使用了 Distillation 这个名字，但其“蒸馏结果”实际上并没有进入 Student 的模型参数。

它更像是把：

教师 Agent 的行为经验

压缩成一个：

学生可以直接检索和使用的外部经验库。

所以这篇论文可以看作 Knowledge Distillation 与 Agent Memory 两条研究路线的结合。

作者自己也将 AMD 定义为一种 training-free 的教师到学生 Agent Memory Transfer。

23. 这篇工作的局限

论文自己列出了三个比较明确的限制。

23.1 目前只验证了结构化 Tool-Use

当前实验基本都是：

  • Python API；
  • Function Calling；
  • JSON Tool Call。

因此还不知道它能不能很好迁移到：

  • GUI Agent；
  • 多模态 Agent；
  • 开放式 Coding Agent；
  • Web Agent 等更加复杂的任务。

23.2 Memory 是离线生成并冻结的

AMD 的过程是：

Teacher 先生成 Memory
↓
Student 使用

Student 在之后执行任务过程中获得的新经验：

不会自动反过来更新 Memory。

因此它并不是一个完整意义上的持续自进化系统。

如果 Student 在实际使用中发现：

新的成功方法
新的错误
新的环境变化

AMD 当前都没有继续学习和维护这些经验的机制。

23.3 Teacher 的选择依然是开放问题

实验已经说明：

最强 Teacher 不一定是最适合某个 Student 的 Teacher。

因此未来一个很自然的问题就是：

Student A 应该向哪个 Teacher 学？
Student B 又应该向哪个 Teacher 学？

甚至进一步：

不同类型任务
是否应该动态选择不同 Teacher？

论文并没有解决这个问题。

24. 总结

这篇论文的故事其实可以浓缩成一句话：

小模型 Agent 自己不会做，那就让强模型先做；但不能只把强模型的高层经验扔给它，而是要把经验拆成它能够理解的多个层次。

AMD 因此建立了三级 Memory：

Workflow Memory
↓
告诉 Student：整体怎么做

Subtask Memory
↓
告诉 Student：具体某一步以前怎么做成功

Function Memory
↓
告诉 Student：某个工具调用失败时应该怎么修

其中实验最值得注意的结论是：

  1. Teacher Memory 明显优于 Student 自己产生的低质量 Memory；
  2. 简单迁移 Teacher Memory 并不稳定，Memory 必须适应小模型能力；
  3. Subtask Memory 是整个框架贡献最大的部分；
  4. Memory 不是越多越好，Top-1 往往比 Top-k 大量召回更有效；
  5. 高层规划适合自然语言，底层执行经验更适合具体 Code / Tool Call；
  6. Teacher 并非越强越好，还存在 Teacher–Student 兼容性问题；
  7. 整个过程无需修改 Student 权重，可以直接在推理阶段实现能力增强。

从 Agent Memory 的角度来看，这篇工作的重点已经不再只是传统的：

“记忆应该怎么存、怎么查？”

而是进一步提出了一个新的问题：

“一个模型产生的经验，怎样才能真正成为另一个能力更弱模型可以使用的记忆？”

这也是 Agent Memory Distillation 相比普通 Agent Memory 工作最值得关注的地方。

posted @ 2026-08-15 15:39  YourF4u1t  阅读(3)  评论(0)    收藏  举报