TL;DR
- 2026 年的 OpenAI Plugins 不是 2023 年那批简单 API 包装器重新上线。一个新版 Plugin 可以同时包含 MCP server、Skills、身份验证、交互界面、文件查看器、事件和可分发的软件包。
- Plugin Extensions 可以在 ChatGPT 中提供侧栏入口、对话旁的交互面板、输入框入口和专用文件查看器。
- MCP Events 允许连接的服务在发生变化时主动触发工作，让插件不再只能等待用户发出提示。
- Plugin Creator、重做的审核流程、会话内推荐、Sites 和可分享主页共同组成了分发系统，而不只是开发接口。
- 能力面越广，风险面也越广。事件触发、连接数据、渲染界面和可复用 Skill 都必须配合最小权限和清晰的信任边界。
这不是 2023 年的 ChatGPT Plugins
OpenAI 沿用了旧名称，但产品已经变了。最早的 ChatGPT 插件大多是由 manifest 描述的远程 API：ChatGPT 选择接口、传递参数，再把结果写回对话。作为 OpenAI DevDay 2026 整套平台发布的一部分，新版平台把 Plugin 当成可运行在 ChatGPT 与 Codex 中的完整应用。它可以渲染自己的界面、说明工具该怎么用、验证用户身份、响应外部事件，并通过多个入口被发现。
因此，Plugin 是应用层概念，不是一种协议。MCP 提供工具与数据；Skills 提供工作方法；Extensions 提供界面；身份验证绑定用户和权限；打包、审核与目录分发把这些组件变成可安装产品。
它也不同于 Cordis 插件内核。Cordis 解决的是软件组件如何在运行时可逆地组合；OpenAI Plugins 解决的是产品如何进入 OpenAI 的用户环境并被使用。两者都叫插件，但职责完全不同。
一个 OpenAI Plugin 的五层结构
MCP server：能力与数据
MCP server 暴露动作和资源，例如搜索项目、创建工单、读取设计文件、更新记录或取得文档。它是宿主智能体与外部产品之间的机器接口。现有 MCP server 可以成为插件的起点，但它本身还不是完整的插件体验。
Skills：把工具用对的方法
工具 schema 只能说明函数接受哪些参数。Skill 可以进一步说明什么时候该调用、多个工具如何排序、先检查哪些文件和上下文，以及最终产物要达到什么标准。对价值来自整套流程、而非单个接口的产品，这一层尤其重要。
UI：用户真正工作的地方
Plugin Extensions 提供普通工具调用没有的界面。插件可以拥有固定侧栏入口，在对话旁打开交互面板，出现在输入框入口中，或为自己支持的文件类型注册查看器。用户一边与 ChatGPT 协作，一边直接操作真实界面。
身份与权限
插件可以验证用户并连接其账户。关键不是“连上即可”，而是让身份和授权保持可见：用户选择启用哪些插件，并批准每个插件得到哪些访问权限。权限范围应缩到完成任务所需的最小集合。
软件包与分发
打包和提交系统把 MCP server、可选 UI、Skills、元数据与身份验证配置组合起来。通过审核后，插件可以进入目录、在相关对话中被推荐、展示在创作者主页上，或被放进 Site。
Plugin Extensions 让 ChatGPT 成为应用宿主
侧栏改变了产品与对话的关系。插件不再完成一次工具调用就消失，而是可以拥有长期入口。交互面板可以展示设计稿、时间线、表格、媒体或垂直领域控制台；文件查看器则能保留专有格式的结构，不必把一切压平成抽取文本。
例如，设计插件可以让智能体在对话里讨论布局，同时在侧栏展示真实画布；数据产品可以呈现可筛选表格，由 ChatGPT 解释异常；文档工具可以使用自己的查看器保留用户关心的结构。对话变成协调面，而不是唯一界面。
OpenAI 表示 Plugin Extensions 面向所有计划开放，但不同客户端和网页能力可能分批上线，具体状态仍应以官方文档为准。
MCP Events 让连接的应用主动发起工作
传统工具调用从用户或智能体决定“现在调用工具”开始。MCP Events 把方向反过来：连接的服务可以在新任务、记录更新或请求到达时发出事件，触发 ChatGPT 中的自动化。
例如，项目看板新增任务后，插件可以读取任务链接的文档，并在用户离线时起草执行计划。事件不必携带所有数据；它只负责通知“发生了变化”，后续再由已经获批的工具取得所需上下文。
这不同于定时任务。定时任务因为时间到了而运行；MCP Event 因外部系统发生变化而运行。它也不同于 Computer Use：插件通过声明好的接口和权限工作，而不是在任意界面上模拟点击。目前官方文档要求 ChatGPT 的事件能力使用 MCP 2.0，对应协议版本 2026-07-28。
风险同样直接：错误或恶意事件可能在无人查看时启动工作。生产插件需要验证事件、保证幂等、限制频率、保留审计记录，并在不可逆动作前要求人工批准。
创建、审核与发现
DevDay 发布的 Plugin Creator 用于协助构建插件；新的提交系统可以跟踪审核状态并给出更清楚的反馈，既有插件更新也更简单。发布后，插件既能出现在目录里，也能在相关对话中被推荐。
分发入口还包括：
- Sites：工作区成员使用同一个应用，但各自连接数据和权限；
- Shareable Profiles：集中展示创作者的 Sites 与 Plugins；
- Sign in with ChatGPT：减少账号摩擦，并让部分合作工具使用符合条件的 ChatGPT 计划额度；
- 会话内推荐：在用户真正需要某项能力时出现，而不是等用户先逛应用商店。
这套组合暴露了 OpenAI 的平台路线：它不仅规定工具如何连接，还控制工具在哪里运行、如何被发现、身份如何建立，以及部分模型用量如何结算。
Plugins、MCP、Skills、Connectors 与 Computer Use
| 名称 | 本质 | 适合场景 |
|---|---|---|
| MCP | 暴露工具、资源、提示与事件的协议 | 产品需要标准智能体接口 |
| Plugin | 面向 ChatGPT 与 Codex 的可安装、带权限完整体验 | 用户需要能力、界面、工作方法与分发入口 |
| Skill | 执行某类工作的说明和资源 | 正确使用工具依赖领域流程和产物标准 |
| Connector | 连接某项服务或具体账户 | 宿主需要获权访问外部数据或动作 |
| Computer Use | 通过软件界面直接操作 | 没有合适 API 或 MCP 接口 |
这些层可以同时存在。一个 Plugin 可以连接账户、暴露 MCP 工具、附带 Skill、显示交互面板，并在某个没有接口的步骤使用 Computer Use。把它们都叫“插件”会掩盖架构与安全边界。
谁现在值得构建 Plugin
最适合的产品已经拥有无法压缩成一次 API 返回值的体验。设计工具、分析产品、文档系统、项目平台和垂直 SaaS 都可能受益于长期界面与工作流知识；有专有文件格式的产品可以使用 Viewer；由状态变化驱动的产品可以使用 MCP Events。
如果用户只需要少量可靠动作，而且对话已经是足够好的界面，一个普通 MCP server 可能就够了。完整 Plugin 会增加审核、UI、权限、运维和平台依赖成本。只有丰富体验真正改变工作方式时，才值得承担这些成本。
体验扩大，安全边界也随之扩大
每个新界面都带来新责任。工具要遵循最小权限；交互面板要安全渲染并清楚标记动作状态；文件查看器必须把内容当成不可信输入；Skill 不能把宽泛指令或权限偷偷带进软件包；事件需要验证和防重放；身份验证必须避免把密钥带进提示词和日志。
用户批准安装是必要条件，但不是永久安全保证。插件之后仍会收到新数据，工具可能发生变化，事件也可能在没有活跃对话时启动流程。高影响动作应当可见、尽量可撤销，并能追溯到明确的审计记录。
结论
OpenAI Plugins 正在成为 ChatGPT 与 Codex 的应用层。MCP 提供标准能力接口，Skills 让能力可以被正确使用，Extensions 提供真实界面，Events 允许主动工作，审核与发现系统负责分发。
它比 2023 年的插件系统野心得多，也更难做好。机会是在用户已经使用 AI 的地方放进一个真正可工作的产品；代价是接受宿主平台、审核规则和更大的安全面。值得构建的 Plugin，应当确实需要这些层共同发挥作用，而不是把一个 API 换个名字包装起来。
本文依据 OpenAI Plugins 文档、Plugin Extensions、MCP Events与 OpenAI DevDay 2026 官方复盘完成核验。
https://floatboat.ai/zh/blog/openai-plugins-explained