网上有海量的软件教学视频、代码仓库、教程文章，但Agent没法直接用。微软这篇论文做了一件事：把它们蒸馏成一个可检索、可执行、可自增长的Skill Wiki，让Agent学会操作PPT、Excel、Blender、UE5。

Part 01

最好的教程摆在那，Agent却看不到

教人用Blender做一段动画，YouTube上一搜几百个视频。录屏里操作步骤清清楚楚：点哪个菜单、拖什么参数、时间轴怎么拉、最终渲染出来什么效果。人看着就能学。

Agent不行。

你把一个20分钟教学视频链接塞给Agent，它不会"看"。顶多读一下标题和简介，然后拿预训练时见过的代码片段硬凑方案。方案常常语法正确、跑得通，但做出来的东西完全不对，那些"只能通过看来传达"的信息它完全没拿到：操作顺序、界面反馈、前后对比效果、动画节奏。

文本教程也一样。一篇教程告诉你"选中对象后按G键再输入数值可以精确移动"，但不会告诉你移动之后场景应该是什么样。代码仓库告诉你bpy.ops.mesh.primitive_cube_add() 能创建立方体，但不会告诉你在哪个位置放、配什么材质、打什么光。

这就是RESOURCE2SKILL要解决的问题：把多模态的人类创作资源，如教学视频、代码仓库、文章、参考作品，自动蒸馏成Agent能理解、能检索、能执行的技能。 不是让Agent看原始视频，而是把视频里的操作知识提出来，组织成一个结构化的技能库。

Part 02

四步管线：构造、组织、选择、执行

RESOURCE2SKILL的pipeline分四步。没有追求端到端的"让模型看懂视频"，而是用一个可控的、可审计的工程管线把问题拆开做。

2.1 第一关：从四种资源里提取技能

系统从四个来源获取素材：教学视频、代码仓库、文章教程、参考作品。每个来源提供不同的信息，视频捕获操作顺序和视觉效果，代码提供可执行的调用模式，文章解释概念和适用场景，参考作品提供风格和质量基准。

提取过程由领域特定的查询驱动。不是把视频全部看一遍，而是针对每个领域的关键操作发起定向搜索，比如"Blender 材质节点编辑""Excel数据透视表""PPT动画时序"。搜到的资源交给一个视觉语言模型，由它提取关键帧、代码片段、文字描述和元数据，拼成结构化技能条目。

每条技能不会直接入库。它们先过五道质量检查：条目是否完整、来源是否可追溯、是否跟已有条目重复、多模态信息是否一致、代码字段能否在目标环境中执行。通不过的直接丢。这个质量门槛是整套系统能稳定工作的前提——没它，低质量信息会把后面的检索和选择全拖垮。

2.2 第二关：用Wiki树组织技能

最容易想到的做法是把所有技能平铺成一个列表，检索时走语义搜索。但RESOURCE2SKILL的实验结果是：flat list比层级Wiki低了 2.5 到 8.2 个百分点。 差距最大的领域恰好是那些"需要按类别理解操作"的，Excel的公式模式和图表设计是两回事，PPT的排版和动画也互相独立。技能平铺，"图表"和"公式"会互相干扰；用 Wiki 树把父子关系、兄弟关系、层级路径全保留下来，顺着树走，候选池的精度大幅提升。

每个领域有自己的分类体系。PPT按版面、字体、色彩、图表、动画组织；Blender按几何、材质、光照、相机组织。分类法各不相同，但浏览和读取的接口统一，下游Agent不需要理解每个领域的特殊结构。

每个技能条目包含三个互补字段：文本字段解释"这个技能做什么、什么时候用"；视觉字段提供缩略图、截图、渲染预览；代码字段包含可直接执行的程序片段。 文本管"是否适用"，视觉管"目标长什么样"，代码管"具体怎么调"。如果只保留纯文本，平均分直接掉 3.9 个点。

2.3 第三关：METABROWSE两层选择

Agent面对用户请求时怎么从几千条技能里挑？METABROWSE 分两步。

第一步，词汇层初筛：BM25对技能名称、标签、适用描述和层级路径做关键词匹配，从几千条缩到20条候选。层级路径是这里的关键，Wiki树已经把技能归好了类，用户要"做 PPT封面"，BM25顺着 PPT → 版面 → 封面 把相关技能顶上来，而不是在全库里乱撞。

第二步，语言模型精选：20条候选的结构化evidence交给语言模型，让它决定选哪些来组合。注意：模型做的是子集选择，不是排序。可以选 0 条（没一个有用），选 3 条（排版+配色+字体组合），选 5 条。不是"必须喂top-K"，所以不会强行塞进不相关的技能。

