Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills

一句话概括

论文提出技能蒸馏框架 DisCo，把 GitHub 仓库中的操作知识提炼成可复用技能。在固定模型主干与执行预算下，加载技能的智能体在多项 AI 科研基准上取得提升。

任务与方法：DisCo 用任务无关与任务导向两种蒸馏，把 ML 仓库知识转成紧凑、已验证的技能，供智能体在任务前加载。
关键数字：从 1000 个常用 ML 仓库蒸馏出 5000+ 已验证技能，组织为 20 个领域、178 个能力族。
性能提升：固定 GPT-5.5 主干、研究框架与执行预算，MLE-bench 提升 134.3%，PaperBench 提升 34.4%，FrontierCS 提升 9.2%，PassNet 提升 14.0%。
数据与开源情况：摘要未给出。

自主智能体已能端到端执行机器学习（Machine Learning, ML）研究任务。其架构通常由模型主干加外围模块组成。外围模块负责规划、执行、记忆与验证。

但作者指出一个断层。智能体即便「知道」某个算法原理，也常不知道如何让它真正跑通。比如装哪个版本的依赖、数据预处理有哪些坑、超参数默认值设多少。论文把这种差距称为操作知识（operational knowledge）。它指的是从知道方法到让它工作之间的距离。

这类知识并不缺失。它散落在 GitHub 仓库、论文附录和 issue 讨论中。问题在于它们为人类读者编写，体量庞大。单次任务无法把全部内容载入上下文。

结果是每个智能体每次运行都要重新摸索、重复踩坑。作者的核心洞察是：把这类知识预先蒸馏成紧凑、经过验证的技能模块，技能就能跨任务复用。

DisCo 的蒸馏分两种互补形式。

任务无关蒸馏（task-agnostic）：面向整个开源生态。它从广泛使用的 ML 仓库提炼通用技能。作者对 1000 个高频仓库蒸馏，产出 AREX-Skill Library。该库含 5000+ 已验证技能，按 20 个领域和 178 个能力族组织。
任务导向蒸馏（task-oriented）：针对具体科研任务。它从相关仓库提炼该任务特别需要的技能，更聚焦于执行细节。

蒸馏出的技能需经过验证（verified）。技能描述不是凭空生成，而是经过实际运行或逻辑校验。

推理阶段，智能体在开始任务前检索并加载相关技能。这些技能作为额外操作上下文，参与规划与执行。

关键设计选择：对比实验固定模型主干（GPT-5.5）、研究框架和下游执行预算。唯一变量是是否加载蒸馏技能。这样可干净归因性能提升来源。

在固定 GPT-5.5 主干、研究框架和执行预算下，装备技能的智能体相比无技能版本取得提升。MLE-bench 提升 134.3%，PaperBench 提升 34.4%，FrontierCS 提升 9.2%，PassNet 提升 14.0%。
技能库规模可观。从 1000 个仓库蒸馏出 5000+ 已验证技能，组织为 20 个领域和 178 个能力族。
性能提升全部来自「蒸馏后的操作上下文」这一新增信息源。它不是来自模型能力或计算资源的增加。

需说明：摘要未给出各基准的绝对分数。摘要也未给出技能验证的具体流程。技能数量对性能的边际影响曲线同样未给出。各基准提升差异较大，从 9.2% 到 134.3%。摘要未解释 MLE-bench 提升为何显著、FrontierCS 为何温和。

这篇论文的实用价值直接。它把「经验」从隐性变为显性，从不可传递变为可复用模块。对 AI 科研智能体而言，相当于配备一本「实战手册」，而非只给一本「理论教材」。

适用场景包括：

一个延伸思考：若技能库持续积累，它可能成为某种「集体操作记忆」。它不是论文里的理想化方法，而是社区真正跑通的做法。这或许比传统文档更能反映真实世界的 ML 实践。

摘要未给出技能验证的失败率或过滤标准。因此无法判断 5000+ 技能中有多少高质量可迁移。也无法判断有多少可能过拟合于特定仓库版本。这是最值得追问的点。

另一个开放问题是技能的生命周期管理。ML 生态演进快，框架版本更新、API 废弃、新最佳实践出现。技能库如何保持时效性？摘要未提及更新机制。

技能蒸馏本身依赖 GPT-5.5 这类强模型。那么蒸馏质量是否受限于教师模型能力？若未来模型更强，是否会出现「技能蒸馏的自我改进循环」？论文未讨论。

最后，134.3% 的 MLE-bench 提升幅度引人好奇。是否 MLE-bench 任务特别依赖操作知识，如环境配置、库调用？而 FrontierCS 是否更侧重算法推理？这种任务类型与技能收益之间的相关性，值得后续研究深挖。