如果您上一次了解 ChatGPT 的可扩展性还是一年前，那么这期间词汇变了两次，实质只 变了一次。“插件”这个词回来了，但它的含义已经不是 2023 年那个。OpenAI 的开发者 文档现在把插件定义为三样东西的打包：技能、一台 MCP 服务器，以及可选的 UI。技能 在工具之外补上可复用的流程；MCP 服务器提供工具本身以及对外部系统的访问；UI 则是 某些工具返回、供 ChatGPT 内展示的一组资源。
实际后果很容易被忽略。插件是围绕 MCP 服务器的一层分发外壳——不是它的替代品， 也不是使用它的前提。这意味着，如果您的目标是让 ChatGPT 读到自己的文件、笔记或 会议记录，那么去做一个插件通常是从问题的另一头下手。目录和协议是两个不同的层， 挡在您路上的只有其中一个。
下面就把这两层分开来看，依据是 OpenAI 自己的文档和 Agent Plugins 规范在 2026 年 8 月 15 日的状态。
按 OpenAI 的插件架构页面，插件可以包含技能、MCP 服务器，或者两者都有。哪一样都 不是无条件必需的。“当指示和模型已有的工具就足以完成任务时”，只有技能也够；MCP 服务器出现的时机，是插件必须触及某个服务、认证某个用户，或在别人运营的基础设施上 执行行为。
两者的分工值得记住，因为无论有没有插件，任何助手配置里的分工都是这一套：
| 部分 | 用来做什么 |
|---|---|
| MCP 服务器 | 实时数据、认证、授权、受控的动作 |
| 技能 | 工具的调用顺序、决策点、输出要求、示例、模板 |
| UI | 由选定工具返回、在 ChatGPT 中渲染的资源 |
这不是 ChatGPT 特有的想法。它和为什么光有工具描述还不够 是同一个论点：服务器告诉模型它能做什么，技能告诉它这个团队希望怎么做。把 两者打包在一起，只不过意味着它们作为一个单位一起流转。
ChatGPT 和 Codex 共用一个插件目录，公开上架的条目在两边都能被发现。进入目录是
一套带有发布要求的发布流程。OpenAI 的构建指南在托管这一面毫不含糊：要提交公开
插件，MCP 服务器需部署在稳定、公网可达的 HTTPS 端点上，支持 MCP 的 streamable
HTTP 传输，通常在以 /mcp 结尾的 URL 上响应。该端点在插件审核和域名验证期间
必须保持可达，文档还明确排除了为公开提交而使用临时隧道或本地端点。
要把这段读成关于上架的说明，而不是关于 MCP 的说明。里面的每一项——公网 HTTPS、 稳定 URL、审核、域名验证——之所以存在，是因为会有陌生人来安装这个东西。助手要 用上一台工具服务器，这些一样都不需要。这是应用商店的税，只有当您把东西发给别人时 才需要缴。
因为形式不等于目录。2026 年 8 月 6 日，打包本身成了一项开放标准：Agent Plugins 1.0.0，其技术指导委员会汇集了来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的 核心维护者，首发即获得 ChatGPT 与 Codex、Cursor、GitHub Copilot、Kiro 和 VS Code 的支持。它宣称的目标是一层不高的互通底线——作者把组件打包一次，而不是为每个 客户端重新摆一遍。
布局刻意做得很无趣。插件就是一个目录，根下放 plugin.json（只有 $schema 和
name 是必填），Agent Skills 放在 skills/ 下，每个占一个子目录并带一份
SKILL.md，MCP 服务器配置放在 mcp.json。而 mcp.json 描述三种传输：stdio
用于由命令启动的本地子进程，streamable-http 用于远程端点，sse 用于
2024-11-05 的旧传输。一致性规则写得很明确：支持 Agent Plugins MCP 服务器的
客户端，必须至少支持 stdio 或 streamable-http 之一，并且应当两者都支持。
所以，一个 MCP 服务器完全跑在您笔记本上的插件，是合法的插件。它只是在 OpenAI 的 公开目录里不可上架，而这和“不允许”是两回事。比如 VS Code 就能从市场、或直接从 Git 仓库 URL 安装 Agent Plugins，插件的 MCP 服务器会与工作区级和用户级的服务器 并列出现。Cursor 在自家格式之外也支持这项标准，并在 Customize 页面里一并管理。
跳过插件，直接接服务器。
config.toml
共用 MCP 配置，由命令启动的本地进程是头等公民：写 command，再加可选的
args、env 和 cwd。可以用 codex mcp add 添加，也可以在桌面应用的 MCP
服务器设置里添加，或者直接编辑 ~/.codex/config.toml。这些形态之间的区别不是表面功夫。本地 stdio 服务器是客户端启动、并通过标准输入 输出与之对话的程序：不开端口，不发令牌，通往助手的路上也没有任何东西流向第三方。 托管端点则意味着一个运营方、一份凭证和一条网络路径——对真正生活在云上的服务来说， 这是合理的交换；对您自己的笔记来说，就很奇怪。
打包方式的变化没有改动一件事：助手能不能动手，由客户端决定，而不是由插件决定。
Codex 提供四种批准模式——auto、prompt、writes 和 approve——其中 writes
会对未标记为 read-only 的工具发起询问，可通过 default_tools_approval_mode 全局
设置，也可按工具设置。VS Code 则相反：一旦您安装了插件，它就把插件的 MCP 服务器
视为隐式受信任的，与工作区服务器不同，它们不会在启动时单独弹出信任提示。从陌生
市场安装插件之前，这一点值得先知道。
这也是为什么“只读”是服务器声明的一种属性，而不是目录所强制的承诺。Speak-Y 的
服务器把会改动数据的命令——给录音打标签、重命名发言人、分享到团队频道——都声明
为会改动数据，因此客户端会在运行前询问；读取是本地的，不需要另外运行什么。只要
在服务器的 args 里加上 --read-only，就能把客户端固定为只读，此后那些会改动的
命令根本不会提供给它。
如果您是在为别人做集成，插件现在是对的形状：一个包、一份清单、多个客户端，还有 一个能同时触达 ChatGPT 和 Codex 的目录。如果您是想把自己的上下文交给自己的助手， 这套机器一样都用不上，去够它只会为一个配置文件里一行就已解决的问题，换来一张 托管账单和一条审核队列。
Speak-Y 有意选了第二条路。它的 MCP 服务器是一个本地进程，在包括 Free 在内的所有 套餐上都免费，从设置 → 集成一键安装——助手能读什么、能改什么，见 MCP 概览。如果您还在挑要把哪个助手指过来， 客户端对比讲的是谁能启动本地 服务器、谁不能。
是一个包，不是一套协议。OpenAI 的开发者文档把它定义为技能、一台 MCP 服务器和可选的 UI：技能补上可复用的流程，MCP 服务器提供工具以及对外部系统的访问，UI 则是由选定工具返回的一组资源。MCP 服务器是可选的——只由指示和资源构成的插件，可以只包含技能。
不必。发布插件，是通过 ChatGPT 与 Codex 共用的目录把集成分发给别人的方式。要让助手访问您自己机器上的数据，直接让客户端指向一台 MCP 服务器即可——Codex 和 ChatGPT 桌面应用在 config.toml 里接受本地 stdio 服务器，Cursor 和 VS Code 在 mcp.json 里接受。不用上架，不用审核，不用托管。
格式是允许的：Agent Plugins 1.0.0 规范在 mcp.json 中定义了 stdio、streamable-http 和 sse 三种传输，符合规范的客户端至少要支持 stdio 或 streamable-http 之一。OpenAI 的公开目录则不允许：提交公开插件时，服务器必须位于稳定、公网可达的 HTTPS 端点上，文档还明确排除了本地端点或临时隧道。核实于 2026 年 8 月 15 日。
MCP 是助手与工具服务器对话所用的协议。Agent Plugins 于 2026 年 8 月 6 日发布，是一种打包格式，规定插件的各个部分放在哪里：根目录下的 plugin.json、放在 skills/ 里的技能、写在 mcp.json 里的 MCP 服务器配置。它的技术指导委员会包含来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的维护者，首发客户端是 ChatGPT 与 Codex、Cursor、GitHub Copilot、Kiro 和 VS Code。
不是，也不需要是。Speak-Y 提供的是一台本地 MCP 服务器，由您的客户端在您的机器上启动，所以录音和文字记录是从磁盘上的资料库读取的，而不是上传到某个人托管的端点。它可从设置 → 集成一键安装，并在包括 Free 在内的所有套餐上都免费。