從模型到智能代理：為 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 就會與我們一同學習。

現在我們來看看狀態與資源。容器不僅是執行指令的地方，同時亦是模型的工作上下文。在容器內，模型可以讀取檔案、查詢資料庫，並在網絡政策控制下存取外部系統。

容器上下文的第一部分是檔案系統，用於上載、整理和管理資源。我們建立了 container and file⁠（在新視窗中開啟） 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 工具和電腦環境來建立端對端工作流程，可以參閱我們的開發人員網誌文章⁠（在新視窗中開啟）和大全⁠（在新視窗中開啟），了解如何封裝技能並透過 Responses API 執行。

我們很期待看到開發人員運用這組基礎元件構建的成果。語言模型的用途不應只限於生成文字、圖片和音訊，因此我們會持續推動平台演進，令平台更有能力以規模化方式處理複雜的現實世界任務。