什麼是 AI 代理沙箱？

AI 代理沙箱是 AI 代理執行其實際工作的執行層：編寫和執行程式碼、安裝套件、讀取和修改檔案、進行 API 呼叫，以及與瀏覽器工作階段或桌面 GUI 互動。沙箱提供了一個有邊界的環境，包含自己的檔案系統、CPU 和記憶體分配、網路介面以及行程命名空間——並且與外部的一切隔離。

關鍵的設計目標是 封閉性。當 LLM 產生一個 shell 命令且代理執行它時，該命令會在沙箱內執行。如果它安裝了一個套件、執行了一個子行程，或嘗試讀取憑證，這些操作都將限定在沙箱內。如果程式碼導致行程崩潰或磁碟空間耗盡，損害也只會停留在本地。

沙箱也作為雲端供應商的計費和資源核算單位。當你呼叫像 E2B、Daytona 或 Novita Agent Sandbox 這樣的 SDK 時，你就是在建立一個沙箱實例，在其中執行操作，然後關閉它——而供應商會根據你消耗的計算資源來收費。

代理沙箱與一般容器有何不同？

一般的容器提供了一個檔案系統命名空間和資源限制，但同一主機上的所有容器共享相同的作業系統核心。如果容器內的行程利用核心漏洞或配置錯誤的系統呼叫過濾器進行攻擊，它可能會影響主機或其他容器。

代理沙箱通常會更進一步，使用 微型虛擬機 邊界。微型虛擬機將工作負載包裝在一個輕量級的虛擬機中，擁有自己的客戶核心，並由硬體虛擬化 (KVM) 支援。客戶端與主機核心在設計上是隔離的，因此客戶端中的核心漏洞不會自動影響主機。

實際的取捨是效能開銷。微型虛擬機啟動速度比容器慢，因為它需要啟動一個核心，即使是最小化的核心。像 Firecracker 這樣的快速微型虛擬機平台已將此開銷降低到大多數情況下低於 500 毫秒，而像 Daytona 這樣的基於快照的系統則將其推至 100 毫秒以下。但這仍然比啟動容器有更多的開銷。

對於大多數涉及 LLM 產生或不受信任程式碼的 AI 代理工作負載來說，更強的邊界是值得的。如果你執行的是完全受信任的內部程式碼，且沒有使用者輸入，那麼一個強化過的容器可能就足夠了。

在 AI 代理的背景下，什麼是隔離？

代理沙箱中的隔離在多個層面上運作。如需深入探討沙箱隔離在真實工作負載下的表現，包括微型虛擬機邊界在哪裡有幫助、在哪裡沒有幫助，請參閱 Firecracker 評估指南。

檔案系統隔離——代理擁有自己的檔案系統，與主機分離。在沙箱內寫入的檔案不會出現在主機上，除非明確掛載，否則主機檔案也無法從沙箱內部存取。這可以防止代理讀取存在於沙箱之外的憑證、配置檔案或其他機密。

行程隔離——沙箱內的行程無法看到或向沙箱外的行程發送信號。代理可以在沙箱內啟動子行程、背景任務或伺服器，但它們無法與主機行程樹進行通訊。

網路隔離——預設情況下，代理沙箱可以配置為封鎖、允許清單或限制速率的外出網路呼叫。一個不應該能夠將資料外洩到任意網際網路位址的代理，可以被限制在一個已知的端點列表中。詳情請參閱下面的出口過濾部分。

資源隔離——CPU 和記憶體分配有上限。一個進入無限迴圈或產生大量輸出內容的代理，不會使同一主機上的其他沙箱資源匱乏，因為資源限制是在 VM 或容器層級強制執行的。

這些維度共同定義了 爆炸半徑：如果代理行為不當、崩潰或執行意外程式碼，最壞的情況是什麼？

什麼是出口過濾，為什麼它很重要？

出口過濾控制代理允許從沙箱內部進行的外出網路連線。

