OpenAI Agents SDK 的可插拔式程式碼執行

搶先體驗 OpenAI Agents SDK,瞭解可插拔式沙箱如何簡化跨遠端供應商的程式碼執行。

執行摘要

  • 較精簡的任務執行框架與能執行程式碼的智慧體更適合開放式任務,因為過於僵化的編排可能限制模型效能。

  • 因此,程式碼執行與沙箱機制如今已成為智慧體系統的核心架構考量。

  • 根據我們的測試,Agents SDK 可降低建置程式碼執行智慧體所需的複雜度,程式碼量最多可減至六分之一。

長久以來,智慧體系統的進展主要來自改善編排,包括更好的提示詞設計、工具介面、情境管理,以及更嚴密的控制流程。但隨著程式設計智慧體的能力提升,這項平衡正開始轉變。

在許多開放式工作流程中,瓶頸不再是智慧體迴圈本身,而是執行層:模型在沙箱內編寫程式碼、執行命令、檢查輸出並反覆改進。隨著更多任務層級的推理轉移至該環境,周邊編排也必須簡化,才能讓模型充分發揮能力。

新版 Agents SDK 所實現的正是這項轉變。在搶先體驗期間的測試中,我們發現它並未再增加一層框架邏輯,而是讓執行層更模組化且可組合,使系統其餘部分得以維持精簡。

轉變

任務執行框架工程領域,將框架精簡至最低限度的有效形式已蔚為趨勢。概括而言,任務執行框架就是模型周邊的軟體:它負責管理情境、工具、控制流程與回饋迴圈,讓模型能可靠地完成工作。

過去幾年,智慧體效能的許多提升都來自強化這一層。更好的工具、記憶與擷取機制、更明確的任務拆解,以及更嚴密的編排,往往能提升系統的可靠性與能力。在這種典範下,進步主要意味著將更多任務邏輯編入模型周邊的軟體。

至少對某一類開放式任務而言,這種模式如今正逐漸式微。愈來愈多專案與論文指出,任務執行框架變得更具規範性時,效能未必會隨之提升。在輔助程式設計、長時間執行的任務瀏覽器使用,以及長情境任務中,同一模式反覆出現:當模型具備足夠智慧後,若將過多任務結構強加於周邊軟體,反而可能成為限制,而非優勢。

因此,任務執行框架的角色正在改變。任務執行框架不再試圖透過僵化編排預先設想任務,而是愈來愈著重提供清晰的執行介面:模型可在沙箱中檢查狀態、執行程式碼、從錯誤中復原並調整做法,同時仍受系統介面與防護措施約束。這與 Andrej Karpathy 在 Software Engineer 3.0 中描述的轉變相近:部分原本存在於軟體中的邏輯,向上移入「提示詞」。

這並不表示智慧體系統應全面移除結構。許多任務仍可受益於明確的工作流程、啟發法與確定性防護機制,尤其是範圍明確、數量龐大或成功標準清楚的任務。正如我們先前在〈智慧體系統設計的啟發法〉一文所述,當可靠的邏輯流程既可行又符合需求時,強而有力的編排仍然重要。

對開放式任務而言,重點正在轉移。挑戰不再是設計愈加繁複的編排層,而是建構足夠簡潔、可觀察且模組化的執行環境,讓模型能在其中有效運作。

將複雜度從任務執行框架轉移至執行層

一旦智慧體能讀取檔案、編寫程式碼、執行殼層命令並啟動長時間執行的任務,工程挑戰便隨之改變。難題不再只是提示詞最佳化或工具路由。智慧體如今能在真實系統上操作,因而具備強大得多的能力;但同時也更為敏感,因為這擴大了安全與資安的風險面。例如,若環境隔離不良,能執行程式碼的智慧體可能採取有害行動(請參閱 AISI 的 Sandbox Bench)。

