Skill OS论文学习：为什么Skill会成为Agent时代的新App

这篇文章基于 AgenticOS 2026 论文《Skills are the new Apps – Now It’s Time for Skill OS》整理，重点想讲清楚：为什么 Skill 不再只是提示词片段，而正在演化成 Agent 时代的新型应用单元。

写在前面

---

• 博文内容为 AgenticOS 2026 论文 Skills are the new Apps – Now It’s Time for Skill OS 的学习笔记
• 论文地址：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_13.pdf
• 这篇论文带有很强的“系统视角”，不是在教你怎么写 skill，而是在讨论 skill 爆炸增长后，底层系统应该怎么变
• 理解不足小伙伴帮忙指正 :),生活加油

我看远山，远山悲悯

持续分享技术干货，感兴趣小伙伴可以关注下 ^_^

---

一句话先说结论

这篇论文最核心的观点是：

Skill 已经不只是“为了省 token 而拆出来的提示模板”，它正在变成一种可复用、可调度、可治理、带环境依赖和安全边界的新型执行单元，因此需要一个类似 OS 的系统层把它作为一等公民来管理。

论文甚至直接把标题写成了：

• Skills are the new Apps
• Now It's Time for Skill OS

这句话非常激进，但我觉得很有道理。

名词解释

• Skill：可复用的任务能力包，通常包含说明、步骤、脚本和资源文件
• Skill OS：把 skill 当成一等执行单元来统一管理的系统层抽象
• prompt-centric：以提示词加载为中心的执行方式，系统主要负责把文本送给模型
• procedure：具备明确步骤和阶段边界的过程描述
• semi-deterministic blocks：skill 中大概率重复出现、相对稳定的步骤或片段
• semantic equivalence：语义目标相同，但不代表执行轨迹完全相同
• execution drift：语义看起来一致，执行细节却逐渐偏离的现象
• locality-aware caching：利用重复结构和稳定块做缓存，而不是每次从零解释
• dynamic environment construction：在 skill 执行前动态拼出合适依赖环境的能力
• global skill management：跨任务、跨会话统一管理 skill、缓存和共享资源的系统能力
• fault management：对失败进行分类、恢复、回滚和审计的系统能力
• MCP：Model Context Protocol，一类把外部工具和上下文接入模型的协议接口

论文到底在研究什么

现在主流 Agent 平台里，skill 已经非常常见了，比如：

• Claude Code
• Cursor
• OpenAI Codex
• Gemini

它们都支持某种形式的 skill 包。

一个 skill 通常包含三部分：

• 元数据
• 指令正文
• 捆绑资源，例如脚本、模板、参考文档、资产文件

论文指出，现在的 skill 运行模式本质还是 prompt-centric：

1. 系统启动时扫描 skill 目录
2. 根据用户请求选出相关 skill
3. 把 skill 指令加载进上下文
4. 模型再解释这些步骤并调用工具执行

这种方式的优点是简单，但随着 skill 数量和复杂度上升，问题开始暴露。

论文做了什么实证工作

论文不是纯观点输出，而是先分析了 接近 100,000 个公开 skill。

作者的目标不是统计热度，而是回答一个系统问题：

• skill 到底具备什么共性
• 这些共性是否足以支撑一层新的系统抽象

他们最后总结出 六个关键性质。

Skill 的六个关键性质

1. 很多 skill 本质上是 procedure

论文发现，超过 50% 的 skill 可以被 reasonably 看成 procedure，也就是明确分步骤的过程描述。

这很重要，因为它说明 skill 并不是一团自由文本，而更像：

• 有阶段边界
• 有步骤序列
• 有条件分支
• 有循环结构

一旦有了这些结构，系统就可以在这些边界上做：

• checkpoint
• 缓存
• 失败恢复
• 并行调度

2. 很多 skill 包含 semi-deterministic blocks

论文发现，大约 70% 的 skill 里都包含这种“半确定性块”。

比如：

• 大段固定模板
• 重复出现的代码片段
• 相对稳定的工具调用序列

这些内容每次执行都被完整塞进上下文，但其实大部分 token 是不变的。

这意味着当前系统没有充分利用 skill 的 locality。

3. 语义等价，不代表执行等价

即使两次 skill 调用在语义目标上相同，模型生成的步骤顺序、参数、工具调用细节仍可能不同。

论文把这件事称为 execution drift under semantic equivalence。

这点非常现实：

• 语义上看起来一样
• 操作上却可能细节不同
• 所以不能简单做精确匹配缓存

4. 很多 skill 带有关键要求，但没有强约束

论文专门举了一个并行 skill 的例子：它要求子任务彼此不要互相干扰。

问题是现在这些要求通常只写在自然语言里，例如：

• 不要并发处理互相关联的问题
• 避免共享状态冲突
• 要求幂等

但系统层并没有真正 enforce。

也就是说，当前很多安全约束只是“提示词里的希望”，不是“运行时里的保证”。

5. skill 往往依赖外部执行环境

论文指出，大约：

• 45% 的 skill 依赖 shell utilities，例如 grep
• 31% 会调用 OS API，例如 read、exec

还有一些依赖：

• 数据库命令
• 网络接口
• MCP 服务
• 特定版本工具链

更关键的是，作者发现如果缺少正确依赖，模型往往会进入高 token 消耗的试错修复过程。

论文里有一组特别直观的数据：

• 某些 skill 在依赖不正确时，会额外消耗几十万 token
• 图里甚至出现了 331.3k 级别的 token 开销

