给 AI 一本"操作手册"：5000 个技能让研究 Agent 起飞

一个尴尬的场景

设想你是一个刚入行的 ML 研究实习生，导师丢给你一个任务："在这个数据集上跑一个 baseline，用 sentence-transformers 做文本嵌入。"

你知道 sentence-transformers 是什么，你甚至读过它的论文。但当你真正坐下来写代码，问题来了：这个包的 API 是 SentenceTransformer 还是 SentenceTransformers？预训练模型名是 all-MiniLM-L6-v2 还是 all-mpnet-base-v2？输入要不要先 tokenize？batch size 设多少才不会 OOM？GPU 不够的时候怎么用 model.encode 的 device 参数？

你开始试错。第一次跑报错，改参数，再跑，再报错。两小时后你终于跑通了，但你的预算——导师给你的那台机器的 GPU 时间——已经烧掉了一半。

现在把"实习生"换成"自主研究 Agent"。

GPT-5.5 搭配 Codex harness，理论上能读论文、写代码、跑实验。但面对 sentence-transformers，它和你一样：知道这个包存在，不知道怎么正确使用。区别在于，Agent 的试错成本以美元计——每一次失败都是 token 和 API 调用费用。

这篇论文（arXiv: 2609.02749）解决的就是这个问题。它的核心论点只有一句话：Agent 缺的不是更强的模型或更好的 harness，而是一层"操作知识"。

三层架构：模型、harness、还有什么？

论文把当前 Agent 架构拆成两层：

• 模型层（M_θ）：LLM backbone，提供理解、推理、规划能力。模型越强，能力越广，但它的先验是"广而固定"的——训练时见过的东西记得住，没见过的包和 API 就得现猜。
• harness 层（H）：编排层，控制 Agent 怎么探索、怎么记忆、怎么迭代。harness 越精，流程越顺，但它"控制过程，不提供领域内容"。

这两层之间有个缝隙。模型知道"transformer 是什么"，harness 知道"先读文档再写代码"，但"transformers 这个包的 AutoModelForSequenceClassification 在什么场景下用、怎么配置、有哪些坑"——这种知识既不在模型的先验里，也不在 harness 的流程里。

论文把这层缺失的东西命名为操作知识（Operational Knowledge）：

Operational knowledge is what separates knowing a method from making it work.

一句话：知道一个方法"是什么"和"怎么让它跑起来"是两回事。前者是论文里写的，后者是 GitHub issue 里堆的。

这个观察本身不算新颖——任何做过工程的人都知道"理论"和"实操"的鸿沟。但论文的贡献在于：它把这层知识形式化了，并且给出了一个可扩展的生产方案。

DisCo：从仓库到技能的四步蒸馏

论文提出的 Agent 叫 DisCo（Distill and Conduct），它做两件事：生产技能和使用技能。

生产技能的过程叫"技能蒸馏"（Skill Distillation），分四步：

锚点 → [scope 范围] → [ground 接地] → [construct 构造] → [verify 验证] → (技能图, 构造记录)

用一个类比：你在给一个新员工写 onboarding 文档。

1. Scope（范围）：先看这个仓库/论文/教程"能做什么"。比如 sentence-transformers 能做文本嵌入、语义搜索、聚类。这一步决定"要写哪些技能"。
2. Ground（接地）：从仓库的 README、文档、示例代码、测试里收集证据。不是让 LLM 凭空编，而是从真实代码里提取。
3. Construct（构造）：把证据打包成技能。每个技能有三层（后面细说）。
4. Verify（验证）：跑一遍，看技能里的脚本能不能真正执行。失败就局部修复，再跑。

四步回答四个问题：哪些能力重要？什么证据支持它们？怎么变成技能？这些技能靠不靠谱？

两种蒸馏模式

DisCo 有两种触发方式：

• 任务无关蒸馏（task-agnostic）：锚点是一个仓库/论文。比如把 sentence-transformers 整个仓库蒸馏成一组技能，存到库里，任何任务都能用。这是"提前备课"。
• 任务导向蒸馏（task-oriented）：锚点是一个具体任务。比如"在 MLE-bench 的第 42 题上做模型训练"。Agent 先分析任务需要什么能力，发现自己缺什么，再去搜索相关仓库和论文，现蒸出现用。这是"临时抱佛脚"。

两种模式互补：前者构建通用库，后者补长尾任务。

技能的三层结构：SKILL.md + references + scripts

这是整个工作里我最喜欢的部分。每个技能的物理结构是：

skill/
├── SKILL.md          # 知识接口（唯一一开始就读的文件）
├── references/       # 知识基底（按需加载）
└── scripts/          # 执行接口（可直接调用的脚本）

SKILL.md 是入口：它说明这个技能"是什么、什么时候用、怎么用"。Agent 一开始只读这个文件。

references/ 是深层材料：API 文档、参数配置、算法细节。只有当 SKILL.md 觉得"这里需要更多信息"时，才加载对应的 reference。

