这项由上海交通大学计算机科学团队主导的研究，以预印本形式发布于2026年4月，编号为arXiv:2604.03088v3，有兴趣深入了解的读者可通过该编号查阅完整论文。

假设你雇了一位助理，给他一本厚厚的工作手册，告诉他"按照手册里的步骤帮我完成任务"。如果这位助理是一名资深专家，他会一眼看懂手册里的每个细节，流畅完成任务。但如果换成一位刚入职的新人，同样的手册他可能看不懂某些专业指令，搞出一堆错误。更麻烦的是，手册里某些步骤需要用到特定工具，但办公室里根本没有这些工具，新人就只能在那里干着急，浪费大量时间瞎折腾。

这就是当前AI智能体使用"技能包"时每天都在发生的真实困境。上海交通大学的研究团队在分析了超过11.8万个技能包之后，发现这个问题严重到令人咋舌——他们因此设计了一套叫做SkVM的系统，专门充当技能包和AI模型之间的"翻译+调度员"，让任何能力水平的AI模型都能正确、高效地执行技能包中的指令。

**一、"技能包"是什么，为什么AI现在离不开它**

要理解这项研究，得先搞清楚"技能包"是什么东西。现代AI智能体的工作方式很像一个不断思考、不断行动的工人：收到任务之后，它会反复推理、调用工具、观察结果，再继续推理，直到任务完成。这个循环被称为"ReAct循环"，类似于人类在解决问题时"想一想、做一做、看结果、再想想"的过程。

技能包的出现，就是为了给这个工人额外塞一本"领域专属操作手册"。一个技能包通常由三部分组成：第一部分是"名片"，记录这个技能包叫什么名字、适用于什么场景；第二部分是"正文"，用自然语言描述具体的操作步骤、工具用法和注意事项；第三部分是"附件"，包含脚本、模板和代码片段。

举个具体例子：有一个专门处理PDF文件的技能包，它会教AI如何使用pdfplumber这个库来提取表格，同时还会提醒AI合并PDF文件时要用pypdf而不是已经过时的PyPDF2。这类技能包相当于把领域专家的经验直接打包塞进AI的"脑袋"，让它不需要自己摸索就能用正确的方式完成任务。

目前，两个主要的技能包分发平台——clawhub.ai和skills.sh——合计上架了超过11.8万个技能包，覆盖数据分析、金融、办公自动化、编程开发等几乎所有常见工作场景。然而，这些技能包绝大多数都只是一份Markdown格式的纯文本文件，直接丢给AI去读。这种"把手册往桌上一扔"的做法，带来了严重的问题。

**二、同一本手册，不同的人读出了完全不同的结果**

研究团队对八个不同能力水平的AI模型做了测试，结果触目惊心。启用技能包之后，有15%的任务得分反而下降了——也就是说，给AI看了手册，它做得反而更差。另有17%的任务得分毫无变化（排除那些本来就能100%完成的任务）。更令人沮丧的是，在87%的任务上，至少有一个AI模型在使用技能包后没有任何改善。

这背后有三种典型的失败模式，研究团队把它们分别称为"模型失配"、"执行环境失配"和"运行环境失配"。

模型失配是最直观的问题。不同AI模型的能力差异极大，技能包的写法往往默认读者是"高水平"模型。研究团队记录了一个生动的案例：有一个用于生成PowerPoint演示文稿的技能包，推荐使用一个叫PptxGenJS的JavaScript库。Claude Opus 4.6和Gemini 3 Flash这两个顶级模型都能正确理解这是一个编程库，拿到满分100分。但Devstral Small这个较弱的模型却把PptxGenJS误认为是命令行工具，反复执行错误的命令，最终失败。如果不加载这个技能包，Devstral Small反而会自己选择熟悉的python-pptx库，得到95分。

执行环境失配则更加隐蔽。同一个AI模型、同一个技能包、同一个任务，但换了一个不同的"执行框架"（也就是给AI提供工具和运行环境的软件），结果可能天差地别。Gemini 3 Flash在BareAgent这个简单框架里用原始技能包完成工作日排班任务得了满分，但换到OpenCode框架里得了0分。失败原因是OpenCode框架会在对话开头塞入大量工具说明文档，让整个上下文变得很长，最终导致AI输出了格式错误的JSON，无法被解析。

