蒸馏一个Agent，到底要蒸什么？首篇「系统级综述」来了

从蒸馏一个模型，到蒸馏整个 Agent 系统。

Agent 的任务求解能力来自模型、可复用资源与执行控制的共同作用，知识蒸馏也因此需要从模型层面扩展到完整智能体系统。

这篇 57 页综述以知识在学生智能体中的保留位置为主线，统一梳理智能体蒸馏的定义、技术路径与评估框架，为智能体能力的迁移与复用提供系统性指导。

一个编程 Agent 修好了 Bug。换一个 Agent 接手新的代码仓库，原来的补丁可能已经用不上，但诊断问题的方法、测试的顺序，以及出现回归时的回滚策略，仍然值得复用。

这些经验可以被模型学会，也可以沉淀为可调用的技能，或转化为执行流程中的控制规则。

要传递这样的任务求解能力，面向智能体系统的知识蒸馏就需要同时考虑模型、可复用资源与执行控制。

围绕这一从模型层面到完整智能体系统的蒸馏视角转变，来自中南大学、北京智源人工智能研究院、香港理工大学和北京邮电大学等机构的研究团队，近期联合发布了一篇系统级智能体蒸馏综述。

该综述以完整智能体作为教师与学生，围绕任务求解知识如何被提炼、保留并用于后续任务，建立统一的定义、分类与评估框架，并进一步讨论知识在不同载体之间的迁移与组合。

论文标题：

Distilling Agentic Systems: A Roadmap across Models, Artifacts, and Harnesses

论文地址：

https://arxiv.org/abs/2609.36630

〓 图1. 从模型蒸馏到智能体蒸馏。知识可以保留在模型、可复用资源和执行控制中。来源：论文图2

一次执行结束后，经验留下了什么

在经典知识蒸馏中，教师和学生通常被视为两个模型。学生通过学习教师的输出、分布或推理过程，把知识吸收到参数中。

对于会调用工具、维护记忆并根据执行反馈调整计划的 Agent，这一视角需要进一步扩展。

论文用一个贯穿全文的示例说明原因：教师 Agent 为代码仓库适配新版依赖，先尝试大范围替换旧 API。局部测试通过了，完整测试却暴露出回归。

随后，它撤销修改，改用局部兼容封装，最终通过验证。

整段记录中混合了临时路径、仓库特定代码和可复用经验。蒸馏过程需要从中提炼可复用的做法，例如先复现错误、控制修改范围、逐步扩大测试覆盖，并在回归出现时回滚。

换一个仓库后，具体补丁无法照搬，这些策略却可能继续有用。

沿着这一思路，论文将智能体蒸馏（Agent Distillation）定义为：从教师智能体提供的证据中提炼任务求解知识，并将其持久融入学生智能体，使这些知识在原始交互结束、教师不再参与后，仍可用于后续任务。

因而，一次临时提示或在线求助本身并不足以构成蒸馏；关键在于，它是否给学生留下了可供未来使用的变化。

教师也可以是同一个 Agent 的早期版本。这让跨 Agent 传授经验与基于历史经验的自我演进，能够在同一套定义下讨论。

〓 图2. 从一次代码修复提炼可迁移的调试策略，再由学生在新任务中复用。说明性案例（来源：论文图3）

同一份经验，可以进入三种知识载体

综述以知识在学生中的保留位置为分类依据，将相关方法组织为三条主线：模型（Models）、可复用资源（Artifacts）和执行控制框架（Harnesses）。

判断依据是这些知识如何参与未来执行，而不是训练材料叫什么、用了哪种优化算法，或是否保存成了文件。

模型中的参数化知识

第一条路线最接近熟悉的模型蒸馏：通过训练，让教师的经验影响学生模型的推理和决策。放在代码修复场景中，就是让学生学会在修改后主动验证、遇到回归时调整策略。

Agent 任务还带来一个额外难点：学生的行动会影响后续遇到的状态与反馈。仅学习教师提供的轨迹，未必能覆盖学生自主执行时遇到的情况。

