OpenClaw 採用 Codex 引擎優化 OpenAI 代理運行時
OpenClaw 現在默認使用 Codex 應用服務器引擎來驅動 OpenAI 代理的模型循環，將底層模型推理與上層產品功能分離。這一變化減少了工具重複、提示膨脹和翻譯開銷，帶來了動態工具加載、更加清晰的消息傳遞和心跳機制，以及基於訂閲的認證。未來，這些改進將逐步惠及其他模型提供商。
OpenClaw 近日宣佈了一項重要更新：其平台現在默認使用 Codex 應用服務器引擎來驅動 OpenAI 代理的模型推理循環。這一改變旨在解決此前 OpenClaw 自行驅動模型循環時面臨的翻譯開銷、工具重複和提示膨脹等問題。
在舊架構中，OpenClaw 需要在其自身框架與 OpenAI 正在積極構建的代理運行時之間進行轉換。而現在，Codex 接管了底層的 OpenAI 循環，包括原生線程狀態、工具延續、壓縮、代碼模式和動態工具搜索。OpenClaw 則專注於使其代理成為用户專屬助手的產品功能：渠道、個性、記憶、會話、定時任務、媒體、瀏覽器、網關以及 OpenClaw 工具。
這一重新劃分邊界帶來了多項實際改進。首先，模型現在可以直接使用 Codex 原生的讀寫、編輯、修補、執行、進程和規劃工具，而無需在重複的工作空間工具之間做出選擇。其次，可見回覆現在通過 OpenClaw 消息工具有意發送，使內部推理保持私密，只有代理真正有話要説時才會產生可見輸出。心跳機制也得到升級，不再依靠“HEARTBEAT_OK”之類的標記文本，而是使用結構化心跳響應工具，明確表達“無報告”、“通知用户”或“安排跟進”等狀態。
最顯著的改進之一是動態工具加載。OpenClaw 代理可能擁有大量工具，包括消息、會話、媒體、定時任務、瀏覽器、節點、網關控制、網絡搜索、MCP 服務器、插件工具和特定於渠道的動作。過去，所有工具模式都會加載到初始提示中，導致提示龐大且模型容易選錯工具。現在，Codex 允許將 OpenClaw 產品能力作為動態工具傳遞，模型通過原生工具搜索按需發現並加載所需工具。這不僅減小了初始上下文，還提高了工具選擇的準確性。
對於非 OpenAI 用户而言，這一改進同樣有意義。OpenClaw 計劃將從 Codex 學到的模式應用到其默認的 PI 工具搜索中，允許所有模型受益於更緊湊的搜索、描述和調用接口。目前，PI 工具搜索仍處於實驗階段，尚未默認啓用。
在認證方面，用户可以使用 ChatGPT/Codex 賬户登錄 OpenClaw，即可通過訂閲獲得 Codex 認證配置文件，無需為同一模型付費兩次。API 密鑰可作為備份選項。OpenClaw 還為每個代理隔離了 Codex 狀態，確保個人 Codex CLI 設置不會被意外導入代理。
安全方面，Codex 引擎支持無限制本地執行和審核批准模式。OpenClaw 保留了外部審批路由、渠道交付、插件鈎子和可見故障報告，同時利用 Codex 的原生安全機制。
長遠來看，OpenClaw 旨在成為多模型平台，支持 Anthropic、Google、本地模型、OpenRouter、DeepSeek、Kimi、MiniMax 等。此次與 Codex 的整合是雙向的：在 Codex 最擅長的領域使用它，同時將優秀的設計思想（如更清晰的工具邊界、延遲目錄、結構化靜默結果、更好的提示範圍）帶回 OpenClaw 自身的 PI 引擎，最終提升所有模型的處理能力。