SkVM：面向技能跨异构 LLM 与 Agent 框架高效执行的虚拟机

把 LLM 技能当作代码、LLM 当作处理器，设计了一套编译+运行时系统，让技能在异构模型和 agent 框架上稳定高效执行。

前置知识

LLM Agent 与技能（Skill）

LLM Agent 通过 ReAct 循环（推理→工具调用→观察→再推理）完成开放任务。技能（Skill）是封装好的自然语言+脚本包，包含 metadata、instruction 和 bundled resources 三层结构，用于指导 agent 完成某一类任务，可被自动发现和加载。

本文把技能当作 agent 时代的'代码'，理解技能的三层结构和调用机制是理解 SkVM 设计动机的前提。

Agent Harness（智能体运行时框架）

Agent Harness 是位于 LLM 与操作系统之间的中间层（如 Claude Code、OpenCode、OpenClaw），负责管理 API 连接、注册可用工具、分发工具调用以及控制上下文窗口。不同 harness 在工具丰富度、子 agent 派发能力、上下文管理上差异显著。

SkVM 把 harness 视为异构目标之一，并发提取（concurrency extraction）的 DLP/ILP/TLP 三种并行原语需要 harness 提供相应的执行能力。

AOT 与 JIT 编译

AOT（Ahead-of-Time）编译在程序运行前完成代码分析和优化；JIT（Just-In-Time）编译在运行时基于执行反馈动态优化代码。两者结合在 JVM 等传统运行时中是经典做法，能在启动延迟和峰值性能之间取得平衡。

SkVM 的核心架构直接借鉴 AOT+JIT 范式：AOT 在安装时生成针对目标的技能变体，JIT 在运行时基于失败日志重编译并固化为可执行代码。

能力画像（Capability Profile）与能力差距分析

能力画像指对目标模型在多个维度（如工具调用、推理、代码生成）上的水平进行离线下测评，形成能力向量。能力差距分析则把技能要求的能力向量与目标画像对比，找出欠配（gap）或过配的位置。

SkVM 的 Capability-Based Compilation 完全依赖这一思想：基于 26 种原始能力的多级水平画像，决定对技能做补偿（compensation）还是替换（substitution）。

DLP/ILP/TLP 并行

DLP（数据级并行）对独立数据项执行同一操作；ILP（指令级并行）让无依赖的指令并行执行；TLP（线程级并行）将任务拆分到独立子线程/进程。三者分别对应不同粒度的并行机会。

SkVM 的并发提取 pass 把技能工作流拆成 DAG，分别映射到 DLP/ILP/TLP 三种 harness 原语，是性能加速的核心机制之一。

研究动机

作者对 clawhub.ai（28,990 个）和 skills.sh（89,280 个）上共 118,000 个真实技能做了系统分析，发现当前 agent 把技能当成'原始上下文'直接塞给 LLM，这种朴素使用方式在异构模型和 harness 上引发三类失败：P1 模型不匹配（如 devstral-small 把 pptx-creation 技能里的 JavaScript 库 PptxGenJS 误当成 CLI 反复执行错命令，无技能时反而能用 python-pptx 拿到 95 分）、P2 harness 不匹配（Gemini 3 Flash 在 BareAgent 上 workday-scheduling 任务得 100 分，但同样的技能在 OpenCode 上由于系统 prompt 拼接上下文过长导致 JSON 键格式错误，得 0 分）、P3 环境不匹配（缺失依赖时 Qwen 模型成功率从 100% 跌到 33–67%，输出 token 数反而增加 2–4 倍）。论文对 8 个模型的统计显示：开启技能后 15% 的任务分数反而下降（Opus 4.6 是 7%，Qwen3-30B 高达 25%），17% 的任务分数不变，87% 的任务中至少有一个模型没有提升。在 SWE-Bench 上另有研究表明 49 个技能里 39 个没有任何分数提升。

