Agent 自己交互过的经验，怎么"蒸馏"成永久技能——arXiv 2607.21051 给了一条新路
- 关联论文：2607.21051
你有没有这种感觉？
你做了一个 AI Agent 帮你跑代码、debug、修 bug。它在对话里"学到"了——你提醒它"别忘了检查依赖冲突"、它下次确实改进了。
但你一刷新会话、或者换个任务——它又"忘了"。你要重新教一遍。
这种"学到的东西只在当前对话里有效，一出 Context 就归零"的现象，是 2026 年 AI Agent 商业化路上最让人抓狂的体验之一。
更扎心的是——你想让 Agent 真的"记住"这些经验，传统做法是两种都不理想：
① 在已有日志上直接 SFT → 效果几乎为零，只保留 3.8% 的增益；
② 用 RL 让 Agent 自己探索 → 需要海量环境样本，SWE-Bench 类任务动辄几千次交互，成本爆炸。
arXiv:2607.21051（Sample-Efficient Learning from Agent Experience）给出了一条中间路线——Experience Distillation（经验蒸馏）：
Agent 已经交互过的历史（无需再调用环境），通过「hindsight 重标记」策略蒸馏进模型权重——在 749 个 SWE-Bench 任务和 6 个文字冒险游戏中保留 ≥64.8% 的 In-Context Learning 增益，对比 RL 基准用 9.6× 更少的环境样本达到同等性能。
翻译成大白话：Agent 自己趟过的坑、被你纠正过的反馈，能在不消耗额外环境预算的情况下，"焊进"模型权重——下次开局就自带这些经验。
这件事对做 Coding Agent、Agent 平台、AI Infra、关注训练成本的团队都值得关注——因为它重新定义了"怎么让 Agent 持续学习"。
为什么这件事和每个做 Agent 的人有关
先说清楚一个反常识的事实——
Agent 的 In-Context Learning（ICL）是非常强的。给它一段历史，它能从历史里"临时学到"东西。
但问题是——这种"学到"是临时的。历史一退出 Context，增益立即消失。
这件事的真实影响：
- Coding Agent（Cursor、Devin、Claude Code 这类）：用户每次新开对话都要"重新教"代码风格、项目约定、bug 历史——用户体验反复撕裂；
- 企业 RAG Agent：客服 Agent 跟某个客户聊过的事、修正过的回复——Session 结束全清零，下次该用户来咨询，又从零开始；
- 多轮工作流 Agent：复杂流程跑了 50 步学到"哪些 API 容易超时"、"哪些参数组合有效"——只要任务结束，这些全丢。
于是大家开始想：能不能让 Agent 真的"记住"——不是存在 Context 里，而是把经验"焊"到模型权重？
过去的两条路都让团队心累：
路线 A：直接 SFT（把交互日志当成训练数据直接微调）
→ 结果只有 3.8% 增益（论文数字）
→ 几乎等于白做
→ 根因：模型学的是"输入→输出"的表面映射，学不到"为什么这个历史背景下输出是对的"
路线 B：用 RL（PPO/GRPO）让 Agent 自己探索
→ 需要海量环境样本
→ SWE-Bench 类任务成本爆炸
→ 论文对比：用了 9.6 倍的环境样本才达到 ED 的同等效果
arXiv:2607.21051 给出的第三条路：Experience Distillation——Agent 已经趟过的历史，不需要再调用环境，通过 hindsight 重标记把"上下文依赖的决策"变成"独立的行为映射"，然后做 SFT——一次蒸馏、长效保留。
一句话核心：Experience Distillation = 重标记 + SFT
论文的核心思路可以一句话讲清楚：
"让 Agent 把它已经交互过的历史，重新标记成'独立可学'的训练样本，再蒸馏进模型权重——保留大部分 In-Context Learning 的增益，且不需要额外环境交互。"
完整 pipeline 长这样：
Agent 与环境交互 → 收集轨迹（Interaction History）
↓
对每条轨迹做"经验重标记"（Hindsight Relabeling）
↓
用重标记后的轨迹做监督微调（SFT）
↓
得到蒸馏后模型：在无历史 Context 时仍保持高性能 ✅
关键技巧是 Hindsight Relabeling（事后重标记）——这条思路借鉴了 Hindsight Experience Replay（HER，2017）。
怎么理解 HER 的精髓？
举个例子：
Agent 接到任务"走到房间 A"。它尝试了但走到了房间 B。在原始轨迹里，这条经验是"失败"——没达成 A。
但事后看来，它确实走到了 B——所以可以重新标注为"走到房间 B"的任务，然后从中提取"走到 B 的过程中哪些步骤是对的"。
一条"失败"轨迹瞬间变成"成功"训练样本。
这就是 Experience Distillation 的核心魔法：用实际结果重新标注决策点，把"上下文依赖的序列决策"变成"独立的 (state → optimal_action) 映射"——直接 SFT 在原始轨迹上失效，是因为原始轨迹里的每一步都依赖"当时已经发生的上下文"；重标记打破了这个依赖。
关键实验数据（最扎心的一组对比）
论文在两个差异极大的领域做了验证：
| 领域 | 任务数 | 评估 |
|---|---|---|
| 软件工程（SWE-Bench 精选） | 749 个 | 代码生成 / 调试 |
| 文字冒险游戏 | 6 个 | 探索 / 推理 |
核心数字对比：
| 方法 | 保留 ICL 增益比例 | 环境样本需求 |
|---|---|---|
| In-Context Learning（原始） | 100% | 0（但需持续 Context） |
| Direct SFT on Experience | 3.8% | 0 |
| Classical RL（PPO/A2C） | 基线 | 9.6×（本工作用 1/9.6 达到同等） |
| Experience Distillation | ≥ 64.8% | 0 ✅ |
几个关键洞察：
- 3.8% vs 64.8% 的对比，扎心证明了"在 Agent 日志上直接 SFT 就是在浪费算力"——必须先有重标记 pipeline；
- 64.8% 是下限保证——某些任务可能远高于此，但生产环境别假设都这么高；
- 9.6× 样本效率——这条结论对所有关心训练成本的团队都直接有用：ED 帮你用 RL 的 1/9.6 预算达到同等性能。
为什么这件事重要
1. 给"持续学习"问题一个新的解法
过去做 Agent 持续学习的思路只有两条：ICL（临时）+ RL（贵）。ED 在中间找了一个既临时又便宜的甜蜜点——用已有轨迹 + 重标记 + SFT，把经验"焊"进权重。
2. 重新定义了"训练数据"
Agent 自身的交互历史就是宝贵的训练数据——只要你有结构化轨迹日志 + 重标记策略。
这条结论对所有做 Agent 平台的团队都直接有用——你的 trajectory log 是金矿，别让它白存着。
3. 跨领域通用
论文同时验证了 SWE 工程和文字冒险两个差异极大的领域——说明 ED 本质上不依赖特定领域的 inductive bias，适合作为"通用 Agent 持续学习"的基础设施。
4. 与 RL 互补，不是取代
最优路径通常是：ED 先固化经验（样本高效），再小规模 RL 探索（探索成本高但必要）——这正好对应论文"9.6× 样本效率"的定位。
5. 论文本身定义了一个新研究子领域
"Experience Distillation" 这个命名有望成为新的研究方向——「怎么把 ICL 的增益持久化到权重」这个问题，从此有了正式的名字。
三处落地风险别踩
风险 1：Relabeling 策略细节不足
论文借鉴了 HER 的思路，但具体 relabel 策略的细节"较简略"——读者无法直接复现。从已知 HER 方法参考：
- 标准 HER：把失败轨迹的目标替换为实际到达状态；
- 多目标 HER：对同一轨迹用多个目标重标记；
- 逆动力学 relabel：用逆动力学模型估算中间状态的隐含意图。
工程建议：复现时从标准 HER 起步，再结合领域特点调优。
风险 2：64.8% 是"下限"，分布未披露
论文给的是"至少 64.8%"——意味着某些任务可能远低于此，但原文未提供分布细节。生产环境建议：用自己的业务场景做内部基准，不要直接信任 SWE-Bench 数字。
风险 3：精选 SWE-Bench ≠ 真实工程
749 个任务是 SWE-Bench 的 精选子集（curated subset），不是 SWE-Bench Full。这意味着：
- 精选集偏"容易成功"——真实工程的失败模式（版本冲突、隐藏配置、非确定性行为）可能被低估；
- 蒸馏效果在更难的任务上可能显著更低；
- 生产部署前必须用自己的真实业务日志验证。
一句话总结
arXiv 2607.21051（Experience Distillation）给 Agent 持续学习找到了一条「中间路线」——Agent 自己趟过的经验通过 hindsight 重标记 + SFT 蒸馏进模型权重，保留 ≥64.8% 的 In-Context Learning 增益，且不需要额外环境交互——对比 RL 基准用 9.6× 更少的样本达到同等性能。
这件事的真正含义：「让 Agent 真正'记住'经验」这个困扰所有做 Agent 团队的问题，第一次有了既不贵又能落地的解法。
下次你看到有人说"我们 Agent 越用越聪明、但每次重启都从零开始"时，你可以甩一句：
「Trajectory log 存了吗？Hindsight Relabeling 做了吗？ED pipeline 跑起来了吗？——直接 SFT 在日志上只有 3.8% 增益，重标记才是关键。」
📎 论文 ID：2607.21051
延伸阅读 - 论文：arXiv 2607.21051（Sample-Efficient Learning from Agent Experience） - 主分类：Agent 持续学习 · LLM SFT · RL × LLM 交叉 - 关键贡献：Experience Distillation 命名 + Hindsight Relabeling 借鉴 HER + ≥64.8% ICL 增益保留 + 9.6× 样本效率 - 同方向工作：Reflexion / Self-Refine / LATS（推理时改进）、HER（Hindsight Experience Replay）、ReAct（轨迹格式）、SWE-Bench（评测）
三个标题变体
- Agent 自己交互过的经验，怎么"蒸馏"成永久技能——arXiv 2607.21051 给了一条新路
- 别在 Agent 日志上直接 SFT 了——只会保留 3.8% 增益，arXiv 2607.21051 用重标记把数字提到 64.8%
- In-Context Learning 出了 Context 就归零？arXiv 2607.21051 用 9.6× 更少样本把经验焊进权重
小红书风格卡片文案（可直接发布）
🤖 你的 AI Agent 越用越聪明，但一刷新会话就归零？ 😭
arXiv 2607.21051（Sample-Efficient Learning from Agent Experience）直接给解法 ✨
🎯 先说一个反常识的事实：
In-Context Learning（ICL）非常强——Agent 在对话里能"临时学到"东西 但这种学到是临时的 ⏰ 历史一退出 Context，增益立刻归零 💨
这就是为什么你的 Agent： ❌ Coding Agent 每次新对话要重新教代码风格 ❌ 客服 Agent 下次见同客户从零开始 ❌ 工作流 Agent 跑过的"踩坑经验"全丢
🔍 过去两条路都让人心累：
路线 A：直接 SFT（Agent 日志当成训练数据微调）
→ 只保留 3.8% 增益（几乎白做）😱
→ 根因：模型学的是"输入→输出"表面映射
学不到"为什么这个历史背景下输出是对的"
路线 B：用 RL（PPO/GRPO）让 Agent 自己探索
→ 需要海量环境样本 💸
→ SWE-Bench 类任务成本爆炸 💣
→ 论文对比：用了 9.6 倍样本才达到 ED 同等效果
arXiv:2607.21051 给出第三条路： Experience Distillation ✨
🧠 一句话核心：
让 Agent 把已交互过的历史，重新标记成"独立可学"的训练样本，再蒸馏进模型权重——保留大部分 ICL 增益，且不需要额外环境交互 🎯
完整 Pipeline：
Agent 与环境交互 → 收集轨迹
↓
Hindsight Relabeling（事后重标记）
↓
用重标记后的轨迹做 SFT
↓
蒸馏后模型：无历史 Context 仍保持高性能 ✅
💡 Hindsight Relabeling 的精髓：
举个例子 🌰
Agent 接到任务"走到房间 A" 它尝试了但走到了房间 B 在原始轨迹里，这是"失败" ❌ 但事后看，它确实到了 B → 可以重新标注为"走到房间 B"的任务 → 一条"失败"瞬间变"成功"训练样本 ✨
这就是核心魔法： 用实际结果重新标注决策点 把"上下文依赖的序列决策"变成"独立的 (state → optimal_action) 映射" 🪄
📊 关键实验数据（扎心对比）：
| 方法 | 保留 ICL 增益 | 环境样本需求 |
|---|---|---|
| ICL（原始） | 100% | 0（但需持续 Context） |
| Direct SFT on Experience | 3.8% | 0 |
| Classical RL（PPO/A2C） | 基线 | 9.6× |
| Experience Distillation | ≥ 64.8% ✅ | 0 ✅ |
⚡ 关键洞察：
1️⃣ 3.8% vs 64.8% 扎心证明："在 Agent 日志上直接 SFT 就是在浪费算力" 💸 必须先有重标记 pipeline
2️⃣ 64.8% 是下限 ——某些任务可能远高于此，但生产别假设都这么高 ⚠️
3️⃣ 9.6× 样本效率 —— 对所有关心训练成本的团队都直接有用 💰
🔑 三大关键设计：
1️⃣ Hindsight Relabeling（事后重标记） 借鉴 HER（Hindsight Experience Replay, 2017） ✅ 标准 HER：失败轨迹的目标换成实际到达状态 ✅ 多目标 HER：同一轨迹多目标重标记 ✅ 逆动力学 relabel：估算中间状态隐含意图 工程建议：复现从标准 HER 起步
2️⃣ 跨领域通用 ✅ 749 个 SWE-Bench 任务（精选） ✅ 6 个文字冒险游戏 ✅ 两个差异极大领域都拿到 ≥64.8% ✅ 不依赖领域-specific 的 inductive bias
3️⃣ 与 RL 互补，不是取代 最优路径：ED 先固化经验（样本高效） 🧠 再小规模 RL 探索（探索成本高但必要） 🔍 = ED 是「冷启动 + 经验固化」，RL 是「性能突破」 ⚡
⚠️ 三个踩坑点：
1️⃣ Relabeling 策略细节不足 —— 论文借鉴 HER 但具体策略"较简略"，读者无法直接复现。复现从标准 HER 起步
2️⃣ 64.8% 是下限，分布未披露 —— 某些任务可能远低于此。用自己业务日志做内部基准，别只信 SWE-Bench
3️⃣ 精选 SWE-Bench ≠ 真实工程 —— 749 个是精选子集，偏"容易成功"。真实工程的失败模式（版本冲突、隐藏配置）可能被低估。生产部署前必须用自己的真实业务日志验证
🛠️ 生产部署 Checklist：
- [ ] Relabeling 策略设计与实现 —— 最大的工程不确定性
- [ ] 轨迹日志基础设施 —— 状态/动作/结果的结构化存储，是 relabeling 前提
- [ ] SFT 训练 pipeline —— 与普通 SFT 相同，但数据换 relabeled 轨迹
- [ ] 内部评测基准 —— 用自己业务场景构建，不能只靠 SWE-Bench
- [ ] 蒸馏频率 —— 太频繁成本高，太稀疏跟不上任务演化
- [ ] 模型版本管理 —— ED 后产生新权重，需 A/B 对比测试
- [ ] 灾难性遗忘风险 —— 蒸馏可能让模型在某些场景退化，保留原模型作 fallback
💡 一句话总结：
2607.21051 不是又一个 SFT/RF 工作—— 它给 Agent 持续学习找到一条中间路线 Agent 自己趟过的经验 → 重标记 → 蒸馏进权重 保留 ≥64.8% ICL 增益、9.6× 样本效率、不需要额外环境交互 🎯
这件事的真正含义 ✨
「让 Agent 真正'记住'经验」这个困扰所有做 Agent 团队的问题 第一次有了既不贵又能落地的解法 💎
下次听到"Agent 越用越聪明、但每次重启从零"时 🗣️
「Trajectory log 存了吗？Hindsight Relabeling 做了吗？ED pipeline 跑起来了吗？——直接 SFT 只有 3.8% 增益，重标记才是关键。」
📎 论文 ID：2607.21051
💬 评论区聊聊：你做 Agent 时遇到过「重启就归零」的痛吗？有没有试过把交互历史用起来？👇