写在前面

---

• 博文内容为 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 爆炸增长后，底层系统应该怎么变
• 理解不足小伙伴帮忙指正 😃,生活加油

我看远山，远山悲悯

持续分享AI Agent相关技术干货，感兴趣的小伙伴可以关注交流 ^_

---

一句话先说结论

这篇论文最核心的观点极具冲击力：

Skill 已经不只是“为了节省Token而拆分的提示模板”，它正演化成一种可复用、可调度、可治理，且带有明确环境依赖和安全边界的新型执行单元。因此，我们需要一个类似操作系统（OS）的系统层，将其作为“一等公民”进行统一管理。

这句看似激进的论断，结合论文中的实证分析与系统思考，实则极具说服力。

名词解释

• Skill（技能）：可复用的任务能力包，通常包含说明文档、执行步骤、脚本代码及相关资源文件，是Agent完成特定任务的核心能力载体。
• Skill OS：一种系统层抽象，核心是将 Skill 作为一等执行单元，对其进行统一调度、管理、缓存和安全管控的系统架构。
• prompt-centric（提示中心式）：以提示词加载为核心的执行模式，系统的主要职责是将Skill文本加载到模型上下文，由模型自行解析并执行。
• procedure（过程化流程）：具备明确步骤划分、阶段边界，且包含条件分支、循环等逻辑结构的执行过程描述。
• semi-deterministic blocks（半确定性块）：Skill 中大概率重复出现、内容相对稳定的步骤或片段，如固定模板、重复代码片段等。
• semantic equivalence（语义等价）：两次Skill调用的核心语义目标一致，但具体执行轨迹、步骤细节可存在差异。
• execution drift（执行偏移）：语义目标看似一致，但执行过程中的细节的逐渐偏离预期的现象，是LLM非确定性的典型表现。
• locality-aware caching（ locality感知缓存）：利用Skill中的重复结构和稳定块进行缓存优化，避免每次执行都从零解析，提升效率。
• dynamic environment construction（动态环境构建）：在Skill执行前，系统根据其依赖需求，动态拼接、适配合适运行环境的能力。
• global skill management（全局Skill管理）：跨任务、跨会话，对Skill、缓存及共享资源进行统一管理、调度和治理的系统能力。
• fault management（故障管理）：对Skill执行过程中的失败进行分类、拦截、恢复、回滚及审计的系统级能力。
• MCP（Model Context Protocol）：模型上下文协议，用于将外部工具、环境上下文接入LLM的标准化接口。

论文到底在研究什么

如今，Skill在主流Agent平台中已成为标配，例如 Claude Code、Cursor、OpenAI Codex、Gemini 等，均支持不同形式的Skill包。

一个完整的Skill，通常包含三部分核心内容：

• 元数据（描述Skill的用途、作者、依赖等基础信息）
• 指令正文（具体执行步骤、逻辑规则等）
• 捆绑资源（脚本文件、模板、参考文档、资产文件等辅助材料）

论文一针见血地指出：当前主流的Skill运行模式，本质上仍属于 prompt-centric（提示中心式），其执行流程可概括为四步：

1. 系统启动时，扫描并加载所有Skill目录；
2. 根据用户请求，筛选出与任务相关的Skill；
3. 将Skill的指令文本完整加载到模型上下文；
4. 由LLM解析指令、调用工具，完成任务执行。

这种模式的优势在于实现简单、门槛低，但随着Skill的数量激增、复杂度提升，其底层缺陷逐渐暴露，成为制约Agent规模化应用的瓶颈。

论文做了什么实证工作

这篇论文并非纯理论、纯观点输出，而是基于扎实的实证分析展开——作者团队收集并分析了近10万个公开Skill，核心目标并非统计Skill的热度，而是解答一个关键的系统级问题：

Skill 到底具备哪些共性特征？这些共性是否足以支撑起一层全新的系统抽象？

通过对海量样本的分析，作者最终总结出Skill的 六个关键性质，为“需要Skill OS”这一核心观点提供了坚实的实证支撑。

Skill 的六个关键性质

1. 多数Skill本质是过程化流程（procedure）

论文研究发现，超过 50% 的Skill可以被合理地归类为“过程化流程”，即具备明确的步骤划分、阶段边界，包含条件分支、循环等逻辑结构，而非杂乱无章的自由文本。

这一发现至关重要——它打破了“Skill只是提示词片段”的认知，证明Skill更接近“可执行的微型程序”，拥有清晰的执行结构。而这种结构，为系统层的优化提供了基础：系统可以在步骤边界上实现 checkpoint（检查点）、缓存、失败恢复、并行调度等功能，大幅提升执行效率和稳定性。

