從模型到智慧體：為 Responses API 建立電腦執行環境

我們正從以模型為核心的使用方式，轉向能處理複雜流程的智慧體。透過輸入提示詞來與模型互動，只能調用模型既有的知識與能力；若為模型提供電腦執行環境，則能擴展應用範圍，例如執行服務、向 API 取得資料，或產出試算表與報告等實用的具體成品。

在建構智慧體時，會遇到幾個實務問題：中間檔案應該存放在哪裡？如何避免把大型表格直接貼進提示詞？如何讓工作流程具備網路存取能力，同時不帶來安全風險？以及在不自行打造整套工作流程系統的情況下，如何處理逾時與重試？

我們沒有要求開發者自行建置執行環境，而是打造必要的元件，為 Responses API⁠(在新視窗中開啟) 提供電腦環境，使系統能穩定執行真實世界的任務。

OpenAI 的 Responses API 搭配 shell 工具與託管容器工作區，專為解決這些實務問題而設計。模型會提出步驟與指令；平台則在隔離環境中執行，該環境包含用於輸入與輸出的檔案系統、可選的結構化儲存（如 SQLite），以及受控的網路存取。

本文探討我們如何為智慧體打造電腦執行環境，並分享初步經驗，說明如何讓生產工作流程更快速、更穩定可重複，同時提升安全性。

良好的智慧體工作流程始於緊密的執行循環：模型提出動作，例如讀取檔案或透過 API 取得資料；平台負責執行，並將結果帶入下一步。我們會先從 shell 工具開始，這是最能直接觀察此循環運作的方式，接著再介紹容器工作區、網路存取、可重複使用的技能，以及上下文壓縮。

要理解 shell 工具，先了解語言模型一般如何使用工具會更清楚，例如呼叫函式或與電腦互動。在訓練過程中，模型會逐步看到工具如何使用，以及會產生什麼結果，模型可從中學習判斷何時該使用工具，以及如何使用。所謂的「使用工具」，其實是指模型「提出工具呼叫的要求」，模型本身實際上無法執行工具呼叫。

Shell 工具大幅提升模型的能力：模型可透過命令列與電腦互動，執行各種任務，例如從搜尋文字到發送 API 要求等等。我們的 shell 工具採用常見 Unix 工具組打造，具備你預期的各項功能，且提供 grep、curl 和 awk 等無需額外設定即可使用的工具。

現有的程式碼解譯器僅能執行 Python，相較之下，shell 工具支援更廣泛的使用情境，例如執行 Go 或 Java 程式，或啟動 NodeJS 伺服器。這樣的彈性讓模型能完成複雜的智慧體任務。

單靠模型本身只能提出 shell 指令，那這些指令實際上是如何執行的？我們需要一個協調機制，負責接收模型輸出、呼叫工具，並將工具的回應持續回傳給模型，形成循環，直到任務完成。

Responses API 是開發人員與 OpenAI 模型互動的主要介面。搭配自訂工具使用時，Responses API 會將控制權交回用戶端，而用戶端需要自行建立執行工具的機制。不過，這個 API 也能在無需額外設定的情況下，於模型與託管工具之間進行協調。

當 Responses API 接收到提示詞時，會組成模型的上下文，包括使用者提示詞、先前的對話狀態，以及工具指示。若要讓 shell 執行正常運作，提示詞必須指出要使用 shell 工具，且所選模型必須具備提出 shell 指令的能力；GPT‑5.2 及後續版本已支援此功能。有了這些上下文後，模型會決定下一步動作。若模型選擇執行 shell，會將一個或多個 shell 指令回傳給 Responses API 服務。API 服務會將這些指令轉送至容器執行環境，串流回傳 shell 輸出，並將其納入下一次要求的上下文。模型接著可以檢視結果、發出後續指令，或產生最終答案。Responses API 會持續重複這個循環，直到模型回傳不再包含額外 shell 指令的最終結果。

當 Responses API 執行 shell 指令時，會與容器服務維持串流連線。一旦有輸出產生，API 會近乎即時地將結果傳回模型，讓模型判斷是否等待更多輸出、執行其他指令，或直接產生最終回應。

