微软最近开源了 Resource2Skill，一套把人类已有资源“炼”成可执行 Skill 的系统。论文作者来自微软、加州大学圣克鲁兹分校和上海交大，代码已经放在 microsoft/Resource2Skill 仓库中。
它想解决的问题很工程化：Agent 需要的 Skill，不能永远靠人一份一份手写。教程视频、文章、代码和参考产物里，原本就藏着大量成熟的操作经验；Resource2Skill 要做的，是把这些经验提炼出来，组织成 Agent 能检索、组合和执行的能力。
它不是一个新模型，不是 Skill 商店，也不是一个放出去就能把互联网啃干净的超级爬虫。官方实现会在“视频蒸馏”环节调用 Gemini，用来理解演示画面并提取操作过程；Gemini 是这条流水线中的一个处理组件，不是 Resource2Skill 本身。它更像一座 Skill 工厂。
人类已经录好的教程视频、写过的文章、维护的代码和做出来的参考产物，是原材料；Resource2Skill 负责发现、提炼、组织和检索这些材料，并把它们变成 Agent 能够直接执行的程序性经验。
说人话就是：以前我们手把手教同事怎么做一件事，现在它想把这套“手把手”自动炼成 Skill。
Skill 到底从哪里来
今天大多数 Skill 是人写的。
我们先观察一个任务，再把步骤、工具、约束、异常处理和验收标准塞进 SKILL.md。写完还要调触发条件、补脚本、跑测试。一个优质 Skill，可以看作一份压缩过的人类经验。
问题是，人类真正积累经验的地方，通常不是 SKILL.md。
它们散落在十几分钟的演示视频里，藏在 GitHub 仓库的代码里，埋在教程文章和文档里，也存在于 PPT、Excel、网页、Blender 工程甚至音频工程这些“参考产物”里。
这套系统做的事情，就是把这些资料重新变成 Agent 能用的经验。
图：Resource2Skill 的资源蒸馏流程。来源：项目页与论文。
整条流水线大致可以拆成五步：
1. 发现资源：围绕某个领域或能力寻找视频、代码、文章与参考产物。 2. 蒸馏经验：识别任务步骤、工具调用、关键参数、失败条件和验收方式。 3. 组织成 Wiki：按能力层级把大量 Skill 组织起来，而不是扔进一个平铺文件夹。 4. 选择和组合：Agent 接到任务后，先浏览层级，再挑出少量相关 Skill。 5. 执行与补缺：现有 Skill 不够时，再触发在线获取，补齐新的能力缺口。
注意，输出不是一篇“视频摘要”。
摘要只能告诉 Agent 视频讲了什么；Skill 则要告诉 Agent 下一步做什么、用什么工具、做到什么程度、失败了怎么办。论文里还把文字、视觉关键帧和代码片段放进同一份 Skill 表征中，因为某些操作只靠文字很难讲清。
图：官方仓库展示的多领域任务与产物。来源：Microsoft Resource2Skill GitHub 仓库。
它真正值钱的，不是批量生成 SKILL.md
如果只把 Resource2Skill 理解成“自动写 Skill 的工具”，会低估这个项目。
自动生成一份 Markdown 并不难。让模型读一篇教程，整理出步骤，现在很多 Agent 都能做到。真正困难的是：资料一多，哪些值得学；学完以后放在哪里；执行任务时应该拿哪几个；旧 Skill 和新 Skill 冲突怎么办；怎样证明使用以后真的变好。
Resource2Skill 惹人注意，是因为它开始同时处理这几层问题：资源采集、经验蒸馏、层级组织、运行时选择、在线补缺和任务评测。它试图交付的不是一个文件，而是一条可以持续生产和运营 Agent 能力的供应链。
图：项目价值归纳。基于论文方法、消融实验和本地试验，属于作者判断，不是官方宣传语。
第一层价值，是把隐性经验变成团队资产。
许多公司的“最佳实践”根本不在知识库里，而在某位同事录过的视频、某次成功提交、某份交付文件和一句“这里千万别这么配”的口头提醒里。文档搜索只能帮你找到材料，Resource2Skill 想进一步把材料里的动作、顺序、边界和验收标准提出来。经验由“知道去哪问谁”，变成“Agent 能按步骤执行什么”。
第二层价值，是压缩运行时上下文。
普通 RAG 容易把几篇相关文档塞给模型，模型还得临场判断哪些是背景、哪些是操作步骤。Skill Wiki 则把昂贵的阅读和整理提前做掉；真正执行任务时，先通过层级浏览缩小范围，再取少量相关 Skill。论文中的选择实验也说明，随机把整个 Skill 池交给 Agent，成绩只比没有 Skill 高一点；层级浏览再由模型选择，效果才明显。这意味着组织和选择本身就是能力的一部分。
第三层价值，是让经验与单一模型适度解耦。
模型会换，团队会换，项目也会换。如果一套经验只存在某个人的 Prompt 历史里，它几乎无法迁移。Skill 把工具步骤、检查点和产物要求放到模型之外，同一份经验就有机会被不同 Agent 后端复用。当然，这不是完全解耦：不同模型使用同一 Skill 的效果仍然不同，论文的七领域结果已经把差异画得很清楚。
第四层价值，是让“Agent 学会了没有”开始可以评测。
手工经验最麻烦的地方，是大家都觉得有用，却很少做同题对比。Resource2Skill 的论文把 Skill 池规模、来源、表征方式、选择策略和在线获取逐项拆开做消融。对于团队落地，这种思路比具体分数更重要：一个 Skill 不是写完就进入祖传目录，而是要用固定任务比较，表现不好就修改、降级或删除。
第五层价值，才是自动从互联网补充新能力。
它并不鼓励 Agent 每次任务都重新上网学习。论文里，在线获取对标准任务只增加 0.7 个百分点，对新能力缺口任务却增加 21.6 个百分点。正确的顺序是：先复用已经验证的离线 Skill；确认覆盖不足，再带着明确问题出去找。这让“自动学习”从一个无限任务，收缩成一个有触发条件、有停止点的工程过程。
放到一个包含很多子项目的代码库里，价值也不是给每个目录生成一份说明书。更合理的目标，是提炼跨项目重复出现的工程套路，同时保留每个项目自己的边界：公共流程进入共享 Skill Wiki，项目差异留在局部适配层，再通过真实任务决定哪些经验值得继续维护。
它怎样从“网上那么多资料”里找到想要的东西
这里必须给热闹降一点温。
目前的公开实现，并不是把整个互联网抓回来建立一座无穷知识库。以视频为例，它更接近一条定向流水线：根据领域和能力生成搜索词，通过 yt-dlp 的 ytsearch 查找 YouTube 视频，再按时长过滤、去重，并结合标题、频道、播放量等信息筛选候选资源。
筛完以后，系统把公开视频地址和针对当前领域的蒸馏提示交给 Gemini，让模型分析视频并输出 Skill；如果需要视觉证据，还能通过 yt-dlp 和 ffmpeg 抽取关键帧。
图：依据官方代码整理的在线视频发现流程。来源：core/collector.py、core/sources/youtube.py。
所以它解决的是“带着能力问题去找材料”，不是“把网上所有东西都搜一遍”。
反爬也不会凭空消失。YouTube 的访问限制、页面变化、频率限制和区域策略，照样会让 yt-dlp 失败。官方实现会跳过部分失败资源，但如果一个领域最终一个可用视频都拿不到，采集仍然会失败。
还有一个经常被忽略的问题：能看，不等于能随便炼；能炼，也不等于能公开分发。
官方仓库给部分 YouTube 来源留下了 youtube_review_pending 这样的许可复核标记。代码本身使用 MIT 许可证，并不意味着被分析的视频、截图和教程内容自动变成 MIT。
做企业内部 Skill 库时，版权、隐私和来源许可必须单独过一遍。
花费调用的是 Gemini，还是本地模型
答案不是二选一，而是看环节和配置。
官方仓库的模型配置示例包含 Azure OpenAI；视频分析代码则直接接了 Google Gemini API。批量 YouTube 蒸馏路径还特意倾向使用 Gemini 2.5 Flash，代码注释给出的理由很朴素：Pro 对批量处理来说太贵，也有点大材小用。
这意味着，按官方默认思路跑完整流水线，通常不是纯本地、纯免费的。
成本主要来自三块：
• 长视频和多模态内容的模型分析； • 大量资源的反复蒸馏、纠错与结构化生成； • 最终执行 Skill 时使用的 Agent 模型。
搜索动作本身未必贵，真正花钱的是后面的“仔细看完并提炼”。资源越多、视频越长、失败重试越多，费用越高。
能不能换成本地模型？理论上可以改，但官方公开实现并不是“切个开关就全部本地化”。你需要自己替换模型适配层，还要保证本地模型具备足够的长上下文、视频理解、代码理解和稳定的结构化输出能力。
如果资料涉及私有仓库，我更建议先做两层隔离：本地完成扫描、切片和脱敏，只把确实需要模型理解的最小材料送到云端；或者彻底换成本地模型，但接受速度和质量上的折损。
论文结果很亮眼，但别只记最大数字
这篇论文发表于 2026 年 6 月，目前还是预印本。
主实验覆盖 4 个 Agent 后端和 7 个领域：Web、Excel、Reaper、PPT、Blender、CAD 与 UE5。每个领域匹配 80 个任务说明，合起来构成 28 个“模型—领域”比较单元。
汇总结果是：不用 Skill 时平均 45.0%，使用 Resource2Skill 生成的 Skill 后为 56.8%，增加 11.9 个百分点。28 个比较单元里，有 26 个超过了 ClaudeCode-H 和 Codex-H 两个基线中较强的那个。
图：四个 Agent 后端、七个领域的汇总结果。来源：论文 Table 1。
这句话里每个限定词都重要。
它不是“所有任务提升 11.9%”，更不是“装上 Skill 就固定提升 11.9%”。它是跨模型、跨领域的汇总差值，而且非音频产物主要由盲化的视觉模型评审，音频使用具备音频能力的模型评审。
论文还做了 40 对人类 A/B 对比，每对由 5 位评分者判断，共 200 个配对评分。排除平局后，带 Skill 的结果拿到了 85.5% 的偏好票。这个结果很强，但样本规模和任务范围仍然要一起看。
原论文表格在这里：
图：论文主实验表格原页，便于核对模型与领域口径。来源：Resource2Skill 论文第 7 页。
如果只看 GPT-5.4，七个领域的平均成绩从 51.9 提升到 66.9，增加 15.0 个百分点。其中 UE5 从 29.1 跳到 67.3，增加 38.2 个百分点；Reaper 则只增加 4.1 个百分点。
图：仅 GPT-5.4 的七领域结果，不能与跨四个模型的总体 +11.9 混用。来源：论文 Table 1。
这个差异比平均数更有意思：Skill 的价值和模型原本会不会、任务能不能被明确描述，关系很大。
UE5 这类工具链复杂、界面操作密集、步骤依赖强的任务，更容易从程序性经验里获益；模型本来就熟悉的任务，收益可能没那么夸张。
论文里最值钱的数字，其实不是 38.2
我觉得真正决定 Resource2Skill 应该怎么用的，是下面这组数据。
论文把离线 Skill 池，与“离线池加最多 100 个在线获取 Skill”做了对比：
• 对标准任务，成绩从 65.4 到 66.1，只增加 0.7 个百分点； • 对专门设计的新能力缺口任务，成绩从 41.2 到 62.8，增加 21.6 个百分点。
图：在线获取的价值集中在新能力缺口。来源：论文 Table 2。
这基本把它的产品定位钉死了：在线搜索不是常驻外挂，而是缺口补给。
常规任务已经被离线 Skill Wiki 覆盖时，再搜一百个 Skill 也未必有用；遇到现有库完全没学过的新工具、新流程，在线蒸馏才可能拉开明显差距。
Skill 也不是越多越好。论文中的扩展实验显示，Skill 池从 0 增加到约 200 个时收益最大，此后逐渐饱和；从 400 个增加到完整池，各领域最多只再提升 0.8 个百分点。
这和我们平时做知识库很像：前两百条高质量经验在解决覆盖问题，后面几百条很可能开始解决重复、冲突和检索噪声问题。
另一个值得注意的消融实验是视频。
四类来源全部使用时，特定实验设置下平均为 68.9；拿掉视频，只保留代码、文章和参考产物后降到 59.4。视频不是为了让 Skill 看起来“多模态”，而是因为大量 GUI 操作、时序动作和微妙参数，本来就只存在于演示过程里。
我拿一个真实的多项目系统试了试
看完论文以后，我没有直接把整个项目丢进去。
一方面，完整官方流水线需要云端模型和视频资源；另一方面，一个真实业务系统里有大量私有代码、内部字段和环境配置，直接全量上传既不安全，也很难判断花出去的钱到底换来了什么。
我选择了一个小得多的试验：在隔离目录中，只读观察某个多项目业务系统，挑出一个重复出现、规则相对稳定、能够检查结果的后端工作流，再把它提炼成 Skill。
随后用同一道任务做 A/B：一组直接交给 Agent，另一组提供刚提炼的 Skill，再让两位独立评审在不知道分组的情况下比较输出。
图：本地小样本试验流程。所有项目身份、路径、模块和业务字段均已移除。
结果没有出现“一装 Skill，模型原地飞升”的戏剧性场面。
两位评审都更偏向带 Skill 的输出，但综合提升只在中等区间。真正改善的主要是三件事：
• 边界更清楚，Agent 不容易顺手改到任务范围之外； • 步骤更一致，跨层衔接和检查点不容易遗漏； • 验收更具体，输出不再停留在“代码看起来写完了”。
它没有证明强模型突然获得了新的深度推理能力，也不是对论文完整流水线的复现。
但这次小实验让我确认了一点：对多项目仓库来说，Resource2Skill 最现实的价值不是“把所有代码变成 Skill”，而是把团队反复踩坑、反复口头交接的流程先变成 Skill。
例如环境适配、跨模块功能接入、固定格式的数据处理、发布前检查、特定工具的复杂操作。它们有共同特征：资料已经存在，步骤反复发生，结果可以验收，而且漏一步就会返工。
它和 Skill Creator 到底有什么区别
两者都会产出 Skill，所以很容易被放在一起比较。但它们回答的其实是两个不同问题：
- Resource2Skill：
面对一堆现成资料，里面到底藏着哪些可以复用的能力？ - Skill Creator：
已经明确要教 Agent 做什么，怎样把它做成一个可靠、可触发、可维护的 Skill？
换个更直观的说法：Resource2Skill 负责找矿、选矿和炼出毛坯；Skill Creator 负责把关键毛坯精加工、验收并装进工具箱。
它们不是替代关系。更靠谱的生产流程反而是把两者接起来：先用 Resource2Skill 从多项目代码、教程和历史文档中找到候选流程，再用 Skill Creator 的方式做人工复核、触发测试、失败路径补齐、安全审查和持续迭代。
如果手里只有一个明确流程，例如“发布前执行一组固定检查”，直接用 Skill Creator 更省事；如果面对的是一整个多项目仓库，还不确定哪些经验值得沉淀，Resource2Skill 才真正开始发挥价值。
谁应该用，什么时候值得用
它主要不是给只想临时写一个 Prompt 的个人用户，而是给三类人：
• Agent 平台与工具团队：需要为多个 Agent、多个模型持续生产和管理能力； • 拥有大量教程与历史资产的组织：知识散落在视频、代码、文档和产物里； • 复杂软件与专业工具团队：工作高度依赖 GUI、工具链和程序性步骤，纯文档很难教会模型。
图：基于论文结果和本地试验总结的工程判断，属于作者建议。
我会在下面这些条件同时出现时考虑它：
1. 同类任务每周都在重复； 2. 团队已经有足够多的教程、代码或成功产物； 3. 新人或 Agent 经常漏掉同样的步骤； 4. 输出能够被测试、截图、文件或评分规则验收； 5. 这个 Skill 会被多个模型、成员或项目重复使用。
反过来，如果只是一次性的简单编码、需求仍在每天变化、现有模型本来就能稳定完成，或者连“做得好不好”都没有判断标准，就没必要先建一座炼厂。
如果要用在多项目仓库，我会这样开始
第一步不是全量扫描，而是列一张“高频返工清单”。
找一个月内反复发生、每次都要查资料、最容易遗漏步骤的流程。把它的成功案例、失败案例、代码模板、文档和验收结果放到一个隔离材料包里。
第二步，只提炼一个最小 Skill。
Skill 里必须包含适用边界、前置检查、执行步骤、禁止修改范围、失败处理和验证方法。先别追求把整个领域都教会。
第三步，准备一组固定任务做盲测。
同一个模型、同样的输入和工具权限，一组带 Skill，一组不带。看它是否真的降低漏项、返工和越界，而不是只让回答更长。
第四步，再决定是否扩大。
一个 Skill 没跑稳之前，不要急着蒸馏几百个。论文自己也告诉我们，规模会饱和；选择、组织和质量比数量更重要。
我的判断
这个项目最吸引人的地方，不是又多了一个 Agent 项目。
而是它把 Skill 的来源，从“少数人手工编写”往前推了一步：人类已经做过的东西，都可能被重新炼成 Agent 的技能。
但“可能”不等于“自动”。搜索有平台限制，蒸馏有模型费用，素材有版权与隐私，论文指标也有任务和评测口径。真正落地以后，最难的仍然是挑对资源、控制边界、验证效果和持续维护。
所以如果你也有一个包含很多子项目的代码库，我的建议不是立刻把整个仓库喂进去。
先找一个高频、稳定、可验收的流程，炼出第一个 Skill。
如果它真的让 Agent 少漏一步、少越一次界、少返一轮工，再谈下一百个。
这比“让 Agent 学会整个互联网”，朴素得多。
也有用得多。
