---

SkVM: Revisiting Language VM for Skills across Heterogenous LLMs and Harnesses

• https://arxiv.org/abs/2604.03088
• https://github.com/SJTU-IPADS/SkVM

想象一个场景：你从技能市场下载了一个"数据分析助手"技能包，满心期待地装进你的 AI 智能体。结果呢？它不仅没帮上忙，反而把原本能做对的任务搞砸了——就像给一个熟练工人塞了一本看不懂的操作手册，越看越糊涂。

这不是假设。上海交通大学 IPADS 实验室的研究团队对 clawhub.ai 和 skills.sh 两大平台上超过 118,000 个技能包进行了系统分析，发现了一个令人不安的事实：同一个技能包，换一个 AI 模型或换一个执行框架，表现可能天差地别——15% 的任务性能反而下降，17% 毫无变化，而在 87% 的任务中，至少有一个模型完全无法从技能包中获益。

为什么会这样？答案出奇的简单：因为这些技能包本质上就是 Markdown 文本文件，被直接"丢给"AI 去读，没有经过任何编译或优化。就像把同一份 C 语言源码直接扔给 x86、ARM、RISC-V 三种处理器裸奔——不出错才奇怪。

SkVM（Skill Virtual Machine）的解决思路正是从这个类比出发：把技能视为"代码"，把大语言模型视为"异构处理器"，而 SkVM 自己，则充当编译器和运行时。 它从 15,063 个代表性技能中提炼出 26 种"原始能力"（Primitive Capabilities），覆盖代码生成、工具使用、推理和指令遵循四大类别，能够描述 95% 的技能需求。在此基础上，SkVM 通过能力画像（Profiling）、提前编译（AOT-Compilation）、运行时优化（JIT-Optimization）和基准评测（Benchmark）四大组件的协同，实现了技能的"一次编写，处处高效运行"。

效果如何？在 8 个不同规模的 LLM 和 3 个主流 Agent 框架上的评测表明：任务完成率显著提升，Token 消耗最多降低 40%，通过并行化实现最高 3.2 倍加速，而代码固化技术更将延迟降低了 19 到 50 倍。项目已在 GitHub 开源（v0.1.5，2026 年 4 月），目前获得 298 个 Star 和 26 个 Fork。

---

一、问题：技能为什么"水土不服"？

要理解 SkVM 解决了什么，先要理解 LLM 智能体是如何工作的。

当前主流智能体遵循 ReAct（Reasoning and Acting，推理-行动）循环：接收任务 → 推理 → 调用工具 → 观察结果 → 继续推理 → ……直到任务完成。这个"思考-行动-观察-再思考"的循环，正是人类解决复杂问题的认知模式在 AI 中的复现。

为了让智能体在特定领域更专业，业界发展出了技能包（Skill）。一个典型的技能包包含三部分：描述名称和适用场景的"名片"、用自然语言详述操作步骤和工具用法的"正文"、以及包含脚本、模板和代码片段的"附件"。目前，clawhub.ai 和 skills.sh 两大平台合计上架了超过 118,000 个技能包，覆盖数据分析、金融、办公自动化、编程开发等几乎所有常见场景。

问题在于，这些技能包绝大多数只是 Markdown 纯文本——被直接塞给 AI，没有经过任何编译或优化处理。更糟的是，研究团队的测试揭示了一个系统性问题：同一技能在不同模型或框架下的表现不仅不一致，甚至可能相反。

研究团队将技能移植失败的原因归纳为三种典型的"失配"：

第一种：模型失配（Model Mismatch）。 不同 AI 模型的能力差异极大。技能包的写法往往默认读者是"高水平"模型，导致在能力较弱的模型上无法正确理解和执行。比如一个假设模型具备强代码生成能力的技能包，碰到代码能力弱的模型就会以各种方式失败。