本文的目标是本文的目标是构建一个完整的编译+运行时系统 SkVM，把'技能-模型-harness-环境'四者的不匹配从'运行时碰运气'变成'编译时显式解决'。具体目标包括：让同一份技能在不同 (模型, harness, 环境) 上获得稳定且最优的执行；用 AOT 编译把技能按目标特化、用 JIT 在运行时基于失败反馈自适应重编译；最终在不同能力层级的模型上平均把任务完成率提升 15.3%、在可完成任务上节省高达 40% token、整体加速 3.2× 到 50×。

与已有工作不同的是，作者独特的切入角度是把'技能'类比为 agent 时代的'代码'、把 LLM 类比为'处理器'，把 agent harness 类比为'运行时'。这一视角让他们借用经典编译器的整套设计语言：抽象出一组 26 个'原始能力（primitive capabilities）'作为字节码级别的中间表示；在安装期做能力画像与差距分析；引入 JIT 的代码固化（code solidification）把高频模板从 LLM 推理路径下沉到直接执行；并用 DLP/ILP/TLP 三级并行模拟硬件并行原语。与已有工作（如 SWE-Skills-Bench 指出技能普遍无用、Skill-Creator 用 LLM 重写技能）相比，SkVM 第一次给'技能'配齐了完整的编译工具链，而不是把技能当作 prompt 工程对待。

核心方法

SkVM 把技能当作代码、LLM 当作处理器，整体思路是'安装期特化、运行时反馈迭代'。在安装时，AOT 编译器对技能做三个 pass 的分析：Pass 1 能力画像式编译拆解技能要求的能力并对照目标模型/harness 的微基准画像，必要时做补偿或替换；Pass 2 环境绑定把'隐式依赖'显化为可执行的安装脚本；Pass 3 并发提取把工作流拆成 DAG，标注 DLP/ILP/TLP 并行机会。运行期间，runtime 选择当前 (模型, harness) 对应的变体，并叠加 JIT 优化：自适应重编译基于失败日志触发补偿变换，代码固化把反复出现的高频模板生成可执行函数从而绕过 LLM 推理；资源感知调度器根据 CPU、内存和 API 限流信号动态节流或挂起并发子 agent。整套系统参考 JVM 字节码、AOT/JIT 编译器与 OpenCL 异构编程的设计思想。

SkVM 与已有方法的本质区别在于：现有方法（无论是把技能当 prompt 直接喂给模型，还是用 Skill-Creator 让 LLM 重写一遍）都是在文本层面打转，缺乏对'技能要求'和'目标提供'之间结构化差距的显式建模。SkVM 引入了三层抽象：(1) 用 26 个有等级划分的原始能力作为'中间表示'，使任何技能都可以被分解为能力需求向量；(2) 用差距驱动的两阶段变换（补偿 vs 替换）做目标特化，而非简单的重写；(3) 用代码固化把'反复执行的脚本模板'从 LLM 推理路径下沉到本地函数调用，配合自适应重编译处理 AOT 静态画像漏掉的运行时问题。这套思路把'技能-模型-harness-环境'从一次性匹配升级为可持续迭代的优化循环。

方法步骤详情

SkVM 的执行分两阶段。AOT 编译阶段，输入是原始技能文本与 (模型, harness, 环境) 三元组，输出是若干特化变体 + env-binding 脚本 + 并发 DAG 注解。Pass 1 Capability-Based Compilation：先把技能分解为具体任务，把每个任务映射到 26 种原始能力（每种有 L1/L2/L3 等多级熟练度）；用离线微基准套件在目标模型上跑出能力画像；如果目标满足需求则直接通过，如果目标在某能力上低一级则做'补偿'（注入更显式的指令、把相对路径换绝对路径、补示例），如果目标完全不具备该能力则做'替换'（切换到能力画像内的等价实现路径）。Pass 2 Environment Binding：从 Pass 1 输出和技能显式前置条件中提取依赖清单（pip 包、CLI、service），对每项做轻量探测（pip show、which），缺失时进一步探测系统特征并生成幂等的 env-binding.sh；执行失败时把脚本输出回退给 LLM 让其诊断。Pass 3 Concurrency Extraction：用 LLM 辅助分析把步骤拆成节点，边表示数据依赖形成 DAG；对每个并行机会根据 harness 支持选择 DLP（语言层并行原语，如 xargs -P）、ILP（在单个 LLM turn 内批量派发多个独立 tool_use）或 TLP（拆出独立 sub-agent 块）。Runtime 阶段，任务到达时 runtime 按 (model, harness) 选择对应变体并通过渐进式披露加载；先跑 env-binding 脚本校验依赖；JIT 监控每次执行，对跨多次调用反复失败且失败日志具有系统性（而非任务特定）特征的技能触发 adaptive recompilation，把失败日志和 self-recovery trace 一起喂给编译器做定向补偿；对 75% 的技能中嵌入的高频参数化代码模板，AOT 在编译时为每个候选生成'关键词+代码签名+代码模板+参数 schema'四元组，runtime 在多次调用 signature 匹配通过后把模板实例化为 callable shell/函数，绕开 LLM 推理直接执行；任一步出错即回退到 LLM 路径。资源感知调度器在并发压力（API 429、CPU、内存）上升时按 (a) 节流新 sub-agent 启动 (b) 选择性挂起低优先级 sub-agent 的策略动态调整并发度，并把每条技能在上一次执行的有效并发度作为下次 hint。

