Inference-Time Distillation: Cost-Efficient Agents Without Fine-Tuning or Manual Prompt Engineering

Inference-Time Distillation：无需微调，用教师轨迹在推理阶段“蒸馏”出低成本 Agent

论文标题： Inference-Time Distillation: Cost-Efficient Agents Without Fine-Tuning or Manual Prompt Engineering
作者： Vishnu Sarukkai, Asanshay Gupta, James Hong, Michaël Gharbi, Kayvon Fatahalian
机构： Stanford University、Reve
论文： arXiv:2512.02543，初版发表于 2025 年 12 月，本文基于 2026 年 4 月更新的 v3 版本。

1. 一句话理解这篇论文

这篇论文想做一件非常直接的事情：

先让昂贵的大模型教师 Agent 做几百个任务，把完整轨迹保存下来；之后便宜的小模型学生 Agent 做新任务时，每一步都从这些教师轨迹中检索相似经验。学生如果很确定，就自己执行；如果拿不准，再临时叫教师模型来做这一小步。

整个过程：

不训练模型；
不修改模型权重；
不需要专门人工设计大量提示词；
教师只负责少量示范任务以及学生真正不会的步骤；
大部分任务最终仍由便宜的学生模型完成。

作者把这种方法称为 Inference-Time Distillation，推理时蒸馏。

如果进一步把论文压缩成一句更加工程化的话，其实就是：

教师轨迹 RAG + 动态少样本学习 + 大小模型级联。

2. 为什么需要“推理时蒸馏”？

假设现在我们需要部署一个 Agent，而且有两个模型可以选择：

模型	优点	缺点
强模型教师	能力强、任务成功率高	非常贵
小模型学生	便宜	能力明显弱

最简单的办法当然是：

所有任务都交给教师模型。

但如果需要跑几十万甚至几百万个 Agent 任务，这个成本会非常夸张。

传统知识蒸馏的解决办法则是：

教师模型↓
生成大量高质量数据↓
训练学生模型↓
获得便宜但能力更强的学生

问题在于：

训练本身也很麻烦。

你需要准备训练数据、设计训练目标、调参、训练、验证，Agent 的多步轨迹训练尤其容易出现各种工程问题。

而如果 Agent 的框架稍微改了一下，例如：

原 Agent：
Plan → Action → Observation改版 Agent：
Plan → Tool Selection → Action → Observation → Reflection

之前蒸馏出来的模型甚至可能又需要重新训练。

作者因此提出了一个非常现实的问题：

能不能完全不训练学生，而是在推理阶段直接把教师的能力“借”给学生？

这就是本文的出发点。作者明确限制所有模型权重保持冻结，只允许使用检索、上下文示例以及模型路由等推理阶段机制。

3. 整体框架

论文 Figure 1 基本已经把整个方法讲完了。

整个系统可以分成两个阶段：

阶段一：教师经验收集
────────────────────任务 1 → Teacher LLM → Trajectory 1
任务 2 → Teacher LLM → Trajectory 2
任务 3 → Teacher LLM → Trajectory 3↓Vector DB阶段二：学生执行
────────────────────新任务↓
Student LLM↓
检索相似 Teacher Trajectory↓
学生生成多个 Action↓
这些 Action 是否一致？├── 是 → Student 自己执行│└── 否 → Teacher 接管当前这一步

这张图最重要的地方其实不是 Vector Database，而是最右边：

教师不是接管整个任务，而是只接管学生不确定的某一个步骤。

所以一个任务可能是：

Step 1 → Student
Step 2 → Student
Step 3 → Student
Step 4 → Teacher
Step 5 → Student
Step 6 → Student

而不是：

Student 不会↓
整个任务重新交给 Teacher

这使得昂贵教师模型的调用比例能够被压得很低。

4. 第一阶段：建立教师轨迹数据库

首先选择一个强模型作为教师。

论文主要实验中使用：

Teacher = Claude Sonnet 4.5
Student = GPT-4.1-mini

此外作者还使用 Llama-3.3-70B 作为学生进行了额外实验，验证方法并不只对 GPT 系列模型有效。

教师首先执行一小批任务。

例如：

