一件事，跟它旁邊那件更重要的事
這則消息本身很單純：OpenAI 把 Codex 從一個工具變成一個可以接進去的平台。你現在可以拿它的命令列在 CI 裡跑單次任務、用官方 SDK 從自己的程式驅動它、或是透過 app-server 這一層把整個 agent 嵌進你自己的產品介面裡。
旁邊那件更重要的事是：他們同時明確講了什麼不給。模型不給，託管推理不給。外殼是你的，燃料要買。這句話值得放大來看，因為它把這整個系列的三篇文章串成了一條線。
OpenAI 在 2026 年 8 月 19 日發表文章，說明 Codex 現在以平台形式開放，包含三層介面：單次執行的 codex exec、官方 SDK、以及提供持續對話、串流輸出、中斷執行與動作核准的 app-server，並附上一個名為 Relay 的範例應用程式作為參考實作。程式碼在 openai/codex，採用 Apache-2.0 授權（2025-04-13 建立，2026-08-21 查得 109,089 stars）。
官方在同一篇文章裡畫了界線：開放的是 harness 與整合介面，模型存取與託管服務仍然分開。換句話說外殼免費、推理付費。文中提到的第三方採用例子（Cisco 的 App Builder 情境、Thrive Holdings 與 Crete 的報稅試點約 7,000 份報表、準備時間減少約三分之一）屬於廠商發表的客戶案例，沒有揭露量測方法與對照組，適合當作「有人接進生產環境了」的存在性證據，不適合當作效率幅度的依據。
本文對「為什麼送外殼、留模型」的解讀為筆者分析，非官方說法。若下文與此摘要衝突，以此摘要為準。
開放的三層，分別解決什麼問題
這三層不是三個功能等級，而是三種你跟 agent 之間的關係。選錯層的代價不是少了功能，而是你會花大量力氣去模擬另一層本來就給你的東西。
單次執行。給它一個任務，它做完，結束。輸入輸出就是命令列那一套，所以它天然適合被塞進任何已經存在的自動化裡——CI 流程、排程腳本、git hook。
這一層的價值在於它不需要你的系統理解任何 agent 的概念。對呼叫方來說，它就是一個比較聰明的命令列程式。
當你要的不只是「跑完」，而是要把 agent 的產出接進後續邏輯——依結果分支、寫進資料庫、觸發下一步——命令列那層的字串進字串出就開始礙事了。SDK 這一層讓你用程式語言直接驅動，並拿到結構化的結果。
這一層是這次開放裡最有份量的部分，因為它處理的是單次呼叫在本質上表達不了的四件事：持續的對話狀態、串流輸出（讓使用者看到它正在做什麼，而不是盯著一個轉圈圈）、中斷執行（讓人可以喊停）、以及動作核准（讓人可以在危險的一步之前說可以或不可以）。
這四件事任何一件自己實作都不算難，但湊在一起、而且要在錯誤與逾時的情況下都還正確，是相當可觀的工程量。把它們一起送出來，等於省掉了自己寫 agent 產品時最麻煩的那一段。官方另外提供了一個名為 Relay 的範例應用程式，可以當作參考實作來讀。
由下往上試，不要由上往下。先確認 codex exec 能不能滿足需求——如果你的情境本來就是「跑完給我答案」，那上面兩層提供的東西你一項都用不到，卻要付出全部的整合成本。往上走應該是被需求逼上去的，不是一開始就選最完整的那個。
界線畫在哪裡，以及它為什麼是主動畫的
大部分廠商在講「我們開源了」的時候，不會順便告訴你哪些東西沒開源——那是留給讀者自己去發現的。這次不太一樣。
官方在同一篇文章裡直接寫明：開放的是 harness 與整合介面；模型存取與託管服務仍然是分開的。
來源：OpenAI Developers〈Codex as a platform〉，2026-08-19。原文為英文，此處為本文翻譯。
把這句話翻成使用者聽得懂的版本：你可以把整台車拆開來看、改裝、裝到別的底盤上，甚至拿去賣；但油要跟他們買。
下面這張表把「你拿到什麼、你沒拿到什麼」列清楚，因為這是最容易在轉述中被含糊帶過的部分：
| 項目 | 是否開放 | 說明 |
|---|---|---|
| Codex CLI | 是 | Apache-2.0，可商用、可修改、可再散布 |
| Codex SDK | 是 | 官方維護，供程式驅動 agent 使用 |
| app-server | 是 | 持續對話、串流、中斷、動作核准 |
| Relay 範例應用 | 是 | 參考實作，示範怎麼接 app-server |
| 模型權重 | 否 | 未開放 |
| 託管推理服務 | 否 | 需付費或訂閱 |
授權與 repository 事實於 2026-08-21 以 GitHub API 查得：openai/codex，Apache-2.0，建立於 2025-04-13，109,089 stars。
為什麼被送出來的偏偏是外殼
如果你讀過本系列前兩篇，這裡會有一個看起來矛盾的地方需要解釋。
上一篇談的是：同一個模型換個外殼，分數可以差三倍。那外殼顯然很值錢——既然這麼值錢，為什麼送？
我的解讀是這樣的，這部分是分析不是官方說法：
因為外殼別人做得出來，模型做不出來
外殼是工程。它需要品味、需要大量真實使用的磨練，但它終究是別人只要有足夠動機就做得出來的東西。事實上市面上已經有好幾份不同來源的 agent 外殼。守著一個遲早會被複製的東西，換不到什麼。
模型與託管推理則相反：那是持續性的收入，也是真正難以被複製的資產。守可守的，送守不住的，這在商業上是清楚的取捨。
因為外殼被越多人接走，模型的入口就越多
這是更直接的那一半。每一個把 app-server 接進自己產品的團隊，都變成了一個把流量導向該公司模型的入口。送出外殼不是放棄控制，而是換一種控制方式——從「你來用我的產品」變成「你的產品裡跑著我的東西」。
寬鬆授權讓你可以修改與再散布外殼，但你的系統會因此在架構上假設某一家的 agent 形狀。真正的鎖定通常不發生在授權條款上，而發生在你的產品邏輯開始依賴某一層介面的行為細節之後——串流事件長什麼樣、核准流程怎麼表達、中斷之後狀態如何恢復。這些不寫在授權裡，但換掉它們的成本是真的。
官方提到的採用案例，該怎麼讀
發表文章裡提到了幾個第三方採用的例子：Cisco 把它用在 App Builder 這類產品情境；Thrive Holdings 與 Crete 在報稅流程上做了試點，被描述為處理約 7,000 份報表、準備時間減少約三分之一。
這類數字的正確讀法是：當成存在性證據，不當成效率證據。
- 可以推論的：有具名的公司真的把這套東西接進了生產環境，而且是在報稅這種錯了會有實際後果的領域。這比任何示範影片都有說服力。
- 不能推論的：「減少約三分之一」代表你也會減少約三分之一。沒有揭露基準線、量測方法與對照組，也沒有第三方複驗，這個比例無法遷移到你的情境。
這跟上一篇談 benchmark 時的原則是同一個：數字的證據等級，取決於它是誰量的、跟什麼比、有沒有人能複驗。廠商與客戶共同發表的成果數字，在這三題上通常都是空的。
那你該做什麼
如果你在做一個要嵌入 agent 的產品
那麼「自己寫一套 agent 迴圈」這個選項剛剛變得比較不划算了。串流、中斷、核准、對話狀態這四件事現在有一份被大量實際使用磨過的實作可以拿。把力氣省下來，花在你真正無法外包的那一層。
如果你只是在用 agent 幹活
那這則消息對你的直接影響大概是零，而這也值得老實講。你不會因為外殼開源了就變快——你原本用的就是這個外殼。
但它有一個間接的意義：它確認了外殼這一層正在變成公共財。當每個人都拿得到同一份外殼，差異就只能來自你餵給它的環境——你的工具長什麼樣、你的文件怎麼組織、你的錯誤訊息有沒有夾帶修法、你的回饋迴路多久轉一圈。
不要把時間花在挑外殼上，花在整理外殼所面對的那個環境。前者現在是共用品，後者只有你自己能做。
常見問題
開放的是 agent 的外殼與整合介面，不是模型。具體來說有三層：可以直接在終端機或 CI 裡執行單次任務的 codex exec；讓你用程式驅動 agent 的官方 SDK；以及 app-server，一個提供持續對話、串流輸出、中斷執行與動作核准的介面層，讓你把 Codex 整個嵌進自己的應用程式。這些都在 openai/codex 這個 repository 裡，採用 Apache-2.0 授權，2025 年 4 月 13 日建立，截至 2026 年 8 月 21 日有 109,089 個 star，任何人都可以下載、檢視、修改與再散布。模型權重沒有開放，託管的推理服務也不在開放範圍內——實際跑起來仍然需要向模型供應商付費或持有訂閱。查證日期 2026-08-21｜來源：developers.openai.com/blog/codex-as-a-platform、GitHub API
看你要的是一次性的結果還是一段持續的關係。如果你要的是「跑完給我答案」——在 CI 裡自動修測試、在腳本裡批次處理檔案——用 codex exec 這種單次執行的形式最省事，它的輸入輸出就是命令列。如果你要在自己的程式裡驅動 agent、把結果接進後續邏輯，用官方 SDK。如果你要做的是一個有介面的產品，使用者會來回跟 agent 對話、需要看到它正在做什麼、需要能中途喊停或核准某個動作，那你需要的是 app-server 這一層，因為串流、中斷與核准這些狀態本來就不是單次呼叫能表達的東西。官方也提供了一個名為 Relay 的範例應用程式作為參考實作。查證日期 2026-08-21｜來源：developers.openai.com/blog/codex-as-a-platform
外殼免費，推理要付費。openai/codex 採用 Apache-2.0 授權，這是一份寬鬆的開源授權，允許商業使用、修改與再散布，你不需要為程式碼本身付任何費用。但 Codex 是一個外殼，它必須連到模型才能運作，而模型存取需要 OpenAI 的 API 付費或訂閱方案。開始的方式是先安裝 CLI 跑一次 codex exec 確認可以連通，再決定要往 SDK 還是 app-server 走——先確認最便宜的那條路能不能滿足需求，是比較不會後悔的順序。查證日期 2026-08-21｜來源：developers.openai.com/blog/codex-as-a-platform、GitHub API
因為兩者的可替代性不一樣。外殼是別人重寫得出來的——它是工程，是別人只要有足夠動機就能自己做一份出來的東西；而且外殼被越多人拿去接進自己的系統，導向該公司模型的入口就越多。模型與託管推理則是持續性的收入來源，也是真正難以被複製的資產。從結果看，這個組合對雙方都合理：使用者省下重造外殼的工程，供應商換到分發管道。但要理解的是這不是慈善也不是全面開放，而是一條刻意畫在特定位置的界線——官方自己的說法就是開放的是外殼與整合介面，模型存取與託管服務仍然分開。（本題中對商業動機的解讀為本文分析，非官方說法。）查證日期 2026-08-21｜來源：developers.openai.com/blog/codex-as-a-platform
應該當成廠商發表的客戶案例來讀，不是獨立評測。官方在這次的發表中提到了幾個第三方採用的例子，包括 Cisco 把它用在 App Builder 這類產品情境，以及 Thrive Holdings 與 Crete 在報稅流程上的試點——後者被描述為處理約 7,000 份報表、準備時間減少約三分之一。這些數字由廠商與其客戶共同發表，沒有揭露量測方法、基準線或對照組，也沒有第三方複驗，因此適合當作「有人真的把它接進生產環境了」的存在性證據，不適合當作效率提升幅度的依據。查證日期 2026-08-21｜來源：developers.openai.com/blog/codex-as-a-platform
主要影響在於「自己寫 agent 迴圈」這件事變得比較不划算了。過去要把一個 coding agent 嵌進自己的產品，你得自己處理工具呼叫迴圈、串流、中斷、上下文管理與動作核准，這些是相當可觀的工程量；現在其中一份已經被開放出來，而且是被大量實際使用磨過的那一份。反過來說，這也讓你的差異化位置往上移了一層——如果外殼是大家都拿得到的，那麼你的價值就不在外殼本身，而在你餵給它的環境：你的工具、你的文件結構、你的回饋迴路。這正是本系列前兩篇在講的事情。查證日期 2026-08-21｜來源：developers.openai.com/blog/codex-as-a-platform
結論：三篇合起來是同一句話
這個系列的三篇文章來自三個不同時間、看起來各自獨立的來源，但擺在一起會發現它們在講同一件事的三個切面。
把三句話疊起來，會浮出一個不太舒服但相當有用的結論：真正難以被複製的優勢，來自同時握住兩端——既能為了配合模型去改外殼，也能為了配合外殼去訓練模型。只握住一端的人，不管握的是哪一端，都在跟一個可以同時調整兩邊的對手比較。
但這對你不是壞消息，因為你不需要跟他們比。你要握住的是他們握不到的那一端：你自己的環境。你的程式碼長什麼樣、你的工具好不好用、你的錯誤訊息有沒有把修法一起講、你的文件是一張地圖還是一座墳場——這些沒有任何一家廠商能替你整理，而從這三篇文章的證據看，它們就是差距真正發生的地方。
本文對「為什麼開放外殼而保留模型」的商業解讀為筆者分析，非 OpenAI 官方說法。文中提及的第三方採用成果由廠商與其客戶共同發表，未揭露量測方法與對照組，亦無第三方複驗，本文僅將其視為採用的存在性證據。原文為英文，文中引文為本文翻譯。
主要來源：OpenAI Developers〈Codex as a platform〉（2026-08-19）全文、GitHub API（openai/codex repository 事實，2026-08-21 查得）。