Skill 确实好用，但架不住模型和 Agent Harness 适配翻车。
不是所有模型都吃得动 Skill，有的用上直接反向掉性能。
从计算机系统架构角度审视"程序语言"和" Skill 语言"
为了解决这个问题，来自上海交大的 IPADS 研究团队提出了SkVM：面向 Skill 的语言虚拟机。
在 Agent 时代下，Skill 是代码，而不同的 LLM 是异构处理器。
研究团队借鉴了经典语言虚拟机（如 Java Virtual Machine）的架构，首次为 Skill 设计了原生的语言虚拟机，让 Skill 通过一次编写，能够在任意的模型和 Agent Harness 上高效运行。
通过 SkVM 编译后的 Skill，甚至能够让小模型（30B）获得匹配 Opus4.6 的精度，同时减少 40% 的 token 消耗量和至多 50 倍的运行速度提升。
从而一键提升 OpenClaw、Hermes、openJiuwen、PI 等 Agent 框架与 Clawhub 等主流 Skill 生态的执行速度、Token 效率与任务精度。
Skill 与模型间不匹配
同一个技能在不同模型 / 不同 harness 组合上的执行效果天差地别，甚至还会拖后腿。
上海交大 IPADS 的研究人员分析了超过 11.8 万个技能，发现：
15% 的任务在使用技能后反而性能下降；
87% 的任务至少有一个模型没有任何提升；
有的技能带来的 token 开销暴增 451%，但成功率却纹丝不动。
采取 Skill 前后，对于任务完成率的影响，红色表示下降，绿色表示上升
原因很简单：
技能写的是"自然语言代码"，但模型和运行环境千差万别，Skill 需求的能力和模型与环境提供的能力，存在明显的语义鸿沟！
具体而言：
模型能力不匹配：技能预设模型很聪明，但如果你用的是个小模型，它可能完全听不懂你在说什么，强行使用甚至会导致 15% 的任务性能下降；
环境依赖老报错：技能里写了要用某个 Python 包，但用户的电脑上根本没装，大模型只能不断试错，疯狂浪费 Token；
又慢又贵：高度重复的死板工作，大模型每次都要重新走一遍"推理 - 工具调用"的脑回路，Token 成本极高 。
SkVM：一次编写，处处高效！
面对上面所述的痛点，上交大团队从传统的语言虚拟机设计中汲取灵感，给出了面向自然语言的虚拟机 SkVM 架构，其整体架构如下图所示：
SkVM 整体架构：包含 AOT 编译优化和运行时优化两个部分
SkVM 类比了经典了 Java 语言虚拟机（JVM）的设计，提炼了底层运行抽象，结合 AOT/JIT 等编译方式，并在运行时做自适应调优和运行时调度。
下表展示了 SkVM 和 JVM 在不同编译优化策略上的对比：
AOT 编译（Ahead-of-Time Compilation）：将 Skill 编译成模型更能看懂的形式
在安装 Skill 的时候，AOT 编译器（由编译优化 Skill+LLM 组成）会对 Skill 进行编译，生成多个编译后产物，帮助后续 Agent Harness+LLM 在运行时更好地理解 Skill。
SkVM 在运行前会做三件事：
PASS-1 基于能力的编译
系统提炼了 26 种"原子能力"（Primitive Capabilities），像测 CPU 跑分一样先摸底你的大模型。
不同于其他的 LLM 测试集，原子能力并非测试大模型能否解决一个复杂逻辑问题，更多是测试模型是否具备工具调用，指令遵循，格式对齐等对立、可组合、以及逻辑无关的基本能力。
同时，对于每一个"原子能力"，也会进行分级打分，从而生成更加客观的大模型 +Harness 组合能力画像。
其次，编译器会去分析 Skill 本身需要哪些"原子能力"，以及对应的等级。
如果 Skill 需要的"原子能力"等级大于当前运行的大模型 +Harness 能够提供的能力等级，编译器会编译 Skill，以降低 Skill 的能力需求。
例如，Skill 中往往会包含一些预先定义的 python/js 执行文件，而这些文件通常是通过相对路径定义的。
如果模型 +Agent harness 缺乏对应相对路径的解析能力，编译器会在安装 Skill 的时候，将相对路径转换为绝对路径，以降低 Skill 对于"脚本执行"这一原子能力的等级需求。
基于模型原子能力的 skill 编译
PASS-2 环境绑定
Skill 中往往会定义运行需要的环境和依赖。
Agent 在运行时候，LLM 会检查并且安装对应的环境，导致大量的 token 浪费 / 环境安装失败。
为此，AOT 编译器自动提取技能需要的包和工具，生成安装 / 检验脚本。运行前一键配好环境，不用大模型自己尝试排错了 。
PASS-3 并发提取
有超过 76% 的 Skill 中包含 workflow，并且 Agent harness 默认会采用串行的方式执行。
AOT 编译能够发掘 Skill 执行过程中，不同粒度的并行机会，包括数据并行（一条指令，多个数据）、指令并行（无依赖的指令并行发射）和线程并行（多个独立的 sub-agent，完成不同的子任务），并且生成可并行的 DAG 工作流图。
同时，开发者还可以自定义编译优化机制，注册到 AOT 编译器中，从而进一步对 Skill 进行运行前优化。
运行时优化：越跑越准，越跑越省
除了静态编译，在运行时，SkVM 会采用 JIT（Just-in-Time Compilation）加速 Skill 的执行效率。
代码固化（Code Solidification）
Skill 中定义的脚本，往往是可变参数的代码模板。
Skill 在每次运行时，LLM 都需要反复生成可执行的脚本，导致大量 token 的浪费。
为此，SkVM 会在 AOT 阶段，生成代码的指纹，模板，以及对应的参数列表。
在运行阶段，调用 Skill 后由 LLM 生成的代码，和 AOT 阶段提前生成的代码指纹进行匹配，如果连续多次匹配成功，SkVM 会采用 JIT 编译优化，根据输入参数，直接固化可执行的代码，而非每次由 LLM 重新生成。
自适应重编译
如果在运行中出现报错 / 重试，系统会收集错误日志反馈给编译器，自动重新优化技能。
防止每次运行 Skill 的过程中，发生同样的错误，并且提高任务的成功率。
在运行时，SkVM 除了采用 JIT 的编译优化外，还会负责 Skill 生命周期、加载管理，保证 Skill 编译后新的编译产物，能够正确的加载和执行。
同时，SkVM 还会根据当前的系统资源，调节并行粒度，减少不必要的资源竞争。
实验结果：小模型 +SkVM 比肩 Opus4 .6，效率至多提升 50 倍
研究团队在包含代码生成、数据分析等 118 个代表性任务上进行了测试。
结果显示，SkVM 带来的收益非常显著。尤其是对于偏弱的小模型，提升最为显著，因为它弥补了小模型在处理复杂 JSON 结构生成、环境依赖、脚本解析上的短板，使得 qwen 30B 拥有比肩 Opus 4.6 的任务成功率。
对于顶尖模型，采用 SkVM 编译后，消耗的 token 至多下降 40%。
经过 SkVM 编译后和原始 Skill 在任务完成率上的对比，绿色深度表示提升的幅度，数字表示完成率分数
不同模型 +Harness 下，没有 Skill、原始 Skill、Skill-creator、SkVM 的任务完成率对比
同时，得益于"代码固化"技术，代码部分的执行时间，从上万毫秒直接压缩到了几百毫秒，速度飙升 19 到 50 倍。
而针对 Skill 中潜在的并行机会，SkVM 通过数据并行、指令并行和线程并行，将 Skill 的执行效率至多提升 3.2 倍。
△数据并行、指令并行、线程并行下 Skill 效率的提升
触发 JIT- 代码固化优化前后，token 消耗量和执行延迟间的对比
目前，SkVM 能够无缝键入 openClaw，Hermes Agent，openJiuwen Agent、PI Agent 等主流的 Agent 框架，支持 Clawhub 等主流的 Skill 生态。
SkVM 论文：https://arxiv.org/abs/2604.03088
项目网站：https://skillvm.ai/
项目仓库：https://github.com/SJTU-IPADS/SkVM/
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
我们正在招聘一名眼疾手快、关注 AI 的学术编辑实习生 � �
感兴趣的小伙伴欢迎关注 � � 了解详情
� � 点亮星标 � �
科技前沿进展每日见
泓川证券提示：文章来自网络，不代表本站观点。
