Codex Plugin、Skill、MCP、Internet Access 到底怎么选？扩展能力前先把边界讲清楚

AI Code With · Codex 扩展能力与安全边界指南

第一次把 Codex 用到“能改代码”以外的场景时，很容易掉进一个坑：看到 Plugin、Skill、MCP、Internet Access 这些名字，就下意识把它们理解成四种“给 Codex 加功能”的方式。

结果就是，本来只想让 Codex 按固定规则写一份报告，却先接了远程 MCP；本来只是需要查询一份官方文档，却把 Cloud Agent 的网络出口全部放开；或者安装一个插件以后，没搞清里面到底包含 Skill、外部 App，还是一个需要额外认证的 MCP 服务。

这些能力确实都能扩展 Codex，但扩展的是完全不同的层。选错了，最轻是多维护一套配置，最麻烦的是把不必要的账号权限、网络权限和敏感数据一起带进任务。

先问“任务缺的是规则、工具、打包交付，还是网络出口”，再决定装什么。

1. 先记住这张图：四种能力不在同一层

能力	它主要解决什么	会不会引入外部权限	最适合的场景
Skill	告诉 Codex 按什么流程做事、读什么事实、如何验收	不一定；纯本地 Skill 可以完全不联网	固定写作流程、代码审查规则、项目内操作规范
MCP / App	让 Codex 访问外部工具、数据或动作	通常会，取决于连接的服务和工具权限	查数据库、访问第三方系统、调用远程工具
Plugin	把一组可复用能力打包交付；可包含 Skills、Apps、App templates	取决于插件包含的能力	团队分发一套完整工作流
Internet Access	允许特定执行环境访问外部网络	是，风险与允许的域名/方法有关	下载依赖、读取站点、调用外部 API

这张表最重要的不是背定义，而是避免“谁替代谁”的错误理解。Skill 不等于 MCP，MCP 不等于 Internet Access，Plugin 也不是一个更高级的 MCP。

OpenAI 当前的产品术语也已经比早期教程更清晰：Plugin 是工作流能力的打包容器，可以包含 Skills、Apps 和 App templates；Apps 负责连接外部系统、数据与动作；自定义外部工具仍可以通过 MCP 构建。

2. 只缺一套稳定的做事方法，优先用 Skill

Skill 最像一份“可执行的工作说明书”。它不一定给 Codex 新增一个外部能力，而是把原本需要你每次重复交代的流程固定下来。

Skill 特别适合这三类任务

• 规则重复：同样的检查、写作、测试、审计流程会反复出现。

• 事实源固定：需要读取项目里的 PRODUCT_KNOWLEDGE、AGENTS.md、规范文件等。

• 验收标准明确：任务完成前必须经过固定 QA、测试或发布门禁。

什么时候不该为了“更完整”强行加 MCP

如果任务只需要当前仓库、本地文件、命令和固定规则，Skill 已经够了。

例如“扫描当前项目的 Markdown，按既定 House Style 重写”并不需要访问外部账号。为了这个任务再接一个远程 MCP，只会多出认证、可用性、数据边界和故障排查。

能在本地闭环的流程，先让它留在本地。

3. 真正缺的是外部数据或动作，再考虑 MCP / App

当任务必须离开当前项目，访问第三方系统、远程数据库、团队账号或外部工具时，MCP / App 才真正有价值。

这类能力新增的不只是“能查到更多信息”，还会新增四件事：身份认证、可读范围、可写范围、失败后的撤销路径。

安装之前，至少问清 5 个问题

• 它能读取什么数据？是整个账号，还是只读一个项目/仓库？

• 它能执行哪些写操作？发消息、删记录、修改配置是否都包含在内？

• 凭证放在哪里？OAuth、Token、环境变量还是本机配置？

• 每次写操作是否需要确认？能否把默认权限收缩到只读？

• 断开连接、撤销 Token 或移除 MCP 后，能力是否真的停止？

一个现实例子：让 Codex 查公司知识库

如果需求只是“以后写方案时参考公司知识库”，最容易犯的错是给它一个能读全部空间、还能编辑页面的账号。