因此，综述进一步讨论了如何在学生自身产生的交互轨迹上引入教师指导，帮助学生学习应对实际执行中的偏差与错误。

可以检索和调用的外部知识

第二条路线将经验保留为记忆、示例、技能、代码或工具，论文将这些可独立检索或调用的资源称为 Artifacts。

模型参数可以保持不变，学生通过使用这些资源利用教师知识。例如，将修复过程抽象为带有适用条件的调试技能，或保存成经过验证的辅助脚本。

这类方法的重点在于筛选、抽象和验证。原始轨迹里的临时信息、过时接口和相互冲突的建议，都可能降低复用价值。资源库也需要随着环境变化进行更新、合并和删除。

组织行动的执行知识

第三条路线将经验固化到执行控制系统（Harness）中。它决定何时调用资源、怎样分配预算、哪些结果需要检查，以及失败后如何重试、回滚或终止。

同样一条“出现回归就回滚”的经验，可以写在技能文档中，也可以被实现为运行时必须经过的控制分支。前者是可读取的资源，后者直接组织执行。

论文据此区分 Artifact 与 Harness，避免把所有工作流文件、脚本和控制逻辑混为一类。

这也解释了为什么文件格式不能决定分类：单独保存的模型适配器仍属于参数化知识；可调用脚本属于资源；决定何时调用脚本的机制则属于执行控制。

知识跨越模型，技能与流程的边界

这三类知识载体之间也可以发生转换。例如，一份调试技能可以作为训练材料，被学生模型吸收；其中关于检查、重试和回滚的规则，也可以进一步转化为执行控制逻辑。

论文将这类知识形式之间的转换称为跨载体迁移。它关注的是：知识改变了表达形式之后，原本有用的判断和行动策略能否保留下来。

跨载体迁移描述知识如何从一种载体转化到另一种载体，混合式蒸馏结果则描述知识最终同时保留在多个学生组件中的状态。

两者可以同时发生：例如，将教师提供的一份调试技能中的诊断方法训练进学生模型，同时将其中的验证与回滚要求转化为执行控制规则。

知识由可复用资源迁入模型与执行控制框架，并在这两个组件中持续保留。

分数提高之后，还要找到经验起作用的证据

学生得分提高，能够说明整套系统的表现有所改善，却不能单独说明教师知识被保留在哪里。提升可能来自模型学习，也可能来自新增技能、更好的路由机制或更多执行预算。

为此，综述构建了连接知识保留、因果贡献与实际任务收益的评估框架，系统考察学生保留了什么、这些变化如何影响执行，以及相关收益能否在新任务和部署环境中持续成立。

具体而言，可以在控制其他组件、任务条件和执行预算的前提下，将某个蒸馏后的组件恢复到蒸馏前的状态，观察学生的行为和表现如何变化。

再结合新任务测试、成本与失败分析，才能把“留下了什么”“实际起了什么作用”与“带来了多少收益”联系起来。

把知识放在适合它的位置

这套视角最终指向一个工程问题：哪些经验适合训练进模型，哪些适合保存为可编辑资源，哪些应转化为执行控制规则？

综述对此讨论了几种可能的分配原则：频繁使用且相对稳定的决策模式，可以考虑参数化；经常变化的知识或具体操作规范，适合保存在可更新资源中；验证、恢复和权限约束，则可以通过显式控制逻辑实施。

具体选择仍取决于成本、更新频率、可迁移性与安全要求。

与此同时，经验会过期，工具会升级，权限也会变化。保留知识之后，还需要记录来源、适用条件和依赖关系，并支持修改、撤销与回滚。持续积累经验，也意味着持续维护经验。

从模型蒸馏到 Agent 蒸馏，知识迁移的研究对象拓展为模型、可复用资源与执行控制共同构成的完整系统。

这篇综述围绕知识如何被提炼、保留和复用建立统一框架，为研究者分析智能体能力的迁移机制提供了工具，也为开发者选择知识载体、设计蒸馏流程和验证实际效果提供了依据。

更多阅读

·