SkillOS 深度调研：当 Skill 成为 Agent 系统的基本程序单元，这条路能走通吗

AI Systems / Agent OS / Survey Essay

SkillOS 深度调研：当 Skill 成为 Agent 系统的基本程序单元，这条路能走通吗

在最近一波 agent system 叙事里，很多项目在讨论“工具调用”“多智能体协作”“记忆”“规划”，但 SkillOS 想做的事情更激进：它试图把 agent、tool、planner、memory、security、runtime 乃至项目目录结构都重新组织成一套 skill 体系，并用 markdown 去定义这些 skill 的规格，再让 LLM 直接充当这些规格的解释器。换句话说，它不是在一个既有 runtime 上“挂几个 agent”，而是在尝试把 skill 变成 agent 系统里的基本程序单元。

这使它成为一个非常值得单独调研的项目。它既不是传统的工作流编排框架，也不是单个研究论文的代码附件，而更像“研究型原型 + 架构宣言 + 文档驱动实验平台”的混合体。本文基于公开仓库、README、架构文档、测试文件、benchmark 脚本与相关论文锚点，对 SkillOS 做一次尽量克制、面向工程判断的综述式梳理。

项目状态 公开仓库、文档、测试和 benchmark 都比较齐，但整体仍明显带有研究原型特征，不宜直接等同于成熟生产系统。

论文状态 截至 2026-06-02，未确认到独立的 SkillOS 正式 paper；其规划理论核心锚点主要外引 HWM 论文。

最高价值 它把 markdown 规格、分层技能树、懒加载路由、认知流水线和 dialect 压缩层系统性地拼成了一套完整叙事。

最大风险 文档叙事、测试口径与仓库快照之间存在错位，尤其体现在多运行时实现一致性和可复现性上。

一、先给结论：SkillOS 值得研究，但不该被误判为成熟 Agent OS

如果只看 README，SkillOS 很容易被理解成一个“已经把 Agent OS 跑通”的系统：有 Skill Tree，有 HWM 规划，有 memory，有 security，有多运行时，有 benchmarks，还有针对中等模型的 cognitive pipeline。但把公开材料拆开看之后，更准确的判断是：SkillOS 目前最强的是概念架构与规格化表达，不是工程闭环已经完全坐实。

它的真正贡献不在于“终于做出了 agent 版 Linux”，而在于它把很多之前分散在 prompt engineering、agent workflow、tool orchestration、context compression 里的想法，收束成一个相对一致的系统设计语言。这个语言的核心观点是：skills as programs，也就是把技能规格本身视为程序，把 LLM 视为解释器，把项目目录、manifest、routing index、dialect 和 memory 都当作运行时协议的一部分。

我的核心判断： SkillOS 更像一个高密度的研究型开源原型与架构宣言。它非常适合拿来研究 agent 系统应该如何被“规格化”，也适合做实验性系统、教学型原型、runtime 叙事验证和 prompt 协议探索；但如果把它直接当成“已经验证完毕、可无痛生产部署的 Agent OS”，这个评价明显过头。

最值得学的部分

把 markdown 从“说明文档”提升为“路由卡 + 行为规范 + 组合协议 + 可演进接口”的一等公民。

最需要防止误读的部分

文档里的“支持某运行时”“有某能力”与仓库快照里“可直接复现某能力”并不总是同一件事。

最强的工程美感

把 Domain → Family → Skill、manifest、base 继承、lazy loading 与语言门面组织成一整套统一词汇体系。

最现实的工程短板

公开快照里多运行时叙事存在缺口，端到端验证并没有完全覆盖“文档承诺的所有路径”。

二、SkillOS 到底是什么：一个把 markdown 当作操作系统规格层的原型

从 GitHub 元数据来看，SkillOS 仓库是 EvolvingAgentsLabs 在 2026-03-17 创建的公开仓库，仓库描述直接写着 PoC about how generate an Agentic OS, based in Skills as programs。这个描述其实很诚实：它自己就把项目定位成 PoC，也就是 proof of concept，而不是 production-ready 平台。

