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

arXiv：https://arxiv.org/abs/2512.02543

关键词：LLM Agent、Knowledge Distillation、In-Context Learning、RAG、Teacher-Student、Model Cascade、Self-Consistency

1. 一句话总结

这篇论文想解决一个非常实际的问题：

能不能不 Fine-tuning，也不花大量人工去调 Prompt，仅仅调用大模型 Teacher 跑少量任务，就让一个便宜得多的 Student Agent 在后续大量任务上接近 Teacher 的能力？

作者给出的答案是：

可以，而且关键只需要两个并不新的技术：

  1. Dynamic In-Context Learning：把 Teacher 做过的任务轨迹存起来，在 Student 执行新任务时动态检索相关轨迹作为 Few-shot 示例；
  2. Self-Consistency Cascade：让 Student 对同一个动作预测多次，如果几次结果一致，就相信 Student；如果不一致，就临时把这一步交给昂贵的 Teacher。

可以把整个方法浓缩成一句话：

Teacher 先留下少量“做题笔记”，Student 平时查笔记做题；只有 Student 自己都拿不准的时候，才去问 Teacher。

因此，这里的 Inference-Time Distillation 和传统知识蒸馏有一个本质区别：

知识并没有被训练进 Student 的权重，而是被保存在外部 demonstration database 中，通过推理时检索动态注入 Student 的上下文。

2. 为什么要做 Inference-Time Distillation？

2.1 大模型 Agent 面临一个非常现实的成本问题

假设我们开发了一个 Agent。

使用 Claude Sonnet 4.5 这样的强模型作为 Agent Backbone，效果很好，但是如果每天需要处理几十万甚至几百万个任务，推理成本会非常高。

最简单的解决方案当然是：

换一个便宜的小模型。

问题是，小模型虽然便宜，能力却可能断崖式下降。

论文中的实验就是一个非常典型的例子。

在 ALFWorld 上：

Model Accuracy
Claude Sonnet 4.5 Teacher 0.89
GPT-4.1-mini Zero-shot Student 0.18

如果直接把 Teacher 换成 GPT-4.1-mini：

成本确实下来了，但 Agent 基本也不会做任务了。

因此真正的问题并不是：

怎么使用小模型？

而是：

怎么让小模型以尽可能低的成本获得大模型的能力？

2.2 传统方案：Fine-tuning

一个很自然的方法就是 Knowledge Distillation：

Teacher
   ↓
生成大量轨迹
   ↓
作为训练数据
   ↓
Fine-tune Student
   ↓
Student 学会 Teacher 的行为

这也是经典 Teacher-Student Distillation 的思路。

但是作者认为，在很多 Agent 场景下，这条路线存在一个非常重要的问题：

不够 Agile。

这里的 Agility，可以理解成：

修改完 Agent 后，能不能马上部署。

例如你今天修改了：

  • Agent 的 Tool；
  • Prompt；
  • Action Space；
  • Planning 逻辑；
  • 工作流；
  • 环境接口。

如果依赖 Fine-tuning，那么可能又需要：

收集数据
   ↓
整理数据
   ↓
重新训练
   ↓
调参
   ↓
测试
   ↓
重新部署

整个周期可能需要数小时甚至数天。

对于一些大规模 Batch Processing 任务来说，这更加明显。

例如：

现在突然有 100 万条数据需要 Agent 处理

你可能希望：

先让强 Teacher 做几百条
↓
然后马上让便宜 Student 做剩下几十万条

而不是：

Teacher 做几百条
↓
训练 Student 两天
↓
再开始执行任务

因此论文提出了两个明确约束：

  1. No Model Training
  2. Immediate Deployment

也就是说：

Student 的模型参数完全冻结，能力增强必须全部发生在 inference time。

3. 核心思想：把“蒸馏到权重”变成“蒸馏到 Context”

传统 Knowledge Distillation 是：

Teacher Knowledge
      ↓
Training
      ↓
Student Parameters

而这篇论文变成：

Teacher Knowledge
      ↓
Teacher Trajectories
      ↓
Vector Database
      ↓
Retrieve
      ↓
Student Context

因此它实际上做了一次非常重要的转换：

Parameter-level Distillation → Context-level Distillation

Teacher 的知识并没有真正进入 Student 参数，而是被保存成一种外部经验库。

每次 Student 遇到任务时，再动态取出相关 Teacher 经验。

从这个角度来看，这篇论文所谓的 Distillation，其实和下面几个领域存在非常明显的交叉：

  • Knowledge Distillation
  • Retrieval-Augmented Generation
  • Agent Memory
  • In-Context Learning
  • LLM Cascade / Model Routing

