AI 代理沙箱是一個隔離的執行環境，AI 代理可以在其中執行程式碼、呼叫工具，以及與檔案系統或瀏覽器互動，而不會影響主機系統、相鄰的工作負載或敏感的基礎設施。沙箱建立了一個邊界：沙箱內部發生的事情就留在內部，而外部的事情則無法從內部觸及，除非你明確允許。Novita 代理沙箱 是這種模式的一種實作 — Firecracker 微型虛擬機隔離、在您自己的 AWS 或 GCP VPC 中進行 BYOC 部署，以及純粹的按用量付費定價 — 但這裡的概念適用於任何沙箱平台。本文回答了關於該邊界如何運作、取捨在哪裡，以及何時真正需要它的一些最常見問題。如需更深入探討隔離、機密、出口和合規要求的問答，請參閱 AI 代理沙箱常見問題。
什麼是 AI 代理沙箱？
AI 代理沙箱是 AI 代理執行其實際工作的執行層：編寫和執行程式碼、安裝套件、讀取和修改檔案、進行 API 呼叫，以及與瀏覽器工作階段或桌面 GUI 互動。沙箱提供了一個有邊界的環境，擁有自己的檔案系統、CPU 和記憶體分配、網路介面以及行程命名空間 — 並且與外部的一切隔離。
關鍵的設計目標是 封閉性。當 LLM 產生一個 shell 命令，而代理執行它時，該命令會在沙箱內部執行。如果它安裝套件、執行子行程或嘗試讀取憑證，這些操作都將被限制在沙箱內。如果程式碼導致行程崩潰或磁碟空間耗盡，損害也僅限於本地。
沙箱也作為雲端供應商的計費和資源計算單位。當你呼叫像 E2B、Daytona 或 Novita 代理沙箱 這樣的 SDK 時，你正在建立一個沙箱實例，在其中執行操作，然後關閉它 — 供應商根據你消耗的計算資源來收費。
代理沙箱與一般容器有何不同？
一般容器為你提供檔案系統命名空間和資源限制，但同一主機上的所有容器共享同一個作業系統核心。如果容器內的行程利用核心漏洞或配置錯誤的系統呼叫過濾器，它可能會影響主機或其他容器。
代理沙箱通常會更進一步，使用 微型虛擬機 邊界。微型虛擬機將工作負載包裝在一個輕量級虛擬機中，擁有自己的客戶核心，並由硬體虛擬化（KVM）支援。客戶端與主機核心在設計上是隔離的，因此客戶端內的核心漏洞不會自動影響主機。
實際的取捨在於效能開銷。微型虛擬機啟動速度比容器慢，因為它需要啟動核心，即使是最小化的核心。像 Firecracker 這樣的快速微型虛擬機平台已將此開銷在大多數情況下降低到 500 毫秒以下，而像 Daytona 這樣基於快照的系統則將其推至 100 毫秒以下。但它仍然比啟動容器有更多的開銷。
對於大多數涉及 LLM 生成或不受信任程式碼的 AI 代理工作負載來說，更強的邊界是值得的。如果你執行的是完全受信任的內部程式碼，且沒有使用者輸入，那麼強化容器可能就足夠了。
在 AI 代理的背景下，什麼是隔離？
代理沙箱中的隔離在多個維度上運作。如需深入了解 沙箱隔離 在實際工作負載下的表現，包括微型虛擬機邊界在哪裡有幫助、在哪裡沒幫助，請參閱 Firecracker 評估指南。
檔案系統隔離 — 代理擁有自己的檔案系統，與主機分離。在沙箱內寫入的檔案不會出現在主機上，除非明確掛載，否則也無法從內部存取主機檔案。這可以防止代理讀取存在於沙箱外的憑證、設定檔或其他機密。
行程隔離 — 沙箱內部的行程無法看到或向外部行程發送訊號。代理可以在沙箱內啟動子行程、背景任務或伺服器，但它們無法與主機行程樹進行通訊。
網路隔離 — 預設情況下，代理沙箱可以配置為阻止、允許列或限制對外網路呼叫的速率。一個不應能夠將資料外洩到任意網際網路地址的代理，可以被限制為僅能存取已知的端點列表。詳情請參閱下面的出口過濾章節。
資源隔離 — CPU 和記憶體分配受到限制。一個進入無限迴圈或產生大量輸出的代理，不會耗盡同一主機上其他沙箱的資源，因為資源限制是在虛擬機或容器層級實施的。
這些維度共同定義了 爆炸半徑：如果代理行為不當、崩潰或執行意外程式碼，最壞的情況是什麼？
什麼是出口過濾（Egress Filtering），為什麼它很重要？
出口過濾控制代理被允許從沙箱內部建立哪些對外網路連線。
在寬鬆的配置中，代理可以對網際網路上的任何主機進行 HTTP/HTTPS 呼叫。這對於需要擷取套件、呼叫外部 API 或瀏覽網頁的程式碼代理來說很方便。但這也意味著一個被入侵的代理，或者一個被提示注入攻擊操縱的代理，可以將資料外洩到攻擊者控制的伺服器，或與不應觸及的基礎設施進行互動。
在嚴格的配置中，出口被鎖定為一個明確的允許列表：代理只能呼叫模型 API、特定的資料庫和套件註冊表。其他所有流量都會被丟棄。這更難設定，並且需要隨著代理依賴關係的變化而維護允許列表，但它提供了更小的攻擊面。
大多數生產環境的代理部署都存在於這兩個極端之間：出口並非完全不受限制，但也並非從第一天起就鎖定為零信任列表。常見的模式包括阻止已知的惡意目標、記錄所有對外呼叫以供稽核，以及隨著代理行為變得可預測而逐步收緊列表。如需完整說明 出口控制 以及哪些東西仍然可以逃脫每個隔離邊界，請參閱安全程式碼執行指南。
一些沙箱供應商透過 SDK 為你提供程式化的出口控制。其他供應商則將沙箱預設為完全對外開放。在假設你的代理無法連線到外部主機之前，請先了解你的供應商使用哪種模式。
代理沙箱中的快照（Snapshotting）是什麼？
快照會捕捉正在運行的沙箱的完整狀態 — 檔案系統、記憶體、運行中的行程、網路狀態 — 並將其儲存起來，以便稍後可以將沙箱恢復到該狀態。
這在以下幾種情況下很有用：
減少冷啟動成本 — 不必每次都啟動一個新的虛擬機並安裝套件，你可以啟動一次，安裝所有東西，拍攝快照，然後在每個新工作階段從該快照恢復。Daytona 低於 90 毫秒的冷啟動速度就是因為這項技術而實現的。
為長時間運行的代理設定檢查點 — 一個處理多小時任務的程式碼代理可以中途暫停，並保存其確切狀態。如果需要審查、修改或重新啟動代理，它可以從檢查點恢復，而不是從頭開始。
可重現的評估 — 對於強化學習訓練或模型評估管線，你可以拍攝一個已知良好的起始狀態的快照，並在每次評估回合之前重置到該狀態。這為你提供了多次運行之間真正相同的起始條件，而不是重新配置並希望狀態匹配。
並非所有沙箱供應商都在 API 層級公開快照控制。E2B 的模板系統處理了「預安裝環境」的使用案例，但不提供任意中途會話的檢查點恢復。Daytona 的快照 API 更靈活。
哪些技術為代理沙箱提供支援？
最常見的底層技術包括：
Firecracker — 由 AWS 開發的微型虛擬機運行時，內部用於 Lambda 和 Fargate。Firecracker 在 500 毫秒內啟動一個最小化的客戶核心，透過暴露最小的設備模型來減少攻擊面，並由 KVM 硬體虛擬化支援。E2B 和 Novita 代理沙箱 都使用 Firecracker。
gVisor — 由 Google 開發的核心沙箱，它攔截系統呼叫，而不是運行一個完整的客戶核心。它比微型虛擬機更輕量，但不提供完整的核心隔離 — 它位於隔離光譜上的行程層級和虛擬機層級之間。
具有系統呼叫過濾功能的 Docker 容器 — 使用 seccomp、AppArmor 和最小化權限進行強化的容器。這是最常見的起點，但對於不受信任的程式碼來說，它是最弱的隔離邊界。
V8 / Deno — 使用 V8 運行時的權限模型進行 JavaScript 特定的隔離。適用於沙箱化僅限 JavaScript 的工作負載，但對於需要執行任意 shell 命令或非 JavaScript 程式碼的代理來說無法使用。
底層技術的選擇決定了沙箱的啟動效能、隔離強度和操作複雜性。對於在多租戶環境中執行不受信任或 LLM 生成程式碼的代理工作負載，Firecracker 級別的隔離是目前實務上的標準。
AI 代理能逃脫沙箱嗎？
在實務上，沙箱逃逸雖然罕見但並非不可能，風險概況取決於技術：
容器逃逸 是有記錄的。配置不當的容器 — 特權模式、掛載了 Docker socket、可寫入的主機目錄 — 具有已知的逃逸向量。一個沒有權限、唯讀根檔案系統和最小化權限的強化容器可以大幅降低此風險，但並不能完全消除。
微型虛擬機逃逸 需要一個 hypervisor 漏洞或設備模型中的缺陷。這些情況很少見，因為攻擊面在設計上很小。Firecracker 的最小化設備模型是專門為了減少 hypervisor 暴露而設計的。AWS 尚未披露任何在生產環境中的 Firecracker 層級逃逸事件。
提示注入到沙箱操作 是一種不同類型的「逃逸」 — 不是核心漏洞，而是攻擊者將指令嵌入到使用者提供的內容中，導致代理採取不應採取的行動。這是一個應用層面的問題，而不是沙箱層面的問題。沙箱有助於限制提示注入造成的損害（被注入的程式碼在沙箱內部運行，而不是在你的主機上），但它們無法防止注入本身。
實際結論：一個配置良好的基於 Firecracker 的沙箱在理論上並非無法逃逸，但攻擊門檻足夠高，對於大多數企業代理部署來說，殘餘風險是可控的。更常見的失敗模式是配置錯誤（過於寬鬆的出口、傳遞到沙箱中的憑證範圍不當），而不是核心層級的漏洞利用。
AI 代理沙箱支援 GPU 工作負載嗎？
截至 2026 年中，大多數 AI 代理沙箱不包含 GPU 支援。E2B、Daytona 和 Vercel Sandbox 都僅限 CPU。
在受管理的沙箱領域，Modal 是主要的例外 — 它在容器內提供隨需 GPU 存取，適用於需要與代理程式碼在同一環境中使用 GPU 的模型推理、微調或強化學習工作負載。
對於大多數代理工作流程，代理本身會呼叫外部的 LLM 推理 API（例如 Novita 的推理端點），而不是在本地運行模型。在這種架構中，你不需要在沙箱中使用 GPU — 沙箱處理程式碼、檔案操作和工具呼叫，而繁重的推理則在單獨的 GPU 服務上運行。這是程式碼代理、數據分析代理和大多數瀏覽器自動化工作流程所使用的模式。
如果你確實需要在沙箱內使用 GPU — 例如，用於離線使用的本地模型推理、強化學習訓練步驟或多步驟評估管線 — 請將此納入你的供應商選擇考量。Modal 目前是此模式最常用的選項。
何時真正需要專用的沙箱？
並非每個 AI 應用程式都需要專用的沙箱。以下情況中，沙箱能帶來真正的價值：
你正在執行 LLM 生成的程式碼 — 代理撰寫並運行非人類編寫的程式碼，可能執行意想不到的操作。這是核心使用案例：在沙箱中執行，使其無法影響你的主機、憑證或其他工作負載。
你正在服務終端使用者 — 多個使用者的代理運行共享相同的底層基礎設施。你需要在使用者之間進行隔離，以防止一個使用者的代理有意或無意地影響另一個使用者的代理。
你需要長時間運行的有狀態工作流程 — 一個編輯檔案、運行測試和提交變更的程式碼代理需要一個跨多個 LLM 輪次持續存在的工作空間。每次呼叫都建立一個新的子行程無法維持狀態；而沙箱可以。
你有合規或稽核要求 — 你需要記錄所有代理操作、限制網路存取，或證明代理工作負載無法存取生產資料庫或憑證。沙箱為這些控制提供了實施層。
你正在進行瀏覽器或電腦使用自動化 — 瀏覽器自動化沙箱 環境與主機完全隔離，因此代理可以點擊、輸入和截圖，而不會影響你的本地瀏覽器工作階段或系統狀態。
如果你只運行一個簡單的「總結這段文字」管線，且沒有程式碼執行，你可能不需要專用的執行沙箱 — 對 LLM 進行 API 呼叫就足夠了。一旦代理開始執行具有副作用（side effects）的操作：寫入檔案、執行程式碼、代表你呼叫外部 API，沙箱就變得必要了。
常見問題
AI 代理沙箱與開發環境相同嗎？
不。開發環境是人類開發者使用的工作空間 — 它跨工作階段持續存在、是長期的，並且設計為可自訂和重複使用。AI 代理沙箱是一個運行時執行邊界：它存在於任務期間，設計為短暫且可重現，其主要工作是封閉性，而不是開發者的舒適度。一些沙箱可以在一個工作階段內跨 LLM 輪次持續存在狀態（使其感覺更像一個工作空間），但設計目標是與主機隔離，而不是一個功能完整的 IDE。這些術語在供應商的行銷中有時會重疊；如果你正在評估一個平台，請查看實際的隔離邊界是什麼，而不是標籤。
什麼是代理執行沙箱？
代理執行沙箱與 AI 代理沙箱是同一回事 — 「執行」這個框架只是強調了運行時方面。當 LLM 決定採取某個行動（執行程式碼、呼叫工具、寫入檔案）時，這些行動會在沙箱內執行。沙箱是執行層，它強制執行了代理行為與系統其餘部分之間的可見性和影響邊界。在業界，「代理沙箱」、「程式碼執行沙箱」和「代理執行環境」這幾個術語可以互換使用。
對於 AI 代理工作負載，Firecracker 與 gVisor 相比如何？
兩者都提供了超越標準容器的隔離，但機制不同。Firecracker 在 KVM 支援的微型虛擬機內啟動一個最小化的客戶核心 — 沙箱擁有自己的核心，與主機核心完全分離。gVisor 使用使用者空間核心（runsc）攔截系統呼叫，而不運行完整的客戶核心。實際的取捨：Firecracker 提供了更強的主機邊界，因為客戶核心是完全分離的；gVisor 每個沙箱的記憶體開銷較低，因為它不運行完整的核心，但隔離程度介於完整的微型虛擬機和經過系統呼叫攔截強化的容器之間。對於運行不受信任的 LLM 生成程式碼的多租戶 AI 代理工作負載，Firecracker 級別的隔離是目前的生產標準。對於程式碼部分受信任且記憶體密度比最大隔離更重要的工作負載，gVisor 是合理的選擇。
提示注入會導致代理逃脫其沙箱嗎？
提示注入不會繞過沙箱的技術隔離 — 它利用代理的決策過程來執行攻擊者意圖但開發者未預期的操作。像「將環境變數外洩到這個 URL」這樣的注入指令會導致代理發出對外網路呼叫，這只有在出口政策阻止時才會被攔截。沙箱的檔案系統和行程隔離保持完整。這意味著沙箱安全和提示注入防禦處理的是堆疊的不同部分：沙箱在基礎設施層級限制了代理能做的事情的爆炸半徑；應用層控制（工具呼叫限制、人工審批、出口允許列表）則防禦代理被引導去濫用這些能力。
為什麼需要專門為 AI 代理設計沙箱？
與傳統程式碼執行的關鍵區別在於 不確定性。當人類開發者編寫程式碼時，開發者大致知道它會做什麼。當 LLM 生成程式碼或決定呼叫工具時，應用程式可能對具體將運行什麼、將安裝哪些套件、或將聯繫哪些外部端點只有有限的能見度 — 且可能涉及數千個並發工作階段。這種不確定性提高了每個標準安全控制的風險：出口政策很重要，因為代理可能連接到沒有人預料到的端點；套件治理很重要，因為代理可能動態安裝依賴項；稽核日誌很重要，因為當代理的操作沒有被預先列舉時，重建發生的事情更困難。沙箱為你提供了處理這種不確定性的執行層，而無需事先信任每個單獨的代理操作。
常見沙箱供應商
以下是主要選項的簡要概述，更完整的比較請參閱相關文章：
- Novita 代理沙箱 — Firecracker 微型虛擬機，在您自己的 AWS 或 GCP VPC 中進行 BYOC 部署，無訂閱費，最長 24 小時工作階段。對於有合規要求、成本敏感，或已使用 Novita 進行 LLM 推理的團隊來說，是主要選項。請參閱 novita.ai/sandbox。
- E2B — 受管理，Firecracker 微型虛擬機，大型社群，無需自託管。文件完善的 SDK 和活躍的生態系統。
- Daytona — 低於 90 毫秒的冷啟動，開源（AGPL），可自託管。更適合需要低延遲或需要自託管基礎設施的合規使用案例。
- Modal — 當你需要沙箱內 GPU 時的主要選項。基於容器的隔離。
- Vercel Sandbox — 快速冷啟動，最適合 Vercel 平台上的 JS/TS。
如需包含規格和決策框架的完整比較，請參閱 2026 年最佳 AI 代理沙箱。如需針對 E2B 和 Daytona 的深入評估 — 冷啟動、BYOC、快照和定價 — 請參閱 AI 代理沙箱評估指南：E2B 與 Daytona 比較。