第二种：执行环境失配（Execution Environment Mismatch）。 即使是同一个模型、同一个技能、同一个任务，换用不同的"执行框架"（Harness）也可能导致结果天差地别。执行框架负责编排智能体、管理工具访问、处理输入输出——不同框架在工具调用接口、上下文管理方式、错误处理机制上的差异，会直接影响技能的执行效果。

第三种：运行环境失配（Runtime Environment Mismatch）。 技能包中可能声明"需要 Python 3.9+"、“依赖 numpy 库"或"需要 Docker”，但用户的机器上根本没有安装这些依赖。技能跑不起来，再好的提示词也白费。

这三种失配叠加，造成了一个根本问题：技能的脆弱性（Fragility）——同一技能在不同模型-框架组合下行为不一致。对开发者来说，这意味着"N 个技能 × M 个模型 = N×M 次手动适配"的组合爆炸；对终端用户来说，从技能市场下载的包可能根本无法正常工作。

那么问题来了：有没有一套系统，能像传统编译器屏蔽硬件差异那样，帮技能屏蔽模型和框架的差异？

---

二、破局：“技能即代码，模型即处理器”

这正是 SkVM 的核心洞察。

在传统计算机系统中，C 语言源码需要通过编译器转换为机器码，才能在特定处理器上执行。不同架构的处理器（x86、ARM、RISC-V）需要不同的机器码——编译器的核心价值，正是屏蔽底层硬件差异，为上层应用提供统一抽象。

SkVM 将这一理念直接迁移到智能体领域：技能 ≈ 源代码，不同的 LLM ≈ 不同架构的处理器，而 SkVM ≈ 编译器 + 虚拟机。 正如 Java 虚拟机（JVM）通过字节码抽象实现"一次编写，处处运行"，SkVM 的目标是实现技能的"一次编写，处处高效运行"（Write Once, Run Everywhere Efficiently）。

SkVM 团队还从另一个深度学习编译器——TVM（Tensor Virtual Machine）——中汲取了灵感。TVM 通过高级图优化和代码生成技术，将深度学习模型高效部署到各种硬件后端。SkVM 借鉴了这种"针对特定目标优化"的思路，但将应用场景从"模型部署"转向了"技能执行"：TVM 关心的是如何让训练好的模型在特定硬件上跑得快，SkVM 关心的是如何让写好的技能在特定模型-框架组合上跑得好。

三阶段流水线

基于这个类比，SkVM 设计了一条三阶段流水线——“分析 → 编译 → 优化”，环环相扣。

第一阶段：Profile（能力画像）。 系统针对目标模型和框架组合，生成一份"目标能力配置文件"（Target Capability Profile, TCP）。SkVM 定义了 26 种原始能力，覆盖代码生成、工具使用、推理和指令遵循四大类别，每个能力还分多个熟练度等级。通过运行一系列微基准测试（Micro-benchmarks），系统量化目标环境在每种原始能力上的实际表现——说白了，就是先摸清"这台处理器到底擅长什么、不擅长什么"。

第二阶段：AoT Compile（提前编译）。 在用户首次安装技能时自动触发。编译器读入原始技能文本，通过三个子阶段产出优化后的技能变体：第一遍做能力差距分析——对比技能需要什么、目标能提供什么，找到缺口并选择补偿策略；第二遍做环境绑定——将技能中声明的依赖与实际运行环境匹配，解决"缺库少件"的问题；第三遍做并发提取——识别技能中可并行执行的任务片段，为后续运行时并行调度做准备。

第三阶段：Optimize（运行时优化）。 在技能实际执行过程中持续进行，包含两个独立的 JIT（Just-In-Time，即时编译）子系统：JIT-Boost 监听 LLM 调用模式，当检测到重复的代码生成请求时，将代码模板缓存下来——后续直接填参数执行，完全绕过 LLM 调用；JIT-Optimize 更为激进，它基于运行时收集的证据直接编辑技能文本本身，通过提案树（Proposal Tree）管理优化版本，滚动评估并自动选择最佳版本。此外还有 Autotune 功能，基于合成任务进行全闭环自监督优化——生成任务 → 执行 → 评分 → 提交编辑提案，循环往复直至收敛。

