一句话核心：OpenAI 把 Skills 变成了平台原生能力——开发者文档写明：技能是「一个包含 SKILL.md 的目录」，上传时以「带版本的技能包（versioned bundles）」形式管理，并明确一句关键声明：「Skills are compatible with the open Agent Skills standard」。这把 SKILL.md 从某一家的约定，变成了跨厂商的通用层：同一份技能，可以在不同客户端与 API 之间流转。
为什么这条对你重要
本专区此前两篇分别讲了「怎么写」（SKILL.md 逐字段规范）与「怎么验证有没有用」（plugin eval 与 Δ 机制）。这条补上的是第三块：技能在哪里被分发与运行。
以前 SKILL.md 主要是单一客户端的约定；现在一个主流模型厂商在自己的 API 与 Agent 沙箱里原生接入了同一套规范，并在文档里显式点出开放的 Agent Skills 标准。对写技能的人，这意味着投入产出比变化：一份符合规范的技能，不再只服务一个客户端。
官方文档给出的做法（均为一手）
- 技能是什么：一个目录，含
SKILL.md（front matter + 指令），可附带支持文件；官方示例是review-pr/目录下SKILL.md+references/。 - 上传即版本化：上传的技能以带版本的 bundle 存在；文档给出两种上传方式——目录 multipart（
POST /v1/skills，逐个文件带filename）或 zip 上传。 - 两种使用路径：
- Responses API 的 shell 工具：在
shell工具的environment里用skills: [{ type: "skill_reference", skill_id: "..." }]引用，并可指定version（例如version: "2"）； - Agents API 沙箱：会话会从目录中发现技能，目录布局为
/workspace/capabilities/<领域>/<技能名>/SKILL.md。
- Responses API 的 shell 工具：在
- 本地执行模式：Responses API 支持技能的两种执行形态——本地执行与容器内执行；要在自己机器上跑代码，用
shell工具的 local execution 模式。 - 模型在发现阶段只看两行：官方明确「技能发现时，模型只能看到技能的
name与description」，并给出写作建议：要同时说明「做什么」和「何时使用」——这与开放式规范的要求一致。 - OpenAI 在开放规范之上加了扩展：ChatGPT 侧构建文档给出可选元数据，包括
interface（display_name、short_description、图标、品牌色、default_prompt）、policy（allow_implicit_invocation，即是否允许模型隐式调用）、以及dependencies——其中可以把 MCP 服务器声明为依赖（含transport与url）。
三个值得单独拎出来的变化
| 变化 | 具体表现 | 对写技能的人意味着什么 |
|---|---|---|
| 规范跨厂商 | 官方文档显式声明兼容开放 Agent Skills 标准 | 同一份 SKILL.md 面向多个客户端与 API，维护成本下降 |
| 技能成为「制品」 | 上传为版本化 bundle，引用时可指定 version |
技能需要像代码一样做版本管理与回滚，而不只是「拷一个目录过去」 |
| 与 MCP 的分工被写清 | 技能是指令层，MCP 提供数据与动作；dependencies.tools 可声明 MCP 依赖 |
选型时不必二选一——技能负责「怎么做」，MCP 负责「能碰到什么」 |
辩证评估
- 价值：这是技能生态从「单一厂商规范」走向「通用层」的一个明确信号。对做企业级技能分发的团队，跨客户端兼容意味着一次编写、多处运行，也让技能库的价值可被复用。
- 反向视角：其一，厂商扩展字段（
interface、policy、dependencies）是专有的，跨厂商并不完全对等——核心字段能通用，展示与策略部分大概率要按平台各写一份；其二，官方文档页没有标注发布日期，本轮无法确认这项能力的上线时间，因此不能把时间口径写成具体某日；其三，文档未说明服务端是否对上传技能做安全校验或签名——这与同期披露的技能/插件供应链漏洞（技能被劫持、版本钉扎被绕过）形成对照，技能一旦成为可执行制品，治理要求会跟着上来；其四，版本管理的细节（如何回滚、如何废弃旧版本）尚未在文档中展开。 - 一个务实的判断：把技能当「可复用的指令 + 可执行文件」来治理，比把它当作配置文件更贴近现实——因为在 API 侧它已经是有 ID、有版本、能被引用的制品了。
已知 vs 待验证
官方已证实（OpenAI 开发者文档与 ChatGPT 构建文档）：技能 = 含 SKILL.md 的目录；上传采用版本化 bundle；目录上传与 zip 两种方式；通过 skill_reference（可选 version）在 shell 工具中使用；Agents API 从目录发现技能及其布局；发现阶段仅暴露 name 与 description；interface、policy、dependencies（可声明 MCP 依赖）等扩展元数据；兼容开放 Agent Skills 标准的声明。
待验证：该能力的发布日期（文档页未标注）；上传技能是否有服务端校验/签名机制；版本回滚与废弃策略；是否已有第三方对其运行时隔离与安全边界的独立评测。
给读者的建议
- 正在写技能的多客户端团队：把核心逻辑与描述严格按开放规范写，把展示/策略类字段（图标、品牌色、隐式调用策略）单独放在厂商扩展区，避免换平台时重写。
- 把技能接入生产的团队：既然技能已经是有 ID、有版本、可被引用的制品，就按制品管理它——记录版本、保留回滚路径、在变更时走审阅。
- 评估「技能还是 MCP」的团队：按官方分工来切——把「怎么做」放进技能，把「能碰到什么」交给 MCP，并在技能里显式声明 MCP 依赖。
- 安全与合规视角：目前文档未提上传技能的安全校验，建议在内部流程里自行补上代码审阅与来源核验。
来源
官方来源
- OpenAI 开发者文档《Skills》（技能定义、版本化上传、shell 工具与 Agents API 用法）：Skills | OpenAI API
- OpenAI Cookbook《Skills in OpenAI API》（上传、管理与挂载可复用技能）：Skills in OpenAI API
- ChatGPT 构建文档《Build skills》（
interface／policy／dependencies扩展元数据）：https://learn.chatgpt.com/docs/build-skills - Agent Skills 开放规范：Specification - Agent Skills