Repo-To-Skill:将 GitHub 仓库蒸馏为 AI4AI 技能
自主智能体正开始端到端地执行机器学习(ML)研究。这类智能体将模型主干与用于规划、执行、记忆和验证的框架相结合,但该架构仍未将领域特定知识纳入智能体。我们将这一缺失层面称为操作知识,即区分“了解方法”与“让方法奏效”的诀窍。这类知识并非不存在,而是散落在仓库和论文中,以面向人类读者的形式呈现,且体量过大,难以在任务过程中完整加载。一旦被蒸馏为紧凑且经过验证的技能,这些知识便可跨任务复用,而无需每次运行都重新发现。 我们提出 DisCo,一个以技能为驱动的科研智能体,能够在研究过程中创建并使用技能。其蒸馏以两种互补形式进行:任务无关蒸馏,将领域内广泛使用的仓库浓缩为可复用技能;任务导向蒸馏,生成具体任务所需的技能。前者应用于开放生态系统,产出了 AREX-Skill Library,包含从 1000 个广泛使用的 ML 仓库中蒸馏出的 5000 多项已验证技能,并划分为 20 个领域和 178 个能力族。 在固定 GPT-5.5 骨干模型、研究框架与下游执行预算的条件下,装备技能的科研智能体在 MLE-bench 上得分提升 134.3%,在 PaperBench 上提升 34.4%,在 FrontierCS 上提升 9.2%,在 PassNet 上提升 14.0%。这些提升源于在该固定设置下额外加入的、经蒸馏的操作上下文。
论文精读
TL;DR DisCo 将 GitHub 仓库蒸馏为可验证技能(AREX-Skill Library,5000+ 技能),使同一智能体在 MLE-bench 等四基准上分别提升 134.3%、34.4%、9.2%、14.0%。
问题
问题背景
自主机器学习研究智能体(autonomous ML research agents)正从单任务执行走向端到端研究自动化,核心架构通常为“模型骨干 + 规划/执行/记忆/验证 harness”。然而,该架构缺少一层领域特定的、可操作的 know-how。
现有方法局限
现有 agent 在需要领域操作知识时面临两类困境:
- 直接加载原始仓库或论文:数据量过大(数千文件、数万行代码),超出上下文窗口,且信息密度低、为人类阅读而非 agent 消费而写。
- 任务内重新探索:agent 每次运行都需重新试错、阅读文档、调试,导致高 token 成本与高延迟,且结果不稳定。
此外,缺少年级验证机制,提取的知识可能包含错误或过时信息,难以复用。
为什么这个问题难且重要
难点在于操作知识具有隐性、分散、仓库特定的特点:它散落在 README、setup.py、测试用例、issue 讨论甚至论文附录中,需要自动蒸馏、结构化和运行时验证。业界对 AI4AI(AI 自动化 AI 研究)关注度持续上升,因为一旦这类技能可复用,能显著降低研究迭代成本,并提升基准评测(如 MLE-bench、PaperBench)上的通过率。
行业类比
类似企业级 LLM 应用中,将海量内部文档提炼为可检索、可执行的工具或知识块,而不是每次让模型通读全部资料。
核心洞察
- 操作知识(operational knowledge)是自主 ML 研究智能体缺失的独立层:DisCo 将 GitHub 仓库中隐含的“如何让方法跑起来”的 know-how 蒸馏为紧凑、可验证的技能(skills),填补了模型骨干与规划/执行 harness 之间的空白。与仅增强推理或搜索策略的同类工作不同,DisCo 通过在任务前构建可复用知识库,使智能体无需在每次运行时从原始仓库重新发现操作细节,从而将隐性经验显式化、模块化。
- 技能蒸馏采用任务无关与任务导向双模式,并构建了可路由的技能图(skill graph)。任务无关蒸馏从 1000 个广泛使用的 ML 仓库产出 5000+ 验证技能,按 20 领域与 178 能力族组织;任务导向蒸馏则根据具体任务动态生成补充技能。这种“预计算+按需提取”架构与简单的文档检索或 RAG 有本质区别:技能不是原始文本片段,而是经过执行验证、可被智能体直接调用的知识单元,且通过图结构支持渐进式披露,避免了上下文过载。
- 在固定模型骨干、研究 harness 与下游执行预算的条件下,仅添加技能层使 DisCo 在 MLE-bench 上提升 134.3%,PaperBench 提升 34.4%,FrontierCS 提升 9.2%,PassNet 提升 14.0%。这一结果挑战了“性能提升主要依赖更大模型或更优搜索”的假设,表明操作知识的缺失是智能体在真实 ML 任务中的关键瓶颈。对工程实践而言,投资于领域知识蒸馏与维护,可能比单纯扩展模型规模更具性价比。
方法
DisCo 以 GitHub 仓库与论文为输入,输出为按分类组织的技能图库。
任务无关蒸馏 从 1,000 个广泛使用的 ML 仓库开始,首先进行 scoping 和 grounding 界定证据边界,然后为每个仓库构建自包含的 repository graph;随后验证区分运行时技能与静态检查,生成可复用的技能。这些技能被归纳为 20 个领域、178 个能力族,构成 AREX-Skill Library,包含 5,000+ 经验证技能。
任务导向蒸馏 针对具体研究任务(如 MLE-bench 的竞赛、PaperBench 的论文复现)生成技能:从任务要求或论文中提取目标,通过执行反馈迭代验证,最终得到描述性技能而非可执行代码。
路由与使用 在 Researcher 模式下,利用分类树和路由器实现渐进式披露,只向模型暴露与当前子任务相关的技能子集,避免上下文过载。Creator 模式负责在离线阶段生成技能。
与同类方法仅将操作知识散落在仓库中、依赖 agent 运行时自行重新发现不同,DisCo 将操作知识预蒸馏为紧凑、可验证、可路由的技能,在固定模型 backbone 与 harness 的条件下提升基准成绩。
实验
实验设计
在固定 GPT-5.5 backbone、研究 harness 和下游执行预算下,对比 DisCo 技能增强版与同一 agent 无技能的基线。评估覆盖四个基准:MLE-bench (Full)、PaperBench (Full)、FrontierCS (Agent Track)、PassNet。技能来自 AREX-Skill Library(5,000+ verified skills,源自 1,000 个广泛使用的 ML 仓库)。
关键发现
- 技能使 MLE-bench 得分提升 +134.3%,PaperBench 提升 +34.4%,FrontierCS 提升 +9.2%,PassNet 提升 +14.0%。
- 增益并非来自新 harness 或扩大模型,而是添加 distilled operating context。
- 在 MLE-bench 上,任务难度越大,提升越显著;在 PaperBench 上,低基线任务提升最大,少数任务出现回归。
- PassNet 上,技能让 Codex 聚合得分超越 TorchInductor。
与基线对比解读
原作者论断:这些提升来自在固定设置下添加 distilled operating context。
基线是相同 backbone 和 harness 的无技能 agent,因此差异完全归因于 operational knowledge 的注入。技能库将人类可读但无法在任务中加载的仓库知识压缩为可路由、可验证的模块,使 agent 无需每次运行时重新发现 know-how。这验证了“知识蒸馏 + 按需路由”架构对自主 ML 研究的价值,而非单纯算力或模型规模扩展。
行业影响
落地场景
AREX-Skill Library 可作为 AI 研发团队的“操作知识外挂”,直接服务于自动化研究 agent 与 AutoML 平台。典型场景包括:
- 电商推荐系统:团队反复训练多任务模型,技能库中的训练技巧、损失函数配置、调试流程可直接注入 agent,减少重复试错。
- 金融风控建模:复现论文中的新架构(如时序模型、图模型)时,paper-derived skills 提供可执行步骤,缩短从读论文到跑通代码的周期。
商业价值
核心是降本增效:将专家隐性知识外部化为可复用技能,减少对高级研究员的依赖;在 MLE-bench 上提升 134.3% 意味着同样预算下能完成更多任务,加速模型迭代;同时提升 agent 在长尾任务上的成功率,降低失败成本。
与现有产品/工作流的接口
技能以图结构组织,通过 router 暴露,支持渐进式披露。集成时可将技能库作为外部知识源,接入现有 agent harness(如 Codex 或内部编排框架),在任务规划阶段按需查询相关技能。任务导向的蒸馏能力可嵌入 CI/CD pipeline,为每个新项目自动生成专属技能子集,实现持续沉淀。
局限
- - 论文仅在固定 GPT-5.5 骨干和特定 research harness 下验证技能增益,未跨多个骨干模型或不同 agent 框架做消融。若换用较弱或较新的模型,蒸馏技能带来的提升可能衰减,且任务无关技能库的构建与验证开销是否可泛化到其他代码领域仍不明确。
- - AREX-Skill 库从 1000 个仓库蒸馏得到 5000+ 技能,但基准测试仅限 MLE-bench、PaperBench、FrontierCS、PassNet 四个偏 ML 研究任务的评测集;缺少更长周期、开放式科研或工业部署场景的证据。技能验证依赖执行反馈,可能过拟合特定环境,真实复现时的环境差异会削弱技能有效性。
- - 论文将任务无关蒸馏和任务导向蒸馏结合,但未深入讨论技能库的持续维护、过期检测与冲突消解机制。随着上游仓库更新或新方法涌现,静态技能图可能迅速失效,路由与分类也需要重新训练,这在实际工程中会引入额外运维成本。