---

三、四大核心组件——深入细节

3.1 Profiling：用 26 种"原始能力"给模型画像

能力画像的核心创新在于提出**原始能力（Primitive Capabilities）**这一抽象。原始能力被定义为"技能从目标处所需的基本能力"，是不可再拆的最小单元。这个定义遵循三条原则：组合性（任何具体任务都能用原始能力的组合来描述）、通用性（每个原始能力必须广泛出现在大量技能中，避免能力集无限制膨胀）、语义独立性（只关心结构是否正确，不关心输出有没有"洞见"）。

这 26 种原始能力是怎么来的？团队从 15,063 个技能中，分两阶段推导得出。第一阶段精选 50 个代表性技能——覆盖文档生成、脚本执行、数据分析和代码开发——用 LLM 辅助分解出 19 个初始能力，再由人工逐一审核。第二阶段用完整的 15,063 个技能语料库验证：每个技能的需求能否用现有原始能力的组合来表达？覆盖不了的技能会暴露缺失的能力，只有当缺失的能力出现在至少 1% 的语料库中时才会被加入。这样既保证了覆盖度（最终满足 95% 的技能需求），又过滤掉了过于冷门的特定领域需求。

对于每个原始能力的每个等级，团队生成了对应的微基准测试。运行这些测试，就能得到模型在特定能力维度上的量化表现。SkVM CLI 提供 skvm profile 命令，会为每个（模型, 框架）组合生成缓存的 TCP 文件，供后续的编译和流水线任务复用。

3.2 AOT 编译：三遍改写，逐层补缺

知道了目标环境的能力缺口，下一步就是自动改写技能来弥补这些缺口。

AOT 编译器的三遍流水线，每一遍解决一类问题。**第一遍，基于能力的编译（Capability-Based Compilation）**专门处理模型-工具套件不匹配。编译器用原始能力作为"词汇表"，把技能的需求和目标的能力都翻译成同一种语言，然后对比差距，选择优化策略。例如，当目标模型的 JSON 结构化输出能力较弱时，编译器会自动插入额外的格式验证和修复逻辑。

**第二遍，环境绑定（Environment Binding）**解决运行环境失配。技能包里常写着"需要 Python 3.9+"、“依赖 numpy”、“需要 Docker”——绑定阶段负责验证这些依赖在目标环境中是否存在，识别缺失项并提供安装指引或替代方案。

**第三遍，并发提取（Concurrency Extraction）**分析技能中可并行执行的任务片段。智能体任务往往包含多个相对独立的子任务——比如数据分析技能中，数据加载、格式转换、初步统计可能可以同时进行。编译器识别这些并行机会，为运行时的并行调度提供依据。

评测显示，经过 AOT 编译后，平均任务得分提升了 88%。更值得注意的是，在 14 个技能类别中有 11 个，原始技能的表现还不如直接不使用技能——说明未经优化的技能包不但帮不上忙，反而引入噪声和误导。而 AOT 编译后的变体在所有类别上都超越了无技能基线。

3.3 JIT 优化：运行时自我进化

编译阶段再细致，也无法预知所有运行时情况。有些优化机会，只有在技能真正跑起来之后才会暴露。SkVM 用两个互补的 JIT 系统来应对。

**JIT-Boost（代码固化）**的核心思想很简单：如果 LLM 反复生成类似的代码，为什么不把第一次的成果缓存起来，后面直接复用？具体做法是：先扫描整个技能包，生成包含代码签名、关键词、参数模板和执行模板的候选条目。运行时，系统通过钩子监听 LLM 调用，当某条缓存命中足够多次连续成功后，候选条目被"升级"——此后直接从提示词中提取参数，执行存储的模板，完全不再调用 LLM。如果固化后的模板执行失败，系统自动降级回退到 LLM 调用。

这个机制不会修改技能源代码，只加速稳定的重复行为路径。评测数据显示，代码固化将延迟降低了 19 到 50 倍——说明大量技能任务中确实存在可固化的重复模式。