这也是理解整篇论文最重要的一点。

4. 整体框架

论文的整体方法其实非常简洁。

image

【Figure 1：Inference-Time Distillation 整体框架，论文最核心的架构图，展示 Teacher Demonstration Collection、RAG、Student 与 Self-Consistency Cascade】

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

阶段一：Demonstration Collection

Teacher
   ↓
运行几百个任务
   ↓
产生完整 Trajectory
   ↓
Vector Database


阶段二：Inference

New Task
   ↓
Retrieve Teacher Experience
   ↓
Student
   ↓
生成多个 Candidate Actions
   ↓
是否一致？
 ┌───────┴────────┐
 Yes              No
  ↓                ↓
Student Action   Teacher Action

5. 第一阶段：Teacher Demonstration Collection

首先让昂贵的 Teacher Agent 执行一批任务。

论文中使用：

  • Claude Sonnet 4.5 作为 Teacher；
  • GPT-4.1-mini 作为主要 Student。

Teacher 每完成一个任务，就得到一条完整 trajectory。

一条 Teacher trajectory 可以表示为：

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

其中：

  • $g_i$：任务 Goal；
  • $p_i$：Teacher 生成的高层 Plan；
  • $o_t$：第 $t$ 步 Observation；
  • $r_t$：Teacher 的 Reasoning；
  • $a_t$：Teacher 最终采取的 Action。

换句话说，作者不是只保存：

State → Action

而是保存：

Goal
Plan
Observation
Reasoning
Action

所以 Student 后面模仿的不只是：

Teacher 做了什么。

还包括：

Teacher 为什么这么做。

作者因此把它和 Reasoning Distillation 联系起来。

6. Teacher 数据如何存储？

收集 Teacher Trajectory 之后，作者使用 MiniLM-L6-v2 生成 Embedding，并建立 Vector Database。

比较值得注意的是：

作者并不是简单地：

整个 trajectory
→ 一个 embedding

而是分别为不同内容建立表示。

包括：

Goal Embedding
Plan Embedding
Reasoning Embedding

后面 Student 执行任务的时候，会根据当前阶段使用不同的信息进行 retrieval。

7. 第二阶段之一：Dynamic In-Context Learning

这是整篇论文真正承担“能力迁移”功能的部分。

Student 每次面对新任务，并不是 Zero-shot 执行，而是首先：

从 Teacher Demonstration Database 中找到和当前情况最相似的 Teacher 经验。

然后把它们塞进 Context。

不过作者没有使用一个固定的 Few-shot Prompt，而是采用了：

Dynamic Per-Step Retrieval

也就是：

Agent 每走一步，都重新检索一次。

这非常重要。

8. Planning 阶段如何 Retrieval？

Agent 首先需要生成一个 High-Level Plan。

例如当前 Goal 为：

Goal
↓
Retrieve similar teacher goals
↓
得到 Teacher Plans
↓
Student 根据这些 Plan 示例生成自己的 Plan

作者会根据 Goal 的 cosine similarity：

Current Goal
      ↓
Vector Search
      ↓
Top-k Similar Teacher Goals
      ↓
对应的 Teacher Plans

然后将这些 Plan 作为 In-Context Examples。

因此 Planning 可以理解为：

找几个 Teacher 曾经处理过的类似任务，看看 Teacher 当时是怎么规划的。

9. Acting 阶段如何 Retrieval？

真正执行任务之后，Agent 每一步又进行一次检索。

这一阶段会同时考虑：

  • Goal；
  • Plan；
  • 当前相关 Reasoning / Step Context。

论文采用 multi-key retrieval，通过多个维度的 cosine similarity 找到相似的 Teacher Steps。

关键在于：

作者不会把整条 Teacher Trajectory 都塞进 Context。

而是只拿相关步骤附近的一个小窗口。

例如 Teacher trajectory 是：

Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10

当前最相似的是：

Step 6

系统可能只拿：

Step 4
Step 5
Step 6
Step 7
Step 8

而不是把完整 10 步全部放进去。

这样做有两个好处：

  1. Context 中的信息更加相关；
  2. 减少 Input Token Cost。

论文的实验甚至发现：

Retrieval 的相关性比 Context 的数量更加重要。

使用 Per-step Retrieval 和直接检索整条 Trajectory，准确率几乎一致：

Method ALFWorld Accuracy Relative Cost
Per-step Retrieval 0.87 0.43
Full / Single Retrieval 0.87 0.54

AppWorld 上同样如此：