技术新颖性

技术新颖性主要体现在四个层面。第一是'原始能力'作为中间表示：传统编译器的 IR 是字节码，SkVM 把 26 个多级能力向量当作技能 IR，使其既能在自然语言技能上做需求分解、也能在 LLM 上做画像测评，且满足 composability/generality/semantic-independence 三原则。第二是把 AOT/JIT 的双层结构移植到 prompt+执行链路：AOT 在安装期做静态画像与一次性特化，JIT 在运行时通过失败日志和 self-recovery trace 做自适应重编译，并设计 rollback 机制——若新变体比旧版差就回退，且每次重编译都从历史最优变体起步。第三是代码固化机制：把'75% 的技能含有结构固定、仅参数变化的代码片段'这一观察变成实际可执行的下沉路径，并通过'多次 signature 匹配后才晋升'的安全门避免模型漂移导致错误固化，失败时 fallback 到 LLM。第四是把经典编译器的 DLP/ILP/TLP 三级并行显式映射到 harness 能力（DLP 仅需 shell 级并行、ILP 需 harness 支持批量 tool dispatch、TLP 需 harness 支持 sub-agent spawn），并用资源感知调度器闭环运行时反馈。

**Figure 6**: Capability-based compilation on a PPTX skill

**Figure 7**: Concurrency extraction on an incident-response skill

**Figure 8**: Code solidification pipeline

实验结果

SkVM 在 8 个 LLM × 3 个 harness × SkillsBench/PinchBench 任务（118 个任务，每个任务 5 个 instance）上做了完整评估。Figure 9 给出任务完成率热力图，Figure 10 给出平均分数对比，Figure 11 给出 14 类技能在六个阶段（None / Orig / AOT / JIT.1 / JIT.2 / JIT.3）下的逐级提升。在任务完成率上，SkVM-Optimized 在 8 个模型、3 个 harness 上对所有 baseline（No Skill / Original / Skill-Creator）都拿到最高分；在 BareAgent 上对 Qwen3-30B 比 Skill-Creator 高 25 分、对 Devstral-Small 高 10 分，差距随模型变弱而放大。Figure 11 显示在 Qwen3-30B + BareAgent 上，11/14 类技能原始版本比'无技能'更差，SkVM 的 AOT 编译平均把分数拉回 +88%，JIT 进一步补齐 AOT 未覆盖的能力缺陷；1 轮 JIT 后 8/14 类技能拿到满分，3 轮后 10/14 满分；同时观察到 JIT 也会引入回归（如 Line Chart 任务早期注入示例过长触发解析错误，3 轮后修复）。Figure 12 显示大多数 (模型, harness) 组合点都落在'分数更高且 token 更少'的右上四象限，DS-v3.2 + BareAgent 的 token 节省接近 40%，来自消除多次错误重试。Figure 14 验证环境绑定：缺失依赖时 Qwen3.5-122B 直接失败、Opus 4.6 也能恢复但 token 多 56–69%；env-bound 把所有模型都拉回 complete 环境水平并大幅降 token。Figure 15–16 验证运行时优化：代码固化把 PDF-extract 从 10,469–15,116 ms 压到 206–568 ms（19–50× 加速），Weather-Current 因受网络 API 延迟限制降到约 5×，Weather-Forecast 因代码结构漂移从未晋升验证了安全门有效；并发提取在 8 类任务上最高 3.2× 端到端加速，TLP 收益最大、ILP 同时减少 LLM 调用次数、DLP 收益与数据量成正比。Figure 13 显示目标画像的离线开销对 Devstral-Small 是 7.3 min / $0.033，对 Qwen3-30B 是 31.1 min / $0.079，属一次性成本。最后 Figure 2 给出基线全景：同任务同技能下模型差异与 harness 差异幅度相当，开启技能后 15% 任务退化、17% 不变、87% 至少一个模型没收益；Figure 3 显示技能下载量长尾分布（skills.sh 上 89% 的技能下载 <86）。