任务：
把桌子上的苹果放进冰箱。Teacher Plan：
1. 找到苹果
2. 拿起苹果
3. 找到冰箱
4. 打开冰箱
5. 放入苹果

之后产生完整轨迹：

Goal
↓
Plan
↓
Observation 1
Reasoning 1
Action 1
↓
Observation 2
Reasoning 2
Action 2
↓
...

论文把一条教师轨迹表示为：

[
\tau_i =
{g_i,p_i,(o_t,r_t,a_t)_{t=1}^{T_i}}
]

其中：

(g_i)：任务目标；
(p_i)：教师生成的整体计划；
(o_t)：当前环境观察；
(r_t)：教师当前步骤的推理；
(a_t)：教师最终采取的动作。

也就是说，作者并不是只保存：

任务 → 最终答案

而是保存：

任务
+ 整体计划
+ 中间观察
+ 中间推理
+ 每一步 Action

因此这实际上是一个 完整的 Agent Trajectory 数据库。

5. 教师轨迹是如何存储和检索的？

作者使用 MiniLM-L6-v2 生成向量表示，然后建立向量索引。

但这里并不是简单地：

完整 Trajectory → 一个 embedding

而是分别处理：

Goal       → embedding
Plan       → embedding
Reasoning  → embedding

这么做的原因很好理解：

一个完整 Agent 任务可能非常长。

假设教师曾经解决过：

“找到红色苹果，把它洗干净，然后放进冰箱。”

学生现在正在解决：

“找到杯子，把它放进冰箱。”

两个完整任务其实并不一样。

但是当学生执行到：

如何打开冰箱？

这一具体步骤时，教师过去轨迹里的：

找到冰箱
→ 打开冰箱
→ 放入物体

仍然可能非常有价值。

因此论文并不是简单的“任务级 RAG”，而是进一步做到了 步骤级动态检索。

6. 两层动态检索

这是这篇论文方法部分最值得注意的设计之一。

作者把检索分成两个层级。

6.1 任务开始：检索 Plan

刚拿到一个任务时：

当前 Goal↓
搜索历史 Teacher Goal↓
找到 k 个最相似任务↓
取出这些任务对应的 Teacher Plan↓
作为示例交给 Student↓
Student 生成自己的 Plan

例如学生现在收到：

把刀放到抽屉里。

系统可能检索出：

Teacher Example 1：
把叉子放进抽屉Teacher Plan：
找到叉子
→ 拿起叉子
→ 找到抽屉
→ 打开抽屉
→ 放入叉子

学生看到之后，很容易学到当前任务的大致结构。

6.2 执行过程中：每一步重新检索

接下来进入 ReAct 循环。

学生每执行一步之后，环境都会产生新的 Observation。

此时不会继续机械使用刚才那几个示例，而是：

Goal
+
当前 Plan
+
当前执行状态↓
重新检索 Teacher Trajectory↓
寻找与“当前步骤”最相关的教师经验

于是不同步骤召回的教师经验可以完全不同。

例如：

Step 1：寻找物体
召回 → 教师过去“搜索物体”的经验Step 2：拿起物体
召回 → 教师过去“拾取物体”的经验Step 3：打开容器
召回 → 教师过去“打开容器”的经验

这就是论文所说的 Dynamic In-Context Learning。

它与普通 few-shot 最大的区别之一就在这里。

普通 few-shot 往往是：

Prompt 开头塞几个 Example
↓
整个任务从头用到尾

而这篇论文是：

每走一步
↓
重新判断我现在处于什么状态
↓
重新寻找最有帮助的教师经验

对于多步 Agent 来说，这显然更加合理。

7. 为什么作者把它叫做“蒸馏”？

这里很容易产生一个误解。

传统知识蒸馏通常意味着：

Teacher Knowledge↓
训练↓
Student Parameters 改变

但是本文：

Teacher Knowledge↓
Context↓
Student Parameters 完全不变

所以严格来说，它并不是传统意义上 Hinton 式的参数蒸馏。

作者自己在方法章节里甚至给 “Distillation” 加了引号。

作者的解释是：

教师过去的：

Reasoning
+
Action