公开文档里对 SkillOS 的主叙事非常一致：它把自己描述成一个 Pure Markdown Operating System。但更准确地说，系统中的 agent、tool、memory、planner 和 validation 能力被组织成 skill，而这些 skill 再以 markdown 文档形式存在；文档用 YAML frontmatter 描述元信息，用 markdown body 描述行为，最终由 Claude Code、Qwen、Gemini、Gemma 这类 LLM runtime 在执行时读取、解释和调用工具。

1. 它不是传统框架

SkillOS 并不把 Python 类、LangGraph 节点或工作流 DSL 作为第一主角，而是把 markdown 规格文件当作系统基本单元。

2. 它也不是单一 agent

系统的最小计算单元叫 skill，skill 又被分成 agent 和 tool；因此它更像“技能操作系统”，而不是某个总控 agent 的简单扩展。

3. 它强调目录即协议

system/skills、projects/[ProjectName]、.claude/agents、state、memory 这些目录都被赋予了明确运行时含义。

4. 它强调 LLM 即解释器

项目文档反复强调“没有编译器去解释 markdown，LLM 本身就是解释器”，这是 SkillOS 最核心也最激进的设计前提。

维度	SkillOS 的主张	更现实的工程解读
系统边界	一个完整的 markdown operating system	一个高度规格化的 agent system 原型，重点在于定义统一的系统描述语言。
执行方式	LLM 直接解释 markdown skill	更接近“prompt 协议 + 目录协议 + tool loop”的组合执行方式，而非传统意义上的可验证解释器。
扩展方式	通过新增 markdown skill 动态扩展能力	这个方向非常有价值，尤其适合 agent catalog、场景包和任务模板的模块化扩展。
成熟度	文档叙事接近完整平台	代码与测试仍显示其主要价值在研究原型、结构实验和概念验证，而非稳态工业平台。

三、SkillOS 最重要的创新，不是“更多 agent”，而是“规格即程序”

SkillOS 的第一个核心创新，是把 skill 的完整规格直接写进 markdown，并且把这份 markdown 当成执行逻辑本身。这个思想在 docs/skills.md 中写得很明确：一个 skill 由 YAML frontmatter 和 markdown body 两部分组成，前者负责元数据和路由信息，后者负责行为规范。

---
name: my-agent
type: agent
domain: orchestration
family: core
extends: orchestration/base
description: One-line description used for routing decisions
tools: [Read, Write, WebFetch]
invoke_when:
  - when this goal is detected
---

# MyAgent

## Purpose
...

## Instructions
1. Step one
2. Step two

这种写法的关键不是“文档写得漂亮”，而是它把原本散落在代码注释、系统 prompt、路由表、权限声明和工具清单里的信息，压进了同一个规格载体。对 agent 系统来说，这带来三个非常实际的收益。

1. 路由信息不再与实现文档分离，manifest 可以直接为 router 提供低成本判断卡片。
2. skill 可以显式继承 domain/base 规格，从而把共享行为抽象到 markdown 层，而不是只能藏在代码里。
3. 对于需要频繁新增能力的系统，新增 skill 的边际成本会更低，因为新增的是“协议对象”，不是一整段新的 runtime 代码。

为什么这点重要： 很多 agent 项目都在讲“tool use”“sub-agent”“workflow”，但真正难的往往不是把调用串起来，而是如何让能力项可发现、可路由、可继承、可审查、可被后续 agent 继续维护。SkillOS 试图用 markdown 规格把这几件事统一起来，这正是它最有启发性的部分。

四、把系统拆开看：SkillOS 有三条主轴

如果只用一句话概括 SkillOS 的结构，我会说它有三条主轴：规格与路由层、执行与规划层、验证与安全层。这三条主轴在公开文档里互相咬合，也是理解项目最有效的切入方式。

规格与路由层主要由 docs/architecture.md 和 docs/skills.md 支撑。SkillOS 把 skill 组织成 Domain → Family → Skill 的三级树结构，并为每个 skill 配一张轻量 manifest 卡片，用于 lazy loading 路由。

