RESOURCE2SKILL: 从人类创建的多模态资源中提取可执行的智能体技能

TL;DR 从教程视频、代码等多模态资源自动蒸馏可执行技能，构建分层技能维基，使代理在7个创作领域中平均性能提升11.9个百分点，超越强基线。

问题

问题背景
为了让软件代理具备可复用的过程知识，技能库(skill library) 正成为关键抽象，但如何从日益丰富的多模态人类资源中高效构建技能，是当前自主代理研究的焦点。

现有方法局限
现有技能库主要依赖手写(hand-written) 或从代理执行轨迹(agent traces) 提取，几乎只关注文本模态，完全忽略了视频教程、代码仓库、设计文档等多模态资源。手写技能成本高、覆盖窄；而轨迹提取的方法只能从代理自身的交互历史中学习，无法利用人类创建的、蕴含丰富操作细节和视觉效果的教程视频。此外，这些方法缺乏结构化的多模态组织，无法同时保留代码的可执行性、视频的时序操作信息和参考文档的风格约束。

为什么这个问题难且重要
挑战在于：多模态资源(视频、代码、文章)信号高度互补但模态异构，需要自动对齐并蒸馏为统一的可执行技能表示；同时，技能库的覆盖度无法预知，代理必须在推理时判断何时利用已有技能、何时在线获取新技能。重要性：若能实现，代理将像人类一样从教程中学习，极大降低技能构建门槛，并提升跨领域(PPT、Excel、3D 建模等)的任务成功率，使自主代理从专用走向通用。

行业类比
这一思路类似于从 Stack Overflow 帖子中提取可执行代码片段，但 RESOURCE2SKILL 更进一步：它从视频中学习操作流程，将“观看教程并动手操作”这一人类常用学习方式赋予了软件代理。

核心洞察

• **从人类创作的多模态资源直接蒸馏可执行技能，打破了现有技能库的手工编写与纯文本局限**。现有方法依赖人工书写、纯文本描述或从智能体自身轨迹中提取技能，而大量教程视频、代码仓库与设计文档等富模态资源未被利用。RESOURCE2SKILL 提出统一的构建算子，将这些资源转化为包含结构化文本、代码片段、视觉示例及来源元数据的技能条目，使得技能既保留了视频中的操作时序与视觉效应，又融入了代码的可执行逻辑与文档的概念锚点，实现了多样互补信号的融合。
• **分层多模态技能维基与在线获取机制，让智能体像查阅手册一样动态组合与扩展技能**。技能按领域/任务组织成分层树状结构，检索时可基于任务描述快速定位相关条目，并支持多技能组合；当现有覆盖不足时，同一构建算子可在线抓取新资源并即时生成新技能。实验表明，该设计相比无技能基线平均提升 11.9 个百分点，且在 28 个主评测单元格中有 26 个超越强基线，消融研究证实多模态格式、分层组织、源多样性与选择策略均带来显著增益，在线获取机制则进一步缩小了未知任务上的性能差距。

方法

输入：多模态人力资源

框架以 教程视频、代码仓库、文档文章、参考工件 等多模态人为创作资源作为输入。这些资源互补地承载了操作逻辑、视觉演示与风格规范，但以往未被系统性地转化为智能体可执行技能。

关键模块：分步构造与分层组织

1. 资源到技能构造 (f_θ)：基于提示的蒸馏方法，将原始资源解析为结构化技能条目，并通过确定性后处理保证格式一致。
2. 质量验收 (A_D)：使用五个确定性关卡（如完整性、可执行性校验）过滤低质量技能，确保 wiki 条目可靠。
3. 分层多模态技能 Wiki：所有技能以树状层级存储，每个技能条目包含文本指令、代码片段、视觉示例、元数据及溯源信息，从而保留不同模态的互补信号（视频中的时序操作与视觉效果、代码中的可执行工具模式、文档中的概念与风格约束）。
4. 在线技能获取：当智能体推理时发现 wiki 覆盖不足，则触发同一构造算子在线学习新技能，支持动态扩展。

输出：可组合执行技能

推理时，智能体根据任务从 wiki 中检索并组合相关技能，生成面向具体创作领域的操作序列。技能组合方式受分层结构引导，优先匹配高层级意图，再细化到低层级实现细节。

与同类方法差异：现有技能库多为手写、纯文本或从智能体自身轨迹提取，难以利用视频等多模态资源；RESOURCE2SKILL 首次将视频等多模态教程蒸馏为结构化可执行技能，并通过分层 wiki 与在线获取机制显著提升技能覆盖与复用性。

实验

实验设计

在七个实际创作领域（PPT、Excel、Web 等，此处选取前五个）上评估，每个领域生成任务简报，后端使用多种基座模型（如 Claude、Codex）并配备强化的 harness 基线（如 ClaudeCode-H、Codex-H）。评分采用 judge 模型聚合得到 平均整体得分，对比有/无技能两类代理。消融实验涵盖技能格式、组织、源多样性、选择策略与在线获取。

关键发现

