這份 AI Agent 沙箱常見問題回答了開發者在執行 Agent 生成的程式碼之前會提出的實際安全問題：隔離是如何運作的、Agent 擁有什麼樣的網路存取權限、檔案和 Session 狀態存放在哪裡，以及如何處理機密資料、稽核日誌、合規性和成本。如果你還不熟悉沙箱，請先閱讀什麼是 AI Agent 沙箱？ 以了解隔離模型、網路出口和快照的基礎知識。如果你正在選擇供應商，請參閱2026 年最佳 AI Agent 沙箱 或 E2B 與 Daytona 評估指南。
為什麼要為 AI Agent 使用沙箱
為什麼團隊要為 AI Agent 使用專用沙箱？
AI Agent 與傳統軟體在一個關鍵方面有所不同：它們執行的程式碼並非由人類編寫並在執行前經過審查。LLM 會動態生成指令、選擇工具、安裝套件並進行 API 呼叫——這些方式往往是應用程式開發者事先無法預先列舉的。沙箱提供了一個運行時強制執行層，可以限制這些行為的後果，而無需預先批准所有可能的操作。沒有沙箱，行為不當或被操縱的 Agent 可能會影響主機系統、相鄰的工作負載或外部基礎設施。有了沙箱，最壞情況的影響範圍被限制在隔離環境內，並且可以在 Session 結束後將其丟棄。
什麼是 AI Agent 程式碼執行？
AI Agent 程式碼執行是 LLM 的決策轉變為電腦實際執行的指令的運行時階段。Agent 接收任務，進行推理，生成程式碼或工具呼叫，然後執行層運行這些動作並將結果返回給 Agent。沙箱是此執行階段的標準基礎設施層：它提供 Agent 所需的運算、檔案系統和網路環境，同時將該環境與其他一切隔離。「模型推理 → 執行層運行 → 結果回饋給模型」的循環會持續，直到 Agent 完成任務。
沙箱與僅在容器中執行 Agent 有何不同？
容器增加了檔案系統和網路命名空間隔離，但同一主機上的所有容器共享同一個作業系統核心。對於執行來自不受信任輸入的 LLM 生成程式碼的 AI Agent 來說，透過共用漏洞進行核心級逃逸可能會影響相鄰的工作負載。專用的 AI Agent 沙箱通常會增加一個 microVM 邊界：Agent 的程式碼在一個輕量級虛擬機器中執行，該虛擬機器擁有自己的 Guest 核心，因此即使在 Guest 中發生核心級漏洞利用，也不會影響主機。實際的權衡是冷啟動時間會稍微增加（對於基於 Firecracker 的平台，通常低於 500 毫秒）。請參閱沙箱隔離模型部分以獲得完整比較。
沙箱隔離模型
在 AI Agent 沙箱中，「隔離」是什麼意思？
隔離意味著 Agent 的程式碼、檔案、程序和網路存取權限都被限制在一個有邊界的環境中，該環境無法影響主機系統或其他租戶。實際上，隔離是一個光譜：程序層級隔離使用作業系統原語（命名空間、cgroups、seccomp）來限制系統呼叫和資源存取；容器隔離增加了檔案系統和網路命名空間邊界；而 microVM 隔離則將工作負載包裝在一個具有自己 Guest 核心的輕量級虛擬機器中。每向上一個層級，邊界強度都會增加，但代價是啟動時間和操作複雜性會有所增加。有關所有隔離維度的全面概述，請參閱什麼是 AI Agent 沙箱？。請參閱用於 AI Agent 沙箱的 Firecracker 以獲得詳細的評估框架。
執行 Agent 生成的程式碼，使用 Docker 就足夠了嗎？
容器提供了可重複的映像檔和良好的資源控制，但同一主機上的所有容器共享主機核心。核心漏洞或通過 seccomp 過濾器的系統呼叫可能會影響其他工作負載。對於執行可信或接近可信程式碼的低風險、短期任務，如果在正確強化後——無特權模式、最小權限、不安裝 Docker socket、盡可能使用唯讀根檔案系統——容器通常是足夠的。對於可能安裝套件、產生子程序或呼叫任意 shell 命令的不可信 AI 生成程式碼，值得評估更強的邊界。答案取決於你的實際威脅模型。請參閱AI 生成程式碼沙箱：生產應用的要求 以獲取每個隔離層級的驗證檢查清單。
容器隔離和 microVM 隔離之間有什麼區別？
關鍵區別在於核心邊界。容器共享主機核心；microVM 則在輕量級虛擬機器中各自執行一個 Guest 核心，並由硬體虛擬化（KVM）支援。使用 Firecracker 等技術的基於 microVM 的沙箱提供了 VM 風格的邊界，而沒有傳統 VM 的全部開銷：啟動延遲設計得很快，裝置模型極簡以減少攻擊面，且 Guest 與主機核心在設計上是隔離的。實際意義在於，Guest 中的核心漏洞利用不會自動影響主機或其他 Guest，而在共享核心的容器模型中則可能發生。請參閱用於 AI Agent 沙箱的 Firecracker 以了解 microVM 邊界在哪些方面有幫助，以及在哪些方面無法解決整個問題。
一個沙箱是按 Agent、按使用者還是按任務來分配的？
這取決於平台以及應用程式的設計方式。對於多租戶應用程式，最安全的模式是每個 Agent 運行或每個任務都有一個獨立的隔離沙箱環境——這意味著每個使用者的 Session 都有自己的程序樹、檔案系統、網路命名空間和憑證範圍。跨使用者或跨不相關任務共用沙箱是生產 Agent 應用程式中狀態洩漏最常見的來源。在評估平台時，請驗證並發 Session 是否在檔案系統、程序和網路層級得到隔離，而不僅僅是在 API 路由層級。請參閱AI 生成程式碼沙箱：生產應用的要求 以獲取每個 Session 隔離檢查清單。
沙箱網路出口與網路策略
AI Agent 可以從沙箱發出對外網路呼叫嗎？
這取決於沙箱的網路出口策略。預設情況下，許多沙箱允許對外連線，這對於網路研究、API 呼叫和套件安裝很方便。對於執行不可信程式碼的生產工作負載，預設開放的網路出口是一個風險：被入侵或行為不當的 Agent 可以外洩資料、存取內部中繼服務，或從任意 URL 拉取未預期的程式碼。更強的生產姿態是預設拒絕網路出口，並明確允許清單列出允許的目標。無論你選擇何種策略，都應該明確記錄並記錄下來。請參閱用於 AI Agent 沙箱的 Firecracker 以了解如何評估網路控制。
沙箱中的 DNS 是如何控制的？
DNS 是網路出口策略中的一個常見漏洞：允許 HTTP 目標的清單並不會自動限制 DNS 解析。能夠解析任意網域名稱的 Agent 可以推斷網路拓撲、探測內部名稱，甚至在 HTTP 被封鎖的情況下使用 DNS 作為側通道。為了實現一致的網路出口策略，DNS 解析應該一致地處理——要么指向一個遵守允許清單的內部解析器，要么將解析限制在批准的網域。請向你的沙箱供應商確認 DNS 在更廣泛的網路出口策略中是如何被限定範圍的。
在網路受限的 Session 中，如何控制套件獲取？
套件安裝是網路操作。如果網路出口被限制在允許清單內，則允許清單必須包含 Agent 合法需要的套件註冊表，或者沙箱應在信任的網路內提供一個拉取快取。拉取快取還有一個額外的好處，即作為一個檢查點：你可以查看哪些套件被獲取，捕捉意外的依賴項，並減少重複的網路出口。對於那些可重複性比靈活性更重要的工作負載，一些團隊會使用預先準備好的沙箱模板，這完全消除了運行時套件獲取。請參閱套件安裝部分以了解有關管理運行時安裝的更多資訊。
檔案存取與主機檔案系統
沙箱化 Agent 擁有什麼樣的檔案存取權限？
沙箱化的 Agent 應僅能存取明確掛載到其工作區的檔案。對於一個程式碼 Agent，這可能是一個檢出的儲存庫和一個用於生成工件的工作目錄。對於一個資料分析 Agent，這可能是一個上傳的 CSV 檔案和一個輸出資料夾。Agent 不應能夠存取主機檔案系統、其他租戶的工作區、應用程式伺服器的機密資訊，或其掛載路徑之外的系統目錄。最佳實踐是將來源資料以唯讀方式掛載，並提供一個單獨的讀寫輸出目錄用於生成的工件。請參閱MCP 伺服器沙箱：具有檔案系統、機密和網路控制的隔離 MCP 伺服器 以了解如何為每個工具設定檔案系統掛載範圍。
可以從沙箱內部存取主機檔案系統嗎？
不應該。一個正確配置的沙箱——無論是容器還是 microVM——都會將 Agent 的視圖限制在其自己的 Guest 檔案系統內。從沙箱內部存取主機檔案系統是一種配置失敗，而不是預期行為。破壞此邊界的常見錯誤包括掛載寬泛的目錄（例如開發者的主目錄或 /）、在容器中使用特權模式，或將 Docker socket 掛載到沙箱中。在評估平台或自行建置時，請驗證掛載了什麼、根檔案系統的權限是什麼，以及符號連結逃逸或歸檔提取技巧是否可以到達預期工作區之外的路徑。
Session 結束後，檔案會如何處理？
對於短暫的 Session，工作目錄和所有生成的檔案會在 Session 終止時被銷毀。這是程式碼完成、評估運行以及任何可重複性比連續性更重要的任務的正確預設值。對於持久化工作區（長時間運行的程式碼 Agent、迭代開發 Session），檔案可以在一個 Session 內的多次執行呼叫中存活，並且如果平台支援工作區持久化或快照，則可能在 Session 結束後保留。需要回答的關鍵問題是：誰擁有保留的工作區、何時清理它、以及一個使用者的工作區是否會洩漏給另一個使用者？請參閱AI 生成程式碼沙箱：生產應用的要求 以獲取持久化模型檢查清單。
Session 狀態與持久化
沙箱 Session 是有狀態的還是短暫的？
這兩種模式都存在，並服務於不同的工作負載。短暫 Session 每次任務都從一個乾淨的基準線開始——沒有累積的套件、檔案或歷史記錄。它們更容易推理，並且非常適合評估運行或一次性程式碼執行。有狀態 Session 會跨多次執行呼叫保留檔案、已安裝的套件、Shell 歷史記錄和環境狀態，這對於多步驟程式碼 Agent、互動式資料分析和長時間運行的工作流程是必要的。大多數生產平台都支援這兩種模式。權衡在於，有狀態 Session 需要明確的清理策略和更仔細的租戶隔離。
在託管沙箱中，狀態會持續多久？
Session 持續時間因平台和方案而異。一些供應商設定了一個預設的 Session 超時時間（通常為 60 分鐘到 24 小時），之後 Session 將被終止，並且除非持久化到快照或外部儲存，否則狀態將丟失。長時間運行的 Agent 工作流程——可能在 LLM 呼叫之間暫停數分鐘或數小時的 Session——需要一個支援 Session 暫停和恢復或自動暫停的平台，以避免在空閒時間產生費用，同時保留狀態。請驗證最大 Session 長度，以及在發生超時時對正在進行中的狀態會發生什麼。Novita Agent Sandbox 支援長達 24 小時的 Session，並記錄了用於管理空閒時間的暫停/自動恢復功能。請參閱Novita Sandbox：E2B Pro 的經濟高效替代方案，具有無縫相容性 以進行功能比較。
Session 可以暫停和恢復嗎？
一些平台支援暫停和恢復，其中 Session 被掛起到磁碟，並且可以在稍後從相同狀態重新啟動。這對於在步驟之間等待 LLM 回應的 Agent、對於限制昂貴工作負載的速率，以及對於跨時間跨越多個使用者互動的 Session 非常有用。需要驗證的關鍵事項是：暫停的 Session 可以保持掛起狀態多長時間、暫停期間持有的網路連線會發生什麼，以及在 Session 啟動時注入的憑證在恢復後是否仍然有效，或者是否需要刷新。
沙箱狀態可以被快照並重複使用嗎？
模板和快照是相關但不同的。模板是預先建置的基準環境——運行時、工具、已批准的套件——新的 Session 從中啟動。快照捕獲正在運行的 Session 的當前狀態，並將其用作未來 Session 的起點。模板減少了每個 Session 的啟動開銷，並確保所有 Agent 從一致、受控的基準線開始。快照對於保留部分工作或熱啟動迭代作業很有用。兩者都需要治理：誰可以建立它們、誰可以讀取它們、它們屬於哪個租戶，以及它們如何進行版本控制。
套件安裝與運行時依賴項
Agent 可以在運行時安裝套件嗎？
大多數沙箱環境預設允許運行時套件安裝（pip install、npm install、apt-get 等），因為許多 Agent 工作負載需要它們。問題不在於是否允許安裝，而在於每次安裝是否都受到管理。不受管理的套件安裝是沙箱中風險最高的操作之一：它們在運行時將外部程式碼拉入執行環境，可能包含執行任意命令的安裝後腳本，並且可能引入供應鏈風險。
有哪些策略管理運行時套件安裝？
生產環境的套件策略通常包含以下組合：註冊表允許清單（僅從批准的套件註冊表或鏡像獲取）、拉取快取（在進入執行環境之前檢查內容）、安裝日誌記錄（記錄每次安裝的套件名稱、版本、來源和結果），以及可選的離線模式（將依賴項預先打包到模板中，並在可重複性至關重要的評估管線中禁止運行時安裝）。正確的策略取決於工作負載：幫助開發者除錯程式碼的程式碼 Agent 可能需要靈活的套件存取；自動化評估管線則應從凍結的環境運行。請參閱使用沙箱化 Python 和受控套件存取建置 AI 資料分析師 以獲得一個實際的實作範例。
機密資料與憑證處理
沙箱中的機密資料和憑證是如何處理的？
機密資料應該被窄範圍地注入——僅注入特定任務所需的憑證，且僅在該 Session 的持續時間內有效。常見的反模式是將包含所有 API 金鑰的寬泛環境檔案掛載到每個 Session 中；這意味著任何 Session 如果被入侵，都可以存取該檔案中的所有憑證。優先使用範圍限定於該任務的短期 Token，並優先使用注入機制（環境變數或掛載的檔案），而不是硬編碼。對於最敏感的憑證，提供僅對明確授權的程序提供值的運行時機密 API，比對所有程序都可用的普通環境變數提供了更強的隔離。
模型可以看到注入到沙箱中的環境變數嗎？
可以，如果環境變數被注入到模型程式碼所執行的程序中。預設情況下，環境變數對同一 Session 中的所有程序是可見的。模型無法直接從其上下文視窗讀取它們，但在沙箱內部執行的生成程式碼可以使用 os.environ、process.env 或等效方式讀取它們。這就是為什麼窄範圍很重要的原因：僅注入任務所需的憑證，並優先使用短期 Token，以便洩漏的憑證具有有限的可用時間視窗。編輯是應用程式的責任：如果機密資料可能出現在錯誤訊息或列印語句中，請不要預設記錄完整的標準輸出。
Session 結束後，機密資料會如何處理？
環境變數和掛載的機密檔案應作為 Session 拆除的一部分進行清理。如果平台跨 Session 保留狀態（快照、持久化磁碟區），請驗證寫入檔案系統或由憑證提供者快取的憑證也已清理或輪換。可恢復快照中的過期憑證是一種風險——在 Session 拆除後，快照不應保留僅在原始 Session 持續時間內有效的 Token。
稽核日誌與可觀察性
沙箱中記錄了哪些事件？
有用的沙箱稽核記錄包括 Session 建立和拆除（Session ID、租戶、模板版本、資源分配、持續時間）、執行事件（運行了什麼程式碼或命令類別、開始/結束時間、退出狀態）、套件安裝（名稱、版本、來源、結果）、對外網路聯絡（網域、IP、連接埠）、從特定路徑讀取或寫入的檔案，以及清理結果。目標是讓 Agent 的行為在事後可重構，而不會將稽核日誌變成第二個機密儲存庫。原始客戶檔案、完整命令輸出和完整提示通常不屬於稽核日誌，除非你的保留和存取控制是專門為此類資料設計的。
誰可以存取稽核日誌？
稽核日誌的存取控制應限定於操作員，以及相關情況下的租戶。在多租戶平台中，一個租戶的稽核記錄不應對其他租戶可見。對於合規性敏感的部署，稽核軌跡需要是防篡改的、按要求期限保留，並可供授權的審查者（安全團隊、合規官）按需存取。請向你的沙箱供應商詢問：預設提供什麼樣的日誌保留期限、日誌是否可以匯出到你自己的 SIEM 或儲存系統，以及有哪些存取控制措施保護日誌資料。
合規性與安全審查
在生產環境中使用沙箱之前，需要進行哪些合規審查？
具體要求取決於你的行業和管轄區域，但任何生產 Agent 系統的標準問題包括：哪些資料進入沙箱（以及這些資料是否受 GDPR、HIPAA、SOC 2 或其他框架的約束）、沙箱託管在哪裡以及是否滿足資料駐留要求、隔離模型是什麼以及是否可以將其記錄給審計員、憑證如何管理和輪換，以及稽核軌跡是什麼樣的。大多數安全審查還會詢問生成的程式碼是否可能觸及預期範圍之外的生產資料庫、內部管理介面或客戶資料。這些是架構控制，而不僅僅是供應商認證。
安全團隊在評估 AI Agent 沙箱時應提出哪些問題？
安全審查的實用評估檢查清單：
- 隔離： 邊界是什麼——程序、容器還是 microVM？每個 Agent Session 是否在檔案系統、程序和網路層級都得到隔離？
- 網路出口： 預設的網路出口策略是什麼？外部目標是否可以加入允許清單？DNS 如何控制？
- 機密資料： 憑證如何注入？它們是否限定於任務範圍？它們在 Session 拆除時是否會被清理？
- 稽核： 記錄了哪些事件？誰可以存取日誌？保留期限是多少？
- 資料駐留： 沙箱託管在哪裡？部署是否可以限定在特定的雲端區域或帳戶？
- 合規性態勢： 供應商是否持有相關認證（SOC 2、ISO 27001）？他們的共同責任模型是什麼？
- 網路可達性： 沙箱是否可以存取內部中繼服務、私有 API 或其他租戶的資源？如何防止橫向移動？
將這些視為需要評估的問題，而不是任何單一供應商自動滿足的要求。供應商文件中的安全性和合規性聲明應根據當前產品文件進行驗證，而不是僅憑表面價值接受。對於有監管或合約要求的團隊，請讓你的安全團隊在生產部署之前完成審查，而不是之後。
何時適用 BYOC（自帶雲端）或 VPC 部署？
資料駐留要求、網路安全策略或禁止資料離開特定雲端帳戶的監管限制，是團隊選擇 BYOC 或 VPC 部署而非共用託管服務的主要原因。在你的 AWS 或 GCP VPC 內執行沙箱意味著執行環境在你的網路邊界內、你的雲端帳戶的存取控制適用，並且沙箱的網路出口可以由你現有的網路策略來管理。權衡是運營責任：你負責基礎設施管理、修補和擴展。Novita Agent Sandbox 將 BYOC 部署到 AWS 或 GCP 帳戶作為一項功能記錄在案，適用於有這些需求的團隊。請在 Novita Agent Sandbox 文件中驗證當前的可用性和配置選項。
沙箱定價與成本驅動因素
什麼因素驅動沙箱成本？
沙箱成本通常是以下因素的組合：運算時間（vCPU 和記憶體按每秒或每分鐘計費）、Session 開銷（某些平台每次 Session 的啟動費用）、超過包含免費層的持久化儲存，以及對外資料傳輸（網路出口）。每個因素的相對權重取決於你的工作負載：短 Session 的程式碼直譯器主要是運算成本；下載大型檔案的瀏覽器自動化 Agent 可能會產生大量網路出口費用；持久化程式碼工作區會累積儲存成本。空閒時間處理是一個主要的差異化因素——具有自動暫停功能的平台會在沙箱等待 LLM 回應時停止計費，這可以顯著降低互動式工作流程的成本。請參閱AI Agent 沙箱定價模型：按 Session、運算、儲存和網路出口 以獲得每個定價軸的詳細分解。
Session 時間、運算和網路出口在成本方面如何相互作用？
對於大多數工作負載，運算時間占主導地位。一個 10 分鐘的程式設計 Session（使用 1 個 vCPU）的成本高於典型費率下 1 GB 的網路出口。但對於特定工作負載，它們的相互作用很重要：下載大型訓練資料集的資料 Agent 會產生遠高於運算成本的網路出口費用。在 LLM 輪次之間保持 Session 開啟的瀏覽器 Agent 如果未啟用自動暫停，將會累積空閒運算時間。實際的方法是在承諾使用某個平台之前，根據你的實際工作負載概況來估算每個維度。Novita Agent Sandbox 根據實際的 vCPU 和記憶體使用量按每秒計費，沒有每次 Session 的啟動費用；截至 2026 年中，1 個 vCPU 的價格為 $0.0000098/s。（來源：Novita AI 定價頁面，已在已發布的文件中驗證。在進行預算規劃之前，請務必驗證當前費率。）
自託管 vs. 託管 AI Agent 沙箱
團隊何時應選擇自託管而非託管沙箱？
自託管（運行你自己的沙箱基礎設施，通常基於 Firecracker 或類似的 microVM 層）在以下情況下有意義：資料駐留或網路策略要求禁止使用第三方託管服務、工作負載量足夠高以致於託管服務成本超過運行你自己基礎設施的運營成本，或者團隊擁有現有的平台工程能力並希望完全控制隔離模型、映像治理和網路策略。自託管比看起來更困難：管理核心、根檔案系統、映像、快照、速率限制器、指標、清理和多租戶隔離是實際的工作。請參閱用於 AI Agent 沙箱的 Firecracker 以了解運營範圍的實際情況。
何時使用託管沙箱更合理？
對於大多數建置程式碼 Agent、資料分析工具、瀏覽器自動化工作流程或評估管線的團隊來說，託管沙箱是通往生產環境的更快路徑。平台負責基礎設施配置、安全強化、映像更新、擴展和生命週期管理。團隊專注於 Agent 架構，而不是沙箱內部細節。成本比較不僅僅是雲端運算費率：還要考慮建置和維護隔離層的工程時間、記錄它的合規工作，以及發生意外情況時的應變處理。對於沒有專用平台工程能力的團隊，託管服務通常能更快地達到生產環境，並維持較低的總體擁有成本。請參閱AI Agent 沙箱定價模型 以獲得一個比較託管與自託管總成本的框架。
團隊在評估託管沙箱供應商時應提出哪些問題？
除了標題定價之外的實用評估問題：
- 每個 Session 的隔離模型是什麼（microVM、容器、程序）？
- 預設和可配置的網路出口策略是什麼？
- 有哪些套件安裝治理選項？
- 機密資料如何注入和清理？
- 有哪些稽核日誌資料可用，以及如何存取？
- 在你所需層級，Session 長度和並發限制是多少？
- 供應商是否支援 BYOC 或 VPC 部署？
- 暫停/恢復行為是什麼，以及它如何影響計費？
- 啟動延遲在規模化下表現如何（熱池、快照、冷啟動）？
安全地執行不受信任的程式碼
我如何在生產環境中安全地執行 AI 生成的程式碼？
底線是：不要在你的主機上執行 LLM 生成的程式碼。將所有執行通過一個提供檔案系統、程序和網路隔離的沙箱進行路由。除此之外，五個實踐會產生顯著的差異：(1) 明確設定網路出口策略——預設拒絕搭配允許清單比預設開放更安全；(2) 窄範圍地設定機密資料——僅注入當前任務所需的憑證；(3) 管理套件安裝——允許從批准的註冊表安裝，或對可重複的工作負載使用預先建置的映像；(4) 在核心或 Hypervisor 層級進行日誌記錄，而不是信任應用程式層級的日誌；(5) 設定資源限制——CPU、記憶體、磁碟和掛鐘超時——以便失控的 Agent 無法影響相鄰的 Session。請參閱AI 沙箱執行程式碼的安全性如何？ 以獲得完整的評估檢查清單。
有開源的 AI Agent 沙箱嗎？
有的。Daytona 在 AGPL 許可證下是開源的，並支援自託管部署。E2B 的核心 SDK 是開源的，但託管運行時基礎設施則不是。如果你想從頭開始建置自己的沙箱，最常見的方法是使用 Firecracker（AWS 開發，Apache 2.0 許可）作為 microVM 運行時，並結合你自己的映像管理、編排和生命週期控制。自託管意味著要承擔託管服務抽象掉的運營範圍：核心管理、根檔案系統治理、速率限制、快照儲存、清理策略和多租戶隔離。請參閱用於 AI Agent 沙箱的 Firecracker 以了解該範圍在實踐中的情況。
什麼是託管 AI 沙箱平台？
託管 AI 沙箱平台是一種雲端服務，它將沙箱基礎設施作為 API 提供：你呼叫 SDK，一個沙箱被配置並以就緒狀態返回，而平台處理底層的運算、網路、映像管理和生命週期。Novita Agent Sandbox、E2B 和 Daytona 的託管模式是例子。替代方案是自託管，即你自己配置和運營沙箱基礎設施。對於任何託管平台，關鍵問題是：它使用什麼隔離模型、可以配置什麼網路出口策略、是否提供 BYOC 或 VPC 部署，以及針對你預期的工作負載，每秒定價是多少。請參閱2026 年最佳 AI Agent 沙箱 以獲得結構化的比較。
什麼是適合企業使用的 AI Agent 沙箱？
企業 AI Agent 沙箱的要求通常超出了以開發者為中心的託管服務預設提供的範圍。常見要求包括：BYOC 或 VPC 部署（沙箱在你的雲端帳戶內執行，而不是在共用的第三方租戶中）；SOC 2 或 ISO 27001 認證；可配置的網路出口策略和稽核日誌匯出到 SIEM；使用短期 Token 進行 Session 級別的憑證範圍設定；以及限制 Agent 工作負載執行位置的資料駐留控制。Novita Agent Sandbox 支援在你自己的 AWS 或 GCP VPC 中進行 BYOC 部署，這解決了最常見的企業資料駐留和網路隔離要求。在做出架構決策之前，請在產品文件中驗證當前的合規認證和可用的配置選項。