运行环境失配是最实际的痛点。技能包里写着"需要用到某某库"，但用户的机器上根本没装。研究团队测试发现，当必要的库缺失时，两个Qwen模型的成功率直接跌到33%至67%，同时还会产生2到4倍多余的输出——因为模型在不停尝试各种变通方案。就连最强的Claude Opus 4.6，虽然最终能自己诊断并安装缺失的库，但也因此多消耗了56%到69%的输出内容。每一个缺失的依赖，都是一笔重复缴纳的"智力税"。

**三、编译器的思路：把自然语言技能包当成代码来对待**

面对这三种失配问题，研究团队的灵感来自计算机发展史上的一个经典解决方案：编译器。

回顾计算机的演进历程，早期程序员要直接用机器能懂的汇编语言写代码，费时费力还容易出错。后来出现了C语言这样的高级编程语言，程序员用更接近人类思维的方式写代码，再由编译器自动翻译成机器能执行的指令。Java虚拟机（JVM）则更进一步，让同一份Java代码能在任何操作系统上运行，实现了"一次编写，到处运行"。

研究团队注意到，在AI智能体时代，技能包就是"代码"，而AI模型就是"处理器"。不同的AI模型就像不同的CPU架构，同样的指令在不同的处理器上执行效果完全不同。现有系统对技能包的处理方式，相当于直接把汇编代码扔给处理器，完全没有编译和优化这个环节。

于是，研究团队设计了SkVM——一个专门为技能包服务的编译和运行时系统。这个系统借鉴了传统编译技术中的两个核心概念：提前编译（AOT，即在使用之前就完成编译和优化）和即时编译（JIT，即在运行过程中动态优化）。

**四、提前编译：装好技能包就把活儿做到位**

SkVM的提前编译器在用户安装技能包时自动运行，它会针对当前的AI模型和执行框架，对技能包进行三轮优化处理。

第一轮处理叫"基于能力的编译"，专门解决模型失配问题。这一步的核心在于一套精心设计的"原始能力"体系。研究团队从1.5万多个技能包中提炼出26种"原始能力"，分属四大类别。每种原始能力还细分为不同的熟练程度等级，等级越高代表要求越复杂。

举个例子，"执行命令行工具"这个能力被分为三个等级：第一级是能执行基础命令（比如ls、cat这类简单指令）；第二级是能处理带参数和相对路径的命令；第三级是能写出用管道、重定向、循环连接起来的复杂命令链。编译器会用一系列小测试（类似于驾照考试的科目考核）来测量每个AI模型在每种能力上的等级，结果保存下来供所有技能包复用，不需要重复测量。

有了模型的能力档案，编译器就能找到技能包要求和模型实际水平之间的差距，然后选择相应的优化策略。差距较小时，编译器采用"补偿"策略：在技能包里添加更明确的说明、示例或约束，把任务难度降下来，填平这个差距，同时保留技能包的原始意图。差距太大、补偿无法解决时，编译器采用"替换"策略：换一条能达到相同目标但用不同能力实现的路径。比如技能包要求用Python的pandas库做数据分析，但模型Python能力不够，编译器可以改成用SQL来实现同样的数据分析，前提是模型的SQL能力足够。

以前面提到的PowerPoint生成技能包为例，编译器发现这个技能包需要"处理相对文件路径"这个能力，但目标模型只掌握了第一级，还不能处理相对路径。编译器考虑过把PptxGenJS替换成其他方案，但差距只有一级，补偿策略就够了。编译器直接在技能包里加入一条指令：把所有相对路径替换为技能包所在目录的绝对路径。问题解决，成本极低。

第二轮处理叫"环境绑定"，专门解决运行环境失配问题。编译器从技能包里提取出所有依赖项的清单——包括需要哪些第三方库、命令行工具和系统服务——然后检查当前机器上是否都已安装。对于缺失的依赖，编译器会生成一个"环境绑定脚本"，在每次执行技能包之前自动运行，确保所有工具都就位。这就把"边执行边装工具"变成了"先把工具准备好再开干"，AI模型不再需要花时间处理这些和核心任务无关的杂事。

第三轮处理叫"并发提取"，目标是挖掘技能包里隐藏的并行执行机会。研究发现，76%的技能包包含明确的步骤式流程，但这些步骤是按顺序写下来的，并不代表每个步骤都必须等前一个完成才能开始。就像做饭时，等水烧开的同时可以切菜，不必傻等着。