因此,沙箱機制正成為智慧體框架中的關鍵考量。在早期系統中,執行功能往往被視為附加元件,也就是加裝到任務執行框架上的工具。但執行作業一旦具備狀態、需長時間運作或移至遠端,這種做法便開始失效。管理沙箱本身及其生命週期、狀態、介面,以及它與智慧體迴圈的銜接,很快就會成為獨立的系統設計問題。這正是愈來愈多供應商開始提供代管程式碼執行環境的原因之一,包括 OpenAI 的 Container API 與 shell 工具、Modal、Cloudflare、Daytona、E2B 等。

這道界線相當重要,因為程式碼執行需要比任務執行框架其餘部分更嚴密的隔離與執行階段控制。實務上,實作不佳的程式碼執行智慧體可能帶來三項攸關業務的重大風險:運算支出失控、對內部系統採取破壞性行動,以及敏感資訊外洩。透過適當的容器化、隔離與執行階段防護措施,可將這些風險控制在實際部署可接受的程度。

可以這樣理解:與其把整間辦公室的鑰匙交給智慧體,不如給它一個專屬的封閉工作區。它仍可在該空間內完成實用工作,但只能在明確界定的範圍內行動。您可以設定運算用量上限、限制它能存取的系統與檔案,並從一開始就控制它可取得的資訊。

這無法完全消除風險,卻能將問題從「智慧體在您的基礎架構中不受約束地行動」,轉變為「智慧體在受控環境中運作」。若這一層將成為智慧體系統的標準組成部分,框架本身就必須將其視為第一級功能提供支援。如此一來,沙箱便成為模組化的執行層,提供可攜式基本元件,讓開發人員能快速採用、跨供應商替換,並在無須反覆重寫智慧體邏輯的情況下擴充。

為何智慧體框架必須提供更完善的支援

智慧體一旦執行程式碼,沙箱本身也需要編排。從本機概念驗證轉向遠端執行、多個後端或長時間工作階段,會使營運負擔大幅攀升。您需要一套一致的方法來建立、停止、暫停及恢復環境,建立狀態快照、稍後重新連線,並跨供應商管理這一切。

這些工作在概念上並不亮眼,卻攸關實際成效。當每個團隊都要從頭重建智慧體管線時,這類基礎架構尤其令人頭痛;若未整合至智慧體框架中,問題更為嚴重……

這正是更完善的框架支援變得重要之處。我們曾搶先體驗新版 OpenAI Agents SDK,並親自用它建置沙箱化智慧體。最引人注目的是架構重心的轉變:SDK 將執行視為第一級系統層,而非周邊工具。實務上,這表示您只需更少的程式碼,即可啟動沙箱化智慧體、建立沙箱快照或恢復執行(在部分測試中,程式碼量約為原本的六分之一),之後還能切換後端,無須重寫周邊智慧體邏輯。

這種更清晰的職責分離,讓任務執行框架得以專注於推理、情境與工作流程。執行層則可專注於隔離、可攜性與執行階段狀態。這種抽象化設計可讓程式設計智慧體具備更強能力,也更容易持續演進;它們能在本機與遠端執行之間切換、支援更長時間的任務,並可更換執行後端,無須重新設計整套系統。

重點摘要

隨著更多任務層級邏輯從任務執行框架移入模型,部分系統複雜度也會隨之下移至執行層。程式碼執行與沙箱機制如今已成為智慧體系統的核心架構考量,對大量涉及程式設計及開放式任務尤其如此。設計智慧體管線如今固然重要,但同樣重要的是設計一套能讓智慧體長期安全、可靠行動的環境。

這正是沙箱化執行的高階抽象化如此重要的原因。新版 OpenAI Agents SDK 正朝此方向邁進,將執行視為系統中的模組化層:可跨後端移植、能在長時間執行的任務中保留狀態,而且使用方式足夠簡單,無須為每種新設定重建相同的基礎架構。

更廣泛的啟示是,下一代智慧體框架的特色,可能不再取決於加入多少編排邏輯,而在於能否妥善建構智慧體日益倚賴的執行環境。

作者

Romain Bourboulou