Step 1  识别 domain 关键词
Step 2  读取 SkillIndex.md
Step 3  读取 domain/index.md
Step 4  读取 skill.manifest.md
Step 5  只有在真正调用前才加载 full spec

这套机制的价值很明确：如果一个系统要管理几十上百个 skill，而每个 skill full spec 都很长，那么“先路由 manifest，再按需展开 full spec”是比平铺所有 prompt 更合理的 token 策略。SkillOS 把这件事显式化了，而且和 skill tree 绑定得很紧密，这是它作为“系统设计原型”的重要亮点。

Manifest 不是附属文档

在 SkillOS 里，manifest 是一等运行时对象。它不是为了“补文档”，而是为了让路由本身更低成本、更可控。

继承也被规格化了

extends: validation/base 这类字段把共享行为提升到了 markdown 协议层，减少了散落规则。

目录树即系统地图

你几乎可以通过浏览 system/skills/ 目录树直接理解系统的能力地图，这一点对维护者非常友好。

懒加载是真实工程需求

对于上下文昂贵的 agent runtime，先读 manifest 再读 full spec，不是美学选择，而是必要的 token 工程。

执行与规划层由三部分构成：HWM 规划、cognitive pipeline、dialect / language facade。它们分别解决“下一步做什么”“中等模型如何可靠做多步任务”“内部表达如何压缩并提高推理质量”这三个问题。

其中最值得注意的是 cognitive pipeline。它本质上不是更强的模型，而是外部强约束执行策略：为每个子任务隔离上下文、预注入文件内容、提供工具调用脚手架、做输出验证与重试，并在必要时动态生成缺失 agent。这个思路很接近 Claude Code / Codex 一类工具链里“subagent + bounded tool loop”的工程经验总结。

模块	解决的问题	更准确的工程理解
HWM planner	给 skill invocation 引入层级规划视角	是对 HWM 思想的 prompt / workflow 映射，不是训练型 latent world model 的严格实现。
Cognitive pipeline	让 mid-tier 模型按阶段完成复杂场景	本质是“外部施加结构”，而不是模型自己获得了更强的自主编排能力。
Dialects	压缩 token、降低输出冗余、约束表达	最强价值不只是省 token，而是把某些任务强制映射成更低歧义的中间表示。

验证与安全层由测试文件、benchmark 脚本、docs/security.md、permission_policy.py 和 sandbox.py 组成。它们证明 SkillOS 不只是停留在概念海报，而是至少试图给自己的叙事补上约束、扫描、路径限制和性能对比。

但这里也必须分清两件事：有测试 不等于 所有关键路径都被强端到端验证；有 benchmark 也不等于 项目外部独立复现过 benchmark。SkillOS 的测试和 benchmark 提供了有价值的项目内证据，但还没有强到足以消除所有“文档叙事领先代码实现”的疑虑。

这也是我对项目的总体态度： SkillOS 值得认真看，因为它不是空喊概念；但也必须保持工程上的克制，因为它仍然更多是在“证明这条设计路线有意思”，而不是“证明这套系统已经全面稳固”。

五、关于“paper”：目前最可信的论文锚点是 HWM，而不是独立 SkillOS 论文

这是调研里最容易被误读的一点。SkillOS 文档中最重要的理论锚点，是 Hierarchical Planning with Latent World Models。在 docs/planning.md 里，项目明确把 HWM 作为默认逻辑执行策略，并把高层世界模型、低层世界模型、macro-action、subgoal、replanning 这些概念映射到了 SkillOS 的 skill 调度与 tool 调用过程上。

但截至 2026-06-02，我没有确认到以 SkillOS 为题、正式描述该系统本身的独立 paper。也就是说，当前公开可确认的学术锚点，主要是它借用和改写的 HWM 论文，而不是“SkillOS 已经作为一个独立系统被论文严格定义和评估”。这不是小差别，因为这决定了我们如何看待它的理论地位。