2. 多数Skill包含半确定性块（semi-deterministic blocks）

研究显示，大约 70% 的Skill中，都包含“半确定性块”——即每次执行时重复出现、内容相对稳定的片段，例如大段固定模板、重复的代码片段、标准化的工具调用序列等。

当前的运行模式中，这些稳定片段每次都会被完整加载到模型上下文，造成大量Token浪费和效率损耗。这也意味着，现有系统并未充分利用Skill的局部性特征，存在巨大的优化空间。

3. 语义等价≠执行等价

即使两次Skill调用的核心语义目标完全一致，LLM生成的执行步骤、参数配置、工具调用细节仍可能存在差异——论文将这种现象称为 “语义等价下的执行偏移（execution drift under semantic equivalence）”。

这一现象非常贴合实际：语义层面的“完成同一任务”，不代表执行层面的“步骤完全一致”。因此，对Skill的缓存优化，不能简单采用字符串级别的精确匹配，而需要基于语义层面的感知和适配。

4. Skill的约束多为“文本提示”，缺乏系统级强制

论文中专门举了一个典型例子：一个并行执行的Skill，明确要求子任务之间互不干扰，但这种要求仅以自然语言的形式写在指令中，例如“不要并发处理互相关联的问题”“避免共享状态冲突”“要求幂等性”等。

核心问题在于：当前系统层并未对这些约束进行有效强制执行，导致这些安全要求沦为“提示词里的希望”，而非“运行时的保证”。一旦Agent并发执行、跨会话调用，很容易出现冲突、异常等问题。

5. Skill高度依赖外部执行环境

论文通过统计发现，Skill对外部环境的依赖程度远超预期：

• 约 45% 的Skill依赖Shell工具（如grep、awk等）；
• 约 31% 的Skill会直接调用OS API（如read、exec等）；
• 此外，还有部分Skill依赖数据库命令、网络接口、MCP服务或特定版本的工具链。

更关键的是，作者发现：若缺少正确的运行环境依赖，LLM会陷入高Token消耗的“试错修复”循环。论文中一组直观的数据显示，部分Skill在依赖缺失时，会额外消耗几十万Token，其中甚至出现了 331.3k 级别的Token开销，严重影响执行效率和成本控制。

6. Skill存在跨会话复用，但缺乏全局管理

很多Skill并非一次性使用，而是会在多个任务、多个会话中重复调用。但当前的Agent平台中，LLM仅能感知当前对话上下文，缺乏系统级的全局视角，导致无法实现：

• 发现跨任务可复用的Skill；
• 统一管理Skill的共享资源；
• 实现全局缓存优化；
• 进行系统级的审计和治理。

为什么作者认为需要 Skill OS

论文的逻辑脉络非常清晰：只要认可上述Skill的六个关键性质，就会自然得出一个结论——Skill 早已不是单纯的提示词，它已经具备了程序的结构、执行语义、依赖关系、安全要求和跨会话复用特征，因此，其管理职责需要从“模型层”下沉到“系统层”，由专门的系统抽象来接管。

作者提出的 Skill OS，并非某一款具体的产品，而是一种全新的系统层抽象，其核心目标是解决Skill规模化应用中的系统级问题，重点覆盖五类核心需求。

Skill OS 应该做什么

1. 局部性感知缓存（locality-aware caching）

基于Skill中大量存在的半确定性块，Skill OS应实现针对性的缓存优化，不再每次从零解析、从零执行。具体而言，应缓存以下内容：

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

同时，缓存策略需突破“字符串级匹配”的局限，基于语义等价性进行适配，避免因执行偏移导致缓存失效。

2. 动态环境构建（dynamic environment construction）

Skill OS应承担起“环境适配”的职责，在Skill执行前，主动动态构造合适的运行环境，而非将依赖解析、环境适配的任务全部丢给LLM临场补救。

具体而言，系统需要同时感知两侧信息：一是Skill明确声明的依赖需求，二是当前运行机器的实际环境配置，将两者进行对齐匹配后，为Skill绑定最优的执行环境，避免因依赖缺失导致的效率损耗和执行失败。

3. 全局Skill管理（global skill management）

论文强调，Skill OS的核心优势之一，是具备跨任务、跨会话的全局视角。基于这一视角，它可以实现：

• 识别高频复用的Skill，优先进行缓存和资源分配；
• 统筹管理共享资源，避免资源浪费和冲突；
• 对不同Skill的执行环境进行隔离，保障安全性；
• 避免多个Agent并发执行时，出现“踩状态”等异常问题。

4. 系统级故障管理（system-level fault management）

