把教程视频蒸馏成Agent可执行技能：Resource2Skill让软件Agent在7个创作领域平均涨11.9个点

你有没有这种感觉：让 GPT-5.4 帮你做一个 UE5 场景，结果丢给你一个空荡荡的工程文件，连基本的光照都没加；让它做一份"全公司季度汇报"PPT，结果排版稀烂、信息密度感人；让它做一份"实时数据仪表盘"的 Excel，公式能写但图表跑出来根本不对。

我前阵子也在调这种"商业软件操作类"agent——写代码本身没问题（GPT-5.4 在 Codeforces 上早就及格了），但让它去用 Blender、Excel、UE5、Reaper 这样的"商业软件"完成任务，它就懵了。不是因为它不会写代码，而是因为它不知道这些软件里那些说不清的行业惯用法——什么工具该用、什么参数该调、什么步骤是隐含但必做的、什么中间结果该 inspect。

微软研究院（Microsoft Research）联合 UC Santa Cruz 和上海交大最近发了一篇论文 RESOURCE2SKILL（arXiv: 2606.29538），想做的事一句话讲清楚：把 YouTube 教程、代码仓库、技术文章、参考制品这些"人类干活时留下的多模态材料"，自动蒸馏成 Skill Wiki，让 Agent 在执行时按需调用。

光看主表数据就挺猛——在 4 个 GPT-5 系列后端 × 7 个创作领域（PPT、Excel、Web、Blender、Reaper、CAD、UE5）的 28 个 main-aggregate cell 中，w/ Skills 全部胜出 w/o Skills，平均提升 11.9 个点；拿现成的 Claude Code 和 Codex harness 做 baseline，w/ Skills 在 26/28 个 cell 仍然更优。我自己的第一反应是：这是不是又在刷榜？

继续看消融就发现不是。它的 ablation 设计特别干净——视频源的不可替代性、多模态格式（text/visual/code）的边际收益、hierarchy-then-LM 选择策略对 BM25/Embed 的压制、库规模饱和点、在线获取机制的真正作用——每一项都做了 matched-budget 控制。这不是又一个把"加 RAG"包装成核心贡献的论文。

论文信息

• 标题：RESOURCE2SKILL: Distilling Executable Agent Skills from Human-Created Multimodal Resources
• 作者：Yijia Fan¹, Zonglin Di², Zimo Wen³, Yifan Yang¹, Mingxi Cheng¹, Qi Dai¹, Bei Liu¹, Kai Qiu¹, Yue Dong¹, Ji Li¹, Chong Luo¹
• 机构：¹ Microsoft Research ² University of California, Santa Cruz ³ Shanghai Jiao Tong University
• arXiv：2606.29538（v1 提交于 2026 年 6 月 28 日，最新版本 v4，2026 年 7 月 17 日）
• 代码：https://aka.ms/Resource2Skill

这篇论文到底在解决什么

说实话，"让 Agent 拥有技能库"这件事并不是新点子。Voyager 在 Minecraft 里早就用 GPT-4 自我生成 JavaScript 技能代码了；SkillFlow 在 166 个任务基准上把 Claude Opus 成功率从 62.65% 提到 71.08%；Anthropic 去年 10 月也搞了 Agent Skills，本质形态是一个 SKILL.md 文件夹，用三层渐进式披露（metadata / instructions / additional files）按需加载。

但 R2S 抓住了一个被严重忽略的痛点：现有 skill 库的源材料太"单薄"了。

• 人类工程师真正常用的资源形式是什么？教程视频——B 站/YouTube 上教 Blender、UE5、Excel 高级玩法的视频一大堆。
• 视频能告诉你什么？操作的时间顺序、视觉变化、参数怎么试出来的、设计选择背后那些"说不清道不明"的 tacit knowledge。
• 现有方法怎么用视频？要么直接当 pretraining 数据（代价高、效率低），要么 ASR 抽文本（丢掉了视觉信号），要么干脆不用。

R2S 的核心问题因此可以一句话概括：能不能从教程视频、代码仓库、技术文章、参考制品这些多模态人类资源里，自动蒸馏出一个结构化、可检索、可执行的 Skill Wiki，让商业软件 agent 在执行时按需调用？

