最近在学习 Codex 时，我一直没搞懂“应用（App）”到底是什么。
因为在 Codex 的“插件”页面里，同时能看到：
插件
应用
MCP
技能
而且“应用”里面又有：
Sites
GitHub
Codex Document Control
Hotline
Plugin Management
Safety Settings
刚开始看非常容易迷糊。
后来我把它理解成了一句话：
Codex 的 App，本质就是“让 Codex 可以访问某个外部系统、数据或动作的连接能力”。
下面用最小白的方式解释。
假设 Codex 是你刚招来的一个员工。
它很聪明，会：
写代码
分析问题
读取本地项目
执行命令
但是它刚入职的时候，并不能天然进入：
GitHub
Google Drive
Slack
Notion
公司内部系统
因为这些系统都在 Codex 外面。
所以需要给它增加一个“入口”。
这个入口就是：
App。
例如你问 Codex：
帮我看看 GitHub 上这个项目最近有哪些 Pull Request。
如果没有 GitHub App：
Codex
↓
不知道你的 GitHub 账号
↓
也看不到你的私有仓库
如果连接了 GitHub App：
Codex
↓
GitHub App
↓
你的 GitHub 账号权限
↓
仓库 / Issue / Pull Request / CI
↓
Codex 获取信息并回答
所以：
App 就像给 Codex 开通了某个系统的“账号入口”。
技术上不是把账号密码直接交给模型，而是通过受控授权和接口来访问。
这是最容易误解的地方。
看到“App”，很多人会以为一定是：
GitHub
Google Drive
Slack
Notion
其实不是。
在 Codex 里：
只要是一项可以被 Codex 调用的外部服务能力，都可能以 App 的形式出现。
所以会看到：
GitHub
也会看到：
Plugin Management
Safety Settings
Codex Document Control
它们不一定是传统意义上的“一个网站”。
更准确地说：
App 是 Codex 可以调用的一项外部能力。
说明是：
Build and deploy websites with Sites.
可以简单理解成：
给 Codex 增加“使用 Sites 创建和部署网站”的能力。
例如用户说：
把这个页面做成一个可以访问的网站。
Codex 在需要时可能使用 Sites。
这个最好理解。
它给 Codex 增加：
访问仓库
查看 Issue
查看 Pull Request
查看 CI
执行支持的 GitHub 操作
的能力。
例如：
帮我看看最近哪个 PR 的 CI 失败了。
流程可能是：
Codex
↓
GitHub App
↓
GitHub
↓
读取 PR / CI
↓
返回结果
可以先理解成：
让 Codex 发现和控制已连接的文档会话。
它更偏 OpenAI/Codex 自己的文档能力，不是传统第三方 App。
它的作用是：
查询用户所在国家或地区相关的本地帮助热线信息。
这是一个非常专用的小能力。
可以理解成：
让 Codex 可以处理插件管理相关操作。
也就是说：
“管理插件”
本身也可以作为一项 App 能力提供给 Codex。
它主要用于：
家长控制
Trusted Contact
相关安全设置
等能力。
所以从这些例子可以看出来：
App 的范围很广，本质不是“一个软件”，而是“Codex 能调用的一项外部能力”。
这是最容易混的地方。
我现在这样理解：
Plugin
=
能力安装包 / 能力套餐
App
=
安装包里真正连接外部系统的能力
例如一个插件可以包含：
Web 开发 Plugin
│
├── GitHub App
├── Sites App
├── 前端开发 Skill
└── 前端测试 Skill
所以：
Plugin 是“包”，App 是里面的一种能力。
一个 Plugin：
可以只有 Skill
可以只有 App
也可以同时有 App + Skill
这个也是当前 Codex 界面最容易让人困惑的地方。
现在 OpenAI 已经把原来的：
App Directory
迁移到了：
Plugin Directory
所以现在主要通过“插件目录”发现新的 App。
也就是说：
不是先进入“应用”页，然后点“添加应用”。
而是：
插件
↓
浏览目录
↓
找到需要的 Plugin
↓
安装
↓
如果里面包含 App
↓
连接 / 授权 App
然后这个 App 才会出现在：
应用
页签里。
例如想添加：
Google Drive
可以按下面理解。
Codex
↓
设置
↓
插件
不要在“应用”页里找“添加 App”。
应该：
浏览目录
然后搜索：
Google Drive
GitHub
Slack
Notion
……
例如：
Google Drive Plugin
点击安装。
这个 Plugin 里面会包含：
Google Drive App
或者相关的 App 能力。
有些 App 需要登录授权。
例如 Google Drive：
安装 Plugin
↓
Connect
↓
登录 Google 账号
↓
查看要求的权限
↓
授权
完成以后：
Codex
↓
Google Drive App
↓
你的 Google Drive
就连通了。
不是所有 App 都必须连接一个第三方账号。
App 可能是：
个人账号授权
例如：
GitHub
Google Drive
也可能：
不需要个人登录
或者：
由公司管理员统一配置
所以安装 App 后：
有没有 Connect、要不要 OAuth 登录，要看这个 App 自己的设计。
可以把 Codex 里的“应用”页理解成：
查看和管理当前 Codex 已经可以使用的 App 能力。
例如：
应用 6
代表当前有 6 个 App 类型能力。
在这里可以看到：
Sites
GitHub
Codex Document Control
Hotline
Plugin Management
Safety Settings
右边还有：
开关
例如：
GitHub 开
可以理解成：
允许 Codex 使用 GitHub 这项 App 能力。
不是说：
开了以后每次聊天都会调用 GitHub
而是：
GitHub App 开启
↓
Codex 在需要的时候“可以”使用它
例如：
Python 的 list 是什么？
根本不需要 GitHub。
但是：
帮我看看 GitHub 上这个 PR。
这时 GitHub App 才有可能被使用。
例如把：
GitHub
关闭。
可以简单理解成：
Codex
↓
暂时不能使用 GitHub App
但要注意：
关闭 App 不一定等于把包含它的 Plugin 卸载。
因为：
Plugin
和：
App
是两层东西。
一个 Plugin 里面除了 App，还可能有 Skill。
所以可能出现：
GitHub App 被关闭
↓
依赖 GitHub 的能力不能用
但是 Plugin 里的其他 Skill
仍然存在
假设 GitHub 连错账号了。
可以进入：
设置
↓
插件 / 应用
↓
找到 GitHub
↓
查看 Connection / Connected accounts
如果当前 App 支持，可以：
查看当前账号
连接另一个账号
Reconnect
Disconnect
是否支持多个账号，要看具体 App。
这两个不要混。
类似：
这项能力暂时不给 Codex 用。
例如：
GitHub App
关闭
类似：
把当前连接的 GitHub 账号解除授权。
例如：
Codex
X
GitHub 工作账号
以后需要重新 Connect 才能访问。
所以：
关闭
=
暂时禁用能力
Disconnect
=
解除账号连接
如果把整个 Plugin 卸载：
Plugin
↓
整个能力包移除
可能影响：
里面的 App
里面的 Skill
相关工作流
所以操作前要看 Codex 的提示。
可以分成四件事。
浏览目录
↓
安装 Plugin
↓
连接其中的 App
插件
↓
应用
↓
右侧开关
决定：
Codex 当前能不能使用这个 App。
例如：
GitHub
Google Drive
Slack
可以检查：
到底连的是哪个账号
权限有没有过期
需不需要重新 Connect
可以先判断：
只是暂时不用？
→ 关闭 App
账号不应该继续授权？
→ Disconnect
整个工作能力包都不要？
→ 卸载 Plugin
这三个操作不是一回事。
假设现在 GitHub App 已经开启。
正常状态：
Plugin 已安装
+
GitHub App 已开启
+
GitHub 工作账号已连接
那么：
Codex
↓
可以在权限范围内访问 GitHub
如果暂时不想让 Codex 用 GitHub：
应用
↓
GitHub
↓
关闭开关
如果 GitHub 连错账号：
找到 GitHub App
↓
Connected accounts
↓
Disconnect
↓
重新 Connect
↓
选择正确 GitHub 账号
如果整套 GitHub 相关工作流都不要了：
卸载对应 Plugin
可以。
例如：
公司 OA
公司 ERP
公司 CRM
公司知识库
都可以做成自定义 App。
常见思路是：
Codex
↓
公司自定义 App
↓
MCP
↓
公司 MCP Server
↓
OA / ERP / CRM
例如以后可以说：
帮我看一下今天有哪些 OA 待办。
Codex：
调用公司 OA App
↓
MCP Tool
↓
OA 系统
↓
返回待办
所以：
公共 App 是别人已经帮你做好的；公司自定义 App 是你们自己把内部系统接进来。
回答：
Codex 能去哪里？
例如：
GitHub
Google Drive
公司 OA
回答：
Codex 用什么标准方式连接外部 Tool？
例如：
Codex
↓
MCP
↓
公司 OA MCP Server
回答：
这类事情应该怎么做？
例如：
前端开发 Skill
PDF Skill
测试 Skill
最终可以这样记：
Codex
= 员工
Plugin
= 给员工发的一整套工作装备
App
= 给员工开的外部系统入口
MCP
= 连接外部工具的一套统一协议
Skill
= 告诉员工怎么完成某类工作的 SOP
最推荐记住这句话：
Plugin 是“能力包”，App 是“外部能力入口”，MCP 是“怎么连接”，Skill 是“怎么干活”。
对于 App 来说，最重要的使用和维护流程就是：
添加 App：
浏览 Plugin Directory
↓
安装 Plugin
↓
连接 App
↓
完成账号授权
日常维护：
应用页
↓
查看当前 App
↓
开启 / 关闭
账号维护：
查看 Connected accounts
↓
Connect / Reconnect / Disconnect
完全不用：
卸载对应 Plugin
所以，Codex 里的“应用”页面可以简单理解成：
“Codex 目前已经接通了哪些外部能力，以及这些能力现在允不允许使用”的管理页面。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。