在寬鬆的配置中，代理可以向網際網路上的任何主機進行 HTTP/HTTPS 呼叫。這對於那些需要獲取套件、呼叫外部 API 或瀏覽網頁的編碼代理來說很方便。但這也意味著一個被入侵的代理，或一個受到提示注入攻擊操縱的代理，可能將資料外洩到攻擊者控制的伺服器，或與不應觸及的基礎設施進行互動。

在嚴格的配置中，出口被鎖定在一個明確的允許清單中：代理只能呼叫模型 API、特定的資料庫和套件 registry。其他所有連線都會被丟棄。這更難設置，並且需要隨著代理依賴項的變化而維護允許清單，但它提供了更小的攻擊面。

大多數生產環境的代理部署存在於這些極端情況之間：出口並非完全不受限制，但也不是從第一天就鎖定在零信任清單上。常見的模式包括封鎖已知的不良目的地、記錄所有外出呼叫以供稽核，以及隨著代理行為變得可預測而逐步收緊清單。如需完整了解出口控制以及哪些東西仍然可以逃脫每個隔離邊界，請參閱安全程式碼執行指南。

一些沙箱供應商透過 SDK 提供程式化的出口控制。其他供應商則將沙箱預設為完全開放的對外連線。在假設你的代理無法觸及外部主機之前，請先了解你的供應商使用的是哪種模式。