被动态放进学生上下文以后，学生实际上正在模仿：

教师做了什么
+
教师为什么这么做

因此它起到了类似“推理蒸馏”的效果，只不过知识不是进入学生的参数，而是进入学生的 上下文。

可以把两种方法理解为：

方法	教师知识存在哪里？
传统知识蒸馏	Student 权重
本文推理时蒸馏	外部 Trajectory Database + Context

所以它其实是一种：

非参数化的教师→学生知识迁移。

8. 第二个核心设计：学生“不确定”时再调用教师

即使有教师示例，小模型仍然不可能什么都会。

于是接下来出现第二个问题：

我们怎么知道学生什么时候会？

最理想的情况当然是学生直接告诉系统：

我这个 Action 有 97% 概率是正确的。

但 LLM 的置信度并没有这么可靠。

尤其 Agent 通常会先生成一串推理，再生成 Action，所以直接依赖某个 Action token 的概率并不能很好地描述整个决策到底靠不靠谱。

作者于是使用了一个非常朴素的方法：

Self-Consistency

对于同一个状态，让 Student 连续生成 3 次：

Sample 1 → Action A
Sample 2 → Action A
Sample 3 → Action A

如果三次结果一致：

A
A
A

说明：

Student 对当前该怎么做非常稳定。

那就直接执行 Student 的 Action。

但如果是：

A
B
A

甚至：

A
B
C

说明：

Student 自己都拿不准。

此时：

调用 Teacher
↓
让 Teacher 决定当前 Action

论文默认采用 (N=3) 次学生采样。

9. 一个例子就能看懂整个系统

假设现在学生 Agent 的任务是：

“找到杯子，把杯子放进微波炉。”

系统首先从教师数据库里找到几个类似任务：

Teacher Trajectory A：
把盘子放进微波炉Teacher Trajectory B：
把杯子放进橱柜

然后学生生成：

Plan：
1. 找杯子
2. 拿杯子
3. 找微波炉
4. 打开微波炉
5. 把杯子放进去

开始执行。

Step 1

Observation：

You are in the kitchen.

重新检索教师轨迹。

召回：

Teacher：
寻找目标物体前先检查 countertop。

Student 采样三次：

look at countertop
look at countertop
look at countertop

一致。

所以：

Student 执行。

Step 2

Observation：

A mug is on the countertop.

召回教师经验：

Teacher：
take mug from countertop

Student：

take mug
take mug
take mug

仍然一致。

Student 自己执行。

Step 3

突然遇到一个复杂状态。

例如：

Microwave is closed and another object blocks access.

Student 三次生成：

move object
open microwave
inspect microwave

三个结果完全不同。

系统认为：

Student 对这里没有把握。

于是：

Teacher LLM↓
给出正确 Action

Teacher 只负责解决这个步骤。

之后任务又重新交回 Student。

这就是整个方法。

10. 实验设置

论文选择了两个 Agent Benchmark。

10.1 ALFWorld

ALFWorld 是一个典型的交互式环境任务。

例如：

找到苹果
→ 拿起苹果
→ 找到冰箱
→ 打开冰箱
→ 把苹果放进去

任务主要考察：

环境理解；
多步规划；
状态追踪；
Action 选择。

作者使用：

500 条 Teacher Trajectory
134 个测试任务

作为实验数据。

10.2 AppWorld

AppWorld 更接近真实 Agent 场景。

Agent 需要操作 Gmail、Contacts、Calendar 等应用提供的 API，完成多步骤工作流。

例如一个任务可能要求：

找到某个人
↓
查询他的联系方式
↓
找到相关邮件
↓
创建一个日历事件
↓
发送消息

作者使用：

147 个 Teacher Demonstration
168 个测试任务

进行实验。

11. 对比哪些方法？

实验中主要比较四种配置：

Teacher

所有步骤都使用 Claude Sonnet 4.5。

可以看成：

高准确率
+
最高成本

Student Zero-Shot

直接让 GPT-4.1-mini 做任务。

没有教师经验。

最低成本
+
最低能力

Student + IC

学生使用动态检索到的 Teacher Trajectory。

但是：

永远不调用 Teacher。

这个实验用于观察：

