從模型到代理：為 Responses API 配備電腦運行環境

2026 年 3 月 11 日

從模型到代理：為 Responses API 配備電腦環境

作者：Bo Xu、Danny Zhang 與 Rohit Arunachalam

我們目前正處於一個轉型期，從使用擅長特定任務的「模型」，轉向使用能夠處理複雜工作流的「代理」（Agents）。透過提示模型，你只能獲取已訓練的智慧。然而，若賦予模型一個電腦環境，則可以實現更廣泛的使用場景，例如運行服務、從 API 請求數據，或生成更有用的產出物（如試算表或報告）。

在嘗試構建代理時，會出現一些實際問題：中間文件該放在哪裡、如何避免將大型表格貼入提示詞中、如何在不造成安全隱患的情況下賦予工作流網路存取權限，以及如何在不自行構建工作流系統的情況下處理超時和重試。

我們沒有讓開發者自行構建執行環境，而是構建了必要的組件，為 Responses API⁠（在新視窗中開啟）配備電腦環境，以可靠地執行現實世界的任務。

OpenAI 的 Responses API 結合了 Shell 工具和託管的容器工作區，旨在解決這些實際問題。模型提出步驟和指令；平台則在一個隔離的環境中運行它們，該環境包含用於輸入輸出的文件系統、可選的結構化存儲（如 SQLite）以及受限的網路存取。

在這篇文章中，我們將拆解我們如何為代理構建電腦環境，並分享一些早期經驗，介紹如何利用它來實現更快速、更具可重複性且更安全的生產工作流。

Shell 工具

一個好的代理工作流始於一個緊密的執行迴圈：模型提出一項操作（如讀取文件或透過 API 獲取數據），平台執行該操作，結果則回饋到下一步。我們將從 Shell 工具開始——這是觀察此迴圈運作最簡單的方式——接著再介紹容器工作區、網路連接、可重複使用的技能（Skills）以及上下文壓縮（Context Compaction）。

要理解 Shell 工具，首先需要了解語言模型通常如何使用工具：執行諸如呼叫函數或與電腦互動等操作。在訓練期間，模型會看到工具使用方式及其產生效果的逐步範例。這有助於模型學習何時以及如何使用工具。當我們說「使用工具」時，實際上是指模型僅「提出」工具呼叫。它本身無法執行該呼叫。

Shell 工具讓模型變得極其強大：它透過命令行與電腦互動，執行從搜索文本到在你的電腦上發送 API 請求等廣泛任務。我們的 Shell 工具建立在熟悉的 Unix 工具之上，可以執行你預期的任何操作，並內建了 grep、curl 和 awk 等實用程式。

與我們現有的僅執行 Python 的代碼解釋器（Code Interpreter）相比，Shell 工具支援更廣泛的使用場景，例如運行 Go 或 Java 程序，或啟動 NodeJS 伺服器。這種靈活性讓模型能夠完成複雜的代理任務。

編排代理迴圈

模型本身只能提出 Shell 指令，但這些指令是如何執行的呢？我們需要一個編排器（Orchestrator）來獲取模型輸出、調用工具，並在迴圈中將工具回應傳回模型，直到任務完成。

Responses API 是開發者與 OpenAI 模型互動的方式。當與自定義工具配合使用時，Responses API 會將控制權交還給客戶端，而客戶端需要自己的框架來運行工具。然而，此 API 也可以開箱即用地在模型與託管工具之間進行編排。

當 Responses API 收到提示時，它會組裝模型上下文：用戶提示、先前的對話狀態和工具指令。為了讓 Shell 執行生效，提示中必須提到使用 Shell 工具，且所選模型必須經過訓練以提出 Shell 指令——GPT-5.2 及更高版本的模型已針對此進行了訓練。憑藉所有這些上下文，模型隨後決定下一步行動。如果它選擇 Shell 執行，它會向 Responses API 服務返回一個或多個 Shell 指令。API 服務將這些指令轉發到容器運行時，串流回傳 Shell 輸出，並將其放入下一次請求的上下文中提供給模型。模型隨後可以檢查結果、發布後續指令或產生最終答案。Responses API 會重複此迴圈，直到模型返回不含額外 Shell 指令的完成結果。