Method Accuracy Relative Cost
Per-step Retrieval 0.55 0.15
Single Retrieval 0.54 0.24

因此：

塞更多历史不一定更好，精准地塞入当前真正需要的历史才更加重要。

这一结论其实对 Agent Memory 同样非常有启发。

10. Dynamic ICL 为什么可以被称为“Distillation”？

看到这里可能会产生一个疑问：

这不就是 RAG / Few-shot ICL 吗？为什么叫 Distillation？

作者的解释是：

Teacher trajectory 中包含：

Observation
Reasoning
Action

Student 在执行任务时，可以直接看到 Teacher 对相似状态的：

Teacher 如何理解问题
↓
Teacher 如何推理
↓
Teacher 最终如何行动

因此 Student 实际上是在 Context 中模仿 Teacher 的行为模式。

传统蒸馏：

Teacher trajectory
↓
Gradient Descent
↓
Student Weight

本文：

Teacher trajectory
↓
Retrieval
↓
Student Context

所以更准确地说，它是一种：

Non-parametric / In-Context Reasoning Distillation。

11. 但是只靠 Retrieval 还存在一个问题

即使给 Student 看 Teacher 的案例，也不意味着 Student 一定会做。

可能出现：

检索结果非常相关
→ Student 很确定
→ 正确执行

也可能：

检索结果不够相关
→ Student 不知道怎么办
→ 开始乱猜

这时候如果仍然强制让 Student 执行，就可能导致整个任务失败。

因此系统需要解决第二个问题：

什么时候应该相信 Student，什么时候应该调用 Teacher？

这就是第二个核心模块：

Self-Consistency Cascade。

12. Self-Consistency Cascade：Student 不确定时再请 Teacher

对于每个 Agent Step，作者不会只调用一次 Student。

而是让 Student 对同一个问题采样：

$$N=3$$

次。

得到：

Action 1
Action 2
Action 3

然后比较三个 Action。

如果：

Action 1 = Action 2 = Action 3

说明 Student 的输出具有较高一致性。

系统直接执行 Student Action。

反过来，如果：

Action 1 = A
Action 2 = B
Action 3 = C

或者存在明显分歧：

说明 Student 对当前状态并不确定。

此时：

Student
  ↓
Inconsistent
  ↓
Teacher
  ↓
Teacher Action

因此路由逻辑可以写成：

$$a_t=\begin{cases}a_t^{(1)},&\text{Student outputs are consistent}\M_t(g,p,o_t),&\text{otherwise}\end{cases}$$

本质上就是：

简单的题 Student 自己做，难题再调用 Teacher。

13. 为什么不用模型自己的 Confidence？

一种更自然的方法可能是：

Student probability > threshold
→ Student

Student probability < threshold
→ Teacher

但 Agent 场景中存在 Reasoning。

也就是模型通常产生：

Reasoning Tokens
↓
Action Tokens

因此 Action 的概率受到整条 Reasoning Path 的影响。

直接使用 Token Probability 并不能很好地反映：

模型到底对这个 Action 有多确定。

所以作者选择了一个非常简单的替代方案：

Sampling + Self-Consistency。

如果多次采样都得到相同答案，就将其作为一种 confidence signal。

14. AppWorld 中还有一个细节：语义一致 ≠ 字符串一致

例如三个 Student 可能输出：

delete_song(id=3)

remove_song(song_id=3)

queue.delete(3)

虽然字符串不同，但有可能表达的是相同操作。

因此在 AppWorld 中，作者额外使用 GPT-4.1-mini Verifier 判断：

多个 Candidate Actions 是否在语义上等价。

如果 Verifier 判断等价，就视为 Consistent。

否则调用 Teacher。

15. 最终完整流程

这样整篇论文的方法就可以写成：

==============================
Offline / Collection
==============================

Teacher
   ↓
执行少量任务
   ↓
Goal + Plan + Observation
+ Reasoning + Action
   ↓
Embedding
   ↓
Teacher Demonstration DB


==============================
Online / Inference
==============================

New Task
   ↓
Retrieve similar Teacher Plans
   ↓
Student generates Plan
   ↓
Observation
   ↓
Retrieve similar Teacher Steps
   ↓
Student Sample #1
Student Sample #2
Student Sample #3
   ↓
Self-Consistency
   ↓
 ┌──────────────┬──────────────┐
 Consistent                 Inconsistent
     ↓                         ↓
Student Action              Teacher
                               ↓
                         Teacher Action

可以发现，整个系统实际上非常朴素。