编译器会把技能包里的步骤分解成一张"依赖关系图"：哪个步骤需要哪个步骤的输出结果，哪些步骤互相独立。然后根据依赖关系图，提取出三种层级的并行机会。数据级并行是指同一个操作要对大量独立数据重复执行，比如对15个CSV文件分别做同样的分析，编译器会改写这个步骤，让它们同时进行。指令级并行是指多个独立的步骤可以同时发出工具调用请求，比如同时运行八个互不依赖的代码分析脚本，编译器会把这些请求打包成一次批量调用。线程级并行是指任务能分解成几个完全独立的子任务，每个子任务都需要多轮思考和操作，比如同时调试三个互相独立的系统服务，编译器会把每个子任务都标注成独立的"子智能体任务"，让执行框架并行启动多个智能体来处理。

**五、即时编译：在实战中越用越聪明**

提前编译只能解决安装时就能发现的问题，但有些问题只有在真正执行时才会暴露出来。SkVM的即时编译器负责处理这些运行时才出现的情况。

第一个机制叫"自适应重编译"。系统会追踪每一次任务执行的结果。当某个技能包在多次执行中反复出现失败或需要重试的情况时，系统会分析这些失败是偶然的任务特定问题，还是技能包本身存在系统性的能力缺口。只有确认是后者，才会触发重编译：把这些失败日志和模型自己尝试纠错的记录一起喂给编译器，让编译器找出根本原因并打上补丁。如果重编译后效果反而变差，系统会回滚到之前的版本，保证技能包的稳定性。每次重编译都从迄今为止表现最好的版本出发，确保优化方向是向前走的。

第二个机制叫"代码固化"，这是一个非常有意思的优化。研究团队发现，75%的技能包里都包含"结构固定、只有输入参数变化"的代码片段。比如PDF合并的代码，每次都是同样的框架，只有要合并哪几个文件这个参数会变。正常情况下，每次执行这段逻辑，AI模型都要重新"想一遍"——推理、决策、生成代码——这既耗时又浪费资源。

代码固化分三个阶段完成。提前编译阶段，编译器分析技能包里的代码片段，识别出哪些有固化潜力，为每个候选片段生成四样东西：关键词（用来判断当前任务是否和这段代码相关）、代码特征签名（描述这段代码应该长什么样）、带参数槽的代码模板，以及参数提取规则。运行阶段，系统监控AI模型实际生成的代码，检查是否和预测的特征签名匹配。只有在连续多次调用中都成功匹配之后，才会触发固化，确保这个代码结构确实是稳定可靠的。固化完成之后，后续调用完全绕开AI推理，系统直接从任务上下文中提取参数，套入模板，生成代码并执行，速度大幅提升。

有一个细节很重要：如果在监控阶段发现AI模型每次生成的代码结构不稳定、和预测的特征签名对不上，系统就永远不会触发固化，老老实实继续走AI推理的路子。这是一个安全阀，防止错误的固化损害任务结果。研究团队用一个天气查询技能包的案例验证了这个安全阀的有效性：处理当前天气的代码结构稳定，成功固化；处理天气预报的代码因为格式比较灵活，结构不稳定，系统正确地识别出来并放弃固化，所有八次调用都继续走AI推理路径。

此外，SkVM还有一个"资源感知调度器"，负责把编译时提取出的并行计划与运行时的实际资源状况结合起来。并行执行多个子任务听起来很美，但现实中API调用有速率限制，机器内存有上限，多个子任务同时跑可能反而互相阻塞。调度器会实时监控API响应延迟、HTTP 429错误（速率限制信号）、CPU和内存使用率。当压力超过阈值时，调度器会暂停启动新的子任务，或者选择性地把一部分正在运行的子任务挂起，减少竞争。每次执行结束后，调度器还会记录这次实际有效的并发度，作为下次执行的参考基准。

**六、实验结果：数字说话**

研究团队在八个不同能力等级的AI模型（横跨顶级、中级、小型三档）和三种不同的执行框架上做了全面测试，覆盖118个任务，每个任务产生5个不同输入实例。

在任务完成率上，SkVM优化后的技能包在所有模型和执行框架组合上都达到了最高得分。与原始技能包相比，SkVM平均提升任务完成率15.3%。能力较弱的模型受益最大，因为它们的能力和技能包要求之间的差距最大，优化空间也最大。SkVM优化后出现得分下降的任务比例只有4.5%，而原始技能包导致得分下降的比例是15%，减少了三分之二以上。

在不同执行框架之间的一致性上，使用原始技能包时，两个不同框架之间的得分差距最高达13分；SkVM优化后，这个差距缩小到最多5分，跨框架的表现更加稳定。

