我终于搞懂了 Codex 的 Plugin 和 Skill：顺便把 App、MCP 一次理清
最近在学习 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 去执行。
8. 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
9. Skill 和 Tool 的区别
这是最值得记住的一组区别：
Tool
=
“我能做什么动作”
Skill
=
“完成这类工作应该按什么步骤做”
例如：
bash
read
write
都是 Tool。
而：
Excel 数据分析 Skill
可以告诉 Codex：
先 read
↓
再 bash 运行分析脚本
↓
再 write 输出结果
↓
最后检查
所以：
Tool 是“手里的工具”，Skill 是“怎么使用这些工具完成任务的操作手册”。
10. 一个 Skill 可以同时使用多个 Tool
例如一个“审批异常检查 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 到底“会不会按照你的方式干活”。
浙公网安备 33010602011771号