图1：左半边是7个创作领域（Web/Excel/PPT/Blender/UE5/Reaper/CAD）的"带技能 vs 不带技能"对比渲染图。右半边是4个系统（w/ Skills 绿、w/o Skills 红、Codex-H 蓝、ClaudeCode-H 紫）在7个 domain 上的雷达对比图。雷达图清楚显示 w/ Skills 在每个 domain 都包住 w/o Skills。

作者做了一个关键观察：教程视频里真正有用的不是整段视频，而是几个关键帧 + 操作序列。一段 10 分钟的 Blender 教程，可能只有 30 秒是真正讲材质贴图的关键步骤；其他都是"准备工程文件"这种冗余。所以直接喂视频给 agent 是不行的，必须做"程序化信号提取"。

方法：四阶段统一 pipeline

R2S 的方法可以拆成四阶段，但有个关键设计：构造（construction）和在线获取（online acquisition）共用同一个算子——也就是说"蒸馏"这件事离线、在线都能用，不存在两套 pipeline。

图2：完整 pipeline。从左侧 1.Sources（视频/代码/文章/参考制品四类资源）开始，经过 2.Parse & Distill（提取关键帧、代码段、文本），进入 3.Quality Gates（去重/完整性/可执行性/安全），落进 4.LM Wiki（每个 skill 含 Text/Visual/Code/Metadata 四视图）。右侧 5.Skill-Grounded Agent 用 MetaBrowse 检索并组合 skill，通过 6.Domain Adapter 翻译到 7.Domains（PPT/Web/Excel/Blender/UE5/Reaper/CAD），产出 8.Rendered Outputs。下方是 Benchmark Protocol。

1. 多模态 Skill Wiki

每个 skill 是个五元组：

• \(p\)：领域特定分类树（taxonomy）里的路径。比如 PPT 里"layout / typography / motion"是一个子树，Blender 里"geometry / material / lighting / composition"是另一个。
• \(x_{\text{text}}\)：技能名、机制描述、适用场景、输入输出、预期效果。
• \(x_{\text{visual}}\)：缩略图、关键帧截图、渲染预览、示意图。
• \(x_{\text{code}}\)：可执行或可改写的 procedure 片段（纯参考型 skill 可以为空）。
• \(m\)：元数据，含 tier、category、tags、source、exec_ok、provenance。

关键设计点是多模态视图互补：文本负责"为什么这么做"，视觉负责"做出来长什么样"，代码负责"怎么在工具里执行"。这三者都不能单独 hold 整个任务。

2. Resource-to-Skill Construction

构造算子 \(\left(f_\theta, A_{\mathcal{D}}\right)\) 把多模态资源映射到候选 skill 集：

• \(f_\theta\)：多模态 distiller，用视觉 LM 提取关键帧 / 代码段 / 文本段落 / 渲染样本，按 wiki schema 蒸馏成 \((p, x_{\text{text}}, x_{\text{visual}}, x_{\text{code}}, m)\)，再做 normalize。
• \(A_{\mathcal{D}}\)：领域特定的接受谓词，五道硬门槛——completeness / traceable provenance / deduplication / modality consistency / 结构可执行性。

我不喜欢把这部分讲得太轻描淡写——这个"normalize + 五道门"是整个系统能 maintainable 的根本。光有 LLM 蒸馏不设门槛，wiki 会很快被噪声塞满；没有可追溯的 provenance，后续审计和删改都做不了。

3. MetaBrowse：hierarchy-then-LM 选择

agent 拿到一个 user brief \(q\)，要选一个子集来组合。R2S 设计了一个两阶段选择器：

第一阶段是 BM25 粗筛。关键点：BM25 的 query 不只是 skill name，而是 name ⊕ tags ⊕ applicability ⊕ taxonomy path $p(s)$，即把路径拼进去：

把 taxonomy 路径拼进 query 是这篇的一个小巧思——它让 BM25 天然偏向"在主题相关子树里的 skill"，相当于一种隐式的 hierarchical prior。

第二阶段 LM 精排，从 \(\mathcal{C}_K(q)\) 里选子集：