单纯把教师轨迹放进 Context 到底能提升多少？

Student + IC + Cascade

完整方法：

Teacher Trajectory Retrieval
+
Student
+
Self-Consistency
+
必要时 Teacher 接管

这也是作者最终的方法。

12. 最关键实验结果

论文 Table 1 的结果非常直观。

这里每个数字都是：

相对成本 / 任务成功率

GPT-4.1-mini 作为 Student

方法	ALFWorld	AppWorld
Teacher	1.00 / 0.89	1.00 / 0.83
Student Zero-Shot	0.31 / 0.18	0.09 / 0.28
Student + IC	0.43 / 0.87	0.15 / 0.55
Student + IC + Cascade	0.41 / 0.96	0.29 / 0.66

这个表其实已经说明了整篇论文最重要的两个结论。

13. 结论一：教师轨迹本身就能极大增强学生

先看 ALFWorld。

纯 GPT-4.1-mini：

Accuracy = 18%

加入 Teacher Trajectory Retrieval：

Accuracy = 87%

从：

18%
↓
87%

而模型权重：

一丁点都没有改变。

更加夸张的是，教师 Claude Sonnet 4.5 本身也只有：

89%

也就是说：

仅仅靠动态检索教师轨迹，GPT-4.1-mini 就已经达到教师 97% 左右的水平。

同时成本只有教师的：

43%

14. AppWorld 上提升同样非常明显

AppWorld 更难。

GPT-4.1-mini Zero-Shot：

28%

加入教师轨迹：

55%

直接接近翻倍。

而成本仅仅是教师模型的：

15%

这组结果非常重要，因为它说明：

教师轨迹并不只是“让小模型多看几个例子”这么简单。

对于多步 Agent 来说，强模型历史轨迹中的：

任务规划
+
API 使用方式
+
环境状态处理
+
错误处理
+
中间推理

确实能够显著改变小模型之后的行为。

15. 结论二：再加入教师兜底，可以进一步推高性能

ALFWorld：

Teacher：Accuracy = 89%
Cost     = 100%

完整方法：

Student + IC + Cascade：Accuracy = 96%
Cost     ≈ 41%

也就是说作者甚至出现了一个有点反直觉的结果：

学生系统比教师本身还准，但只花了教师约四成的成本。

作者认为，一个可能原因是：

教师自己执行任务时只有当前上下文；

而学生除了拥有自身推理之外，还能从数据库里同时参考多个教师过去的相关轨迹，因此相当于额外获得了关于环境规律的信息。

16. 成本到底能省多少？

在 ALFWorld 中，论文按照其采用的 API 价格计算：

Teacher：$0.059 / episode

完整方法：

$0.024 / episode

大约：

2.5× 成本下降

而在 AppWorld：

约 3.5× 成本下降

同时保留教师约：

79% 的任务准确率

不过这里有一个很重要的前提：

教师一开始生成 Demonstration 也是要花钱的。

ALFWorld 中，论文计算的初始 500 条教师 Demonstration 成本约为：

$29.50

按照论文当时的模型价格，大约跑到：

843 个任务

之后，前期教师数据收集成本就能够被后续节省的推理费用抵消。

所以这套方法特别适合：

少量 Teacher Demonstration
+
大量后续重复类型任务

而不是只运行十几个任务就结束的场景。论文的成本计算使用的是 2025 年 10 月的 API 定价，并且没有计入向量数据库检索成本。

17. 一个非常有意思的现象：示例越多，并不是越好

作者进一步研究：

每一步到底应该召回多少个 Teacher Example？

假设：

k = 1

就是只拿一个最相似案例。

k = 10

就是塞十个案例。

在 ALFWorld 上：

k = 1 → 75%
k = 2 → 81%
k = 4 → 86%

增长非常明显。

但继续增加：

k = 6 ~ 10

准确率基本停留在：

86% ~ 88%

提升已经非常有限。

可是 Context 越来越长，调用成本却继续增加。

所以：

更多 Teacher Trajectory ≠ 一定更好。

关键仍然是：

召回足够相关的经验。

论文最终在 ALFWorld 使用 (k=6)，在 AppWorld 使用 (k=3)。