没有：

  • Fine-tuning；
  • RL；
  • Learned Router；
  • 专门训练 Reward Model；
  • 复杂的 Prompt Optimization。

真正做的就是：

Teacher Experience Retrieval
+
Student
+
Self-Consistency Routing

16. 实验设置

论文主要使用两个 Agent Benchmark。

16.1 ALFWorld

ALFWorld 是一个经典的 Embodied Agent / Planning Benchmark。

作者：

  • 使用 500 个 Train Tasks 收集 Teacher Demonstrations；
  • 在 134 个 OOD Tasks 上测试。

16.2 AppWorld

AppWorld 更接近真实的数字工作流。

Agent 需要操作：

  • Gmail；
  • Contacts；
  • Calendar；
  • Spotify；
  • 其他 App API。

很多任务需要完成复杂的：

理解用户需求
↓
寻找 API
↓
连续 API 调用
↓
管理状态
↓
最终完成任务

作者：

  • 使用 147 个 Train + Validation Tasks 作为 Demonstrations；
  • 在 168 个 test-normal Tasks 上测试。

因此 AppWorld 明显比 ALFWorld 更难。

17. Teacher 与 Student

主要配置：

Teacher:
Claude Sonnet 4.5

Student:
GPT-4.1-mini

作者另外使用：

Llama-3.3-70B

作为 Student 进行泛化验证。

实验比较的主要配置包括：

Teacher

Student (ZS)
    Zero-shot Student

Student (IC)
    Student + Dynamic In-Context Learning

Student (IC + Cascade)
    完整方法

Student (Cascade Only)
    只有 Cascade，没有 Teacher Examples

Random Mix
    随机决定调用 Student / Teacher

这里的消融实验设计还是比较清楚的。

作者希望分别验证：

Retrieval 到底有没有作用？
Cascade 到底有没有作用？
二者组合是否更好？

18. 核心实验结果

image

【Figure 2：ALFWorld 与 AppWorld 的 Cost-Accuracy Pareto Frontier，论文最重要的实验结果图】

最核心结果如下。

GPT-4.1-mini

Method ALFWorld Cost / Acc AppWorld Cost / Acc
Teacher 1.00 / 0.89 1.00 / 0.83
Student ZS 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

这里的 Cost 都是相对于 Teacher 的归一化成本。

19. 一个非常重要的结果：光靠 ICL 就已经提升巨大

先看：

Student ZS
vs
Student IC

ALFWorld

Zero-shot Student：

Accuracy = 0.18

加入 Teacher In-Context Examples：

Accuracy = 0.87

直接从：

18% → 87%。

而 Teacher 是：

89%

也就是说：

完全没有训练，只是把检索到的 Teacher Experience 放进 Context，小模型就达到了 Teacher 97% 左右的性能。

成本则只有 Teacher 的：

43%

AppWorld

Zero-shot：

0.28

加入 IC：

0.55

同时成本只有 Teacher 的：

15%

这其实说明：

在这种具有明显重复工作流结构的 Agent Task 中，小模型能力不足的一大部分原因，并不是完全不会推理，而是缺少当前任务所需要的行为模式和操作知识。

Teacher Examples 恰好可以在 Context 中提供这些信息。

20. IC + Cascade：进一步移动 Pareto Frontier

加入 Cascade 后：

ALFWorld

Teacher：

Accuracy = 0.89
Cost = 1.00

完整方法：

Accuracy = 0.96
Cost ≈ 0.41

也就是说：

准确率甚至超过 Teacher，同时成本只有 Teacher 的约 40%。

按照论文给出的实际 API Cost：

Teacher:
$0.059 / episode

Ours:
$0.024 / episode

约：

2.5× Cost Reduction。

作者认为超过 Teacher 的一个可能原因是：

Student 不只是拥有当前 Teacher 的一次推理能力，同时可以在 Context 中看到多个 Teacher 历史轨迹，其中还隐含了环境动力学相关的信息。

需要注意的是，这是作者针对实验现象给出的解释，而不是论文严格证明出的因果机制。

21. AppWorld：更难的任务上还无法完全达到 Teacher

AppWorld：

Teacher:
Accuracy = 0.83

Student IC + Cascade:
Accuracy = 0.66

也就是恢复了 Teacher 大约：

79%

的性能。

但成本仅为：

29%

相当于约：

3.5× Cost Reduction。

所以 AppWorld 的结果更加现实：

不是免费得到 Teacher 的全部能力，而是在 Accuracy 和 Cost 之间找到更好的 Pareto Point。

