最近在学习 Codex 时，我最容易混淆的几个词就是：

Plugin
App
Skill
MCP
Tool

它们看起来都像“给 Codex 增加能力”，但实际上解决的问题并不一样。

先记住一句最简单的话：

Plugin 是“能力包”，App 是“外部系统入口”，Skill 是“工作方法”，MCP 是“连接外部 Tool 的统一协议”。

这篇文章重点讲 Plugin 和 Skill，App 和 MCP 只做简短回顾。

---

1. 先把 Codex 想成一个员工

假设 Codex 是公司新来的一个员工。

它本身已经有：

大模型
+
Agent Runtime / Harness
+
文件读写
+
Shell
+
Git
+
基础 Tool

但是想真正把工作做好，还需要：

工作手册
外部系统权限
专业工作流程
配套工具

于是就出现了：

Plugin
App
Skill
MCP

---

2. Plugin 到底是什么

Plugin 最简单的理解：

Plugin = 一个“工作能力包 / 套餐”。

它不是某一个具体 Tool，也不是某一个具体系统。

一个 Plugin 里面可以包含：

Skill
App
其他工作流能力

例如一个“Web 开发 Plugin”可能长这样：

Web 开发 Plugin
│
├── Skill：前端页面开发
├── Skill：前端测试
├── App：GitHub
└── App：Sites

所以：

Plugin 是外包装，里面可以装多个能力。

---

3. 为什么 Codex 现在主要从“插件目录”添加能力

现在 Codex 里经常能看到：

插件
应用
MCP
技能

而发现新能力时，主要入口通常是：

Plugin Directory
插件目录

可以把它理解成：

Codex 的“能力商店”。

里面有的 Plugin：

只有 Skill

有的：

只有 App

还有的：

Skill + App

所以：

你安装的是一个能力包，安装以后里面的 App、Skill 再分别出现在对应页面。

---

4. Plugin 不要简单理解成“一个功能按钮”

传统浏览器插件容易理解成：

安装一段代码
↓
增加一个功能

Codex 的 Plugin 更适合理解成：

某一类工作的完整能力组合。

例如：

数据分析 Plugin

可能包含：

数据分析 Skill
+
表格处理能力
+
外部数据 App
+
相关工作流配置

所以 Plugin 更像：

“完成这一类工作需要的一整套装备”。

---

5. Skill 到底是什么

Skill 最简单的理解：

Skill = 给 Codex 的一套可复用工作方法 / SOP。

例如一个：

PDF Skill

它可能告诉 Codex：

处理 PDF 时：

1. 先检查文件
2. 获取页数
3. 读取内容
4. 按用户要求修改
5. 修改后重新检查版式
6. 最后再输出结果

所以：

Skill 重点解决的不是“能不能做”，而是“应该怎么做”。

---

6. Skill 里面只有文字吗

不是。

Skill 可以很简单，只包含：

Instructions

也可以包含：

Instructions
Examples
Reference Files
Scripts
Code

例如一个 Excel Skill：

excel-skill/
│
├── SKILL.md
├── scripts/
│   ├── inspect_excel.py
│   └── validate_excel.py
└── references/
    └── excel_rules.md

其中：

SKILL.md

可以理解成：

这个 Skill 的主工作手册。

---

7. Skill 里面有代码，谁执行代码

这是最容易误解的地方。

假设 Skill 里面有：

scripts/check_excel.py

Skill 自己不会运行代码。

正确流程是：

用户提出任务
↓
Codex 判断适合使用某个 Skill
↓
读取 Skill 的工作说明
↓
Skill 说明要求执行 check_excel.py
↓
Codex 决定调用 bash Tool
↓
Harness / Runtime 真正执行：

python scripts/check_excel.py
↓
返回结果
↓
Codex继续下一步

所以：

Skill 负责告诉 Codex“应该怎么干”；真正执行代码的是 Codex 的 Runtime / Harness，通过 Tool 去执行。

---

Tool 可以理解成：

模型可以调用的一个“函数式能力入口”。

例如：

query_order(order_no)

是一个 Tool。

它内部可能调用 HTTP API。

同样：

bash(command)

也是一个 Tool。

例如：

bash(command="python check_excel.py")

这里：

bash
=
Tool

python check_excel.py
=
传给 bash Tool 的参数

所以 Tool 底层可以做很多事情：

调用函数
调用 HTTP API
执行 Shell
读文件
写文件
操作浏览器
调用 MCP Tool

---

这是最值得记住的一组区别：

Tool
=
“我能做什么动作”


Skill
=
“完成这类工作应该按什么步骤做”

例如：

bash
read
write

都是 Tool。

而：

Excel 数据分析 Skill

可以告诉 Codex：

先 read
↓
再 bash 运行分析脚本
↓
再 write 输出结果
↓
最后检查

所以：

Tool 是“手里的工具”，Skill 是“怎么使用这些工具完成任务的操作手册”。

---