JIT-Optimize（技能重写）比代码固化激进得多：它直接编辑技能文本本身。工作流程是：把运行证据标准化为通用格式 → 将技能复制到临时工作区 → 启动一个无界面 Agent 编辑 SKILL.md 或其他技能包文件 → 提交包含根因分析、推理过程、置信度和变更文件的结构化记录 → 快照为编号版本 → 在适当时机重新运行评估，根据得分选择最佳版本。整个过程基于提案树（Proposal Tree），支持版本回滚和效果对比，而不是一股脑覆盖原文件。

Autotune 是 JIT-Optimize 的升级版——基于合成任务的全闭环自监督优化。它不需要人工标注数据，而是自动生成评估任务、执行、评分、提交编辑提案，循环往复直至任务耗尽或收敛。对于长期运行的生产环境来说，这意味着技能可以根据实际执行反馈"自我进化"。

3.4 Benchmark：用数据说话

再好的设计也需要数据验证。SkVM 的评测建立在 SkillsBench 之上——这是首个专门评估智能体技能实际效果的基准框架，由独立研究团队于 2026 年 2 月发布。SkillsBench 包含 84 到 86 个专家精心设计的任务，覆盖 11 个领域，每个任务都配备了经过人工审核的技能包和确定性验证器。

SkillsBench 的分层设计很清晰：最底层是模型层（Models Layer）——类比 CPU，提供原始计算能力；中间层是Agent 框架层（Agent Harness Layer）——类比操作系统，负责编排智能体、管理工具、处理输入输出；最上层是技能层（Skills Layer）——类比应用程序，为特定任务提供专业知识和工具。这种分层让评测结果可以被清晰地归因到具体层面，知道到底是模型不行、框架不行、还是技能不行。

---

四、实测效果——数据说话

SkVM 在 8 个不同规模的 LLM 和 3 个 Agent 框架上进行了系统评测，测试任务总计 118 个，涵盖简单、中等和困难三个难度级别，涉及 3D 打印、自适应巡航控制、数据分析、文档生成、脚本执行、代码开发等多个领域。

任务完成率：越弱的模型，获益越大

一个耐人寻味的规律浮现出来：模型越弱，从 SkVM 优化中获益越多。 在 BareAgent 工具链下，qwen3-30b 的得分提升了 25%，而更强的 devstral-small 提升了 10%。这不是因为优化对强模型无用，而是因为弱模型本身具备完成任务的逻辑能力，但在生成复杂 JSON、管理环境依赖等"非逻辑环节"存在明显短板——SkVM 恰好补上了这些短板。强模型在这些环节本来就不弱，SkVM 对它的主要帮助体现在减少 Token 消耗和执行延迟上。

阶段拆解进一步揭示了原始技能的问题严重性：14 个技能类别中有 11 个，原始技能的表现不如直接不用技能。经过 AOT 编译后，平均任务得分提升 88%，所有类别全部超越无技能基线。JIT 优化继续发力——一轮 JIT 后，14 个技能中有 8 个在评估任务中拿到满分；三轮后，满分技能增加到 10 个。

性能提升：更快、更省、更稳定

在三个性能维度上，SkVM 都给出了扎实的数据：

• 延迟：代码固化降低 19 到 50 倍。许多技能任务存在大量可固化的重复模式，一旦缓存命中，响应接近瞬时。
• 吞吐量：并行化实现最高 3.2 倍加速。AOT 编译阶段识别的并行机会在运行时得到充分调度。
• 资源消耗：Token 用量最多减少 40%。一是 JIT-Boost 绕过了部分 LLM 调用，二是 AOT 编译后的技能变体更加精简高效。

关键是，这些性能增益不是用质量换来的。优化后技能得分下降的比例仅为 4.5%，而未优化技能的这个数字是 15%——优化不仅让技能更快，还让它更可靠。

跨模型、跨框架：真正可移植