當 Responses API 執行 Shell 指令時，它會與容器服務保持串流連接。隨著輸出產生，API 會近乎即時地將其轉發給模型，以便模型決定是等待更多輸出、運行另一個指令，還是進入最終回應。

Responses API 串流傳輸 Shell 指令輸出

模型可以在一個步驟中提出多個 Shell 指令，Responses API 可以使用獨立的容器對話（Sessions）並行執行它們。每個對話獨立串流輸出，API 將這些串流多路復用（Multiplexes）回結構化的工具輸出作為上下文。換句話說，代理迴圈可以並行化工作，例如搜索文件、獲取數據和驗證中間結果。

當指令涉及文件操作或數據處理時，Shell 輸出可能會變得非常龐大，並在不增加有用訊號的情況下消耗上下文額度。為了控制這一點，模型會為每個指令指定輸出上限。Responses API 會強制執行該上限，並返回一個有界的結果，保留輸出的開頭和結尾，同時標記省略的內容。例如，你可以將輸出限制為 1,000 個字元，並保留開頭和結尾：

開頭的文字 ... 截斷 1000 字元 ... 結尾的文字

並行執行與有界輸出相結合，使代理迴圈既快速又具備上下文效率，讓模型能夠持續對相關結果進行推理，而不會被原始的終端日誌淹沒。

當上下文視窗滿載時：壓縮

代理迴圈的一個潛在問題是任務可能會運行很長時間。長時間運行的任務會填滿上下文視窗，而上下文視窗對於在輪次之間和代理之間提供背景資訊至關重要。想像一個代理呼叫一項技能、獲取回應、添加工具呼叫和推理摘要——有限的上下文視窗很快就會填滿。為了避免在代理繼續運行時丟失重要上下文，我們需要一種方法來保留關鍵細節並移除任何無關內容。我們沒有要求開發者設計和維護自定義的摘要或狀態攜帶系統，而是在 Responses API 中添加了原生壓縮功能，旨在與模型的行為方式及其訓練方式保持一致。

我們最新的模型經過訓練，可以分析先前的對話狀態並生成一個壓縮項（Compaction Item），以加密且節省 Token 的表示方式保留關鍵的先前狀態。壓縮後，下一個上下文視窗由該壓縮項和早期視窗的高價值部分組成。這使得工作流能夠跨越視窗邊界保持連貫，即使是在擴展的多步驟和工具驅動的對話中也是如此。Codex 依賴此機制來維持長時間運行的編碼任務和迭代工具執行，而不會降低品質。

壓縮功能可透過伺服器內建或獨立的 /compact 端點使用。伺服器端壓縮讓你能夠配置閾值，系統會自動處理壓縮時機，消除了複雜的客戶端邏輯需求。它允許稍微大一點的有效輸入上下文視窗，以容忍壓縮前的小額超量，因此接近限制的請求仍可被處理和壓縮，而不是被拒絕。隨著模型訓練的演進，原生壓縮解決方案也會隨每個 OpenAI 模型版本的發布而同步進化。

Codex 在作為早期用戶的同時，也幫助我們構建了壓縮系統。當一個 Codex 實例遇到壓縮錯誤時，我們會啟動第二個實例進行調查。結果是，Codex 僅透過解決問題就獲得了一個原生的、有效的壓縮系統。Codex 這種檢查和完善自身的能力已成為在 OpenAI 工作中一個特別有趣的部分。大多數工具只要求用戶學習如何使用它們；而 Codex 則與我們一同學習。

容器上下文

現在讓我們來談談狀態與資源。容器不僅是運行指令的地方，也是模型的「工作上下文」。在容器內部，模型可以在網路政策控制下讀取文件、查詢數據庫並存取外部系統。

文件系統

容器上下文的第一部分是用於上傳、組織和管理資源的文件系統。我們構建了容器和文件⁠（在新視窗中開啟）API，為模型提供可用數據的地圖，並幫助它選擇有針對性的文件操作，而不是執行廣泛且嘈雜的掃描。