模型可在單一步驟中提出多個 shell 指令，Responses API 則會透過不同的容器工作階段並行執行。各個工作階段會各自串流輸出，API 會將這些串流整合為結構化的工具輸出，納入上下文。換句話說，智慧體的運作循環能將工作並行處理，例如搜尋檔案、擷取資料，以及驗證中間結果。

當指令涉及檔案操作或資料處理時，shell 輸出可能非常龐大，佔用了上下文空間，卻未必提供實際價值。為了控制這種情況，模型會為每個指令設定輸出上限。Responses API 會套用這個上限，回傳經過限制的結果，保留輸出的開頭與結尾，並標示中間省略的內容。例如，你可以將輸出限制為 1,000 個字元，並保留開頭與結尾：

開頭的文字 ... 中間已截斷 1,000 個字元 ... 結尾的文字

綜合來看，並行執行與輸出上限讓智慧體運作循環同時具備速度與上下文效率，使模型能持續針對關鍵結果進行推理，避免被原始終端機日誌淹沒。

智慧體運作循環的一個潛在問題是，任務可能會長時間執行。長時間執行的任務會填滿上下文視窗，而上下文對於跨回合與跨智慧體維持脈絡非常重要。想像智慧體呼叫一項技能、取得回應，接著加入工具呼叫與推理摘要，有限的上下文視窗很快就會填滿。為了避免智慧體持續運作時遺失重要脈絡，就需要設法保留關鍵細節，同時移除多餘內容。我們沒有要求開發者設計並維護自訂的摘要或狀態管理系統，而是在 Responses API 中加入原生壓縮機制，使其運作方式貼近模型的行為與訓練特性。

我們最新的模型經過訓練，能分析先前的對話狀態，並產生一個壓縮項目，藉由加密且具備 Token 效率的方式，保留先前狀態中的關鍵內容。壓縮後，下一個上下文視窗會由該壓縮項目與先前視窗中具價值的內容組成。這讓工作流程即使跨越不同視窗，也能維持連貫運作，即便在長時間、多步驟且依賴工具的工作階段中也是如此。Codex 仰賴此機制，讓長時間的程式碼任務與反覆的工具執行得以持續進行，並兼顧品質。

壓縮可直接在伺服器端使用，或透過獨立的 `/compact` 端點呼叫。伺服器端壓縮可讓你設定門檻，並由系統自動判斷何時進行壓縮，無需處理複雜的用戶端邏輯。這也讓有效的輸入上下文視窗略為擴大，使系統能在壓縮前短暫容許小幅超出，因此接近上限的請求仍可處理並壓縮，而不會被拒絕。隨著模型訓練持續演進，這套原生壓縮機制也會隨每次 OpenAI 模型發布同步進化。

Codex 協助我們建置壓縮系統，同時也在早期階段實際使用這套系統。當某個 Codex 執行個體發生壓縮錯誤時，我們會啟動另一個執行個體進行調查。在持續處理這個問題的過程中，Codex 逐步建立出一套原生且有效的壓縮機制。Codex 能夠檢視並持續改進自身的這項能力，已成為在 OpenAI 工作中特別有趣的一環。多數工具只需要使用者學會操作；Codex 則會與我們一同學習。

接下來說明狀態與資源。容器不只是執行指令的環境，也是模型運作的上下文。在容器中，模型可以讀取檔案、查詢資料庫，並在網路政策控管下存取外部系統。

容器上下文的第一個部分是檔案系統，用於上傳、整理與管理資源。我們建置了容器與檔案 API⁠(在新視窗中開啟)，讓模型能掌握可用資料的整體結構，並選擇更精準的檔案操作，而非進行範圍廣、雜訊多的掃描。

一個常見的反模式是將所有輸入直接塞進提示詞的上下文。隨著輸入增加，過於龐大的提示詞不僅使成本提高，也會讓模型難以掌握內容。較佳的做法是先將資源放入容器的檔案系統，再讓模型透過 shell 指令自行決定要開啟、解析或轉換哪些內容。正如人類一樣，資訊有條理時，模型的表現會更好。

