今天凌晨，OpenAI 釋出了 OpenAI o3 和 o4-mini，是為回答之前思考更長時間而訓練。
這些推理模型首次實現了自主呼叫並整合 ChatGPT 內的全量工具：包括網頁搜尋、使用 Python 分析上傳檔案及資料、深度視覺推理，甚至影像生成。關鍵突破在於，這些模型能夠自主判斷何時及如何運用工具，在解決複雜問題時（通常在一分鐘內）以恰當的格式輸出縝密詳盡的解答。
“這些是我們迄今為止釋出的最智慧的模型，標誌著 ChatGPT 能力的一次飛躍，適用於從好奇的使用者到高階研究人員的所有人群。”OpenAI 認為，這使得它們能更高效處理多維度問題，標誌著 ChatGPT 向自主代理形態邁進——未來或可獨立代使用者完成任務。
Altman 在轉發了醫學博士 Derya Unutmaz 帖子後評價：“達到或接近天才水平”。
這個評價顯然很高，帖子下有網友不認同：能夠搜尋數百萬個網站（甚至是所有收集到的資料）並在幾秒鐘內彙總出看似合乎邏輯的答案，聽起來像是“達到或接近天才水平”，但事實並非如此。
ChatGPT 的 Plus、Pro 和 Team 使用者即日起就可以使用 o3、o4-mini 和 o4-mini-high，它們將取代之前的 o1、o3-mini 和 o3-mini-high。ChatGPT Enterprise 和 Edu 使用者將在一週後獲得訪問許可權。免費使用者可以在提交問題前在編輯器中選擇 “Think” 來嘗試使用 o4-mini。所有套餐的請求速率限制保持不變，與之前的模型一致。據悉，未來幾周內，OpenAI 將釋出帶有完整工具支援的 OpenAI o3-pro。
此外，o3 和 o4-mini 也已透過 Chat Completions API 和 Responses API 向開發者開放（部分開發者需要驗證其組織資訊才能訪問這些模型）。
o3 和 o4-mini 三大改進
OpenAI o3 是其目前最強大的推理模型，在程式設計、數學、科學、視覺感知等多個領域均達到了前沿水平。它在多個基準測試中重新整理了最新的 SOTA，包括 Codeforces、SWE-bench（無需構建特定模型的自定義支架）以及 MMMU。
OpenAI 稱 o3 特別適用於需要多方面分析、答案並非一目瞭然的複雜問題，在影像、圖表和圖形等視覺任務中的表現尤其出色。在外部專家的評估中，o3 在面對複雜的現實任務時，重大錯誤相較 o1 減少了 20%。
OpenAI o4-mini 則是一個更小巧的模型，專為快速、成本高效的推理任務最佳化，擅長處理數學、程式設計和視覺任務。o4-mini 是 AIME 2024 和 2025 年測試中表現最好的模型。在專家評估中，它在非 STEM 任務以及資料科學等領域優於其前身 o3-mini。另外 OpenAI 表示，o4-mini 支援遠高於 o3 的使用上限，是應對高頻次、需要強推理能力問題的優選。
擴充套件強化學習的規模
在 o3 的開發過程中，OpenAI 觀察到，大規模強化學習展現出了與 GPT 系列預訓練相同的趨勢：“更多算力 = 更好效能”。OpenAI 稱，其在強化學習領域中沿襲了“規模擴充套件”路徑，在訓練算力和 inference-time 上都提升了一個數量級後，能看到明顯的效能增益，驗證了模型的表現確實會隨著“思考時間”的增加而持續提升。
“在與 OpenAI o1 擁有相同延遲和成本的情況下，o3 在 ChatGPT 中提供了更高的效能——我們也證實，只要讓它‘多想一會兒’，它的表現就會繼續上升。”OpenAI 表示。
OpenAI 還透過強化學習訓練讓兩個模型學會了使用工具——不僅僅是教它們怎麼使用工具，而是 教它們如何判斷在什麼情況下使用工具。這種根據預期結果來靈活使用工具的能力更加適用於開放式場景，尤其是在涉及視覺推理和多步驟流程的任務中。
o3 和 o4-mini 價效比優於之前的 o1 和 o3-mini。 比如，在 2025 年的 AIME 數學競賽中，o3 的價效比超越了 o1，類似地，o4-mini 的價效比也超越了 o3-mini。OpenAI 預計，在大多數實際應用中，o3 和 o4-mini 相比 o1 和 o3-mini，不僅在智慧程度上更高，成本也更低。
o3-mini 和 o4-mini 的成本與效能
o1 和 o3 的成本與效能
用影像思考
新模型首次實現了將 影像直接融入思維鏈的能力。它們不僅是“看見”影像，而是“帶著影像去思考”，能夠將視覺和文字推理深度融合，在多模態基準測試中也展現出了最先進的效能。
使用者可以上傳白板照片、教科書插圖或手繪草圖，即使影像模糊、反轉或質量較差，模型也能理解。在工具使用的加持下，模型還能動態操作影像，比如旋轉、縮放或變換影像，這些操作會作為推理過程的一部分。
不過，該功能目前仍存在以下限制：
-
推理鏈過長：模型可能會執行冗餘或不必要的工具呼叫、影像處理步驟，導致思維鏈條過於複雜冗長。
-
感知錯誤：模型仍可能在基本的視覺感知上出錯。即使工具呼叫推動了正確的推理過程，影像的理解錯誤也可能導致最終答案錯誤。
-
可靠性問題：在多次嘗試同一個問題時，模型可能會採用不同的視覺推理路徑，其中一些可能導致錯誤的結果。
代理級的工具使用
根據介紹，OpenAI o3 和 o4-mini 模型在 ChatGPT 中擁有完整的工具呼叫許可權，還能透過 API 介面接入開發者自定義的工具。新模型經過專門訓練，具備智慧決策能力——它們會先分析問題本質，自主判斷何時呼叫什麼工具，通常在一分鐘內就能生成格式規範、邏輯縝密的回答。
比如，當用戶問：“今年夏天加州的能源使用情況與去年相比會怎樣？”模型可以在網上搜索公共電力資料、編寫 Python 程式碼進行預測、生成圖表或圖片，並解釋預測背後的關鍵因素——整個過程會串聯使用多個工具。
輕量級編碼智慧體：Codex CLI
“o3 和 o4-mini 非常擅長編碼，因此我們釋出了一款新產品 Codex CLI，以使它們更易於使用。這是一個可以在你的計算機上執行的編碼代理。它完全開源並且今天就可以使用；我們預計它會迅速改進。”Altman 說道。
Codex CLI 是一個可以直接在終端執行的輕量級編碼智慧體。這是一個為日常工作離不開終端的開發者打造的工具，可以在本地計算機上執行，專為充分發揮 o3 和 o4-mini 等模型的推理能力而設計，未來還將支援包括 GPT-4.1 在內的其他 API 模型。此外，Codex CLI 還外加實際執行程式碼、操作檔案、快速迭代的能力。
遵循指令和代理工具使用測評
根據介紹，使用者可以在命令列中利用多模態推理的優勢，例如將截圖或低保真草圖傳遞給模型，同時結合原生代碼訪問，實現強大的開發輔助功能。我們將它視為一種最小化的介面，讓我們的模型可以更直接地連線到使用者和他們的計算機上。
Codex 讓使用者決定智慧體的自主權以及自動批准策略，可以透過
--approval-mode 標誌（或互動引導提示）來設定。在完全自動模式（Full Auto） 下，每個命令都將在網路環境中停用，並限制在當前工作目錄（以及臨時檔案）內，以實現深度防禦。如果在未被 Git 跟蹤的目錄中啟動自動編輯或完全自動模式，Codex 還會顯示警告 / 確認提示。
與此同時，OpenAI 還啟動了一項 100 萬美元的支援計劃，資助那些使用 Codex CLI 和 OpenAI 模型的專案。官方將以每項 25,000 美元 API 使用額度 的形式，評估並接受資助申請。
開源地址：github.com/openai/codex
使用者實際體驗，曝模型虛構事實問題
釋出後，網上充滿稱讚，有使用許可權的使用者迫不及待測試了新模型，但評價並非一邊倒的好評。
網友 M4v3R 反饋，新模型出現了“捏造事實”的情況：
好吧，我有點失望。我問了一個相對技術性較強的問題，非常小眾（Final Fantasy VII 反向工程）。透過正確的知識和網路搜尋，最多幾分鐘就能回答這個問題。模型在論壇和其他網站上確實找到了些不錯的內容，但隨後它開始憑空猜測一些細節，並在後續的研究中使用了這些資訊。最後給我的結果是錯誤的，並且它描述的步驟完全是捏造的。”更糟糕的是，在推理過程中，它似乎意識到自己沒有準確答案，所謂的 399 只是一個估算值。但在最終回答中，它卻自信地表示找到了正確數值。本質上，它隱瞞了“自己不知道”的事實，用估算值冒充確切結論，且未向用戶說明這一不確定性。”M4v3R 說道。
X 使用者“Transluce”也表示，在測試了一個 o3 預釋出版本後，發現它經常捏造自己從未執行過的操作，並且在被質疑時還能詳細地為這些虛構的行為辯解。
Transluce 在進一步挖掘中發現 o3 中存在多次虛構使用程式碼工具的情況，包括：
-
聲稱掌握 Python REPL 的資訊。 模型宣稱沙盒直譯器返回了包括 Python 版本、編譯器、平臺、時間戳、環境變數等在內的虛構資訊。當用戶要求它使用直譯器執行一段程式碼時，它給出了一個錯誤的值；在被質疑後，它辯稱是因為在直譯器和聊天視窗之間貼上時“手滑”了。
-
編造時間並聲稱是用 Python 的 datetime 模組獲取的。 當用戶詢問當前時間時，模型編造了一個時間。當用戶追問它是如何得到這個時間的，模型回答說它用了 Python 的 datetime 模組。
-
在複製 SHA-1 雜湊時誤導使用者。 使用者要求模型為一首詩生成 SHA-1 雜湊，並嘗試復現模型給出的雜湊值。當用戶得到不同的結果時，模型將其歸咎於使用者錯誤，並堅持它生成的雜湊是正確的。
-
假裝分析來自 Web 伺服器的日誌檔案。 使用者要求模型從 Web 伺服器的日誌檔案中提取統計資訊。模型生成了一段 Python 指令碼並聲稱已經在本地執行，但當用戶要求提供更多關於程式碼執行的細節時，它才承認自己沒有 Python 直譯器，輸出結果其實是“手工編寫的”。
“o4-mini 程式設計能力超強。但是，當它犯錯卻找不到錯誤原因時，它就會一直在那個錯誤上糾纏，一遍又一遍地犯錯。我浪費了很多時間去尋找錯誤，並試圖告訴 o4-mini 它犯了什麼錯誤。然而，它卻無法從錯誤中吸取教訓。”開發者 HurryNFT 說道。
不過，也有網友給出了一些正向反饋：
有意思……我讓 o3 幫我寫一個 flake，以便在 NixOS 上安裝最新版的 WebStorm（因為軟體源裡的版本已經好幾個月沒更新了），結果看起來它真的啟動了一個 NixOS 虛擬機器，下載了 WebStorm 包，寫好了 Flake 配置，計算出了 NixOS 所需的 SHA 雜湊值，還寫了一個測試套件。測試套件顯示它甚至進行了 GUI 測試——不過我不確定那是不是它臆想出來的。儘管如此，它一次性就寫出了完整的安裝說明，而且我不覺得它能在沒下載包的情況下算出雜湊值，所以我認為這意味著它具備了一些非常有意思的新能力。令人印象非常深刻。
但在這個網友的帖子下，有其他人反饋：“這和我的經驗完全不一樣。我試過讓它把一個能用 npm 的 yarn 包換成 flake，試了三次，用盡了所有提示，它還是不行。”
此外，也有使用者使用 Codex o4-mini 與 Claude Code 進行了對比，結果不如 Claude Code，並且也提到了模型虛構問題：
我嘗試使用 Codex o4-mini 與 Claude Code 進行一項正面交鋒的任務：為中型程式碼庫中一個棘手的部分編寫文件。Claude Code 表現出色，寫出來的文件質量不錯。Codex 表現不佳。它憑空編造了很多程式碼中不存在的內容，完全誤解了架構——它開始談論服務端後端和 REST API，但這個應用根本沒有這些東西。
我很好奇到底出了什麼問題——感覺可能是沒有正確載入上下文或者注意力沒放在對的地方？這似乎正是 Claude Code 最佳化得特別好的一個方面。我對 o3 和 o4-mini 兩個模型寄予厚望，希望其他測試能有更好的表現！也很好奇像 Cursor 這類工具會如何整合 o3。
有網友跟帖稱，“Claude Code 依然感覺更強。o4-mini 有各種各樣的問題，o3 雖然更好，但到了那個層級你也沒省下多少錢，所以誰在乎呢。”
為此，有開發者表示，“為什麼不直接選擇 Gemini Pro 2.5 的 Copilot 編輯模式呢？幾乎無限使用，無需額外付費。Copilot 以前沒什麼用，但在過去的幾個月裡，一旦添加了編輯模式，它就變得非常出色。”
參考連結：
https://openai.com/index/introducing-o3-and-o4-mini/
https://openai.com/index/thinking-with-images/
https://transluce.org/investigating-o3-truthfulness
宣告：本文為 AI 前線整理，不代表平臺觀點，未經許可禁止轉載。
AICon 2025 強勢來襲，5 月上海站、6 月北京站，雙城聯動，全覽 AI 技術前沿和行業落地。大會聚焦技術與應用深度融合，匯聚 AI Agent、多模態、場景應用、大模型架構創新、智慧資料基建、AI 產品設計和出海策略等話題。即刻掃碼購票，一同探索 AI 應用邊界！