SkVM - 面向 LLM 技能的编译与运行时系统

一句话概括

把 Skill 当作”代码”、把 LLM 当作”异构处理器”，借鉴传统编译器（AOT + JIT）设计思想，首次为 LLM Agent 的 Skill 构建了跨模型、跨平台的编译与运行时系统。

一、核心问题：Skill 的”可移植性危机”

当前 Agent 把 Skill 当作原始文本直接塞给模型，导致同一 Skill 在不同模型/Harness 上表现天差地别。作者分析了 118,000+ 个 Skill（clawhub.ai + skills.sh），发现：

问题数据
使用 Skill 后性能下降15% 的任务
使用 Skill 后无变化17% 的任务
至少一个模型无改善87% 的任务
Token 开销暴增最高 451%

三大失配：

  • P1 模型失配：Skill 假设模型能区分库 API 与 CLI，小模型直接翻车
  • P2 Harness 失配：同一模型在不同 Harness（Claude Code / OpenCode / BareAgent）上结果差异巨大
  • P3 环境失配：缺少依赖包时，Qwen 成功率从 100% 暴跌到 33-67%，且 Token 消耗翻倍

二、核心类比：编程语言的演进

flowchart LR
    subgraph Stage1["Stage 1: Assembly"]
        A1["汇编代码"]
        B1["Assembler & Linker"]
        C1["操作系统"]
        D1["硬件"]
        A1 --> B1 --> C1 --> D1
    end
    
    subgraph Stage2["Stage 2: High-level Language"]
        A2["C / Java 代码"]
        B2["C Compiler / JVM"]
        C2["操作系统"]
        D2["硬件"]
        A2 --> B2 --> C2 --> D2
    end
    
    subgraph Stage3["Stage 3: Natural Language (Skill)"]
        A3["Skill (自然语言程序)"]
        B3["SkVM<br/>Compiler & Runtime"]
        C3["Agent Harness"]
        D3["LLM (异构处理器)"]
        A3 --> B3 --> C3 --> D3
    end
    
    style Stage3 fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style B3 fill:#ffcccc,stroke:#cc0000,stroke-width:2px

    %% 关键改动：使用隐形连线强迫子图横向排列
    Stage1 ~~~ Stage2 ~~~ Stage3

关键洞察：Skill 是”自然语言程序”，LLM 是”异构处理器”，但缺少编译器和运行时来保证跨目标可移植性与执行效率。

三、SkVM 架构：AOT 编译 + 运行时 JIT

flowchart TB
    subgraph AOT["AOT Compiler (Install Time)"]
        direction TB
        P1["Pass 1: Capability-Based Compilation<br/>• 提取26个原始能力<br/>• 微基准画像 → 差距分析<br/>• 补偿(compensate) / 替换(substitute)"]
        P2["Pass 2: Environment Binding<br/>• 提取隐式依赖<br/>• 生成 env-binding.sh"]
        P3["Pass 3: Concurrency Extraction<br/>• 工作流 → DAG<br/>• DLP / ILP / TLP"]
        P1 --> P2 --> P3
    end
    
    SV["Skill Variants<br/>(按 target 存储)"]
    
    subgraph RT["Runtime (Execution Time)"]
        direction TB
        VS["Variant Selection<br/>(匹配当前 model+harness)"]
        JIT["JIT Optimizer"]
        AR["Adaptive Recompilation<br/>• 监控失败日志<br/>• 系统性缺口 → 重编译"]
        CS["Code Solidification<br/>• 高频模板 → 可执行函数<br/>• 绕过 LLM 推理"]
        RS["Resource-Aware Scheduler<br/>• API/CPU/内存感知"]
        VS --> JIT
        JIT --> AR
        JIT --> CS
        JIT --> RS
    end
    
    AOT --> SV
    SV --> VS
    
    style AOT fill:#e6ffe6,stroke:#006600
    style RT fill:#ffe6e6,stroke:#cc0000
    style SV fill:#fff0e6,stroke:#cc6600

四、三大技术创新详解

1. 原始能力（Primitive Capabilities）—— 让”可移植”可量化

从 15,063 个 Skill 中归纳出 26 个原始能力（如 gen.code.shell, tool.exec, follow.procedure），每个能力分 L1/L2/L3 熟练度。

