让AI科研智能体不再"每次从零踩坑"：把1000个GitHub仓库蒸馏成5000个技能，MLE-bench暴涨134%

你有没有这种感觉：让 AI 智能体去跑一个机器学习任务，它就像一个失忆的新员工——每次都从头摸索该用哪个库、参数怎么调、报错了怎么办，在同样的坑里反复摔跤，预算烧光了还没摸到门道。

上周看到的这篇论文（arXiv: 2609.02749）给了我一个挺有启发的视角：问题可能不在于智能体不够聪明，也不在于它的"骨架"（harness）不够好，而是它缺了一层东西——那些写在 GitHub 仓库和论文里、专供人类读者消化的操作知识（operational knowledge）。知道一个方法存在，和真正把它跑起来，中间隔着的就是这层知识。

作者们干了一件看起来很"笨"但效果惊人的事：把 1,000 个被广泛使用的 ML 仓库逐个蒸馏成结构化技能，构建出一个 5,353 个技能的库，然后让科研智能体带着这些技能去干活。结果在 MLE-bench 上分数从 31.11% 涨到 72.89%，相对提升 134.3%；高难度任务的拿牌率直接翻了 4.67 倍。

核心摘要：这篇论文提出了 DisCo——一个会"造技能"的科研智能体。它用四阶段流水线（圈定能力 → 采集证据 → 构建技能图 → 验证修复）把仓库和论文蒸馏成经过验证的、可执行的技能，沉淀为 AREX-Skill Library。在 backbone（GPT-5.5）、harness（Codex）、执行预算全部固定的前提下，仅加这层蒸馏知识，MLE-bench 涨 134.3%、PaperBench 涨 34.4%、FrontierCS 涨 9.2%、PassNet 涨 14.0%。说实话，这个提升幅度不像底层突破，更像一次大规模、纪律严明的工程整合——但它验证了一个被低估的命题：科研智能体的瓶颈可能不是模型，而是"知道怎么干活"的知识没被供给到位。

📖 论文信息

  • 标题：Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills
  • 作者：Jianlyu Chen, Yuyang Hu, Hongjin Qian, Jiawei Liu, Wenqing Wei, Xiaolong Chen, Defu Lian, Zhicheng Dou, Chaozhuo Li, Qiwei Ye, Zheng Liu
  • 发表：2026 年 9 月 2 日，48 页，3 张图
  • 链接：https://arxiv.org/abs/2609.02749

🎯 问题：智能体缺的不是脑子，是"操作知识"

论文把传统科研智能体形式化为两个组件：

\[\mathcal{A}=(M_{\theta},H)\]

\(M_\theta\) 是 LLM backbone，\(H\) 是 harness——负责规划、执行、记忆、验证的那套骨架。现在的主流做法就是在这两块上卷：换更强的模型，或者设计更精巧的 harness。

但作者指出这里有个结构性缺口。你想想看，一个人类研究员接手新任务时，他带的不只是智力和工作习惯，还有一堆"这个场景该用 XGBoost 而不是硬上 Transformer"、"复现这个 repo 先跑 import 检查再跑 smoke test"、"遇到 CUDA OOM 先降 batch size 再查梯度累积"之类的经验。这些知识写在哪？写在仓库的 README、文档、测试用例、issue 里——但它们是为人类写的，体量太大，任务进行时根本塞不进上下文。

论文把这层缺失的东西命名为 operational knowledge，形式化为 \(\mathcal{K}\)，智能体变成三组件：

\[\mathcal{A}_{\mathrm{res}}=(M_{\theta},H,\mathcal{K})\]

它有两个构成成分：一是把方法、代码、API 封装成智能体可实际调用的能力单元；二是每个单元携带的使用条件、理由和过程。作者有句话说得挺到位——capability without policy 是给智能体一堆工具却不给选型标准，policy without capability 是给一堆建议却没有可执行接口。两者缺一不可。

而 harness 和 \(\mathcal{K}\) 的分工也很清晰：harness 管"怎么探索"，\(\mathcal{K}\) 管"探索时知道该考虑什么"。这层知识不是不存在，它只是以错误的形态存在着。

AREX-Skill 总览：左图展示技能作为模型与骨架之外缺失的操作层，右图展示技能库、DisCo 智能体与四个基准的提升

