From fork() to Fleet: Designing an Agent Sandbox Cloud — Abhishek Bhardwaj, OpenAI

OpenAI面臨的核心挑戰是：大型語言模型（GPT系列）在生成代碼時表現優異，但這些模型生成的代碼需要在真實系統上執行才能驗證正確性。然而，代碼執行涉及安全風險。模型可能（無意或有意地）生成試圖進行權限提升、讀取敏感文件或在雲環境中洩露其他用戶數據的代碼。因此，沙箱成為必需品—既要允許代碼安全執行，又要防止越權。

講者從第一原理展開沙箱的演進。最簡單的方案是fork/exec模型：harness（訓練或推理框架）直接分叉進程執行模型生成的代碼。優點是原生性能，缺點是完全沒有隔離。惡意代碼可直接呼叫系統調用攻擊主機內核，或造成資源濫用（如無限fork導致節點癱瘓）。Linux容器（基於命名空間和cgroups）改進了這一點：PID命名空間讓容器內看到獨立的進程樹；掛載命名空間隔離文件系統；cgroups限制CPU和記憶體消耗。但根本問題未解決—容器進程仍直接與主機內核互動，內核成為共同的攻擊面。SecComp過濾系統調用可減少攻擊表面，但容易造成功能受限的反饋迴圈。GVisor試圖進一步隔離：它用Go實現了一個用戶空間內核（sentry），攔截Guest的系統調用，而非直接傳遞。這樣即使Guest進程被破壞，執行代碼也停留在用戶空間（ring 3）而非內核空間（ring 0）。但仍有漏洞：若sentry本身被利用，攻擊者可進行兩步式漏洞鏈利用逃逸。

真正的突破是硬件虛擬化。Linux KVM使用CPU的VMX模式提供硬件級隔離。Guest OS運行在VMX non-root模式，具有ring 0權限但在獨立的處理器上下文中；Host OS和超級監視程序運行在VMX root模式。這在物理硬件層面保證了隔離—即使Guest內核被全面控制，Host仍絕對安全。為實現高效虛擬化，業界過去依賴QEMU（通用虛擬機監視程序）。但QEMU代碼臃腫、用C寫成、支援眾多設備（歷史上許多逃逸都是通過設備模擬漏洞）。最近五年出現了"微VM"浪潮—用Rust重寫的精簡VMM，如Google的CrossVM、Amazon的Firecracker和社區的Cloud Hypervisor。它們"微"的含義不是Guest小，而是VMM本身更輕—只支持必要設備、啟動更快（秒級變毫秒級）、記憶體佔用更少。Para-virtualization進一步優化了性能：Guest驅動通過VertIO協議與Host通信，比全模擬設備高效得多，使虛擬機在實用性上接近原生性能。

但安全本身不夠—模型需要持久化存儲。想象一個Agent在沙箱裡耗時數小時建構代碼倉庫和演示文檔。若節點故障，所有工作丟失—既浪費了寶貴的GPU算力，也毀滅了用戶體驗。OpenAI引入了增量快照機制。每次快照不是保存整個根文件系統，而是利用FIEMAP檢測哪些磁盤塊發生變更，只保存diff。基於copy-on-write（XFS支持），新建快照的成本是零（不複製任何塊），寫入時才付出成本。更巧妙的是，快照操作本身立即返回快照ID，系統在後台異步上傳到雲存儲，modelharnessHarness無須等待。恢復也很快：給定快照ID，系統解析其lineage（前置快照鏈），逐層下載，應用回base image，秒內啟動新虛擬機。這解鎖了驚人能力：模型可進行蒙特卡洛式搜索，在狀態樹中往返探索（checkpoint、分支、回溯），有望在藥物發現、量子化學等領域加速科研。另一種模式是"always-on persistence"—利用NBD將GCS或S3掛載為虛擬機內的虛擬塊設備，用分層緩存（VM內→節點內→遠端）實現自動持久化，無需顯式快照呼叫。

最後是編排層。沙箱需跨多節點和地理區域執行，以支持ChatGPT規模的並發。頂層控制平面根據區域負載和延遲選擇集群；集群內調度器根據節點負載和快照本地化程度選擇節點。為實現低延遲（產品成功的必要條件），系統採用多策略：預熱沙箱池（但空閒時消耗資源）、記憶體快照及時啟動（毫秒級但複雜）或混合方案。快照與編排的協作尤其聰明—調度器評估各節點已持有的快照層，優先選需下載最少數據的節點，進一步降低建立延遲和提升可靠性。