flowchart LR
    Skill["Skill Requirements<br/>• gen.code.python L3<br/>• tool.exec L2<br/>• follow.procedure L2"]
    Target["Target Profile<br/>(微基准测试)"]
    Gap["Gap Analysis（差距分析）<br/>need vs has"]
    T1["Compensate（补偿）<br/>L2→L1<br/>+ 绝对路径替换"]
    T2["Substitute（替换）<br/>Python→SQL"]
    
    Skill --> Gap
    Target --> Gap
    Gap --> T1
    Gap --> T2
  • 补偿（Compensation）：目标能力级别不足时，通过增加示例、明确约束来”降级” Skill 要求
  • 替换（Substitution）：差距过大时，切换到等价实现路径（如 Python pandas → SQL）

2. 代码固化（Code Solidification）—— 绕过 LLM 的”JIT 编译”

75% 的 Skill 包含结构固定、仅参数变化的代码片段。SkVM 将其提升为可执行函数：

flowchart LR
    S1["Stage 1: AOT分析<br/>• 提取代码签名<br/>• 生成参数模板"]
    S2["Stage 2: 运行时监控<br/>• 连续匹配签名<br/>• 确认结构稳定"]
    S3["Stage 3: 提升执行<br/>• 模板→可执行函数<br/>• 后续调用绕过LLM"]
    
    S1 --> S2 --> S3

效果：PDF 提取任务从 10,469 ms → 206 ms，加速 19-50×；天气查询加速 5×（受网络延迟限制）。

3. 并发提取（Concurrency Extraction）—— 从自然语言中挖并行性

借鉴编译器经典优化：

  • DLP（数据级并行）：批量处理多个文件
  • ILP（指令级并行）：独立工具调用可重叠
  • TLP（线程级并行）：生成独立子 Agent 并行执行
flowchart TB
    Root[技能工作流DAG构建] --> DLP[数据级并行 DLP<br/>单步骤对多份独立数据执行相同操作]
    Root --> ILP[指令级并行 ILP<br/>多个无依赖工具调用合并为单轮批量执行]
    Root --> TLP[线程级并行 TLP<br/>独立子任务拆分为子Agent并行执行]

    DLP --> D1[实现: 语言原生并行原语<br/>无需Harness特殊支持]
    ILP --> I1[实现: 批量工具调用注解<br/>需Harness支持批量分发]
    TLP --> T1[实现: 子Agent任务块注解<br/>需Harness支持子Agent孵化]

五、评估结果

在 8 个 LLM（Claude Opus 4.6, Gemini 3 Flash, Claude 3.5 Haiku, Devstral Small, Qwen3-30B 等）× 3 个 Harness（Claude Code, OpenCode, BareAgent）上测试：

指标结果
任务完成率提升平均 +15.3%
Token 消耗降低最高 -40%
并行加速最高 3.2×
代码固化延迟降低19-50×

六、Skill 生态画像（基于 118,000+ Skill）

pie
    title Skill 分类 (15,063 个高下载量 Skill)
    "工具引用 (Tool-reference)" : 52
    "流程指导 (Procedural)" : 28
    "内容生成 (Generative)" : 20
  • 76% 包含显式流程结构（编号步骤、条件分支）
  • 75% 嵌入可固化代码片段
  • 长尾分布：89% 的 Skill 下载量 < 86 次

七、局限与未来方向

  1. 非确定性：编译过程依赖 LLM，输出可能有波动（已设计回滚机制）
  2. 能力覆盖：26 个能力覆盖 95% Skill，新领域需扩展
  3. 编译成本：AOT 为一次性开销，但对”一次性使用”场景不友好

八、为什么这篇论文重要？

维度价值
问题定义首次用大规模数据（118K Skills）量化了 Skill 可移植性危机
理论框架将”Skill = 代码，LLM = 处理器”的类比落地为完整编译器体系
工程实现从 AOT 三阶段编译到 JIT 代码固化，全链路可运行
实际收益不仅提升准确率，还显著降本（Token -40%）提速（延迟 -50×）

一句话推荐给同行：如果你在做 Agent 框架、Skill 市场或 LLM 工具链，这篇论文提出了一个像 JVM 之于 Java 那样的基础设施愿景——让 Skill 真正”一次编写，到处运行”。

论文链接：arXiv:2604.03088v2

相关文章