在代理沙箱中，機密和憑證是如何被限定範圍的？ {#secrets-and-credentials}

傳入沙箱的機密應僅限定於該特定代理執行所需的内容——並且應作為環境變數或短期令牌傳遞，而不是寫入磁碟的長期憑證。沙箱邊界限制了爆炸半徑，但並不能自動防止代理讀取和轉發它在環境內可以存取的任何憑證。

核心原則是 最小權限：傳遞能完成工作的最小範圍憑證，而不是根雲端金鑰或具有廣泛權限的服務帳戶。常見模式：

啟動時的環境變數——在啟動時將機密注入沙箱環境。它對代理的程式碼可用，但預設不會持久化到檔案系統快照，也不會出現在日誌中。優先選擇短期令牌而非靜態 API 金鑰。

DNS 層級封鎖——某些部署配置允許你限制從沙箱內部可以解析哪些 DNS 名稱。這可以防止代理聯繫到憑證外洩端點，即使它有網路存取權限，方法是透過在 DNS 層級進行封鎖，而不是按個別 IP 封鎖。

具有短 TTL 的限定範圍服務帳戶——對於呼叫雲端 API 的代理，請使用具有短生命週期的角色扮演鏈。如果憑證洩露，攻擊者的機會窗口將受到令牌生命週期的限制。

不要掛載主機憑證檔案——避免將主機憑證檔案（如 ~/.aws/credentials）掛載到沙箱檔案系統中。改為每個工作階段產生全新的短期憑證。

沙箱提供了行程層級的邊界；你仍然需要對你傳入其中的內容負責。

AI 代理沙箱中的稽核日誌如何運作？ {#audit-logs}

代理沙箱的稽核日誌通常涵蓋兩個層級：平台層級事件（沙箱建立、啟動、停止、超時）和應用程式層級事件（執行的命令、修改的檔案、進行的外部 API 呼叫）。大多數託管供應商會自動發出平台事件；應用程式層級的日誌記錄則由你負責進行檢測。

要捕獲哪些內容以獲得有意義的稽核覆蓋範圍：

沙箱生命週期事件——建立時間戳記、工作階段持續時間、終止原因（正常關閉、超時或崩潰）。大多數託管平台會自動記錄這些事件，並透過 API 或儀表板公開。

外出網路呼叫——代理聯繫了哪些主機，附帶時間戳記。這是出口日誌記錄和稽核日誌記錄重疊的地方。如果你的平台支援出口日誌記錄，請啟用它並將輸出路由到你的日誌聚合器。

程式碼執行輸入/輸出——代理執行的命令以及它收到的結果。這是應用程式層級的，必須在你的代理框架中捕獲，而不是在沙箱基礎設施層級。

檔案系統變更——寫入、刪除或修改的檔案。這與編碼代理和資料處理管道相關。一些沙箱平台在工作階段結束時會公開檔案系統差異 API；其他的則需要你在代理程式碼中進行檢測。

對於合規用例（SOC 2、HIPAA、受監管行業），你通常需要在防篡改儲存中的平台層級日誌，以及來自代理框架的應用程式層級日誌。在假設覆蓋範圍之前，請確認你的供應商實際發出了哪些內容，以及哪些需要明確啟用。

代理沙箱中的快照是什麼？

快照捕獲了正在執行的沙箱的精確狀態——檔案系統、記憶體、正在執行的行程、網路狀態——並將其儲存起來，以便稍後可以將沙箱恢復到該狀態。

這在以下幾種場景中很有用：

減少冷啟動成本——無需每次啟動新的 VM 並安裝套件，而是啟動一次，安裝所有內容，拍攝快照，然後在每個新工作階段中從該快照恢復。Daytona 低於 90 毫秒的冷啟動之所以可能，就是因為這項技術。

檢查點化長時間運行的代理——一個正在處理多小時任務的編碼代理可以在中途暫停，並儲存其精確狀態。如果需要審查、修改或重新啟動代理，它可以從檢查點恢復，而不是從頭開始。

可重現的評估——對於強化學習訓練或模型評估流程，你可以快照一個已知良好的起始狀態，並在每個評估回合之前重置到該狀態。這讓你在多次運行中獲得真正相同的起始條件，而不是重新配置並希望狀態匹配。

並非所有沙箱供應商都在 API 層級公開快照控制。E2B 的範本系統處理了「預安裝環境」的用例，但不提供任意的工作階段中檢查點-恢復功能。Daytona 的快照 API 更為靈活。

哪些技術為代理沙箱提供支援？

最常見的底層技術包括：

Firecracker——由 AWS 開發的微型虛擬機執行環境，內部用於 Lambda 和 Fargate。Firecracker 在 500 毫秒內啟動一個最小化的客戶核心，暴露最小化的設備模型以減少攻擊面，並由 KVM 硬體虛擬化支援。E2B 和 Novita Agent Sandbox 都使用 Firecracker。

gVisor——Google 開發的核心沙箱，它攔截系統呼叫而不是運行完整的客戶核心。它比微型虛擬機更輕量，但不提供完整的核心隔離——它位於隔離頻譜上的行程層級和 VM 層級之間。

具有系統呼叫過濾功能的 Docker 容器——使用 seccomp、AppArmor 和最小化權限進行強化的容器。這是最常見的起點，但對於不受信任的程式碼來說，這是最弱的隔離邊界。

V8 / Deno——使用 V8 執行環境的權限模型進行特定於 JavaScript 的隔離。適用於沙箱化僅限 JavaScript 的工作負載，但不能用於需要執行任意 shell 命令或非 JS 程式碼的代理。

底層技術的選擇決定了沙箱的啟動效能、隔離強度和操作複雜性。對於在多租戶環境中執行不受信任或 LLM 產生程式碼的代理工作負載，Firecracker 級別的隔離是當前的實際標準。

AI 代理能否逃脫沙箱？

實際上，沙箱逃逸雖然罕見，但並非不可能，風險取決於技術：

容器逃逸 是有記錄的。配置不當的容器——特權模式、掛載了 Docker socket、可寫入的主機目錄——具有已知的逃逸向量。一個沒有權限、唯讀根檔案系統和最小化權限的強化容器，可以大幅降低這種風險，但並不能消除它。

微型虛擬機逃逸 需要一個虛擬機器監視器漏洞或設備模型中的缺陷。這些情況很罕見，因為攻擊面在設計上很小。Firecracker 的最小化設備模型是專門為了減少虛擬機器監視器的暴露而設計的。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 呼叫就足夠了。一旦代理開始執行具有副作用的操作：寫入檔案、執行程式碼、代表你呼叫外部 API，沙箱就變得必要了。

程式碼直譯器與代理執行環境有何不同？ {#code-interpreter-vs-agent-runtime}

程式碼直譯器 隔離地運行單個程式碼片段並返回輸出。它預設是無狀態的：每次執行都從乾淨狀態開始，結果返回，沒有什麼會持久化。可以把它想像成一個沙箱化的 Jupyter 核心，其中儲存格在呼叫之間不共享狀態。這是資料分析、公式評估或一次性程式碼執行（你不需要在運行之間保持狀態）的正確工具。

代理執行環境 是一個持久的、有狀態的執行環境，專為多步驟工作流程設計。代理可以寫入檔案、安裝套件、運行背景行程、進行網路呼叫，並在多次 LLM 輪次中累積工作區狀態——所有這些都不會在步驟之間丟失上下文。一個編輯檔案、運行測試、讀取錯誤輸出並進行迭代的編碼代理，是在代理執行環境中運作，而不是在程式碼直譯器中。

這個區別對於工具設計很重要：

	程式碼直譯器	代理執行環境
呼叫間的狀態	無（每次執行都是全新的）	工作階段內持久化
檔案系統存取	通常每次呼叫隔離	持久化工作區
多步驟工作流程	非設計用途	核心用例
典型工作階段長度	秒級	分鐘到小時
範例	Jupyter 核心、單個程式碼儲存格	E2B、Daytona、Novita Agent Sandbox

在實踐中，界線是模糊的。E2B 和大多數託管沙箱平台可以像程式碼直譯器一樣運作（運行一個片段，返回輸出），但它們在底層提供了完整的代理執行環境基礎設施——持久化檔案系統、行程管理、網路存取。像 OpenAI 的 Code Interpreter 這樣的平台是專門為無狀態用例設計的，並在代理執行環境提供的靈活性方面做出了有意的取捨。

當你需要一個快速、隔離的執行環境來執行不需要狀態的單一任務時，請選擇程式碼直譯器。當你的工作負載涉及迭代檔案編輯、已安裝的套件依賴項、長時間運行的行程，或任何需要從中斷處繼續的工作流程時，請選擇代理執行環境。

如何安全地執行 AI 產生的程式碼？ {#run-ai-generated-code-safely}

在生產環境中安全地執行 AI 產生的程式碼需要在每個層級都有適當的控制——沙箱處理執行邊界，但你也需要做出應用程式層級的決策。

對於不受信任的程式碼，使用微型虛擬機級別的隔離，而不是容器。 基於 Firecracker 的沙箱（E2B、Novita Agent Sandbox）將 LLM 產生的程式碼放在具有自己核心的 VM 中。容器逃逸是有記錄的，並且有已知的向量；微型虛擬機級別的逃逸需要虛擬機器監視器漏洞，並且在設計上很罕見。當程式碼未經人工審查時，冷啟動成本值得換取更強的邊界。

將出口限制為代理實際需要的內容。 一個運行資料分析程式碼的代理可能不需要觸及任意的網際網路主機。將出口鎖定到模型 API、特定的套件 registry，以及任務明確要求的任何外部服務。在 BYOC 部署中，這可以在 VPC 安全群組層級強制執行。在託管部署中，如果可用，請使用供應商的出口控制，否則接受並記錄無限制的出口作為已知風險。

僅傳遞限定範圍的、短期憑證。 不要讓沙箱存取生產資料庫、根雲端金鑰或廣泛的服務帳戶。僅傳遞當前任務所需的內容，使用具有短 TTL 的憑證。如果產生的程式碼讀取並外洩了憑證，損害是有限的。

強制執行超時和資源限制。 對執行設定明確的時間和記憶體限制。LLM 產生的無限迴圈或意外的大輸出應該優雅地終止，而不是無限期地消耗工作階段或填滿磁碟。

從一開始就記錄出口和命令歷史。 如果沒有代理行為的記錄，你就無法調查意外行為。即使在開發環境中，也要及早啟用出口日誌記錄。已執行命令、檔案寫入和外部呼叫的應用程式層級日誌記錄由你負責——沙箱基礎設施不會自動執行此操作。

沒有任何配置可以完全消除風險。目標是達到一個已知的、有限的殘餘風險：代理在你未編寫的程式碼，在一個強大的隔離邊界內，使用其所需的最小憑證和網路存取權限，並有足夠的日誌記錄來檢測和診斷意外行為。

常見問題

AI 代理沙箱與開發環境相同嗎？

不。開發環境是人類開發者使用的工作區——它跨工作階段持久化，是長期存在的，並且設計為可自訂和可重複使用。AI 代理沙箱是一個執行階段邊界：它存在於任務持續期間，設計為短暫且可重複，其主要工作是封閉性，而不是開發者的舒適度。一些沙箱可以在工作階段內的 LLM 輪次之間持久化狀態（使它們感覺更像一個工作區），但設計目標是與主機隔離，而不是一個功能齊全的 IDE。這兩個術語有時在供應商的行銷中重疊；如果你正在評估一個平台，請查看實際的隔離邊界是什麼，而不是標籤。

什麼是代理執行沙箱？

代理執行沙箱與 AI 代理沙箱是同一回事——「執行」這個框架只是強調了執行階段層面。當 LLM 決定採取行動（執行程式碼、呼叫工具、寫入檔案）時，這些行動會在沙箱內執行。沙箱是執行層，它強制執行了代理所做的事情與系統其餘部分所能看到或受到影響的事情之間的邊界。術語「代理沙箱」、「程式碼執行沙箱」和「代理執行環境」在業界可以互換使用。

對於 AI 代理工作負載，Firecracker 與 gVisor 相比如何？

兩者都提供了超越標準容器的隔離，但透過不同的機制。Firecracker 在 KVM 支援的微型虛擬機內啟動一個最小化的客戶核心——沙箱擁有自己的核心，與主機核心完全分離。gVisor 使用使用者空間核心 (runsc) 攔截系統呼叫，而不運行完整的客戶核心。實際的取捨：Firecracker 提供了更強的主機邊界，因為客戶核心是完全分離的；gVisor 每個沙箱的記憶體開銷較低，因為它不運行完整的核心，但隔離是在完整的微型虛擬機和使用系統呼叫攔截強化的容器之間。對於運行不受信任的 LLM 生成程式碼的多租戶 AI 代理工作負載，Firecracker 級別的隔離是當前的生產標準。gVisor 適用於程式碼部分受信任且記憶體密度比最大隔離更重要的工作負載。

提示注入會導致代理逃脫其沙箱嗎？

提示注入不會繞過沙箱的技術隔離——它利用代理的決策過程來執行攻擊者意圖但開發者未預期的操作。像「將環境變數外洩到此 URL」這樣的注入指令會導致代理發出外出網路呼叫，這只有在出口策略阻止它時才會被阻止。沙箱的檔案系統和行程隔離保持不變。這意味著沙箱安全性和提示注入防禦處理了堆疊的不同部分：沙箱在基礎設施層級限制了代理所能做的事情的爆炸半徑；應用程式層級的控制（工具呼叫限制、人工審批、出口允許清單）則防禦代理被引導濫用這些能力。

為什麼需要專門為 AI 代理設計沙箱？

與傳統程式碼執行的關鍵區別在於 不確定性。當人類開發者編寫程式碼時，開發者大致知道它會做什麼。當 LLM 產生程式碼或決定呼叫工具時，應用程式可能對具體會執行什麼內容、會安裝哪些套件，或會聯繫哪些外部端點只有有限的能見度——而且可能是在數千個並發工作階段中。這種不確定性提高了每個標準安全控制的風險：出口策略很重要，因為代理可能觸及沒人預料到的端點；套件治理很重要，因為代理可能動態安裝依賴項；稽核日誌記錄很重要，因為當代理的動作沒有被預先列舉時，重建發生的事情會更困難。沙箱為你提供了應對這種不確定性的執行層，而不必事先信任每個單獨的代理動作。

常見的沙箱供應商

以下是主要選項的簡要概述，更完整的比較請參閱相關文章：

Novita Agent Sandbox — 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、快照和定價——請參閱比較 E2B 和 Daytona 的 AI 代理沙箱評估指南。

什麼是 AI 代理沙箱？