OpenAI昨天一口氣打出了四張大牌。

Agents API、GPT-Live-1 API、Data agent、ChatGPT for Financial Services，一天橫跨Agent、語音、數據和金融四條產品線，每一條都值得單獨拿出來說道。

但這四張牌裏，最值得看的可能還是Agents API。

因為這一次，OpenAI把Codex「拆開賣了」。

原本藏在Codex背後、負責讓Agent持續工作、調用工具、管理上下文和協同多個Agent的那套能力，被抽出來打包成了雲端API，交給所有開發者調用。

Codex即服務？

其實，OpenAI早就在拆Codex了。

早在2025年4月，OpenAI剛發布o3和o4-mini那會兒，就把Codex CLI開源了。它有點像OpenAI版的Claude Code，直接就裝在本地終端裏。Agent怎麼跑，怎麼調用工具，都明明白白地放在GitHub上，你願意折騰，就可以自己拿回去改，自己跑。

不過那個時候只是單純地把東西給了出來，至於你會不會用、想怎麼用，那都還是你自己的事。

一個月後，Codex雲端版，也就是我們今天所熟悉的那個產品，才正式上線。用戶可以把代碼倉庫交給它，一個任務對應一個獨立的雲端沙盒，Codex可以自己改代碼、跑測試、修bug，還能同時處理多個任務。

又過了幾個月，在2025年的10月份，OpenAI發布了Codex SDK。

簡單來說，SDK就是給開發者的一套工具包，讓Codex不只作為獨立產品使用，也可以塞進別人的應用裏。SDK允許開發者用幾行TypeScript代碼啓動同一個驅動Codex CLI的Agent，拿到結構化輸出，還能保留任務狀態，在暫停之後繼續跑。

但是呢，SDK主要適合在程序裏調用Codex，還沒有把完整的Codex交互能力開放出來。它很適合後台的工作流、自動化腳本、服務端的程序。但如果你想做一個像Codex IDE那樣的完整客戶端，還是有些困難。

於是到了2026年2月，OpenAI正式公開Codex App Server，第一次系統地把Codex裏面那套Harness講清楚了。

OpenAI明確解釋，Codex Web、CLI、IDE擴展和Mac App看起來是不同的產品，但底下其實都在運行同一套Codex Harness，也就是負責Agent Loop、Thread、工具執行、認證和管理狀態的那層東西。

App Server給這一整套Harness加了一套雙向JSON-RPC接口。JetBrains、Xcode或者其他客戶端，不需要重新造一個Agent Loop，直接啓動App Server，就可以驅動完整的Codex。

有了App Server，其他產品就可以直接接上完整的Codex Harness。

不過走到這裏，還有最後一個麻煩沒解決。

SDK控制的是本地Codex Agent，App Server本身也是一個需要開發者啓動和維持的常駐進程。雖然把Codex接進產品這事已經解決了，但想把它穩定地跑成一個線上的服務，還是有點困難。

舉一個比較具體的例子，如果你用App Server做一個自己的Coding Agent網站，前端已經接上了Codex，但當用戶點下「修復這個倉庫」之後，後續的大量運行和基礎設施問題，都還需要你自己想辦法解決。

然後就到了8月19日，這一天，OpenAI把過去一年陸續開放的CLI、SDK、App Server統一放進了「開放Codex Harness」的平台敘事裏，並明確把Codex從一個產品提升成了平台。

再然後就是（美國時間）9月10日，也就是昨天，Agents API正式開放公測。

這一次，開發者只需要告訴API四件事——任務、模型、工具、運行環境——就可以直接創建一個Agent。負責長會話上下文壓縮、工具調度和subagent協作的Codex Harness由OpenAI自己託管和維護。

甚至就連Agent真正幹活的機器都能自己選，是用OpenAI的沙盒、自己的基礎設施，還是Cloudflare、E2B、Modal等第三方環境，都可以。Harness由OpenAI提供，執行環境由開發者決定。

官方的口徑很明確，Agents API本身不額外收費。也就是說，Harness託管、長會話管理等能力，並沒有再單獨收一層Agent平台費。

開發者按實際使用的模型Token和工具付費；如果使用OpenAI自己的託管沙盒，計算資源另算。

把這一年多串起來，OpenAI一直在做同一件事：把Codex從一個具體產品，一層一層拆成可以被複用的能力，同時讓開發者越來越不需要自己操心。

如果一定要給這條產品線起個名字，它其實很像當年的SaaS，只不過這次被服務化的不是軟件，而是Codex。

Codex as a Service。

Harness也開始分叉了

盯上Harness的當然不止OpenAI。

DeepSeek Harness（後文簡稱DSH）發布的時候，就給出了一個非常響亮的等式：Agent ＝ Model + Harness。

在DeepSeek看來，模型只是Agent的一半，另一半則是負責讓它理解環境、調用工具、管理狀態、持續執行任務的Harness。兩者互相協調，Agent才能真正執行任務。

DSH把Harness本身做成了一套高度模塊化的開放框架：模型、工具、Skills、Session、沙盒、存儲、Agent Loop、調度，甚至UI都可以替換。

「一切皆插件」的口號可不是說着玩玩而已，最好大家都來寫插件，都來適配DSH，最後不管上面跑的是DeepSeek，還是別的模型，底下都可以是同一套Harness。

這和OpenAI現在走的方向剛好形成了一個挺有意思的對照。

OpenAI雖然也把Codex harness開源了，但Agents API明顯是在往另一個方向走：Harness你可以用自己的，也可以拿走開源的，但如果你嫌麻煩，還可以直接不管，讓我來替你安排。

