模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第16章 — 可扩展性对比
Token用量: 约 4,650 input + 1,170 output

16.2 技能系统

Skill 是一种非常特别的扩展机制。它不像 plugin 那样直接改运行时，也不像 hook 那样拦截生命周期。Skill 更像是把“知识、流程、经验、规范”注入给 agent。简单说，Plugin 改的是机器，Skill 改的是机器如何做事。

OpenCode 的 skill system 很优雅，原因在于它把技能定义成一种极轻量的内容资产：一个带 frontmatter 的 SKILL.md 文件就够了。目录发现也做得很开放：支持全局目录、项目目录、配置目录、显式路径，甚至远程 URL。这个设计有一个很强的优点——门槛低。写一个技能，不需要打包发布，不需要写代码，不需要理解复杂 SDK，只需要写清楚“这类任务应该怎么做”。

更重要的是，OpenCode 在技能发现上有明显的兼容性野心。它不只搜索自己的目录，还搜索 .claude/skills/ 和 .agents/skills/。这意味着它并没有把 skill 当成封闭生态里的私有格式，而是把它当成一种可以跨工具迁移的知识资产格式。这一点非常聪明，因为可移植性会降低用户迁移成本，也会放大整个 skill 生态的规模。

OMO 继承了这套能力，但并不满足于“技能能被找到”。它进一步让技能在运行时活起来。通过 category reminder、runtime 注入、skill-embedded MCP、自动命令触发等机制，Skill 不再只是静态文档库，而成为编排过程中的活跃参与者。这是 OpenCode 和 OMO 在技能层最大的区别：OpenCode 让技能可发现，OMO 让技能可运作。

Claude Code 也非常重视 skill，因为对于商业产品来说，Skill 是一个非常安全、非常可治理的扩展层。相比可执行插件，markdown 型技能更容易审核、更容易分享、更容易在团队里协作维护。它们可以承载组织规范、岗位流程、领域知识，而不必给外部代码太高权限。

三者对比可以概括为：

为什么 skill system 这么关键？因为大模型很多时候不是缺“通用智力”，而是缺“本地流程知识”。模型可能很懂编程，但不知道这个仓库该先跑哪个脚本，不知道哪些目录不能碰，不知道这个团队把哪条测试当成硬门槛。Skill 恰恰擅长承载这种局部、具体、组织化的 know-how。

这里的 know-how 也值得解释。它不是某个严格教材术语，而是工程实践里常用的词，指“知道怎么做的经验性知识”。这类知识通常很难浓缩进几条配置项里，却非常适合放进 skill。

从治理角度看，Skill 还有一个巨大优势：可审阅性强。Markdown 是人类可读的，frontmatter 是显式的，reviewer 很容易看出这个 skill 想教模型什么。它当然仍可能写得差、写得误导，但它的风险画像明显低于任意可执行代码。

OMO 在这之上又加了一层非常有意思的东西：skill-embedded MCP。也就是说，技能里不只是“告诉你该做什么”，还可能“带着你去调用做这件事需要的能力”。这样一来，Skill 就从纯知识资产，开始向“知识 + 能力入口”的复合对象演化。

这也引出技能系统的核心张力：发现性与过载之间的平衡。技能太少，很多组织知识永远沉睡；技能太多、注入太激进，agent 上下文就会变得嘈杂。OpenCode 通过清晰的发现层级来控制，OMO 通过类别感知和运行时提醒来控制，Claude Code 通过更产品化的调用方式来控制。

对未来 agent 平台而言，Skill 大概率会成为最重要的组织知识扩展层。它创建成本低、审阅成本低、迁移成本低，且风险远小于插件。OpenCode 展示了它的格式优雅，OMO 展示了它的运行时活化，Claude Code 展示了它在商业场景里的治理优势。

深度解析：技能系统——与MCP同等重要

模型: openai/gpt-5.4
Token用量（本次追加内容，估算）: 约 5,500 input + 2,400 output