6. skill 会跨会话共享，但模型无法全局管理

有些 skill 不是一次性使用，而是会在多个任务、多个会话里重复出现。

论文认为，现在模型只看到当前对话上下文，缺乏系统级视角，所以无法：

• 发现哪些 skill 可跨任务复用
• 统一管理共享资源
• 做全局缓存
• 做系统级审计和治理

为什么作者认为需要 Skill OS

论文的逻辑其实很清晰：

只要你承认上面六个性质成立，就会很自然得出一个结论：

skill 不是纯 prompt，它已经具有结构、执行语义、依赖关系、安全要求和跨会话复用特征，所以它应该被系统层接管一部分职责。

作者提出的 Skill OS 不是具体产品，而是一种系统抽象，重点覆盖五类需求。

Skill OS 应该做什么

1. locality-aware caching

既然很多 skill 有稳定块，就不应该每次都从零解释、从零执行。

Skill OS 应该缓存：

• 稳定的指令片段
• 已解析的工具调用序列
• 中间产物
• 可复用的执行痕迹

但缓存又不能只做字符串级别，因为语义等价的流程可能会有表面差异。

2. dynamic environment construction

Skill OS 应该在 skill 执行前动态构造合适运行环境，而不是把依赖解析任务全丢给模型临场补救。

也就是说，系统要同时看两侧信息：

• skill 需要什么
• 当前机器实际上有什么

把这两边对齐之后，再决定具体绑定到哪个环境。

3. global skill management

论文强调，Skill OS 应该拥有跨任务、跨会话的全局视角。

这意味着它可以：

• 知道哪些 skill 经常复用
• 决定哪些缓存可以共享
• 决定哪些资源必须隔离
• 避免多个 agent 并发时互相踩状态

4. system-level fault management

当前很多 tool failure 在模型看来只是一段错误字符串，模型得自己猜。

论文希望 Skill OS 像操作系统处理异常一样，对常见故障进行：

• 分类
• 拦截
• 决定恢复策略
• 在步骤边界做回滚或恢复

这样可以避免每次都从头重跑整个 skill。

5. security, access control, auditing

这部分我觉得特别重要。

现在很多 skill 的安全要求写在文本里，但没有真正变成系统级策略。

Skill OS 应该把这些要求提升为运行时约束，例如：

• 权限控制
• 工具访问边界
• 审计日志
• 并行安全与幂等性检查

我对这篇论文的几个理解

下面是我自己的理解，不是论文原文。

1. Skill 正在从“提示增强器”变成“程序封装单元”

一开始很多人理解 skill，只是把它当成：

• 长 prompt 的拆分方式
• 减少上下文长度的技巧

但论文证明它已经开始具备程序单元的很多特征：

• 有结构
• 有依赖
• 有输入输出约束
• 有复用价值
• 有故障模式

这时候再把它只当 prompt，就会低估系统问题。

2. Agent 平台下一步竞争点可能是 skill runtime

以后大家比的可能不只是：

• 模型强不强
• 工具多不多
• 提示词写得好不好

还会比：

• skill 能不能缓存
• skill 环境构建快不快
• skill 故障恢复稳不稳
• skill 审计和权限边界做得好不好

3. Skill OS 的本质是把“非确定执行”重新约束回系统边界

论文里有一句潜台词我很认同：

LLM 天生带有非确定性，而传统操作系统最擅长做的事，恰恰是给复杂不稳定底层提供稳定抽象。

Skill OS 想做的，就是把这种 OS 思想迁移到 Agent skill 时代。

论文的局限

1. 这是 survey + position paper，不是完整实现论文

它的价值主要在：

• 抽象问题
• 总结规律
• 提出系统需求

而不是已经交付一个成熟 Skill OS。

2. 六个性质来自公开仓库统计，仍然可能有样本偏差

公开 skill 和企业内部 skill，在复杂度、安全约束、依赖方式上可能存在差异。

3. 从 skill 到“系统原语”的落地还需要更多运行时验证

例如：

• 缓存命中到底能省多少 token 和延迟
• 环境构建会不会带来额外冷启动成本
• 并行安全 enforcement 怎么做才不影响灵活性

这些还需要后续系统论文继续补。

对工程实践的启发

1. skill 最好尽量结构化

如果 skill 已经写成分阶段、分步骤、条件明确的形式，后续无论做缓存、回放还是失败恢复，都更容易系统化。

2. 不要把依赖问题完全交给模型“边跑边猜”

如果 skill 需要特殊环境，最好显式暴露出来，否则模型会在运行时用大量 token 去做本不该它做的依赖排障。

3. 并行安全和幂等性不能只写在说明里

只要多个 agent 或多个 branch 并行起来，纯提示层约束很容易失效。最好尽早往系统级策略靠。

总结

如果只用一句话概括这篇论文，我会这样说：

它想表达的是，skill 正在从“prompt 的附件”变成“agent 的应用单元”，而一旦 skill 成为应用，缓存、环境、调度、故障恢复和安全治理这些 OS 级问题就迟早要补上。

所以这篇论文真正有价值的地方，不是那句口号本身，而是它把一个趋势说透了：

• App 时代，OS 管应用
• Agent 时代，系统层很可能要开始“管 skill”

参考

• 论文 PDF：https://os-for-agent.github.io/papers/AgenticOS_2026_paper_13.pdf
• AgenticOS 2026 Workshop：https://os-for-agent.github.io/

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 :)

---

---

© 2018-至今 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)