Agent Memory Distillation：把大模型 Agent 的"三段记忆"蒸馏给小模型

关联论文：2608.07169
作者：flyP
更新：2026-08-11
审校：Jay · 2026-08-11

一句话结论

AMD（Agent Memory Distillation）是一个免训练框架：让小语言模型（4B-8B）通过"工作流—子任务—函数调用"三层结构化记忆，蒸馏大教师 Agent（GPT-5-mini 作为示例教师）的成功轨迹，在 AppWorld / BFCL V3 / ToolSandbox 三个工具调用基准上分别取得 +27.2%p、+11.2%p、+3.4%p 平均准确率提升。

解决的真问题

小模型做 Agent 有两个先天短板：

成功轨迹稀缺：4B-8B 模型在工具调用 / 多轮推理任务上自己跑出来的成功率低，无法靠"自我试错 + 经验积累"攒出有意义的 memory。
直接蒸馏行为成本高：传统 knowledge distillation 让学生拟合教师的 token 输出，会把教师的"长思考链"也压进小模型，推理成本和延迟反向恶化。

AMD 的解法是：只蒸馏结构化经验，不蒸馏行为。教师跑完任务后，把成功的轨迹拆成 Workflow（任务级策略）/ Subtask（中间粒度的具体行为示例）/ Function（每个工具的调用约定和踩坑点）三类记忆，按需注入学生。

核心方法

三层记忆结构

层级	内容	注入时机	作用
Workflow memory	任务级策略（先做什么 → 后做什么 → 何时分支）	任务开始前主动注入	给学生"地图"
Subtask memory	子任务粒度的成功示例（中等粒度）	任务开始前主动注入	给学生"模板"
Function memory	单个工具的调用约定、常见踩坑	工具调用出错时被动触发	给学生"踩坑预警"

主动 vs 被动是关键设计：Workflow + Subtask 在任务开始前一次性 push（避免上下文累积），Function memory 在错误触发时按需检索（避免正常任务被冗余提示稀释）。

蒸馏流程伪代码

def distill(teacher_trajectories: list[Traj]):
    workflows = []   # task-level
    subtasks  = []   # intermediate
    functions = {}   # tool-level

    for traj in teacher_trajectories:
        if not traj.success: continue
        workflow = abstract_to_workflow(traj)        # LLM 摘要
        workflows.append(workflow)
        for step in traj.steps:
            subtasks.append(extract_subtask_example(step))
            for call in step.tool_calls:
                functions.setdefault(call.tool, []).append(
                    extract_calling_convention(call, step.error if step.failed else None)
                )
    return MemoryBank(workflows, subtasks, functions)

def student_run(task, memory: MemoryBank):
    # 任务开始前
    prompt = task.prompt + "\n" + render(memory.workflows_for(task)) \
                              + "\n" + render(memory.subtasks_for(task))
    while not task.done:
        action = student.next_action(prompt)
        result = env.step(action)
        if result.error:
            # 被动检索
            prompt += "\n" + render(memory.functions_for(action.tool, result.error))

伪代码里的两个常被忽略的细节：

Workflow 的检索靠任务相似度：意味着记忆库里必须存一份任务级别的 embedding 索引，distill 阶段就要为每个 workflow 算 embedding。
Function memory 的写入条件是"错误发生过"：所以踩坑库天然只覆盖"老师也犯过错"的工具调用——对从未踩坑的工具，没有预警条目。

关键设计点

Training-free：记忆是文本/结构化条目，不是模型权重；切换学生模型无需重训；部署只需文本存储 + 相似度检索。
教师-学生解耦：教师的成功轨迹来源可以是任意大模型 Agent（论文用 GPT-5-mini），学生侧可以是任意能跑 tool-use 的小模型（论文评估 4B-8B 四个）。
记忆检索粒度区分：Workflow 按任务相似度，Function 按（tool, error_type）键检索；这是论文主动 push vs 被动 pull 设计的数据结构基础。
主动注入 vs 被动触发的不对称：Workflow + Subtask 在任务开始一次性 push，避免中途上下文爆炸；Function memory 只在错误发生时检索，避免正常路径被冗余提示稀释——这是 prompt 长度与准确率的平衡点。