• 一致提升：使用 Resource2Skill 后，相比无技能代理，平均整体得分提升 +11.9 个百分点。
• 广泛胜出：在 28 个主要模型-领域聚合单元中，赢下了 26 个。
• 提升集中于约定与风格密集型任务：视频代码等资源捕捉了可视化与时间模式，弥补纯文本技能的不足。
• 消融证实：多模态技能格式、层次化 Wiki 组织、源多样性与在线获取均有正向贡献。

基线对比解读

相较于无技能代理的原始能力，Resource2Skill 显著利用了人类创造的多模态资源（教程视频、仓库、文章），将其蒸馏为可执行技能，并通过 Wiki 实现高效检索与组合，效果优于简单的文本技能库或轨迹库。即便面对经过强化的 harness 基线（已通过 prompt 工程提升），仍以 26/28 的胜率占优，表明其优势并非仅来自 prompt 优化，而是技能表示与组合策略的实质性进步。在线获取能力则进一步保证在覆盖率不足时仍能动态扩展技能库，接近人类的持续学习方式。对工程实践而言，该框架提供了将零散教程资源系统化为可复用 agent 技能的路径，可显著降低技能工程成本。

行业影响

落地场景

RESOURCE2SKILL 从视频教程、代码仓库、文档等多模态资源中蒸馏可执行技能，构建层次化多模态技能库 (Skill Wiki)，直接赋能软件智能体。该框架可嵌入以下产品与业务：

• 企业级 RPA 与自动化平台（如 Power Automate、UiPath）：将员工录制的操作视频或内部培训材料自动转为可复用机器人技能，加速流程自动化开发。
• 低代码/无代码开发环境：为 AI 辅助的网页、PPT、3D 建模等创作工具提供技能推荐，用户只需给出目标，智能体即可检索并组合技能完成复杂设计任务。
• 垂直行业 SaaS（如电商店铺装修、教育课件制作、游戏资产生成）：将领域专家的创作过程沉淀为标准化技能，降低新人上手门槛，确保产出风格一致性。

商业价值

主要影响在降本增效与体验提升：

• 降本：自动化将以往需人工观摩教程、手动提取操作的环节缩减为在线蒸馏，显著降低技能开发与维护的人力成本。
• 增收：通过快速复用已有技能，缩短交付周期，使企业能承接更多项目；在内容创作平台中，内置技能库可转化为增值付费服务。
• 体验提升：用户（或下游 Agent）无需理解底层 API 细节，以自然语言描述需求即可组装技能，大幅降低使用门槛，提升产品易用性与留存。

与现有产品/工作流的接口

RESOURCE2SKILL 以 Skill Wiki 作为中间表示，可无缝集成至现有 AI Agent 栈：

• 与 LLM 推理框架（如 LangChain、Semantic Kernel）结合：将 Wiki 条目作为 Retriever-Augmented Generation (RAG) 的 knowledge base，或作为 function calling 的 schema source，Agent 在规划时动态检索并组装技能。
• 与 CI/CD 与资产管理集成：技能库可绑定版本控制，支持定期从新资源在线获取技能 (online acquisition)，保持与业务同步演化。
• 对接现有工具生态：技能本体包含可执行代码片段（如 Python 脚本、API 调用），可直接在容器或沙箱中执行，无需修改已有工作流。

具体落地 Use Case

1. 电商大促页面生成：运营人员向 AI 助手描述“做一个 cottagecore 风格的餐厅落地页”，Agent 从 Skill Wiki 检索相关布局、色彩、动画技能，组合生成符合品牌规范的页面，大幅缩短从创意到上线的周期。
2. 企业季度财报 PPT 自动生成：Agent 检索历史会议录制视频、公司设计规范库，蒸馏出数据可视化、页面过渡等技能，根据数据摘要自动生成标准化演示文稿，保证专业与一致性，将分析师从重复排版中解放。

论文显示，在 7 个实用创作领域的 28 个指标中，RESOURCE2SKILL 在 26 个指标上优于强基线，平均总体得分提升 +11.9 个百分点，验证了多模态技能格式与层次化组织的实战价值。

局限

• 技能构造高度依赖源资源的质量与覆盖度。RESOURCE2SKILL 通过提示式蒸馏从教程视频、代码库等提取技能，但若视频模糊、解说含歧义或代码风格不统一，可能导致技能步骤缺失或错误。此外，资源中隐含的领域知识若未显式表达，构造算子可能遗漏关键上下文，影响技能可执行性。
• 分层多模态技能 Wiki 的构建与维护成本较高。尽管框架支持在线获取新技能，但初始库的建立仍需人工筛选高质量资源、验证自动蒸馏结果并整理元数据。技能条目涉及文本、代码、视觉示例等多模态对齐，当领域数量扩展时，维持一致性与最新性将面临可观的工程负担。
• 实验域限于七项明确的创作任务（如幻灯片设计、web 开发、音频制作等），未涉及开放式协作或需要长期规划的真实工作流。技能组合在当前设计中假定任务是单步或短序列，对需要持续交互与状态跟踪的复杂代理场景（如软件工程项目管理）的有效性尚未验证，泛化边界不清晰。