Codex

資料來源#

• Coding Agents and Technical Debt
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• How we use /goal to find bugs in Patch the Planet
• Models are worse at reviewing their own code
• OpenAI Codex lead on the new shape of product work
• The Shift to Agentic AI: Evidence from Codex

摘要#

Codex 是 OpenAI 的代理式程式設計與工作平台——在這份 wiki 中，它始終是 Claude Code 的 OpenAI 端對應產品。它於 2025 年 4 月以命令列工具形式發布，後來發展成多介面的代理 harness：採用執行緒化互動模型（每項任務各自擁有獨立工作區）、可重複使用的 skills 與可安裝的 plugins、用於程式化工作階段的無頭 App Server Protocol，以及將 Linear 轉化為控制平面的 Symphony 協調器。它原本是為軟體開發打造——這個領域的產出可驗證、具經濟價值且可模組化——如今用途已遠超程式碼，擴展到研究、撰稿、資料分析與營運工作。

在這份語料中的定位#

• 代理 harness。 以 GPT-5-series Codex models 為基礎；可執行多步驟、使用工具並修改檔案的任務。它的執行緒化模型讓平行代理協調成為可能——可同時執行許多彼此獨立的代理。
• 系統化層。 Skills（SKILL.md 工作流程規格）加上 plugins（可安裝的 skills、MCP 整合、hooks 套件），構成代理式工作系統化的基礎；skill 撰寫工作流程，plugin 負責散布。
• 無頭協定。 App Server Protocol（透過 stdio 傳輸的 JSON-RPC）能以非互動方式驅動 Codex，構成協調與類似 CI 的使用方式之基礎。
• 協調器。 Symphony（OpenAI 於 2026 年 3 月開源）會根據 Linear 看板協調每個 issue 的 Codex 工作區。
• 使用情況的研究對象。 OpenAI 於 2026 年 6 月發布的 轉向代理式 AI 研究，衡量個人、組織及 OpenAI 內部族群採用 Codex 的情形——2026 年上半年每週活躍使用量成長逾 5 倍，使用者也愈來愈多來自開發者圈以外。

桌面應用程式（Ambrosino 的說法）#

wiki 原有的 Codex 條目聚焦於 CLI 與協調堆疊。Andrew Ambrosino 在 2026 年 6 月的訪談談到的是桌面應用程式——一個有自身歷史與發展軌跡的獨立介面：

• 時間軸。 團隊於 2025 年 11 月啟動應用程式，先在內部試用，並於 2026 年 2 月發布。Ambrosino 強調這是個大小恰當的介面——「有點像聊天機器人，但功能更多；你能看到程式碼，但我們不會讓你編輯它」——刻意不把它做成 IDE。
• 使用情況（第一方、未經查證）。 他表示，OpenAI 全公司約 90% 的人（不只是工程師）都在使用 Codex，約 100% 的員工每週都會使用；每週活躍使用者超過 500 萬，自 1 月以來成長約 6 倍。這些數字屬於 vendor-claim 等級，來自產品主管。
• 從開發者工具走向一般知識工作。 內部一項關鍵發現是：非工程師（行銷、傳訊、財務、法務）也使用 Codex 應用程式，「儘管它對這些人其實很不友善」——會向他們顯示程式碼，還叫他們執行 rg。打造獨立的一般用途介面的嘗試都失敗了，因為「沒人願意離開 Codex 應用程式」。策略於是變成打造一個**「大本營」**——從簡單開始，再依各使用者的需求增加複雜度，並連接專門工具（它會呼叫財務用的 Excel 增益集；也會開啟其他應用程式來完成工作）——至於「super app」這個標籤，Ambrosino 說他很後悔得一直聽人提起。
• 自我延伸。 最具代表性的軼事是：OpenAI 內部的錄影師用 Codex 編輯發布影片；Codex 本身不是影片編輯器，於是自行打造 Premiere Pro 擴充功能，透過編輯底層檔案控制 Premiere，接著再與自己寫出的擴充功能互動。代理把自身延伸到原本並非為它設計的專門工具中。
• 互動模式設計。 應用程式整合了連接器、應用程式內瀏覽器（如今採用 Atlas「owl」堆疊並支援企業登入）、Chrome 擴充功能橋接，以及電腦操作——Ambrosino 說，在這些方式之間做選擇仍是個尚未定案的設計問題（例如鍵盤快速鍵對應，以及「瀏覽器是頂層功能還是只供代理使用」）。電腦操作讓它能在沒有 API 的使用者介面中「直接開始點擊」（例如 Google Cloud 控制台）。
• 作為 OpenClaude 式操作員的自動化。 Ambrosino 執行排程任務，把約 3,000 個 Slack 頻道的內容整理成每日摘要，再用自然語言指示後續工作——這正成為一種重要的一級模式，團隊希望讓非建置者也能免設定使用。