问题	可确认事实	应当避免的误读
SkillOS 有独立 paper 吗？	目前未确认到独立正式 paper。	不要把仓库文档直接当作已发表论文结论。
HWM 与 SkillOS 是什么关系？	HWM 是 SkillOS 规划层的主要理论锚点。	不要把 SkillOS 说成 HWM 论文的官方实现，或等同于 latent world model 训练系统。
SkillOS 真有 latent world model 吗？	公开文档更像是在用结构化状态文件和 LLM 推理去“类比实现”世界模型接口。	不要把这种 prompt-level mapping 直接说成严格世界模型方法复现。

一个关键边界： SkillOS 对 HWM 的使用，更接近“把 HWM 的层级规划思想翻译为 markdown 状态文件、subgoal 文件和 skill / tool 选择协议”，而不是在做一个带 latent state 学习、预测误差建模和显式训练目标的严格 world model 系统。这并不削弱它的启发性，但会直接影响你该如何判断它的学术严谨性与工程可复现性。

六、HWM 映射本身有价值，但它本质上仍是“协议化规划”

SkillOS 在规划层做的事情，本质上是把 HWM 的概念翻译成文件协议和 LLM 推理协议。例如文档中把 world_state.md 视为状态编码，把 skill invocation 视为 macro-action，把 tool call 视为 primitive action，把 subgoal.md 视为高层规划产出的阶段目标，再通过 divergence threshold、stagnation window、final transition 等机制控制何时重规划、何时降级为 flat planner。

这种设计有两个现实优点。第一，它让规划过程对维护者可见，不再完全藏在一坨对话历史里；第二，它把“计划”“子目标”“当前世界状态”都落成了项目内可审查的 artifact，这对调试 agent system 很有帮助。也就是说，即便你不把它当作严格 HWM，它依然是一种相当好的 agent planning 工程化表达方式。

它把规划显式化了

很多 agent 系统有计划，但计划是隐性的；SkillOS 把计划、世界状态和子目标都文件化了。

它让调试变得可能

如果预测状态、实际状态和重规划触发条件都可以被记录，agent 行为至少更容易被复盘。

它降低了规划概念门槛

研究者不需要先搭建复杂的学习型 world model，就能试验“层级规划 + 子目标”这套方法论。

但它仍偏向提示协议

规划质量最终仍高度依赖 LLM 的语义判断，而不是一个被训练和校准过的动态模型。

因此我会这样定义它： SkillOS 不是“把 HWM 原封不动搬进 agent 系统”，而是“把 HWM 的规划词汇、决策节拍和层级分工嫁接到一个 markdown-native runtime 中”。对于架构研究，这是优点；对于严格复现论文，则必须保持审慎。

七、Cognitive Pipeline 是 SkillOS 最实用的一块：它解决的不是智能，而是执行秩序

如果说 HWM 更偏“理论叙事”，那么 cognitive pipeline 就更偏“工程经验”。在 docs/cognitive-pipeline.md 中，SkillOS 把模型按 high / mid / low tier 划分，并为中等模型设计了一套外部约束式的执行策略：自动解析 scenario、逐步运行每个阶段、注入前置文件、提供工具调用脚手架、验证输出、不合格则重试，必要时还动态生成 agent spec。

这一套做法最有价值的地方，在于它抓住了一个非常真实的问题：很多中等模型不是完全不会做复杂任务，而是不会稳定地自我编排复杂任务。SkillOS 的解决办法不是“让模型更聪明”，而是“把工作流强制拆开，让模型只在一个很窄的上下文里做一件事”。这就是它文档里说的 Recursive Context Isolation。

补偿机制	针对的失败模式	工程意义
Tool-call scaffolding	中等模型在几轮后忘记工具格式	把工具调用格式固定住，减少输出塌缩。
Prior-output file injection	模型不会主动读取前一步产物	直接把关键文件注入上下文，降低遗漏依赖的概率。
Dynamic agent creation	场景里需要的 agent 事先不存在	让 scenario 驱动 agent catalog 增长，而不是事事手工补齐。
Auto-wrap prose	模型写出内容但没按要求写文件	把“有用但不合格”的输出变成可回收结果。
Output validation + retry	输出过短、未落盘、缺段落	把质量门槛外显成规则，而不是靠人工猜。

