从模型蒸馏到Agent系统蒸馏，系统级智能体蒸馏综述

当AI智能体完成一次任务后，它留下的经验该如何被复用？传统的模型蒸馏只关注参数层面的知识传递，但对于会调用工具、调整计划的智能体来说，这套思路需要彻底升级——知识蒸馏的对象，应当从单个模型扩展到由模型、可复用资源与执行控制共同构成的完整智能体系统。

近期，来自多所高校与科研机构的研究团队发布了一篇57页的学术综述，以知识在智能体中的保留位置为主线，为智能体蒸馏建立了统一的定义、分类与评估框架，填补了系统级智能体蒸馏领域的研究空白。

比如，一个为代码仓库适配依赖的智能体，在测试中遇到错误后，撤销修改改用兼容封装的过程中，会产生临时路径、仓库特定代码与可复用经验三类信息。蒸馏的核心是从中提炼出可复用的策略：先复现错误、控制修改范围、逐步扩大测试覆盖，以及在回归出现时执行回滚。这些策略无法直接照搬给其他代码仓库，但可以被学生智能体学习为模型参数，沉淀为可调用的调试技能，或是转化为执行流程中的控制规则。

基于这类场景，综述将智能体蒸馏定义为：从教师智能体的交互过程中提炼任务求解知识，并将其持久融入学生智能体，使这些知识在原始交互结束后仍能用于后续任务。值得注意的是，教师可以是同一智能体的早期版本，这让跨智能体的经验传授与基于历史的自我演进，都能在同一套框架下讨论。

为了清晰梳理蒸馏的技术路径，综述将知识的保留位置分为三类核心载体：

第一类是模型中的参数化知识，对应传统的模型蒸馏思路，但智能体场景下需要额外处理学生自主执行带来的状态变化，因此需要在学生的交互轨迹中引入教师指导，帮助应对实际执行中的偏差。

第二类是可复用资源，包括记忆、调试技能、验证脚本等，这类知识无需修改模型参数，学生通过调用这些资源即可复用经验，关键在于筛选、抽象与验证，确保资源的复用价值，以及随环境变化的更新维护。

第三类是执行控制框架，决定何时调用资源、分配预算、检查结果，以及失败后的重试、回滚或终止逻辑。同一经验可以是可读取的资源，也可以是嵌入执行流程的控制规则，这是区分资源与控制逻辑的核心。

这三类载体之间可以发生转换，比如一份调试技能可以作为训练材料融入模型，也可以转化为执行控制规则。这类转换被称为跨载体迁移，而混合式蒸馏则是指知识同时保留在多个载体中的状态，比如将诊断方法训练进模型，同时将验证规则转化为控制逻辑，让知识在不同组件中持续发挥作用。

为了验证蒸馏的实际效果，综述构建了一套评估框架，需要追踪三个核心问题：学生保留了什么知识？这些知识如何影响智能体的执行表现？相关收益能否在新任务中持续成立。具体方法是在控制其他组件的前提下，将蒸馏后的某个组件恢复到原始状态，观察智能体的行为变化，结合新任务测试与成本分析，最终明确知识的作用与价值。

这套框架最终指向一个工程问题：哪些经验适合存入模型，哪些适合作为可复用资源，哪些应转化为控制规则？综述提出了分配原则：频繁使用且稳定的决策模式适合参数化；经常变化的知识或操作规范适合作为可更新资源；验证、恢复与权限约束则适合用控制逻辑实现。无论哪种选择，都需要持续维护知识，记录来源、适用条件与依赖关系，支持修改与回滚，确保经验能长期发挥作用。

从模型蒸馏到智能体蒸馏，研究的边界从单个模型拓展到了完整的智能体系统，这篇综述为智能体能力的迁移与复用提供了系统性的指导，无论是研究者分析知识的传递机制，还是开发者设计蒸馏流程，都能从中获得清晰的参考。