夜雨聆风
OpenAI 给 Codex 加了插件,这不是小功能,是平台战争开始了
这两天，我看到 OpenAI 给 Codex 上了一个新东西：Plugins。
很多人第一反应可能是，“哦，又多了个插件市场”。但我看完官方文档后，真正的感受是：
AI 编程工具的竞争，开始从“谁模型更强”，转向“谁能把技能、工具、权限和分发一起打包”。
这件事比一个功能页重要得多。
先把事实摆清楚：Codex 这次到底加了什么
根据 OpenAI 官方的 Plugins和 Build plugins文档，这次 Codex 的插件不是传统意义上那种“装个 UI 扩展”。
它的定义很明确：插件是把技能、应用集成、MCP 服务一起打包成可复用工作流。
一个插件里目前可以放三类东西：
- Skills
：可复用的指令和流程。 - Apps
：GitHub、Slack、Google Drive、Gmail 这类外部应用连接。 - MCP servers
：把更多工具和共享信息暴露给 Codex 的服务层。
这三个东西被官方直接打包在一个概念里，信号非常清楚：
OpenAI 已经不把 Codex 当成“回答你问题的模型界面”，而是当成一个能装能力包的工作台。
这件事为什么重要：它把“会不会”变成了“怎么接、怎么管、怎么分发”
过去一年，AI 编程领域大部分讨论还停留在 benchmark、模型能力和 agent 成功率上。
但插件一出来，问题开始变了。真实工作里的瓶颈往往不是“模型不够聪明”，而是：
-
这个工具能不能接进我现在的工作流 -
团队里的 10 个人能不能复用同一套配置 -
权限怎么控制 -
外部应用怎么认证 -
工具链能不能随着项目一起迁移
Codex 这次给出的答案，不是再多堆一个大模型，而是把这些工程化问题往前推了一步。
第一，插件有统一入口
在 Codex App 里可以直接打开插件目录，在 CLI 里则是：
这意味着插件不是散落在 README 和脚本里的民间偏方，而是进入了正式产品入口。
第二，插件既能自动选，也能显式点名
官方文档写得很清楚，装好插件后你有两种用法：
-
直接描述任务，让 Codex 自己选合适的已安装能力 -
用 @显式调用某个插件或其中的 skill
这意味着 Codex 同时在服务普通用户和高级用户。一个隐藏复杂度，一个保留控制权。
第三，插件开始有“分发”和“治理”层
继续看 Build plugins文档，你会发现 OpenAI 连插件入口和 marketplace 都开始标准化了。插件必须有 .codex-plugin/plugin.json，还可以继续打包 skills/、.mcp.json、.app.json和 assets/。
市场清单则可以放在：
如果你只想快速理解它的最小形态，官方给的最简结构其实很直白：
它对应的核心入口就是 .codex-plugin/plugin.json加上一个 skills/目录。只有当你要继续打包 MCP 或外部应用时，才需要把 .mcp.json、.app.json往里加。
也就是说，插件已经不只是“我本地能用的小技巧”，而是“团队、仓库、个人都能分层管理的能力包”。
真正值得警觉的，不是插件本身，而是 OpenAI 开始吃“工作流层”
很多人会把这件事理解成“OpenAI 终于给 Codex 补了插件能力”。我觉得这个理解太轻了。
更准确的说法应该是：OpenAI 正在把 Skills、MCP、外部应用连接、安装入口、权限流程，全部往 Codex 自己的产品层里收。
这件事至少会带来三个后果：
- AI 编程产品开始从“模型调用器”变成“能力打包器”。
- Prompt 正在被“安装式能力”替代一部分。
- 平台之间会开始抢生态位。
一旦插件、marketplace、skills、MCP 都被产品原生吸收，接下来拼的就不是单次对话体验，而是你有多少现成能力包、你能不能控制默认入口、你的团队配置能不能统一、你的生态能不能形成网络效应。
这不是一个“小功能”。这是平台战争的开场动作。
这对 OpenClaw 用户意味着什么
如果你一直在看 OpenClaw、MCP、skills 这些方向，这次会有一种很强的既视感。因为 Codex 插件的核心思路，本质上就是把技能包、工具连接、MCP 服务和团队共享配置产品化。
换句话说，OpenAI 正在把“高手会自己搭的 AI 工作流”，做成面向更多人的安装式产品。
好消息：方向被验证了
OpenClaw 这类开源工具一直强调 agent 不该只是聊天、工具调用要标准化、能力组合要可复用。现在 Codex 也开始往这个方向走，说明这不是少数极客的自嗨，而是大厂也认定有价值的产品方向。
坏消息：闭源产品开始把“组合能力”做得更顺
一旦 OpenAI 把插件目录、安装入口、账号认证、权限流程、marketplace 全部串起来，它天然就比纯手工配置更低摩擦。开源工具如果长期停留在文档、命令、JSON 配置和手动认证，普通用户会更容易被闭源平台吸走。
所以 OpenClaw 真正要守住的，不只是开放，而是这三件事
- 可审计
：用户要知道 agent 拿了什么权限，调用了什么工具，做了什么动作。 - 可迁移
：一套能力不该只锁在某个闭源产品里。 - 可定制
：复杂团队工作流不可能永远只靠官方市场满足。
闭源产品会在“默认体验”上越来越强，开源框架要赢，就得把“上限、透明度、可控性”拉到别人追不上的程度。
如果你现在就在用 Codex，最实用的判断是什么
我不建议一看到“插件”两个字就脑补成新一代 App Store。官方文档其实已经给出了一个很务实的边界：
如果你还只是围绕一个仓库、一个个人工作流在迭代，先从 local skill 开始；只有当你要跨团队共享、打包 app 集成或 MCP 配置时，再上 plugin。
这个建议我很认同。很多工具体系死得很快，不是能力不够，而是太早平台化，结果每个人都在维护一堆半成品抽象。
所以如果你是普通开发者，我会这么建议：
- 适合马上试插件的人
：已经在用 Codex 做真实开发任务，有重复流程，且想把 skills、MCP、外部应用认证打包给团队复用。 - 暂时别急着做插件的人
：还在单人探索阶段，稳定工作流没跑顺，只想解决一个仓库里的一个具体问题。
这时候，先把 skill 写明白、把流程跑通，比急着做 marketplace 更重要。
我的判断
OpenAI 给 Codex 加插件，表面上像是补齐产品功能。
但真正值得看的地方不是“多了几个集成入口”，而是 AI 编程工具正在从“一个会写代码的助手”，变成“一个可安装、可治理、可分发的工作平台”。
以后真正值钱的能力，不只是模型聪不聪明，而是能不能把工作流打包、能不能让团队复用、能不能把权限和治理做进去、能不能形成自己的能力生态。
从这个角度看，Codex 插件很重要。它不只是 OpenAI 多做了一页文档，而是在告诉所有人：下一轮竞争，开始拼平台了。
你会愿意把自己的常用工作流打包成插件吗？你更看重“默认就顺手”的闭源平台，还是“更自由但需要自己搭”的开源路线？评论区聊聊。