图 1（a）：普通智能体靠试错前行，一路撞进死胡同——方法选错、实验重复、过拟合假设、预算耗尽；而装备 AREX-Skill 的智能体沿途经过方法选择、代码使用、校验检查、失败恢复等技能节点，直达目标。图 1（b）右侧：AREX-Skill 技能库（1,000 仓库、5,000+ 技能、20 领域、178 能力族）、DisCo 的两种模式，以及四个基准上 +134.30%、+34.43%、+9.22%、+14.02% 的提升。

🏗️ 方法：技能长什么样，怎么蒸馏

技能的三层结构

既然问题是"生产 operational knowledge"，那 \(\mathcal{K}\) 就实例化为一组技能。每个技能 \(S\) 由三层组成：

\[S=(\underbrace{\texttt{SKILL.md}}_{\text{knowledge interface}},\ \underbrace{\texttt{references/}}_{\text{knowledge substrate}},\ \underbrace{\texttt{scripts/}}_{\text{execution interface}})\]
  • SKILL.md：唯一会被预先读取的层，携带标准操作流程，写明目标、关键概念、工具用法、已知失败模式。它让持有单个技能的成本低到智能体可以随身带几千个。
  • references/ 目录：按需加载的深层材料，API 文档、算法细节、参数配置都在这里，遵循 progressive disclosure（渐进披露）原则——用到才打开。
  • scripts/ 目录：带明确输入输出的可执行包装器，智能体直接调用，而不是每次重新实现。

一个源（比如一个仓库）蒸馏出的技能往往不止一个，所以作者把它们组织成技能图 \(\mathcal{G}=(\mathcal{S},\mathcal{L})\)：一个入口技能声明源的适用范围，把智能体路由到数据准备、训练、评估、部署、排障等组件技能；边编码 routing、dependency、composition 三种关系。智能体读入口，沿需要的链接前进，其余部分永远不打开。

DisCo 的 Creator Mode：四阶段蒸馏流水线

蒸馏的核心流程是：

\[z\ \xrightarrow{\ \mathsf{scope}\ }\ \mathcal{Q}\ \xrightarrow{\ \mathsf{ground}\ }\ \mathcal{X}\ \xrightarrow{\ \mathsf{construct}\ }\ \tilde{\mathcal{G}}\ \xrightarrow{\ \mathsf{verify}\ }\ (\mathcal{G},R)\]

四个阶段依次回答四个问题：哪些能力重要、什么证据支撑它们、证据怎么变成技能、这些技能到底成不成立。说实话，看到最后这个阶段我才意识到这套东西和普通"文档摘要"的区别在哪——verification 才是蒸馏和总结的分水岭。论文里写得很硬：任何技能都不能仅凭其来源被准入，验证中幸存的缺口不会被藏起来，而是写进构建记录 \(R\)。

验证阶段的实现也很有意思：验证器生成 assertion-backed 的可用性用例，跑原生检查并分成五类——pass、skill_gap、native_fail、skip_unsafe、skip_not_selected。出现 skill_gap 就触发对责任技能的局部修复并重跑。相当于每个技能上岗前都要通过冒烟测试。

蒸馏分两种形态，区别在于锚点 \(z\) 是什么：

维度 Task-agnostic（任务无关） Task-oriented（任务导向）
锚点 \(z\) 一个源（仓库、论文） 一个具体任务 \(\tau\)
核心提问 这个源"使什么成为可能" 解决这个任务"需要什么"
证据来源 从源自身提取 主动搜索覆盖能力缺口的材料
产出 预先构建的长寿命技能，摊销到所有后续任务 按需产出，但对同类问题可复用

成本上有个不对称设计值得注意：Creator Mode 每个源只付一次钱（平均每个仓库约 40 美元，用 GPT-5.5 和 GPT-5.6-sol、xhigh reasoning effort），摊销到之后所有任务；Researcher Mode 只付任务实际打开的那部分。知识生产是离线的重活，知识消费是在线的轻活。

DisCo 方法总览：左下为使用技能的科研智能体，右上为四阶段蒸馏流水线，下方为技能库与可复用元技能包