为什么我认为这块最实用： 它并没有假装“中等模型已经拥有强 executive function”，而是承认模型会塌缩、会忘记工具格式、会跳过步骤、会写出一大坨不可用 prose，然后用一层 deterministic orchestration 去补这些缺陷。这种思路很朴素，也很工程化。

八、Dialects 不是小功能，而是 SkillOS 的第二条方法论主线

SkillOS 的另一条高价值主线是 dialect framework。项目把 dialect 定义为一种领域特定压缩格式，用来把冗长自然语言压缩成更短、更稳定、歧义更少的中间表示。这里最值得注意的，不只是“省 token”，而是它把 compression、representation 和 reasoning scaffold 放到了同一个设计框架里。

文档列出的 14 种 dialect 中，最有代表性的三类分别是：strict-patch 这类软件工程型结构压缩、formal-proof / system-dynamics 这类推理脚手架、以及 dom-nav / trace-log 这类把复杂原始输入重编码为最小动作表示的压缩层。对 agent system 来说，这个思路非常关键，因为它触碰到了一个更底层的问题：agent 内部到底应该用人类自然语言思考，还是应该尽快编译到更适合机器执行的表示？

1. 压缩不仅是省钱

在 SkillOS 的叙事里，压缩后的表示往往更容易暴露结构，例如 run-length encoding 会让 stuck loop 一眼可见。

2. 约束本身就是质量提升

strict-patch 通过只允许输出补丁操作，逼模型像手术刀一样精确，而不是重写整份文件。

3. 形式化符号也是脚手架

formal-proof、boolean-logic、data-flow 不是单纯格式转换，而是在给模型上推理护栏。

4. Language Facade 很值得借鉴

人类说自然语言，内部 agent 说 dialect，再由 renderer 翻译回自然语言，这个 ingress / egress 边界设计相当清晰。

不过，我也不建议把这套 benchmark 读得过满。对于 strict-patch 一类场景，优势确实非常强；但对于分析型任务，文档也承认多轮 SkillOS pipeline 可能引入额外 orchestration overhead，导致总 token 反而更多。也就是说，dialect 真正适合的是那些“原始表示浪费严重、目标表示可强约束”的任务，而不是所有任务都机械压缩一遍。

这也是 SkillOS 和许多 agent 项目最大的气质差异： 它不是简单追求“让 LLM 在自然语言里多想几步”，而是不断试图把自然语言编译成更窄、更短、更稳定、更利于推理的内部表示。这个方向很可能是未来 agent engineering 的重要演化线索。

九、最需要警惕的工程问题：多运行时叙事与公开仓库快照之间存在错位

这是我在整个调研里最在意的一个问题。SkillOS 的 README、docs/runtimes.md、QWEN.md、tests/test_cognitive_pipeline.py 和 tests/test_runtime_qwen.py 都多次围绕 agent_runtime.py 展开，包括 CLI 用法、provider 配置、scenario 执行、Gemma / Gemini / Qwen runtime、工具编译等。

但在我对主分支公开递归树的核对里，没有找到 agent_runtime.py 这个文件。与此同时，run_scenario.py、permission_policy.py 和 sandbox.py 是可以在公开树里确认存在的。这意味着当前公开仓库快照里，围绕多 provider runtime 的文档叙事并没有被同等强度地落实成一个可直接核对的主实现文件。

对象	公开仓库中可确认	说明
docs/runtimes.md	是	明确描述 Claude Code、Qwen / Gemini / Gemma 等运行时。
QWEN.md	是	存在完整 manifest 风格运行时说明与工具定义。
tests/test_runtime_qwen.py	是	明确测试 agent_runtime.py 与 runtime manifest 解析。
agent_runtime.py	否	在公开递归树中未见该文件，这直接影响多运行时叙事的可复现判断。