22. 为什么 Cascade 有价值？不是直接随机调用 Teacher 就行吗？

论文还设计了一个 Random Router。

例如：

20% Steps → Teacher
80% Steps → Student

或者：

40%
60%
80%

这样可以判断：

Cascade 的提升到底只是因为“调用了一部分 Teacher”，还是因为它真的知道“什么时候需要 Teacher”。

结果表明：

Self-Consistency Routing 明显优于 Random Routing。

也就是说：

Teacher 调用次数本身不是关键，关键是要把有限的昂贵 Teacher Calls 用在 Student 真正不确定的位置上。

23. Teacher Demonstration 越多越好吗？

作者进一步研究了 Teacher Database Size。

ALFWorld 上：

100 Teacher Demonstrations
→ Accuracy = 0.836

已经达到 Teacher Accuracy 的约：

94%

500 条时：

接近 Teacher 的 98%

这说明 In-Context Distillation 的数据效率非常高。

甚至：

20 条 ALFWorld Teacher Demonstrations

和：

5 条 AppWorld Demonstrations

都可以明显超过 Zero-shot Student。

因此整个框架成立的一个重要基础就是：

并不需要先花巨额成本收集几十万条 Teacher Data。

少量 Teacher Trajectory 就已经可以带来显著收益。

24. 为什么 Database 越大，成本反而可能下降？

这个实验结果一开始看起来有点反直觉。

Database 越大：

Retrieved Context

似乎应该让成本越来越高。

但作者发现：

ALFWorld：

DB Size = 20
Cost ≈ 58% Teacher

DB Size = 500
Cost ≈ 43% Teacher

原因在于：

更大的 Database 增加了检索到真正相关经验的概率。

于是 Student：

少走弯路
↓
更快完成任务
↓
Trajectory 更短
↓
总 Token 数反而减少

例如论文报告：

ALFWorld：

Zero-shot Student:
27.0 steps

Student + IC:
12.1 steps

AppWorld：

19.3 steps
→
12.1 steps

所以 Retrieval 虽然增加了每一步的 Input Context，却降低了总执行步数。

最终反而可能更加便宜。

这是论文中一个很有意思的发现：

Context Token 更多，并不一定意味着整个 Agent 更贵；如果这些 Context 能让 Agent 少走足够多的弯路，总成本反而可能下降。

25. 每次 Retrieval 应该拿多少 Example？

更多 Examples 通常能够提高准确率，但会增加 Context Cost。

ALFWorld：

k = 1
Accuracy ≈ 0.75

k = 4
Accuracy ≈ 0.86

但是继续增加到：

k = 6 ~ 10

收益已经非常有限。

因此存在明显的：

Diminishing Return。

论文最终采用：

ALFWorld:
k = 6

AppWorld:
k = 3

这里说明一个非常实际的问题：

RAG / Agent Memory 并不是 Retrieve 越多越好。

真正需要优化的是：

Relevant Information / Token Cost

而不是单纯增加 Context。

26. Student 为什么还会失败？

这是论文中我认为非常值得关注的一组分析。

作者分析了 AppWorld 上：

Teacher 成功
但 Student + IC 失败

的 53 个任务。

他们希望知道：

已经给 Student Teacher Examples 了，为什么还是不会？

通过 LLM Judge 分析后，作者认为其中大量失败都与：

Coverage Gap

有关。

也就是：

检索出来的 Teacher Examples 根本没有展示当前任务真正需要的关键行为。

27. 论文中的真实案例：Spotify Queue

这个案例来自论文 Appendix E，而不是额外构造的示意案例。

任务要求 Agent：

从 Spotify Queue 中删除一组歌曲。

Teacher 成功完成了任务。

Teacher 使用的关键策略是：

从队列后方向前删除歌曲。

原因很简单：

如果从前往后删除：

index 2 删除
↓
后面的歌曲 index 全部改变
↓
继续按旧 index 删除就可能删错

因此 Teacher 使用：

back-to-front deletion

维护 Queue Index 的正确性。

Student 得到了三个 Retrieved Teacher Demonstrations：

Example 47
Example 55
Example 58

其中某个 Example 展示了：

如何获取 Spotify Queue。

但是：

没有任何一个 Retrieved Example 展示如何正确删除 Queue 中的歌曲。

于是 Student 知道：

怎么查看 queue

却不知道：

如何执行关键 deletion operation

最终任务失败。

这正是作者所谓的：

Coverage Gap

28. Coverage 比单纯“有多少 Memory”更加重要

作者对 53 个失败任务进行分析，其中 48 个能够被归因到具体原因。