18. Teacher Database 越大，学生越强

另一个实验研究：

一开始到底需要采集多少条教师轨迹？

ALFWorld 的结果很漂亮。

只保存：

100 条 Teacher Demonstration

学生就已经达到：

83.6% Accuracy

相当于教师模型准确率的：

94%

增加到：

500 条

之后，已经达到教师约：

98%

的水平。

更加有意思的是：

Teacher Database 变大以后，成本反而可能下降。

乍看非常反直觉。

因为数据库越大：

检索内容更多？
Context 更长？
成本不是应该更高吗？

实际上并不是。

更大的数据库意味着：

更容易找到真正相关的经验
↓
Student 少走弯路
↓
需要执行的 ReAct Step 变少
↓
整个 Trajectory 变短
↓
Token 总量反而下降

例如论文附录统计发现，加入动态上下文示例以后：

ALFWorld 平均轨迹长度：

27.0 steps
→
12.1 steps

AppWorld：

19.3 steps
→
12.1 steps

所以：

好经验虽然会增加单步 Context，但可能让 Agent 少犯很多错误，最终总 Token 反而更少。

19. 学生为什么还会失败？

这部分其实是我认为论文实验里最有价值的分析之一。

作者专门找出了 AppWorld 中：

Teacher 成功
Student + IC 失败

的 53 个任务。

然后分析学生为什么失败。

其中有 48 个失败能够被比较明确地归因。

在这 48 个案例里：

33 个
≈ 68.8%

是因为：

召回出来的教师示例根本没有覆盖当前任务真正需要的能力。

例如当前任务需要：

某个特殊 API

但召回案例里：

没人用过这个 API

或者当前任务需要：

消除歧义
错误恢复
特殊状态判断

但是 Teacher Demonstration 里没有出现类似操作。

于是 Student 自然很难凭空学会。

20. 这里暴露出了整套方法真正的瓶颈

表面上看，这篇论文似乎是在研究：

怎么检索？
召回几个？
什么时候调用 Teacher？

但实验实际上指出了一个更加本质的问题：

Teacher Experience Coverage。

翻成更直白的话就是：

教师经验库里到底有没有“教过”学生现在需要的东西？

假设 Student 现在需要：

能力 A
能力 B
能力 C
能力 D

但 Teacher Database 只覆盖：

A
B
C

那么你把检索算法调得再漂亮：

Top-1
Top-3
Top-10
Cosine Similarity
更好的 Embedding

都没有办法召回：

因为数据库里根本不存在 D。

所以作者最后给出的启示是：

与其盲目收集更多相似 Trajectory，不如让 Teacher Demonstration 尽可能覆盖更多不同操作和能力。

这个结论非常重要。

21. 任务越难，小模型与教师的差距仍然会扩大

作者还按照 AppWorld 的任务难度进行了分析。

结果如下：

难度	Teacher	Student + IC + Cascade	Student Zero-Shot
Level 1	96%	91%	51%
Level 2	85%	70%	29%
Level 3	71%	43%	6%

可以看到：

简单任务：

Teacher 96%
Student 91%

已经非常接近。

但是困难任务：

Teacher 71%
Student 43%

差距重新明显拉大。

所以不能简单得出：

“有了 Teacher Trajectory，小模型就等于大模型。”

更加准确的说法是：

教师轨迹能够极大扩展小模型能够处理的任务范围，但不会完全消除模型自身能力上限。

22. 这篇论文和传统 Few-Shot 有什么区别？

乍看之下很容易说：

这不就是给 Student 几个 Teacher Example 吗？

确实，底层机制依然是 In-Context Learning。

但普通 Few-Shot 通常是：

人为选几个 Example
↓
固定写进 Prompt
↓
所有任务共用

本文则是：

几百条 Teacher Trajectory
↓
建立数据库
↓
根据当前 Task 自动检索
↓
执行过程中每一步重新检索
↓
不同 Step 使用不同 Example

所以它实际上把：

Few-Shot Prompt

扩展成了：

动态 Teacher Experience Retrieval

也就是：

教师经验不是 Prompt 的固定组成部分，而成为了 Agent 可以随时查询的外部知识库。

