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 应该如何被系统管理」的好起点。