**Table 1**: Representative primitive capabilities and their proficiency levels

**Figure 9**: Skill compilation effectiveness

**Figure 10**: Average task score by skill variant

**Figure 11**: Staged optimization breakdown across 14 skill categories

**Figure 12**: Score gain vs. token savings for SkVM optimization over the Original baseline

**Figure 13**: Per-category breakdown of capability profiling overhead for two small models

**Figure 14**: Environment binding restores correctness, token efficiency, and execution speed

**Figure 15**: Code solidification across four cases

**Figure 16**: Performance of different parallelization strategies across eight tasks

查看结构化数据

任务	指标	本文	基线	提升
SkillsBench 综合完成率（Qwen3-30B + BareAgent）	Average task score across 14 categories	SkVM 在 10/14 类别达到 100；AOT 较 Original 平均 +88%	Original: 11/14 类别低于 No Skill；Skill-Creator: 未在 Qwen3-30B 上单测	AOT 单次提升即 +88%，1 轮 JIT 8/14 满分，3 轮 10/14 满分
BareAgent 综合（弱模型提升幅度）	Task completion rate vs Skill-Creator baseline	Qwen3-30B +25，Devstral-Small +10	Skill-Creator（用 claude-opus-4.6 自动优化过的技能）	+10 到 +25 分（绝对值），弱模型收益最大
Token 节省（DS-v3.2 + BareAgent）	Output token 减少幅度	接近 40%	Original baseline	最高 ~40%
并发提取加速（8 类任务）	Wall-clock 加速比	最高 3.2× end-to-end	Sequential execution	最高 3.2×
代码固化（PDF-Extract）	Per-invocation latency	206–568 ms	10,469–15,116 ms (LLM path)	19–50×
环境绑定（Qwen3.5-122B，依赖缺失场景）	Success rate / token consumption	Env-bound 恢复到 complete 环境水平并大幅降 token	Deps-removed: 执行失败、token 2–4× 增长	成功恢复且 token 显著降低
跨 harness 一致性	OpenCode vs OpenClaw 分数差	SkVM 后差距 ≤ 5 分	Original: 差距最多 13 分	差距从最多 13 分压缩到 ≤ 5 分
代码固化安全门（Weather-Forecast）	Promotion rate	0/8 晋升（始终走 LLM 路径）	LLM path 为基线	未误晋升，验证 signature-match gate 有效

局限与改进

作者明确承认的局限有几条：技能编译因以自然语言为输入，本身存在不可消除的非确定性，论文用 rollback 机制和严格 pass 来缓解但不能完全消除；26 个原始能力目前覆盖 95% 的技能，未覆盖的能力需要用迭代流程继续扩充；AOT 编译会调用 LLM 产生 token 成本，虽然可被后续调用摊薄、也可跨用户共享。最后作者也承认对更强模型收益相对小——主要价值在 token 与时延节省而非完成率。作者未深入讨论的、读者也应注意的点：(a) JIT 的代码固化依赖'多次 signature 匹配'这一门槛，对一次性任务收益为 0；(b) 资源感知调度器的节流/挂起策略是启发式的，缺乏在更复杂多用户/多模型场景下的评估；(c) 实验硬件是 16GB Mac Mini M4，对更大规模并行和真实云环境中的资源调度效果未验证；(d) SkVM 需要修改 harness 才能加载变体，作者扩展了 BareAgent / OpenCode / OpenClaw 三个 harness，对未覆盖的 harness 落地成本未量化；(e) Figure 11 显示 JIT 也会引入回归（Line Chart 案例），rollback 机制虽存在但缺少对累计收益的更细粒度分析。