更合理的做法是：先只开放目标知识库或目标空间的读取权限，用一个最小查询验证能否拿到需要的信息；确认没有意外数据越界以后，再决定是否真的需要写能力。

这里的思路和网络权限一样：不是问“能不能开”，而是问“为了这项任务最少要开多少”。

4. Plugin 适合“把一整套能力交付给别人”，不是功能越多越好

Plugin 更像一个可以安装、分发和维护的工作流包。根据当前 OpenAI 插件体系，一个 Plugin 可以只包含 Skills，也可以带上外部 Apps，或者包含需要管理员配置的 App template。

所以团队里如果已经有一套稳定流程，例如：

代码安全 Review Skill

GitHub / 工单系统 App

必要的模板和配置

一个可分发的 Plugin

这时候 Plugin 的价值才明显：使用者不需要自己知道每个 Skill 放在哪里、每个连接怎样组合，维护者可以按版本交付整套能力。

Plugin 带来的责任，也比单个 Skill 更大

一旦 Plugin 包含外部 App 或 MCP 服务，维护者就不只是在维护提示词，还要考虑：版本、权限、OAuth、工作区角色、可用区域、升级和撤销。

OpenAI 当前的 Plugin Directory 还会显示插件包含的 Skills、Apps 和连接要求；即使插件标有 Verified，也不等于可以跳过组织自己的隐私、安全和供应商审查。

Plugin 的好标准不是“装完功能最多”，而是“这组能力确实值得作为一个版本化单元长期维护”。

5. Internet Access 解决的是“网络出口”，不是工具能力

这一点特别容易和 MCP 混淆。

MCP / App 决定的是 Codex 能调用什么外部工具；Internet Access 决定的是某个执行环境能不能向外发网络请求。一个 MCP 可能自己就是远程服务，但“能连这个 MCP”不等于 Agent 拥有任意互联网访问。

反过来也一样：你给 Cloud Agent 打开互联网，并不会自动多出数据库、Slack 或内部系统的专用工具。网络只是通道，不是业务能力。

6. “Codex 连不上网”不是完整问题：先确认你在哪个执行面

原稿里最值得保留的一点，就是先区分执行环境。Cloud Agent、本地 CLI、IDE/桌面客户端的网络边界不一样，不能拿一篇 Cloud 教程的开关直接套到本地。

Codex Cloud：setup 和 agent phase 是两件事

OpenAI 当前文档明确说明：Codex Cloud 默认会阻止 agent phase 的互联网访问，但 setup scripts 仍然可以联网，用来安装依赖。需要时，可以按 environment 单独开启 Agent internet access。

这就解释了一个很常见的现象：依赖安装明明成功，Agent 真正开始处理仓库以后却访问不了某个网站。这不是网络“时好时坏”，而是两个阶段本来就有不同的边界。

本地 CLI / IDE：不要套 Cloud 的答案

本地 Codex 还受到当前机器的代理、企业证书、沙箱、系统网络和项目权限影响。浏览器能打开某个页面，不代表终端进程一定使用同样的代理；同样，某个 MCP 能连通，也不代表普通 shell 请求可以任意出网。

本地排查时，应该记录：当前客户端、运行目录、目标域名、请求方式和具体错误。DNS、TLS、超时、401/403 分别指向不同层，不要为了一个域名访问失败直接解除所有限制。

7. Cloud Agent 要联网，最稳的是“域名白名单 + 只读 HTTP 方法”

OpenAI 当前对 Codex Cloud 的建议非常直接：只开放任务需要的域名和 HTTP 方法，并检查 Agent 输出与工作日志。

Cloud Internet Access 可以按 environment 设置为 Off 或 On；开启后仍然可以使用 domain allowlist，同时限制允许的 HTTP methods。

如果只是读文档，优先考虑把方法限制在：

GET

HEAD

OPTIONS

这样 POST、PUT、PATCH、DELETE 等写入型请求会被阻止。

