OpenAI昨天一口氣打出了四張大牌。
Agents API、GPT-Live-1 API、Data agent、ChatGPT for Financial Services，一天橫跨Agent、語音、資料和金融四條產品線，每一條都值得單獨拿出來說道。
但這四張牌裡，最值得看的可能還是Agents API。
因為這一次，OpenAI把Codex“拆開賣了”。
原本藏在Codex背後、負責讓Agent持續工作、呼叫工具、管理上下文和協同多個Agent的那套能力，被抽出來打包成了雲端API，交給所有開發者呼叫。
01. 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。
02. 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”的介面。
順帶一提，Google也早已加入這條路線。今年5月的I/O大會上，Gemini API推出Managed Agents，同樣把Antigravity Harness和沙箱做成了託管服務。但Google的牌面不止於此，這一點咱們後面再討論。
不過話說回來，誰先誰後好像也不是那麼重要……最後當然是誰把自家的Harness變成開發者默認的那一層，誰才能吃下最大的蛋糕。
03. 誰是大贏家？
說到底，為什麼現在模型公司都開始搶Harness了？
就像是DSH給出的等式那樣，Agent = Model + Harness，模型可以告訴Agent下一步應該做什麼，但真要把一個任務從頭跑到尾，它還得知道檔案在那裡、需要呼叫那個工具、出了錯怎麼恢復、結果最後要寫在那裡。
換句話說，模型決定Agent的能力上限，而Harness越來越決定它到底能不能把活做完。
而一旦競爭的維度從“智力”走向“執行力”，最佔優勢的，未必是那些模型做得最好的AI公司。
因為Agent真正開始幹活之後，需要的那些東西——郵件、文件、會議、通訊、帳號權限等等——往往掌握在傳統平台公司手裡。
國內最近打得熱鬧的“辦公Agent大戰”，其實就是一個非常典型的例子：大廠在網際網路平台時代積累下來的那些東西，以前更多隻是各自生態裡的部分功能，但到了Agent時代，這些東西恰好就是Agent真正幹活時需要呼叫的工具。
現在大家做辦公Agent，表面上是比誰家的AI員工更聰明、更有本事，背後其實也在重新利用自己過去積累的平台優勢。誰手裡有更多企業資料、文件、工具和權限，誰就更容易讓Agent真正把事情做完。
模型公司需要一點點接入它們沒有的入口，而那些做了十幾年辦公軟體和網際網路平台的公司，本來就掌握著這些入口。
換句話說，AI公司要重新連接現實世界，而平台公司手裡原本就有一大串鑰匙。
沿著這條路往前看，如果非要找一個最有優勢的“全家桶”選手，Google恐怕是最誇張的那個。
從TPU、雲基礎設施、Gemini，到Search、Workspace、Chrome和Android，Google幾乎覆蓋了AI從底層技術到終端使用者的所有關鍵環節。Search、Gmail、Calendar、Drive、YouTube、Maps等產品，又天然構成了一套可以被Agent呼叫的數字環境。這些資產在上一代網際網路裡是一個個獨立入口，到了Agent時代，卻可以被重新組織到同一個任務之下。
事實上，Google已經開始把散落在各個產品裡的Agent能力，在底層往同一套執行系統裡收。Gemini Spark、Gemini API裡的Managed Agents，乃至Search裡的部分Agent體驗，背後正在逐漸共享同一套Antigravity Harness。
但到了使用者這一端，事情還是有點亂。
今天Google同時有Gemini Spark、Workspace Studio、Antigravity、Gemini Enterprise，以及Search裡的Information agents。它們面對的使用者和場景各不相同，但對於普通人來說，當他們想把一件複雜的事情整個交給Google，還是不知道應該找誰。
對Google來說，它已經擁有完成這一切所需的大部分條件，缺的只是一個足夠簡單的產品答案。
而如果Google真把這件事做明白了——無論是做出了一個統一的Agent工作台，還是讓同一個Agent執行系統穿透整個Google生態，讓使用者習慣“有問題找Google”，全球Agent市場的競爭格局恐怕都要再變一變。
話雖如此，Google就算真把這套“全家桶”塞進一個Agent，中國使用者大機率也只能先圍觀一下。
還是先看看國內的Agent大戰，接下來還會怎麼打吧。 (字母AI)