LM 看的是 structured evidence（meta + text + visual + code，按当前配置暴露）。注意这里是子集选择而不是排序——LM 可以选 0 个 skill（如果没合适的）。

4. 执行与在线获取

wiki 侧通过 MCP 暴露三类发现动作：list categories / list skills / read per-modality content / BM25 search。domain 侧通过一个统一的 apply action 暴露领域能力，能力缺失会返回 structured not-applicable。

最有意思的是在线获取的设计哲学。当 \(\mathcal{C}_K(q)\) 找不到合适 skill 时，同一个 \((f_\theta, A_{\mathcal{D}})\) 算子被调用——只是查询从离线库换成在线检索，返回的资源被蒸馏成临时 candidate，\(A_{\mathcal{D}}\) 验证后暴露为单独的 online pool。

注意："offline pool 和 online pool 始终隔离"。这是论文里反复强调的设计点——online 不污染 offline，online 是 controlled gap-filler，不是"context 灌满"。

实验：主对比的硬数据

设置

• 7 个 domain：PPT（slide 设计）、Excel（电子表格）、Web（HTML/CSS/JS）、Blender（3D 场景）、Reaper（音频制作）、CAD（2D 绘图）、UE5（实时 3D）。
• 4 个后端：GPT-5.5、GPT-5.4、GPT-5.4 Mini、GPT-5.4 Nano。
• 4 个系统：w/ Skills（完整 R2S）、w/o Skills（同一 agent + 自由 code，但不用 wiki）、ClaudeCode-H、Codex-H（注意 H 是 harness 不是 human rater）。
• 任务 brief：每个 domain 80 条匹配 brief（main comparison），所有条件共享 brief ID，差异是 paired 的。
• 打分：非音频用 GPT-5.4 vision judge，Reaper 用 GPT-4o 音频 judge。每个 domain 自有 5 个评估轴（如 PPT：layout quality / content density / theme coherence / typography hierarchy / overall polish），rubric 0-10 转百分比。

主对比表（GPT-5.5 / GPT-5.4，截取核心 cell）

几个让我真的愣一下的观察：

1. w/ Skills vs w/o Skills：所有 28 个 main-aggregate cell 全部胜出，平均 +11.9 pp。Wilcoxon 配对检验 p < 10⁻⁹（部分 p < 10⁻¹⁴），不存在"统计侥幸"。
2. w/ Skills vs 两个 harness baseline：26/28 个 cell 胜出。两个例外（GPT-5.5 Web vs ClaudeCode-H、GPT-5.4 Nano PPT vs Codex-H）都不到 1 个点的差距，论文直接说"within one point"。
3. lift 集中在"约定密度大"的领域：UE5 上 +30 到 +40 pp（GPT-5.4: 29.1 → 67.3，+38.2），Blender +14.6，Web +14.0，CAD +7.0。反直觉的是 Reaper 提升最小（+4.1），原因是"Reaper 在中等复杂度上 free-form agent 已经有比较强的 prior"。
4. 所有 backbone 都成立：Nano 也能拿到 +11 pp，Mini 也能拿到 +9 pp，5.5/5.4 维持 +14 pp 左右。说明这不是只有大模型才能用的奢侈品。

一个关键 case

图3：Blender "emerald jewelry hero shot" 任务。左边 w/ Skills（score 6.78）能渲染出完整场景——金色戒指、宝石、柔光、阴影、玻璃罩都到位；右边 w/o Skills（score 1.14）只剩个光秃秃的几何体，没什么可看的。delta +5.636。

这个 case 是"对设计知识依赖度高、对 API 知识依赖度更高"的典型——free-form agent 不是不会写 bpy 代码，而是不知道"hero shot" 的灯光、材质、镜头该怎么配。skill 把这些 tacit knowledge 显式化了。

人评 A/B Study

5 个 rater × 40 个匹配 pair × 7 个 domain = 200 个配对评分。

人评方向和 judge 数字一致，而且 w/ Skills 在 7 个 domain 全部胜出，没有"数字好看但人觉得差不多"的情况。

消融实验：每一项设计都有价值

这部分是论文我最欣赏的地方。每一个 ablation 都有"matched-budget"控制——改一个变量、冻结其他所有变量。