独立分析的弱点

独立观察到的弱点与改进方向包括：(1) 26 个原始能力的等级校准目前靠微基准反复迭代，对新增能力的扩展成本不低；改进方向是把能力定义和微基准套件做成可插拔的 registry，让社区贡献新的能力维度。(2) JIT 代码固化的 signature 匹配是文本/结构层面的，没有捕捉 LLM 输出中的语义漂移；改进方向是引入轻量的执行验证（沙箱跑一次输出检查是否符合 schema）作为晋升门槛的补充。(3) 资源感知调度器只看 CPU/内存/API 限流，对 harness 内部状态（如 token 用量、上下文窗口压力）无感知，可能在长上下文任务中过度节流；改进方向是把 harness 的运行时 telemetry 接入调度器。(4) AOT 编译对模型调用引入额外 token 成本（虽然论文说可摊薄），对小流量、单次执行的技能不划算；改进方向是引入'按调用频次决定是否编译'的策略，避免冷门技能的长尾成本。(5) JIT 自适应重编译只在多次失败时才触发，对一次性失败但对系统能力有揭示意义的情况利用不足；改进方向是引入更敏感的信号（部分退化、用户反馈）触发轻量级 patch 而非完整重编译。

未来方向

作者明确提出的未来方向有：随着技能库扩大按 §4.1 的迭代流程扩充原始能力集；进一步利用 AOT 编译结果跨用户、跨应用共享以摊薄成本；JIT 的能力缺陷检测将覆盖更多 AOT 静态画像未能覆盖的场景。基于本文成果，研究者还可以延展的方向包括：(a) 把 SkVM 的'能力差距→变换'框架反向用于 agent 训练——即用失败日志作为合成数据微调模型以缩小 capability gap，长期降低对编译的依赖；(b) 把代码固化机制泛化到非脚本类技能（如 API 调用模板、文档生成模板），从 shell 函数扩展到任意的 deterministic subroutine；(c) 探索将 DLP/ILP/TLP 并行与 agent 的多轮规划结合，让 runtime 在 DAG 上做动态调度（而不只是按编译期标注执行）；(d) 把 SkVM 的设计语言推广到 multi-agent 协作场景，把每个 sub-agent 当作处理器，把跨 agent 的'技能调用'当作异构计算图，研究任务级与 agent 级的两层并行。

复现评估

论文声称将在 https://github.com/Chencheng233/SkVM 开源 SkVM（基于论文上下文）。评估使用 SkillsBench 和 PinchBench 作为基准，并扩展任务；技能来源覆盖 Anthropic-skills、OpenClaw skills、skills.sh；评测覆盖 8 个模型（Claude Opus 4.6、DeepSeek V3.2、Gemini 3 Flash、Qwen3.5-397B、Qwen3.5-122B、Claude 3.5 Haiku、Qwen3-30B、Devstral-Small） × 3 个 harness（BareAgent 自研极简版、OpenCode、OpenClaw），每个任务生成 5 个不同 instance 取平均。算力方面目标画像仅一次性：Devstral-Small 7.3 min / $0.033、Qwen3-30B 31.1 min / $0.079，整体在 16GB Mac Mini M4 上完成，对小实验室较友好。复现难度中等：模型 API 调用成本是主要开销（8 模型 × 多 harness × 118 任务 × 5 instance 的端到端评估不便宜），且需要修改 harness 加载机制；需要一定的 LLM API 预算和工程能力。自动化评测用静态分析+LLM-as-judge，与 SWE-Bench 同源，相对客观。

SkVM：面向技能跨异构 LLM 与 Agent 框架高效执行的虚拟机 SkVM: Compiling Skills for Efficient Execution Everywhere