图 2：左侧是 Researcher Mode——LLM backbone 加 harness（ideation → experimentation → evaluation → revise 循环），操作知识作为 operating context \(\mathcal{K}\) 以渐进披露方式注入；右侧是 Creator Mode 的四阶段流水线：圈定能力、锚定证据、构建技能图、验证修复，产出验收后的技能图 \(\mathcal{G}\) 和构建记录 \(R\)；底部是 AREX-Skill Library（任务无关的仓库/论文技能 + 任务导向的各基准技能）和可复用的元技能包（create-repo-skill、verify-repo-skill 等）。

技能库本身

Task-agnostic 路径铺开后产出了 AREX-Skill Library 的快照：5,353 个已验证技能、来自 1,000 个 ML 仓库、组织成 20 个领域和 178 个能力族的两级分类。2,209 条精确的仓库指派路径，700 个仓库横跨多个能力族（成员关系是重叠而非互斥的，这符合直觉——vLLM 既是推理基础设施也是模型部署工具）。

使用时的路由是渐进的：从领域缩到能力族，再打开具体的仓库技能图，只加载当前步骤需要的内容。还有个细节我很喜欢——没有合适的能力族时，router 不强行路由。这比硬塞一个不相关的技能要聪明。

AREX-Skill Library 概览：20 个领域、178 个包族、1,000 个仓库、5,000+ 技能的覆盖情况与路由路径

图 3：技能库覆盖计算机视觉（21 族 / 211 仓库）、LLM 应用（16 族 / 153 仓库）、数据科学、训练基础设施等 20 个领域；底部是 Library Router 的使用路径：用户请求 → 选领域 → 探索能力族 → 选仓库 → 读仓库技能图 → 获取相关技能。

📊 实验：固定一切变量，只加技能

实验设计的方法论亮点在于"预算隔离"：backbone 固定 GPT-5.5，harness 固定原版 Codex（不改控制循环、不加定制编排），下游执行预算匹配。技能构建在评测开始前完成，构建成本一次性且不计入运行预算。唯一的受控变量就是有没有技能。所以所有增益都可以归因于知识层 \(\mathcal{K}\) 本身。

MLE-bench：涨幅最猛的一个

75 个 Kaggle 竞赛，指标是 Any-Medal 分数，3 次重复运行取均值。每个竞赛配一个专用技能图，构建时排除了原始竞赛网页——避免直接泄题。

智能体 Backbone Low Medium High 总分
Famou-Agent 2.0 Gemini-3-Pro-Preview 80.30 64.04 42.22 64.44
AIBuildAI Claude-Opus-4.6 77.27 61.40 46.67 63.11
Codex（无技能） GPT-5.5 42.42 31.58 13.33 31.11
Codex + AREX-Skill GPT-5.5 86.36 69.30 62.22 72.89

31.11% → 72.89%，绝对涨 41.78 个百分点。但有两个观察值得说。

其一，原版 Codex 在这个榜上其实垫底——31.11% 对最强的 Famou-Agent 2.0 的 64.44%，差距接近腰斩。所以加技能后超过所有 baseline 这件事，一半的功劳是"Codex 底子差"。其二，难度越高收益越大：High 难度从 13.33% 到 62.22%，相对提升 366.8%。这个模式说得通——低难度任务模型自己就能趟过去，高难度任务才真正考验"知不知道怎么干活"。

PaperBench：论文复现

20 篇 ICML 论文的复现任务。技能从目标论文 related-work 引用的 153 篇论文及其仓库蒸馏而来（共 636 个技能），严格排除目标论文本身及其官方代码。平均分 29.45 → 39.59，涨 34.4%。

低基线任务的提升最夸张：ftrl 从 1.50 涨到 17.17（11.4 倍），rice 从 7.94 涨到 48.51（6.1 倍）。但也有 2 个任务退化了——sample-specific-masks 掉 5.07 分，stay-on-topic 掉 4.52 分。作者归因为检索精度失败：当复现依赖技能图没覆盖到的特定实现选择时，检索到的技能反而把智能体带离了它本可以自行收敛的路径。这个失败案例其实挺有价值的——技能引导是有机会成本的，不匹配的技能比没有技能更糟。

FrontierCS：开放式算法优化

188 个开放式 CS 问题，写 C++ solver 迭代提交，每任务 5 小时、2 CPU、4 GiB RAM 的硬约束。这里用的是单一共享的 recovery-oriented 技能图，评测前冻结。