一種常見的反模式是將所有輸入直接打包進提示上下文中。隨著輸入增加，過度填充提示會變得昂貴且讓模型難以導航。更好的模式是將資源暫存在容器文件系統中，讓模型決定使用 Shell 指令開啟、解析或轉換什麼。就像人類一樣，模型在處理有組織的資訊時表現更好。

數據庫

容器上下文的第二部分是數據庫。在許多情況下，我們建議開發者將結構化數據存儲在 SQLite 等數據庫中並進行查詢。例如，與其將整個試算表複製到提示中，不如給模型一個表格描述——有哪些列以及它們的含義——並讓它提取所需的行。

例如，如果你問：「本季度哪些產品的銷售額下降了？」模型可以僅查詢相關行，而不是掃描整個試算表。這更快、更便宜，且對大型數據集更具擴展性。

網路存取

容器上下文的第三部分是網路存取，這是代理工作負載中不可或缺的一部分。代理工作流可能需要獲取即時數據、呼叫外部 API 或安裝軟體包。與此同時，賦予容器不受限制的網路存取是有風險的：它可能會將資訊洩露給外部網站、無意中接觸敏感的內部或第三方系統，或使憑證洩露和數據外洩更難防範。

為了在不限制代理實用性的情況下解決這些疑慮，我們構建了託管容器以使用 Sidecar 出口代理（Egress Proxy）。所有出站網路請求都流經一個集中的政策層，該層執行允許列表和存取控制，同時保持流量的可觀察性。對於憑證，我們在出口處使用網域範圍的秘密注入（Secret Injection）。模型和容器只能看到佔位符，而原始秘密值保留在模型可見的上下文之外，僅應用於經批准的目的地。這降低了洩露風險，同時仍能實現經過身份驗證的外部呼叫。

代理技能

Shell 指令雖然強大，但許多任務會重複相同的多步驟模式。代理每次運行都必須重新發現工作流——重新規劃、重新發布指令並重新學習慣例——這導致結果不一致且浪費執行資源。代理技能⁠（在新視窗中開啟）將這些模式打包成可重複使用、可組合的構建塊。具體來說，一項技能是一個文件夾包，其中包含「SKILL.md⁠（在新視窗中開啟）」（包含元數據和指令）以及任何支援資源，如 API 規範和 UI 資產。

這種結構自然地映射到我們之前描述的運行時架構。容器提供持久文件和執行上下文，Shell 工具提供執行介面。兩者就緒後，模型可以在需要時使用 Shell 指令（ls、cat 等）發現技能文件、解釋指令，並在同一個代理迴圈中運行技能腳本。

我們提供 API⁠（在新視窗中開啟）來管理 OpenAI 平台中的技能。開發者將技能文件夾作為版本化包上傳並存儲，稍後可透過技能 ID 檢索。在將提示發送給模型之前，Responses API 會加載技能並將其包含在模型上下文中。這個序列是確定性的：

在決定一項技能是否相關時，模型會逐步探索其指令，並透過容器中的 Shell 指令執行其腳本。

代理是如何製成的

總結所有組件：Responses API 提供編排，Shell 工具提供可執行操作，託管容器提供持久的運行時上下文，技能層提供可重複使用的工作流邏輯，而壓縮功能則允許代理在擁有其所需上下文的情況下長時間運行。

憑藉這些原語，單個提示可以擴展為端到端的工作流：發現正確的技能、獲取數據、將其轉換為本地結構化狀態、高效查詢並生成持久的產出物。

下圖顯示了該系統如何運作以從即時數據創建試算表。

Responses API 編排代理任務

製作你自己的代理

有關結合 Shell 工具和電腦環境進行端到端工作流的深入示例，請參閱我們的開發者部落格文章⁠（在新視窗中開啟）和 Cookbook⁠（在新視窗中開啟），其中介紹了如何打包技能並透過 Responses API 執行它。

我們很高興看到開發者利用這套原語構建出什麼。語言模型不僅僅是為了生成文本、圖像和音訊——我們將繼續發展我們的平台，使其在處理大規模、複雜的現實世界任務方面變得更加強大。

作者

延伸閱讀

工程 2026 年 2 月 13 日

工程 2026 年 2 月 11 日

工程 2026 年 2 月 4 日