这意味着什么： 这不一定说明项目在“造假”，更可能说明仓库快照、文档与测试维护节奏没有完全同步，或者某些实现尚未落进当前公开分支。但从工程判断角度，这已经足够构成一个明确风险信号：至少在多运行时这一块，SkillOS 的公开可复现性不能按文档最强表述去估计。

对研究型项目来说，这类错位并不罕见；但对任何想把它当作生产参考栈的人来说，这个问题必须被明确点出来。因为一旦 runtime 主文件不存在，围绕 provider config、agent delegation、tool compilation、scenario execution 的很多“能力声明”，就会从“可验证事实”退回到“文档承诺或测试期望”。

十、测试很多，但测试强度要分层看：不少测试更接近结构校验，而不是完整 E2E

SkillOS 的测试数量并不算少，覆盖了 boot manifest、cognitive pipeline、runtime、dialects、examples、security scanner、sandbox 等多个方面。这一点比很多只写 README 的 agent 项目强得多。不过，当我继续往里看，会发现其中相当一部分测试其实更偏“结构与源码文本检查”，而不是实打实跑完整执行链路。

举例来说，tests/test_cognitive_pipeline.py 里有不少断言是在检查源文件中是否存在某个函数名、某个字符串、某个控制流程片段，或者某个场景解析是否返回期望字段。它们有价值，因为它们能防止文档口径与代码结构继续漂移；但它们和真正跑一遍多 provider runtime、触发真实 tool loop、完成完整 scenario、再验证产物一致性，仍然不是一个强度层级。

结构测试的价值

它们能约束命名、文件组织、frontmatter、函数存在性和文档协议不被轻易破坏。

结构测试的局限

它们不能充分证明“在真实模型、真实 provider、真实工具环境下，整条执行链是稳定可复现的”。

benchmark 的价值更高

benchmark_patch.py、benchmark_math.py、benchmark_physiology.py 至少在尝试做任务级比较，而不只是结构检查。

benchmark 仍是项目内自证

这些 benchmark 很有参考价值，但目前主要还是项目自己定义任务、自己定义验证、自己在文档中解释结果。

更稳妥的表述应该是： SkillOS 有一套比普通 demo 丰富得多的测试与 benchmark 体系，但它们还不足以把项目直接抬升为“所有关键路径都被强验证过的成熟平台”。把它理解成“认真做了内部验证的研究型项目”会更准确。

十一、安全设计有明显工程意识，但它仍建立在“LLM 解释规格”的脆弱前提之上

SkillOS 的安全文档是我认为写得比较扎实的一部分。它明确区分了三层安全：路径穿越防护、skill 安全扫描、执行 sandbox。尤其是安全扫描器把 prompt injection、name spoofing、tool overclaiming、hardcoded exfiltration URL、obfuscation、delegation bomb、frontmatter integrity、supply chain conflict 拆成八项检查，这种 threat model 对一个“技能可安装、规格可解释”的系统来说是相当合理的。

同时，permission_policy.py 做路径限制，sandbox.py 提供 local / E2B 两类执行后端，这说明项目作者是清楚知道“LLM 解释 markdown 规格”会天然带来额外攻击面和边界不确定性的。换句话说，SkillOS 至少没有把自己浪漫化成“纯 prompt 就可以安全运行一切”。

安全层	解决的问题	现实边界
PathPolicy	阻止文件 I/O 脱离工作区	能约束路径，但不能自动证明上层 agent 行为都合理。
Skill Security Scanner	在安装技能前做类似 antivirus 的规则检查	对明显恶意模式有效，但仍主要依赖规则枚举，而不是强语义证明。
SandboxExecutor	把 shell 执行包进可切换后端	能减轻宿主风险，但并不消除“规格解释错误”或“agent 决策错误”的逻辑层风险。

安全层面的真实评价： SkillOS 的安全意识比许多 agent demo 强得多；但只要系统的底层前提仍然是“由 LLM 解释富语义 markdown 规格并产生动作”，那么很多风险本质上就不可能被彻底降到传统确定性软件的水平。这不是 SkillOS 独有的问题，而是这类系统设计共同要面对的硬边界。