为什么 Skill 值得被单独做一次深度分析？因为在 agent extensibility 里，它其实和 Plugin、MCP 处在同一个战略层级。只是过去大家更容易把注意力放在 MCP 上：协议更“硬核”、工程感更强、生态想象力更大，所以看起来更像“真正的基础设施”。但如果从一线项目成败去看，很多 agent 失败并不是因为缺少协议，而是因为缺少本地化流程知识——也就是它不知道这个团队到底怎么做事。

这里的“本地化流程知识”不是严格的教科书术语，而是一个工程分析概念。它指的是：只在某个团队、某个仓库、某条发布链路、某套协作习惯里成立的操作知识。比如先跑哪个脚本、哪些目录不能动、哪种测试必须过、PR 描述该按什么模板写、什么时候必须停下来让人确认、哪些操作属于高风险动作。这类知识往往不在通用文档里，但它恰恰最决定 agent 在真实环境中的成功率。

如果换一种更直白的说法：Plugin 改的是宿主能力，MCP 扩展的是宿主的工具边界，而 Skill 改的是 agent 的“做事方式”。三者缺一不可，但 Skill 最容易被低估，因为它看起来“不过就是一个 markdown 文件”。可问题恰恰在这里：真正高价值的扩展，不一定非得先表现成代码。很多时候，最关键的扩展是把隐性的 know-how 明确写出来。

这里的 know-how 也需要解释一下。它不是经典 CS 教材里的标准术语，更接近工程实践里常说的“会做这件事的经验性知识”。它和 declarative knowledge（陈述性知识）不同。陈述性知识告诉你“是什么”；know-how 告诉你“具体怎么做、先后顺序是什么、什么叫做做对了”。Skill 最擅长承载的，就是这种知识。

所以，Skill 不应该被看成 MCP 的附属物，而应该被看成三大扩展原语之一。一个 agent 系统如果只有工具，没有技能，那么它可能“什么都连得上”，却不知道“在这里应该怎么正确地做”。这就是为什么这一节要强调：技能系统与 MCP 同等重要。

一、OpenCode 的 Skill 架构：把扩展做成“内容资产”

OpenCode 的 Skill 设计非常值得研究，因为它抓住了一个极强的原则：把技能做成内容，而不是代码。它的基础载体是 SKILL.md 文件，前面配 YAML frontmatter，后面是 markdown 正文。frontmatter 用来写 name、description、触发条件、适用场景等元数据；正文则承载真正的知识、流程、模板、经验和注意事项。

这个设计的第一个优点是门槛极低。你不需要学 SDK，不需要写 server，不需要发 package，不需要部署进程。只要能把一件事情写清楚，就能做出一个 Skill。对团队来说，这意味着能写 Skill 的人，远比能写 Plugin 或 MCP server 的人多得多。架构师可以写规范类 Skill，运维可以写发布类 Skill，安全工程师可以写审计类 Skill，技术写作者可以写流程类 Skill。知识生产者不必变成平台开发者。

第二个优点是可审阅性非常强。Markdown 是天然可读的，frontmatter 是显式结构，reviewer 很容易看出这个 Skill 想教 agent 什么。相比之下，Plugin 或 MCP server 往往要经过代码审查、依赖审查、权限审查、行为审查，复杂度明显高得多。Skill 当然也可能写错、写偏、写得误导，但它的风险轮廓仍然更可控。

第三个优点是可移植性。文本资产的迁移成本远低于代码资产。OpenCode 在实现上也强化了这个方向：它不仅支持自己的目录，还支持跨生态的 Skill 发现。其发现层级大致包括全局目录、项目目录，以及多个兼容目录来源。

其中比较关键的发现路径包括：

• 全局级 Skill 目录，例如 ~/.config/opencode/skills/ 一类用户级目录，用于放个人长期可复用的 Skill；
• 项目级目录，例如 .opencode/skills/，用于放当前仓库的本地流程知识；
• 兼容目录，例如 .claude/skills/、.agents/skills/，用于吸收 Claude Code 和其他 Agent 生态里的 Skill 资产。