在与专业竞品的对比上，Anthropic公司有一个叫Skill-Creator的技能优化工具，同样使用顶级的Claude Opus 4.6模型来优化技能包。与这个工具相比，SkVM在较弱模型上的优势尤为明显：在BareAgent框架上，SkVM比Skill-Creator在Qwen3-30B模型上高出25分，在Devstral Small模型上高出10分。

在逐阶段的细分分析中，研究团队选取了14类技能、Qwen3-30B模型和BareAgent框架，记录了从"不用技能包"到"用原始技能包"到"AOT编译后"再到"三轮JIT优化后"的得分变化。结论是：14类任务中有11类，原始技能包的表现还不如不用技能包；AOT编译后，平均得分提升了88%；经过三轮JIT优化，14类中有10类达到满分。这个数字直观地展示了编译优化对任务完成率的巨大影响。

在执行效率上，代码固化的效果最为惊艳。对于PDF文本提取任务，原始执行时间是10,469到15,116毫秒；固化后降到206到568毫秒，实现了19到50倍的速度提升。并行化提取最高实现了3.2倍的端到端加速。在Token消耗上，对于最强模型加最弱框架的组合（DeepSeek V3.2加BareAgent），SkVM减少了接近40%的Token消耗。

在环境绑定的效果上，对比了"完整环境"、"缺失依赖"和"使用环境绑定"三种情况。缺失依赖时，Qwen模型的成功率跌到33%到67%，Token消耗翻2到4倍；使用环境绑定后，三个测试模型的表现全部恢复到完整环境水平。

在能力档案建立的成本上，对devstral-small模型做完整的26项原始能力测评需要7.3分钟，费用约0.033美元；对qwen3-30b需要31.1分钟，费用约0.079美元。这个一次性成本在后续大量技能包复用中会被快速摊薄。

**七、这套系统的边界与未来**

研究团队也坦诚地讨论了SkVM的局限性和开放性问题。

自然语言天然带有不确定性，技能包不是结构严格的源代码，编译过程会引入一定的非确定性。不过研究团队认为，AI模型本身对输入变化有一定的容忍度，加上SkVM的回滚机制，这种非确定性在实践中是可控的。

当前的26种原始能力覆盖了所分析的1.5万个技能包中95%的需求，但随着技能包生态继续扩张，可能会出现当前能力体系无法描述的新类型需求。研究团队已经设计好了扩展流程：当某种需求在语料库中出现频率超过1%时，才考虑新增一种原始能力，避免能力体系过度膨胀。

AOT编译需要调用AI模型来分析和改写技能包，会产生一定的Token费用。不过因为每个技能包只需要编译一次，编译结果可以在所有用户之间共享，平均到每次使用的边际成本极低。

Q&A

Q1：SkVM的"原始能力"体系是如何建立起来的？

A：研究团队从1.5万多个技能包中先手工挑选50个有代表性的样本，用AI辅助分析提炼出19种初始原始能力，再由研究人员逐一验证这些能力是否满足"可组合性、通用性、语义独立性"三条原则。然后用这19种能力去覆盖全部1.5万个技能包，凡是覆盖不了的情况，如果出现频率超过1%就补充新能力。这个过程最终收敛到26种原始能力，能覆盖95%技能包的需求。能力还被细分为不同熟练等级，并通过微基准测试在实际模型上验证等级划分是否合理。

Q2：代码固化失败了怎么办？

A：SkVM设计了两层保护机制。第一层是"促进门"：在连续多次调用中，如果AI模型生成的代码结构和预测的特征签名匹配不稳定，系统就永远不触发固化，继续走AI推理路径，天气预报任务就是这种情况的真实案例。第二层是运行时回退：即使固化已经触发，如果固化后的代码在某次执行中导致任务失败或抛出异常，SkVM会立刻重新启用AI推理来完成这次任务，保证正确性不受损失。

Q3：SkVM对顶级AI模型有用吗，还是只对弱模型有价值？

A：对强弱模型都有价值，但收益侧重不同。对能力较弱的模型，SkVM主要带来任务完成率的显著提升，因为弱模型和技能包要求之间的差距更大，优化空间更多。对顶级模型，任务完成率本来已经很高，SkVM主要贡献在于减少Token消耗和提升执行速度——最强的DeepSeek V3.2模型在最简单的框架上，Token节省接近40%，这对于大规模使用来说是相当可观的成本节约。