OpenAI 把 Responses API 接上 shell 與容器，代理競爭正式進入執行環境戰
OpenAI 這次真正丟出的，不是一個比較花俏的 AI 代理人 demo，而是一套更接近 agent runtime 的基礎層。從官方工程文章公開的內容來看，Responses API 現在不只負責把模型輸出回傳給開發者，而是開始直接承接 shell 執行、容器工作空間、檔案系統、資料庫、受控外網、技能包與 context compaction。這代表 OpenAI 想賣的東西，正在從「你來接模型」改成「你把任務交過來，我連執行環境都幫你準備」。
這條線和站內之前寫過的 GPT-5.4 把 computer use 往更高層級的桌面任務推進，其實是前後呼應的。前一篇看的是模型在桌面任務上的能力上限，這一篇更值得看的則是 OpenAI 終於把能力之外的幾個硬問題公開講清楚: 中間產物放哪裡、工具怎麼調用、長任務怎麼不爆 context、外網怎麼控、密鑰怎麼防外洩、還有工作流如何被重複利用。這些看起來不如 benchmark 好看，但才是真正決定 agent 能不能進生產的地方。
官方把 shell tool 定位得很直接: 模型不再只會跑 Python，而是能提議執行熟悉的 Unix 命令，像是 grep、curl、awk 這類工具都能進入工作流。更關鍵的是，Responses API 不只是把命令丟出去，而是內建 orchestrator，讓模型提出指令後，由 API 把命令送進容器執行、回收輸出、再把結果送回下一輪上下文，直到任務完成。這件事的意義，不在於 shell 很新，而在於 OpenAI 正在把 agent loop 變成自己的平台能力，而不是完全留給開發者自己補。
官方還公開了幾個以前很少被講得這麼具體的細節。第一，模型可以在同一步提出多個 shell 指令，而 Responses API 可以把它們放進不同 container session 並行執行。第二，輸出可以被設上限，避免超長 terminal log 把 Token 預算吃掉。第三，當上下文快滿時，系統可以用原生 compaction 機制保留高價值狀態，減少長工作流因為 context 爆掉而斷線。這三件事一起看，才會知道 OpenAI 這次不是在教大家怎麼做 agent，而是在把 agent 常見的工程痛點產品化。
如果只看到這裡，可能還會以為這只是幫開發者省點事。但真正把 OpenAI 往平台層再推一步的，是它把 container context 也搬上桌了。官方明講容器裡除了檔案系統，還會建議開發者把結構化資料放進像 SQLite 這樣的資料庫，讓模型去 query 而不是把整份表格直接塞進 Prompt。同時，它也把網路 access 做成 sidecar egress proxy，所有對外請求都經過 allowlist 與 policy layer，並用 domain-scoped secret injection 控制憑證。這代表 OpenAI 現在不只是說「我們有模型會用工具」，而是在補一整套模型安全調用外部世界的執行邊界。
真正的重點不是工具，而是 OpenAI 正在收走更多 agent 工程層
官方另外把 skills 這一層一起說清楚，也很值得注意。它把 skill 描述成一個包含 SKILL.md 與支援資源的 bundle，先被上傳與版本化，再在請求前複製進 container，由模型按需要探索與執行。這種設計本質上是在把重複工作流模板化。對開發團隊來說，這會直接改變 agent 的交付方式: 不再只是寫一堆 prompt 和工具綁定，而是把常見任務打包成可重複載入的能力單位。這和我們之前談過的 企業 AI 平台開始把工具、治理與採購入口包成平台權力 是同一個方向，只是 OpenAI 這次切得更底，直接從 runtime 和 execution layer 下手。
這也會讓 OpenAI 和一般 API 供應商的差別愈來愈大。過去很多模型公司賣的是一個 endpoint，真正複雜的 orchestration、工具接線、context 控制、資源管理，都留給開發者或第三方框架。現在 OpenAI 的訊號比較像是: 如果 agent 真的會成為下一代軟體互動方式，那麼最值錢的不只是模型本身，而是誰能把模型、工具、執行環境與長工作流控制一起做成預設答案。只要這層被它拿下，開發者就會更難只是把模型換一家，因為要換掉的不再只是 API key，而是整套 runtime 假設。
不過這條路也不是沒有代價。OpenAI 文章雖然把受控外網、容器與 compaction 描述得很完整，但它目前公開更多的是能力與架構邏輯，而不是更細的企業治理邊界。例如不同資料敏感度下的審計粒度、成本模型如何計算、哪些組織會願意把更多中間流程直接交給 hosted runtime，現在都還在早期。對很多團隊來說，自己搭 agent harness 很麻煩，但完全把 runtime 交給單一供應商，也會帶來新的平台依賴與控制問題。
所以這則消息最值得記住的，不是 OpenAI 又多了一個 developer feature，而是 agent 競爭終於更清楚地往下一層打。接下來比的不只是哪個 LLM 會規劃，更是誰能把規劃、執行、記憶、安全與重複使用變成更穩的預設工作流。若你想看 OpenAI 在 agent 面的另一個延伸，也可以再對照 OpenAI 把 Codex 往安全代理與任務閉環推進。模型只是入口，執行環境才開始變成真正的戰場。