1. 视频源的不可替代性

四种资源：Video / Code / Article / Artifact。组合 ablation 测了 6 种 source mix：

关键发现： - 移除视频（用 Code+Article+Artifact 三源）平均直接从 68.9 掉到 59.4，掉了 9.5 个点。Excel 单域 -14.2、Web -11.5，集中在"需要时序操作和视觉过渡"的场景。 - 单独用视频（只有 video 源）仍然能拿到 66.8——比"三源无视频"还高 7.4 个点。说明 video 的程序化信号不能被 text/code/article 简单替代。 - 四源全开比最强二源组合多 0.3 到 0.9 pp。video 是必需，diversity 是保险。

2. 多模态格式的边际收益

固定所有变量（同样的资源池、同样的接受 skill ID、同样的 wiki frontmatter、同样的 BM25+LM 预算、同一个 GPT-5.4 agent），只改暴露给 agent 的内容模态：

text-only 已经 65.0——因为它继承了 applicability 和 routing cues（其实已经是个强 curated text-memory baseline）。Visual +1.9、Code +2.0、Full +3.9。每一个模态都在贡献独特价值，不是"加了等于没加"。

3. hierarchy-then-LM 选择策略的压制

6 种选择策略在 matched-budget 下对比：

几个判断： - Random-FullPool 比 No-Skill 只高 0.7——把 skill 库当噪声采样基本没用。这反过来证明选择策略是整个系统的关键，不是 skill 库本身。 - Embed 单独用最差，分数 60.0——dense retrieval 在 skill 这种"过程性知识"上的语义对齐其实不好。 - Ours 对最强 retrieval baseline（BM25）平均 +2.9，PPT 单点 +3.8、Excel +5.0、Blender +2.3。这意味着"任务适配和互补性"是纯检索抓不住的——必须 LM 来选。

4. 库规模饱和点

固定 agent / judge / brief / wiki 接口，库从 0 涨到 full pool：

• 0 → 200 这段收益最大（Reaper +3.1 到 Excel +14.2）。
• 200 之后曲线变平；400 → full 这步每域最多 +0.8 pp。
• 饱和点大约在 200。这其实对"建一个 skill 库要花多大成本"是重要参考——不用攒到 5000 也能拿到 95% 的增益。

5. 在线获取的真实作用

T_standard（标准基准）：online 只 +0.7，几乎是噪声——离线库已经覆盖了大多数常见请求。 T_novel（针对离线库覆盖不足的能力设计的压力测试）：online +21.6 pp（41.2 → 62.8）。

结论非常清楚：online acquisition 是 gap-filler，不是 booster。这是个挺重要的认知——很多人会想"加 online 搜索总能变强"，但其实在常规任务上它没有 marginal value，只在离线库明确缺能力的场景才爆发。论文也据此把默认设置选成 Offline-only（避免不必要的 context 扩张）。

跟同期工作比，R2S 到底什么位置

Skill 库这个赛道不算新。我把几个最近的代表性工作摆出来对比：

R2S 的差异化很清晰：

1. 首次系统性地把教程视频作为一等资源——其他工作要么只用 agent self-trace，要么只用 text/code。
2. 首次在多模态 skill 上做了 artifact-level 评估（vision judge + audio judge），其他工作的评估多是任务完成度（pass/fail），不直接看产物质量。
3. offline + online 用同一个算子——避免"两套 pipeline"带来的维护负担。
4. hierarchy-then-LM 选择器——其他工作要么纯 retrieval，要么纯 LM selection。
5. 跨 7 个商业软件 domain 的实证——不是单域（Minecraft / Minecraft-like）而是真正不同的软件栈（PPT、Excel、Blender、UE5、Reaper、CAD、Web）。

但我必须指出几处需要警惕的地方：

