SkVM 深度解析：为 LLM Agent Skills 构建的编译与运行时系统

SkVM 深度解析为 LLM Agent Skills 构建的编译与运行时系统一、背景与问题在 LLM Agent 工程实践中有一个长期被忽视但极其棘手的问题Skill 的可移植性。一个在 Claude Sonnet 4.6 上运行流畅的 Agent Skill换到 Qwen3-35B 上可能错误百出一套针对 OpenClaw 写好的指令集迁移到 Hermes Agent 后往往需要大量手工调整。这背后的根因是不同的 LLM 在代码生成、推理、工具调用、指令遵从等维度上能力参差不齐不同的 Agent 框架在工具集、沙箱环境、交互协议上也各自为政。这个问题的本质和传统计算机体系结构中的ISA指令集架构移植性问题高度同构高级语言Skill 指令需要编译到具体硬件LLM Harness不同的目标平台能力不同需要针对性的代码生成运行时需要 JIT 优化来弥补静态分析的不足SkVMSkill Virtual Machine正是从这个类比出发构建了一套完整的 LLM Skill 编译与运行时系统。二、核心原理语言 VM 的类比SkVM 的核心设计哲学是将LLM Agent Harness 的组合类比为计算机体系结构中的”硬件平台”将 **Agent Skill一组 Markdown 指令 配套脚本**类比为”高级语言程序”。传统编译体系 SkVM 类比 ───────────────────────────────────────────────────── 高级语言代码 SkillSKILL.md 脚本 目标硬件平台 LLM 模型 Agent Harness ISA / ABI Primitive 能力目录26 个原语 编译器 AOT Compiler3 pass 性能分析 ProfilerTCP 生成 JIT 编译器 JIT-Boost JIT-Optimize这个类比不是噱头而是整个系统设计的骨架——每个子系统的存在都有其在传统 VM 体系中的对应角色。三、系统架构3.1 整体数据流Profile Tool ──TCP── AOT Compiler ──Variant── Runtime Agent │ │ │ 26 primitives 3 passes JIT-boost JIT-optimize L1 → L2 → L3 1: capability gaps - code solidification 2: env binding - skill content improvement 3: concurrency DAG - headless optimizer loop整个系统分为三个相互独立、可单独使用的层1.Profile 层测量目标 LLM Harness 的能力生成 TCPTarget Capability Profile2.Compile 层基于 TCP 编译 Skill生成针对目标平台优化的 Variant3.Optimize 层运行时 JIT 优化包括代码固化Boost和内容改进Optimize3.2 代码结构src/ ├── index.ts # CLI 入口手写 flag 解析器 ├── core/ # 共享基础类型、配置、日志、并发、headless agent ├── providers/ # LLM 后端Anthropic SDK、OpenRouter ├── adapters/ # 5 种 Agent Harness 适配器 ├── profiler/ # 26 个微基准测试生成器 运行器 ├── compiler/ # 3-pass AOT 编译器 ├── runtime/ # RuntimeHooks 接口定义 ├── jit-boost/ # 运行时代码固化 ├── jit-optimize/ # 基于 Proposal 的 Skill 内容优化循环 ├── proposals/ # Proposal 存储与部署管理 ├── framework/ # 任务运行器 评估引擎profiler 和 bench 共用 └── bench/ # 基准测试编排器四、核心模块深度解析4.1 Profiler建立能力基线Profiler 是整个系统的”侦察兵”。它的核心工作是用 26 个预定义的微基准测试测量目标 LLM Harness 组合在各原语上的能力等级最终生成 TCPTarget Capability Profile。26 个 Primitive 原语目录这 26 个原语按照 4 个大类组织大类原语示例说明Generation生成gen.code.python,gen.code.bash,gen.text.summary代码生成、文本生成能力Reasoning推理reason.logic,reason.math,reason.plan逻辑推理、数学计算、规划能力Tool Use工具调用tool.file.read,tool.file.write,tool.shell.exec文件操作、命令执行Instruction Following指令遵从follow.format,follow.constraint,follow.multi-step格式遵从、约束遵从、多步指令每个原语有 3 个能力等级L1/L2/L3对应从简单到复杂的任务难度。两种评估模式-工具调用型原语gen.code.*、tool.*Agent 实际运行工具评估脚本检查workDir中的文件结果-纯文本型原语reason.*、follow.*、gen.text.*Profiler 把 LLM 响应写入response.txt脚本读取并评分评估脚本统一使用python3 PYEOFheredoc 模式规避 shell 引号转义问题。TCP 输出格式{model:anthropic/claude-sonnet-4-6,adapter:bare-agent,primitives:{gen.code.python:L3,reason.math:L2,tool.file.write:L3,follow.constraint:L1}}关键设计决策TCP 是模型harness 组合的属性不是模型单独的属性。同一个模型在 bare-agent 下和在 OpenClaw 下的 TCP 可能不同因为工具集和交互协议不同。4.2 AOT Compiler三遍静态编译编译器是 SkVM 的核心它将一个通用 Skill 重写为针对特定目标平台优化的 Variant。编译过程分为三遍每遍都有明确的职责边界。Pass 1能力缺口弥补输入原始 Skill TCP核心步骤1.SCR 提取LLM 调用从 Skill 中提取 Skill Capability Requirements即这个 Skill 假设目标模型具备哪些能力2.缺口分析纯计算对比 SCR 和 TCP找出 “Skill 需要 L2 但模型只有 L1” 的原语3.Agentic 重写LLM 调用让compiler-agent.ts分析每个缺口决定重写策略——是降级任务复杂度、拆分步骤、还是添加更详细的示例Pass 1 中只有 SCR 提取和重写两步调用 LLM缺口分析是纯计算这是有意为之的设计——缺口分析频繁、确定性强不适合用 LLM。Pass 2环境绑定职责处理 Skill 的外部依赖。步骤LLM 从 Skill 中提取依赖清单dependency manifestShell 脚本检查这些依赖在目标环境中是否存在生成幂等的env-setup.sh确保 Skill 运行前环境就绪这一遍解决的是”Skill 假设git已安装但实际没有”这类环境不匹配问题。Pass 3并发 DAG 提取职责从 Skill 的工作流中提取可并行执行的任务图。步骤LLM 进行工作流分解识别步骤间的依赖关系纯计算构建 DAG有向无环图提取三类并行性-DLPData-Level Parallelism同一操作作用于多个数据项-ILPInstruction-Level Parallelism独立指令同时执行-TLPTask-Level Parallelism独立子任务并行运行最新版本PR #5还对 ILP 工具分发做了并行化进一步提升编译效率。编译产物位置~/.skvm/proposals/aot-compile/{adapter}/{safeModel}/{skillName}/{passTag}/每个 pass 的产物独立存储支持增量重编译。4.3 JIT-Boost运行时代码固化JIT-Boost 解决的是运行时效率问题当 Agent 在执行 Skill 时反复产生相同模式的工具调用完全可以用确定性代码替代 LLM 推理节省 token 和延迟。工作原理候选生成candidates.tsheadless agent 分析完整 Skill 目录识别可能被固化的模式输出boost-candidates.json{candidates:[{keywords:[list files,directory contents],codeSignature:list_directory({path}),functionTemplate:ls -la {path},params:[path]}]}运行时监控与提升solidifier.ts-afterLLMhook监控每次 LLM 工具调用与代码签名匹配统计连续命中次数-beforeLLMhook当连续命中达到阈值默认 3 次直接从 prompt 中提取参数、执行模板完全绕过 LLM失败时回退到 LLM连续失败 M 次默认 3 次后降级该候选这是一个经典的自适应优化策略观察 → 统计 → 提升 → 验证 → 回退。┌─────────────────────────────┐ beforeLLM ────── │ 命中阈值 │ │ 是 → 执行模板跳过 LLM │ │ 否 → 正常走 LLM │ └─────────────────────────────┘ afterLLM ────── 更新命中计数管理候选状态4.4 JIT-Optimize基于证据的 Skill 内容改进JIT-Optimize 是系统中最复杂、最有创意的子系统。它的目标是基于真实执行证据自动改进 Skill 的内容本身。三个正交轴维度选项任务来源synthetic-taskLLM 从 Skill 自动推导/real-task真实 bench 任务/execution-log解析已有对话日志无需重跑循环控制rounds 轮数、runsPerTask 每任务跑数、convergence 收敛条件、holdoutTestSet 保留测试集、baseline 基线交付方式统一为 ProposalkeepAllRounds控制剪枝autoApply控制是否自动覆盖原始 SkillOptimizer 运行协议这是整个系统中最精妙的设计之一Optimizer 本身是一个 Headless Agent。1. Engine 将 Skill 目录复制到临时工作区 2. 将执行证据 历史记录序列化到 .optimize/ 目录JSON Markdown 3. 启动 Headless Agent默认驱动opencodecwd 指向工作区 4. Agent 使用自身工具read/edit/write/glob/grep/bash编辑 Skill 文件 5. Agent 将结果写入 .optimize/submission.json { rootCause: ..., // 必填诊断出的根本原因 reasoning: ..., confidence: 0.85, changedFiles: [SKILL.md], changes: {...} } 6. Engine 对工作区做快照计算实际 diff验证 changedFiles 声明关键约束rootCause字段是强制要求的。Optimizer 必须阐明诊断出的根本问题而不仅仅描述它做了什么改动。历史记录中保留每轮的 rootCause避免后续轮次重复同样的失败诊断。Proposal 树结构~/.skvm/proposals/jit-optimize/{harness}/{safeTargetModel}/{skillName}/{timestamp}/ original/ # 起始 Skill 快照 round-0/ # 基线与 original 相同保持轮次枚举统一 round-1/ … round-N/ # 每轮优化后的完整 Skill 目录 history.json # HistoryEntry[] bestRound bestRoundReason analysis.md # 人类可读摘要 meta.json # { status, acceptedRound, bestRound, optimizerModel, … } round-N-agent-logs/ # Agent 对话日志 round-N-optimizer-logs/ # Optimizer NDJSON每个 round 目录都是完整、可用的 Skill 目录做到了”每轮可独立部署”。4.5 Adapters统一 Agent Harness 接口SkVM 通过AgentAdapter接口屏蔽了不同 Agent 框架的差异目前支持 5 种适配器适配器特点bare-agent内置最小化循环5 个基础工具read_file/write_file/list_directory/execute_command/web_fetch是 profile/test 的主力适配器opencode包装 OpenCode CLI解析 NDJSON 事件流openclaw包装 OpenClaw CLI管理临时 agent 实例hermes包装 hermes CLI解析 session export JSON支持完整的 token/cost 统计jiuwenclaw通过 JSON-RPC 调用jiuwenclaw-clitoken/cost 不在上游持久化每个适配器都支持RuntimeHooksbeforeLLM/afterLLM/afterTool/afterRunJIT-Boost 正是通过这些 hook 注入到任意适配器中。两种配置模式-managedSkVM 在沙箱内配置一个全新的 harness 实例干净基线无主机状态依赖-native克隆用户本机已有的 harness 配置需要本地已安装该 harness4.6 并发调度器层级式槽位管理src/core/concurrency.ts实现了一个定制化的层级调度器用于profile和bench的大规模并发任务分配。核心概念-Pool并发槽位池支持跨组的槽位”偷取”slot stealing-runScheduled按调度策略分发任务支持”组内”和”跨组”两种槽位分配-distributeSlots层级化地向 adapter × model × task 三维矩阵分配并发配额这个调度器使得在大规模基准测试中空闲的工作单元可以自动”偷取”其他组的任务最大化硬件利用率。4.7 评估框架四种评分策略src/framework/evaluator.ts定义了四种固定的顶层评估方法方法适用场景scriptShell 退出码0通过非0失败file-check检查文件内容精确匹配/包含/正则/JSON schemallm-judgeLLM 作为评委打分 0-1适合主观质量评估custom注册自定义评估器grade.py等通过evaluatorId分发llm-judge支持--async-judge模式在 bench 跑完之后批量异步评分不阻塞主流程。五、关键技术选型5.1 Bun 运行时SkVM 选择 Bun 而非 Node.js原因包括内置 TypeScript 支持无需编译步骤-Bun.file()/Bun.write()比node:fs更符合人体工学自动加载.env文件更快的启动速度CLI 工具中体验明显5.2 Zod 模式验证所有跨子系统的 JSON 产物TCP、SCR、Proposal、日志都用 Zod schema 定义并验证。类型定义和 schema 定义放在同一文件types.ts保证类型系统和运行时验证的一致性。5.3 双层结构化输出策略providers/structured.ts中的extractStructured()采用两层降级策略1.优先使用tool_use结构化工具调用Anthropic SDK 原生支持2.降级如果模型不支持 tool_use则 prompt parse提示 JSON 格式然后解析响应这使得 SkVM 在 OpenRouter 上的弱模型上也能稳定运行。5.4provider/前缀路由所有模型 ID 必须携带provider/前缀-anthropic/claude-sonnet-4-6→ Anthropic 原生 SDK-openrouter/qwen/qwen3.5-35b-a3b→ OpenRouter三段式-openai/gpt-4o→ OpenAI 兼容接口这个设计使 provider 路由完全显式避免了隐式猜测引发的错误也让多 provider 混用变得自然。六、典型业务流程流程 A从零到可运行的优化 Skill# Step 1配置向导一次性 skvmconfiginit # Step 2Profile 目标模型约 20 分钟--concurrency 可加速 skvmprofile--adapteropenclaw--modelanthropic/claude-haiku-4-5-20251001 # Step 3AOT 编译 Skill3 个 pass 顺序执行 skvmaot-compile\ --skillpath/to/my-skill \ --modelanthropic/claude-haiku-4-5-20251001\ --adapteropenclaw \ --pass1,2,3\ --compiler-modelanthropic/claude-sonnet-4-6 # Step 4用 JIT-Optimize 自动调优合成任务模式 skvmjit-optimize\ --skillpath/to/my-skill \ --task-sourcesynthetic\ --target-modelanthropic/claude-haiku-4-5-20251001 \ --optimizer-modelanthropic/claude-sonnet-4-6\ --target-adapteropenclaw \ --rounds3 # Step 5Review 并接受最佳 Proposal skvmproposalsserve # Web UI skvmproposalsaccept id流程 B从事后日志优化Post-Mortem# 任务运行完成后用已有对话日志做分析 skvmjit-optimize\ --skillpath/to/my-skill \ --task-sourcelog\ --logs~/.openclaw/sessions/session-xyz.jsonl \ --target-modelanthropic/claude-haiku-4-5-20251001\ --optimizer-modelanthropic/claude-sonnet-4-6 \ --target-adapteropenclaw流程 C基准测试对比# 对比原始、编译后、JIT 优化后三个版本的性能 skvmbench\ --skillmy-skill \ --modelanthropic/claude-haiku-4-5-20251001\ --adapteropenclaw \ --conditionsoriginal,aot-compiled,jit-optimized\ --tasksall七、使用案例案例 1跨模型部署能力降级场景一个复杂的代码审查 Skill依赖模型具备 L3 的reason.logic能力深度逻辑推理。但目标部署模型一个成本更低的开源模型在该原语上只有 L1。SkVM 解法Profiler 检测到缺口Pass 1 编译器将 Skill 改写将”一步完成的复杂推理”拆分为”多步引导式推理链”并增加 CoTChain-of-Thought提示编译后的 Variant 在弱模型上的通过率显著提升案例 2跨 Harness 迁移场景原本为 OpenClaw 写的 Skill 需要迁移到 Hermes Agent两者工具集和指令风格不同。SkVM 解法Pass 2 编译器重新绑定环境依赖处理工具调用 API 差异Adapters 层屏蔽 Harness 差异同一 Skill 可以用不同 adapter 运行案例 3JIT-Boost 加速重复操作场景一个文件分析 Skill 在处理每个文件前都会调用list_directory每次都产生 LLM 推理开销。SkVM 解法JIT-Boost 检测到list_directory调用连续出现 3 次自动将后续调用固化为直接的 shell 命令执行跳过 LLM节省 token 和延迟案例 4数据集规模验证SkVM 附带的skvm-data包含-108 个Skill 目录-216 个任务目录预建的多模型 TCP profile可以直接基于这些数据运行系统级基准测试。八、体会与思考8.1 “把 LLM 视为硬件”是个深刻的类比传统软件工程中抽象硬件差异是整个计算机体系结构的核心任务。SkVM 把这个思路搬到 LLM Agent 领域不是简单的比喻而是真正落地的工程实践。26 个 Primitive 原语目录的设计尤其值得称赞。它将 LLM 能力从”模糊的感知”变成了”可量化的测量”。以前我们说”这个模型推理能力弱”现在可以说”这个模型在reason.logic上是 L1”精确、可重现、可比较。8.2 Agentic Compiler 的范式转移传统编译器是确定性的符号变换。SkVM 的 Pass 1/2/3 编译器核心步骤都调用 LLM这意味着编译过程本身是非确定性的。这带来了一个有趣的工程问题如何保证编译质量SkVM 的答案是-guard.ts对每个 pass 的输出做 Zod 验证每个 pass 的产物独立存储失败可以单独重跑JIT-Optimize 通过运行时证据弥补编译不足这是”编译时尽力、运行时修正”的务实工程哲学。8.3 Headless Agent 作为基础设施SkVM 在多个关键节点JIT-Boost 候选生成、JIT-Optimize Optimizer都使用 Headless Agent 来执行复杂分析和编辑任务。这个选择背后有深刻的工程考量文件编辑、代码分析、多文件协调——这些任务本来就是 Agent 擅长的。与其自己写一个复杂的文件操作库不如用一个已经会这些的 Agent。但这也意味着 Optimizer 本身的质量依赖于底层 Agent Driver 的质量。SkVM 通过OptimizeConfig.driver将 Driver 抽象化支持插件化替换bare-agent/opencode/claude-code这是正确的解耦方向。8.4 rootCause 的强制要求是工程智慧在 JIT-Optimize 的submission.json中rootCause字段是强制的。这个约束看起来很小但背后的工程智慧不小没有 rootCause 的修改是”打补丁”有 rootCause 的修改是”治根本”。在多轮优化中历史 rootCause 记录让 Optimizer 在后续轮次可以明确避免”已经试过但没用的方向”防止无效循环。这是从大量 Agent 工程实践中提炼出来的约束。8.5 可移植性 vs 最优性的权衡SkVM 的目标是可移植性但这和在特定平台上的最优性存在天然张力。一个为 Claude Sonnet 原生优化的 Skill未必比经过 SkVM 编译的通用 Skill 更差——但在极端情况下比如需要非常特定的提示风格SkVM 的通用化改写可能会牺牲一定性能。这是所有”中间层”系统都面临的根本权衡。SkVM 的应对策略是提供 JIT-Optimize 做运行时弥补保留每轮产物让用户可以选择接受哪一轮提供完整的基准测试系统让数据说话8.6 从论文到工程的落地SkVM 背后有 arXiv 论文 支撑但代码库本身的工程质量独立于论文评价。几个值得学习的工程点-TypeScript Bunno build step降低贡献门槛减少工程摩擦-Zod schema 作为系统边界所有跨模块数据结构强制验证减少运行时惊喜-src/adapters/registry.ts单一注册点新增 Adapter 只需在一个文件中注册避免分散修改-Cache root 全局共享可覆盖~/.skvm/在所有目录下共享同时支持SKVM_CACHE覆盖兼顾便利性和灵活性九、总结SkVM 是一个在 LLM Agent 工程领域思路非常新颖的系统。它把传统计算机体系结构中”编译 → 运行时优化”的完整体系移植到了 Skill 的生命周期管理上每个子系统都有清晰的职责和良好的解耦。对于 Agent 工程师SkVM 提供了一套系统化解决”Skill 可移植性”问题的工具链从量化能力Profiler到自动适配Compiler再到持续改进JIT-Optimize覆盖了 Skill 全生命周期。对于系统设计者SkVM 展示了如何将传统系统软件的设计范式——能力抽象、静态分析、动态优化、中间表示——迁移到以 LLM 为核心的新型计算范式中。未来最值得期待的方向或许是 Skill 之间的依赖管理和版本化——类似包管理器当一个 Skill 依赖另一个 Skill 的输出时SkVM 能否自动管理这些组合的兼容性这将是让 SkVM 从工具变成生态的关键一步。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】​