Codex 的野心，MCP 和 Skill 的下一步
整理版優先睇
Codex 等 Agent 應用正從單純聊天界面走向多功能工作區，未來將透過插件生態實現「幾乎所有任務」的閉環。
呢篇文章係由一位長期使用 Codex、Cursor 等 Agent 工具嘅開發者所寫。佢留意到今年 Agent 應用嘅界面出現咗一個有趣嘅收斂：Codex、Claude 桌面版、Cursor 3.0 等頂尖產品，幾乎同時採用咗左中右三欄佈局——左邊係項目同會話列表，中間係對話窗，右邊係工作區。呢個變化背後嘅原因係，Agent 可以自己寫 code 改文件，用戶需要一個區域去檢查結果，而傳統兩欄 chatbot 已經唔夠用。但作者指出，呢個只係第一階段；隨住用戶越來越依賴 Agent，佢哋自然希望可以直接喺 Agent 入面微調生成嘅內容，而唔係再開另一個軟件。
作者認為 Codex 嘅真正野心係「Codex for (almost) everything」，但目前佢仲未做到生成後編輯。佢推測 Codex 可能係等緊一個統一嘅解決方案，而唔係自行開發每個垂直領域嘅編輯器。文章進一步分析，目前 Agent 能力拼圖有兩塊已經補齊：MCP 解決咗「連接」問題，Agent Skills 解決咗「點樣做」嘅問題，但第三塊「用戶二次編輯」始終係缺口。雖然市面上出現咗好多 Vibe Coding 出嚟嘅 Markdown 編輯器，但 Codex 唔會自己做一個，因為眾口難調。最合理嘅做法係引入插件機制，類似 VSCode 同 Chrome 嘅插件市場。
插件機制仲可以順手解決另一個問題：Skill 冇辦法商業化，因為佢係透明嘅，復…
- Agent 界面已收斂到左中右三欄佈局，右側工作區由檢查結果演變為多功能編輯區。
- Codex 嘅野心係「幾乎所有任務」，但現階段生成後無法編輯，插件機制係最可行嘅出路。
- MCP 解決工具連接，Skills 解決領域知識，唯獨用戶二次編輯呢塊缺口一直未補上。
- 插件機制可以令 Skill 商業化，仿效 App Store 收費模式，開發者先有動力持續貢獻。
- 中小團隊應該把握窗口期，專注喺 Codex 等平台上開發插件，而唔係由零自建 Agent。
baoyu-skills
作者維護嘅 Agent Skills 集合，接近 2 萬 Star，但未能商業化。
界面收斂：左中右三欄成為新標準
呢段時間作者密集使用 Codex App、Cursor 等 Agent 應用，發現一件事好有意思：去年大家爭邊個模型更強，今年爭嘅係邊個窗口右側更好用。Codex、Claude 桌面版、Cursor 3.0、TRAE SOLO，呢幾間最頂尖嘅 Agent，喺完全冇協商嘅情況下，幾乎同時收斂到同一個界面佈局：左側係項目同會話列表，中間係同 Agent 嘅對話，右側係工作區，放住文件瀏覽、網頁預覽、文件變更審查呢啲功能。
肯定唔係相互之間嘅抄襲，更像係當前 Agent 交互嘅最優解。
傳統 Chatbot 只需要兩欄，左邊會話歷史，右邊對話窗口，你問佢答，用完走人。到咗 Agent 時代，Agent 能自己寫 Code、改文件、調工具，做完之後你要睇嚇有冇做啱——右側工作區就係為咗呢件事出現。但呢個只係第一階段。
- Codex 同 Cursor 用 Tab 切換工作區，Claude 用浮動面板。
- 作者認為 Codex 最順手，Claude 嘅浮動面板設計感有餘、實用性不足，遲早要改。
Codex 嘅真正野心：從代碼助手到萬能平台
Codex 4 月大版本發佈時嘅口號係「Codex for (almost) everything」——幾乎任何任務都能做。呢句可以理解成廣告口號，但更像係一個產品方向嘅聲明。要兑現呢句話，Codex 唔可以係個擅長寫 Code 嘅 Agent，佢必須能處理各種文件格式，支持各領域嘅專業工作流，仲要讓用戶能喺佢裏面完成全程閉環，包括最後嘅人工微調。
目前 Codex 仲做唔到最後一步：生成之後無法編輯，Code、Markdown、PPTX 都唔得。
作者推測可能係產品上有意為之嘅剋制，可能係技術上未跑通，亦可能係等緊一個統一嘅解決方案。作者認為係第三種。
MCP 同 Skill 只解決咗一半：二次編輯嘅缺口
要理解 Codex 喺等乜，要先諗清楚 Agent 能力拼圖裏面而家差邊一塊。MCP 解決咗「連接」問題：Agent 透過統一規範接入各種工具，數據庫、日曆、代碼倉庫都能打通。Agent Skills 解決咗「點樣做」嘅問題：Agent 學識咗佢冇訓練過嘅領域知識同最佳實踐。
呢兩件事做得都仲唔錯，但有一塊缺口始終未補上：用戶嘅二次編輯。
就算將來 AI 再聰明，佢都做唔到百分百懂你，最後嗰 5% 嘅精準度，始終要自己動手。於是最近 Markdown 編輯器又火了，各種 Vibe Coding 出嚟嘅 Markdown 產品滿天飛。但 Codex 唔會自己做一個 Markdown 編輯器。
下一步：Agent 版 App Store 同留俾中小團隊嘅窗口
插件機制仲可以順手解決一個長期冇答案嘅問題：Skill 冇辦法商業化。作者自己嘅 baoyu-skills 快 2 萬 Star 了，但從中賺到嘅錢係 $0。Skill 呢樣嘢幾乎係透明嘅，對 Agent 透明，對人都透明，復刻成本極低，護城河好淺。
插件唔一樣：App Store 同 Chrome 插件市場已經跑通咗一套收費同版權保護機制，移植到 Agent 插件市場完全可行。
Codex 而家已經有一個非常原始嘅插件市場。從嗰度到成熟嘅收費插件生態，仲有好長嘅路，但方向係啱嘅。想做呢件事嘅唔止 Codex 一家。Cursor 都有類似影子。唯獨 Claude Code 同 Cowork，目前未見到呢個方向嘅產品跡象。
- 做一個垂直 Agent，由零開始建立調度層同用戶羣。
- 在 Codex 呢類平台上做插件，專注最後一公里，靠平台分發用戶。
呢排我密密用 Codex App、Cursor 呢啲 Agent 應用，有樣嘢越嚟越覺得得意。
舊年大家爭嘅係邊個模型更勁，今年爭嘅好似變咗係邊個視窗右邊好用啲。
Codex、Claude Desktop、Cursor 3.0、TRAE SOLO，呢幾間最頂尖嘅 Agent，喺完全冇協商嘅情況之下，幾乎同時間收斂到同一個界面佈局：左邊係項目同對話列表，中間係同 Agent 對話，右邊係工作區，放咗檔案瀏覽、網頁預覽、檔案變更審查呢啲功能。
肯定唔係互相抄襲，更加似係而家 Agent 交互嘅最優解。
傳統 Chatbot 只需要兩欄，左邊會話歷史，右邊對話視窗，你問佢答，用完就走得。
到咗 Agent 時代，Agent 可以自己寫 Code、改檔案、調用工具喇。佢做完之後，你要睇下佢有冇做啱——右邊工作區就係為咗呢件事而出現嘅。
但呢個只係第一階段。
隨住用戶越嚟越多時間係指揮 Agent，開 VSCode 呢類專業工具嘅時間自然越嚟越少。嗰個問題遲早會出現：Agent 幫你寫完 Code、做完 PPT，你想微調幾個字，仲要專登切出去開另一個軟件？
冇人想咁樣。用戶嘅自然期望係：可唔可以直接喺 Agent 入面改？呢個都係而家 Codex App 呼聲最高嘅功能之一（另一個呼聲高嘅係手機版，就快出喇）。
於是各家開始靜雞雞升級右邊工作區，令佢由淨係睇到檔案編輯記錄，變成咗一個多功能區。Codex 喺 4 月 16 日嘅大版本更新入面，右邊工作區嘅改動幅度係所有功能入面最大嘅。
交互細節上各家有少少唔同。Codex 同 Cursor 用 Tab 切換，Claude 用浮動面板。我自己用落覺得 Codex 最就手，Claude 嘅浮動面板方案設計感有餘、實用性不足，遲早要改。
Codex 嘅真正野心
但如果淨係將呢個變化解讀成『設計界面進化』，咁就低估 Codex 喇。
Codex 4 月大版本發佈嘅口號係『Codex for (almost) everything』——幾乎任何任務都做到。你可以當佢係一句廣告口號，但更加似係一個產品方向嘅聲明。
要兑現呢句說話，Codex 唔可以淨係一個擅長寫 Code 嘅 Agent，佢必須要處理到各種檔案格式，支援各領域嘅專業工作流程，仲要令用戶可以喺佢入面完成全程閉環，包括最後嘅人手微調。
目前 Codex 仲做唔到最後一步：生成之後冇得編輯，Code、Markdown、PPTX 都唔得。呢個可能係產品上有意嘅剋制，可能係技術上仲未搞掂，亦可能係等緊一個統一嘅解決方案出現。
我估係第三種。
MCP 同 Skill 都只係解決咗一半
要理解 Codex 等緊啲乜，就要先諗清楚 Agent 能力拼圖入面而家爭邊一塊。
• MCP 解決咗『連接』問題：Agent 透過統一規範接入各種工具， Database、日曆、Code Repository，全部打通到。 • Agent Skills 解決咗『點樣做』嘅問題：Agent 學識咗佢冇訓練過嘅領域知識同最佳做法，例如點樣寫特定風格嘅文章，點樣處理某類複雜任務。
呢兩件事做得都唔錯。但係有一塊缺口始終未補返：用戶嘅二次編輯。
你叫 AI 寫完一篇文章，最後都係要自己開編輯器改幾個地方，畢竟好多時最後嗰 5% 嘅準確度，得自己動手先至到位。就算將來 AI 再聰明，佢都做唔到百分百明你，始終都要人手去改。
於是最近 Markdown 編輯器又爆紅，各種 Vibe Coding 出嚟嘅 Markdown 產品周圍都係。
但 Codex 唔會自己做一個 Markdown 編輯器，因為每個人嘅偏好都唔同，做出嚟永遠有人唔滿意；何況佢都冇可能將每個垂直領域嘅專業編輯器都集成入嚟。
最合理嘅路，係插件機制。
下一步：Agent 版 App Store
將 Agent 整成平台，俾社區貢獻插件，就好似 VSCode 同 Chrome 咁。
Codex 只需要專注喺 Agent 調度呢一層，將檔案預覽、二次編輯、垂直領域嘅專業能力都交俾插件嚟擴展。用戶按需要安裝，做設計嘅裝設計插件，寫作嘅裝寫作插件。
插件機制仲可以順便解決一個長期冇答案嘅問題：Skill 冇辦法商業化。
我自己嘅 baoyu-skills 快 2 萬 Star 喇，但從中賺到嘅錢係 $0。Skill 呢樣嘢幾乎係透明嘅，對 Agent 透明，對人都透明，復刻成本超低，唔理你寫得有幾好，護城河都好淺。
插件唔同。App Store 同 Chrome 插件市場已經行通咗一套收費同版權保護機制，將佢移植到 Agent 插件市場完全可行。好嘅插件可以收費，開發者先有持續打磨嘅動力，生態先至真正轉得起。
Codex 而家已經有一個好原始嘅插件市場。由呢度去到成熟嘅收費插件生態，仲有好長嘅路，但方向係啱嘅。
想做呢件事嘅唔止 Codex 一間。Cursor 我都見到類似嘅影子。唯獨 Claude Code 同 Cowork，目前睇唔到呢個方向嘅產品跡象——可能佢哋唔志在做，可能只係未行到呢一步。
留俾中小團隊嘅窗口
如果 Codex 真係行通咗插件生態，對中小團隊嚟講意味住啲乜？
除咗自己做一個垂直 Agent，仲有另一條路：喺 Codex 呢啲平台上做插件。唔使自己搭 Agent 調度層，唔使自己搞 Token 接入，用戶分發都靠平台。你只需要專注喺嗰個『最後一公里』——幫用戶將 Agent 生成嘅結果處理好、編輯好、用得就手。
呢個窗口唔會開得太耐。早入去嘅可以拎到冷啟動紅利，遲入去嘅得返存量競爭。
時間點唔會太遠，可能就係呢幾個月。
Codex 嘅野心擺喺度，『幾乎任何任務』呢個口號要真正兑現，插件機制係繞唔過嘅一步。如果 OpenAI 喺呢件事上繼續猶豫，咁先係真正嘅失誤。
你覺得呢個插件生態最後會係邊間先跑通？或者你覺得有冇更適合 Agent 嘅產品表現形式？歡迎留言分享！
這段時間我在密集使用 Codex App、Cursor 等 Agent 應用，有件事越來越覺得有意思。
去年大家爭的是誰家模型更強，今年爭的好像變成了誰家窗口右側更好用。
Codex、Claude 桌面版、Cursor 3.0、TRAE SOLO，這幾家最頂尖的 Agent，在完全沒有協商的情況下，幾乎同時收斂到了同一個界面佈局：左側是項目和會話列表，中間是和 Agent 的對話，右側是工作區，放着文件瀏覽、網頁預覽、文件變更審查這些功能。
肯定不是相互之間的抄襲，更像是當前 Agent 交互的最優解。
傳統 Chatbot 只需要兩欄，左邊會話歷史，右邊對話窗口，你問它答，用完走人。
到了 Agent 時代，Agent 能自己寫代碼、改文件、調工具了。它做完之後，你得看看有沒有做對——右側工作區就是為這件事出現的。
但這只是第一階段。
隨着用戶越來越多時間是在指揮 Agent，打開 VSCode 這類專業工具的時間自然越來越少。那個問題遲早會冒出來：Agent 幫你寫完代碼、做完 PPT，你想微調幾個字，還要專門切出去打開另一個軟件？
沒有人願意這樣。用戶的自然期待是：能不能直接在 Agent 裏改？這也是目前 Codex App 呼聲最高的功能之一（另一個呼聲高的是手機版，馬上要出了）。
於是各家開始悄悄升級右側工作區，讓它從只能看文件編輯記錄，變成了一個多功能區。Codex 在 4 月 16 日的大版本更新裏，右側工作區的改動幅度是所有功能裏最大的。
交互細節上各家略有差異。Codex 和 Cursor 用 Tab 切換，Claude 用浮動面板。我自己用下來覺得 Codex 最順手，Claude 的浮動面板方案設計感有餘、實用性不足，遲早要改。
Codex 的真正野心
但如果只把這個變化讀成“設計界面進化”，就低估 Codex 了。
Codex 4 月大版本發佈時的口號是“Codex for (almost) everything”——幾乎任何任務都能做。你可以把它理解成一句廣告口號，但更像是一個產品方向的聲明。
要兑現這句話，Codex 不能只是個擅長寫代碼的 Agent，它必須能處理各種文件格式，支持各領域的專業工作流，還要讓用戶能在它裏面完成全程閉環，包括最後的人工微調。
目前 Codex 還做不到最後一步：生成之後無法編輯，代碼、Markdown、PPTX 都不行。這可能是產品上有意為之的剋制，可能是技術上還沒跑通，也可能是在等一個統一的解決方案出現。
我猜是第三種。
MCP 和 Skill 都只解決了一半
要理解 Codex 在等什麼，得先想清楚 Agent 能力拼圖裏現在差哪一塊。
• MCP 解決了“連接”問題：Agent 通過統一規範接入各種工具，數據庫、日曆、代碼倉庫，都能打通。 • Agent Skills 解決了“怎麼做”的問題：Agent 學會了它沒訓練過的領域知識和最佳實踐，比如怎麼寫特定風格的文章，怎麼處理某類複雜任務。
這兩件事做得都還不錯。但有一塊缺口始終沒補上：用戶的二次編輯。
你讓 AI 寫完一篇文章，最後還是要自己打開編輯器改幾處，畢竟很多時候最後那 5% 的精準度，只有自己動手才能到位。就算將來 AI 再聰明，它也做不到百分百的懂你，還是少不了要手動去做修改。
於是最近 Markdown 編輯器又火了，各種 Vibe Coding 出來的 Markdown 產品滿天飛。
但 Codex 不會自己做一個 Markdown 編輯器，因為每個人的偏好都不一樣，做出來永遠有人不滿意；更何況它也不可能把每個垂直領域的專業編輯器都集成進來。
最合理的路，是插件機制。
下一步：Agent 版 App Store
把 Agent 做成平台，讓社區來貢獻插件，就像 VSCode 和 Chrome 那樣。
Codex 只需要聚焦在 Agent 調度這一層，把文件預覽、二次編輯、垂直領域的專業能力都交給插件來擴展。用戶按需安裝，做設計的裝設計插件，寫作者裝寫作插件。
插件機制還能順手解決一個長期沒有答案的問題：Skill 沒辦法商業化。
我自己的 baoyu-skills 快 2 萬 Star 了，但從中賺到的錢是 $0。Skill 這東西幾乎是透明的，對 Agent 透明，對人也透明，復刻成本極低，不管你寫得再好，護城河都很淺。
插件不一樣。App Store 和 Chrome 插件市場已經跑通了一套收費和版權保護機制，把它移植到 Agent 插件市場完全可行。好插件可以收費，開發者才有持續打磨的動力，生態才真正能轉起來。
Codex 現在已經有了一個非常原始的插件市場。從這裏到成熟的收費插件生態，還有很長的路，但方向是對的。
想做這件事的不止 Codex 一家。Cursor 我能看到類似的影子。唯獨 Claude Code 和 Cowork，目前沒看到這個方向的產品跡象——也許他們不屑於做，也許只是還沒走到這一步。
留給中小團隊的窗口
如果 Codex 真的跑通了插件生態，對中小團隊意味着什麼？
除了自己做一個垂直 Agent，還有另一條路：在 Codex 這樣的平台上做插件。不用自己搭 Agent 調度層，不用解決 Token 接入，用戶分發也靠平台。你只需要專注在那個“最後一公里”——幫用戶把 Agent 生成的結果處理好、編輯好、用得順手。
這個窗口不會開太久。先進去的能拿到冷啓動紅利，晚進去的只剩存量競爭。
時間點不會太遠，也許就在這幾個月。
Codex 的野心擺在那裏，“幾乎任何任務”這個口號要真正兑現，插件機制是繞不過去的一步。如果 OpenAI 在這件事上繼續猶豫，那才是真的失誤。
你覺得這個插件生態最後會是哪家先跑通？或者說你覺得有更適合 Agent 的產品表現形式？歡迎留言分享！