Skills Are the New Apps — 论 Skill OS 的必然崛起
Skills Are the New Apps – Now It's Time for Skill OS
上海交大研究团队通过分析近 10 万条真实 Skill 数据，提出 Skill 已成为 LLM Agent 时代的新型「应用」，并由此引出一个新的系统抽象：Skill OS——一个将 Skill 作为一等执行实体进行管理的操作系统层。
一句话总结
Skills 已不再只是 Prompt 的衍生品，而是 LLM Agent 时代真正的「应用」——而现有系统尚未为此做好准备。
论文信息
- 机构：上海交通大学
- 发表时间：2026 年 2 月 13 日（预印本）
- 关键词：LLM Agents、Operating System、Skill
背景与动机
在 Cursor、Claude Code、Coze 等主流 LLM Agent 平台上，Skill（技能） 的使用量正呈爆炸式增长。Skill 最初只是为了节省 Prompt 上下文长度而引入的「按需加载提示词」，但论文作者认为，Skill 与普通 Prompt 之间已经出现了本质性的分化：
| 维度 | 普通 Prompt | Skill |
|---|---|---|
| 复用性 | 一次性使用 | 隐含反复调用 |
| 确定性 | 语义模糊 | 场景具体、可验证 |
| 环境依赖 | 无特定要求 | 依赖特定运行时环境 |
这三点差异，使 Skill 具备了成为系统级一等公民的条件——正如程序之于操作系统。
核心数据分析：近 10 万条真实 Skill 的画像
研究团队从公开仓库收集了 97,754 条 Skill 数据，并从结构、执行模式和系统需求三个维度进行了系统分析，得出了 6 个关键洞察：
Insight 1：超过 50% 的 Skill 是「过程式」的
Skill 往往不只是简单的一段描述，而是一个包含明确步骤、条件分支和迭代循环的执行过程（Procedure）。研究通过启发式规则与本地语言模型相结合的方法对 Skill 进行分类，发现 50% 以上的 Skill 都具有高置信度的过程式结构。
这意味着 Skill 的执行逻辑已经接近「程序」——有控制流、有步骤边界、有中间状态。
Insight 2：约 70% 的 Skill 包含「半确定性代码块」
Skill 中常常嵌入代码片段、模板或脚本（论文称之为 semi-deterministic blocks）。这些内容大多是固定的，却在每次执行时都被完整加载进上下文。这会造成大量 token 浪费——相当于每次运行程序时，都要重新编译所有不会变化的代码。
Insight 3：语义等价的 Skill 在操作细节上可能不同
即便处理的是完全相同的任务，LLM 生成的执行序列也可能在步骤顺序、参数化方式等方面存在细微差异。这使得「精确匹配式复用」几乎不可行，必须引入语义层面的缓存与复用机制。
Insight 4：Skill 的关键约束缺乏强保证
Skill 往往通过自然语言来描述运行前提（如「并行任务之间不能相互干扰」「操作需幂等」），但这些约束的落实完全依赖模型的内部推理，并没有系统级的强制保证。其安全风险是切实存在的。
Insight 5：环境依赖缺失导致大量额外 token 消耗
约 45% 的 Skill 依赖 Shell 命令，31% 依赖 OS 接口，另有相当一部分依赖数据库和网络 API。当这些依赖缺失时，平均会产生数万到数十万个额外 token 的诊断开销——而这本是可以在系统层面提前解决的问题。
Insight 6：跨会话共享的 Skill 缺乏全局管理
同一个 Skill（如「代码测试流程」）可能会在不同任务、不同时间段被反复调用，但当前 Agent 系统通常只能感知当前任务的上下文，无法进行跨会话的全局优化与管理。
核心提案：Skill OS
基于上述洞察，论文提出了 Skill OS 的五大核心能力：
1. 局部性利用（Skill Locality）
通过语义缓存，Skill OS 可以识别并存储 Skill 执行轨迹中语义稳定的部分（如半确定性代码块、已解析的工具调用序列和中间结果），以便在后续调用中直接复用，而不是重新生成。
可以类比为 CPU 缓存或操作系统的页面缓存。
2. 执行环境构建（Execution Environment Construction）
Skill OS 应当在 Skill 执行前主动识别并预装所需依赖，将依赖解析从「运行时模型推理」提升为「系统级提前准备」，从而彻底消除因依赖缺失而导致的大量额外 token 消耗。
3. 全局 Skill 管理（Global Skill Management）
由于 Skill OS 运行在高于任何单个 Agent 的特权层，因此它具备系统级视角，能够：
- 追踪所有 Skill 的使用模式
- 识别可跨任务共享的无状态 Skill
- 隔离需要独立环境的 Skill
- 对多 Agent 并发访问进行调度与去重
4. 结构化故障处理（Structured Failure Handling）
借鉴操作系统的异常处理机制（即内核拦截硬件异常 → 分类 → 恢复），Skill OS 应当：
- 在系统层拦截并分类工具调用失败、API 错误
- 在步骤边界维护逻辑检查点，支持回滚至最近安全点
- 避免整个 Skill 从头重跑
5. 运行时安全（Runtime Security）
当前 Skill 的权限控制完全依赖 Prompt 文本描述与模型推理，本质上仍是一种「口头约束」。Skill OS 应当构建策略引擎，实现：
- 基于 Skill/Agent/Session 粒度的细粒度访问控制
- 在工具调用发生前进行权限校验（而非事后）
- 最小权限原则：Skill 只能获取其声明所需的资源
- 完整的操作审计日志
更宏观的视角：OS 与 App 边界的历史演进
论文给出了一个精彩的历史类比：
- 传统 PC 时代：应用程序包揽一切，OS 只提供基础服务
- 移动互联网时代（Android）：平台变厚，应用变薄——存储、网络和认证能力都下沉到系统层
- Serverless 时代：应用进一步简化为无状态函数，平台接管弹性伸缩与容错
- LLM Agent 时代（Skill OS）：Skill 成为「意图的薄规约」，OS 负责执行、缓存、并发和恢复
OS 越来越厚，App 越来越薄。 Skill OS 是这条历史曲线在 AI 系统时代的自然延伸。
我的思考
这篇论文本身的观察是有说服力的——近 10 万条数据支撑的实证分析表明，Skill 体系中存在的系统性问题是真实的、可测量的。
但在读完之后，我有几个想法值得记录：
Skill OS 与 Agent Framework 的边界在哪里？ 论文区分了「格式层」（如 Agent Skills 规范、SKILL.md）、「检索编排层」（如 AgentSkillOS）和「执行层」（Skill OS），这一分层是清晰的。但实际上，LangGraph、AutoGen 这类框架已经在处理其中许多问题——缓存、错误处理、并发控制都有所涉及。Skill OS 究竟需要成为一个独立系统，还是更适合作为这些框架的一组最佳实践集合？
安全问题的复杂性被低估了。 论文提出的「策略引擎」听起来很直接，但真正的挑战在于：如何形式化 Skill 的意图与实际工具调用之间的映射？自然语言的语义天然是模糊的，把安全策略建立在 Prompt 解析之上，本质上仍没有摆脱对模型推理的依赖。
「语义等价」的判断是个未解问题。 Insight 3 指出，同一任务的执行序列可能因模型随机性而不同，因此 Skill OS 需要语义级匹配来复用缓存。但如何定义并计算两个执行序列的「语义等价」？这本身就是一个开放性的研究问题，论文并未给出具体答案。
总结
这是一篇观点鲜明、数据扎实的 Vision 论文。它的价值在于提出了一个值得认真对待的系统抽象，并用实证数据说明了为什么「把 Skill 当作 Prompt 来处理」是不够的。Skill OS 的完整实现仍有许多技术问题有待解决，但作为一个研究议程的框架，它已经足够清晰，也相当有说服力。
如果你正在开发或使用 LLM Agent 工具链，这篇论文为思考「Skill 应当如何被系统化管理」提供了一个很好的起点。