精簡的任務執行框架和可執行程式碼的智能代理，更適合處理開放式任務；過於僵化的協調機制反而可能限制模型表現。
因此，程式碼執行和沙箱機制如今已成為智能代理系統的核心架構考量。
Agents SDK 可降低建立程式碼執行智能代理所需的複雜度和程式碼量；在我們的測試中，最多可減少至六分之一。
長久以來，智能代理系統的進步主要來自改善協調機制，包括更佳的提示詞設計、工具介面、情境管理，以及更嚴密的控制流程。但隨着編程智能代理的能力提升，這種平衡開始轉變。
在許多開放式工作流程中，瓶頸已不再是智能代理循環本身，而是執行層：模型在沙箱中編寫程式碼、執行指令、檢視輸出並反覆改進。隨着更多任務層面的推理移至該環境，周邊的協調機制需要變得更簡單，讓模型充分發揮能力。
新版 Agents SDK 正是為這項轉變提供支援。在搶先體驗期間的測試中，我們發現它並非再加入一層框架邏輯，而是讓執行層更模組化、更容易組合，使系統的其餘部分保持精簡。
在任務執行框架工程中，將任務執行框架精簡至最低有效形式已成為趨勢。概括而言，任務執行框架就是模型周邊的軟件：這一層負責管理情境、工具、控制流程及回饋循環，讓模型能可靠地完成工作。
過去數年，智能代理表現的許多改進，都源於加強這一層。更佳的工具、更完善的記憶與檢索、更明確的任務拆解，以及更嚴密的協調機制，往往能提升系統的可靠性和能力。在這種模式下，進步主要意味着把更多任務邏輯編入模型周邊的軟件。
如今，至少對某一類開放式任務而言，這種模式的效用正在減弱。越來越多專案和論文顯示，任務執行框架加入更多規範，並不一定能提升表現。在輔助編程、長時間運行任務、瀏覽器操作和長情境任務中，同一模式一再出現：當模型足夠智能時，強行把過多任務結構置於周邊軟件中，可能由優勢變成限制。
因此，任務執行框架的角色正在改變。任務執行框架不再試圖透過僵化的協調機制預先涵蓋任務，而是逐漸轉為提供簡潔的執行介面：模型可在沙箱中檢視狀態、執行程式碼、從錯誤中恢復並調整方法，同時仍受系統介面和防護措施約束。這與 Andrej Karpathy 在 Software Engineer 3.0 中描述的轉變相近：部分原本存在於軟件中的邏輯，向上移至「提示詞」。
這並不代表智能代理系統應全面移除結構。許多任務仍可受益於明確的工作流程、啟發法和確定性防護規則，尤其是範圍狹窄、大量重複或成功標準清晰的任務。正如我們在上一篇關於智能代理系統設計的啟發法的文章中所述，如果可靠的邏輯流程既可行又理想，穩健的協調機制依然重要。
對開放式任務而言，重點正在轉移。挑戰不再是設計日益複雜的協調層，而是建立簡潔、可觀察且充分模組化的執行環境，讓模型能在其中有效工作。
當智能代理能夠讀取檔案、編寫程式碼、執行 shell 指令並啟動長時間運行的任務，工程挑戰便會改變。難點已不再只是提示詞優化或工具路由。智能代理如今在真實系統上操作，能力因而大幅提升；但這也擴大了安全與保安風險面，使這些智能代理更為敏感。例如，如果環境隔離不當，能執行程式碼的智能代理可能會作出有害操作（請參閱 AISI 的 Sandbox Bench）。
因此，沙箱機制正成為智能代理框架的重要考量。在較早期的系統中，執行功能通常被視為附加元件，即加裝在任務執行框架上的工具。但當執行變成具狀態、長時間運行或遙距進行時，這種做法便開始失效。管理沙箱本身、其生命週期、狀態和介面，以及沙箱與智能代理循環的銜接，很快便會成為獨立的系統設計問題。這正是現時越來越多供應商提供程式碼執行託管環境的原因之一，包括 OpenAI 的 Container API 和 shell 工具、Modal、Cloudflare、Daytona、E2B 等。
這項邊界至關重要，因為程式碼執行需要比任務執行框架其他部分更強的隔離和更嚴格的運行時控制。在實際應用中，實作不當的程式碼執行智能代理可能帶來三項關乎業務的重大風險：運算開支失控、對內部系統作出破壞性操作，以及敏感資料外洩。透過適當的容器化、隔離和運行時防護措施，可將這些風險控制在實際部署可接受的水平。
可以把這想像成為智能代理提供專屬的密封工作空間，而不是把整間辦公室的鑰匙交給它。它仍可在該空間內完成有用的工作，但只能在明確界定的範圍內行動。你可以限制它使用的運算資源、可接觸的系統和檔案，並從源頭控制它可取得的資料。
這無法完全消除風險，卻可把問題由「智能代理在你的基礎設施中任意行動」，轉變為「智能代理在受控環境內運作」。如果這一層將成為智能代理系統的標準部分，框架本身就需要把它列為一級功能。這樣，沙箱便成為模組化執行層，提供可移植的基礎元件，讓開發人員能迅速採用、跨供應商切換及擴展，而毋須不斷重寫智能代理邏輯。
當智能代理開始執行程式碼，沙箱本身也需要協調管理。從本機概念驗證轉向遙距執行、多個後端或長時間運行的工作階段，會令營運負擔急劇增加。你需要以一致方式建立、停止、暫停和恢復環境，建立狀態快照、稍後重新連線，並跨供應商管理這一切。
這些工作在概念上並不亮眼，但在實務上十分重要。當每個團隊都要從零開始重建智能代理管道時，這類基礎設施尤其棘手，未整合至智能代理框架時更是如此……
此時，更完善的框架支援便十分重要。我們曾搶先體驗新版 OpenAI Agents SDK，並用它自行建立沙箱化智能代理。最突出的地方是架構重點的轉變：SDK 將執行視為一級架構層，而非周邊工具。實際上，這意味着你能以更少程式碼啟動沙箱化智能代理、建立沙箱快照或恢復執行（在我們部分測試中，程式碼量約減至六分之一），之後更可切換後端，而毋須重寫周邊的智能代理邏輯。
這種更清晰的職責分離，讓任務執行框架可專注於推理、情境和工作流程。執行層則可專注於隔離、可移植性和運行時狀態。這種抽象化設計更容易建立能力更強、也更易演進的編程智能代理，使其可在本機與遙距執行之間切換、支援更長時間運行的任務，並可更改執行後端而毋須重新設計整個系統。
隨着更多任務層面的邏輯由任務執行框架移入模型，部分系統複雜度也隨之向下轉移至執行層。程式碼執行和沙箱機制如今已成為智能代理系統的核心架構考量，對編程比重高和開放式任務尤其重要。如今，設計智能代理管道固然重要，設計一個讓智能代理可安全、可靠且持續行動的環境亦同樣重要。
因此，沙箱化執行的高階抽象層十分重要。新版 OpenAI Agents SDK 正朝這個方向發展，將執行視為系統中的模組化層：可在不同後端之間移植、在長時間運行的任務中保持狀態，而且使用簡單，毋須為每項新配置重建相同的基礎設施。
更廣泛而言，下一代智能代理框架的特點，可能不在於加入多少協調邏輯，而在於能否妥善建構智能代理日益依賴的執行環境。