Codex 不只會寫程式：OpenAI 把 Agent 執行層開放後，開發架構會怎麼變？
Codex 正從 AI 寫程式工具變成可嵌入產品的 Agent 執行層。一次看懂 harness、SDK、app-server 與未來開發架構。
多數人認識 Codex，是從 App、終端機裡的 CLI，或程式編輯器中的擴充功能開始。你交代一個任務，它會讀程式碼、修改檔案、執行測試，再回報結果。
OpenAI 在 2026 年 8 月 19 日公布的 Codex as a platform，真正重要的地方不是又多了一種使用 Codex 的方法，而是把支撐這些能力的 Agent harness 開放給開發者。Agent harness 可以理解成「讓 AI 持續做事的執行系統」，負責保存任務狀態、蒐集資料、呼叫工具、限制權限、處理失敗與要求人工批准。
這代表開發團隊不必把使用者趕進另一個聊天視窗，也不一定要從零打造 Agent 執行層。原本的客服後台、資安面板、工單系統或垂直 SaaS，都可以保留自己的介面與業務規則，再把 Codex 接到需要推理與操作的流程中。
我的判斷是，這會影響未來幾年的 AI 產品架構，而且重要性高於單次模型升級。不過，團隊現在最實際的做法不是全面重寫系統，而是先挑一個高頻、可覆核、能清楚限制權限的流程做 MVP。
Codex as a platform 到底發布了什麼？
這次開放的核心不是模型權重，也就是決定模型如何運算、從訓練中學到什麼的核心參數；它也不是一個叫做「Codex API」的單一接口。OpenAI 把 Codex CLI、Codex SDK 與 Codex app-server 等元件公開，讓開發者依整合深度選擇接法。
其中最關鍵的是 Agent loop，也就是 AI 執行任務時不斷重複的工作循環：理解目標、取得 Context、採取行動、讀取結果、修正下一步，直到完成或需要人類介入。Context 是 Agent 當下能使用的工作背景，例如對話、檔案、系統紀錄與工具結果。
傳統的 AI 功能常是一個 Prompt 送進模型，再取得一段文字。真正要把 Agent 放進產品，還得處理更多問題：任務做一半如何續接、工具失敗怎麼恢復、哪些資料可以讀、哪些動作需要批准，以及執行進度怎麼顯示給使用者。Codex harness 提供的正是這一層。
OpenAI 也特別劃清邊界：開源的是 harness 與整合介面，模型存取和 managed services 仍是分開的服務。換句話說，開源 Codex 不等於可以免費取得 OpenAI 模型，也不代表整套雲端服務都能自行部署。
為什麼 Agent harness 比 Prompt 更重要？
Prompt 會影響模型如何回答，但 Agent 能不能可靠完成工作，還取決於它如何保存狀態、選擇工具、壓縮 Context 與處理權限。這些看似是工程細節，實際上會直接改變任務品質與成本。
OpenAI 在官方文章引用 ARC-AGI-3 測試：加入 retained reasoning 與 Context compaction 後，GPT-5.6 Sol 的分數從 13.3% 提升到 38.3%，輸出 Token 同時降為原本的六分之一。Context compaction 是把過長的工作歷程濃縮成仍可延續任務的內容，避免 Agent 每一輪都帶著全部紀錄工作。
這組數字不能直接套用到客服、開發或企業流程，卻證明了一件事：同一個模型放進不同的執行系統，表現可能差很多。未來比較 AI 產品時，不能只問「用了哪個模型」，還要問它如何管理 Context、工具、權限、失敗恢復與人工審批。
對產品團隊來說，這讓競爭焦點開始移動。模型能力仍重要，但真正難以複製的部分，會逐漸變成公司如何整理業務資料、設計工具、定義批准流程，以及累積可評估的任務紀錄。
未來開發架構會從「聊天功能」變成五層分工
過去要加入 AI，最常見的做法是在右下角放一個聊天框，再把使用者輸入送給模型。Codex 平台化後，更合理的架構會拆成五層：
| 層級 | 負責什麼 | 應由誰掌握 |
|---|---|---|
| 產品介面 | 顯示任務、紀錄、進度、比較結果與確認按鈕 | 原產品 |
| 業務 Context | 帳戶資料、工單、告警、文件與目前選取項目 | 原產品 |
| Agent loop | 規劃步驟、維持對話、呼叫工具、串流進度與處理失敗 | Codex harness |
| 權限與執行 | Sandbox、可用工具、批准規則與可觀測紀錄 | 雙方共同設計，產品負最終責任 |
| System of record | 訂單、客戶、程式碼、案件等正式紀錄 | 原產品 |
Sandbox 是受限制的執行環境，用來控制 Agent 可以讀寫哪些檔案、執行哪些指令。System of record 則是保存正式資料的系統，例如 CRM、訂單資料庫或 Git Repository。
這個分工最值得注意的是：AI 負責理解與推進工作，不代表 AI 擁有業務真相。 客戶餘額、貨運狀態、工單權限與最終發布狀態，仍應由原系統保存。Agent 可以提出下一步，也可以在獲得授權後呼叫工具，但不能靠對話內容自行改寫正式紀錄。
codex exec、Codex SDK、app-server 該怎麼選？
OpenAI 提供三種不同深度的整合方式。它們不是互相取代，而是對應不同產品需求。
| 整合方式 | 適合情境 | 開發成本 | 產品可控程度 |
|---|---|---|---|
codex exec |
Script、CI job、排程或一次性背景任務 | 低 | 低至中 |
| Codex SDK | 應用程式要啟動、繼續、恢復或串流 Codex 任務 | 中 | 中至高 |
| Codex app-server | Agent 成為產品核心，需要完整對話生命週期、事件、工具與批准介面 | 高 | 高 |
如果只是每天掃描錯誤紀錄並輸出報告，codex exec 已經足夠。這類任務有明確開始與結束，不需要長時間維持互動狀態。
如果後端服務要建立 Codex 任務、隔天恢復同一個 Thread，或把執行結果送回既有系統，Codex SDK 比較合適。SDK 是 Software Development Kit，也就是讓程式以較少整合工作呼叫 Codex 的開發套件。
當 Agent 本身就是產品體驗的一部分，才需要 app-server。它提供較底層的 Client Protocol，讓應用程式建立 Thread、開始 Turn、接收串流事件、暫停工作與處理批准。這能讓產品掌握完整 UX，但也代表團隊要承擔更多生命週期、版本、安全與錯誤處理責任。
我的建議很直接：能用 codex exec 驗證價值，就不要先做 app-server。只有當使用者確實需要長任務、即時進度、人工介入與自訂介面時，再往更深的整合層移動。
真正改變 UX 的地方：使用者不必先學會寫 Prompt
OpenAI 用 Relay 展示這套架構。Relay 是一個使用虛構資料的物流操作範例，畫面原本就有貨運異常清單、貨件細節與處理動作。使用者不必先想好 Prompt，只要選取一筆貨件，再按下「Compare recovery」，系統就會把相關 Context 交給 Codex。
Codex 接著透過產品自有的 MCP 工具取得最新資料、比較選項並解釋建議。MCP 是 Model Context Protocol，一套讓 Agent 連接外部資料與操作工具的共同規格。如果 Agent 要重新預訂貨運這類會改變紀錄的動作，Relay 會先要求人類批准。
這比聊天框更符合實際工作。使用者原本就透過表格、時間軸、地圖與案件頁面理解狀況，這些介面本身就是 Context。把 Agent 放進既有畫面，系統可以直接知道使用者在看哪一筆資料，也能在正確位置顯示證據、差異與批准按鈕。
對 UX 的真正影響不是「不用 Prompt」四個字，而是把 Prompt 需要描述的背景改由產品結構提供。使用者少打一段話，Agent 也少一次猜測。
PM 與開發團隊的規格要跟著改
如果 Agent 只是聊天功能，PRD 可能只會寫入口、對話框與回答格式。當 Agent 可以跨系統做事，規格至少要補上以下問題：
- 什麼事件啟動任務？ 是使用者按按鈕、工單移到特定狀態，還是排程自動開始？
- 系統提供哪些 Context？ 只給目前案件，還是允許查詢歷史紀錄與內部文件？
- Agent 可以使用哪些工具？ 哪些只能讀取，哪些會修改正式資料？
- 什麼情況必須人工批准？ 付款、刪除、發布、改價與通知外部使用者，通常不應全自動執行。
- 失敗後如何恢復？ 是重試、回到上一個安全狀態，還是交給人工接手？
- 結果如何驗收？ 只看 Agent 說「完成」不夠，還要從正式系統讀回結果並留下操作紀錄。
這也會改變工程分工。前端不只負責聊天 UI，而要顯示 Agent 正在做什麼、引用哪些資料，以及哪個動作等待批准。後端不只轉送模型請求，還要提供範圍清楚的工具與資料介面。QA 則要測試權限、失敗恢復、重複執行與人工拒絕等情境。
這個方向很重要，但不要忽略三個成本
第一個成本是整合綁定。Codex harness 雖然開源，使用 Codex SDK 或 app-server 仍會依賴它的 Thread、Turn、事件與權限模型。團隊應把業務規則與資料工具留在自己的服務層，避免把所有流程直接寫死在 Agent 專用介面裡。
第二個成本是安全責任。Agent 能讀檔、執行指令與修改系統後，風險不再只是回答錯誤。每項工具都要採最小權限，重要寫入要批准，操作要能追蹤，正式資料要能從 system of record 驗證。
第三個成本是評估。Agent 的路徑不一定每次相同，傳統只比對固定輸出的測試方式不夠。團隊要另外記錄任務成功率、人工介入率、錯誤寫入、執行時間與成本，才能知道 Agent 是否真的改善工作流程。
因此，我對 Codex 平台化的方向偏正面，但不建議把它理解為「以後所有軟體都改成 AI Agent」。更可能發生的是，軟體保留原本的介面、資料與控制權，再把一部分需要跨資料理解、調查與操作的流程交給 Agent。
最實際的導入方式：先做一條可控流程
適合第一個 MVP 的任務，通常有四個特徵：發生頻率高、輸入資料明確、結果可以人工覆核，而且做錯時不會立即造成不可逆損失。
例如，客服系統可以先讓 Agent 查詢帳戶紀錄與 Log，再草擬回覆，不直接寄出。資安面板可以整理告警與受影響服務，再由分析師決定是否建立修復工單。產品團隊也可以在工單進入 Ready 狀態後，讓 Agent 先讀需求、找相關程式碼並提出實作計畫。
第一版只要驗證三件事：Agent 取得的 Context 是否正確、產出的下一步是否值得採用，以及人工覆核能否阻止錯誤。當成功率與節省時間有穩定證據，再增加寫入工具或升級到 app-server 深度整合。
這種做法的維護成本最低，也最符合 MVP 精神。先證明一條流程值得自動化，再決定是否把 Agent 變成平台能力。
Codex as a platform 常見問題
Codex 現在是開源模型嗎？
不是。OpenAI 開源的是 Codex harness 與部分整合元件，包括 CLI、SDK 與 app-server。模型存取和 managed services 仍是分開的服務。
Codex SDK 和 OpenAI API 有什麼不同？
OpenAI API 讓開發者直接使用模型與工具能力；Codex SDK 則是以 Codex 的任務、Thread 與工程流程為中心，協助應用程式啟動、延續或恢復 Codex 工作。若需求只是一般文字生成，不一定需要 Codex SDK。
使用 Codex app-server 就不需要自己的後端嗎？
仍然需要。app-server 負責 Agent 生命週期與工具互動，產品自己的帳號、業務規則、資料庫與正式紀錄仍應由原系統管理。
所有 AI 功能都應改用 Agent 架構嗎？
不需要。摘要、分類與固定格式轉換等單一步驟功能，直接呼叫模型通常更簡單。只有任務需要多步推理、跨資料查詢、工具操作、長時間狀態或人工批准時，Agent harness 的價值才會明顯。
非工程團隊也會受到影響嗎？
會。OpenAI 展示的場景包含營運、客服、資安、研究、銷售與行銷。差別在於 Agent 被放進原本的工作介面，而不是要求每個人改用工程工具。
結論：未來的 AI 架構，重點是誰掌握工作流程
Codex 平台化真正改變的不是「AI 能不能寫程式」，而是開發者能否把一套成熟的 Agent loop 放進自己的產品。介面、業務 Context、資料、工具與批准規則仍由產品掌握，Codex 則負責維持任務、推進步驟與在受限制的環境中執行工作。
這會讓 AI 功能從獨立聊天框，逐漸變成軟體內部的一個執行層。對已經有客服後台、營運系統、開發流程或垂直 SaaS 的團隊來說，這個方向值得現在開始驗證。
但第一步不是做一個無所不能的 Agent。先找一條高頻、資料清楚、可以人工覆核的流程，用 codex exec 或 Codex SDK 做出 MVP。只有當長任務、串流進度與審批 UX 確實成為需求，再投入 app-server。這樣才能把平台化帶來的彈性，變成真正可維護的產品架構。