• GPT-5.x 评测的争议。GPT-5.4 / GPT-5.4 Mini / GPT-5.4 Nano 是 OpenAI 闭源模型，论文没有公开 prompt、推理参数、judge prompt 的完整内容。读者要复现这个 +11.9 是非常难的。这也是为什么 skill 库赛道现在越来越像"在闭源模型上做 emipirical study"——可复现性堪忧。
• baseline 的"强"是相对的。ClaudeCode-H 和 Codex-H 是 harness baseline，不是 Claude Code 内部的"skill 增强版"。如果拿 Anthropic 自己的 Agent Skills（用 filesystem SKILL.md + 渐进式披露）来对比，R2S 还能不能 +11.9？这其实是个开放问题。论文 Related Work 里也承认这是 SkillFoundry-like 的方向。
• judge 的 bias。vision judge 是 GPT-5.4 自己评 GPT-5.4 生成的产物——有自我偏好的嫌疑。论文做了 human A/B study 作为交叉验证（85.5% win rate 跟 judge 数字方向一致），但人评只有 200 个 pair，置信区间不窄。值得在更大规模上验证。
• brief 的"wiki-blind" 是不是真的 wiki-blind。论文说 brief 作者是 blind to the wiki——但 brief 描述的是任务，wiki 里 skill 的 taxonomy 是 domain expert 设计的。brief 的语言分布会不会和 wiki 的语言分布天然对齐？这个我没法只看 paper 确认。

我的判断

这是一篇"工程整合 + 实证扎实"的论文，不是底层突破。

它的核心贡献是把"从多模态资源蒸馏 skill"这件事首次端到端跑通——offline 构造 + online 获取 + 层次化 wiki + 7-domain 评估 + matched-budget 消融。在 skill 库这个赛道上，R2S 比 Voyager 更通用（不只是游戏），比 Anthropic Agent Skills 更自动（不需要人手写），比 SkillFlow 更系统（不是 ad-hoc 修规则）。

但我不建议把它当成 skill 库赛道的终点——下面还有几个没解决的问题：

1. 视频蒸馏的成本。论文没说 construction operator 的总成本——跑一遍 \(f_\theta\) 蒸馏 891 个 skill 花了多少 token / 钱？如果是 10 万美元级别，那"做 skill 库"对中小团队来说还是奢侈品。
2. cross-domain transfer 没做。R2S 强调 7 个 domain，但没测"在 PPT 上训的 skill 能不能 zero-shot 转到 Keynote"——而现实里用户经常这么干。
3. skill 的更新机制。一旦 Blender 4.0 升到 5.0，wiki 怎么维护？论文里 wiki 是"frozen" 的，没有 versioning / migration 的讨论。生产环境一定会遇到。
4. 和 long context 的对抗。GPT-5.5 已经有 400K context，当模型够强时，skill 库是不是会被 raw context 取代？论文没正面回答。

如果让我用一句话总结给同行：这是 skill 库赛道的 industrial-grade 实证论文，对想认真做商业软件 agent 的团队有非常具体的工程参考价值；但不要把它当成 skill 范式的终极形态。

给工程团队的启发

如果你也在做商业软件 agent，R2S 给的启发不是"用 R2S"，而是几个具体可复用的设计原则：

• 不要把 skill 库当 prompt 拼接。wiki 结构（taxonomy path + text + visual + code + metadata）是直接给 retrieval 和 provenance 服务的——flat list + raw text 在 ablation 里已经输 2.5 到 8.2 pp。
• 教程视频是被严重低估的资源。如果你做的 agent 是 Blender / UE5 / 3D 工具类，专门建一个从 YouTube 教程里蒸馏 skill 的 pipeline——回报可能比你想的大。
• hierarchy-then-LM 比纯 retrieval 强。R2S 显示 BM25+Embed（dense rerank）反而比单独 BM25 还差（66.0 vs 64.2），而 hierarchy-then-LM 比 BM25 还高 2.9。给 LM 一个"已经粗筛过的 candidate set + 结构化 evidence"，比让 LM 在大库里搜靠谱得多。
• 库规模 200 是 sweet spot。不要追求 5000、10000 的库——200 左右拿到 95% 增益。
• online acquisition 是 gap-filler，不要当 booster 用。常规任务上让它跑是浪费 token，只在离线库明确缺能力的场景才调用。

论文：RESOURCE2SKILL: Distilling Executable Agent Skills from Human-Created Multimodal Resources 代码：https://aka.ms/Resource2Skill

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