執行 AI 生成程式碼的生產應用程式，需要一個能強制執行程序級別隔離、支援並行工作階段、提供可程式化生命週期 API、具備可觀測的日誌與資源指標、實施套件與網路策略，並能與應用後端乾淨整合的沙盒。若未系統性地評估每個面向，團隊最容易在上線後遇到問題：在暫存環境看似安全的工作負載，在真實流量下會失敗、在不同租戶之間洩漏狀態，或靜默執行應用程式從未打算允許的程式碼。
本指南是一份需求檢查清單。內容涵蓋在各個隔離層級需要驗證哪些事項、生產環境的生命週期 API 必須公開哪些功能、可觀測性與資源控管應具備什麼樣貌，以及後端整合模式如何在設計中決定成敗。無論您是評估託管沙盒還是自行建置，這些都是在出貨前值得回答的問題。
沙盒隔離：程序、容器與微虛擬機
隔離是一個光譜，每個層級在效能、可攜性以及對生成程式碼的信任程度上，都有不同的取捨。
程序級別隔離 使用作業系統原始功能——命名空間、cgroups、seccomp 以及 AppArmor 或 SELinux 設定檔——來限制程序能存取的內容。它速度快，不需要獨立的 VM 核心，但所有程序共用同一個主機核心。核心漏洞或通過 seccomp 過濾器的特權系統呼叫，可能會影響同一台主機上的其他工作負載。程序隔離是低風險、短生命期、受信任程式碼路徑的合理起點，但對於可能嘗試系統呼叫、衍生子程序或安裝套件的不受信任 AI 生成程式碼來說，這層邊界過於薄弱。
在此層級需要驗證的項目：
- 哪些系統呼叫被阻擋？當嘗試未知的系統呼叫時，預設策略是什麼？
- 命名空間是每個任務、每個租戶，還是跨工作共用？
- cgroup 限制是在任務層級還是僅在主機層級強制執行？
- 沙盒在退出時是否清除所有程序、暫存檔案、socket 與共享記憶體？
容器級別隔離 增加了檔案系統與網路命名空間邊界，並使映像管理可重複。容器啟動速度比完整 VM 快，更容易組合，並被編排層廣泛支援。缺點是容器仍然共用主機核心，容器邊界的強度取決於底層執行階段設定。特權容器、寬鬆的能力集、掛載主機 socket 以及主機網路模式，都會使有效邊界幾乎化為烏有。
在此層級需要驗證的項目：
- 容器映像是否精簡，僅包含工作負載實際需要的執行階段與工具？
- 是否已移除能力至最必要的最小集合？
- 容器是否無根執行？若需要 root 權限，相關控管措施為何？
- 主機 PID 命名空間、主機網路與 Docker socket 是否明確排除？
- 掛載的磁碟區是否僅限於明確定義的路徑？根檔案系統在可能的情況下是否設為唯讀？
微虛擬機隔離 將每個工作負載放入輕量級虛擬機中——擁有自己的 Guest 核心、虛擬裝置，以及基於 KVM 的 Guest 與主機之間的邊界。像 Firecracker 這類技術使用精簡的裝置模型來減少攻擊面，同時啟動速度快到足以滿足互動用途。微虛擬機邊界意味著 Guest 內的核心漏洞不會自動影響主機或其他 Guest。
在此層級需要驗證的項目：
- 每個 agent 執行、每個租戶或每個並行工作階段是否各自擁有獨立的微虛擬機？
- 從 API 呼叫到準備執行之間的啟動延遲是多少？這個延遲是從熱池、快照還是冷啟動測量的？
- Guest 映像是否有版本控制、是否經過稽核以確認包含哪些執行階段與工具，並定期更新？
- 如果 Guest 核心恐慌或無回應，主機層級會發生什麼事？
實際決策取決於您的威脅模型。微虛擬機隔離是目前針對不受信任 AI 生成程式碼最強的通用邊界，但它無法取代檔案系統策略、出口流量控管、套件治理或機密處理。這些控管措施必須建置在您選擇的任何隔離層之上。
管理並行沙盒工作階段
一個同時為多位使用者生成程式碼的生產應用程式，需要一個將並行性視為首要關注事項、而非事後才想到的沙盒。
關鍵問題是：
每工作階段隔離：當同時有 50 個工作階段在執行時，每個工作階段是否有自己的隔離檔案系統、程序樹、網路命名空間與憑證範圍？工作階段之間的狀態洩漏是多租戶沙盒應用程式中最具破壞性的失敗模式之一，而且在測試中（工作階段順序執行）通常看不見。
工作階段限制與背壓：沙盒是否將並行限制作為明確的 API 合約呈現？如果 500 個請求抵達，而平台支援 100 個並行工作階段，API 是回傳結構化錯誤、將請求排入佇列，還是默默降級？生產應用程式需要這個信號來實現背壓、佇列管理以及面向使用者的回饋。
負載下的資源公平性：當一個工作階段消耗異常高的 CPU 或記憶體時，其他工作階段是否受到每工作階段資源限制的保護？還是一個嘈雜的工作負載就能拖慢整個池？
熱池與工作階段啟動延遲：互動式編寫功能需要亞秒級的工作階段啟動時間。這通常需要一個預先初始化的環境池，可以立即被索取，而非按需啟動。請驗證平台是否記錄了熱池可用性，以及在不同並行層級下預期的啟動延遲。
工作階段重用 vs. 全新環境：某些應用程式會從跨多個 agent 回合重用長期工作階段中受益，而其他的則需要為每個請求提供乾淨的環境。請驗證兩種模式是否都受支援，並且工作階段重用不會帶有來自先前對話的陳舊狀態。
生命週期 API：建立、執行、終止
生命週期 API 是應用程式與沙盒執行階段之間的介面。一個生產級別的 API 必須至少公開以下功能：
建立：初始化一個新的沙盒工作階段，可以選擇從範本或快照開始，並指定資源限制、環境變數與掛載的磁碟區。回應應包含工作階段 ID 與就緒信號，而不僅僅是確認。
執行：提交程式碼或命令進行執行。這應是一個非同步呼叫，回傳執行 ID。API 必須支援指定工作目錄、該次呼叫的環境覆蓋，以及逾時時間。
串流輸出：以串流方式（而非僅在執行完成後的最終結果）擷取標準輸出與標準錯誤。串流對於長時間執行的任務、耗時數秒的 agent 步驟，以及任何向使用者顯示增量進度的使用者體驗都非常重要。
終止：在執行完成前結束正在進行的執行。沙盒應保證整個程序樹被清除，而不僅僅是父程序。
清理：銷毀工作階段並釋放所有相關資源——檔案系統、記憶體、程序槽、網路狀態以及任何持有的憑證。此呼叫應具有冪等性，以便在網路錯誤後重試時不會導致錯誤。
上傳與下載檔案：在執行前將輸入檔案傳入沙盒，並在執行後檢索輸出產物。檔案傳送應受到大小限制，且哪些路徑可寫入應受策略控制。
值得為生產用途驗證的額外功能：
- 暫停與恢復：能否暫停長時間執行的工作階段並在之後恢復，而不遺失狀態？這對於速率限制、成本控管以及 agent 回合之間的工作階段交接很有用。
- 快照：能否擷取目前工作階段狀態，並用作未來工作階段的起點？這是實現熱池與可重用環境的關鍵機制。
- 逾時強制執行：如果執行中的程式碼超過牆鐘逾時，平台是否會乾淨地終止它並回報正確的退出狀態？
可觀測性：日誌、指標與追蹤
您無法除錯或稽核您看不見的東西。生產沙盒需要內建（而非事後附加）的可觀測性。
標準輸出與標準錯誤擷取：每次執行都應產生一個與工作階段 ID 和執行 ID 相關聯的擷取輸出記錄。這應在執行完成後可透過 API 存取，而不僅是即時串流。
執行日誌：平台應記錄哪些程式碼執行過、何時開始、何時結束、退出碼為何、哪個使用者或租戶擁有該工作階段、以及使用了哪個範本或快照。這些記錄是重建事件發生經過所需的最低資訊。
資源指標：生產應用程式需要每個工作階段的 CPU 使用率、記憶體峰值、牆鐘時間與檔案系統寫入指標。這有助於容量規劃、異常偵測與按工作階段的成本歸屬。
錯誤追蹤：當沙盒無法啟動、執行或清理時，錯誤資訊應結構化：錯誤碼、訊息、工作階段 ID，以及足夠的上下文來區分使用者錯誤（錯誤程式碼、缺少套件）與平台錯誤（配額超標、內部故障）。
稽核軌跡：對於多租戶應用程式，稽核軌跡應使 agent 行為可重建：工作階段 ID、租戶、執行順序、套件安裝、聯絡的外部網域、寫入的檔案以及清理結果。原始客戶程式碼與完整命令輸出預設可能不應屬於稽核日誌——請根據您的保留與存取政策實際能支援的內容來設計。
應避免的情況：一個沙盒僅顯示「執行失敗」，沒有結構化錯誤、沒有工作階段層級的日誌，也無法區分逾時、記憶體不足與程序逃脫嘗試。這迫使您在應用層自行檢測所有項目，造成重複工作，並遺漏沙盒可直接觀察到的事件。
CPU、記憶體與逾時限制
不受限制的資源消耗是沙盒工作負載在生產環境中造成問題的最簡單方式之一——無論是降低其他工作階段的效能，還是產生非預期的基礎架構成本。
生產沙盒必須在工作階段層級（而非僅在主機層級）強制執行限制：
CPU：限制單一工作階段可消耗的 CPU 時間。產生無限迴圈的工作階段不應降低同一主機上其他工作階段的效能。請驗證限制是硬上限（程序被節流或殺死）還是軟限制（與其他程序競爭可用 CPU）。
記憶體：設定記憶體上限，觸發清理或終止，而非允許工作階段耗盡主機記憶體。請驗證達到上限時會發生什麼事：OOM 殺死、結構化錯誤回應，還是無回應的掛起。
牆鐘逾時：每次執行呼叫都應有最大持續時間。逾時應在平台層級強制執行，而不僅在客戶端層級——如果客戶端斷開連線，沙盒仍應在設定的限制下終止執行。
磁碟用量：生成的程式碼可能會寫入大型輸出檔案、安裝大型套件或填滿工作目錄。工作階段工作目錄的磁碟配額可防止失控寫入。
程序計數：AI 生成程式碼可能會衍生子程序、背景工作者，或自行衍生更多程序的 shell 命令。對工作階段命名空間中的總程序數設定限制，可防止 fork 炸彈與失控的子程序樹。
在評估沙盒平台時，請檢查這些限制是否可依工作階段設定（以便不同使用者層級或任務類型能有不同限制）、是否在沙盒層級強制執行，以及達到限制時是否產生結構化 API 錯誤而非靜默失敗。
套件安裝策略
AI 生成程式碼經常要求安裝套件——pip install、npm install、apt-get、Git 克隆、直接 URL 擷取。這些操作會在執行階段將外部程式碼拉入沙盒，這是沙盒需要管控的最高風險操作之一。
生產套件策略應涵蓋：
註冊表允許清單：哪些套件註冊表被允許？預設是 PyPI 和 npm，但許多團隊希望可以限制為內部鏡像、精選註冊表或明確批准的來源。
安裝快取：當許多工作階段都安裝相同熱門套件時，層級快取或拉取代理可避免重複下載、減少啟動延遲，並提供一個檢查點來檢查正在擷取的內容。
離線模式：某些工作負載應完全不允許套件安裝——環境已預先建置在映像或範本中，安裝嘗試應失敗並顯示明確錯誤。對於可重現性比彈性更重要的評估執行，這是適當的模式。
雜湊驗證與鎖定檔案：當允許安裝套件時，固定版本與雜湊驗證可降低註冊表被破壞後改變沙盒內執行程式碼的風險。
大小限制：套件及其傳遞性依賴可能很大。對每個工作階段的下載總量設定大小上限，可防止意外或蓄意的儲存耗盡。
套件記錄：每次安裝嘗試都應記錄在執行稽核日誌中：套件名稱、請求的版本、註冊表來源以及成功/失敗。這是您在事件發生時重建進入沙盒的資料所需的資訊。
向沙盒供應商提問的問題不是「使用者能否安裝套件？」，而是「每次安裝如何被稽核？預設允許哪些註冊表？對於敏感工作負載，我能否設定更嚴格的策略？」
網路與出口流量控管
網路存取是沙盒到達非預期目的地的第二大向量。預設開放的出口流量在開發時很方便，但對於執行 AI 生成程式碼的生產應用程式來說是一個糟糕的預設值。
預設拒絕出口：最強的生產姿態是預設封鎖所有出站連線，並明確允許清單化工作階段合法需要的目的地。這需要更多設定，但使存取模型可稽核。
允許清單化目的地：對於編碼 agent 來說，典型的允許目的地可能包括套件註冊表、agent 被建置用來呼叫的一組特定公開 API，以及除此之外的內容。對於資料分析 agent，清單可能包括特定資料來源。請驗證平台是否支援依工作階段或依租戶的目的地允許清單。
DNS 策略：DNS 應與出口策略一致處理。無法到達任意 HTTP 目的地的工作階段，也不應能夠解析任意 DNS 名稱，並利用它來推斷網路拓撲或透過 DNS 通道繞過控管。
內部服務存取：AI 生成程式碼不應能夠到達雲端元資料端點（例如 AWS 執行個體元資料服務）、內部 API、私有資料庫或管理面板，除非這些已明確設定。請驗證沙盒的預設網路策略是否封鎖已知的內部位址範圍。
套件下載的出口流量：套件安裝是網路操作。如果出口受限，請確保套件註冊表允許清單與出口策略一致，或使用信任網路內的拉取代理。
記錄出站連線：即使允許出口，記錄工作階段連線的網域與 IP 對於事件調查很有用。並非所有沙盒平台都原生提供此功能；請驗證您會獲得什麼。
機密與憑證注入
AI agent 經常需要憑證——API 金鑰、資料庫連線、OAuth 權杖、短期雲端憑證。沙盒如何處理機密對安全與營運可靠性都很重要。
狹窄範圍：每個工作階段應僅接收其執行特定任務所需的機密。將包含所有憑證的廣域環境檔案掛載到每個工作階段，在操作上很方便，但這表示任何工作階段中受損或行為不當的程式碼都可以存取所有這些憑證。
短期憑證：在後端支援的情況下，偏好使用具有工作階段持續時間 TTL 的短期權杖。這限制了洩漏憑證有用的時間視窗。
注入機制：請驗證機密是作為環境變數、掛載的檔案還是透過機密 API 注入的。環境變數預設可被工作階段內所有程序存取；掛載的檔案則可設定路徑與權限。對於最敏感的憑證，請考慮使用機密 API，該 API 僅向明確授權的程序提供值。
遮罩：沙盒不應透過標準輸出、標準錯誤、執行日誌、錯誤訊息或模型可見的工具回應來回顯機密。遮罩是應用層的責任，但支援可設定日誌清除功能的沙盒可降低意外暴露的影響範圍。
清理：工作階段結束後，請驗證環境變數、掛載的機密檔案以及任何快取的憑證資料是否作為工作階段拆除的一部分被清除，而不是留給下一個工作階段繼承。
暫存 vs. 持久化檔案儲存
不同的工作負載對持久性的需求不同，生產沙盒應清晰地支援兩種模式。
暫存工作階段：短暫程式碼執行的預設值是建立乾淨的工作目錄、執行程式碼、產生輸出然後銷毀的工作階段。暫存工作階段易於推理：每次執行從已知基準開始，沒有狀態累積，清理也很直接。它們適合評估工作、一次性程式碼補全，以及任何可重現性比連續性更重要的任務。
持久化工作區：長時間執行的編碼 agent、迭代開發工作流程以及多回合 agent 工作階段，通常需要一個能跨多次執行呼叫存續的工作區。一個回合中安裝的檔案、快取的相依性、編寫的程式碼以及累積的歷史，應在下一個回合中可用。持久化工作區操作上更複雜：它們會累積狀態，可能偏離範本，並且需要明確的生命週期——工作區何時清理、誰擁有它，以及在工作階段之間有哪些存取控管保護它？
快照與範本：範本讓您可以定義一個已知良好的基準環境——執行階段、工具、相依性——並從中一致地啟動工作階段。快照則擷取執行中工作階段的當前狀態，並將其用作未來工作階段的起點。兩者對於需要可重複環境與低啟動延遲的團隊都很有用。請驗證範本有版本控制、誰可以建立與更新範本受到控管，且快照依租戶隔離。
輸出產物匯出：執行後，哪些東西可以離開沙盒？生產策略應定義哪些檔案路徑可匯出、適用什麼大小限制，以及產物在應用程式接收前是否經過審查或過濾。
跨工作階段狀態：請明確您的應用設計是否打算讓工作階段共享狀態。意外共享——透過共享套件快取、共享磁碟區或錯誤路由的工作區——是一種常見的多租戶隔離失敗。
後端整合：REST、WebSocket、SDK
沙盒只有在能乾淨整合到應用後端時才有用。三種主要整合模式是 REST、WebSocket 與 SDK。
REST：REST API 是針對提交離散執行請求並輪詢結果的應用程式最輕鬆的整合方式。它適用於短暫任務，使用標準 HTTP 工具容易除錯，且自然融入現有服務架構。缺點是輪詢結果會增加延遲（相比於推送通知），且串流長時間運行的輸出需要 SSE 或輪詢日誌端點。
WebSocket：WebSocket 連線支援應用程式與沙盒之間的雙向、低延遲通訊。對於互動使用案例來說是正確的選擇：編碼助手在程式碼執行時串流輸出、需要即時發送命令與接收回應的瀏覽器 agent，或持續監控執行的評估框架。缺點是操作複雜度：WebSocket 連線需要持久狀態、重新連線處理，以及在客戶端和伺服器端都需要更複雜的基礎架構。
SDK：語言原生的 SDK 隱藏傳輸細節、處理驗證、提供工作階段管理與執行的型別化介面，並通常包含串流輸出、上傳檔案與管理範本的輔助功能。對於大多數應用開發者來說，SDK 是整合最快的方式。請驗證 SDK 是否積極維護、涵蓋完整 API 表面，並以應用程式可操作的結構化方式處理錯誤。
您的應用程式需要擁有的整合點：無論傳輸方式為何，您的應用程式負責授權（哪些使用者可以建立工作階段以及使用哪些資源限制）、批准閘門（哪些工具呼叫或程式碼執行需先經人審查才能執行）、結果處理（沙盒輸出如何被 agent 呈現或處理）以及清理（當使用者流程完成或 agent 回合結束時觸發工作階段拆除）。
一個設計良好的沙盒 API 不會試圖擁有您應用程式的業務邏輯。它公開基本操作——建立、執行、串流、終止、清理——並讓您的應用層在其之上建構正確的產品行為。
故障復原與清理
生產系統會失敗。一個能優雅處理失敗的沙盒可防止資源洩漏、陳舊狀態以及難以除錯的事件。
執行逾時處理：當執行中的執行超過逾時時間時，平台應乾淨地終止程序樹並回傳結構化錯誤回應——而非留下一個消耗資源的殭屍工作階段。請驗證逾時後工作階段會發生什麼事：是自動清理，還是需要明確的清理呼叫？
工作階段崩潰復原：如果沙盒主機崩潰或工作階段 VM 意外退出，平台應偵測到失敗、將工作階段標記為終止，並透過 API 呈現該狀態，以便應用程式可以反應。工作階段不應默默消失而不發出 API 信號。
清理保證：cleanup 或 terminate API 呼叫應可靠地釋放所有資源：CPU 與記憶體分配、檔案系統配額、程序槽、網路狀態與憑證。清理應具有冪等性——對同一個工作階段 ID 多次呼叫不應回傳錯誤。這在實務上很重要：在網路錯誤後重試清理的應用程式程式碼不應出錯。
部分執行失敗：當程式碼在執行中途失敗——未處理的例外、程序被殺死、缺少套件——沙盒應回傳一個結構化結果，區分部分成功（在失敗前已產生一些輸出）與完全失敗。建立在部分結果上的應用程式需要此區分，以避免向使用者呈現不完整或誤導的輸出。
失控程序處理：如果生成的程式碼建立了在主要執行結束後仍存在的背景程序，沙盒應在清理工作階段時將其終止，而不是允許其無限期執行。請驗證平台的清理是否涵蓋完整程序樹，而不僅僅是執行呼叫的直接子程序。
容量與配額錯誤：當平台工作階段容量已滿或某個租戶已達到其配額時，API 應回傳一個應用程式可明確處理的特定錯誤碼——而非通用的 500 或靜默掛起。這允許應用程式進行佇列、退避或向使用者顯示有用的訊息。
Novita Agent Sandbox
Novita Agent Sandbox 是一個專為 agent 工作負載建置的託管沙盒平台。它針對編碼 agent、資料分析 agent、瀏覽器導向的工作流程，以及較長時間的 agent 工作階段，讓生成的程式碼能在隔離、可觀測的環境中執行，而無需落在應用伺服器或共享基礎架構上。
對於已在使用 Novita AI 模型 API 的團隊，Agent Sandbox 可作為更廣泛 agent 架構的一部分：模型規劃並生成程式碼，沙盒透過可程式化生命週期提供隔離執行，而應用層則擁有授權、批准閘門與結果處理。
Novita 已描述的功能包括微虛擬機隔離、並行工作階段支援、涵蓋建立、執行、串流、終止與清理的生命週期 API、用於管理工作階段狀態的暫停與自動恢復、用於快速且可重複環境啟動的範本與快照，以及與 Novita 模型 API 的整合。請在做出架構決策前，先驗證 Novita Agent Sandbox 文件 與產品頁面上的當前功能可用性、資源設定選項與定價。關於特定隔離邊界、並行限制、啟動延遲與網路策略的主張，應根據當前產品文件進行確認。
在根據本指南的需求評估 Novita Agent Sandbox 時，請套用與其他供應商相同的檢查清單：每工作階段的隔離邊界、生命週期 API 完整性、可觀測性表面、可設定的資源限制、套件策略選項、出口流量控管、機密處理、持久化模型與後端整合支援。
常見問題
我應該為 AI 生成程式碼選擇哪種隔離模型？
微虛擬機隔離為不受信任的 AI 生成程式碼提供了最強的邊界，但它增加了操作複雜性。容器隔離對於較低風險的工作負載是足夠的，前提是容器已正確強化——無特權模式、最小能力、可能情況下唯讀的根檔案系統，以及無主機 socket 掛載。程序隔離本身對於可能嘗試系統呼叫、衍生子程序或安裝套件的不受信任程式碼來說，邊界過於薄弱。請根據您的實際威脅模型來選擇隔離層級。
如何在生產沙盒中處理套件安裝？
使用註冊表允許清單，而非預設開放的存取。添加拉取快取以減少冗餘下載並提供檢查點。記錄每次安裝嘗試，包括套件名稱、版本、來源與結果。對於可重現性比彈性更重要的負載——評估執行、自動化管道——請考慮離線模式，其中環境已預先建置，完全禁止安裝。
生命週期 API 至少應公開哪些功能？
建立、執行（含串流輸出）、終止與清理。串流輸出是最常在最小實作中缺少的功能，也是對互動式 agent 使用者體驗最重要的功能。清理必須具有冪等性，且必須涵蓋完整程序樹，而不僅僅是入口程序。
如何防止機密透過沙盒洩露？
將憑證範圍狹窄地限定於任務——而非廣泛的環境檔案。偏好短期權杖。預設不要記錄完整標準輸出，如果機密可能出現在其中。驗證沙盒在清理工作階段時是否清除環境變數與掛載的機密檔案。將遮罩視為應用程式的責任，而非沙盒的保證。
