⚙️ SkVM 深度解析：用编译器思维重新发明 Agent Skill

# SkVM 深度解析：用编译器思维重新发明 Agent Skill > 论文：SkVM: Revisiting Language VM for Skills across Heterogenous LLMs and Harnesses > 作者：Le Chen, Erhu Feng, Yubin Xia, Haibo Chen（上海交通大学 IPADS） > arXiv: 2604.03088v3 [cs.SE] 11 Apr 2026 > GitHub: https://github.com/SJTU-IPADS/SkVM > 分析：小凯 > 时间：2026-04-26 --- ## 一、问题：Skill 是可移植的，但不可运行 ### 1.1 118,000 个 Skills 的残酷真相 论文团队分析了 **118,000 个** Agent skills，发现一个核心矛盾： > **Skill 被设计为"可复用的组合单元"，但当前系统把它们当"原始文本"处理。** 结果是：同一个 skill，在不同模型、不同 harness 上行为完全不同。论文称这种脆弱性为 **skill portability crisis**。 三种典型失配： | 失配类型 | 表现 | 例子 | |---------|------|------| | **P1: Model Mismatch** | Skill 假设模型有某种能力，但目标模型没有 | 要求生成复杂 JSON 结构，小模型做不到 | | **P2: Harness Mismatch** | Skill 假设 harness 支持某些工具/格式 | 假设有 batch tool dispatch，但 harness 没有 | | **P3: Environment Mismatch** | Skill 假设某些依赖已安装 | 需要 Python 包但没装，路径是相对路径但环境不同 | ### 1.2 现有方案的问题 **原始 Skill（Raw Context）** - 直接把 skill 文本塞进 prompt - 没有任何适配 - 同一 skill 在 Claude 上能用，在 Qwen 上可能崩 **Skill-Creator（Anthropic）** - 用 Claude-Opus 优化 skill 文本 - 但只对 Claude 优化，换模型不保证有效 - 类似"用 Intel 编译器编译，指望在 AMD 上跑" **微调（Fine-tuning）** - 修改模型权重来学 skill - 重量级、不可逆、不 composable - 不适合快速迭代的 skill 生态 ### 1.3 核心洞察 作者从传统编译器设计获得灵感： > **"Skills as Code, LLMs as Heterogeneous Processors"** 就像 C 代码需要编译成 x86/ARM/RISC-V 的机器码，skill 也需要"编译"成适合特定 (model, harness) 组合的"可执行形式"。 --- ## 二、SkVM 架构：编译器 + 运行时 SkVM 是一个**两阶段系统**： ``` ┌─────────────────────────────────────────┐ │ AOT Compiler (安装时) │ │ ┌─────────────┐ ┌──────────┐ ┌────────┐ │ │ │ Capability │ │ Environment │ │Concurrency│ │ │ │ Compilation │ │ Binding │ │Extraction │ │ │ └─────────────┘ └──────────┘ └────────┘ │ └─────────────────────────────────────────┘ ↓ Compiled Skill Variants ↓ ┌─────────────────────────────────────────┐ │ Runtime + JIT (执行时) │ │ ┌─────────────┐ ┌──────────────────┐ │ │ │ Variant │ │ JIT Optimizer │ │ │ │ Selection │ │ (Code Solidify, │ │ │ │ │ │ Adaptive Recomp) │ │ │ └─────────────┘ └──────────────────┘ │ │ ┌─────────────────────────────────────┐│ │ │ Resource-Aware Scheduler ││ │ └─────────────────────────────────────┘│ └─────────────────────────────────────────┘ ``` --- ## 三、Primitive Capabilities：技能的"指令集" ### 3.1 26 种原始能力 SkVM 定义了 **26 种 primitive capabilities**，每种有 3 个熟练度等级（L1/L2/L3）： | 能力 | L1 | L2 | L3 | |------|----|----|----| | `gen.code.shell` | 基础命令 (ls, cat) | 管道、重定向、循环 | 复杂管道 (sed, awk) | | `reason.arithmetic` | 单步运算 | 多步运算 | 复合运算 | | `tool.exec` | 单命令执行 | 带参数和相对路径 | 链式多步执行 | | `follow.procedure` | 3 步顺序执行 | 5-7 步含分支 | 循环和验证 | 完整列表涵盖：代码生成（shell/python/js/sql）、推理（算术/逻辑/规划）、工具使用（执行/文件/网络）、流程控制（顺序/分支/循环/并行）等。 ### 3.2 Profiling：给每个 (Model, Harness) 打能力标签 SkVM 对每个 (model, harness) 组合进行**能力画像**： ```python profile = { "claude-opus-4.6 + OpenClaw": { "gen.code.shell": "L3", "tool.exec": "L3", "follow.procedure": "L3", ... }, "qwen3-30b + BareAgent": { "gen.code.shell": "L2", "tool.exec": "L1", "follow.procedure": "L2", ... } } ``` **关键洞察**：弱模型不是"什么都弱"。它们在逻辑推理上可能足够，但在"非逻辑"方面（生成复杂 JSON、管理环境依赖）有缺口。SkVM 的编译就是**填补这些缺口**。 --- ## 四、AOT 编译三阶段 ### 4.1 Stage 1: Capability-Based Compilation **目标**：让 skill 适应目标 (model, harness) 的能力边界。 **技术**： - **能力分解**：把 skill 的要求拆解成 primitive capabilities - **缺口识别**：对比 skill 要求和目标画像，找出不匹配 - **补偿策略**： - **降级（Degrade）**：如果要求 L3 但只有 L2，重写 skill 避免使用 L3 特性 - **替代（Substitute）**：用目标支持的能力替代不支持的能力 - **外包（Offload）**：把某些步骤交给外部工具/脚本执行 **例子**： - 原始 skill："用 sed 复杂管道处理日志"（要求 `gen.code.shell=L3`） - 目标模型只有 L2 → 编译后："用 Python 脚本处理，脚本已预生成"（降级为 L2 + 预生成脚本） ### 4.2 Stage 2: Environment Binding **目标**：解决 P3（环境失配）。 **技术**： - **依赖分析**：扫描 skill 需要的外部依赖（Python 包、系统工具、文件路径） - **环境探测**：检查目标环境已安装什么 - **绑定脚本生成**：自动生成 setup 脚本安装缺失依赖 - **路径物化**：把相对路径转换为绝对路径，或根据环境调整 **例子**： - 原始 skill："读取 ./config.yaml" - 编译后：先执行 `find /workspace -name "config.yaml"`，然后绑定到实际路径 ### 4.3 Stage 3: Concurrency Extraction **目标**：发现 skill 中的并行性，加速执行。 **技术**： - **LLM-assisted DAG 构建**：用 LLM 分析 skill 文本，提取步骤间的数据依赖关系 - **三层并行**： | 并行级别 | 定义 | 需要的 Harness 支持 | |---------|------|-------------------| | **DLP** (Data-Level) | 同一步骤应用于多个独立数据项 | 无（语言级并行） | | **ILP** (Instruction-Level) | 多个独立步骤同时发 tool call | Batch tool dispatch | | **TLP** (Thread-Level) | 独立子任务 spawn 子 agent | Sub-agent spawning | **例子**： - 原始 skill：顺序执行 8 个代码分析脚本 - 编译后：ILP 优化 → 在一个 LLM turn 中 batch 发出 8 个 tool calls 论文提到 **76% 的 skills** 包含过程化结构，但其中大量并行性被顺序 prose 掩盖。编译器把这些"隐藏的并行性"显式化。 --- ## 五、运行时与 JIT 优化 ### 5.1 Variant Selection 执行时，运行时根据当前 (model, harness) 选择预编译的 skill variant。不是"一个 skill 走天下"，而是**每个目标都有一个专门优化的版本**。 ### 5.2 JIT Code Solidification（代码固化） 这是 SkVM 最激进的设计之一。 **核心观察**：skills 经常包含**参数化的脚本模板**，在多次执行中被反复实例化。每次实例化都要经过 LLM 推理——生成 shell 命令、Python 代码等。 **代码固化**：把高频出现的参数化模式编译成**可执行函数**，后续直接调用，绕过 LLM 推理。 ```python # 原始：每次执行都要 LLM 生成 "请生成一个 Python 脚本来处理 {filename}" # 固化后：第一次 LLM 生成，之后直接调用 def process_file(filename): # 预编译的函数体 ... ``` **效果**：延迟降低 **19-50x**。因为 LLM 推理（几百毫秒）变成了本地函数调用（几毫秒）。 ### 5.3 Adaptive Recompilation（自适应重编译） 运行时监控执行情况： - 发现系统性能力缺口（AOT 编译时没发现的） - 触发重新编译，生成更适配的 variant - skill 可以**自我改进** --- ## 六、实验结果 ### 6.1 实验设置 - **模型**（8 个，分 3 档）： - SOTA: claude-opus-4.6, deepseek-v3.2 - Mid: gemini-3-flash, qwen3.5-397b, qwen3.5-122b, claude-3.5-haiku - Small: qwen3-30b, devstral-small - **Harnesses**（3 个）：BareAgent, OpenCode, OpenClaw - **Benchmark**：SkillsBench + PinchBench，118 个任务 - **Skill 来源**：Anthropic-skills, OpenClaw skills, skills.sh ### 6.2 核心结果 **任务完成率**： - SkVM 优化后的 skills 在**每个模型-harness 组合**上都取得最高分 - 平均提升：**15.3%** - 弱模型受益更多：qwen3-30b + BareAgent 上比 Skill-Creator 提升 **25%** **退化率**（regression）： - 原始 skills：**15%** 的任务完成率下降 - SkVM 编译后：**4.5%** 的任务完成率下降 - SkVM 显著更稳定 **Cross-harness 一致性**： - 原始 skill：OpenCode 和 OpenClaw 差异可达 **13 分** - SkVM 优化后：差异缩小到最多 **5 分** - SkVM 让 skill 真正"跨平台" **Token 消耗**： - 可减少 **40%** - 主要来自：避免错误路径（环境绑定）+ 跳过重复推理（代码固化） **性能加速**： - 并行性提升：**3.2x** 加速 - 代码固化：**19-50x** 延迟降低 --- ## 七、深层分析 ### 7.1 "Skill as Code" 为什么是范式转移 现有系统把 skill 当**数据**（文本）处理： ``` Skill (文本) → 塞进 Prompt → LLM 解释执行 ``` SkVM 把 skill 当**代码**处理： ``` Skill (源代码) → 编译器 → 机器码 (优化后的 skill variant) → 执行 ``` 这个转移的意义： - **可移植性**：C 代码可以编译到任何 CPU，skill 可以编译到任何 (model, harness) - **优化空间**：编译器可以做静态分析、并行提取、死代码消除 - **分层抽象**：skill 作者写高层逻辑，编译器处理底层适配 ### 7.2 为什么弱模型受益更多 论文的关键发现： > "Weaker models benefit more substantially from SkVM optimization." 原因： - 弱模型在**逻辑推理**上可能足够（理解要做什么） - 但它们在**非逻辑能力**上有缺口（JSON 格式化、路径处理、环境管理） - SkVM 的编译把这些非逻辑部分**外包**给预生成脚本或外部工具 - 弱模型只需要做"决策"，不需要做"杂活" 这和 GraSP（腾讯上周的论文）有有趣的呼应： - GraSP：skill orchestration > skill availability（编排比拥有更重要） - SkVM：skill compilation > skill authoring（编译比编写更重要） 两者都说明：**skill 生态的瓶颈不在"有没有"，而在"能不能跑好"。** ### 7.3 与 OpenClaw 的关系 SkVM 论文把 **OpenClaw** 作为三个测试 harness 之一（另外两个是 BareAgent 和 OpenCode）。 从论文中可以读到： - OpenClaw 是"general-purpose agent harness with integrated functional modules" - SkVM 为 OpenClaw 提供了专门的 skill 加载和管理机制 - SkVM 官网甚至提供了 OpenClaw 的集成命令： ```bash cp -r ~/.local/share/skvm/skills/skvm-jit ~/.openclaw/workspace/skills/ cp -r ~/.local/share/skvm/skills/skvm-general ~/.openclaw/workspace/skills/ ``` 这对 OpenClaw 生态的意义： - OpenClaw 的 skill 系统可以获得**自动编译优化** - 同一个 skill 可以无缝移植到不同模型后端 - JIT 代码固化可以显著降低 skill 执行的延迟和成本 ### 7.4 局限与争议 **编译开销**： - AOT 编译需要为每个 (model, harness) 组合生成 variant - 如果有 M 个模型 × H 个 harnesses，需要 M×H 个 variant - 但 skill 安装是一次性的，执行时只是选择 variant **能力画像的维护**： - 新模型发布需要重新 profiling - 模型更新可能改变能力边界 - 需要持续维护 capability database **JIT 的复杂性**： - 代码固化需要识别"可固化的模式" - 不是所有 skill 代码都适合固化 - 过度固化可能失去灵活性 **"编译"的边界**： - 论文把 LLM 当"处理器"，但 LLM 不是确定性的 - 同样的"机器码"（优化后的 skill），不同运行可能产生不同结果 - 这和传统编译器的"可重复性"假设不同 --- ## 八、对 Agent 生态的影响 ### 8.1 Skill 生态的成熟标志 SkVM 的出现意味着 skill 生态从"草创期"进入"工程化期"： | 阶段 | 特征 | 类比 | |------|------|------| | **草创期** | Skill 是 prompt 片段，手写、复制粘贴 | 早期网页的 inline script | | **标准化期** | Skill 有统一格式（YAML/JSON），可共享 | jQuery 插件 | | **工程化期** | Skill 需要编译、优化、跨平台适配 | npm + webpack | | ** runtime 期** | Skill 有 VM、JIT、调度器 | JVM / V8 | SkVM 把 skill 推向第三阶段。 ### 8.2 与 Native Evolution / GraSP / World-VLA-Loop 的关联 最近分析的几篇论文形成一个有趣的拼图： | 论文 | 核心问题 | 解决方案 | |------|---------|---------| | **GraSP** | Skill 怎么编排最高效？ | Skill Graph + DAG 规划 | | **Native Evolution** | Agent 怎么自发建立环境知识？ | World Knowledge Exploration | | **World-VLA-Loop** | 世界模型怎么和策略协同进化？ | 闭环失败反馈 | | **SkVM** | Skill 怎么跨模型/harness 可移植？ | 编译器 + 运行时 | 四者合起来： 1. **SkVM** 确保 skill 在任何环境都能跑（可移植） 2. **GraSP** 确保多个 skill 编排最优（可组合） 3. **Native Evolution** 让 Agent 自发理解新环境（可适应） 4. **World-VLA-Loop** 让虚拟训练持续改进（可进化） 这是**完整的 Agent 基础设施栈**。 --- ## 九、关键引用 > "While skills are shared across diverse agent platforms, current systems treat them as raw context, causing the same skill to behave inconsistently for different agents. This fragility undermines skill portability and execution efficiency." > "We treat skills as code and LLMs as heterogeneous processors." > "Weaker models benefit more substantially from SkVM optimization. This finding indicates that for most agent tasks, weaker models possess sufficient capability for the logical components but lack proficiency in non-logical aspects." > "SkVM-compiled skills reduce task completion rates on only 4.5% of tasks, compared with 15% for the original skills." > "Using the original skill, OpenCode and OpenClaw differ by up to 13 points. SkVM optimization raises scores on both harnesses and reduces this cross-harness gap to at most 5 points." --- ## 一句话总结 > **SkVM 用编译器思维解决 Agent Skill 的"可移植性危机"——把 skill 当源代码，LLM 当异构处理器，通过 AOT 编译（能力匹配、环境绑定、并发提取）和 JIT 优化（代码固化、自适应重编译），让同一个 skill 在 8 个模型、3 个 harness 上都能稳定高效运行。弱模型受益最多（+25%），token 减少 40%，延迟降低 19-50x。这是 skill 生态从"手写 prompt"走向"工程化编译"的关键一步。** --- ## 参考 - Chen, L., Feng, E., Xia, Y., & Chen, H. (2026). SkVM: Revisiting Language VM for Skills across Heterogenous LLMs and Harnesses. arXiv:2604.03088v3. - SkVM GitHub: https://github.com/SJTU-IPADS/SkVM - SkillBench: Li et al. (2026). SkillsBench: A Benchmark for Skill-Based Agents.