OpenAI Plugins 是什么？Codex 插件体系全解

OpenAI Plugins 是 OpenAI 官方维护的 Codex 插件示例仓库（github.com/openai/plugins），它把「什么是 Codex 插件、插件由哪些文件组成、插件怎么被发现和安装」标准化，并附上一批可直接安装的官方插件。截至 2026 年 9 月中旬，仓库约 6.9k star、900 fork，最近一次提交在 9 月 11 日，仍在活跃更新。

OpenAI Plugins 是什么：Codex 的官方插件仓库

仓库的自我定义很简单：一份经过官方整理的 Codex 插件示例合集（a curated collection of Codex plugin examples）。每个插件住在 plugins/ 目录下的独立文件夹里，必须带一个名为 .codex-plugin/plugin.json 的清单文件，其余能力按需附加。把它理解成 Codex 生态的官方货架最贴切：既陈列了示范商品，也公示了上架标准。

对普通用户来说，它的价值是能用官方认证的方式扩展 Codex 的能力；对开发者来说，它是给 Codex 做插件的规范文档加参考实现。

先澄清：它不是 2023 年那套 ChatGPT 插件

搜 OpenAI plugins 这个词，很多人会想起 2023 年 ChatGPT 那套联网插件，两者已经完全不是一回事。旧插件体系面向聊天产品，后来被 GPTs 和工具调用机制取代并停用；现在的 OpenAI Plugins 面向的是 Codex 编程智能体，插件形态也从网页清单变成了代码仓库里的目录结构。搜资料时认准 GitHub 上的 openai 官方组织，别被旧教程带偏。

一个插件里有什么：plugin.json 和它的搭档们

按仓库 README 的定义，一个完整的插件长这样：

1. .codex-plugin/plugin.json：必需的清单文件，声明插件的元信息，是插件的身份证。
2. skills/：技能目录，给 Codex 注入领域知识和操作流程。
3. .mcp.json：连接 MCP 服务器，让插件能调用外部工具。
4. agents/、commands/、hooks.json：可选的子智能体、自定义命令和钩子。
5. .app.json 与 assets/：应用配置和静态资源。

以官方最完整的示例之一 figma 插件为例，它的清单文件能直接看到插件是怎么标注自己的：

{
  "name": "figma",
  "version": "2.0.20",
  "description": "Figma workflows for design implementation, Code Connect templates, and design system rule generation.",
  "skills": "./skills/",
  "apps": "./.app.json"
}

可以看出 OpenAI 的设计思路：插件是一个能力包的容器，把 Skills、MCP、命令这些 Codex 已有的扩展点打包成一个可分发的整体。清单里的 name、version、description 是基本信息，skills 指向技能目录，apps 指向应用配置，interface 段再负责在插件市场上的展示（显示名、分类、截图、品牌色）。

官方示例插件都有谁：从 Figma 到 build-ios-apps

仓库 README 点名的高价值示例是这几个：

另外几个覆盖更多平台和场景：

想做 Codex 插件开发，官方建议的路径就是先读 figma 或 notion 这两个复杂示例，反推自己插件的结构。Codex 本身的安装和定价，可以看我们的 Codex 完整使用指南。

marketplace.json：插件怎么被发现和分发

仓库还有一个容易被忽略的关键设计：默认市场文件放在 .agents/plugins/marketplace.json，指向标准的 plugins 目录，这就是 Codex 的插件货架来源；用 API key 登录的用户则走单独的 api_marketplace.json 市场。官方市场的名字叫 openai-curated，展示名是 Codex official，结构长这样：

{
  "name": "openai-curated",
  "interface": { "displayName": "Codex official" },
  "plugins": [
    {
      "name": "figma",
      "source": { "source": "local", "path": "./plugins/figma" },
      "policy": { "installation": "AVAILABLE", "authentication": "ON_INSTALL" },
      "category": "Creativity"
    }
  ]
}

从这份清单能读出三条分发规则。第一，source 支持三种来源：local（仓库内目录）、url（整包 Git 仓库）、git-subdir（只取仓库里的某个子目录），第三方插件因此可以挂在外部仓库上。第二，policy.authentication 标的是认证时机，ON_INSTALL 表示装的时候就要求授权（如 Gmail、Slack），ON_USE 表示第一次用某个能力时才授权（如 build-web-apps、codex-security）。第三，不少条目带 products: ["CODEX"]，说明它只在 Codex 这个产品端出现。

上面这份列表会随仓库提交持续变化，想知道此刻官方货架上有什么，直接翻仓库里的 marketplace.json 最准。

插件装了却看不到：三个高频坑

插件生态还新，用户最常撞上的不是「功能不好用」，而是「装完没反应」。按仓库结构，排查顺序如下：

1. 清单路径放错：必须是 .codex-plugin/plugin.json，放在插件根目录的 plugin.json 不会被识别，这是第三方插件最常见的失败原因。
2. 市场来源搞混：账号登录用户读 .agents/plugins/marketplace.json，API key 登录用户读 api_marketplace.json，两条分发路径独立，装错市场自然找不到插件。
3. 认证没走完：ON_INSTALL 的插件装好后还需要完成一次账号授权（如登录 Gmail、Slack），没授权就一直不可用。
4. 插件里没有 skills：插件只是容器，真正干活的能力来自 skills/、MCP 或命令，一个只有清单的插件装上后不会带来任何新本事。

插件安装后的目录与清单检查思路，和我们之前写的 Codex Skill 安装排错指南 是相通的，核心都是先确认文件落位，再确认加载来源。

和 Agent Skills、MCP 怎么分工

三者经常一起出现，分工是：MCP 负责连接外部工具和数据源，Agent Skills 负责给模型注入单项专业能力，插件则是打包分发这两者的最外层容器，还可以额外携带命令、钩子和子智能体。换句话说，插件是 Codex 生态里能力扩展的分销单位。想深入理解 Skills 和 MCP 的取舍，可以看我们的 Skills 与 MCP 的对比分析 和 AI Skill 的概念解读。

动手建议：先去仓库把 figma 插件的目录翻开看一遍，对照本文第二节的清单逐个认文件，比读十篇二手教程都管用。

最后更新于 2026 年 9 月，作者 AI345。