MMSkills：迈向通用视觉智能体的多模态技能库 MMSkills: Towards Multimodal Skills for General Visual Agents

Generator 五阶段流水线（每个 $r \in R_d$ 的终态写作 $M_r = (D_r, P_r, \tilde{S}_r, \tilde{K}_r)$）。Phase 0 嵌入聚类：对任务指令与轨迹元数据做 embedding，按语义聚成 $C_d$，OSWorld 上 Ubuntu 9 个领域产生 73 个 cluster（Table 5）。Phase 1 cluster-level 规划：LLM 代理为每个 cluster 提出原子技能，标注 workflow 边界、完成条件、覆盖任务 id，得到 $A_d$。Phase 2 合并去重：把 cluster 间的重叠技能合并并泛化为 $R_d$，拒绝过于宽泛的 umbrella skill。Phase 3 文本优先草拟：不读图，依据参考任务写出描述 $D$、文本流程 $P$、规划好的状态卡，得到 $\tilde{M}_r$。Phase 4 图像落地与审计：读选定的关键帧、grounding focus 区域、构造多视图束 $K$，再由 multimodal-skill-factory meta-skill $F$ 走质量门审计，最终产出 $M_r$。视觉落地策略保守——只为状态识别、过渡对比、完成校验添加视图，不存储原始演示。运行时分支加载（Algorithm 1）。候选技能 $C_I$ 在回合前根据任务指令 $I$ 和紧凑描述预召回。主代理每步要么直接决策，要么触发 $\text{LOAD\_SKILL}(M_t)$，进入分支：(1) Stage 1 gated view selection：$(J_t, R_t) = \text{SelectViews}(O_t, H_{t-1}, P_t, S_t)$，输出选中的状态卡索引 $J_t$ 和视图集 $V_t = \{K_{vj}: j \in J_t, v \in R_{t,j}\}$，如果文本与状态卡足够，$V_t$ 可为空；(2) Stage 2 branch planning：$G_t = \text{PlanBranch}(O_t, H_{t-1}, P_t, \{S_j: j \in J_t\}, V_t)$，返回结构化 JSON，含 applicability、subgoal、plan、do_not_do、fallback_if_no_progress、expected_state、completion_scope。主代理以 $G_t$ 为决策辅助，仍以 live screenshot 选落地动作 $A_t$。Prompt 模板中明确禁止分支返回 GUI 动作，要求"以当前截图优先，参考视图永远不是坐标模板"，并给出 LOAD_STATE_VIEWS 的规范 JSON（visual_reference_needed、why_not_text_only、requests[]）。

技术新颖性主要在三处。第一，多模态状态节点的 schema 设计——把状态卡从"图像描述"提升为带 when-to-use/when-not-to-use/verification_cue 的决策节点，使其在 RAG/检索召回阶段就可被语义化筛选；这一点是文本技能库所没有的。第二，branch loading 把昂贵多模态阅读隔离到临时分支，主轨迹只接收 ~10 个 JSON 字段。该机制刻意避免 reference screenshots 抢占当前屏幕注意力，并避免长上下文的 "lost in the middle" 问题（Liu et al. 2023）。第三，meta-skill-guided 生成器——把多阶段质量门、聚类、合并、grounding 等都封装进可复用 $\mathcal{F}$，同时声明外部服务仅限于 embedding/clustering/grounding 这类有界支持，使得生成过程可控且可审计。消融（Figure 3A）显示同时移除状态卡与图像都会降低性能，证明两者互补；分支加载在纯文本技能上也已有增益（Branch-loaded text-only 普遍优于 Direct text loading），说明分支本身就是贡献。

独立观察到的弱点与改进方向。第一，Generator 五阶段完全依赖 LLM-as-agent，缺乏形式化约束：Phase 1 cluster plan 与 Phase 4 audit 都靠 prompt 把关，若 LLM 漏判"过度宽泛 umbrella skill"则下游状态卡会过载。可改进方向：引入类型化 schema（如 Pydantic）做硬约束 + 自动覆盖率指标。第二，状态卡的 visible_cue 是自然语言而非可机检的视觉谓词，运行时仍要靠 LLM 比对当前截图。改进方向：把 visible_cue 同时落成可调用的视觉定位函数（如 "查找 sidebar 中带 + 的元素"），让 Stage 1 可结构化决策。第三，branch loading 始终走两阶段 LLM 调用，对弱模型不友好。改进方向：设计 fallback——若 Stage 1 判定 text-only 直接进入 Stage 2，并允许 Stage 2 复用主模型而非独立调用，进一步压低延迟。第四，跨平台迁移差：Qwen3-VL-8B 在 macOSWorld 上完全没增益（6.29%），说明 Ubuntu 训练的技能不能直接给 macOS 用。改进方向：把 domain descriptor 与平台解耦，加入 platform-aware 的 skill canonicalization。第五，缺乏错误恢复机制：技能若误导了一次动作，没有在线 repair loop，只能等主代理自我纠正。改进方向：引入 verifier 角色——若 Stage 2 输出后两步未推进，回滚到 no-skill 模式或触发另一技能。

作者在 Limitations 与 Broader Impact 中点出未来方向：扩展到 embodied/安全敏感场景时需要更强的 verification 与在线 skill repair。我的延伸设想：(1) 实时技能增量更新——用 agent 自身的成功/失败轨迹做 online distillation，类似 Voyager 但限定在视觉状态节点上；(2) 与 GUI grounding benchmark（ScreenSpot-Pro、MMBench-GUI）耦合，把 visible_cue 落地为 grounding 模型可执行的子任务，让 Stage 1 可由 grounding 模型替代 LLM；(3) 安全与隐私维度——Broader Impact 已提到，需要给技能库加 provenance、敏感信息过滤、permission scope 元数据；(4) 多模态 RAG 与 branch loading 的统一接口——目前两个阶段都是 prompt 工程，未来可抽象为 typed guidance protocol，支持第三方技能贡献；(5) 长程任务与子目标规划——把状态卡序列升级为状态机，配合 symbolic planner 处理 multi-app 工作流。

代码与数据：作者明确给出 GitHub 仓库 https://github.com/zkangning/MMSkills_for_Visual_Agents、技能源数据集 huggingface.co/datasets/zhangkangning/mmskills、论文主页 zkangning.github.io/MMSkills_for_Visual_Agents/。开源程度较高，技能库与 prompt 模板（Appendix E）都公开。算力门槛：评估主要跑在 AWS 上，Gemini 3.1 Pro 与 Kimi-K2.6 因成本仅做了 OSWorld 三条件；其他模型覆盖 macOSWorld、VAB-Minecraft、Mario。OSWorld 全跑约需 6 个模型 × 3 条件 × 360 题 × 最多 20 步，对中小实验室是中等门槛。复现难度：方法本身的难点在 Generator——五阶段 LLM pipeline 对 prompt 设计与 meta-skill 质量依赖大，作者给出 Stage 1/Stage 2 的完整 prompt，但 Phase 0–4 的细节只在正文概述，Appendix 没完全披露。运行时分支加载本身实现较轻。整体评估中等难度。