新版 Codex 有什么变化：为什么它现在更像一个开发环境
如果你对 Codex 的印象还停在去年中，那现在再回来，大概率会有点错愕。不是那种“功能又多了两个”的错愕，而是你会明显感觉到，这玩意儿已经不太像最早那个“你提个需求，它去云端干活”的 Codex 了。
最早那版怎么理解都没问题。OpenAI 在 2025 年 5 月 16 日的介绍 里，本来就把它定义成 cloud-based software engineering agent。那时候大家的体感也很统一：它是个很能打的代码代理，你把任务给它，它在隔离环境里做，最后把结果交回来。核心是“代你执行”。
现在这层意思还在，但已经不够用了。你再看后面的几次更新，会发现 Codex 的重点慢慢从“会做任务”挪到了“怎么接住工作流”。
2025 年 9 月 15 日，OpenAI 在 Introducing upgrades to Codex 里开始把 terminal、IDE、GitHub 这些入口往一起拉。到了 2026 年 2 月 2 日的 Introducing the Codex app，这个方向基本就挑明了：app、parallel agents、worktrees、task inbox、skills、automations 一起上，Codex 开始明显像一个 command center，而不是单次对话窗口。
而且这不是纸面变化。OpenAI 在那篇 app 文章里还给了一个挺关键的数据：自从 2025 年 12 月中旬 GPT-5.2-Codex 上线后，整体 Codex 使用量已经翻倍；在过去一个月里，超过 100 万开发者使用过 Codex。这个量级一出来，其实也能解释为什么它这几个月一直在补“技能、插件、自动化、集成”这些层。人一多，光靠 prompt 顶着跑就不够了，迟早得把可复用、可分发、可共享这套东西补起来。
真正值得看的，不只是 Skills，而是 Skills 终于有了“打包和分发”的方式
如果你自己已经用了几个月 Codex，应该很容易理解 Skills 为什么重要。
很多重复的东西，你根本不想每次再讲一遍。仓库规则、代码风格、测试要求、发版边界、危险操作确认格式、某个项目自己的目录约定，这些东西放在长 prompt 里当然也能跑，但体验很差，而且会漂。今天写得细一点，明天忘了补一句，后面代理的行为就开始变味。
所以 Skills 这层很实用。它本质上就是把你常用的一套工作方法收起来，变成 Codex 能逐步发现、逐步调用的能力。它更像“私人定制的工作说明书”，适合你在单一仓库、单一流程里反复迭代。
但如果只写到这里，还是会低估这次变化。因为 OpenAI 这次真正补上的，不只是 Skills，而是 Plugins。
官方在 Codex Plugins 文档 里给的定义非常直接：插件是 installable bundles for reusable Codex workflows。翻成人话就是，插件不是给你多装一个小按钮，而是把一整套可复用工作流打成一个可以安装、共享、分发的包。
这个差别很大。Skills 更像你自己手里的一把顺手工具，怎么改、怎么试、怎么迭代，都偏本地、偏个人、偏项目内部。Plugins 则开始像“包管理”了，它要解决的是另一类问题：同样一套配置、同样一套集成、同样一套工作流，怎么让一个团队、一堆项目、或者一整个组织里的人都能用起来，而且尽量保持一致。
文档里把插件能打包的东西说得很清楚，一个插件里可以一起带上三层：
Skills：描述工作流的提示，Codex 可以逐步发现Apps：可选的应用集成或 connector mappingsMCP servers：这个工作流需要的远程工具或共享上下文
这就是为什么我现在更愿意把新版 Codex 看成“开发环境入口”，而不是“会写代码的聊天工具”。因为从这里开始，它不只是帮你干活，而是在学着承接一整套做事方式。
Skills 和 Plugins，别混着看
很多人第一次看到插件，会觉得“那不就是把 skill 换个名字吗”。其实不是。
更准确一点的理解是：Skill 像局部能力，Plugin 像分发单元。
前者更适合这些场景：
- 你只在一个仓库里迭代
- 这套行为很个人，或者很项目特定
- 你还在试，还没准备好给别人复用
后者更适合这些场景：
- 你想让多个项目复用同一套配置
- 你想把 Skills、MCP 配置、应用集成打包成一个安装单元
- 你需要一个稳定、可版本化、可共享的包
这套边界其实和官方文档是对得上的。文档明确写了：本地 skills 适合单仓库、单工作流、实验性行为；而 plugins 适合跨团队、跨项目共享同一套技能和集成。按这套设计看，skill 更像插件里的一个组成部分，不是主要的对外发布单元。真正进入 marketplace、能被安装和开关管理的，是 plugin。
这次插件层补得还挺完整，不是随便挂个入口就完事
这一点我还挺意外的，因为 OpenAI 不是只写了个概念页，它把结构、安装位置和 marketplace 都给出来了。
一个最小插件，入口是 .codex-plugin/plugin.json。然后在根目录下面，你还可以继续挂这些东西：
skills/.app.json.mcp.jsonassets/
也就是说，这已经不是“写个说明文件给自己看”的级别了，而是一个真正常见软件包该有的样子。manifest、组件指向、展示元数据、截图、logo、默认提示，都开始进来了。官方文档里连这些字段都列得很细：
- 标识信息：
name、version、description - 组件指向：
skills、mcpServers、apps - 展示元数据：
displayName、shortDescription、category、capabilities、brandColor、screenshots
它甚至把目录规则都写死了，比如路径要相对 plugin root，并且以 ./ 开头；视觉资产尽量放 ./assets/。这套东西一出来，你就知道它不是“以后可能会做”的方向，而是已经按产品化思路往前推了。
还有个很实用的细节。官方直接建议，用内建的 @plugin-creator skill 来脚手架本地插件。这个很像在说：别空想了，直接做一个出来试。
Marketplace 这层，才是团队真正会用上的地方
我觉得这部分对开发者尤其关键。
很多 AI 工具的问题不是“你不能定制”，而是“你定制完没法共享”。最后最懂那套流程的人，永远是写那段 prompt 或规则文件的人，其他人只能抄，抄完还容易漂。
Codex 这次把 marketplace 也补上之后，路就顺很多了。按官方文档，Codex 可以读三类 marketplace：
- 官方目录
- 仓库级 marketplace：
$REPO_ROOT/.agents/plugins/marketplace.json - 个人级 marketplace：
~/.agents/plugins/marketplace.json
这就很像真正的包管理思路了。你完全可以在自己的 repo 里放一个 marketplace，把团队内部常用的插件条目都挂进去。或者你自己做一个个人 marketplace，把最顺手的那些工作流收进去。安装之后，Codex 会把插件缓存到 ~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/。本地插件的版本名是 local，开关状态则放在 ~/.codex/config.toml。
这些细节看起来很工程化，但恰恰说明它开始认真了。因为只有把安装位置、缓存、副本加载、启用状态这些事讲明白，插件才不是展示用的概念，而是能进团队流程的基础设施。
另外还有一个值得注意的点：官方文档现在写得很明确，官方 Plugin Directory 的自助发布还没完全开放，属于 coming soon 的状态。也就是说，现在目录已经有了、机制也有了，但“自己一键发到官方市场”这件事还在往前推。这个节奏反而挺合理，先把本地和 repo 级市场跑顺，再放大到公开分发。
所以这轮变化到底值不值得开发者在意
我自己的答案是，值得，而且比“模型又变强了”更值得。
因为旧版 Codex 更像一个一次性很强的外援。你想到一个需求，丢给它，它做完这一票，很多上下文也就跟着散了。你下次再回来，还得重讲你的规则、边界、风格和工具链。
新版 Codex 在补的是另一件事：怎么把这些反复讲的话，慢慢沉淀成长期可用的工作流资产。Skills 是第一层，Plugins 是第二层，Automations 则是把这些能力再往“自动干活”推进一步。
如果你是开发者，这意味着你以后关注的不只是“它能不能写这个函数”，而是“它能不能按我团队的方式稳定地做事”。如果你是 vibe coding 用户，这个变化也很现实，因为你终于不用每次都从一张白纸重新堆 prompt。你顺手的那套流程，可以被收起来、打包、安装、共享，而不是永远只存在某个对话框里。
说白了，之前很多 AI 编程工具的问题，不是模型不够强，而是环境太薄、流程太碎、复用太差。Codex 这几个月补的，恰好就是这些地方。
所以如果你今天再问我“新版 Codex 最大的变化是什么”，我的回答已经不会是“它更像一个代码代理了”。恰恰相反，它正在慢慢脱离“只是代理”这个阶段，开始变成一个能承载技能、插件、自动化和团队配置的工作流平台。