23. 它和 Agent Memory 有什么关系？

从 Agent Memory 的角度看，这套结构其实非常熟悉。

可以直接理解为：

Teacher Trajectory↓
长期记忆库↓
Embedding Retrieval↓
Relevant Memory↓
Student Context

区别主要在于：

普通 Agent Memory：

Agent 自己产生经验
↓
以后自己使用

这篇论文：

Teacher 产生经验
↓
Student 使用

所以从另一个角度来看：

它其实是在研究“跨模型的经验记忆迁移”。

但这篇论文并不属于严格意义上的 Self-Evolving Agent。

因为教师数据库在初始阶段建立完成之后就固定了：

D₀
↓
一直使用
↓
不会自动变成 D₁、D₂、D₃……

学生执行新任务产生的经验也不会继续写回数据库。

作者甚至专门强调，他们为了区分一次性的 Teacher 成本和后续 Student 部署成本，刻意保持数据库固定。

因此它更接近：

静态教师经验库 + 动态召回。

而不是：

持续学习 / 自进化记忆。

24. 这篇论文真正创新的地方是什么？

如果只看组件：

RAG
In-Context Learning
Self-Consistency
Model Cascade
ReAct

其实全部都是已有技术。

所以这篇论文并没有发明一个全新的基础算法。

它真正做的是：

把几种已有机制组合成一个无需训练的教师→学生 Agent 能力迁移方案，并系统验证这种方案在成本—性能之间确实可以形成新的 Pareto 前沿。

论文自己对此也比较坦诚。

作者强调，他们的贡献主要是把：

Teacher Trajectory Retrieval
+
Dynamic In-Context Learning
+
Self-Consistency Routing

真正用于 Agent 大规模低成本部署，然后系统研究：

Teacher Database 需要多大；
每次应该召回多少经验；
哪些经验最重要；
Student 为什么失败；
什么时候应该调用 Teacher；
教师数据成本多久才能摊平。

25. 这篇论文最值得注意的三个发现

我认为真正值得记住的不是某个具体准确率，而是下面三件事。

第一：Trajectory 可以在不训练权重的情况下产生非常强的能力迁移

ALFWorld：

GPT-4.1-mini18%
↓
87%

几乎全部提升来自：

Teacher Trajectory → Context

而不是训练。

这说明：

一个模型过去“怎么做任务”的完整行为轨迹，本身就是一种非常强的能力载体。

第二：对 Agent 来说，“在正确的步骤看到正确的经验”比简单堆更多经验重要

论文发现增加 Example 数量存在明显边际收益递减。

真正决定性能的是：

当前 Step
↓
是否召回了真正有用的 Teacher Behavior

这也是为什么作者最终强调 Demonstration Coverage。

第三：小模型并不需要完全替代大模型

传统蒸馏经常隐含这样的目标：

Teacher
↓
Student 学会
↓
以后完全不用 Teacher

本文采用的逻辑更加工程化：

简单的：
Student 做有经验的：
Student + Teacher Trajectory 做真正不会的：
Teacher 临时接管

也就是说：

目标不是让小模型彻底变成大模型，而是尽量缩小“大模型必须亲自出场”的范围。

这也是为什么 Cascade 在实际部署中特别合理。

26. 这篇论文的局限

26.1 非常依赖任务之间存在重复结构

这套方法成立的重要前提是：

T_test 与 T_demo

之间存在足够多的结构共性。

例如：

任务 A：
把苹果放进冰箱任务 B：
把杯子放进冰箱

经验显然可以迁移。

但如果每个测试任务都完全不同：

任务 A：操作 Gmail
任务 B：证明数学定理
任务 C：修复 Linux
任务 D：设计网页

检索过去轨迹的帮助就会明显下降。

因此它尤其适合：

大量同领域、结构相似的 Agent 工作流。

26.2 Self-Consistency 不等于正确

论文的核心假设之一是：

三次输出一致
≈
Student 有把握

但完全可能出现：

错误答案 A
错误答案 A
错误答案 A

也就是：

非常自信地错。

Self-Consistency 更准确地说检测的是：

输出稳定性

而不是真正意义上的：