为什么"主动 push + 被动 pull"非对称有效

直觉上"全部 push"会让学生最强，但论文用消融证明：

全部 push 会让 prompt 长度爆炸，小模型上下文窗口首先触顶；
全部 pull 会让每个决策点都要做一次检索，引入额外延迟且让学生在"无错误"路径上也负担检索开销；
折中方案是：高层级（Workflow）信息密度高、调用频次低 → push；低层级（Function）只在异常路径上需要 → pull。这一非对称是 AMD 相对此前工作的关键工程创新。

关键实验与数据

学生模型：4 个 4B-8B 参数规模的小模型。 教师模型：GPT-5-mini。 基准与提升（平均准确率）：

基准	AMD 增益	含义
AppWorld	+27.2%p	多应用综合任务
BFCL V3	+11.2%p	Berkeley 函数调用排行榜
ToolSandbox	+3.4%p	沙箱化工具调用

消融结论：

Subtask memory 贡献最大（论文明确指出）。
教师效果同时取决于教师能力 + 学生兼容性，并非"教师越强越好"。
4B 规模学生收益最显著——本来 baseline 越低，提升空间越大。

数字均来自 arXiv abstract 与 TLDR，已 fetch 验证一致（v1 提交时间 2026-08-07 12:43 UTC，第一作者 Kangsan Kim）。

各基准的能力侧重

AppWorld：跨多个 mock 应用的端到端任务（文件 + 日历 + 邮件 + 数据库等），强调整体工作流编排能力；AMD 在该基准 +27.2%p 是最大单点收益，说明 Workflow memory 对长链路任务最关键。
BFCL V3（Berkeley Function Calling Leaderboard V3）：标准化函数调用基准，覆盖嵌套调用、多函数组合、参数类型混淆；AMD +11.2%p 表明 Function memory 的"踩坑预警"对函数边界模糊场景特别有效。
ToolSandbox：沙箱化工具环境，强调整合多步工具调用的稳定性；+3.4%p 较小，提示 AMD 对"工具调用本身"提升有限，主要价值在"调用前的策略"。

亮点与局限

亮点

机制 + 工程双轨：机制上把 memory 拆成"主动 push / 被动 pull"两路注入；工程上 training-free + 三个开源基准 + 多个学生模型，规模与可信度齐备。
+27.2%p AppWorld 是该规模学生的新水位：4B-8B 模型在 AppWorld 上原本远落后闭源大模型，AMD 把差距显著压缩。
Subtask > Workflow > Function 的消融排序为后续工作提供了清晰的优先级——未来想再压榨，可以重点优化 Subtask 提取质量。
Training-free 带来部署灵活性：不需要 GPU 训练集群，只需文本记忆库 + 检索；适合资源受限的本地 Agent。

局限

教师依赖性："教师效果取决于学生兼容性"是经验结论，论文未给出兼容性的形式化判据——换教师/换学生要重新做兼容性测试。⚠️ 原文未明确兼容性公式。
记忆库的更新与剪枝策略：teacher 持续产生轨迹时，Workflow/Subtask 数量会爆炸；论文未给出剪枝或过期机制。⚠️ 原文未明确。
教师-学生任务分布偏移：当学生面对与 teacher 训练分布差异大的任务时，Workflow/Subtask 的命中率会下降；论文未量化跨域泛化能力。⚠️ 原文未明确。
AMD 的延迟开销：注入 Workflow + Subtask 会显著拉长 prompt，对小模型的上下文窗口也是负担；论文未给出 token 开销与准确率之间的 Pareto 曲线。⚠️ 原文未明确。
基准规模有限：三个基准均为工具调用，没有覆盖长链路多轮对话或带状态恢复的复杂环境；外部有效性待验证。