例如一个“审批异常检查 Skill”：

第一步
调用 MCP Tool 查询审批单

第二步
用 write 保存返回数据

第三步
用 bash 运行检查脚本

第四步
用 grep 查询规则

第五步
再次调用 MCP Tool 查询审批历史

第六步
输出异常原因

这时候 Skill 负责的是：

把多个能力按照一套工作方法串起来。

真正执行动作的仍然是：

Tool
MCP Tool
Shell
文件工具

---

11. Skill 和 Prompt 有什么区别

Prompt 更像：

这个 Agent 长期应该遵守的基本要求。

例如：

你是一名严谨的开发助手。
修改代码后必须测试。
回答尽量简洁。

Skill 更像：

遇到某一种具体任务时，再拿出来使用的专项操作手册。

例如：

PDF Skill
Excel Skill
Frontend Testing Skill

所以可以理解成：

Prompt
=
长期岗位要求


Skill
=
专项工作 SOP

---

12. App 简单回顾

App 之前已经单独学过，这里只记一句：

App = 让 Codex 连接某个外部系统、数据或动作。

例如：

GitHub App
Google Drive App
Slack App
公司 OA App

可以理解成：

给 Codex 开一个外部系统入口。

例如：

Codex
↓
GitHub App
↓
GitHub
↓
仓库 / PR / Issue / CI

---

13. MCP 简单回顾

MCP 全称：

Model Context Protocol

最简单理解：

MCP = AI / Agent 连接外部 Tool 的统一标准协议。

例如：

Codex
↓
MCP
↓
公司 OA MCP Server
↓
OA 系统

MCP Server 可以提供：

query_todo
query_approval
create_ticket

这些本质上仍然是 Tool。

---

14. App 和 MCP 的关系

App 更偏：

用户看到的“外部系统连接能力”。

MCP 更偏：

技术上如何标准化提供 Tool。

例如公司 OA：

用户看到：
公司 OA App

底层可能：
↓
MCP
↓
OA MCP Server
↓
OA 系统

所以 App 和 MCP 不是完全同一个层次。

---

15. Plugin、App、Skill、MCP 放在一起看

可以这样理解：

Plugin
=
一个完整能力包

里面可能包含：

├── Skill
│   └── 教 Codex 怎么干
│
├── App
│   └── 让 Codex 连接外部系统
│
└── 其他配置

而：

App

底层连接外部系统时，可能会用到：

MCP

Skill 执行工作时，又可能调用：

Tool / App / MCP

所以它们不是互相替代的关系。

---

16. 用“公司员工”一次记住

假设：

Codex
=
公司员工

那么：

Plugin
=
公司给员工发的一整套工作装备


Skill
=
《这类工作怎么做》的操作手册


App
=
给员工开的外部系统账号 / 入口


MCP
=
员工与外部系统之间的一种统一接口标准


Tool
=
员工真正可以使用的一项具体能力

例如：

Tool：bash
= 能执行命令

Tool：read
= 能读文件

Tool：query_order
= 能查订单

---

17. 一个完整例子：Web 开发

假设安装：

Build Web Apps Plugin

里面可能提供：

Frontend App Builder Skill
Frontend Testing Skill
GitHub App
其他能力

用户说：

根据需求修改这个 React 页面，并完成测试。

Codex 可能：

使用 Frontend App Builder Skill
↓
按照前端开发流程修改代码
↓
调用 read / write / shell 等 Tool
↓
使用 Frontend Testing Skill
↓
启动项目并测试
↓
需要时使用 GitHub App
↓
查看 PR / CI
↓
完成任务

这时候：

Plugin
=
把这些能力组合到一起


Skill
=
告诉 Codex 工作步骤


Tool
=
真正执行动作


App
=
访问外部系统

---

18. 什么时候值得自己做 Skill

如果你发现自己经常重复对 Codex 说：

先看现有代码
不要改其他模块
保持现有 UI 风格
修改后必须测试
测试失败继续修
最终再汇报修改内容

这就非常适合做成：

项目开发 Skill

以后 Codex 在类似任务里就可以复用这套方法。

所以 Skill 最有价值的地方就是：

把人的经验、流程和规范沉淀成 Codex 可以重复使用的工作能力。

---

最后总结

最终只需要记住：

Plugin
= 能力包


Skill
= 怎么干


App
= 能去哪


MCP
= 怎么标准化连接


Tool
= 真正可以执行的具体能力

一句话总结：

Plugin 是“整套装备”，Skill 是“工作方法”，App 是“外部系统入口”，MCP 是“统一连接标准”，Tool 则是 Agent 真正可以调用的一项具体能力。

如果重点理解 Codex 的扩展体系，最值得先搞懂的其实就是：

Plugin 负责“打包能力”，Skill 负责“沉淀工作方法”。

因为 App 和 MCP 更多解决的是“怎么连接外部世界”，而 Plugin 和 Skill 更直接决定 Codex 到底“会不会按照你的方式干活”。