作者 | Eran Stiller

譯者 | 劉雅夢

OpenAI 最近發(fā)布了 Codex 應(yīng)用服務(wù)器的詳細(xì)架構(gòu)描述，這是一個雙向協(xié)議，它將 Codex 編碼智能體的核心邏輯與其各種客戶端界面解耦。應(yīng)用服務(wù)器現(xiàn)在支持每一個 Codex 體驗，包括命令行界面（CLI）、VS Code 擴展、Web 應(yīng)用、macOS 桌面應(yīng)用，以及來自 JetBrains 和蘋果 Xcode 的第三方 IDE 集成，通過一個單一、穩(wěn)定的 API 實現(xiàn)。

這篇文章由 OpenAI 工程師 Celia Chen 撰寫，是 一系列 詳細(xì)介紹開源 Codex CLI 內(nèi)部結(jié)構(gòu)的文章之一。正如 Chen 所描述的，智能體交互與簡單的請求 / 響應(yīng)交換有著根本的不同：

一個用戶請求可以展開成一個結(jié)構(gòu)化的動作序列，客戶端需要忠實地表示：用戶的輸入、智能體的增量進度、沿途產(chǎn)生的工件。

Codex 應(yīng)用服務(wù)器的內(nèi)部架構(gòu)：標(biāo)準(zhǔn)輸入輸出（stdio）讀取器和 Codex 消息處理器將客戶端的 JSON-RPC 請求轉(zhuǎn)換為 Codex 核心操作，并將內(nèi)部事件轉(zhuǎn)換回穩(wěn)定的、UI 就緒的通知（來源）。

為了對此進行建模，OpenAI 設(shè)計了三個對話原語。項（Item）是輸入或輸出的原子單位，具有明確的生命周期：“開始”（started）、可選的流式“增量”（delta）事件和“完成”（completed）。這可以是用戶消息、智能體消息、工具執(zhí)行、審批請求或差異。輪次（Turn）將由單個智能體工作單元產(chǎn)生的項序列分組，由用戶輸入啟動。一個線程（Thread）是正在進行的會話的持久容器，支持創(chuàng)建、恢復(fù)、分叉和存檔，并保留事件歷史記錄，以便客戶端可以在不丟失狀態(tài)的情況下重新連接。

該協(xié)議還支持服務(wù)器發(fā)起的請求。當(dāng)智能體在執(zhí)行命令之前需要批準(zhǔn)時，服務(wù)器會向客戶端發(fā)送請求，并暫停輪次，直到收到“允許”或“拒絕”的響應(yīng)。通信使用 JSON-RPC 作為 JSONL 流式傳輸在 stdio 上，OpenAI 將其設(shè)計為向后兼容，以便舊版客戶端可以安全地與新版服務(wù)器通信。

值得注意的是，OpenAI 在最終確定這個設(shè)計之前嘗試并拒絕了 模型上下文協(xié)議（MCP）。Chen 解釋說，在構(gòu)建 VS Code 擴展時，團隊最初嘗試將 Codex 作為 MCP 服務(wù)器公開，但“在 VS Code 中維護 MCP 語義以使其有意義被證明是困難的?！盜DE 交互所需的更豐富的會話語義，如流式差異、審批流程和線程持久性，并沒有干凈地映射到 MCP 的工具導(dǎo)向模型上。OpenAI 仍然支持將 Codex 作為 MCP 服務(wù)器運行以適應(yīng)更簡單的工作流程，但建議使用應(yīng)用服務(wù)器來實現(xiàn)全保真集成。

帶有可選批準(zhǔn)的工具執(zhí)行的協(xié)議消息流。服務(wù)器暫停輪次并向客戶端發(fā)送請求，客戶端必須在智能體可以繼續(xù)之前用“允許”或“拒絕”響應(yīng)（來源）。

文章描述了客戶端用于嵌入應(yīng)用服務(wù)器的三種部署模式。像 VS Code 擴展和桌面應(yīng)用這樣的本地客戶端捆綁一個特定于平臺的二進制文件，將其作為子進程啟動，并保持一個雙向的標(biāo)準(zhǔn)輸入輸出通道開放。像 Xcode 這樣的合作伙伴通過保持客戶端穩(wěn)定而指向更新的應(yīng)用服務(wù)器二進制文件來解耦發(fā)布周期，允許他們采用服務(wù)器端改進而無需等待客戶端發(fā)布。

Codex Web 運行時采取了不同的方法：一個工作器配置一個容器，在其中啟動應(yīng)用服務(wù)器，瀏覽器通過 HTTP 和服務(wù)器發(fā)送事件進行通信——保持瀏覽器端 UI 輕量級。同時，對于長時間運行的任務(wù)，服務(wù)器仍然是數(shù)據(jù)源。

應(yīng)用服務(wù)器的演變與更廣泛的行業(yè)努力以標(biāo)準(zhǔn)化代理 - 編輯器通信相平行。由 Zed Industries 發(fā)起現(xiàn)在由 JetBrains 支持的智能體客戶端協(xié)議（Agent Client Protocol，ACP）采取了互補的方法：OpenAI 的應(yīng)用服務(wù)器是特定于 Codex 框架的協(xié)議，而 ACP 旨在成為連接任何編碼智能體到任何編輯器的通用標(biāo)準(zhǔn)，直接類比于十年前通過語言服務(wù)器協(xié)議（Language Server Protocol ）標(biāo)準(zhǔn)化語言工具的方式。Codex CLI 本身也被列為 ACP 兼容智能體之一。這些方法的共存反映了行業(yè)仍然在為智能體集成確定正確的抽象邊界——一個 OpenAI 承認(rèn)正在“快速演變”的空間。

Codex 應(yīng)用服務(wù)器的所有源代碼都可以在開源 Codex CLI 存儲庫中找到，協(xié)議文檔 包括用于 TypeScript 和 JSON Schema 的模式生成工具，以方便使用任何語言進行客戶端綁定。

https://www.infoq.com/news/2026/02/opanai-codex-app-server

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。