对工程落地的启发

小模型 Agent 的现实路径：与其硬上 70B+ 大模型，不如蒸馏"结构化记忆"+ 4B-8B 学生——成本/延迟可控，且训练门槛为零。AMD 给出的 +27.2%p AppWorld 数据让这条路第一次具备可量化的说服力。
记忆分层是普适模式：任何"Agent-as-a-Service"产品都建议把记忆分成"任务级—子任务级—工具级"三层，注入时机不同。即便不做蒸馏，这种分层本身就能让 memory 系统的可观测性显著提升。
踩坑预警库：Function memory 本质是"工具错误码 → 历史踩坑示例"映射，适合做成独立中间件，所有 Agent 共享。落地形态可以是 Redis / 向量库 + per-tool keyspace。
教师版本管理：记忆库带版本号（与教师模型版本绑定），切换教师时同步重建记忆——避免"老教师的经验喂新学生"的隐性错误。建议记忆元数据里强制带 teacher_model_id + teacher_version。
监控提示长度：注入记忆虽免费，但会显著增加 prompt tokens；建议监控 per-task 的 prompt 长度分布，超过阈值时降级到 Function-only；这是论文未覆盖的工程细节。
评估兼容性：在切换教师或学生前，先在 50-100 条 held-out 任务上做"教师 / 学生兼容性 pilot"——论文明确指出"教师效果取决于兼容性"，但没给判据，需要工程上自行补齐。

与同方向工作的关系

Self-RAG / Self-Refine：单模型"自我反思"流派，AMD 与之互补——AMD 借教师经验，单模型流派借自身轨迹。
Voyager / MineDojo 的 skill library：长期任务中累积"技能库"，与 AMD 的 Subtask memory 同构；差异在 AMD 是 offline 蒸馏，后者是 online 累积。
ReAct / Toolformer：把工具调用内化为模型能力，AMD 不动模型只动 prompt——部署成本低一个数量级，但上限受学生模型能力约束。
OpenAI Function Calling / Anthropic Tool Use 官方文档：标准化接口层；AMD 假设学生已具备工具调用底座。

适合谁读

小模型 Agent 团队：想在 4B-8B 规模跑出接近大模型工具调用能力的，AMD 是首选参考。
Agent 平台架构师：设计 memory schema 时，"主动 push / 被动 pull"分层是直接可借鉴的范式。
教育/客服类 RAG + Agent 团队：工具调用密集场景下，Function memory 的"踩坑预警"模式可直接落地。
做模型蒸馏 + Agent 部署的产品团队：AMD 的 training-free 路线比 LoRA / 全参数蒸馏便宜一个数量级，可作为产品 MVP 的首选实验。

一句话记忆口诀

「AMD = Workflow + Subtask（任务前 push） + Function（错误时 pull）；AppWorld +27.2%p 是它最强的单点证据。」

不确定处

教师-学生兼容性的形式化判据：⚠️ 原文未明确。
记忆库剪枝 / 过期机制：⚠️ 原文未明确。
跨域任务分布偏移的量化：⚠️ 原文未明确。
prompt 长度 vs 准确率 Pareto 曲线：⚠️ 原文未明确。
论文开源仓库 / 代码：⚠️ v1 abstract 未明确给出 GitHub 链接。

工程落地与核查（Jay）

事实核查结果