其中相当大的一部分与 Coverage Gap 有关，包括缺少：

  • 必要 API Usage；
  • Disambiguation Strategy；
  • Error Handling；
  • 关键操作模式。

因此论文得到一个非常值得 Agent Memory 领域关注的结论：

系统有没有存很多经验不是最重要的，真正关键的是：任务需要的关键行为是否被经验库覆盖，以及 Retrieval 能不能在正确时刻把它取出来。

换句话说：

Memory Size

并不直接等于：

Memory Utility

真正重要的是：

Coverage
×
Retrieval Quality
×
Task Relevance

29. 这和 Agent Memory 有什么关系？

虽然论文从 Inference-Time Distillation 的角度来描述问题，但如果从 Agent Memory 视角来看，它其实非常容易理解。

Teacher Database 本质上就是一个：

External Episodic Experience Memory。

其中保存：

Goal
Plan
Observation
Reasoning
Action

即过去完整的成功经验。

Student 面对新任务时：

Current Context
↓
Memory Retrieval
↓
Past Relevant Experience
↓
Context Augmentation
↓
Action

这和典型 Agent Memory Pipeline：

Store
↓
Retrieve
↓
Use

高度相似。

区别只在于：

Memory 并不是 Student 自己产生的，而是来自一个更强的 Teacher。

因此也可以把这篇论文理解成：

使用强模型产生高质量 Agent Memory，然后让廉价模型消费这些 Memory。

30. 它和 Self-Evolving Agent 又有什么区别？

Self-Evolving Agent 往往是：

Agent 做任务
↓
获得 Experience
↓
Experience 写入 Memory
↓
下一次任务继续使用
↓
Memory 不断增长

也就是：

Online Experience Accumulation。

而本文明确采用：

Teacher Demonstration Collection
↓
固定 Database
↓
Student Deployment

作者在实验中不会让这个数据库随着 Student 执行不断增长。

所以它不是严格意义上的 Online Self-Evolving Agent。

更准确地说：

它研究的是如何利用一个预先构建的高质量经验库，在不训练 Student 的情况下实现 Teacher-to-Student 能力迁移。

不过论文自己也指出：

未来可以根据发现的 Coverage Gap：

发现缺失能力
↓
补充对应 Teacher Demonstration
↓
更新 Database

如果把这一环真正自动化：

执行
↓
发现 Coverage Gap
↓
主动收集新 Teacher Experience
↓
更新 Memory
↓
继续执行

那么整个框架就会非常自然地向 Self-Evolving Agent Memory 演化。

31. 为什么这个方法有效？

把整篇论文压缩之后，我认为主要有三个原因。

31.1 小模型并不是“什么都不会”

GPT-4.1-mini 本身具有：

  • Reasoning；
  • Tool Use；
  • Instruction Following；
  • In-Context Learning。

它缺少的很多时候只是：

当前任务究竟应该采用什么行为模式。

Teacher Demonstration 恰好补充了这个信息。

31.2 相似 Agent Task 存在大量可复用结构

论文选择 ALFWorld 和 AppWorld，也是因为这些任务之间存在重复的结构。

例如：

获取数据
↓
过滤
↓
修改状态
↓
验证

或者某些 API Usage Pattern 会反复出现。

因此：

Teacher 在少量任务中学到/展现出来的行为，可以迁移到大量类似任务。

如果所有任务彼此完全无关，那么 Retrieval Demonstrations 的价值就会显著下降。

31.3 Cascade 把 Teacher Cost 用在最关键的位置

Student 并不需要在整个 Episode 中完全取代 Teacher。

真正需要做到的是：

Easy Steps → Student

Hard / Uncertain Steps → Teacher

因此 Teacher 从：

主执行模型

变成：

Fallback Expert

这使得昂贵模型调用从：

Every Step

下降到：

Only When Needed

最终才形成明显的 Cost Reduction。

32. 这篇论文真正的新意在哪里？

需要特别强调：

Dynamic In-Context Learning、RAG、Self-Consistency、Model Cascade 本身都不是这篇论文提出的新技术。

论文自己也非常明确地把它们称为 established inference-time techniques。

所以创新点并不是：

发明了一种全新的 Agent Architecture。

而是：

作者把几个已有组件组合成一种非常实用的“Training-Free Teacher-Student Agent Deployment”范式，并系统研究了它的 Cost-Accuracy Tradeoff。

也就是说，论文最重要的价值更偏向：

系统设计 + 实证分析 + 工程 Deployment Perspective

而不是某个全新的基础算法。