Ambrosino 談產品理念時也以這款應用程式為背景：實作豐沛如何顛覆產品工作、「二月推出的應用程式若在十一月推出就會失敗——改變的只有模型」，以及為何 AI 在設計上落後。

與 ChatGPT Work 合併（Nathan 的說法，2026 年 7 月）#

Ambrosino 訪談一個月後，Codex 不再是獨立產品。負責 OpenAI 生產力團隊產品工程的 Akshay Nathan，在 Latent Space 訪談中描述了結果（Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI，practitioner-opinion）：ChatGPT Work（2026 年 7 月 9 日推出）採用 Codex harness。 架構詳情見共用 Harness、差異化介面；以下是與 Codex 直接相關的資訊：

• 兩者確實共用同一個 harness，只有 UX 層會依介面加入特定設計：Git 狀態可見性（「動態島」預設使用者有 repo）、以 diff 為主的思路顯示方式，以及沙箱預設值。其他一切——plugins、電腦操作、產物、記憶體、子代理、排程任務——在兩種模式中都相同，這是基於一項原則：「你在桌面版產品的 Codex 部分能做的事，在 ChatGPT Work 也都能做，反之亦然。」
• 傳統 ChatGPT harness 仍用於聊天（針對延遲與個性化最佳化，執行「instant」模型）；如今知識工作採用 Codex harness，因為「如果你讓代理把電腦當成一個無限彈性的環境來使用，它就能做出非常強大的事。」Nathan 將 harness 的歷史描述為「分化、收斂、分化、收斂」，而非取代。在兩者之間路由是模型的決策，不是路由器的工作——「這是模型正在做的決定。」
• 採用情況（第一方、未經查證）。 OpenAI 表示，ChatGPT Work 與 Codex 在 7 月 9 日發布後兩週內合計達到 1,000 萬名使用者；由於 harness 合併，使用者數字也合併計算。Nathan 稱這是「一個階段的成果」，但強調整體 ChatGPT 有數億使用者，而且 Work 僅供付費使用者使用，且不會預設啟用。6 月稍早，OpenAI 表示知識工作者約占 Codex 使用者的 20%，其成長速度是開發者的 3 倍以上。以上皆屬 vendor-claim 等級。
• Codex 品牌會刻意保留。「開發者長期以來一直是我們的核心市場……這完全不會削弱這點。如果有什麼影響，反而會提高 Codex 這類工具的效用，因為你現在可以在撰寫 diff、建立產物或進行搜尋之間無縫切換。」
• Work 推動後新增的共用基礎功能：產物（以代理方式編輯 Excel／PowerPoint／Docs；Nathan 將模型端「相當顯著」的品質提升歸功於 GPT-5.4→5.5→5.6）；Sites（託管的 HTML，愈來愈常取代簡報與試算表，成為團隊的標準產物——見 HTML 成為新的 Markdown）；有檔案系統且檔案能在工作階段間保留的持續性電腦環境；以及排程任務。Nathan 認為最後兩項受到 OpenClaw 啟發：「它具備相同的基礎功能……排程任務、在檔案系統儲存檔案的能力，以及長期參照這些內容的能力。」
• Ultra（多代理模式）在發布後移至進階設定並改為選擇加入，因為它「可能會消耗更多使用額度」；子代理逐字稿預設隱藏。

從外部衡量程式碼庫（2026 年 7 月）#

這份語料中，唯一由第三方盤點 Codex 程式碼儲存庫的資料，來自競爭者：OpenHands 對 GitHub 十二個月活動所做的分析（Coding Agents and Technical Debt，case-study）。只看 openai/codex，截至 2026-07-08 的一年內：合併 7,688 個 PR，其中 1,202 個是錯誤修正（16%——在比較的四個 harness 中占比最低）、約變更 380 萬行、目前程式碼約 132 萬行——合併 PR 數量最多，程式碼庫規模則排名第二。更顯著的是成長速度：Codex 的合併 PR 數從 2025 年中每月約 124 個，增至一年後每月約 1,000 個。單一 repo 的架構也符合上述平台形態——「CLI、數十個核心執行階段 crates、一個 app server、MCP 支援，以及 Python 和 TypeScript SDKs」全都在同一個 repo，因此無論工作是在私人環境或其他地方進行，這份統計都低估了 Codex 的總工作量。見 Harness 自建與採購。

從外部追查 /review 功能（2026 年 7 月）#