SkVM 的核心设计目标是可移植性，评测也验证了这一点。使用未优化技能时，不同工具链（OpenCode 和 OpenClaw）之间的得分差距最高可达 13 分；SkVM 优化后，两个工具链的得分都提升了，差距缩小到最多 5 分。这证明 SkVM 确实有效屏蔽了底层框架差异，为上层技能提供了统一的执行抽象。

---

五、开源生态与技术定位

代码与架构

SkVM 在 GitHub 上完全开源，由 IPADS 实验室维护（github.com/SJTU-IPADS/SkVM）。首个版本 v0.1.5 于 2026 年 4 月 18 日发布，采用 Node.js 技术栈，要求 Node ≥ 18，通过 npm 分发：

npm i -g @ipads-skvm/skvm

安装后，程序在 ~/.local/share/skvm/bin/skvm 生成独立二进制文件，并在 ~/.local/bin/skvm 创建软链接。项目内置独立隔离的无界面 Agent 运行时，仅供 skvm jit-optimize 内部调用，不会干扰全局安装的 Agent 或命令行工具。

项目结构对应四大核心模块：性能分析模块（26 种原始能力测试套件）、AOT 编译模块（多阶段编译流程）、JIT 优化模块（JIT-Boost + JIT-Optimize）、基准测试模块（多任务多条件评测）。此外还有独立的 skvm-data 数据仓库，存储评测数据集和基准测试结果。

框架集成：复制即集成

SkVM 当前支持 OpenClaw、Hermes Agent、pi Agent、bare-agent、opencode 等主流开源 Agent 框架。OpenClaw 强调可扩展性和社区贡献；Hermes Agent 专注于持续学习和记忆机制；pi Agent 则致力于在低功耗硬件（如树莓派）上运行智能体，推动边缘 AI 发展。

与 SkVM 的集成方式非常简洁——把内置技能目录复制到对应框架的技能目录即可：

# OpenClaw
cp -r ~/.local/share/skvm/skills/skvm-jit ~/.openclaw/workspace/skills/
cp -r ~/.local/share/skvm/skills/skvm-general ~/.openclaw/workspace/skills/

# Hermes Agent
cp -r ~/.local/share/skvm/skills/skvm-jit ~/.hermes/skills/
cp -r ~/.local/share/skvm/skills/skvm-general ~/.hermes/skills/

# pi Agent
mkdir -p ~/.pi/agent/skills
cp -r ~/.local/share/skvm/skills/skvm-jit ~/.pi/agent/skills/
cp -r ~/.local/share/skvm/skills/skvm-general ~/.pi/agent/skills/

GitHub issue 中已有社区成员提出对 PI coding agent 的支持请求（#2），表明框架生态仍在积极扩展中。

命令行界面提供完整的开发-优化-评测工具链：skvm profile（能力分析）、skvm aot-compile（提前编译）、skvm jit-optimize（运行时优化）、skvm bench（基准测试）。

与相关技术的关系

SkVM 并非凭空出现，它与三个重要技术方向有密切关系。

与 Anthropic Agent Skills 标准的关系：增强而非替代。 2025 年 12 月，Anthropic 将 Agent Skills 规范作为公开标准发布，定义了基于 SKILL.md 的技能包格式。SkVM 可以读取遵循该标准的技能包，编译优化后输出为兼容格式——SkVM 为 Anthropic 标准技能包提供了"编译器层"的能力增强。

与 MCP（Model Context Protocol）的关系：互补而非重叠。 MCP 关注智能体与外部工具之间的通信协议标准化；SkVM 关注技能本身的编译优化。一个使用 MCP 协议与工具交互的技能包，同样可以通过 SkVM 进行编译优化——两者在不同层次协同工作。

与传统编译器技术的关系：双重虚拟化。 SkVM 明确借鉴了 JVM 和 TVM 的设计思想：像 JVM 一样提供跨平台的可移植性（“一次编写，处处运行”），又像 TVM 一样提供针对特定目标的性能优化。这种"以编译思维解决智能体问题"的范式转换，是 SkVM 最核心的技术贡献。

