在為 AI 應用評估一個相容 E2B 或替代 E2B 的沙箱時，請在決定遷移之前檢查 API 面重疊程度、SDK 介面相容性、程式碼直譯器工作階段行為、檔案與狀態生命週期、套件安裝政策、網路出口控制、工作階段持續時間與並行限制，以及定價模型。這些檢查每一項都不超過一個下午便能完成——但若忽略任何一項，都是生產環境中遷移後最常見的意外來源。
為什麼沙箱遷移問題很重要
沙箱供應商在表面上看起來很相似。它們都提供隔離執行環境、某種形式的 Python 支援，以及 REST 或 SDK 介面。但當你實際嘗試運行真正的代理工作負載時，細節就會迅速分化：一個需要在工具呼叫之間保持持久檔案系統的程式碼代理、一個在執行時安裝 pandas 的資料分析工作流程、或者一個需要對特定 API 進行出站 HTTPS 請求的瀏覽器代理。
一份有用的遷移檢查清單不是功能對照表。它是一組你在決定供應商更換是低摩擦還是需要全面重新架構之前，針對你實際應用需求提出的問題。
本指南將逐一介紹每個類別，提出值得詢問的問題、在供應商文件中該注意什麼，以及 Novita Agent Sandbox 如何針對每個面向為正在評估它作為遷移目標的團隊提供解決方案。
API 與 SDK 相容性
需要提出的問題：
- 目標供應商是否為你的語言（Python、TypeScript、Go）提供官方 SDK？
- SDK 是否提供你依賴的相同高層級基本操作：沙箱建立、程式碼執行、檔案操作、程序管理？
- REST API 表面是否穩定且具有版本控制，還是正在快速變動？
- SDK 使用哪種驗證流程（API 金鑰標頭、OAuth、服務帳戶）？這是否與你現有的密碼管理相符？
該留意什麼： 明確涵蓋沙箱生命週期方法、檔案系統方法和程序方法的 SDK 文件。只有通用 REST API 而沒有維護 SDK 的供應商需要你編寫更多的銜接程式碼。
在實務中差異會出現在何處： E2B 的 Python SDK 封裝了沙箱建立、sandbox.run_code() 的程式碼執行以及檔案系統操作。如果你的應用程式呼叫特定的方法名稱或依賴 SDK 的串流輸出行為，請在假設目標供應商支援之前先測試那些路徑。
程式碼直譯器相容性
需要提出的問題：
- 沙箱是否支援互動式 Python 執行（REPL 風格，而不僅僅是腳本執行）？
- 標準輸出、標準錯誤和執行結果是如何分開的？
- 沙箱能否從 Python 程式碼產生圖表、圖形或二進位輸出（PNG、SVG、HTML）？
- 預設的 Python 版本是什麼，是否可以設定？
- 程式碼直譯器可以執行任意 shell 命令，還是執行僅限於 Python？
該留意什麼： 許多 AI 應用框架假設一種結構化或串流式執行結果，該結果將 stdout、stderr、顯示資料（Jupyter 風格的豐富輸出）和執行錯誤分開。如果你的代理會解析該結構，那麼一個只回傳純文字回應的供應商將需要你重寫解析層。
串流執行結果： 有些供應商在程式碼執行時串流部分輸出。其他供應商則在執行完成後回傳單一回應物件。對於短程式碼片段來說，這很少重要；但對於長時間運行的資料處理步驟來說，串流部分輸出通常對使用者體驗很重要。
工作階段生命週期與逾時行為
需要提出的問題：
- 預設和最大工作階段逾時是多少？
- 供應商是否支援暫停和恢復工作階段（狀態在中斷後保留）？
- 如果工作階段逾時，正在進行的執行會發生什麼事？
- 從你應用程式的角度來看，工作階段的建立是同步還是非同步的？
- 你如何明確終止工作階段，以及會自動執行什麼清理動作？
該留意什麼： 程式碼代理和多步驟資料分析工作流程通常需要比單次 LLM 輪次更長的工作階段。一個預設逾時為 60 秒且沒有暫停/恢復支援的供應商會迫使你的代理在每次輪次結束前序列化所有狀態——這是一個重大的架構限制。
特別關於暫停/恢復： 暫停/恢復與建立一個帶有快照的新工作階段不同。暫停/恢復保留記憶體中的程序狀態、開啟的檔案控制代碼和已載入的函式庫。快照與還原則還原檔案系統映像，但通常不保留運行中的程序。了解供應商提供哪種機制，以及你的代理實際需要哪一種。
工作階段建立延遲： 如果你的代理在每次工具呼叫時都建立一個新沙箱，啟動延遲會迅速累積。請查看供應商文件中關於冷啟動與暖池行為的說明，以及你是否可以預先預熱工作階段。
檔案與狀態持久性
需要提出的問題：
- 沙箱在工作階段內的多次程式碼執行步驟之間是否有持久的檔案系統？
- 在一個工作階段中建立的檔案能否在後續工作階段中存取，還是檔案系統是每個工作階段短暫的？
- 是否有檔案上傳/下載 API，還是必須內嵌傳遞檔案？
- 檔案系統大小限制是多少（每個工作階段的磁碟配額）？
- 如果你的代理產生大型工件（模型、資料集），檔案匯出是如何運作的？
該留意什麼： 大多數沙箱提供每個工作階段的短暫檔案系統。如果你的工作流程需要跨工作階段的持久性（例如，一個在多次使用者互動中建構工件的程式碼代理），請檢查供應商是否支援命名卷、持久工作空間，或一個有文件說明的匯出與還原模式。
在程式碼直譯器模式中的檔案 I/O： 對於資料分析代理，能夠在沙箱內寫入 CSV 或 PNG 並隨後將其下載到你的應用程式是一個核心基本操作。測試整個回圈是否能端到端運作：上傳檔案、運行讀取並轉換檔案的程式碼、下載結果。
套件安裝政策
需要提出的問題：
- 沙箱內的程式碼能否在執行時不受限制地執行
pip install？ - 供應商是否允許自訂基礎映像或預先安裝的套件環境？
- 是否有機制可以將套件加入允許清單或拒絕清單？
- 套件安裝是否在工作階段內的多次工具呼叫之間保留，還是每次執行都會重置？
- 套件安裝失敗時（缺少系統依賴、版本衝突）會發生什麼事？
該留意什麼： 執行時套件安裝是沙箱最常見的分歧點之一。有些供應商將套件安裝到持久的工作階段層中，因此步驟 1 中的 pip install pandas 在步驟 2 中仍然可用。其他供應商則在每個程式碼區塊上重置為基礎映像。如果你的代理假設安裝是持久的，這將是一個破壞性假設。
供應鏈注意事項： 在執行時允許任意 pip install 具有供應鏈影響。對於生產工作負載，請詢問供應商是否允許網路受限的安裝（來自私有 PyPI 鏡像或精心挑選的允許清單），而不是從公共網際網路開放 pip install。
網路政策與出口流量
需要提出的問題：
- 出站網際網路存取是否預設啟用，還是沙箱網路隔離？
- 沙箱內的程式碼能否向外部 API 發送 HTTP 請求？
- 是否有可設定的出口目的地允許清單或拒絕清單？
- 沙箱內的 DNS 解析如何處理？
- 兩個沙箱能否直接通訊，還是只能透過你的應用程式層？
該留意什麼： 對於一個擷取公共資料集的資料分析代理來說，開放的出口是很方便的。對於在安全敏感環境中運行的程式碼代理來說，受控制或封鎖的出口是正確的預設。了解你的工作負載需要哪一種。
瀏覽器代理 vs. 程式碼執行代理： 瀏覽器代理通常需要完整的網際網路存取（以導航到使用者指定的 URL）。程式碼執行代理通常只需要存取特定 API。這些是不同的出口配置檔，可能需要不同的沙箱配置。
沙箱中的密碼處理
需要提出的問題：
- 你如何在建立沙箱時將密碼（API 金鑰、認證資訊）注入其中？
- 注入的密碼是以環境變數、掛載的檔案，還是兩者皆可存取？
- 密碼是否會顯示在執行日誌或序列化狀態中？
- 供應商是否會自動從日誌輸出中清除密碼？
該留意什麼： 最常見的錯誤是通過環境變數注入密碼，然後沙箱在啟動時記錄所有環境變數，從而將密碼洩漏到你的可觀測性堆疊中。詢問供應商是否有任何清除行為，如果沒有的話，請建立應用程式層級的清除。
與一般環境變數的差異： 並非所有環境變數都是密碼。將兩者視為可互換（沒有類型化密碼、沒有修訂）的供應商會需要你在己方進行更多的防禦性編碼。
並行性與擴充限制
需要提出的問題：
- 每個帳戶的預設和最大並行沙箱限制是多少？
- 並行執行是硬性限制（超過限制的請求失敗）還是軟性限制（請求排隊）？
- 是否有按區域或按資料中心的並行上限？
- 是否有每個使用者的沙箱隔離模型，還是所有沙箱共享帳戶級別的限制？
- 當你從 0 個並行沙箱激增到 100 個時，爆發行為是什麼？
該留意什麼： 評估工作負載、RL 環境和多租戶編碼平台都需要高並行數。一個免費層限制在 5 或 10 個並行沙箱的供應商可用於原型設計，但無法用於有 50–100 個平行試驗的生產 RL 運行。
帳戶 vs. 組織限制： 有些供應商按 API 金鑰強制限制，並允許每個組織使用多個金鑰。其他供應商則不論金鑰數量，都在組織層級強制限制。對於高並行工作負載，這個區別會影響你如何組織你的生產帳戶。
可觀測性與日誌記錄
需要提出的問題：
- 供應商暴露哪些執行日誌：stdout、stderr、系統事件、網路流量？
- 日誌是即時串流，還是僅在執行完成後可用？
- 日誌保留多久？
- 是否有結構化日誌 API（JSON、可搜尋欄位）還是只有純文字？
- 你可以附加自己的可觀測性堆疊（OpenTelemetry、Datadog、Splunk）嗎？
該留意什麼： 為了在生產環境中除錯代理失敗，你需要知道運行了什麼程式碼、它輸出了什麼、建立了哪些檔案、以及進行了哪些網路呼叫。只暴露 stdout/stderr 而沒有其他資訊的供應商會使根本原因分析變得很慢。
稽核軌跡要求： 如果你的使用案例涉及受監管資料或合規要求，請詢問供應商是否可以產生帶有時間戳記的所有執行事件的稽核日誌。純文字 stdout 不是稽核軌跡。
遷移路徑與工作量
在承諾遷移之前，請根據以下面向來評估實際工作量：
SDK 層： 如果目標供應商有官方 SDK 且方法名稱相似，那麼應用程式層面的變更可能僅限於初始化、驗證和少量方法簽章。如果目標只提供 REST API，你將需要編寫一個適配器層。
工作階段與狀態模型： 如果你目前的供應商有暫停/恢復功能，而目標沒有，你將需要重新設計你的代理處理多輪次狀態的方式。這很少是一個小變更。
套件環境： 如果你目前的供應商使用帶有預先安裝套件的自訂基礎映像，在新的供應商上重建該環境需要時間和測試。
測試： 任何沙箱遷移都應包括一個整合測試套件，該套件在切換生產流量之前，在目標供應商上端到端地運行你的實際代理工作負載。模擬沙箱的單元測試是不夠的——行為差異恰恰發生在真實的執行環境中。
一個粗略的工作量信號： 如果目標供應商有封裝相同基本操作（建立、執行程式碼、列出檔案、下載檔案、終止）的 SDK，並且你的工作階段模型是每輪次無狀態的，那麼遷移通常需要 1–2 天。如果你依賴暫停/恢復、自訂基礎映像或特定的串流輸出行為，請預留一週或更多時間進行設計、實作和測試。
定價模型差異
沙箱定價模型差異很大，正確的模型取決於你的工作負載形狀。
常見的定價面向：
| 面向 | 影響對象 |
|---|---|
| 按秒計費 | 工作階段短且閒置時間低的工作負載 |
| 按分鐘計費 | 小計費增量不太重要的工作負載 |
| 訂閱底層 | 無論使用量如何的固定每月成本 |
| vCPU + 記憶體計費 | 可自訂資源分配；你為自己配置的內容付費 |
| 按執行次數固定計費 | 對統一任務大小有可預測的成本 |
需要提出的問題：
- 計費是基於使用量（按活躍沙箱時間的秒/分鐘計算）還是訂閱制（每月最低費用）？
- vCPU 和記憶體是獨立計費，還是計費與固定層級掛鉤？
- 什麼算是計費秒——工作階段建立時間、活躍程式碼執行時間，還是工作階段的總掛鐘時間？
- 是否有免費層，其對你的工作負載類型的限制是什麼？
- 冷啟動工作階段和預熱工作階段之間是否有成本差異？
定價在實務中如何產生分歧： 一個從工作階段建立到終止期間（無論程式碼是否在活躍運行）都在收費的供應商，對於代理輪次之間有長時間閒置的工作負載會更昂貴。一個只在活躍執行期間計費的供應商對於這些工作負載更便宜，但可能在你需要的資源層級中不存在。
對於高並行 RL 或評估工作負載，每千次執行的成本通常比每秒費率更重要。在選擇供應商之前，請根據實際的每月運行次數進行計算。
Novita Agent Sandbox 適配度
Novita Agent Sandbox 是這份檢查清單主要針對的遷移目標之一。它針對程式碼代理、瀏覽器代理、資料分析、評估和 RL 工作負載。對於正在使用這份檢查清單的團隊，以下是 Novita 的適配點以及可能存在的差距：
SDK 和 API： Novita 提供 Python SDK 和 REST API，用於沙箱建立、程式碼執行、檔案系統操作和程序管理。從 E2B 風格工作流程遷移的團隊會發現熟悉的基本操作。請針對你的目標 SDK 版本，根據 Novita Sandbox 文件 驗證特定方法名稱。
工作階段生命週期： Novita 支援最長 24 小時的工作階段、暫停/恢復以及閒置工作階段的自動暫停/自動恢復。對於需要在 LLM 呼叫之間保留工作階段內狀態的多輪次程式碼代理而言，這與限制 60 分鐘的供應商相比是一個有意義的操作差異。
並行性： Novita 的基本層支援 50 個並行沙箱，且無需訂閱費用。對於需要更高並行性的評估或 RL 工作負載，請聯絡 Novita 以獲得企業層級。
定價模型： Novita 按實際 vCPU 和記憶體的每秒計費，沒有最低訂閱費用。對於使用模式可變或突發的工作負載，無底層的按使用量計費通常比基於訂閱的替代方案更便宜。在進行成本預測之前，請在 Novita AI 定價頁面 驗證當前費率。
BYOC 部署： Novita 支援在你自己的 AWS 或 GCP VPC 內運行沙箱。對於有嚴格網路隔離要求的團隊，這避免了多租戶公共雲模型。
需要仔細驗證的地方： E2B API/SDK 相容性、無痛替代保證以及特定功能對等性取決於持續開發。在沒有針對 Novita 當前 SDK 測試你特定工作負載模式的情況下，不要假設完全相容。建議在發布任何相容性聲明之前進行產品審查。
Novita 可能不適用的地方： 對 E2B 特定 SDK 抽象有深度投資的團隊、需要 GPU 沙箱支援的團隊，或需要在 AWS/GCP 之外進行本地部署的團隊，應在遷移前仔細評估適配度。
常見問題
Novita Agent Sandbox 是 E2B 的無痛替代品嗎？
並非如此。在將任何供應商視為無痛替代品之前，都需要根據你的特定工作負載測試 SDK 方法名稱、工作階段生命週期行為、串流輸出結構和套件安裝持久性。使用本指南中的檢查清單明確驗證每個面向。
從 E2B 遷移到不同的沙箱供應商最少需要多少工作量？
如果目標供應商有具有類似基本操作（建立、執行程式碼、檔案操作、終止）的官方 SDK，並且你的工作階段模型是每輪次無狀態的，那麼遷移通常需要 1–2 天，涵蓋 SDK 初始化、驗證和少量方法簽章。如果你依賴暫停/恢復、自訂基礎映像或特定的串流輸出行為，請預留一週或更多時間。
Novita Agent Sandbox 支援暫停和恢復嗎？
是的。Novita 支援閒置工作階段的暫停/恢復和自動暫停/自動恢復，工作階段長度最長可達 24 小時。這對於需要在 LLM 呼叫之間保留工作階段內狀態的多輪次程式碼代理非常重要。請針對你的 SDK 版本，根據 Novita Sandbox 文件 驗證當前行為。
如何測試目標沙箱供應商是否與我的應用程式相容？
在切換生產流量之前，在目標供應商的暫存環境中端到端地運行你的實際代理工作負載。測試你的應用程式呼叫的特定 SDK 方法、你的解析器期望的串流輸出結構、跨工具呼叫的套件安裝持久性以及檔案回圈（上傳、轉換、下載）。模擬沙箱的單元測試是不夠的——相容性差異只會在真實執行中出現。
Novita 是否支援在私有雲帳戶中運行沙箱？
是的。Novita 支援在你自己的 AWS 或 GCP VPC 內的 BYOC（自帶雲）部署。對於有嚴格網路隔離、資料駐留或合規要求的團隊，這避免了多租戶公共雲模型。請聯絡 Novita 以獲得當前的 BYOC 可用性和配置選項。