Greptile 研究團隊以 Codex 的 /review 與 Claude Code 審查 1,000 個已標註的 pull request（同模型審查盲點，case-study；研究來自銷售競品審查工具的廠商）。兩項產品層級觀察與底層模型本身無關：Codex 的審查會留下 1–2 則評論，Claude Code 則有 7–8 則；GPT 5.5 的底層執行軌跡顯示，簡短至少部分來自提示與後訓練，而非能力不足——模型在推理中指出死鎖，最後卻只提交一項嚴重性較低的發現；加入要求提出 7–10 則評論的指示後，召回率便有所恢復。Caridad 的診斷是，OpenAI 預設的 /review 系統提示會積極縮小範圍以減少雜訊，而審議式對齊會讓模型在採取行動前權衡開發者與使用者的意圖：「模型並沒有不服從——它只是在完全照著訓練內容行事。」應將此結果視為對已發布預設行為的衡量，而非對 GPT 5.5 本身的評估。

/goal 的實際運用：Patch the Planet 安全工作（2026 年 7 月）#

這份語料中，對 Codex 功能要求最高的公開使用案例，來自安全顧問公司 Trail of Bits。該公司以 Codex 執行 Patch the Planet——與 OpenAI 合作、旨在找出並修正開源軟體錯誤的計畫——並將 Codex 用於 Rust、curl、zlib 與 Keycloak（2026-07-28，case-study；文章由活動共同冠名，也在推廣顧問公司的方法與這項產品，因此解讀其熱情時應納入考量）。以下四項產品層級資訊與底層模型無關：

• /goal 是一種模式，而不是斜線命令。 文章明確表示，文中使用 /goal「泛指以目標為基礎的提示」，Codex 可以透過工具呼叫為自己設定目標，這也是建議用法——「我們很少自己輸入斜線命令。」 有幾位工程師完全不再手寫目標，而是把威脅模型交給 Codex，請它草擬目標提示。
• Codex 會打造自己的安全基礎設施。 Trail of Bits 的摘要主張是：它「能在不到一天內建立安全研究人員需要數週才能打造的自訂安全基礎設施。」他們舉出的實例是協調器：把每個 rust-lang/rust P-critical issue 下載為 JSON，並為每個 issue 啟動一個 Codex 工作階段。
• 因為 Codex 會略過閱讀，所以才有這項工具。 他們打造並開源 aicov（github.com/trailofbits/aicov），追蹤 Codex 實際讀過哪些程式碼行，因為「即使明確要求，Codex 也常常不讀完整個程式碼庫」，因此這個工具能確保它「無法『作弊』」。這是專門針對該 harness 一項明確行為缺陷所推出的工具。
• 每個工作階段只設定一項成果，是實際運作的限制。 在同一個目標中設定相互競爭的成果（「找出錯誤」以及「達到高覆蓋率」）會造成最佳化不均；他們的解法是每個攻擊面各開一個 Codex 工作階段，另加一個開放式探索的代理。這就是上文所列執行緒化模型的實際應用。

由此產生的發現——rustc 的一處健全性漏洞與一項錯誤編譯問題，兩者都已在 Rust 1.98 修補；兩項可能的 Keycloak SAML 權限提升漏洞；以及 11 個 Semgrep CVE 變體命中——收錄於以 LLM 驅動的漏洞研究；目標設計規則則見迴圈工程。請留意，文章並未提供哪些產品資訊：執行次數、token 或成本數據、兩位裁判驗證流程的誤報率，以及除提示設計外的 /goal 失敗模式。

Codex 與 Claude Code#

這兩者是 wiki 的參考 harness，並且一再被拿來比較。迴圈工程的核心結構性主張是，兩者如今都提供相同的五項基礎功能（自動化、工作樹、skills、連接器／plugins、子代理），只是名稱不同，所以相同的代理迴圈在兩者上都能運作——這支持了模型進步帶來的 harness 收斂。兩者的差異在於所屬機構：Codex 位於 OpenAI 的 GPT-5 生態系，以及 Symphony／App-Server 協調堆疊內；Claude Code 則位於 Anthropic 生態系。OpenAI 於 2026 年 4 月提出的「harness engineering」框架，是 Codex 對代理優先工作流程的內部理念。

兩家廠商之外的審查者角色（DHH，2026 年 8 月）#

DHH（David Heinemeier Hansson）並非在兩個 harness 之間擇一，而是固定分派不同職責：Claude Code 負責執行，Codex 以 xHigh 模式負責審查，每次都如此。「我會讓 Opus 或 Fable 執行工作，最後一定用 Codex xHigh 審查……而它總能找到問題」（Lex Fridman #501，2026-08-26，practitioner-opinion）。他也會以 OpenCode 作為 harness，讓開放權重模型搭配 Fireworks 推論服務使用；因此三種 harness 的區別在於用途——執行者、審查者、開放模型主機——而非排名。見同模型審查盲點，了解跨模型家族的審查者可能優於同家族審查者的實測原因。

延伸閱讀#