容器上下文的第二個部分是資料庫。在許多情況下，我們建議開發人員將結構化資料以 SQLite 形式儲存在資料庫中，並透過查詢存取。例如，與其將整份試算表直接貼進提示詞，不如提供模型表格結構的描述（包含有哪些欄位及其意義），再讓模型擷取所需的資料列。

舉例來說，如果你問：「本季哪些產品的銷售額在下滑？」模型可以只查詢相關的資料列，不必掃描整份試算表。這樣做更快、更省成本，也更能擴展到大型資料集。

容器上下文的第三個部分是網路存取，這是智慧體運作不可或缺的一環。智慧體的工作流程可能需要擷取即時資料、呼叫外部 API，或安裝套件。同時，若任由容器不受限制地連上網際網路，會帶來風險：可能將資訊暴露給外部網站、無意間觸及敏感的內部或第三方系統，或使憑證外洩與資料外流更難防範。

為了在不影響智慧體實用性的前提下解決這些問題，我們為託管容器導入 sidecar 出站代理。所有對外網路請求都會經由集中式策略層處理，在維持流量可觀測的同時，強制套用允許清單與存取控制。在憑證處理方面，我們於出口採用以網域為範圍的機密注入機制。模型與容器只會看到佔位符，原始機密值不會出現在模型可見的上下文中，且只會套用至已核准的目的地。這能降低外洩風險，同時仍可進行需要驗證的外部呼叫。

Shell 指令功能強大，但許多任務會重複相同的多步驟流程。智慧體每次執行都必須重新摸索工作流程，重新規劃、重新下達指令，並重新理解相關慣例，導致結果不一致，也浪費執行資源。智慧體技能⁠(在新視窗中開啟)會將這些流程封裝成可重複使用、可組合的基礎元件。具體而言，技能是一種資料夾套件，其中包含 ‘SKILL.md⁠(在新視窗中開啟)’（內含中繼資料與操作指示），以及其他支援資源，例如 API 規格與 UI 資產。

這種結構可自然對應到我們先前說明的執行階段架構。容器提供可持續保存的檔案與執行上下文，而 shell 工具則提供執行介面。兩者到位後，模型就能在需要時透過 shell 指令（`ls`、`cat` 等）探索技能檔案、理解指示，並在同一個智慧體運作循環中執行技能腳本。

我們提供 API⁠(在新視窗中開啟)，用於管理 OpenAI 平台中的技能。開發人員會將技能資料夾上傳並儲存為具版本的套件，之後可透過技能 ID 取回。在將提示詞傳送至模型之前，Responses API 會先載入技能，並將其納入模型上下文。此流程具備確定性：

1. 擷取技能中繼資料，包括名稱與描述。
2. 擷取技能套件，將其複製到容器中，並進行解壓縮。
3. 使用技能中繼資料與容器路徑更新模型上下文。

模型在判斷技能是否相關時，會逐步檢視其指示，並透過容器中的 shell 指令執行對應腳本。

整體來看：Responses API 負責協調編排，shell 工具提供可執行的操作，託管容器提供持續運作的執行環境，技能負責封裝可重複使用的工作流程邏輯，而上下文壓縮則讓智慧體在具備必要上下文的情況下長時間運作。

有了這些基礎元件，一個提示詞就能延伸為端到端的工作流程：找到合適的技能、擷取資料、轉換為本地的結構化狀態、高效率查詢，並產生可長期使用的成品。

下方圖表說明此系統如何從即時資料建立試算表。

如需深入了解如何結合 shell 工具與電腦環境，打造端到端工作流程，請參閱我們的開發者部落格文章⁠(在新視窗中開啟)與 Cookbook⁠(在新視窗中開啟)，其中會逐步說明如何封裝技能，並透過 Responses API 執行。

我們期待看到開發人員運用這組基礎元件建構的成果。語言模型的用途不僅限於生成文字、圖片和音訊，我們將持續演進平台，使其能在大規模情境下處理複雜的真實世界任務。