評估開源 AI 代理沙盒的團隊，應優先檢查真正的隔離邊界、工作區持續性模型、出口流量與套件控制、機密處理方式、可稽核性，以及安全運行所需的營運負擔。正確的選擇較少在於找出萬能解方，而在於將沙盒模型與你的威脅模型、代理工作負載、合規需求及工程能力相匹配。
什麼才算 AI 代理沙盒？
AI 代理沙盒是一種執行環境，代理程式可以在其中執行程式碼、檢查檔案、自動化瀏覽器、呼叫工具或完成任務，而不會取得主機或生產網路的廣泛存取權。它是模型推理與真實世界副作用之間的界線。
這條界線之所以重要，是因為現代的代理程式不只是撰寫文字。一個程式碼代理可能會複製儲存庫、安裝相依套件、執行測試、開啟預覽連接埠，並發起拉取請求。一個瀏覽器或資料代理可能會執行腳本、保留狀態、下載檔案並擷取螢幕截圖。這些動作需要執行階段，而執行階段需要控制。
在評估時，請區分四個層級：
| 層級 | 決策內容 | 為何重要 |
|---|---|---|
| 代理框架 | 模型如何規劃、呼叫工具並對結果做出反應 | 好的框架不會自動產生安全的執行階段 |
| 沙盒執行階段 | 命令、檔案、瀏覽器工作階段和程序在哪裡執行 | 這是主要的隔離和生命週期邊界 |
| 政策層 | 沙盒可以讀取、擷取、安裝、暴露或保留哪些內容 | 決定沙盒是否符合你的風險模型 |
| 審查層 | 運行後有哪些日誌、差異、成品和核准可用 | 決定人類能否驗證發生過什麼事 |
自託管與開源選項能讓團隊對這些層級擁有更多控制權，但也會將更多責任轉移給營運團隊。
何時適合自託管？
當你的團隊需要直接控管部署位置、網路路徑、基礎映像、保留規則、日誌系統或內部安全審查時，自託管是合理的選擇。
若真正的需求只是「讓代理程式安全地執行程式碼」，自託管就較不具吸引力。在這種情況下，受管理的沙盒可能更容易營運，因為供應商會處理佈建、擴展、執行階段更新、正常運行時間以及部分開發者體驗。
當至少符合以下其中一項條件時，採用自託管：
- 你的政策要求執行必須在特定的雲端帳戶、VPC、地區或私有網路內進行。
- 你的代理需要自訂基礎映像、內部套件鏡像、私有原始碼系統或內部瀏覽器目標。
- 你的安全團隊想要檢查隔離堆疊、出口路徑、保留模型和日誌。
- 你有足夠的工程能力來修補執行階段元件、監控濫用訊號、輪替機密以及除錯。
若無法負擔營運工作，預設應避免自託管。沙盒在示範時看起來很簡單，因為單一容器或 VM 就能執行命令。但生產環境截然不同：你需要並發限制、資源配額、映像清理、套件快取策略、網路政策、機密範圍、遙測、事件回應，以及明確的升級路徑。
值得評估的開源沙盒選項
開源生態系統變化快速，請將此視為階段性的方向參考，而非永久的功能矩陣。截至 2026 年 6 月 24 日，下列專案與工具是比較自託管或開源代理沙盒路徑時值得檢視的實例。
| 選項 | 優先檢查項目 | 自託管的問題 |
|---|---|---|
| E2B | 開源沙盒/執行階段元件、SDK、範本，以及基於 Firecracker 的沙盒定位 | 哪些部分是開源的？目前支援哪些部署模式？你的團隊還需要進行哪些營運工作？ |
| Daytona | 針對開發與 AI 代理使用案例的工作區與沙盒基礎設施，附有開源儲存庫及自託管文件路徑 | 其工作區模型、API 表面和部署架構是否符合你的代理工作負載與安全政策？ |
| OpenHands | 代理平台，具有使用沙盒化環境執行代理動作的記錄執行階段架構 | 你是採用整個代理平台，還是僅借用其執行階段模式？ |
| SWE-ReX | 用於軟體工程代理研究與評估工作流程的開源執行階段介面 | 其抽象化層是否符合你的生產需求，或者主要僅適用於受控的評估框架？ |
| Modal Sandbox | 受管理的沙盒 API，而非開源自託管執行階段 | 作為 API 人體工學、程序執行、檔案系統和逾時行為的比較參考點，而非自託管選項 |
不要僅從表格中挑選。針對每個專案，請閱讀當前文件、檢查最新版本說明，並使用你自己的實際工作負載執行一個小型概念驗證。評估應回答：可以執行什麼？什麼被隔離？什麼會持續存在？什麼可以連上網路？什麼可以看見機密？任務完成後留下什麼證據？
隔離邊界：容器、微 VM 與完整 VM
第一個問題不是「安全嗎？」，而是「隔離邊界是什麼？」
容器之所以吸引人，是因為它們速度快、熟悉度高，且容易圍繞 Docker 映像進行建構。它們適用於可信賴的內部工作、類似 CI 的任務、短暫的分析以及威脅模型適中的開發工作流程。但容器共享主機核心，因此處理不受信任程式碼或多租戶工作負載的團隊需要評估核心曝光度、seccomp/AppArmor 設定檔、使用者命名空間、已掛載的磁碟區、特權模式、逃逸回應等問題。
微 VM（如 Firecracker 風格的隔離）能提供更強的 VM 邊界，同時保持啟動速度和密度比傳統 VM 更接近容器工作流程。它們在代理沙盒討論中很常見，因為能為每個工作階段提供獨立核心和更嚴格的資源邊界。但這並不能取代網路政策、機密控制、修補程式或主機強化；它僅釐清了執行階段的隔離層。
完整 VM 可能更適合嚴格的企業環境、桌面自動化，或需要更廣泛作業系統表面的工作流程。其權衡在於啟動較重、映像管理和容量規劃較複雜。
在自託管前，請先確認下列事項：
| 檢查項目 | 需驗證的內容 |
|---|---|
| 核心邊界 | 沙盒是否與其他工作負載共享核心？還是每個工作階段都有獨立核心？ |
| 租戶邊界 | 兩個客戶工作階段是否可能共享主機層級的資源、磁碟區、快取、瀏覽器設定檔或網路命名空間？ |
| 特權模型 | 沙盒是否執行特權容器、root 使用者、已掛載的 Docker socket 或主機路徑？ |
| 逃逸防護 | 核心、執行階段、容器和 Hypervisor 的漏洞如何被修補並推播？ |
| 資源控制 | 每個工作階段的 CPU、記憶體、磁碟、程序數量、開啟檔案數及執行持續時間是否被強制執行？ |
| 側通道 | 你的風險模型是否需要針對共享 CPU、快取、磁碟或嘈雜鄰居行為進行緩解？ |
如果某個專案描述自己「已隔離」，請繼續閱讀直到你了解其運作機制。
狀態、檔案與工作區生命週期
即使沙盒是短暫的，代理的工作仍具有狀態。代理可能會建立檔案、安裝套件、保留瀏覽器設定檔、執行背景程序，或在人類審查成品時暫停。你的沙盒需要一個清晰的工作區模型。
從生命週期開始：
- 從基礎映像或範本建立沙盒。
- 掛載或複製允許的工作區。
- 在政策下執行設定命令。
- 讓代理執行命令、瀏覽器動作和檔案操作。
- 提取輸出：差異、日誌、螢幕截圖、報告或下載的檔案。
- 停止、暫停、快照、封存或銷毀沙盒。
關鍵在於持續性應該是刻意的。持久工作區對於長時間運行的代理、多步驟的程式碼任務以及人機協同審查很有用。但如果清理不確實，它們也容易讓過時的憑證、快取的相依套件、瀏覽器 cookies、產生的資料和部分工作內容跨工作階段洩漏。
在自託管前，請定義：
- 每個代理任務是否都獲得全新的檔案系統。
- 套件快取是共享、限定範圍，還是重建。
- 瀏覽器設定檔是否在運行之間持續存在。
- 使用者上傳的檔案是複製、掛載還是串流處理。
- 快照是否包含機密、Token、cookies 或內部日誌。
- 日誌和成品保留多久。
- 誰可以重新開啟一個已暫停的工作階段。
一個好的沙盒會讓預設的生命週期變得無趣。你應該能夠解釋任務開始前存在什麼、任務期間改變了什麼，以及清理之後留下了什麼。
網路、套件與出口政策
網路存取是許多沙盒設計變得模糊的地方。代理通常需要網際網路，但「網際網路存取」並非單一權限。
一個程式碼代理可能需要套件註冊表、公開文件、Git 遠端儲存庫和預覽 URL。一個瀏覽器代理可能需要測試應用程式、一個 staging API 以及螢幕截圖儲存空間。一個資料代理可能需要物件儲存、資料庫副本或受限的 SaaS API。這些是不同的權限，具有不同的風險。
使用分類：
| 出口類型 | 常見需求 | 政策問題 |
|---|---|---|
| 套件註冊表 | npm, pip, apt, cargo、模型/工具相依套件 |
註冊表是否已列入白名單、快取、掃描並記錄？ |
| 公開網站 | 文件查詢、瀏覽器任務、公開資料收集 | 是否允許任意瀏覽？是否被代理、限制速率並可稽核？ |
| Git 存取 | 複製儲存庫、推送分支、擷取子模組 | 可能的 Token 是否設為唯讀，並限定在任務範圍內？ |
| 內部 API | Staging 服務、測試應用程式、私有套件鏡像 | 存取是否按環境、服務、路由和憑證進行限制？ |
| 預覽入口 (ingress) | 人類審查本地 Web 應用程式或產生的報告 | 哪個連接埠被暴露？暴露給誰？持續多久？使用什麼認證？ |
| Webhook | 代理回呼、CI 事件、外部工具整合 | 沙盒能否將出站回呼傳送到任意主機？ |
套件政策值得特別關注。許多代理任務若不安裝相依套件就會失敗，但安裝套件會帶來安裝後腳本、原生二進位檔、註冊表遭入侵、域名搶註風險以及長期的快取生命週期。建議優先使用基於鎖定檔案的安裝、經過核准的註冊表、短期 Token 以及安裝日誌。
對於自託管系統，也要決定誰負責 DNS 日誌、代理設定、憑證信任儲存庫以及網路事件回應。
機密、日誌與稽核軌跡
代理沙盒不應成為一個讓模型可以輕易列印、複製或外洩原始憑證的地方。
最安全的模式是任務範圍內的存取。給予沙盒完成工作所需的最低憑證，並在工作結束時移除。一個程式碼任務可能需要一個唯讀的儲存庫 Token 和一個拉取請求 Token。一個瀏覽器任務可能需要一個測試帳號，而不是生產使用者。一個資料任務可能需要一個臨時簽署的 URL，而不是永久的雲端憑證。
避免將機密放在代理可以隨意讀取的檔案中。環境變數很方便，但許多除錯命令會顯示環境狀態。如果平台支援代理動作 (brokered actions)，請使用它們：讓沙盒執行狹義的操作，而不將原始憑證暴露給模型循環。
日誌應該足夠強健，以便進行審查和事件回應：
- 已請求、已核准、已拒絕和已執行的命令。
- 工作目錄、退出碼、標準輸出、標準錯誤、逾時和資源使用情況。
- 任務產生的檔案成品。
- 符合政策粒度要求的網路目標。
- 套件名稱、版本、註冊表和安裝輸出。
- 機密編輯的決策和編輯失敗。
- 針對高風險動作的人類核准。
目標不是讓審查者淹沒在日誌中，而是能夠在代理產生意外輸出、相依套件變更或 Token 疑似暴露時，重建發生過的事件。
重設、快照與多租戶風險
重設行為是生產功能，不是示範結尾的清理腳本。
短暫沙盒更容易推理：建立、執行、提取成品、銷毀。它們適用於短程式碼執行、一次性瀏覽器動作和評估任務。持久沙盒有助於較長的工作流程，但它們需要所有權、到期日和審查控制。
快照和範本介於這些模型之間。它們可以透過保留預先準備好的環境來加速啟動，但也會保留快照內的所有內容。檢查它們是否包含：
- 已安裝的套件和快取。
- Shell 歷史記錄或程序狀態。
- 瀏覽器 cookies、本地儲存和下載的檔案。
- 暫存檔案和產生的輸出。
- 憑證或設定檔。
- 先前任務的日誌。
對於多租戶系統，請詢問排程器如何放置工作負載、快取是否共享、磁碟如何清理，以及主機層級資源如何監控。也詢問故障發生時會發生什麼事。一個崩潰、超時或失去控制器的沙盒仍然需要清理和成品處理。
開發者存取與除錯路徑
自託管的沙盒需要實際的除錯方案。當代理失敗時，開發者需要知道問題是在模型、工具呼叫、執行階段、映像、套件鏡像、網路路徑，還是目標應用程式。
有用的除錯路徑包括：
- 一種從相同基礎映像重播命令的方法。
- 命令執行和工具呼叫的結構化日誌。
- 可下載的成品和螢幕截圖。
- 明確的逾時和資源限制錯誤。
- 一種在政策允許時，開發者可以可控地連接到即時工作階段的方法。
- 版本化的範本或映像，以便將失敗與特定環境版本關聯起來。
- 使用者可見輸出與內部執行階段日誌之間清晰的區隔。
對緊急存取要謹慎。對即時沙盒提供廣泛的 Shell 存取，可能會違反沙盒原本要執行的隔離假設。定義誰可以附加、他們可以看到什麼、機密是否被編輯，以及存取如何被記錄。
Novita Agent Sandbox 的定位
Novita Agent Sandbox 是一個受管理的代理執行階段，適用於程式碼執行、瀏覽器自動化、類似電腦使用的流程、資料分析、評估以及長時間運行的代理工作流程。Novita Agent Sandbox 文件 描述了一個有狀態的沙盒環境，並提供 SDK 與 CLI 路徑來處理生命週期、命令、檔案、瀏覽器工作階段及相關工作流程基礎元素。
這使得 Novita 適合在你團隊希望獲得代理執行基礎設施，但又不想從第一天就承擔完整的自託管營運負擔時進行評估。
請保持界線清晰：
- 當部署控制、原始碼層級客製化或內部基礎設施擁有權是優先事項時，使用開源或自託管的執行階段。
- 當更快的採用速度、供應商管理的執行階段營運，以及以 API 為先的工作流程比擁有每一層更重要時，使用受管理的沙盒。
- 無論哪種情況，都應根據你自己的政策來評估隔離、出口、套件安裝、機密、日誌、持久性和審查關卡。
不要將任何供應商名稱視為安全保證，而應將其視為仍需要架構審查的執行階段選擇。
自託管檢查清單
在將開源 AI 代理沙盒移至生產環境前，請使用此檢查清單。
| 領域 | 投入生產前的最低問題 |
|---|---|
| 隔離 | 邊界是容器、微 VM、完整 VM 還是其他？對於此工作負載來說足夠嗎？ |
| 工作區 | 每個任務是否從已知的檔案系統狀態開始？是否可以重設？ |
| 持續性 | 暫停、恢復、快照和保留是否有明確的設計，而不是偶然的？ |
| 網路 | 套件擷取、瀏覽、API 呼叫、Git、Webhook 和預覽入口是否分別受到控制？ |
| 套件 | 鎖定檔案、註冊表、安裝後腳本、原生二進位檔和快取是否受到管理？ |
| 機密 | 憑證是否為任務範圍限定、經過編輯、輪替，且無法被不相關的命令取得？ |
| 日誌 | 審查者能否重建命令、輸出、檔案變更、網路路徑和核准？ |
| 多租戶 | 是否理解主機共享、快取共享、磁碟清理、配額和嘈雜鄰居行為？ |
| 除錯 | 工程師能否在不繞過安全模型的情況下重現故障？ |
| 營運 | 誰負責修補映像、執行階段、核心、相依套件和沙盒控制器？ |
| 濫用控制 | 是否強制執行了逾時、資源限制、速率限制和終止路徑？ |
| 退出路徑 | 即使沙盒崩潰或超時，成品是否可以匯出和審查？ |
如果有幾個答案不清楚，請將該專案保留在原型階段。一個無法解釋其邊界的沙盒，還不適合大規模執行不受信任的代理任務。
常見問題
哪個是最好用的開源 AI 代理沙盒？
對於每個團隊來說，並不存在單一最好的開源 AI 代理沙盒。正確的選擇取決於你的隔離需求、部署模型、代理工作負載、出口政策、持續性需求和營運能力。透過在每個候選執行階段中執行你自己的任務來比較選項。
Docker 足夠用來做 AI 代理沙盒嗎？
對於可信賴的內部自動化、本地開發和類似 CI 的工作，Docker 可能足夠，但對於不受信任的程式碼或嚴格的多租戶工作負載，可能就不夠。在僅依賴容器之前，請檢查核心共享、權限、已掛載的磁碟區、網路存取、機密和逃逸回應。
對於代理工作負載，微 VM 比容器更安全嗎？
微 VM 可以提供更強的隔離邊界，因為每個沙盒可以使用獨立的核心來運行。但這並不能自動解決出口、套件、機密、日誌、修補程式或多租戶營運等問題。請將微 VM 視為架構的一部分，而非整個安全模型。
在自託管代理沙盒之前，我應該測試什麼？
測試一個實際的工作負載，該工作負載會複製或掛載檔案、安裝相依套件、執行命令、處理機密、連線到核准的網路目標、產生成品、超時並重設。也要測試失敗路徑：套件安裝失敗、瀏覽器崩潰、網路拒絕、資源限制，以及控制器錯誤後的沙盒清理。
何時應該使用受管理的沙盒而不是自託管？
當你的團隊希望獲得代理執行 API 和審查成品，而不需要承擔執行階段修補、擴展、容量規劃和基礎設施營運時，請使用受管理的沙盒。而當部署控制或原始碼層級客製化的重要性足以值得投入該工作時，請選擇自託管。