scripts/ 是可执行封装：Agent 直接调用，不用自己重写。

这个设计直接来自 Anthropic 的"Agent Skills"理念，核心原则叫渐进式披露（Progressive Disclosure）：

Agent 可以持有数千个技能，但每次只读当前任务需要的几个。

为什么这很重要？因为 LLM 的上下文窗口是有限的。如果把 1000 个仓库的文档全塞进去，上下文就爆了。渐进式披露让 Agent 像"查字典"一样：平时只看目录（SKILL.md），需要时翻到对应页（references），需要动手时直接用工具（scripts）。

技能图：一个仓库不是只有一个技能

一个仓库（比如 sentence-transformers）通常包含多个功能：嵌入、相似度计算、交叉编码、模型微调……论文把这些组织成技能图：

• 一个入口技能说明仓库范围，路由到各个组件技能
• 组件技能之间有路由、依赖、组合关系
• 图可以只有单个节点，也可以是复杂的多节点图

这比"一个仓库一个文档"灵活得多。Agent 可以只加载"嵌入"技能，不用管"微调"那部分。

AREX-Skill Library：5000+ 技能，1000 个仓库

论文的最大工程产出是 AREX-Skill Library：

• 5,353 个技能，从 1,000 个 ML 仓库蒸馏而来
• 组织成 20 个领域和 178 个能力族
• 每个仓库平均花费约 40 美元（用 GPT-5.5/5.6-sol xhigh reasoning）
• 覆盖模型实现、训练部署、数据评估、科学软件

20 个领域包括什么？论文没全列，但从上下文推断有 NLP、CV、RL、优化、数据工程等。178 个能力族更细：比如"文本嵌入"、"图像分类"、"分布式训练"这种粒度。

仓库可以属于多个能力族（700 个仓库出现在多个族里），所以分类是重叠的而非互斥的——这比硬性单分类更符合现实。

路由器：从 5000 个技能里找到对的那一个

有了 5000 个技能，怎么让 Agent 找到需要的那个？论文用一个两级路由器：

1. Agent 先看领域（20 选 1 或几个）
2. 再看能力族（178 选 1 或几个）
3. 打开对应的仓库技能图
4. 加载需要的具体技能

这就像图书馆的分类系统：先找"计算机科学"书架，再找"机器学习"分区，最后抽出需要的那本书。Agent 不需要扫描所有 5000 个技能的 SKILL.md，只需要读路由器的描述和几个候选技能的 SKILL.md。

实验结果：不换模型，只加技能

实验设计很干净：固定 GPT-5.5 + Codex harness，唯一变量是有没有技能。

MLE-bench（75 个 Kaggle 竞赛）

总体提升 134.3%（31.11% → 72.89%），而且超过了所有公开 baseline，包括用定制 harness 的系统。

最惊人的是 High 难度组：13.33% → 62.22%，相对提升 366.8%，接近 5 倍。难度越高，操作知识的价值越大——因为高难度任务正是"知道方法但不知道怎么用"的坑最多的地方。

PaperBench（20 篇论文复现）

平均复现分从 29.45% 提升到 39.59%（+34.4%）。20 个任务中 18 个提升，2 个下降。

一个有趣的规律：baseline 越低的任务，技能提升越大。比如 ftrl 任务从 1.50 涨到 17.17（11.4 倍），rice 从 7.94 涨到 48.51（6.1 倍）。而本来就能跑好的任务（如 all-in-one 52.93 → 54.70），提升很小。

这说明技能解决的是"不知道怎么用"的问题，不是"不会做"的问题。

FrontierCS 和 PassNet

• FrontierCS +9.2%（且有更强的 score-efficiency frontier）
• PassNet +14.0%（超过 TorchInductor 的聚合分）

工程洞察：为什么这比"换更强的模型"更划算

1. 操作知识是可复用的，token 不是

Agent 每次任务都从零开始试错，烧的是 token。技能蒸馏一次，用无数次。论文算了一笔账：每个仓库蒸馏花 40 美元，1000 个仓库共 4 万美元。但这个库可以在 MLE-bench、PaperBench、FrontierCS、PassNet 上反复用，每次任务省下的试错 token 远超蒸馏成本。

2. 不需要改模型，不需要改 harness

这是论文最强调的点：所有提升都来自"加操作上下文"，模型和 harness 完全不变。

Harnesses specialize how an agent researches, while distilled skills specialize what it knows to consider when research begins.

harness 管"怎么研究"，技能管"研究开始前知道什么"。两个维度正交，可以独立优化。

3. 渐进式披露是可扩展性的关键

5000 个技能如果全塞进上下文，任何模型都会爆。渐进式披露让 Agent 每次只读 2-3 个 SKILL.md（几百 token），需要时再深入 references。这意味着技能库可以无限增长，而 Agent 的单次推理成本不变。

4. 验证是技能可信度的基石

