为什么需要第三层：操作知识的定义
论文开篇的架构判断很干脆：一个能端到端做机器学习研究的智能体，由模型骨干（backbone）加 Harness（规划、执行、记忆、验证的周边工程）组成——这个双层框架已经被业界反复验证，但它仍然缺一块。作者把缺的这块命名为操作知识（operational knowledge）：区分「知道一个方法」与「让这个方法真正跑起来」的 know-how。
关键在于，这些知识并非不存在。它们就写在 GitHub 仓库与论文里——环境变量怎么配、CUDA 依赖装哪个版本、数据从哪里下载、报错后怎么恢复。问题是它们的形态：为人类读者而写、体量太大、无法在任务执行时整段载入上下文。于是每个智能体都在任务进行中重新发现这些知识——用昂贵的试错，一遍又一遍。
论文的解法是把这类知识离线蒸馏成紧凑、已验证、可跨任务复用的技能，而不是在每次运行中重新摸索。这个方向并非孤例：Claude 的 Skills 机制、各家编码智能体的规则文件，本质都在做同一件事——只是多为人工整理。Repo-to-Skill 的差异点在于把这件事做成了自动化流水线，并给出了库级规模的量化验证。
把论文的框架放进工程语境：骨干层决定推理质量，Harness 层决定执行可靠性（工具调用、状态管理、校验恢复），知识层决定领域 know-how 的供给方式。前两层是本站多篇文章的主题（见文末相关研究），Repo-to-Skill 的贡献在于论证：在骨干与 Harness 都不动的前提下，只替换知识层的供给方式，就足以让同一套系统在成熟基准上的表现接近翻倍。
DisCo 双模式：任务无关蒸馏与任务导向蒸馏
DisCo（Distillation of Context）是一个既创建技能、又在研究任务中消费技能的智能体。它的蒸馏沿两条互补路径展开：
任务无关蒸馏：面向整个开源生态
对领域内广泛使用的仓库做系统性蒸馏，产出可跨任务复用的技能库。这条路径的产物即 AREX-Skill Library：从 1000 个广泛使用的 ML 仓库中蒸馏出 5000 余条已验证技能，组织为 20 个领域（area）与 178 个能力族（capability family）。据媒体披露的时间线，该库 8 月 3 日以 170 余个仓库起步，8 月 27 日扩展到 1000 仓库并重写了路由器——两个月内完成库级扩容。
任务导向蒸馏：面向具体任务
当某个研究任务需要的知识不在通用库里，DisCo 可以为该任务定向生成技能。两种模式共享同一套「蒸馏即验证」的原则：技能不是摘要文本，而是要在干净沙箱中实际跑通后才算数。
蒸馏流水线分四个阶段：界定能力（scope capabilities）、锚定证据（ground evidence）、构建技能图（construct the skill graph）、验证与精炼（verify and refine）。媒体引述的成本口径约为每个仓库 40 美元——这个数字来自论文团队的公开分享，属厂商自报，但即便按数倍计，「把两年 GitHub 沉淀变成可执行技能」的单位成本也远低于让智能体在每次任务中重新试错。
技能契约与路由：SKILL.md 与渐进式披露
每条技能围绕一个 SKILL.md 组织，可选搭配 references/ 与 scripts/ 目录，内容覆盖四件事：这项能力何时适用（适用条件）、要跑什么（命令模板）、怎么验证跑通了（验证方式）、失败后怎么恢复（恢复路径）。这不是自由文本，而是一个在意图层与执行层之间的确定性接口。
运行时的关键设计是渐进式披露（progressive disclosure）：路由器把请求逐级收窄到「领域 → 能力族 → 仓库 → 工作流」，智能体只加载命中的那条分支。5000 余条技能因此不会撑爆上下文——这解决了「知识库越大越没用」的经典悖论，与工具检索领域的思路一致。
量化结果与正确读法
论文的核心实验设计是其说服力的来源：GPT-5.5 骨干、研究 Harness、下游执行预算三者全部固定，仅切换「是否装载蒸馏技能」这一个变量。对照基线为同一 Codex 智能体。四个基准的结果（数据来自论文与团队公开的对照表，均为团队自报）：
| 基准 | 任务构成 | 基线（无技能） | 装载 AREX-Skill | 相对增益 |
|---|---|---|---|---|
| MLE-bench | 75 场 Kaggle 竞赛，任意奖牌率 | 31.11% | 72.89% | +134.3% |
| PaperBench | 20 篇论文端到端复现 | 29.45 | 39.59 | +34.4% |
| FrontierCS | 188 道 Agent Track 算法任务 | 70.63 | 77.14 | +9.2% |
| PassNet | 200 个编译器 pass 样本，AS 分 | 1.343 | 1.531 | +14.0% |
读这组数据有三个要点。其一，134.3% 是相对增益——从 31.11% 的基线翻倍到 72.89%，绝对提升约 41.8 个百分点；「相对翻倍」与「从零到神」是两种叙事，前者才是事实。其二，增益梯度与任务的流程性强弱正相关：MLE-bench 这类重环境配置、重工程流程的基准增益最大，FrontierCS 这类纯算法合成任务增益最小。这组梯度本身就是论文的隐性结论——当前自主工程任务的主要瓶颈在程序性执行，而非算法推理。其三，四项对照数字均由团队自报，独立复现尚待社区验证。
论文的解释是：技能供给的是可复用的流程、检查点与恢复路径，让智能体跳过昂贵的无引导试错，把有限执行预算花在真正的实验与验证上——任务越难、流程越长，这笔「预算再分配」的收益越高。这与站内此前对 Harness 工程的分析互为镜像：Harness 治理的是「执行怎么不坏」，技能库治理的是「执行该怎么做」。
工程生态：CLI、导入路径与许可
这项工作没有停留在论文层面。DisCo CLI 以 npm 包发布（v0.2.1，要求 Node.js 22.19+），仓库采用 Apache 2.0 许可；技能可导入 Codex、Claude Code、Pi 等编码智能体使用——也就是说，第三方智能体可以直接消费这个技能库，把它当作外挂的领域知识层。需要注意的一点是许可分层：仓库本体是 Apache 2.0，但每条技能继承自其来源仓库，许可各自独立，商用前需逐条核查。
对国内团队而言，这套「技能契约 + 渐进式披露路由 + 自动验证」的组合是可直接借鉴的工程模板——它不依赖特定模型或框架，且 IDC 近期对企业级通用 Agent 的评估报告也把「Skill 资产化」列为实现 ROI 闭环的关键路径之一（见文末相关研究），两条线索在 9 月同向汇聚。
局限与批评
- 自报数据，尚无独立复现：四项对照均出自团队之手；团队自己也在论文与公开材料中欢迎独立验证。在第三方跑出同口径数字前，134.3% 应作为「待复核的强信号」而非定论。
- 域外迁移未证明：验证集中在 ML 研究域。四阶段流水线能否在医疗、法律、工业等其他领域复制出同量级增益，是这套方法泛化性的真正考题。
- 技能的时效与腐化：开源仓库依赖持续演进，已验证技能会随上游变更失效。论文未给出技能的过期检测与再验证机制，长期运营成本被低估。
- 许可碎片化：5000 余条技能继承各自来源仓库的许可，企业级采用前的合规核查本身就是一个工程量不小的任务。
至于 AREX-Skill Library 的商业化路径、以及任务导向蒸馏在非 ML 领域的实测效果，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
对智能体工程团队的启示
其一，把知识当资产预算，而不是当提示词边角料。多数团队的迭代预算花在换模型、调 Harness 上；这篇论文给出的对照说明，同样一份工程投入砸在知识层，性价比可能更高——尤其在流程密集型场景。其二，先固化流程，再谈自动化。技能的本质是把「跑通过一次的流程」变成可复用资产；一个连内部流程文档都没有的团队，谈不上技能蒸馏。其三，渐进式披露是知识库规模化的入场券。任何打算给智能体挂载百条以上知识单元的团队，都应先设计路由与分层加载，否则上下文经济学会先于能力成为瓶颈。