Agent Memory Distillation: Empowering Small LLM Agents with Hierarchical Teacher Memory 是 KAIST AI 在 8 月上旬放出的论文，也进入了 Hugging Face Daily Papers。论文摘要给出的核心问题很现实：记忆系统已经证明能增强 agent，但小模型往往无法自己产生足够多的成功轨迹，于是记忆库从一开始就缺优质燃料。
AMD 的解决方案是让大模型教师先干活，把成功经验整理成层级记忆，再交给小模型学生使用。这个方向对开发者非常重要，因为过去一年 agent 成本主要卡在两处：强模型工具调用太贵，小模型工具调用又不稳。AMD 试图在两者之间搭桥。
论文要解决的不是知识问答
很多人看到 memory 会先想到 RAG：把文档切块、向量化、检索、塞回上下文。但 agent memory 和知识库不是一回事。
工具调用任务的失败常常不是“不知道某个事实”，而是“不知道该按什么顺序做”。例如 AppWorld 这类任务里，agent 要理解用户目标、选择 API、维护中间状态、检查返回值、处理错误，再决定下一步。小模型可能知道每个 API 的说明，却仍然在第三步走错。
AMD 关注的是执行经验。教师 agent 不是给学生一本百科，而是给学生一套“这个类型的任务通常如何拆解、哪些工具先用、哪些状态必须保存、哪些错误要绕开”的层级记忆。
这对工程落地很有启发：如果你在构建客服 agent、数据表 agent、DevOps agent，本地小模型不一定需要更多参数，它可能需要一批高质量、可检索的任务轨迹。
层级记忆为什么重要
把整条成功轨迹直接塞给学生模型，问题很多。轨迹太长，噪声太多，具体样例过拟合，换个实体名就不一定能用。
层级记忆的价值是把经验分层：
任务级记忆：这类目标通常属于哪种任务模式
计划级记忆：应该分成哪些阶段
工具级记忆：每个阶段常用哪些 API 或工具
状态级记忆：哪些字段、ID、返回值必须保存
错误级记忆：常见失败是什么，如何恢复小模型在执行时可以先召回任务级模式，再召回相关步骤，最后按当前状态选择工具。这样上下文更短，也更符合小模型的能力边界。
AMD 的工程意义
论文报道里提到，小模型 agent 在 AppWorld 这类真实工具使用基准上可以获得明显提升，相关日报摘要甚至给出了 27.2 个百分点的提升说法。具体数值要以论文实验表为准，但方向已经足够明确：小模型 agent 的上限不只由权重决定，还由外部记忆质量决定。
这会改变团队部署策略。过去常见架构是：
所有复杂任务 -> 强模型 agent
所有简单任务 -> 小模型或规则系统AMD 启发的新架构更像：
强模型教师 -> 生成成功轨迹 -> 蒸馏为层级记忆
小模型学生 -> 检索记忆 -> 执行高频任务
强模型复核 -> 处理失败、低置信和新任务强模型不再只承担在线执行，还承担离线教学。小模型不再裸奔，而是站在教师经验上处理高频、低风险、模式稳定的任务。
一个最小实现方案
你可以先不做复杂算法，只做“轨迹到记忆”的管线。
第一步，保存教师成功轨迹：
{
"task_id": "appworld-calendar-018",
"goal": "把下周三下午的客户同步会改到下周五上午",
"success": true,
"steps": [
{
"thought": "需要先查找原会议",
"tool": "calendar.search_events",
"args": {"query": "客户同步会"}
},
{
"thought": "确认候选会议 ID 后修改时间",
"tool": "calendar.update_event",
"args": {"event_id": "evt_42", "start": "next Friday 10:00"}
}
],
"checks": ["确认 event_id", "确认 timezone", "确认更新后的 start 字段"]
}第二步，把轨迹压缩成记忆单元：
{
"memory_id": "calendar-reschedule-pattern",
"scope": "calendar.reschedule",
"task_pattern": "用户要求移动已有会议时间",
"plan": [
"先搜索会议而不是直接创建新会议",
"从搜索结果中确认唯一 event_id",
"调用更新接口后再次读取事件确认时间"
],
"tool_hints": [
"calendar.search_events",
"calendar.update_event",
"calendar.get_event"
],
"failure_guards": [
"如果候选会议超过一个，先向用户确认",
"如果涉及跨时区，必须显式记录 timezone"
]
}第三步，让学生模型执行前检索：
用户任务 -> 任务分类 -> 检索 memory.scope -> 注入相关 plan 和 guards -> 执行这里最重要的是不要把记忆写成冗长故事。小模型上下文预算更紧，记忆应该是短句、步骤和约束。
记忆筛选比记忆生成更重要
AMD 的教师记忆听起来像“把强模型经验都存起来”，但生产系统不能这么做。
建议只收录三类轨迹：
高置信成功：自动检查通过，人工抽样确认
典型失败恢复：先失败再修正，能提供有价值 guard
高频任务模式：未来会反复出现，值得压缩不要收录一次性任务、含敏感数据的原始轨迹、人工没有确认的复杂推断、靠运气成功的执行链。记忆库污染之后，小模型会稳定地犯同一种错，比偶发失败更难排查。
和微调怎么取舍
AMD 的吸引力在于不微调。对很多团队来说，这意味着低门槛、低风险、可回滚。记忆文件可以版本化，某条规则出问题可以删除，某个客户环境可以单独覆盖。
微调适合把稳定能力压进权重，比如格式遵循、领域术语、固定工具 schema。记忆适合保存变化快、可解释、需要审计的经验，比如内部 API 行为、工作流偏好、客户特例、近期故障。
两者不是替代关系。合理结构是：用微调或指令优化保证小模型能听懂工具协议，用 AMD 类记忆保证它知道某类任务怎么做。
局限和风险
第一，教师质量决定上限。强模型如果在某类任务上给出错误流程，学生会继承错误。
第二，记忆检索决定稳定性。召回错记忆会比没有记忆更糟，因为模型会自信地沿错误模式执行。
第三，任务分布变化会让记忆过期。工具 API 升级、业务规则变化、权限模型变化，都需要触发记忆审计。
第四，小模型仍然需要退出机制。遇到新任务、低置信、冲突记忆或高风险动作时，应该升级给教师模型或人工。
结论
AMD 最值得记住的一点是：小模型 agent 的生产能力可以来自外部经验，而不一定来自权重更新。对开发者来说，这比单纯追新模型更实用。
如果你已经有强模型 agent 在跑，今天就可以开始保存成功轨迹。先人工筛选 50 条高频任务，把它们压缩成层级记忆，再让 7B 或 8B 学生模型处理低风险任务。你会更快知道自己的瓶颈到底是模型能力、工具协议，还是缺少可迁移的经验。