当前，Skill执行过程中的工具失败、环境异常等问题，在LLM眼中只是一段错误字符串，需要模型自行猜测故障原因并尝试修复，效率低下且不可靠。

论文希望Skill OS能像传统操作系统处理异常一样，对Skill执行过程中的常见故障进行系统化管理：包括故障分类、实时拦截、恢复策略决策，以及在步骤边界进行回滚或断点续跑，避免每次故障都需要从头重跑整个Skill，大幅提升执行稳定性和效率。

5. 安全、访问控制与审计（security, access control, auditing）

这是Skill OS最具实际价值的功能之一。当前，很多Skill的安全要求仅停留在文本描述层面，无法形成有效的运行时约束。Skill OS应将这些文本化的安全要求，提升为系统级的强制策略，具体包括：

• 精细化的权限控制（限制Skill对工具、API、数据的访问权限）；
• 明确的工具访问边界（防止Skill越权调用危险工具）；
• 完整的审计日志（记录Skill的执行轨迹、资源使用、权限调用等信息）；
• 并行安全与幂等性检查（强制落实Skill的安全约束，避免并发冲突）。

我对这篇论文的几个理解

以下是我结合自身认知的思考，非论文原文内容，供大家交流参考。

1. Skill 正在从“提示增强器”进化为“程序封装单元”

最初，很多人对Skill的理解，仅停留在“长提示词的拆分方式”“减少上下文长度的技巧”，将其视为LLM的“辅助工具”。但论文的实证分析证明，Skill已经逐渐具备了程序单元的核心特征：有结构、有依赖、有输入输出约束、有复用价值、有明确的故障模式。

此时，若仍将其简单视为“提示词附件”，就会低估其背后的系统级问题，也无法充分发挥其价值——Skill的进化，必然要求底层系统的升级。

2. Agent 平台的下一轮竞争，将聚焦于 Skill 运行时（runtime）

当前，Agent平台的竞争焦点多集中在“模型强弱”“工具数量”“提示词质量”上，但随着Skill的规模化应用，下一轮竞争将逐渐转向底层的Skill运行时能力。未来，一个优秀的Agent平台，不仅要具备强大的模型和丰富的工具，更要在以下方面形成优势：

• Skill缓存效率（能否大幅节省Token和执行延迟）；
• 环境构建速度（能否快速适配Skill的依赖需求）；
• 故障恢复稳定性（能否快速处理执行异常，减少重复消耗）；
• 安全治理能力（能否保障Skill执行的安全性和合规性）。

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

论文中隐含着一句核心潜台词，我非常认同：LLM天生具有非确定性，而传统操作系统最核心的价值，就是为复杂、不稳定的底层硬件和软件，提供稳定、可靠的抽象层和约束边界。

Skill OS想要做的，正是将这种“操作系统思想”迁移到Agent时代——面对LLM带来的执行不确定性，通过系统层的抽象、调度和约束，让Skill的执行变得更可控、更高效、更安全。

对工程实践的启发

1. Skill 设计应尽量结构化

在编写Skill时，尽量将其设计为分阶段、分步骤、条件明确的过程化形式，明确步骤边界和逻辑结构。这不仅便于LLM解析执行，更能为后续系统层的缓存、回放、失败恢复等优化，提供清晰的切入点，实现系统化管理。

2. 显式暴露Skill的依赖需求，避免模型“边跑边猜”

若Skill需要特定的运行环境、工具或API依赖，应在元数据中显式声明，而非仅在指令文本中提及。这样可以让系统提前感知依赖需求，主动构建适配环境，避免LLM在运行时花费大量Token进行依赖排障，降低效率和增加成本。

3. 安全约束需从“文本提示”升级为“系统策略”

当多个Agent、多个Skill并行执行时，纯文本层面的安全约束（如幂等性、并发隔离）很容易失效。因此，在工程实践中，应尽早将这些安全要求转化为系统级策略，通过权限控制、环境隔离等方式，确保约束被有效强制执行，保障系统稳定性和安全性。

总结

用一句话概括这篇论文的核心思想：Skill 正在从“prompt的附件”进化为“Agent的应用单元”，而一旦Skill成为新时代的“应用”，缓存、环境、调度、故障恢复和安全治理这些传统OS的核心问题，就迟早要在Agent时代补上。

这篇论文真正的价值，不在于“Skills are the new Apps”这句口号，而在于它看透了一个核心趋势：

• App时代，操作系统管理“应用”，支撑了移动互联网的规模化发展；
• Agent时代，系统层也必将开始“管理Skill”，这是Skill规模化应用的必然要求，也是Agent技术走向成熟的关键一步。

博文部分内容参考

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

---

• 论文 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)