两层各解决一个瓶颈：词汇层解决"从几千条快速缩小范围"的效率问题，BM25在这个任务上比向量检索高了 2.9 个点；语言模型层解决"语义理解和互补性"的精度问题，纯词汇检索丢掉的Excel公式上下文、设计搭配逻辑，语言模型能补回来。

2.4 第四关：执行与在线补漏

选好技能后，Agent通过MCP协议直接调用领域后端工具。技能里的代码直接执行，语言模型不在"选中技能"和"执行代码"之间再做翻译，保证代码原始意图不会被LLM改写偏差破坏。参考型技能（没代码、只有文字和视觉描述）也能用：Agent根据文字和视觉参考自己写代码，来源始终保留在技能 ID 里可审计。

离线库总会漏掉一些用户真正需要的操作。RESOURCE2SKILL的处理很务实：离线不够的时候，同一套提取管线在线补。 在标准测试集上（离线库已覆盖很好），在线补漏只加了 0.7 个点，基本是噪音。但在刻意构造的"离线库覆盖不到"的测试集上，100 条在线技能把分数从 41.2 拉到 62.8 —— +21.6 个点。 在线补漏是gap-filler，不是booster。平时不动，碰到能力缺口才触发。

Part 03

用数据来说话

七个领域，四个模型，28 个格子全赢

RESOURCE2SKILL在七个创意软件领域做了系统评测：PPT设计、Web页面、Excel制表、Blender 3D场景、CAD二维绘图、UE5实时 3D、Reaper音频制作。四个模型后端全扫：GPT-5.5、GPT-5.4、GPT-5.4 Mini、GPT-5.4 Nano。

主对照把四个系统放一起比：WSKILLS（完整 RESOURCE2SKILL）、W/OSKILLS（同一个 Agent 但没技能库）、Claude Code 和 Codex 的 harness 版本。结果：WSKILLS 在所有 28 个模型-领域组合里全部赢过 W/OSKILLS，平均 56.8% vs 45.0%，+11.9 个百分点。 跟最强的 harness 线比，26/28 个格子仍是 WSKILLS 赢。人类偏好盲测——五名评审 40 个配对——WSKILLS 赢了 83.3% 的非平局。

提升最狠的是UE5（+30~40 个点），因为裸 Agent 几乎无法通过 UE5 Python API 拼出可评分场景。提升最小的是 Reaper，裸 Agent 在音频上本来就有个不错的 baseline。

规模不需要太大，选择策略是关键

技能库多大才够？论文做了一个缩放实验：从 0 条到 200 条，性能单调上升，前 200 条增益最大（Excel +14.2 个点，最少的Reaper 也 +3.1）。200条之后增速放缓，400条之后再往全量加收益几乎持平。曲线在 200 条附近就开始饱和，覆盖常用操作不需要海量数据。

选择策略方面比了六种：METABROWSE（层级 + BM25 + 语言模型选择）、纯BM25、纯向量检索、BM25+向量混合、随机采样、无技能baseline。METABROWSE在所有领域里排第一（平均 68.9%），比纯BM25高 2.9 个点，比 BM25+向量混合高 4.7 个点。

纯向量检索最差（60.0%），只比随机采样（58.0%）高了不到两个点。这跟很多人的直觉反着来，在结构化技能库的场景里，关键词匹配比语义向量更有效。 技能的名称、标签、适用场景描述本身就是精炼过的自然语言，不需要再多一层向量映射。

Part 04

这意味着什么

这篇论文不是又一个"用LLM提取知识"的故事。它在回答一个更根本的问题：Agent的技能库应该怎么建？

两端用同一套提取管线，不因为在线离线而换接口。

几个工程选择值得单独说。层级Wiki比flat list好，不是因为"树结构更优雅"，而是因为检索时它把语义空间约束到了相关子树，一种结构化的稀疏性，比向量检索的数学稀疏性更可控。多模态条目不是"文本不够图来凑"：文本判断适用性，视觉锚定目标，代码落地执行，三个视图各有各的活，不互相替代。在线补漏不搞"每次跑都搜一下"，只在离线库确实覆盖不到时才触发。

最容易被忽视的是质量门控。五道检查：完整性、可追溯性、去重、多模态一致性、可执行性，是整个系统能稳定运转的底座。

如果说Anthropic的Agent Skills定义了"技能应该长什么样"，那RESOURCE2SKILL在回答"技能应该从哪来"。视频教程、代码仓库、技术文章、参考作品——这些东西网上到处都是。能不能把它们变成Agent的能力，取决于你用什么质量的管线去提取、用什么样的结构去组织、用什么样的策略去检索。

PS：

更多Agentic AI技术前沿分享，欢迎扫描下方二维码进入技术交流群（或者添加群助手ID：qstarsky 邀请您进群交流）

Agentic AI

相关链接