OpenAI 開放 Agents API 公測:把 Codex 的執行骨架整包租給你

OpenAI 開放 Agents API 公測:把 Codex 的執行骨架整包租給你

9 月 10 日,OpenAI 把驅動 Codex 的那套 harness 開放成 API。沒有額外費用、只收 token 與沙箱時間,但資料僅限美國、不支援零資料保存。對台灣開發者來說,這是一道值得算清楚的取捨題。

OpenAI 開放 Agents API 公測:把 Codex 的執行骨架整包租給你

九月的某個週四晚上,台北一位後端工程師還在調他們家 AI agent 的重試邏輯。這套東西他寫了四個月:工作階段狀態怎麼存、對話長到超過上下文視窗時怎麼壓縮、工具呼叫失敗了怎麼復原、多個子任務怎麼併行。這些程式碼沒有一行跟公司的產品有關,但少了它們,agent 跑十分鐘就會壞掉。

隔天早上他打開 X,看到 OpenAI 宣布 Agents API 進入公測——那四個月的工作,現在是一個 API 呼叫。

這種心情大概每個做基礎建設的人都懂:一半是解脫,一半是被搶了午餐。

事件背景

OpenAI 於 2026 年 9 月 10 日在 X 上的一則討論串與開發者論壇的貼文中,宣布 Agents API 進入公測。官方的定位講得很直接:「用 Codex harness 建立並執行雲端 agent,由 OpenAI 全託管。」

這裡的 harness 是關鍵字。它指的不是模型,而是模型外面那一層負責「讓它能持續工作」的骨架——狀態管理、上下文維護、工具編排、錯誤復原。Codex 之所以能跑長時間的程式任務而不崩潰,靠的就是這一層。現在這一層被打包成 API 對外開放。

值得注意的是這個動作的時機。2026 年 agent 應用的瓶頸早就不是模型能力,而是可靠度——Demo 跑得很漂亮,放到生產環境跑三十分鐘就開始漏步驟、忘記前面做過什麼。OpenAI 選在這個節點把自己的執行骨架商品化,是很準的一刀。

本次重點

  • 四個原語。官方把 API 組織成四個概念:agent(模型、指示、工具與可用的 MCP 伺服器)、environment(可選的沙箱,agent 在裡面存取檔案、載入 skills、執行指令)、session(持久的 agent 實例,能跨多輪保持狀態)、events 與 items(送進去的輸入與產出的輸出)。
  • harness 負責的三件事。長工作階段與自動上下文壓縮;透過工具搜尋與程式化呼叫達成有效率的工具使用;多 agent 協調——主 agent 會把複雜任務拆成可獨立處理的片段。
  • 計費不多收。技術媒體引述的說法是「沒有額外費用;你付的是 token、工具與容器時間」。換句話說 harness 本身不另外收租。
  • 限制講在前面。報導指出目前資料僅限美國境內,且不支援零資料保存。程式範例中出現的模型是 gpt-6-astra。
  • 與現有介面的分工。Agents API 跑在 OpenAI 託管的基礎設施上、整合工作量低;Agents SDK 跑在你自己的應用裡、工作量中等;Responses API 需要手動管理歷史、工作量最高。

市場影響分析

對台灣使用者:短期內一般使用者不會有直接感受,但中期會。當建構可靠 agent 的門檻從「四個月的基礎建設工程」降到「一個 API」,你會看到更多台灣本土的垂直 agent 應用冒出來——法務助理、客服代理、報表機器人。過去這些點子卡在工程量,不是卡在創意。

對企業應用:這裡有一道必須算清楚的取捨題。

好處很明顯:不必自己養一組人維護 agent 的執行迴圈。這部分工作又難又沒有差異化,客戶不會因為你的上下文壓縮寫得比較好而多付錢。

代價有兩層。第一層是資料落地——僅限美國、不支援零資料保存,這對受個資法約束或需要資料在地化的專案是硬限制。金融、醫療、公部門相關的案子,這一條就直接排除了。第二層是議價能力。當你的 agent 執行層綁在單一供應商的託管服務上,三年後的遷移成本會遠高於今天省下的四個月。

我的建議是分層看待:把「agent 要做什麼」的商業邏輯留在自己手上,把「怎麼讓它穩定跑完」的骨架外包出去。前者是你的護城河,後者不是。