每个技能在入库前都经过验证：跑 assertion-backed 测试、CLI 检查、smoke scripts。失败就局部修复。这保证了技能里的脚本真的能跑——不是 LLM 凭空编的"看起来对"的代码。

这直接回应了"LLM 生成的代码不可信"的批评：技能不是生成完就入库，而是生成→验证→修复→入库。

一个更深的洞察：知识的三种形态

这篇论文隐含了一个知识分类框架：

当前 Agent 的问题是把声明性知识当操作知识用——让 LLM 读论文然后自己推断怎么用。这就像让一个只看过菜谱的人去炒菜：菜谱写了"盐少许"，但"少许"是多少，只有炒过菜的人知道。

技能蒸馏的本质是把人类专家的隐性知识外化为 Agent 可直接执行的显性知识。这和知识管理领域的 SECI 模型（Socialization-Externalization-Combination-Internalization）异曲同工：隐性知识→显性知识的转化是知识规模化的瓶颈。

和 Anthropic Agent Skills 的关系

这篇论文不是凭空出现的。Anthropic 在 2025 年提出了 Agent Skills 概念，论文直接引用并采用了它的三层结构（SKILL.md + references + scripts）。

但 Anthropic 的 skills 是手写的——人类专家写 SKILL.md、整理 references、封装 scripts。这篇论文的贡献是自动化这个过程：用 LLM 从仓库自动蒸馏技能，规模从"几十个手写技能"扩展到"5000+ 自动蒸馏技能"。

这和 step子哥你在折腾的 cangjie-skill 方向完全一致——方法论蒸馏。区别在于 cangjie-skill 蒸馏的是"怎么写 skill"的元方法论，AREX-Skill 蒸馏的是"怎么用某个具体仓库"的操作知识。两者互补：cangjie-skill 教 Agent "怎么蒸馏技能"，AREX-Skill 是"蒸馏出来的技能库"。

局限和开放问题

论文也坦承了一些局限：

1. 2/20 个 PaperBench 任务在加技能后反而下降。原因是检索精度不够——技能内容偶尔会"分散注意力"。这说明路由器还有优化空间。
2. 任务导向蒸馏的技能是"描述性"的而非"可执行"的。MLE-bench 的技能是描述性的（告诉 Agent 怎么做），而不是可执行脚本（直接帮 Agent 做）。因为竞赛环境的多样性使得通用脚本难以覆盖所有情况。
3. 成本：每个仓库 40 美元，1000 个仓库 4 万美元。对个人开发者不便宜，但对机构是合理的。
4. 覆盖范围：1000 个仓库是 ML 领域的"常用"子集，不是全生态。长尾仓库仍需任务导向蒸馏补位。

我的思考：这指向什么

这篇论文让我想到一个更大的趋势：AI 系统正在从"单一模型"走向"模型 + 工具 + 知识库"的三元架构。

• 2023 年：一个 GPT-4 搞定一切
• 2024 年：GPT-4 + 工具调用（function calling）
• 2025 年：GPT-4 + 工具 + 手写 skills（Anthropic Agent Skills）
• 2026 年：GPT-5.5 + 工具 + 自动蒸馏的 5000 技能库（AREX-Skill）

每一层都在回答前一层解决不了的问题：模型不够强就加工具，工具不够智能就加 skills，skills 不够多就自动蒸馏。

更深一层：知识的载体正在从"为人类写的文档"转向"为 Agent 写的技能"。GitHub 仓库的 README 是给人看的——它假设你能推理出"这个参数在什么场景下设多少"。技能是给 Agent 看的——它直接告诉你"在 X 场景下用 Y 值，因为 Z"。

这不只是格式转换，而是知识表示的范式转移。就像编程语言从汇编到高级语言：高级语言不改变计算机的能力，但它让人类能表达的复杂度上了一个数量级。技能不改变 LLM 的能力，但它让 Agent 能调用的操作粒度上了一个数量级。

未来，每个成熟的 GitHub 仓库可能都会附带一个 skill/ 目录，就像现在都有 README.md 一样。README 给人看，skill 给 Agent 看。谁先做这个，谁的工具就会被 Agent 优先使用。

开源代码

• AREX-Skill 仓库：https://github.com/VectorSpaceLab/AREX-Skill
• 许可证：Apache 2.0
• 支持：Codex、Claude Code、Pi 等主流 coding agent
• 论文：arXiv:2609.02749

论文信息

• 标题：Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills
• 作者：Jianlyu Chen, Yuyang Hu, Hongjin Qian, Jiawei Liu, Wenqing Wei, Xiaolong Chen, Defu Lian, Zhong Liu 等
• 机构：中科大、人大、BAAI 等
• arXiv：2609.02749 (2026-09-02)

一句话总结：给 Agent 一本操作手册，比给它一个更强的脑子更管用。5000 个技能让 GPT-5.5 在 MLE-bench 上提升 134%，而且不换模型、不换 harness、不换预算。知识的形态决定了知识的价值——为 Agent 写的技能，比为人写的文档更值钱。