---

六、研究团队

SkVM 由上海交通大学 IPADS 实验室（并行与分布式系统研究所）研发。IPADS 成立于 1990 年代初期，三十年来致力于系统软件领域的研究，研究方向涵盖操作系统、分布式系统、编译器技术、安全与隐私、机器学习系统等。在 LLM 推理系统方面，IPADS 此前已发布 PowerInfer 系列——通过稀疏激活感知和 GPU-CPU 混合推理，在消费级显卡甚至手机上高效运行大模型。这一系列工作为 SkVM 积累了 LLM 性能分析、异构硬件适配和运行时优化方面的深厚技术基础。

SkVM 论文的四位作者均为 IPADS 核心成员：陈乐和冯二虎负责系统架构设计和编译器实现；夏虞斌教授是系统安全领域的资深学者，于 2024 年 12 月当选 ACM 杰出会员；陈海波教授是实验室负责人及论文通讯作者，在系统软件领域享有盛誉。论文于 2026 年 4 月提交至 arXiv，跨列软件工程（cs.SE）和机器学习（cs.LG）两个类别，已被 HuggingFace Daily Papers、CatalyzeX、AlphaXiv 等多个学术聚合平台收录推荐。

---

七、局限与未来

任何一个新兴系统都有边界，SkVM 也不例外。

平台覆盖方面，GitHub issue #6（2026 年 4 月 24 日）显示社区已提出 Windows 支持请求，当前版本主要面向 macOS 和 Linux，Windows 支持时间表未定。框架覆盖方面，虽然已支持 OpenClaw、Hermes Agent、pi Agent 等主流框架，但新兴框架（如 NVIDIA NeMoClaw 等）的适配尚未落地。公开信息方面，26 种原始能力的完整清单及其四级分类的具体内容，以及评测中使用的 8 个 LLM 和 3 个框架的具体名称，均未在公开资料中完整披露，这对外部研究者复现和深入评估造成了一定障碍。技能生态方面，当前技能市场中大量技能包仍以 Markdown 纯文本形式存在，缺乏结构化描述和明确的能力声明——这将直接影响 SkVM 编译优化的效果上限。

展望未来，三个方向的探索值得关注。技术深化方面，更细粒度的能力建模（满足生物医药、金融风控等高度专业化领域的需求）和多模态技能支持（随着图像、音频等多模态 Agent 的兴起）将是重要课题。生态扩展方面，Windows 平台支持、更多框架适配、以及与 VS Code、Cursor 等主流 IDE 的深度集成，将显著扩大用户基础；积极参与 Agent Skills 行业标准的制定，也有助于巩固 SkVM 在技能编译领域的先发优势。应用拓展方面，企业级技能市场（将企业内部工具和流程编译为可移植的技能包）和边缘设备技能执行（结合 PowerInfer 的端侧推理经验，将轻量级技能部署到手机和 IoT 设备），都是值得期待的方向。

---

八、结语

SkVM 的出现，标志着 AI 智能体技能生态从"手工作坊"走向"工业化编译"的第一步。

在它之前，技能的可移植性问题被普遍视为提示工程的任务——靠人力逐个模型、逐个框架地调试适配。SkVM 证明了这个思路的局限性：技能可移植性的本质不是一个提示词问题，而是一个编译器问题。就像高级语言不需要程序员手动为每个 CPU 架构写汇编一样，设计良好的技能也不应该要求开发者手动适配每个 LLM 和框架。

当然，SkVM 还远非成熟——它更像 GCC 在 1987 年的第一个版本：核心思想已经立住了，但工程成熟度、生态广度、社区活跃度都还有巨大的成长空间。它的真正价值或许不在于当下能把技能优化多少个百分点，而在于为整个领域打开了一扇新的大门：用系统的、自动化的、可复现的方式，而不是靠手工调参和运气，来管理和优化 AI 智能体的能力。 对于正在构建 AI Agent 应用的开发者而言，这个范式转换值得认真关注。