域名方面，可以从空白 allowlist 开始，也可以用 Common dependencies 作为安装依赖的起点，再补充真正需要的域名。All (unrestricted) 虽然最省事，但也是风险最大的一档。

为什么“允许所有域名”不是一个普通便利选项

官方明确列出的风险包括：不可信网页里的 prompt injection、代码或 Secret 外泄、下载恶意或存在漏洞的依赖，以及引入许可证受限内容。

最危险的组合是：Agent 既能访问任意外网，又能拿到高价值 Secret。此时一个来自 issue、README、网页或依赖描述里的恶意指令，就可能诱导 Agent 把仓库信息或凭证发到攻击者控制的地址。

网络权限越大，外部内容就越应该被当成不可信输入。

8. 四个现实需求，到底应该选哪一层能力？

真实需求	优先选择	为什么
每篇文章都按固定结构、QA 和产品事实写	Skill	缺的是稳定流程，不缺外部服务
Codex 需要查询远程数据库或第三方工单	MCP / App	需要专用数据和动作接口
把“写作 Skill + 外部数据连接”交给整个团队安装	Plugin	需要版本化打包和分发
Cloud Agent 需要读取官方文档网站	Internet Access + 精确 allowlist	需要网络出口，但不需要新增业务工具
Cloud Agent 需要调用某个外部 API	Internet Access + 凭证 + 精确域名/方法	网络与认证都必须最小化
本地任务只需下载依赖	本地网络 / setup 相关环境	不需要因此给所有 Agent 工作阶段开放任意网络

9. 真正复杂的任务，可能同时用 Skill、MCP 和 Internet Access

这几种能力不是互斥的。一个高质量工作流完全可能同时使用它们，只是每一层要负责自己的事情。

以一篇带真实数据和配图的技术文章为例，可以这样分：

Skill

负责：选题、事实检查、结构、写作、SEO Review

↓

MCP / App

负责：读取外部数据或工具结果

↓

Internet Access

负责：允许必要的网络请求

↓

外部 API

负责：真正执行生图 / 查询 / 远程动作

↓

Plugin（可选）

负责：把这整套能力打包给团队复用

AI Code With 在这种结构里，更适合出现在“外部模型 / API 能力”这一层。例如你的 Skill 已经判断某个图片任务确实需要重新生成，才去调用对应的 AI Code With 生图能力；Skill 负责决策，API 负责执行，网络策略负责只让必要请求出去。

这比把“写作流程、API 能力、Plugin、网络权限”全部写成一个产品功能更可信，也更容易审计。

10. 如果任务需要访问 AI Code With，正确做法是“精确放行”，不是“为了省事开全网”

假设一个 Cloud 任务确实要调用 AI Code With。这里 AI Code With 只是一个经过核实的外部 API 服务，不是“打开互联网”的理由。

更稳的做法应该是：

• 先从当前官方 / 产品接入文档确认实际使用的 API 域名和 Endpoint，不靠旧文章或模型记忆猜。

• 只把任务真正需要的域名加入 allowlist。

• 如果请求只是读取资料，优先保留 GET / HEAD / OPTIONS；确实要调用生成或写入型 API 时，再开放所需方法。

• API Key 只在需要的执行步骤注入，不写进 prompt、仓库和日志。

• 任务结束后检查 Usage Records / 对应后台记录，确认请求确实走到了预期服务和 Key。

这样 AI Code With 的价值也更自然：它能提供模型/API入口、Key 管理和调用记录，但网络白名单、Codex 的 Agent 权限以及外部内容是否可信，仍然属于 Codex 环境和你的工作流责任。

11. 安装或开权限以后，不要靠“看起来能用”验收

不管是 Skill、Plugin、MCP 还是 Internet Access，我都建议第一次只做一个最小、只读、可回滚的验证。

能力	第一次怎么验收	失败后怎么撤
Skill	新会话触发一次最小任务，确认读取了正确规则和事实源	禁用 / 移走 Skill，再跑同一任务对照
MCP / App	只读查询一条非敏感数据，确认权限范围正确	断开连接、撤销 Token、禁用 Server/App
Plugin	新会话确认插件加载，只测试一项核心能力	卸载 / 禁用插件并确认相关 App 权限没有残留
Internet Access	允许一个目标域名，确认它可访问且未授权域名仍被阻止	关闭环境网络或收紧 allowlist / HTTP methods