所以我們認為，它更像是一種「服務」。OpenAI負責託管和持續維護Harness，開發者只需要決定要讓Agent幹什麼、用什麼工具、在哪裏執行。甚至以後模型升級了，Harness怎麼跟着改，OpenAI也準備一起包了。

某種意義上，現在Harness這一層隱約出現了兩條路線：

以DeepSeek為代表的路線更像是在建設開放生態，把每一個零件都做成插件，讓開發者自己組裝；而以OpenAI為代表的一方則像在押注雲服務，把錢和需求給到位，剩下的我幫你解決。

我們甚至可以認為，一個想讓Harness越來越像Linux，另一個則想讓Harness越來越像AWS。

當然了，這只是個比喻。OpenAI也開源了Codex Harness，DeepSeek未來也並非沒有可能提供更多的託管服務。但至少在現階段，兩邊產品的重心差別明顯。

有意思的是，在把Harness變成服務的這條線上，Anthropic其實比OpenAI更早一步。

早在2025年9月，Anthropic就推出了Claude Agent SDK，把Claude Code背後的工具、上下文管理、權限系統和subagent能力開放給開發者，讓別人也能拿這套東西做Agent。

今年4月，它甚至比OpenAI更早推出了Claude Managed Agents。Session、Harness和沙盒被拆成三個獨立層：Anthropic負責託管harness和長任務，沙盒既可以由Anthropic提供，也可以接入別的執行環境。這個思路和今天的Agents API其實已經相當接近，Anthropic自己給它的定義就是「一個用於長期Agent任務的託管服務」。

所以某種意義上，OpenAI這次是在沿着Anthropic已經走過的路繼續往前走，區別只不過是OpenAI手裏有一個更「產品化」的Codex。

但因為Codex和Claude Code長期給人的產品印象還是不太一樣，所以即使它們講的是同一套故事，帶來的感覺也大相徑庭。Claude Code給人的感覺更像是讓開發者坐在終端裏和Agent一起寫代碼，而Codex App一開始強調的就是「同時監督多個長期Agent」的界面。

順帶一提，谷歌也早已加入這條路線。今年5月的I/O大會上，Gemini API推出Managed Agents，同樣把Antigravity Harness和沙箱做成了託管服務。但谷歌的牌面不止於此，這一點咱們後面再討論。

不過話說回來，誰先誰後好像也不是那麼重要……最後當然是誰把自家的Harness變成開發者默認的那一層，誰才能喫下最大的蛋糕。

誰是大贏家？

說到底，為什麼現在模型公司都開始搶Harness了？

就像是DSH給出的等式那樣，Agent = Model + Harness，模型可以告訴Agent下一步應該做什麼，但真要把一個任務從頭跑到尾，它還得知道文件在哪裏、需要調用哪個工具、出了錯怎麼恢復、結果最後要寫在哪裏。

換句話說，模型決定Agent的能力上限，而Harness越來越決定它到底能不能把活做完。

而一旦競爭的維度從「智力」走向「執行力」，最佔優勢的，未必是那些模型做得最好的AI公司。

因為Agent真正開始幹活之後，需要的那些東西——郵件、文檔、會議、通訊、賬號權限等等——往往掌握在傳統平台公司手裏。

國內最近打得熱鬧的「辦公Agent大戰」，其實就是一個非常典型的例子：大廠在互聯網平台時代積累下來的那些東西，以前更多只是各自生態裏的部分功能，但到了Agent時代，這些東西恰好就是Agent真正幹活時需要調用的工具。

現在大家做辦公Agent，表面上是比誰家的AI員工更聰明、更有本事，背後其實也在重新利用自己過去積累的平台優勢。誰手裏有更多企業數據、文檔、工具和權限，誰就更容易讓Agent真正把事情做完。

模型公司需要一點點接入它們沒有的入口，而那些做了十幾年辦公軟件和互聯網平台的公司，本來就掌握着這些入口。

換句話說，AI公司要重新連接現實世界，而平台公司手裏原本就有一大串鑰匙。

沿着這條路往前看，如果非要找一個最有優勢的「全家桶」選手，谷歌恐怕是最誇張的那個。

從TPU、雲基礎設施、Gemini，到Search、Workspace、Chrome和Android，谷歌幾乎覆蓋了AI從底層技術到最終用戶的所有關鍵環節。Search、Gmail、Calendar、Drive、YouTube、Maps等產品，又天然構成了一套可以被Agent調用的數字環境。這些資產在上一代互聯網裏是一個個獨立入口，到了Agent時代，卻可以被重新組織到同一個任務之下。

事實上，谷歌已經開始把散落在各個產品裏的Agent能力，在底層往同一套執行系統裏收。Gemini Spark、Gemini API裏的Managed Agents，乃至Search裏的部分Agent體驗，背後正在逐漸共享同一套Antigravity Harness。

但到了用戶這一端，事情還是有點亂。

今天谷歌同時有Gemini Spark、Workspace Studio、Antigravity、Gemini Enterprise，以及Search裏的Information agents。它們面對的用戶和場景各不相同，但對於普通人來說，當他們想把一件複雜的事情整個交給谷歌，還是不知道應該找誰。

對谷歌來說，它已經擁有完成這一切所需的大部分條件，缺的只是一個足夠簡單的產品答案。

而如果谷歌真把這件事做明白了——無論是做出了一個統一的Agent工作台，還是讓同一個Agent執行系統穿透整個谷歌生態，讓用戶習慣「有問題找谷歌」，全球Agent市場的競爭格局恐怕都要再變一變。

話雖如此，谷歌就算真把這套「全家桶」塞進一個Agent，國內用戶大概率也只能先圍觀一下。

還是先看看國內的Agent大戰，接下來還會怎麼打吧。