Score 从 70.63 涨到 77.14（+9.22%，paired bootstrap 95% CI [3.41, 9.83]）。幅度不如 MLE-bench 夸张，但效率维度很能打：对比 Claude Code 配 Opus 4.8 的 14.72M tokens，Codex+技能只用了 4.47M——人家烧 3.29 倍的 token，分数还低 2.64 分。在 Score、tokens、steps、tool calls 四个维度上 Pareto 占优这两个 Claude Code 配置。

还有个排除"纯多烧资源"解释的分析做得挺严谨：增益与 tokens、steps、tool calls 的 Spearman 相关系数分别为 0.006、0.014、0.015——基本零相关。涨分不是因为花得更多。

PassNet：编译器 pass 生成

给计算图写 pattern matcher 和 rewriter，在保持语义的前提下加速执行。主指标 AS Score 从 1.343 涨到 1.5313（+14.0%），超过了 TorchInductor 的 1.419；失败样本从 14 个降到 5 个；正确率从 81.35% 提到 90.76%。唯一的例外是 Fast_1 从 28.48% 微降到 26.72%——正确性上去的代价是少了一些"保守但快"的提交。

🤔 我的判断

这篇论文最值钱的地方：它把"科研智能体为什么不好用"这个问题重新定位了。不是模型不够强，不是 harness 不够巧，而是领域 know-how 以人类可读、机器不可载的形态散落在仓库里。Repo-To-Skill 给的答案是把这层知识离线蒸馏、验证、结构化，再以渐进披露的方式按需供给。134% 的 MLE-bench 提升、High 难度 4.67 倍拿牌率，这些数字说明知识供给确实是当下科研智能体的一阶瓶颈。

但也得泼点冷水。

第一，"蒸馏"和"总结"的边界全靠验证阶段撑着，而验证依赖 LLM 生成的 assertion 用例——$40 一个仓库的构建成本里有多少真正花在了硬核验证上，论文没有拆得很细。5,353 个技能的验证通过率、失败模式分布，这些能让读者判断库的真实质量的数据给得不够。

第二，PaperBench 那两个退化任务暴露了系统性风险：技能是引导也是偏置。当智能体自己的探索策略本来能收敛时，一份不匹配的技能可能把它带沟里。论文建议用更好的路由和显式回退来缓解，但这等于说"这个问题没解决"。

第三，整个技能库是用 GPT-5.5/5.6-sol 蒸馏的，评测也用 GPT-5.5。技能知识里会不会隐性编码了对同家模型行为模式的适配？换 Claude 或开源模型做 backbone，增益还剩多少？这是个很自然的泛化问题，论文没回答。

另外说句题外话，"把仓库蒸馏成技能"这个思路并不孤立——过去一年多工业界已经在大量实践 repo-level 知识沉淀（各类 agent skill、CLAUDE.md 生态、MCP 工具描述都在做类似的事）。这篇论文的贡献在于把它形式化为三层智能体架构里缺失的 \(\mathcal{K}\)，并配上一套带验证的规模化生产流水线和跨四个基准的受控评测。是扎实的工程整合，不是理论突破，但整合得确实有纪律。

💡 工程启发

如果你在做科研智能体或长程编码智能体，有几件事可以直接抄：

  • 知识分层：入口文件（路由 + 操作要点）/ 深层参考（按需加载）/ 可执行脚本（直接调用），这个三层结构几乎是通用配方。
  • 验证准入制：技能不进库就不许用，验证不过就局部修复重跑，缺口写进记录而不是藏起来。知识库的质量不是靠写得好，是靠拦得住。
  • 成本不对称：贵的知识生产离线做一次，便宜的知识消费在线按需付。40 美元一个仓库听起来贵，摊销到几千次任务调用上就几乎可以忽略。
  • 警惕负技能：给不匹配的技能留了显式回退通道，比强行路由更重要。

还有一个更本质的问题这篇论文没碰：技能会过时。仓库在演进，今天蒸馏的技能三个月后可能就指向已废弃的 API。元技能包里有 refresh-repo-skill 这个影子，但动态维护一个 5,000+ 技能库的代价和机制，恐怕是 Repo-To-Skill 这条路线接下来最硬的仗。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我