这一点非常重要。因为 OpenCode 并没有把 Skill 当成“自家格式”，而是把它当成一种跨工具的知识资产格式。这意味着用户不会因为换 Agent 框架就失去已有的流程知识。这种兼容性不只是 DX（Developer Experience，开发者体验）上的友好，更是一种生态策略：降低迁移成本，扩大可复用知识池。

OpenCode 在运行时还提供了 skill tool。它不会一开始就把所有 Skill 全塞进上下文，而是先向 agent 暴露“有哪些 Skill 可用”，然后在任务匹配的时候再按需加载。这个设计非常合理，因为 Skill 的价值不在“全部预装”，而在“该用的时候被精准拉进来”。如果所有 Skill 都预加载，token 会浪费，上下文也会被噪声淹没。OpenCode 的做法可以概括成一句话：广泛发现，按需注入。

从设计哲学上讲，OpenCode 的 Skill system 是一种 content-first extensibility。它不是先问“平台允许执行什么代码”，而是先问“平台怎么最低成本地吸收知识”。在 agent 时代，这是非常重要的转向。

二、Oh-My-OpenCode 的创新：把 Skill 从静态知识变成动态编排单元

OMO 继承了 OpenCode 的 Skill 发现机制，但真正有意思的是，它没有停留在“找到 Skill”这一步，而是继续往前推进，试图把 Skill 变成运行时编排中的活跃对象。

如果说 OpenCode 的关键词是“可发现”，那 OMO 的关键词就是“可激活”。在 OMO 里，Skill 不只是一个安静躺在目录里的 markdown 文件，它还会被提醒、被路由、被去重、被合并、被和能力绑定。也就是说，Skill 从被动知识库，进化成了 agent orchestration 的参与者。

OMO 最有代表性的创新，是 skill-embedded MCP。这不是一个教科书概念，而是 OMO 里非常值得关注的工程模式。它的含义是：一个 Skill 不只包含“如何做某件事”的知识，还可以捆绑一个 MCP server 配置（stdio 或 HTTP）。这样一来，知识和能力被打包进了同一个单元。

传统 Skill 更像“操作说明书”；skill-embedded MCP 则像“操作说明书 + 随盒附带的工具接口”。这会带来一个质变：从“告诉模型该做什么”，变成“告诉模型该做什么，并顺带提供做这件事需要调用的能力入口”。这极大缩短了从理解到执行的路径。

SkillMcpManager 则是支撑这个想法落地的关键部件。它负责 MCP client 的连接复用、session 隔离、重试、认证升级处理、空闲清理和统一断连。换句话说，OMO 不是把 skill-embedded MCP 当成一个概念演示，而是真的为它补齐了生命周期管理。如果没有这一层，技能里嵌的 MCP 很快就会变成连接满天飞、资源难清理的运行时负担。

由此，OMO 实际上形成了一个很有代表性的三层 MCP 体系：

1. 内建 remote MCP：例如 Exa / web search、Context7、grep.app 这一类高价值外部能力；
2. Claude Code MCP 兼容层：从 .mcp.json 读取已有 MCP 定义，兼容 Claude Code 生态；
3. skill-embedded MCP：把领域知识和该领域所需能力封装在同一个 Skill 里。

这三层分别对应三种不同需求：平台级默认能力、环境级兼容能力、领域级打包能力。它们一起把 OMO 的 Skill system 推到了一个比 OpenCode 更动态、更复合的位置。

OMO 的另一个关键创新，是 runtime skill reminders。这看起来像小功能，实际上解决的是 agent 系统里一个非常常见的问题：知识明明存在，但模型想不起来用。Skill 如果只能“被手动调用”，很多组织知识仍然会长期沉睡。OMO 通过 task category、agent role、任务语义等信号，在运行时提醒模型“有这些相关 Skill 值得考虑”。

本质上，这是一种知识推荐机制。它的价值在于减少模型滑向通用套路的概率，让模型更早意识到“这里有本地流程”。在多 agent 环境里，这尤其关键。因为一旦 orchestrator 忘了相关 Skill，下游所有 subagent 都会一起偏离。提醒机制提升的不是单一步骤效果，而是整条委派链的一致性。