33. “Inference-Time Distillation”这个名字需要谨慎理解

严格来说，我认为这里的 Distillation 应该打一个引号。

因为传统 Distillation 意味着：

Teacher Knowledge
↓
Optimization
↓
Student Parameters 改变

本文实际上：

Teacher Knowledge
↓
External DB
↓
Context
↓
Student Parameters 完全不变

所以它实际上更加接近：

Teacher-generated RAG
+
Dynamic Few-shot ICL
+
Model Cascade

作者把它称为 Distillation，是因为最终效果仍然是：

让廉价 Student 模仿并复用昂贵 Teacher 的 Reasoning / Behavior。

只是能力迁移的位置从：

Weights

变成了：

Context

34. 这种方法相比 Fine-tuning 的优势

最大的优势并不一定是最终 Accuracy。

而是：

Agility

假设你今天修改了 Agent：

增加一个 Tool
↓
修改 Action Space
↓
修改 Workflow

Fine-tuning 路线可能意味着：

重新准备 Training Data
↓
重新训练
↓
重新测试

Inference-Time Distillation 则可以：

Teacher 跑一批新任务
↓
生成新的 Demonstrations
↓
放进 DB
↓
Student 马上使用

不需要改变 Student 权重。

所以特别适合：

  • 快速变化的 Agent 产品；
  • 大规模 Batch Processing；
  • 临时任务；
  • Workflow 经常变化的业务系统；
  • 不方便自己训练模型的 API Model 场景。

35. 论文的局限

这篇论文虽然结果不错，但有几个前提不能忽略。

35.1 Teacher Demonstration 并不是免费的

主实验 Cost 主要统计的是：

Test-time inference cost。

Teacher 前期产生 Demonstration 的成本没有直接计入每一个测试 Episode 的主指标，而是假设：

$$|T_{test}| \gg |T_{demo}|$$

这样前期成本可以被大量任务摊薄。

例如 ALFWorld：

Demonstration Cost ≈ $29.50

按照论文的计算，大约执行：

843 episodes

之后，累计推理节省才覆盖前期 Teacher Demonstration Cost。

所以：

它适合大规模重复执行，而不一定适合只执行几十个任务的场景。

35.2 方法高度依赖 Demonstration Coverage

Spotify 案例已经非常清楚：

DB 里没有关键行为
↓
Retrieve 不出来
↓
Student 不会

所以其能力上限强烈依赖：

Teacher DB 到底覆盖了多少 Task Pattern

这也是为什么 AppWorld 上仍然只有：

0.66

而 Teacher 是：

0.83

复杂任务越多，长尾行为越丰富，Coverage 越难做完整。

35.3 Self-Consistency 不代表 Correctness

三个 Sample：

A
A
A

只能说明：

Student 很一致。

却不能证明：

A 一定正确。

模型完全可能：

非常自信地错三次。

所以 Self-Consistency 本质上只是一个低成本 Confidence Proxy，而不是可靠的 Correctness Verifier。

35.4 Student Sampling 本身也有成本

每一步需要：

N = 3

次 Student Sampling。

因此 Cascade 并不是：

1 次 Student
vs
1 次 Teacher

而是：

3 次廉价 Student
vs
必要时 1 次昂贵 Teacher

之所以划算，是因为论文中的 Student 单价远低于 Teacher，而且 Agent Cost 中 Input Token 占据很大比例。

如果 Teacher 与 Student 的价格差距没有那么大，收益也会改变。

35.5 论文中的 Cost 与具体 API Pricing 有关

论文使用的是当时的 API Price。

所以：

2.5×
3.5×
$0.059
$0.024

这些数字不是一种永恒不变的算法属性。

模型价格发生变化之后：

Cost Pareto Frontier 也会变化。

真正稳定的结论应该是：

Teacher / Student 的价格差越大，并且 Student 能够通过 Retrieval 获得越强的能力补偿，这种方法越有价值。

36. 一个值得关注的实验：任务难度越高，Student 与 Teacher 差距越大

AppWorld 按难度分为三档。

Difficulty Teacher Student IC + Cascade Student ZS
1 0.96 0.91 0.51
2 0.85 0.70 0.29
3 0.71 0.43 0.06

可以明显看到：

简单任务：

Teacher 0.96
Student 0.91

已经非常接近。

但困难任务：

Teacher 0.71
Student 0.43

差距明显扩大。

这说明：

In-Context Distillation 更擅长把 Teacher 的可复用行为模式迁移给 Student，但并不能完全弥补基础模型本身在复杂 Planning / Reasoning 上的能力差距。