正确概率。

所以 Cascade 只能减少一部分错误，并不能完全可靠地判断 Student 是否真的会做。

26.3 教师经验覆盖仍然是根本问题

如果数据库没有包含需要的能力：

Retrieval
↓
没有东西可检索

所以未来很自然的方向就是：

发现 Student Failure
↓
判断缺少哪种 Teacher Experience
↓
让 Teacher 专门补充这种经验
↓
写回 Database
↓
下一次 Student 就会

你会发现，一旦继续往这个方向走：

这套静态“推理时蒸馏”框架很自然就会开始接近 Agent 自进化。

因为 Database 不再固定，而开始根据失败不断补全自身。

论文作者在失败分析中也明确提出，未来可以通过不断加入 Demonstration 来填补这些经验覆盖缺口。

27. 一个值得继续延伸的研究方向

论文当前做的是：

Teacher 做一批任务
↓
Teacher DB
↓
Student 一直用

那么很自然可以进一步变成：

Teacher 初始 Trajectory↓
Student 执行↓
发现 Failure↓
分析缺失能力↓
Teacher 补充 Experience↓
更新 Memory↓
Student 再执行↓
继续发现新的 Coverage Gap↓
……

这样系统就从：

Inference-Time Distillation

逐渐变成：

持续 Teacher → Student Experience Transfer
+
Memory Evolution

这可能比单纯继续优化 Embedding 或 Top-k 更有研究空间。

28. 与“无训练教师→学生能力迁移”研究的关系

如果研究目标本身就是：

不训练模型权重，仅利用强模型产生的历史轨迹增强弱模型能力。

那这篇论文属于非常重要的相关工作，而且很适合作为强基线。

不过它和“把教师轨迹伪装成学生自己的历史，然后让学生直接续写”的思路仍然存在一个关键区别：

本文的关系是：

Teacher Trajectory↓
被明确作为 Example 检索出来↓
放进 Student Prompt↓
Student 参考这些 Example

也就是说，本质上是：

“这是别人以前怎么做的，你可以参考。”

而另一种可能的轨迹使用形式是：

Teacher Trajectory↓
直接成为 Student 对话历史的一部分↓
Student 从历史末尾继续执行

此时模型接收到的叙事结构更接近：

“这就是我之前做过的事情，现在我要继续做。”

两者都属于不更新权重的轨迹能力迁移，但对模型而言，Trajectory 在 Context 中的身份和位置不同。

因此这篇论文实际上提供了一个非常自然、而且相当强的对照组：

Teacher Trajectory as DemonstrationVS
Teacher Trajectory as Student History

如果第二种方式能够稳定超过本文这种动态示例式方法，那么就能说明：

提升并不仅仅来自“学生看到了教师轨迹”，轨迹被组织成“自身历史”这一上下文结构本身可能还产生了额外作用。

这也是这篇论文在研究设计层面非常值得关注的地方。

29. 总结

这篇论文提出的 Inference-Time Distillation 并没有训练学生模型，而是把强模型产生的 Agent Trajectory 当成一个外部经验数据库。

整个方法可以总结为：

                Teacher↓收集少量高质量 Trajectory↓Vector Database↓新任务到来↓Student↓每个 ReAct Step 动态检索↓Teacher Experience 放入 Context↓Student 采样 3 次↓┌────────┴────────┐↓                 ↓一致               不一致↓                 ↓Student Action       Teacher Action└────────┬────────┘↓下一 Step

它最终展示了一个很有意思的事实：

教师模型的能力并不一定只能通过参数训练才能传递。完整的任务轨迹本身就可以作为一种外部能力载体，在推理阶段显著改变小模型的行为。

ALFWorld 上，GPT-4.1-mini 从 Zero-Shot 的 18% 提升到只使用教师上下文示例时的 87%，加入动态教师兜底以后进一步达到 96%，甚至超过 Claude Sonnet 4.5 教师自身的 89%；与此同时，推理成本降至教师的大约四成。AppWorld 上虽然无法完全追平教师，但完整方法仍以约 29% 的教师成本获得 66% 成功率，而教师为 83%。

所以从研究视角看，这篇工作的意义并不只是：