OMO 还处理了技能生态里的另一个现实问题：重复与冲突。同名 Skill 可能来自 builtin、用户目录、项目目录、Claude Code 兼容目录，甚至其他来源。如果不做处理，结果要么是重复暴露，要么是冲突覆盖，要么是上下文里出现多个相似版本。OMO 通过 skill deduplication 和 merge 逻辑，把多个来源整理成更干净的最终集合。这一点看似不起眼，其实是“开放兼容”能否成立的基础。开放发现如果没有冲突治理，就很容易变成混乱发现。

最后，还要提 skill-guardian。它体现的是 OMO/Claude 式 Skill 生态中一种很成熟的治理意识：Skill 虽然比 Plugin 安全得多，但也不是完全不需要把关。一个恶意或低质量 Skill，仍然可能误导模型、引入错误流程、诱导安装不必要的扩展。skill-guardian 的思路，就是把 Skill 安装前的安全扫描、必要性评估、重复检测、质量判断做成一道前置闸门。它像 hook，也像 policy gate，本质上是在为“文本型扩展”建立供应链治理。

三、Claude Code 的 Skill System：产品化、可治理、适合团队落地

Claude Code 对 Skill 的处理，和 OpenCode / OMO 有同有异。相同点在于，它同样采用 markdown + YAML frontmatter 的格式，并支持 .claude/skills/ 目录下的自定义 Skill。不同点在于，Claude Code 更强调产品工作流中的 discoverability（可发现性）和治理性。

它提供了 /skills slash command 来做 Skill 的发现与管理。这个设计很重要，因为可扩展系统常见的问题不是“功能不存在”，而是“功能存在但用户不知道怎么找到”。文件系统目录适合高级用户，slash command 则更适合产品化入口。它把 Skill 从“你得知道目录结构才能用”变成“你在界面里就能看到和管理”。

Claude Code 的 Skill system 还有一个非常大的优势：它几乎可以说是整套扩展面里最安全的一层。为什么？因为它大多数时候只是结构化文本，而不是任意可执行代码。它当然可能有 prompt injection 风险、错误流程风险、模糊描述风险，但这些风险仍显著低于 Plugin 或外部可执行组件。对于企业环境来说，这个差异非常关键。

企业要的不是“绝对最强功能”，而是“足够强 + 能审 + 可治理”。Skill 恰好满足这个平衡点。它既能承载团队编码规范、发布流程、incident runbook、审核要求、合规步骤，也不会一下子把宿主暴露给大规模外部代码执行风险。这就是为什么 Claude Code 会把 Skill 作为一个非常重要的扩展层。

Claude Code 还有一个值得特别强调的点：Skill 与 memory system 的结合。Skill 可以引用 memory 条目，或者和 session memory、团队知识一起配合使用。这样一来，Skill 不再只是一个静态模板，而变成“稳定流程 + 动态事实”的组合体。

这里的逻辑是：流程通常比较稳定，比如“上线前要做什么”；但具体事实会变化，比如“当前仓库的部署地址是什么”“这个团队最近改了哪条规范”“最近一次事故复盘要求新增了什么检查项”。如果这些变化都硬写死在 Skill 里，Skill 会迅速过时。把动态信息放进 memory，让 Skill 去引用 memory，就能保持 Skill 本身简洁且长期有效。

这对企业使用尤其重要。因为企业真正需要的，不只是“会用一个工具”，而是“把组织标准可靠地传给 agent”。Team skills 就是很自然的载体：架构规范、code review 标准、文档模板、客服处理流程、上线审批路径，都可以通过 Skill 交给 agent。对管理者来说，这是一种可版本化、可审计、可共享、可推广的组织知识机制。

四、用“三类内容”框架重新理解 Skill

在第22章里，有一个非常有启发性的框架：Three Content Types。这个框架放在 Skill system 上看，特别清楚。

