如果你對 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 mappings
• MCP servers：這個工作流程需要的遠端工具或共享上下文

這就是為什麼我現在更願意把新版 Codex 看成“開發環境入口”，而不是“會寫程式碼的聊天工具”。因為從這裡開始，它不只是幫你幹活，而是在學著承接一整套做事方式。

Skills 和 Plugins，別混著看

很多人第一次看到外掛，會覺得“那不就是把 skill 換個名字嗎”。其實不是。

更準確一點的理解是：Skill 像區域性能力，Plugin 像分發單元。

前者更適合這些場景：

• 你只在一個儲存庫裡迭代
• 這套行為很個人，或者很專案特定
• 你還在試，還沒準備好給別人複用

後者更適合這些場景：

• 你想讓多個專案複用同一套設定
• 你想把 Skills、MCP 設定、應用整合打包成一個安裝單元
• 你需要一個穩定、可版本化、可共享的包

這套邊界其實和官方檔案是對得上的。檔案明確寫了：本地 skills 適合單儲存庫、單工作流程、實驗性行為；而 plugins 適合跨團隊、跨專案共享同一套技能和整合。按這套設計看，skill 更像外掛裡的一個組成部分，不是主要的對外發佈單元。真正進入 marketplace、能被安裝和開關管理的，是 plugin。

這次外掛層補得還挺完整，不是隨便掛個入口就完事

這一點我還挺意外的，因為 OpenAI 不是隻寫了個概念頁，它把結構、安裝位置和 marketplace 都給出來了。

一個最小外掛，入口是 .codex-plugin/plugin.json。然後在根目錄下面，你還可以繼續掛這些東西：

• skills/
• .app.json
• .mcp.json
• assets/

也就是說，這已經不是“寫個說明檔案給自己看”的級別了，而是一個真正常見軟體包該有的樣子。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 最大的變化是什麼”，我的回答已經不會是“它更像一個程式碼代理了”。恰恰相反，它正在慢慢脫離“只是代理”這個階段，開始變成一個能承載技能、外掛、自動化和團隊設定的工作流程平臺。