OpenAI 給 Responses API 加上電腦：支援 Shell 與容器，不再只跑 Python

以往讓 AI 幫你幹活，最尷尬的莫過於讓它改一段程式碼或拉取一段資料，它只能在 Python 直譯器裡打轉。要是想裝個依賴、跑個 Go 指令碼或者啟動一個本地服務，開發者就得自己搭一套沙箱環境，自己處理檔案讀寫和報錯重試。

OpenAI 在 3 月 11 日公佈了針對 Responses API 的一系列重要升級。他們把原本只能處理提示詞呼叫的介面，直接擴充成了一個帶計算機環境的完整執行平臺。從 GPT-5.2 開始的模型，不僅能直接寫命令列，還能在 OpenAI 託管的隔離容器裡真正跑起來。

扔掉單一的 Python 沙箱

這次最直接的改變是加入了 Shell 工具。以前官方提供的程式碼直譯器基本只認 Python，現在的 Shell 工具則基於 Unix 環境打造，內建了 grep、curl、awk 等常用系統工具。

這意味著模型不再只是單純生成程式碼，它可以直接啟動一個 NodeJS 服務，或者編譯執行 Go 和 Java 程式。只要模型判斷某個任務需要調外部介面或篩選檔案，它就會輸出命令列指令，由 Responses API 提交給後臺容器執行並流式拿回結果。

為了避免模型在長任務裡被海量日誌撐爆，OpenAI 還加了併發與輸出截斷機制。模型單次可以提出多個命令讓容器並行跑，同時能設定字元上限，自動保留輸出的開頭與結尾，省略中間冗餘部分。

像人類一樣用檔案系統和記憶壓縮

另一個讓開發者頭疼的問題是上下文管理。很多團隊以前為了讓模型分析大表格，只能硬生生把整個 CSV 貼進 prompt，既費錢又容易超出上下文限制。

OpenAI 現在的做法是給容器配了獨立的檔案系統和 SQLite 資料庫支援。開發者可以把資料直接存在容器裡，模型根據表結構按需查詢特定行，完全不用把整份資料塞進提示詞。容器對外聯網也受到策略控制，防止模型意外洩漏憑證或訪問危險外鏈。

針對超長任務可能跑爆視窗的問題，API 增加了原生上下文壓縮功能。模型會把之前的執行狀態壓縮成高資訊密度的加密表示，只帶上關鍵資訊進入下一輪。有意思的是，OpenAI 透露 Codex 不僅是最早用上這個機制的使用者，甚至還在研發過程中參與了自我排錯：一個 Codex 例項遇到壓縮 bug，工程師就讓另一個 Codex 去排查修復。

為什麼重要

對於做 Agent 應用的開發者來說，這一套組合拳基本免去了自己去折騰 Docker 編排、安全隔離和狀態持久化的苦工。你現在可以直接用官方的端到端能力，把任務丟給 GPT-5.2，讓它在後臺自己拉取資料、跑服務並生成報告，門檻被大幅拉低。

對行業而言，OpenAI 的思路已經非常清晰：單純賣 Token 和模型的時代正在過去，提供端到端的執行環境成了新的護城河。像 Anthropic 此前推出了讓 AI 控制螢幕的方案，而 OpenAI 選擇先從穩定的容器命令列切入，這種做法在我們看來更加務實，工程落地的確定性也更高。

不過這種重度繫結的平臺化打法也有隱患。當儲存、執行和上下文壓縮全部託管在 OpenAI 內部，開發者的遷移成本會變得極高。另外，雲端容器的網路許可權控制哪怕設了策略，在複雜的自動化任務中依然需要團隊極其謹慎，防止因指令越界引發安全事故。