37. 如果提前知道任务难度，还可以进一步 Routing

作者又做了一个额外实验。

如果我们提前知道：

Difficulty 1 / 2
→ Student IC + Cascade

Difficulty 3
→ Teacher

那么 AppWorld 可以达到：

Accuracy ≈ 0.78

约恢复 Teacher：

94%

的 Accuracy，同时仍节省：

29%

左右的成本。

这说明 Self-Consistency 并不是唯一的 Router Signal。

在真实业务中完全可以组合：

Task Type
Task Difficulty
Historical Success Rate
Self-Consistency
Rule-based Risk Level

共同决定：

Student or Teacher

这也是一个非常实用的工程方向。

38. 从 Agent 系统设计角度如何理解这篇论文？

如果不使用论文里的术语，可以把整个系统理解成一个非常简单的三级结构：

        High-quality Experience
                ↓
          Teacher Memory
                ↓
         ┌──────────────┐
         │    Student   │
         └──────┬───────┘
                ↓
          Confidence Gate
          ┌─────┴─────┐
          ↓           ↓
       Confident   Uncertain
          ↓           ↓
       Student      Teacher

这里发生了一个有趣的角色变化：

Teacher 不再承担所有推理。

Teacher 的作用变成了两个：

1. Experience Generator
2. Fallback Expert

Student 则承担：

Cheap Default Executor

这实际上是一种非常典型的：

昂贵模型负责提供知识和兜底，廉价模型负责规模化执行。

39. 我认为这篇论文最值得记住的三个点

第一：Distillation 不一定非要修改参数

传统思路：

Knowledge Transfer
=
Training

这篇论文提醒我们：

Knowledge Transfer
=
Context

同样可以实现。

也就是说：

Model Weights 不是存储“学到的能力”的唯一位置，External Memory + Context 本身也可以承担一部分能力迁移。

第二：Agent Memory 的关键不是“存”，而是 Coverage + Retrieval

存了几百条经验并不意味着 Agent 会做所有任务。

真正重要的是：

当前任务需要的关键行为
↓
是否存在于 Memory
↓
是否能被 Retrieve
↓
是否能被 Student 正确利用

所以 Agent Memory 后续一个很值得研究的问题其实是：

如何主动发现 Experience Coverage Gap，并针对性补齐 Memory。

这比单纯继续设计新的 CRUD Logic 更有意义。

第三：最强模型未必需要执行整个任务

一个 Agent Episode 可能有 20 步。

真正困难的可能只有其中：

2~3 步

那么完全没必要：

20 Steps 全部 Claude Sonnet

可以变成：

17 Steps → Mini Model
3 Steps → Frontier Model

因此未来 Agent Cost Optimization 一个很自然的方向就是：

Step-Level Model Routing

而不是传统的：

整个 Task 选择一个 Model。

40. 总结

这篇论文提出的 Inference-Time Distillation 本身并不是一个复杂的新算法。

它的核心只有两个模块：

Dynamic In-Context Learning
+
Self-Consistency Cascade

首先：

Teacher
↓
少量高质量 Trajectories
↓
Vector Database

然后：

Student 遇到新任务
↓
动态检索 Teacher Experience
↓
通过 Context 模仿 Teacher

最后：

Student 多次 Sampling
↓
一致
→ Student 执行

不一致
→ Teacher 兜底

最终实现：

大部分任务：
Cheap Student

关键困难步骤：
Expensive Teacher

论文在 ALFWorld 上以大约 2.5× 更低的成本达到甚至超过 Teacher Accuracy；在更困难的 AppWorld 上，则以大约 3.5× 更低的成本恢复约 79% 的 Teacher Accuracy。

但我认为，比具体实验数字更重要的是这篇论文背后的一个思想：

与其试图把所有能力永久训练进一个廉价模型，不如让廉价模型拥有访问高质量外部经验的能力，并在真正需要的时候调用强模型。

从这个角度看，Inference-Time Distillation 实际上把：

Knowledge Distillation
RAG
Agent Memory
Model Routing

这几个原本相对独立的方向连接了起来。

如果进一步让系统能够自动：

发现失败
↓
识别 Coverage Gap
↓
调用 Teacher 生成针对性 Experience
↓
写入 Memory
↓
未来自动复用

那么它就会从本文这种静态 Teacher Experience Database，自然发展成一个真正具有：

Experience Acquisition → Memory Update → Capability Improvement

闭环的 Self-Evolving Agent 系统。

posted @ 2026-08-18 21:45  YourF4u1t  阅读(6)  评论(0)    收藏  举报