• OpenAI — 開發者；Codex 是這份語料中 OpenAI 的代理工具主線
• Claude Code — Codex 對照的 Anthropic 端同類 harness（具備相同的五項迴圈基礎功能，生態系不同）
• Symphony — OpenAI 的開源協調器，透過 Linear 驅動 Codex
• Codex App Server Protocol — Codex 的無頭 JSON-RPC 協定
• 對話轉向委派 — 以 Codex 遙測資料為基礎的 2026 年 6 月使用研究；包含採用曲線與 token 占比資料
• 代理式工作系統化 — 研究衡量的系統化基礎，由 Codex 的 skills／plugins 構成
• 平行代理協調 — Codex 的執行緒化模型讓研究記錄的並行工作成為可能
• 迴圈工程 — Codex 是目前提供全部五項迴圈基礎功能的兩種工具介面之一
• 模型進步帶來的 Harness 收斂 — Codex 將 harness 功能（skills、自動化、工作樹）納入具名產品基礎功能
• 共用 Harness、差異化介面 — ChatGPT Work 合併的架構：一個 harness、三項 UX 差異，以及 OpenAI 為何拒絕 Anthropic 選擇的獨立產品模式
• Andrew Ambrosino — Codex 桌面應用程式的產品與工程主管；應用程式歷史、使用情況及轉向一般知識工作的來源
• 實作豐沛如何顛覆產品工作 — Ambrosino 從打造 Codex 得出的產品流程主張
• 為下一個模型打造 — Codex 應用程式作為案例研究：形狀相同、智慧程度不同的版本（11 月→2 月；Operator→Atlas→Codex）
• 為何 AI 在設計上落後 — Ambrosino 在打造應用程式前端時形成的設計能力觀察
• 角色平均化，而非角色消失 — Codex 組織比 OpenAI 其他部門更常遇到的「角色融合」現象
• Harness 自建與採購 — Codex 程式碼庫的外部衡量（每年合併 7,688 個 PR、約 132 萬行、每月 PR 數從約 124 增至約 1,000），以及這對分叉任何 harness 的意義
• OpenHands — 發布這份比較資料的開源競爭者
• 以 LLM 驅動的漏洞研究 — 這份語料唯一投入生產的漏洞研究流程所使用的 harness：每個 Rust P-critical issue 使用一個 /goal 工作階段，搭配兩個不同模型的裁判，並找出在 Rust 1.98 修補的健全性漏洞與錯誤編譯問題
• 迴圈工程 — 本頁對迴圈基礎功能的補充：/goal，以及撰寫目標的三項實務規則（讓模型草擬目標並進行紅隊測試；定義成果，絕不指定路徑；每個代理只負責一項成果）
• 同模型審查盲點 — Codex 的 /review 是兩個受測審查工具之一，以及限制它的研究發現：GPT 5.5 審查 Codex 撰寫的 PR 時表現最弱（高嚴重性問題召回率為 50.5%，Claude 撰寫的 PR 則為 62.0%），因此這個 harness 自帶的審查命令對自身產生的程式碼最不敏銳

資料來源#

• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH，Lex Fridman #501（2026-08-26，practitioner-opinion）：Codex xHigh 固定審查由 Claude 撰寫的工作

• The Shift to Agentic AI: Evidence from Codex — OpenAI，2026 年 6 月（Codex 在三個族群中的使用情形）

• OpenAI Codex lead on the new shape of product work — Lenny's Podcast，2026 年 6 月（Ambrosino 談 Codex 桌面應用程式、使用情況與發展方向）

• Codex from 0 to 10M Users: Building ChatGPT Work - Akshay Nathan, OpenAI — Latent Space，2026-07-28（practitioner-opinion）：Akshay Nathan 談 ChatGPT Work 合併、共用 harness、產物／Sites、持續性電腦環境及千萬使用者的說法

• Coding Agents and Technical Debt — Rajiv Shah，OpenHands，2026-07-28（case-study，由競爭者撰寫）：openai/codex 的第三方 GitHub 活動資料

• Models are worse at reviewing their own code — Rodrigo Caridad，Greptile，2026-07-21（case-study——由原始資料的 empirical 更正而來；由競爭者撰寫）：發現 3（每次審查的評論數）與發現 4 及 FIG. 05/06（遺漏死鎖的執行軌跡，以及在評論數指引下的改善）。完整分析見同模型審查盲點

• How we use /goal to find bugs in Patch the Planet — Trail of Bits，2026-07-28（case-study，與 OpenAI 的 Patch the Planet 計畫共同冠名）：以工具呼叫方式使用 /goal 的說明、aicov、每個工作階段一項成果的限制，以及「不到一天打造安全基礎設施，原本得花上數週」的說法。路由說明：WebFetch 只回傳刪去所有數字的改寫內容；原始資料來自使用瀏覽器標頭的 curl

• 另參考：An open-source spec for Codex orchestration: Symphony.、Harness engineering: leveraging Codex in an agent-first world、Loop Engineering