以 Codex 為平台：運用開放的智慧體任務執行框架打造產品

多數人是透過 App、指令列介面或 IDE 擴充功能認識 Codex。這些使用體驗很重要，但只是同一套底層系統的幾種應用方式。

這些體驗都由開源 Codex 任務執行框架驅動。它協助模型收集上下文、透過推理處理任務、使用工具、在設定的界線內運作、要求核准，並持續推進工作。

這改變了開發人員能打造的產品。你不必要求每個團隊都將工作搬到通用的程式碼編寫助理中，而是可以將智慧體帶入針對實際工作設計的軟體：工程工作流程、營運儀表板、安全調查、客戶支援主控台，或專為特定專業團隊打造的內部應用程式。

可重複使用的部分是智慧體迴圈

一個有能力的智慧體，並非只有提示詞和模型回應。它需要一套機制來理解任務、持續維護上下文、查看相關資訊、呼叫工具、呈現進度、處理失敗、在必要時要求人工核准，並傳回有用的結果。

這套支撐智慧體運作的執行系統，就是任務執行框架。

任務執行框架的設計能大幅影響結果：在 ARC-AGI-3 上，保留推理內容與壓縮上下文，讓 GPT-5.6 Sol 的分數從 13.3% 提升至 38.3%，同時將輸出 Token 數量降至原本的六分之一。

我們打造 Codex 任務執行框架，用來管理對話狀態、串流傳送執行過程、使用工具、落實設定的沙盒與核准政策，並在不同回合之間延續工作。透過 Codex app-server，我們以有文件說明的用戶端通訊協定提供這些能力：應用程式可以建立對話串、啟動回合、接收事件，以及處理核准要求。

如果你正在開發需要智慧體的軟體，可以從 Codex 開始，不必另建一套執行環境，再決定外圍應用程式應負責哪些部分。

開發人員可檢視與調整的開放任務執行框架

由於任務執行框架是開源的，你可以檢視應用程式與模型之間的這一層，了解其運作方式，並調整整合方式以符合產品需求。

這讓開發人員能掌控下列部分，使智慧體更契合自己的產品：

• 介面。團隊可以保留既有的儀表板、編輯器、佇列、地圖、紀錄及核准流程，不必將所有互動都塞進通用的對話視窗。

• 上下文與工具。應用程式可以提供特定工作流程所需的系統、文件、資料與動作，包括由應用程式管理的 MCP 服務。

• 運作界線。主應用程式可以決定智慧體在哪裡執行、能存取哪些檔案或工具、哪些動作需要核准、如何觀察工作過程，以及如何將結果傳回權威紀錄系統。

我們以開源元件的形式發布 Codex CLI、app-server 及官方 Codex SDK。我們的開源元件指南列出了可用元件及各元件的所在位置。

開源範圍涵蓋任務執行框架與整合介面；模型存取和代管服務仍是獨立項目。

選擇合適的整合層

以 Codex 為基礎開發時，不必為每種使用案例採用相同的整合方式。

• 對於指令碼、CI 作業或一次性的背景任務，codex exec 可以執行範圍明確的智慧體工作流程，並傳回結構化輸出。

• 如果應用程式碼需要啟動、繼續執行 Codex 任務，或以串流方式接收任務進度，官方 Codex SDK 提供了可直接透過程式操作的介面。

如需可執行的範例，請參閱 Codex SDK 文件。

當智慧體是產品本身的一部分時，請使用 Codex app-server。它讓應用程式能連線至本機 Codex 處理程序、保持對話開啟、串流傳送事件、中斷工作、提供工具，以及回應核准要求。SDK 簡化了常見的程式化工作流程；app-server 則讓產品團隊能直接掌控生命週期與使用者體驗。

圍繞工作流程打造軟體

最值得探索的機會，不是換個標誌重製 Codex App，而是打造符合特定使用者或團隊既有工作方式的軟體：

安全分析師可能需要調查佇列、近期警示、受影響的服務，以及建立修復工單前的核准步驟。支援工程師可能需要帳戶歷程、產品日誌、內部文件和回覆草稿。產品團隊可能想要一個任務看板，將議題移至就緒狀態時，就能啟動範圍明確的實作工作流程。

在每個範例中，介面都是體驗的重要部分。它讓智慧體知道使用者正在查看什麼，提供合適的工具，也讓使用者有個地方可以審查接下來的動作。

範例：Relay

我們以 Codex app-server 為基礎，打造了營運應用程式範例 Relay。它在虛構的貨運儀表板旁加入智慧體，連接至應用程式管理的 MCP 工具，並要求在重新預訂貨運之前取得人工核准。

使用者不必從零開始撰寫提示詞，只需選取一筆貨運，再點選 比較補救方案等動作。應用程式會提供相關上下文，Codex 會擷取最新的營運範例資料，智慧體則會說明可用選項，而任何會產生重大影響的寫入操作都需要核准。

接著，Codex 可以使用應用程式的 MCP 工具取得最新資料，再建議採取某項動作，或在獲得核准後執行該動作。當工具變更底層紀錄時，應用程式會更新業務檢視。任務執行框架負責智慧體迴圈、對話狀態、活動的串流傳送及工具互動；產品則繼續掌管自己的儀表板、紀錄與控制機制。

Relay 使用預先填入的虛構資料，但這種整合模式具有通用性。同樣的模式也能用於事件回應、帳戶營運、研究工作流程，或其他需要讓智慧體在既有產品體驗中運作的應用程式。

開發人員正在打造的應用

這種模式已出現在公開的實作案例中：

• GitHub 與 JetBrains

  將 Codex 帶入既有的 IDE 工作流程。

• Cisco

  在 Cisco Cloud Control 的 App Builder 中使用 Codex SDK。

• Thrive Holdings 與 Crete

  在納入稅務從業人員回饋的報稅準備工作流程中使用 Codex。 他們的試行計畫處理了 7,000 份申報表，並將準備時間縮短了 約三分之一。

這些案例不限於工程領域：同樣的模式也適用於調查客戶問題的支援團隊、協調工作流程的營運團隊、分流處理事件的安全團隊、研究客戶的業務團隊，以及規劃行銷活動的行銷團隊。在每種情境中，應用程式都負責提供上下文、工具與核准機制，而 Codex 則驅動底層的智慧體迴圈。

探索更多開發可能

在許多工作中，關鍵上下文存在於儀表板、時間軸、地圖、文件或系統紀錄中。這些檢視畫面不只是為了美觀，而是人們理解現況、做出決策並維持掌控的實際方式。

機會不在於用一個通用的對話框取代這些介面，而是為它們加入智慧體，擴充介面的能力。這個智慧體能理解工作、探查相關上下文、提出下一步建議，並執行已核准的動作。

Codex App、CLI 與 IDE 擴充功能展示了任務執行框架的能力。我們將任務執行框架開源，讓開發人員能檢視、整合並調整這些能力，以符合自己的產品與工作流程。

如果你想運用 Codex 任務執行框架開發產品，可以從開源 Codex 程式碼庫開始，再選擇適合產品的整合方式：非互動式作業可使用 codex exec；透過程式操作的智慧體工作流程可使用 Codex SDK；需要持續對話、串流事件及核准處理的應用程式，則可使用 Codex app-server。