十二、它最适合做什么，不适合做什么

讨论 SkillOS 时，最重要的不是问“它强不强”，而是问“它适合被放在哪一层”。从目前公开材料看，我认为它最适合放在以下几类场景里：研究型 agent 平台原型、skill catalog / prompt protocol 设计实验、面向中小模型的流程强约束 orchestration、以及探索 markdown-native runtime 的系统研究。

适合作为	原因	暂不适合作为	原因
研究型 agent OS 原型	它的概念层足够完整，且许多设计确实已经被文档、测试和 benchmark 具象化。	直接投产的通用 Agent OS	多运行时一致性与端到端可复现性仍存在明显疑点。
skill / agent 规格系统实验田	skill tree、manifest、base 继承、language facade 都很适合拿来做协议设计实验。	高可靠、强审计工作流内核	LLM 解释规格的底层前提仍然过于脆弱，不适合在没有额外硬约束的情况下直接承担关键流程。
中等模型补偿式 orchestration	cognitive pipeline 对 mid-tier model 的补偿策略很有现实意义。	理论上严格的 world model 系统	HWM 在这里更像方法借鉴和协议映射，不是严格的 latent world model 实现。
表示层与压缩层研究	dialects 把压缩、推理脚手架和边界翻译统一到了一个框架里。	未经二次验证的企业级基础设施	需要更强的外部验证、真实场景压测和代码与文档的一致性清理。

十三、最后的判断：SkillOS 的价值，在于它把下一代 agent 系统的“规格层”提前摊开了

SkillOS 最打动我的地方，不是它已经把每个工程细节都做完了，而是它把未来很多 agent 系统迟早都要面对的几个核心问题，提前摆到了桌面上：能力应该如何被组织与命名；路由应该如何低成本地发现合适 skill；共享行为应该如何被继承；多步任务该如何做子目标化；中等模型怎样靠外部结构补 executive function；自然语言什么时候应该被编译成更紧凑的中间表示；开放技能生态需要怎样的安全扫描与权限约束。

从这个角度看，SkillOS 更像一个“规格层原型”，而不是一个“所有部件都已经完美固化的操作系统”。如果你把它当成一个研究系统去看，它提供了大量值得拆解和复用的设计；如果你把它当成一个现成可投产的 Agent OS 去看，你就会不断撞到文档叙事与实现快照之间的边界。

一句话收束全文： SkillOS 还不是一个我会直接拿去押生产可靠性的成熟 Agent OS，但它非常可能是一个会影响很多后续 agent framework 设计方式的原型，因为它认真回答了一个更底层的问题：当 agent system 变复杂之后，我们究竟应该用什么样的规格层去组织它。

---

参考资料

[1] EvolvingAgentsLabs. SkillOS GitHub Repository.

[2] GitHub API. Repository metadata for EvolvingAgentsLabs/skillos.

[3] SkillOS README.

[4] SkillOS Documentation. Architecture.

[5] SkillOS Documentation. Skills: Agents and Tools.

[6] SkillOS Documentation. Planning: Hierarchical World Models.

[7] Zhang, W., Terver, B., Zholus, A., et al. Hierarchical Planning with Latent World Models.

[8] SkillOS Documentation. Cognitive Pipeline Executor.

[9] SkillOS Documentation. Dialects: Domain-Specific Token Compression.

[10] SkillOS Documentation. Security.

[11] SkillOS Documentation. Runtimes.

[12] SkillOS Runtime Manifest. QWEN.md.

[13] SkillOS Source. permission_policy.py.

[14] SkillOS Source. sandbox.py.

[15] SkillOS Source. run_scenario.py.

[16] SkillOS Tests. test_cognitive_pipeline.py.

[17] SkillOS Tests. test_runtime_qwen.py.

[18] SkillOS Tests. test_runtime_claude_code.py.

[19] SkillOS Benchmarks. benchmark_patch.py.

[20] SkillOS Benchmarks. benchmark_math.py.

[21] SkillOS Benchmarks. benchmark_physiology.py.