一句话讲清楚👉🏻 微软研究院等提出 Resource2Skill ：把教程视频、代码仓库、文章等资源，整理成按类别组织、同时带文字截图和代码的技能库，让软件 Agent 在网页、表格、幻灯片、三维与音频等七个创作域上平均提升 11.9 个百分点。
论文标题：RESOURCE2SKILL: Distilling Executable Agent Skills from Human-Created Multimodal Resources
论文链接：https://arxiv.org/abs/2606.29538
主页链接：https://microsoft.github.io/Resource2Skill/
Github 链接：https://github.com/microsoft/Resource2Skill
让 Agent 真正做出一张像样的幻灯片、一个能跑的网页，或一个勉强能看的 UE5 场景，关键往往是可复用的操作经验：目标怎么拆、先调哪个接口、中间状态怎么检查、失败了怎么补救。这些经验，正是 Agent 技能库要沉淀的东西。
现有技能库多半来自专家手写、纯文本或代码检索，或 Agent 自己跑任务留下的轨迹。人类学软件时最常用的屏幕录制教程和演示视频，却很少被系统利用。视频里有操作顺序、界面反馈和「改完长什么样」这类文本很难写全的信息；把整段视频直接塞进模型上下文，既贵又充斥无关帧。 Resource2Skill 要做的，就是把这些材料压成 Agent 真能检索、组合、执行的技能条目。
七个创作域上，有技能与无技能的代表性产出对比，以及 GPT-5.4 后端下的雷达图分数。
一条技能里装了什么
每个技能是一条同时可含文字、画面和代码的条目，形式化写成
直觉上可以把它想成 Wiki 词条： 是分类路径（例如「 PPT / 版式 / 双栏对比页」）；文字部分写清何时用、输入是什么、预期效果；视觉部分放缩略图或前后对比截图；代码部分放可直接跑或可改写的脚本片段；元数据负责筛选、检查和追查来源。画面或代码可以为空——只当参考的条目仍然有用， Agent 对照文字和截图自己写代码，同时留下来源标识。
分类按软件各自的操作习惯来定：幻灯片按版式、字体、动效； Blender 按几何、材质、光照、构图。浏览与读取接口跨软件统一，换工具不必另学一套调用方式。
流水线总览：资源蒸馏进 Skill Wiki ， Agent 浏览并选取技能，经域适配器落到各软件后端，再渲染成最终产物。
把流程落到一次具体请求上会更清楚。用户说「做一页双栏对比的产品汇报幻灯片」。 Agent 先在 PPT 分类树里走到「版式」附近， BM25 再按关键词收窄；语言模型读几条候选的适用说明和截图后，可能组合「双栏网格」「标题层级」「强调色条」三几条技能。带脚本的条目直接经 MCP 改版式，只带参考图的条目则当作视觉约束，让 Agent 自己补写布局代码。两组都能吐出标题和正文，但无技能组常把两栏比例、标题层级和强调色处理得不一致；技能库把这些版式约定提前提供出来，成品才更接近产品汇报页。
从资源到技能：离线建库和在线补缺共用同一流程
整条系统拆成四段：构建、组织成 Wiki 、选取、执行。离线先把大批资源做成技能库；执行任务时如果库里没有合适条目，再用同一套「资源→技能」流程去搜材料、抽技能、验收入库。不必另写一套在线系统。
资源按域收集四类：教程视频、源码仓库、文章文档、参考成品。蒸馏器抽出关键帧、代码片段与参数签名、段落、渲染样例，再用带视觉能力的语言模型压成上述词条并规范化。随后做领域验收：内容是否完整、来源能否追溯、是否重复、文字与画面是否对得上，以及有代码时结构上是否可执行。过关的才进入该域技能集合 。
执行阶段， Agent 和「把通用技能落到具体软件」的域适配器，共用一套 MCP 工具（ Model Context Protocol ，一种让模型调用外部工具的协议约定）。 Wiki 侧可以列分类、读元数据、按文字/画面/代码读取，以及先用 BM25 （按关键词打分）筛出一小批候选再细读；软件侧提供一次 apply，背后是各域能力清单。若技能自带可执行代码，会直接交给正在运行的 MCP 服务执行，中间不再让语言模型把技能「翻译」成另一套工具调用。
怎么选技能：先按分类缩小范围，再让模型挑选
面对用户任务描述 ，系统用 MetaBrowse 两步选取。第一步先做关键词初筛：用户说「做双栏对比页」时，系统会同时查技能名称、标签、适用场景和所属分类，把最相关的少数条目挑出来：
第二步让语言模型阅读候选的文字、截图和代码，挑出能配合使用的几条；没有合适条目时可以一个都不选。比起「给每条技能打个分然后取 Top-1 」，这里更像在组工具包。
消融里，这种「层次分类 + 语言模型」策略在五个域上平均 68.9%，高于只靠关键词的 BM25 （ 66.0%）、只靠向量语义的稠密检索（ 60.0%），也高于「 BM25 先筛再向量重排」（ 64.2%）。 Excel 、 PPT 、 Blender 拉开最大。原因也不神秘：这些任务常要几条技能互补，单看字面或向量相似度，很难判断「这条版式」和「那条配色」该不该一起用。
七个域上的主结果
评测覆盖幻灯片、 CAD 、网页、 Excel 、 Blender 、 UE5 、 Reaper 七个创作域，每个域 80 条与建库语料不重叠的任务。模型侧用 GPT-5.5 、 GPT-5.4 、 Mini 、 Nano 四档。对照有三类：完整 Resource2Skill （ w Skills ）、同一 Agent 但没有技能库（ w/o Skills ），以及 Claude Code 、 Codex 这两套现成的 Agent 运行框架。后两者比较的是完成同一批任务时的执行脚手架能力，不是比较各自的训练数据或底层模型。非音频产物用带视觉的 GPT-5.4 按每域五轴量表打分后取平均；交不出达标产物按 0 分计入。
主对比：四档模型 × 七个域的 overall 分数（%）。粗体为同组同列最优。
有技能相对无技能，在全部 4×7=28 个模型–域格子里全部领先，平均 56.8% 对 45.0%，整体 +11.9 个百分点。两个现成运行框架也能抬高无技能基线，但平均大约停在 50.5%； w Skills 仍在 28 格中赢下 26 格，另两格差距在 1 个百分点内。
如果只记一条对照：换更强的 Agent 脚手架有用，但换不过「把教程里的操作惯例装进库」。提升最集中的，是操作约定多、从提示里现推很贵的域——大模型上 Blender 、 Web 、 UE5 都明显。 UE5 上，不靠技能库、自行生成代码的 Agent 经常拼不出最低可用场景，直接掉到质量阈值以下；有技能时 GPT-5.5 从 30.2% 拉到 69.5%。 Reaper 增益最小，说明音频任务上模型本来就相对能应付，技能库的边际更薄。
五名评分者对 40 对匹配样本做盲测 A/B （跨七域共 200 次成对评分），去掉平票后， w Skills 赢下 85.5% 的个人票，方向与自动裁判一致。人眼也站在有技能一侧，至少说明自动裁判没有独自造出这套排序。
技能越多越好吗
固定 Agent 与 Wiki 接口，按类别均衡扩大技能池：分数单调上升，约 200 条附近趋缓。
从 0 条加到完整库，五个域上分数都单调上升，并在约 200 条附近饱和。 0→200 这一段贡献最大（ Reaper +3.1 pp 到 Excel +14.2 pp ）； 400→Full 每域最多再加 0.8 pp 。早期条目覆盖常用操作与补救套路，后面主要补领域缺口。对工程侧，这意味着「先堆到两千条再说」可能是错重心：先把高频路径做扎实，比盲目扩库更划算。
组织方式和材料形态都在加分
无技能 / 扁平纯文本技能列表 / 完整 Wiki ：完整 Wiki 在各域都最高。
扁平纯文本技能列表已经全面高于「完全不用技能」，说明可复用描述本身有用。完整 Wiki 再比扁平文本高 2.5–8.2 个百分点， Excel 、 Web 、 Blender 拉开最多：分类浏览缩小搜索空间，代码与视觉字段补上纯文字说不清的执行依据。
另有一组实验只改一件事：让 Agent 读到的技能材料不同。资源数量、检索预算和执行 Agent 都保持一致，因此分数差异可以归因于技能里是否包含截图和代码。只给文本平均 65.0%；再加视觉 +1.9 pp ，再加代码 +2.0 pp ，三者齐全到 68.9%。多出来的增益，来自同一批技能把画面和可执行片段真正交给 Agent 。
来源消融：去掉视频后平均从 68.9% 掉到 59.4%；仅视频库仍高于「代码+文章+成品」三源组合。
来源侧，视频几乎不可替代。去掉视频、只留代码/文章/成品，平均从 68.9% 掉到 59.4%。仅视频的库平均 66.8%，仍比无视频的三源组合高 7.4 个百分点。跌幅集中在时间顺序和画面变化信息量大的域（ Excel −14.2 pp ， Web −11.5 pp ）。在视频之上再叠其他来源，没有哪一家补充源单独占优，但四源齐全仍比最强双源组合每域再高 0.3–0.9 pp 。多种来源主要是减少知识盲区；真正难替代的仍然是「看得见操作过程」的视频。
在线补技能：标准任务几乎不动，缺口任务才猛涨
离线库 891 条时，标准集上在线再加 100 条几乎不动；专攻离线缺口的 novel 集上 +21.6 pp 。
固定 891 条离线技能时，标准任务集上再开在线获取只多 +0.7 pp ，基本是噪声。专挑离线库覆盖不住的能力做压力测试时，同样最多加 100 条在线技能，平均从 41.2% 提到 62.8%（+21.6 pp）。论文因此把标准榜默认设为离线-only 。在线补技能更适合处理离线库明确缺失的能力；标准任务里默认打开它，收益很小，却会增加检索、验证和执行成本。
边界与可带走的判断
这套数字建立在域适配器、 MCP 工具约定，以及「用大模型当裁判」的量表协议上。人评方向一致，但绝对分仍会随裁判模型和「最低可用」阈值变动。库大约到 200 条就能吃到大部分红利，再堆条目边际很小。视频贡献最大，代码、文章与成品仍各自补位：前者给可执行套路，后两者补概念和风格。
部署时还要自己掂量论文没展开的部分：教程版权与许可、软件版本和 API 漂移后技能是否失效、可执行代码进 MCP 后的权限边界。标准任务上不必默认开在线补技能；它主要在离线库明显缺能力时才划算。
如果要排产品优先级，我会先看任务是否重复出现。团队每周反复做同类 PPT 、修相似 Excel 或搭固定网页组件，就值得把对应教程拆成可检索的步骤、截图和脚本；任务高度一次性、软件接口又频繁变化，先维护提示词和模板可能更便宜，不必急着建完整技能库。提示词里追加一段文档摘要，短期便宜；把操作经验沉淀成技能，复用半径通常更长。
