Claude Code、Codex、OpenCode 对 Skills 的支持现状对比

如果把 AGENTS.md、CLAUDE.md 看作“项目说明书”，那 skills 更像“可复用的专用工具箱”。

它们解决的是两类问题：

• 指令文件解决“这个项目有哪些约定”
• skills 解决“某类任务怎样稳定重复执行”

这篇文章只聚焦一个问题：Claude Code、Codex、OpenCode 到底怎么支持 skills，它们分别放在哪，AI 又是怎么发现这些 skill 的。

如果你想先看三款工具在指令文件和权限模型上的整体差异，可以先读这两篇：

• AI 编程 CLI 工具怎么选：Claude Code、Codex CLI 与 OpenCode 对比
• AI 编程 CLI 的指令文件怎么生效：CLAUDE.md、AGENTS.md 与 OpenCode 对比

写在前面

先说一个容易混淆的点：三家对 skills 的支持程度并不对称。

• Claude Code：已经把 skills 做成了完整的本地能力系统，目录、自动发现、嵌套发现、附加目录、权限限制都有文档。
• OpenCode：同样有明确的 skill 机制，而且原生 skill 工具会把可用 skills 暴露给 agent。
• Codex：OpenAI 已经明确在产品层面支持 skills，也有官方 openai/skills 仓库和 $skill-installer；但就我在 2026 年 3 月 21 日查到的公开资料看，Codex 的本地技能目录与发现规则，没有像 Claude Code 和 OpenCode 那样集中写成一篇单独文档。因此这部分需要区分“官方公开信息”和“本机实测行为”。

这篇文章会把两类信息明确分开写，避免把实测结论误写成官方规范。

先说结论

如果你只想要结论，可以先记住下面这三点：

Claude Code

• 有完整、明确、文档化的本地 skills 机制。
• 最核心目录是 ~/.claude/skills/ 和项目内 .claude/skills/。
• Claude 会根据 skill 的 description 自动决定何时加载，也可以手动用 /skill-name 调用。

OpenCode

• 有完整、明确、文档化的 skills 机制，而且是原生能力。
• 最核心目录是 ~/.config/opencode/skills/ 和项目内 .opencode/skills/。
• 它还兼容 .claude/skills/ 与 .agents/skills/，这点对跨工具复用很有价值。

Codex

• OpenAI 已经明确表示 Codex 支持 skills，且有官方 skill 仓库和安装器。
• 就当前我查到的公开材料，最明确的是：系统 skill 会内置安装，其他 skill 可通过 $skill-installer 安装，安装后通常要重启 Codex 才会被识别。
• 就我当前本机环境的实测，Codex 的用户级 skill 目录是 $CODEX_HOME/skills，未设置时通常就是 ~/.codex/skills。
• 但项目级目录如何扫描、是否像 Claude/OpenCode 那样有清晰的向上发现规则，公开资料不如前两者明确。

Claude Code：支持最完整

Skills 放在哪里

根据 Anthropic 当前文档，Claude Code 的 skill 位置分为三类：

这意味着 Claude Code 的思路很清楚：个人 skill 和项目 skill 是并列的一等公民。

Claude 怎么发现已安装的 skills

Claude Code 的发现机制也很完整：

• skill 的 description 会帮助 Claude 判断什么时候自动加载
• 用户也可以直接通过 /skill-name 手动触发
• 如果 skill 在子目录下，Claude Code 还会自动发现嵌套的 .claude/skills/
• 如果你用 --add-dir 增加工作目录，那个目录里的 .claude/skills/ 也会自动加载

这几点组合起来，意味着 Claude Code 的 skill 系统不只是“能放文件”，而是已经形成了完整的目录层级 + 自动触发 + 手动调用模型。

Claude Code 还有一个容易忽略的变化

Anthropic 现在把自定义 slash commands 和 skills 放到了同一条演进路径上。官方文档明确提到：