對開發者:值得注意的是 MCP 被列進 agent 的定義裡——這個協定在 2026 年正在成為 agent 生態的共同介面,連提案回覆工具(例如 Arphie)都開始支援從外部 AI 助理呼叫。這對開發者是好消息:工具介面標準化之後,換底層模型的成本會下降。

實務上要提醒一件事:agent 型應用的 token 消耗跟單次對話完全不是同一個量級。它會反覆呼叫工具、壓縮上下文、重試失敗的步驟。公測期一定要實際跑一週再推估月成本,別用單次對話的經驗去估。日常開發流程若想搭配 agent,可以參考站上的 CursorClaude 相關整理。

未來發展趨勢

執行層會變成新的平台戰場。模型能力的差距在收斂,而 agent 能不能穩定跑完一個小時的任務,差距還很大。誰的 harness 好用,誰就綁得住開發者。這一戰才剛開始。

自建與託管會長期並存。跟雲端運算的歷史很像:多數人會租,但對延遲、成本、資料主權敏感的仍會自建。差別在於自建的門檻會被拉高,因為託管方案持續在變好。

資料落地會成為採購時的第一道篩子。目前僅限美國這件事,會把一整批亞洲與歐洲的企業客戶擋在門外。這是商業決策而不是技術限制,所以很可能在正式版時放寬——但在放寬之前,別為它做架構賭注。

TheAI學院 總結與評語

這則新聞的重要性不在功能清單,在它揭示的產業結構變化:agent 的執行骨架正在從「每家公司各自造輪子」變成「跟平台租」。

從工程效率看,這是好事。那四個月的重試邏輯、上下文壓縮、狀態管理,說實話是純粹的成本,寫得再好也不會有客戶因此買單。能外包就外包,這是理性的。

但從產業結構看,值得警惕。當愈來愈多台灣的 AI 應用把執行層架在同一家供應商上,整個生態的議價能力會集中到一個點。這不是危言聳聽,是雲端運算走過的路。

評語:把 harness 租來用是划算的工程決策,但別把商業邏輯也一起搬進去——你能外包的應該是「怎麼跑得穩」,不該是「跑什麼」。

給台灣讀者的具體建議,三件事:

第一,先確認資料落地的合規性再寫任何程式碼。 僅限美國、不支援零資料保存,這兩條對受規範產業是紅線。合規部門的意見要在架構決策之前取得,不是之後。

第二,公測期就把成本實測出來。 agent 的 token 消耗會嚇到你。跑一週真實流量再推估月費,這個數字往往決定了商業模式成不成立。

第三,設計時就想好退路。 把商業邏輯與執行層之間的介面切乾淨,讓你三年後有搬家的選項。這件事在第一天做很便宜,第三年做很貴。

資料來源

依公開資訊整理,功能、限制與計費方式以官方最新公告為準。公測階段的規格可能隨時調整,正式導入前請再次確認官方文件。

常見問題

Agents API 跟既有的 Responses API、Agents SDK 差在哪?

差在誰負責維運那套執行骨架。Responses API 需要你自己管對話歷史,整合工作量最大;Agents SDK 跑在你自己的應用程式裡,屬中等;Agents API 則是 OpenAI 託管,長工作階段、上下文壓縮與復原都由官方處理,整合成本最低,代價是控制權與資料落地的彈性也最低。

Agents API 怎麼收費?

依官方與多個技術媒體的一致描述,harness 本身沒有額外費用,你付的是模型 token、工具呼叫以及沙箱容器的執行時間。要注意的是,agent 型應用的 token 消耗跟單次對話完全不是同一個量級——它會反覆呼叫工具、壓縮上下文、重試,實際帳單建議在公測期實測而非估算。

資料只留在美國會有什麼影響?

報導指出目前資料僅限美國境內,且不支援零資料保存(Zero Data Retention)。這對受個資法、金融或醫療法規約束、需要資料在地化的台灣專案是硬限制,不是可以用合約條款繞過的偏好問題。這類專案在公測階段應維持自建 harness 或改用支援地區選擇的方案。

什麼樣的團隊現在就該試?

已經在自己維護 agent 執行迴圈、而且被上下文壓縮與工作階段復原這兩件事困擾很久的團隊。這兩塊是自建 agent 最花工又最沒有差異化的部分,交出去很划算。反過來,還在做單次問答式應用的團隊,用 Responses API 就夠了,不需要為用不到的複雜度付出遷移成本。

資料來源:TheAI學院編輯團隊原創