OpenAI 开源 MCP Extensions,开发者可以把应用直接放进 ChatGPT 了

从 Sidebar、文件 Viewer 到 Composer mention，OpenAI 刚开源的 MCP Extensions，正在把 MCP App 变成 ChatGPT 里真正可以打开和使用的应用。

点开 openai/mcp-extensions 这个仓库时，我以为是又一个 SDK，结果是给 MCP App 装进 ChatGPT 原生界面的一整套规范。翻到 File Viewer 和 Composer mention 那两节，才意识到它想补的那个缺口——AI 产品过去被调用一次就消失，用户之后再也找不到它。

这里有三个容易混在一起的概念。MCP 是开放协议，定义 Server 和客户端怎么交换工具、数据和上下文，它不管界面入口，也不归任何厂商。MCP App 建在这套协议之上，是一层可移植 UI，工具和界面绑在一起，渲染在宿主 iframe 里。OpenAI MCP Extensions 是 ChatGPT 专属的扩展层，不碰 MCP 本体，只把已有 App 接到 ChatGPT 的 Sidebar、对话面板、文件 Viewer、设置页和 Composer，再补几项标准没覆盖的能力。MCP 本身没变，是 ChatGPT 这一端的宿主集成变深了。

从 Sidebar 开一个全屏工作台

以前 MCP 产品只能等 prompt 把它喊出来，用完就找不回。现在 App 能注册一个 global entrypoint，从 ChatGPT 左侧 Sidebar 直接打开，桌面端会得到一个带 composer 的全屏标签页，等于给每个产品发了一把前门钥匙。

图：MCP App 从 Sidebar 打开的全局入口。

Sidebar 之外还有个 Thread entrypoint，在某个对话里把 App 打开成新的内容标签页，和对话并排，每个对话各自开一个实例、状态互不串。

文件归你接管，输入框里能 @

文件在 ChatGPT 里一直共用一个默认查看器。Extensions 让插件声明 .stl、.ipynb 这类扩展名，用户一打开，就由你提供的自定义 Viewer/Editor 接管，通过扩展后的 MCP Resource API 读文件、订阅更新、并在授权范围内写回。怎么渲染、编辑、保存，都交给你。

图：注册了扩展名的文件由自定义 Viewer 接管。

要留意，文件打开、Viewer/Editor 和文件资源读写目前都落在 Desktop；接管发生在“用户打开该类型文件”时，官方没承诺“拖一个 .mp4 进来就自动打开”。

同一套思路用在输入框上，就是 Composer at-mention：插件把人员、文件、素材做成可搜索的资源列表，用户敲 @ 逐项引用，工具返回 ResourceLink。要引用某个素材，直接 @ 出来，Agent 拿到的是精确引用，不用靠一句含糊描述去猜。

图：在 Composer 输入框里通过 at-mention 引用 MCP App 内的资源。

把它和前面的 Viewer 连起来看，一条链很顺：打开受支持的文件进自定义 Viewer，再在 Composer 里 @ 上这个素材给 Agent 当上下文。只是 Composer mention 目前仅 Desktop。

参数收集不靠猜，还有一道窄门

以前让产品填参数，常要模型边猜边聊。这里给了两三样组装件：结构化设置让 MCP App 在插件详情页登记设置项，ChatGPT 用原生控件渲染，Server 提供读取和更新工具、自己持久化；富表单支持枚举、字符串、数值，oneOf 还能带 x-openai-thumbnail，字段有缩略图时选项渲染成图片 UI，也支持 resource picker 直接选插件资源。

图：富表单里带缩略图的选项选择器。

那个图片选择器，准确说是“带缩略图的可视化选项选择器”，不是通用图片/视频上传器。富表单目前主要支持 Desktop 和 Web。

两道容易忽略的门再提一下。一是 Deep Link，能直跳到 App 的具体页面或条目：桌面 codex://plugins/...，移动端 chatgpt://...，Web 用 https://chatgpt.com/plugins/...，适合跨入口跳转；Android 目前还没有直链。二是文件的受控写入，这个权限都必须讲清楚：标准 resources/read 由 ChatGPT 截获，扩展的 openai/resources/write 只允许写当前文件入口交给 App 的那个 URI，且 resources/read 返回必须带 writable: true。它写不了用户的任意本地文件，只能写宿主授权边界内当前打开的那份，而且集中在 Desktop。

把这些拼成一个视频 AI 工作台

把所有能力叠起来，一个视频 AI 产品的形态就出来了：从 Sidebar 打开工作台 → 打开已注册类型的视频进自定义 Viewer → Composer 里 @ 选素材 → 富表单里选模型、时长、分辨率 → Agent 调 MCP Server 的后端执行生成 → 必要时把结果存回可写文件。它有入口、有界面，能被引用，也能保存结果。和只暴露 generate_video、upscale 工具相比，这已经更像一个完整产品。

这只是“顺着规范能设计出来的形态”。OpenAI 并没有提供现成视频工作台，也没有验证过 .mp4 自动接管。MCP Server 始终握着实时数据、认证和受控动作，工具得先在没有 UI 时能干活，可视化那层只是补一层。

我的架构解码，不是官方文档

把这套拆开看，我更习惯分四层：Skill 告诉 Agent 怎么干活；MCP Server 提供数据、工具和受控动作；MCP App 提供可移植 UI；OpenAI MCP Extensions 再把 App 接进 ChatGPT 的 Sidebar、文件、设置和 Composer。这是我自己的拆法，官方文档里没有这个四层命名。真要说交付，外面还有一层 Plugin，把 skills、MCP server 配置、UI 集成和资源包在一起，MCP Extensions 并不取代 Plugin。

落地还在逐平台进行。所以写“已经支持”时，得把边界一起写明：Composer @、文件 Viewer/Editor 和文件写入主要集中在 Desktop，富表单主要是 Desktop/Web，Deep Link 缺 Android，Web 扩展对 Free/Go 用户还是 “coming soon”，而那个 Web 指的是 Work browser，不含 classic ChatGPT。

它终于有了一间屋子

平台边界看清后，我更在意的是，一个 MCP App 终于能在宿主里占据一个明确入口，用户可以反复回来，并继续处理手上的内容。以前它每次被唤起，用完就散；现在算是有了一间自己的屋子。

OpenAI 改的是宿主的接待方式。至于这间屋子最后会建成什么样，得看接下来有多少开发者真的搬进来。