第一类是 Reference content，也就是“模型读来理解”的内容。比如风格指南、术语表、API 摘要、仓库约定、产品背景。这类内容的作用，是帮助 LLM 建立正确认知。

第二类是 Task content，也就是“模型照着执行”的内容。比如 runbook、步骤清单、上线流程、评审清单、事故处理 SOP。这里的 SOP 不是 CS 教材术语，而是企业流程管理里常见的 Standard Operating Procedure，中文通常说“标准操作流程”。Skill 经常同时承载这一类内容。

第三类是 Executable tools，也就是“机器直接执行”的内容。比如命令、脚本、API、MCP server。这类内容的特点是确定性强，执行主体是计算机，而不是模型自己“理解后自由发挥”。

大多数系统里的 Skill 主要覆盖前两类：Reference + Task。也就是说，Skill 本质上是“知识 + 流程”的载体。它先告诉模型应该理解什么，再告诉模型应该按什么步骤做。

而 OMO 很特别的一点，是 skill-embedded MCP 让 Skill 也开始触碰第三类。一个 Skill 既可以包含说明文档，又可以包含任务步骤，还可以打包调用能力。于是，Skill 在 OMO 里就不再只是“prompt file”，而逐渐演化为“理解、执行和外部能力之间的桥”。这也是为什么 OMO 的 Skill system 比传统 markdown skill 更值得研究。

五、Skill 与 MCP 的对比

这个表不是在说谁替代谁，而是在强调两者解决的问题不同。MCP 回答的是：“agent 能连到什么？” Skill 回答的是：“agent 在这里应该怎么做？” 前者偏 capability surface，后者偏 operational intelligence。

很多团队容易犯的错误，是把所有“agent 做不好”的问题都归因于“工具不够”。实际上，agent 很多时候并不是没工具，而是缺少正确使用工具的局部知识。也就是说，它缺的是 Skill，不一定缺的是 MCP。

六、设计启示：Skill 是最好的 80/20 扩展机制

从设计角度看，Skill 最大的价值是它非常符合 80/20 原则：用 20% 的复杂度，覆盖 80% 的定制需求。绝大多数团队真正需要的，不是先写 Plugin，不是先造 MCP server，而是先把自己的流程、约束、风格、注意事项、经验套路沉淀出来。Skill 正好适合做这件事。

所以，一个非常实用的扩展进阶路径应该是：

1. CLAUDE.md / 项目记忆：先放最基础、最常驻的项目背景；
2. Skills：把重复性流程、领域知识、组织规范结构化；
3. MCP：当确实需要稳定访问外部系统时，再引入能力层；
4. Plugins：只有当必须改宿主行为、生命周期或深层集成时，再走最重的扩展方式。

这个顺序非常关键，因为越往后，能力越强，但实现成本、治理成本、安全成本也越高。很多团队上来就想着“要不要做一个插件”，其实问题本质上只是“agent 老忘我们团队怎么发布”。那显然应该先写 Skill，而不是先写插件。

因此，对大多数团队来说，在考虑 MCP 或 Plugin 之前，Skill 往往已经足够解决问题。只要你的问题是“如何让 agent 更懂我们”，Skill 通常就是第一选择。只有当问题升级为“如何让 agent 连接一个外部系统并执行确定性操作”，MCP 才成为更自然的答案。只有当问题再升级为“如何重写宿主平台行为”，Plugin 才真正必要。

综合来看，OpenCode 展示了 Skill 作为轻量内容资产的优雅；OMO 展示了 Skill 如何被激活、被提醒、被合并、被绑定能力，从而变成动态编排单元；Claude Code 展示了 Skill 为什么特别适合商业产品和企业团队：它足够强，又足够安全，足够灵活，又足够可治理。

如果说 MCP 是 agent 世界的“通用接口层”，那 Skill 更像它的“本地作战手册、组织礼仪和现场流程知识库”。没有 MCP，agent 可能什么都接不上；但没有 Skill，agent 也可能什么都接上了，却依然在最关键的地方做错事。这就是为什么技能系统必须获得与 MCP 同等的分析地位。