• 旧的 .claude/commands/ 仍然能工作
• 但推荐优先用 .claude/skills/
• 如果 command 和 skill 同名，skill 优先

这其实很关键，因为它意味着 Claude Code 已经不再把 skills 仅仅看作“一个补充特性”，而是把它当成了统一的可扩展行为层。

OpenCode：原生技能系统最开放

Skills 放在哪里

OpenCode 的官方 skills 文档把目录写得非常明确，而且比 Claude Code 更开放：

这代表 OpenCode 的一个明显特点：它既支持自己的目录规范，也愿意兼容 Claude 和 agent-compatible 的目录结构。

OpenCode 怎么发现已安装的 skills

OpenCode 的官方说明同样很清楚：

• 对项目内目录，它会从当前工作目录向上走，直到 git worktree
• 途中加载 .opencode/skills/，以及兼容目录 .claude/skills/、.agents/skills/
• 同时也会加载全局目录里的 skill

这套机制的好处是，项目内 skill 真正可以做成分层发现，而不仅仅是一个固定全局目录。

OpenCode 怎么把 skills 暴露给 agent

OpenCode 文档里还有一个很值得注意的点：它会把可用 skills 列进原生 skill 工具的描述里，也就是 agent 天然知道“现在有哪些 skill 可用”。

从文档给出的示意来看，OpenCode 会在工具描述里暴露类似：

1
2
3
4
5
6

<available_skills>
  <skill>
    <name>git-release</name>
    <description>Create consistent releases and changelogs</description>
  </skill>
</available_skills>

这和 Claude Code 的 slash 风格不一样，但对 agent 来说反而更直接：它不需要靠用户记忆某个命令名，而是可以在工具上下文里直接看到技能列表。

Codex：已经支持，但目录口径要分开看

OpenAI 官方已经明确 Codex 支持 skills

这一点不需要猜。

OpenAI 在 2026 年 2 月 2 日发布的 Introducing the Codex app 文章里已经明确写到：

• Codex 支持 skills
• skills 可以打包 instructions、resources、scripts
• Codex app 内置了创建和管理 skill 的界面
• 你可以显式要求 Codex 使用某个 skill，也可以让它按任务自动使用
• 新建的 skill 可以在 app、CLI、IDE extension 等不同界面复用

换句话说，产品层面“Codex 是否支持 skills”这个问题，答案已经是明确的“支持”。

OpenAI 官方 skill 仓库也已经成立

OpenAI 还有一个公开仓库：openai/skills。

它说明了几件很关键的事：

• 这是 Codex 的官方 skill catalog
• .system 里的 skill 会自动安装
• 其他 curated 或 experimental skill 可以通过 $skill-installer 安装
• 安装后通常要重启 Codex 才能识别新 skill

这说明 Codex 对 skill 的支持并不是停留在营销文案，而是已经形成了：

• 官方仓库
• 官方安装器
• 官方内置系统 skill

Codex 的本地目录怎么理解

这部分要谨慎一点。

就我当前这台机器的实际环境来说：

• 当前 Codex 可自动发现的用户级 skill 目录是 ~/.codex/skills/
• 如果设置了 CODEX_HOME，则对应为 $CODEX_HOME/skills/

这和 Codex 内置 skill 创建/安装工具的默认路径是一致的。

但需要强调的是：

• 我在本轮能查到的 OpenAI 公开网页里，没有像 Claude Code 和 OpenCode 那样，把“项目级 skill 放在哪、如何向上扫描发现”单独写清楚
• 因此，~/.codex/skills 这一点我愿意写成“本机实测 + 官方仓库工具链默认路径一致”
• 但如果要写成“Codex 公共文档明确规定了完整的项目级技能目录扫描规则”，那就不严谨了

如果你想进一步理解为什么很多 Codex 本地 skill 最后会落到 ~/.codex/skills/，以及 CODEX_HOME 一旦改变会连配置、认证、历史和状态一起迁移，可以继续看这篇专题文：