任何一个步骤如果你说不清“它现在能读什么、能写什么、凭证在哪里、怎么撤销”，就不应该直接进入生产项目。

12. 最常见的 8 个误区

误区	为什么不对	更合适的判断
“Skill 就是更简单的 Plugin”	Skill 是工作流指令；Plugin 是打包和分发单位	先问是否需要把多种能力一起交付
“装了 MCP 就能上网”	MCP 是工具协议，不等于任意网络出口	网络权限和工具连接分别审计
“开了 Internet Access 就能访问公司系统”	网络通道不等于账号授权和业务工具	仍需 App/MCP 与对应身份认证
“Plugin 安装成功就代表权限都安全”	底层 App/OAuth/工作区权限仍然生效	单独检查读写范围和审批
“只读工具没风险”	读取也可能暴露敏感数据或扩大数据面	把读取范围限制到任务真正需要的对象
“Cloud setup 能联网，所以 Agent 也能”	setup 与 agent phase 网络边界不同	按实际运行阶段检查
“某个域名打不开就直接 All unrestricted”	会同时扩大 prompt injection 与 Secret 外泄风险	先定位 DNS/TLS/策略/认证层
“外部网页是资料，所以可以信”	网页、issue、README 都可能包含 prompt injection	外部内容一律按不可信输入处理

13. 最后，用这套决策顺序就够了

1. 任务只是缺固定流程？

→ Skill

2. 任务必须访问外部数据或执行外部动作？

→ MCP / App

3. 这组 Skill + 外部连接要长期分发给团队？

→ Plugin

4. 当前执行环境确实需要网络出口？

→ Internet Access

5. 需要联网时：

→ 先精确域名

→ 再最小 HTTP 方法

→ 最后才注入必要 Secret

6. 上生产前：

→ 最小只读测试

→ 检查日志与权限

→ 确认撤销路径

这套顺序的好处，是不会为了“功能更全”提前引入不必要的风险。一个任务如果用 Skill 就能完成，就停在 Skill；只有任务真的跨出本地边界，再一层层加外部能力。

14. 真正专业的扩展方式，不是让 Codex 什么都能做

Codex 的扩展能力越来越多以后，最有价值的能力反而不是记住多少插件名字，而是能判断“这个任务到底缺哪一层”。

Skill 负责让流程稳定；MCP / App 负责连接外部系统；Plugin 负责把能力组合成可维护的工作流包；Internet Access 负责控制网络出口。

边界一旦清楚，权限审计、故障排查和产品能力描述都会简单很多。

最好的扩展不是“全部打开”，而是让每一项任务只获得完成它所必需的那一点能力。

资料来源与核对说明

本文基于《Codex Internet Access 怎么开才安全？先分清你在哪个执行面》和《Codex Plugin、Skill、MCP 到底怎么选？安装前先弄清边界》两篇原稿合并重写，并对 2026 年当前的 Plugin 与 Codex Cloud Internet Access 术语和行为进行了核对。

需要特别注意：OpenAI 在 2026 年已经把 Plugin 作为 ChatGPT 与 Codex 的主要工作流能力发现入口，Plugin 可以包含 Skills、Apps 和 App templates；因此早期文章里把 Connector 作为主要产品术语的写法，发布时更适合更新为当前的 Apps / MCP 表述。

OpenAI - Plugins in ChatGPT and Codex：https://help.openai.com/en/articles/20001256-plugins-in-codex

OpenAI - Codex Cloud Agent internet access：https://developers.openai.com/codex/cloud/internet-access

OpenAI - Apps / MCP：https://help.openai.com/en/articles/11487775

OpenAI Developers - MCP and Connectors：https://developers.openai.com/api/docs/guides/tools-connectors-mcp

AI Code With 文档：https://docs.aicodewith.ai/zh/docs