结论支撑：全文 5 处数字 claim 全部与 arXiv abstract 一致：+27.2%p / +11.2%p / +3.4%p AppWorld/BFCL/ToolSandbox，GPT-5-mini 教师，4B-8B 学生，Kangsan Kim 作者，提交时间 2026-08-07 ✅
存疑 1：「Subtask memory 贡献最大」——原论文 abstract 原文："Further analysis shows that Subtask memory contributes the largest gains" ✅ 有据可查
存疑 2：「教师-学生兼容性是经验结论，非形式化」——原论文同句有据 ⚠️ 原文未给公式
存疑 3：「BFCL V3 = Berkeley Function Calling Leaderboard V3」——原文未给出此缩写全称，为解读方推论（合理）✅
⚠️ 盲区：abstract_to_workflow / extract_subtask_example / extract_calling_convention 三个关键 LLM 调用在伪代码中黑盒——实际部署时每次 distill 都要对整条轨迹做 LLM 摘要，distill 成本未量化；生产部署需补 latency benchmark
⚠️ 未标注：论文目前 Under Review（"Under review" 在 abstract 的 Comments 字段），解读稿未注明论文尚未经同行评审——工程引用时应留意，重要决策前建议等待评审结果

实际系统怎么落地

最小可跑路径（概念验证级）：

# 1. 教师轨迹收集（无需改动教师 Agent）
teacher_traj = run_teacher(task, teacher_model="gpt-5-mini")
if teacher_traj.success:
    wf = llm_summarize(teacher_traj, mode="workflow")     # 每条轨迹 1 次 LLM call
    for step in teacher_traj.steps:
        st = llm_summarize(step, mode="subtask")           # 每步 1 次 LLM call
        for call in step.tool_calls:
            store(call.tool, call.convention, step.error)  # Function memory

# 2. 学生推理时注入
retrieved = vector_search(workflow_bank, query=task.embedding, top_k=3)
retrieved += vector_search(subtask_bank, query=task.embedding, top_k=5)
prompt = task.prompt + format(retrieved)
# 若 tool_call 报错，再查 Function memory

踩坑清单（基于伪代码黑盒分析）：

distill 成本被严重低估：每条成功轨迹需要 N+1 次 LLM 调用（N=步数）才能完成 extract，distill 1000 条轨迹 ≈ 1000+ 次 LLM call；教师越强步数越多，成本爆炸；若用 GPT-5-mini 做 distill，distill 本身成本可能远超学生推理节省
embedding 模型必须稳定：workflow 相似度检索依赖 embedding 模型一致性——训练集和推理集的 embedding 空间必须对齐；换 embedding 模型需重建全部索引
Function memory 冷启动问题：踩坑库只收录"老师犯过错"的调用；对新接入的工具或 teacher 从未踩坑的边界 case，Function memory 为空，学生遇到同样错误时 0 预警
记忆冲突未处理：同一个 task type 有多条 Workflow/Subtask 时，top-k 检索选哪条、多条是否拼接——伪代码未给出优先级或去重逻辑；生产环境可能需要 weighted merge
教师轨迹去重：真实 teacher 运行同一个任务可能产生多条相似轨迹；不去重直接进 bank 会导致 prompt 膨胀，检索 top-k 里出现高度相似条目浪费 context 窗口

关键配置参数（论文未公开默认值）

参数	说明	工程建议
workflow/top_k	每次任务检索多少条 workflow	建议 3-5；过多膨胀 prompt
subtask/top_k	每次任务检索多少条 subtask	建议 5-10
embedding_model	检索用的 embedding 模型	需与 distill 阶段同一模型
distill_llm	执行 abstract_to_workflow 的模型	建议与 teacher 同款，避免摘要质量差于原始轨迹
success_threshold	判断"成功轨迹"的标准	建议至少"工具调用全完成 + 任务目标达成"双闸

与现有系统的嫁接方案

嫁接 vLLM：vLLM serving 时在 prefill 之前插入 Workflow/Subtask retrieval 并拼接 prompt——需修改 vLLM 的 prompt 拼接入口
嫁接 LangChain / LlamaIndex：在 Agent 的 tool_call hook 里拦截错误，查 Function memory；工具定义在 Schema 层而非代码层，适合 Schema 稳定的客服/开发助手场景
嫁接 RAG pipeline：把 Workflow/Subtask bank 当作知识库，每次任务做 retrieval-augmented generation；适合 task_type 分布稳定的客服机器人