• Codex 的 CODEX_HOME 是什么？会影响哪些目录和行为

那 Codex 怎么发现已安装的 skills

基于当前公开信息与本机行为，可以把 Codex 的发现逻辑理解成两层：

第一层：安装层

• 系统 skill：最新版本 Codex 自动带上
• 其他 skill：用 $skill-installer 安装
• 安装后通常要重启 Codex，官方仓库 README 明确写了这一点

第二层：会话层

• 新会话启动后，Codex 会把可用 skill 纳入当前环境
• 在我当前环境里，已安装 skill 会出现在会话的可用技能列表中，并可按名称触发

因此，Codex 当前更像是：

• 产品上已经支持 skills
• 用户级 skill 目录已经可用
• 但公开文档对本地目录发现规则，没有 Claude/OpenCode 那么完整和集中

三者最大的差异，不在“有没有 skills”，而在“本地目录机制是否清楚”

如果把三家的本地技能支持放在同一张表里，差异会更直观：

如果你最关心“项目里能不能版本控制一套 skills”

这里的答案也不一样：

• Claude Code：最直接，提交 .claude/skills/ 即可
• OpenCode：也很直接，甚至还能顺带兼容 .claude/skills/
• Codex：当前更适合两种做法
  • 用户级放 ~/.codex/skills/
  • 项目里版本控制一份，再通过软链接或同步脚本接到 ~/.codex/skills/

也正因为这个差异，如果你的目标是“一套 SKILL.md 尽量跨工具复用”，OpenCode 和 Claude Code 目前更顺手，而 Codex 更像是“产品能力已经成熟，但本地目录实践还需要自己整理工程化习惯”。

我的建议

如果你只是想在一个工具里稳定使用 skills：

• 只用 Claude Code：直接围绕 .claude/skills/ 建
• 只用 OpenCode：优先 .opencode/skills/，需要兼容时再映射到 .claude/skills/
• 只用 Codex：优先维护 ~/.codex/skills/，项目内如需版本控制，再做软链接

如果你想让一套 skill 尽量复用到三者：

我更建议采用下面这个思路：

1. skill 内容统一使用 SKILL.md
2. 项目里保留一份“源技能目录”
3. Claude Code 和 OpenCode 直接使用项目级目录
4. Codex 通过 ~/.codex/skills/ 软链接到项目里的 skill

这样做的好处是：

• 项目内可版本控制
• Claude Code 能直接发现
• OpenCode 能直接发现
• Codex 也能继续自动识别用户级 skill

这比为三家各写一套独立技能目录要干净得多。

总结

如果只看“有没有 skills”，三家的答案现在都已经不是“没有”了。

真正拉开差距的地方，是：

• Claude Code 把本地 skills 系统做得最完整，目录和触发机制最清楚
• OpenCode 在本地 skill 体系上最开放，兼容性最好
• Codex 在产品层面已经明确支持 skills，也有官方仓库和安装器，但本地目录与发现规则的公开文档化程度，目前不如前两者集中

如果你的重点是“写一套技能，尽量多工具复用”，OpenCode 和 Claude Code 目前更顺手；如果你的重点是“把 Codex 也纳入同一套技能体系”，最好提前接受一件事：Codex 这边更适合用用户级目录 + 项目内版本控制 + 软链接这种工程化方案。

本文基于 2026 年 3 月 21 日查到的公开资料与本机环境实测整理。工具迭代很快，尤其是 Codex，后续很可能继续补齐更正式的本地 skills 文档。

参考资料：

• Anthropic Claude Code Docs: Extend Claude with skills
• Anthropic Claude Code Docs: Create custom subagents
• Anthropic Claude Code Docs: Settings
• OpenCode Docs: Agent Skills
• OpenAI: Introducing the Codex app
• OpenAI GitHub: openai/skills