Claude Skills API vs Codex Skills：云端制品还是仓库契约？

同样叫 Skill，并不代表打包、Runtime 与信任边界相同。

Claude 和 Codex 都用 Skill 表示按需加载的可复用操作知识，但同名背后是不同控制面。Claude Skills API 把 Skill 作为上传、版本化并在 Anthropic Sandbox 执行的平台制品；Codex Skill 通常是与代码一起维护的仓库目录或已安装 Plugin。

先说结论

• 两者都用指令和配套资源实现渐进式加载。
• Claude Skill 通过 API 上传并绑定请求；Codex Skill 多在源码仓库或本地插件中。
• Claude 减少托管工作，Codex 让代码审查与仓库耦合更直接。
• Markdown 并不天然安全，脚本和外部工具仍具有真实权限。
• 最稳妥的是保留一个源码真相，再构建各平台需要的发布制品。

相同抽象，不同治理位置

Anthropic 的官方发布把 Skill 定义为指令、脚本与模板包，通过 API 上传和版本化。Codex 则使用 SKILL.md 作为入口，可带 scripts、references 与 assets。

问题	Claude Skills API	Codex Skill
主要位置	平台对象，最好由源码构建	仓库、本地或 Plugin 目录
使用方式	绑定 API 请求后按需加载	依据描述和任务触发
执行位置	Claude 平台代码 Sandbox	当前 Codex 环境与权限策略
版本审查	平台版本 + 团队源码流程	Git diff + 包/Plugin 版本
最适合	应用级重复工作流	仓库感知工程与运营流程

这不是能力排名，而是治理放在哪里的选择。

仓库原生的优势和代价

Codex 文档展示仓库与 Package 一侧的模型，与 Anthropic 平台 Artifact 形成对照。

Skill 可以和代码在同一个 PR 中变化。相对路径能测试，评审者看得到差异，旧 commit 也保留当时适用的操作规则。对构建、发布和内容流程尤其合适。

代价是环境差异：某些命令、凭证或路径可能只在一台机器存在，安装和更新必须规范化。

API 托管的优势和代价

应用可以把固定 Skill 版本绑定到大量请求，不必自建代码执行服务，灰度和回滚也更集中。

风险是源码漂移：评审通过的是一个 Git commit，生产使用的却是无法对应的手工平台对象。应由 CI 发布、记录 version ID，并禁止生产环境手改。

推荐的混合模式

claims-skill/
  SKILL.md
  scripts/
  references/
  tests/
  manifest.json

CI 校验路径和 frontmatter，用 Fixture 测试脚本，构建确定性归档，上传后把平台 version ID 写进 release manifest。Codex 使用仓库形态，应用使用 Claude 制品，但治理来源只有一个。

安全评审不能止于 SKILL.md

所有脚本、依赖、MCP Server、网络目标和写入路径都要审查。看似无害的指令可能调用下载可变代码的脚本；反过来，Sandbox 也无法阻止一个已获授权的 Skill 把错误客户的文件发出去。

测试应包含提示注入文档、带误导命令的仓库、缺失凭证、大文件和中断工具，预期拒绝和升级行为也应写进 Fixture。

结论

这里的发布纪律也可对照Google 如何规模化构建和测试 Agent Skills。Skill 一旦调用外部工具，还应明确生产级 MCP 执行边界。

流程必须随代码一起变化时，仓库原生 Skill 更自然；应用需要集中版本与规模化执行时，API 托管更省事。严肃工作流不必二选一：维护一个源码 Skill，通过受审发布流程生成平台制品。

真正可移植的单位不是 Markdown，而是指令、资源、测试、权限声明与来源证明的整体。

FAQ

同一 Skill 能原样运行在 Claude 和 Codex 吗？

纯指令可能接近，但脚本、metadata、路径、工具与运行时假设仍需兼容测试。

哪一种更容易审计？

Git 方便源码评审，平台版本方便识别部署。最佳方案是在 release manifest 中绑定两者。

Skill 中能放凭证吗？

不能。只声明需要的秘密名称，由 Host 在运行时注入最小权限凭证。