<!-- title: 六大Agent沙箱引擎：隔离·持久·极速三栈实测 -->

# 六大Agent沙箱引擎：隔离·持久·极速三栈实测

## 概述

当自主Agent开始在生产环境执行任意代码，"代码跑在哪里"从工程细节升格为架构决策。2026年Agent沙箱市场爆发至14家供应商，形成三种技术路线的激烈交锋：Firecracker microVM的硬件级隔离、Docker容器的极速启动、以及copy-on-write快照的亚毫秒派生。E2B凭2亿+沙箱启动量占据临时执行王座；Sprites.dev以检查点/回滚重新定义持久化；Zeroboot用0.79ms的派生速度将启动延迟压缩至极限；Microsandbox在网络层拦截密钥注入，开创"本地优先"安全范式；Daytona借Computer Use把沙箱变成虚拟桌面；阿里OpenSandbox则以协议驱动+K8s原生瞄准企业级规模化部署。本文从隔离深度、启动延迟、持久化能力、GPU支持、成本模型五个维度，深度拆解六大沙箱引擎的真实表现与选型逻辑。

## 六大沙箱引擎全景对比

| 维度 | E2B | Daytona | Zeroboot | Microsandbox | Sprites.dev | OpenSandbox |
|------|-----|---------|----------|--------------|-------------|-------------|
| **隔离技术** | Firecracker microVM | Docker容器 | Firecracker CoW快照 | libkrun microVM | Firecracker microVM | Docker/K8s容器 |
| **隔离级别** | 硬件级（独立内核） | 进程级（共享内核） | 硬件级（独立KVM VM） | 硬件级（KVM/HVF） | 硬件级（独立内核） | 进程级（可配置） |
| **冷启动延迟** | ~150ms | 27-90ms | **0.79ms** | ~187ms | 1-12s | 数秒级 |
| **p99延迟** | ~300ms | ~90ms | 1.74ms | ~300ms | - | - |
| **会话持久化** | 无（临时） | 有（长期） | 无（临时） | 有（可拆离） | 有（检查点/回滚） | 可配置 |
| **检查点** | 不支持 | 不支持 | 不支持 | 不支持 | 支持（~300ms） | 不支持 |
| **GPU支持** | 无 | 无 | 无 | 无 | 无 | 无 |
| **单沙箱内存** | ~128MB | ~50MB | **~265KB** | ~50MB | 可配至16GB | 可配置 |
| **网络能力** | 受限出站 | 完整网络 | 仅串口I/O | 可编程网络策略 | 独立URL+HTTP访问 | K8s网络策略 |
| **部署模型** | 仅托管 | 托管/自托管 | 托管/自托管 | 仅本地 | 仅托管 | 自托管(K8s) |
| **BYOC** | 否 | 否 | 否 | N/A | 否 | 是（原生K8s） |
| **Star数** | ~6K | ~15K | ~2.3K | ~6.2K | N/A | ~3K |
| **SDK语言** | Python/JS/Go | Python/TS | Python/TS | Rust/Python/TS/Go | JS/Go/CLI | 多语言SDK |
| **开源协议** | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 | 闭源 | Apache 2.0 |
| **免费额度** | 有 | 有 | 有demo key | 免费（自托管） | $30试用额度 | 免费（自托管） |

## 深度分析

### 一、E2B：临时执行的绝对王者

E2B是Agent沙箱赛道中体量最大的玩家——超过2亿沙箱启动量、88%的财富100强采用率、100万+月SDK下载量。它的核心哲学极其清晰：每次代码执行都是一次性的，执行完即销毁，不留痕迹。

架构上，E2B使用Firecracker microVM——与AWS Lambda相同的虚拟化技术。每次沙箱启动都获得一个独立的Linux内核，这意味着即使Agent生成了恶意代码试图进行容器逃逸，硬件虚拟化层也会将攻击限制在单个microVM内。这种隔离深度满足了金融、医疗等合规要求最严格的行业需求。

```python
from e2b_code_interpreter import Sandbox

# 创建临时沙箱
sbx = Sandbox(timeout=300)

# Agent生成的任意代码安全执行
execution = sbx.run_code("""
import pandas as pd
df = pd.read_csv("https://example.com/data.csv")
print(df.describe())
""")

# 获取执行结果
print(execution.stdout)
print(execution.error)  # 错误也被安全捕获

# 沙箱自动销毁，无残留
sbx.close()
```

E2B的短板恰恰是其优势的另一面。由于是临时执行模型，Agent无法跨会话保持状态——已安装的包、生成的文件、环境配置全部在会话结束后消失。对于需要多轮迭代、逐步构建环境的Agent（如Claude Code这类编程助手），这意味着每次对话都需要重新配置。150ms的冷启动对于ChatGPT Code Interpreter这类场景已经足够，但在需要每秒创建数百个沙箱的高频场景下，延迟开始累积。

成本模型方面，E2B采用按秒计费，配合自定义模板功能可以预装常用依赖减少冷启动后的安装时间。对于"执行-返回-销毁"这种无状态代码运行模式，E2B仍是第一选择。

**变现评估**：E2B的SDK质量和文档完整度使其成为训练营的理想教材。围绕"E2B + LangChain构建安全代码执行Agent"的课程包有明确市场。

### 二、Zeroboot：亚毫秒派生的极限工程

Zeroboot是目前Agent沙箱领域最激进的性能优化实验。它通过copy-on-write（CoW）内存分叉技术，将沙箱启动延迟压缩到了0.79ms——比E2B快190倍，比Daytona快34倍。

核心原理是三步走。第一步，模板准备：启动一个完整的Firecracker VM，预加载运行时（Python、Node.js等），对内存和CPU状态做快照。第二步，派生：通过`mmap(MAP_PRIVATE)`将快照内存映射为CoW，创建新的KVM VM并恢复CPU状态——这个过程仅需0.8ms。第三步，隔离：每个派生实例是一个独立的KVM虚拟机，拥有硬件强制内存隔离。

```bash
# Zeroboot API调用——亚毫秒级沙箱启动
curl -X POST https://api.zeroboot.dev/v1/exec \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer zb_demo_hn2026' \
  -d '{"code":"import numpy as np; print(np.random.rand(3))"}'
```

```python
from zeroboot import Sandbox

# 每个沙箱仅占265KB内存
sb = Sandbox("zb_live_your_key")
result = sb.run("import numpy as np; print(np.random.rand(3))")
```

性能数据令人印象深刻：1000个并发派生仅需815ms，单个沙箱内存占用仅265KB（对比E2B的128MB）。这意味着同一台物理机上可以运行数千个并发沙箱，密度提升近500倍。

但Zeroboot的限制同样显著：每个派生仅支持单vCPU；沙箱内没有网络能力，只能通过串口I/O通信；派生实例共享快照的CSPRNG状态，需要手动重置随机数种子；模板更新需要完整重新快照（~15秒），不支持增量修补。它目前仍是工作原型，尚未达到生产级别。

**变现评估**：Zeroboot的技术前卫性使其成为技术大会演讲和深度技术文章的绝佳素材。但作为训练营内容，需要等待其API更成熟稳定后才有教学价值。

### 三、Microsandbox：本地优先的安全革命

Microsandbox（ZeroCore AI，YC X26批次）在沙箱赛道中走出了一条独特的"本地优先"路线。它是目前唯一一个主要运行在本地的microVM沙箱平台，6.2K GitHub Star证明了开发者对这一方向的认可。

其杀手级特性是网络层密钥注入。传统沙箱需要将API密钥传入沙箱内部，这创建了一个根本性风险——恶意代码可以在沙箱内读取并外泄这些密钥。Microsandbox的做法完全不同：沙箱只看到占位符，真实的密钥仅在宿主机的网络层对已验证的TLS连接到允许的域名时才进行替换。这意味着即使沙箱内的代码尝试将环境变量写入文件或发送到外部服务器，它只能得到无意义的占位符。

```rust
// Rust SDK - 直接在代码中启动microVM
use microsandbox::Sandbox;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let sandbox = Sandbox::builder("my-sandbox")
        .image("python")
        .cpus(1)
        .memory(512)
        .create()
        .await?;
    
    // 安全执行Agent生成的代码
    let output = sandbox
        .exec("python", ["-c", "print('Hello from microVM!')"])
        .await?;
    
    println!("{}", output.stdout()?);
    sandbox.stop_and_wait().await?;
    Ok(())
}
```

```python
# Python SDK
import asyncio
from microsandbox import Sandbox

async def main():
    sandbox = await Sandbox.create(
        name="agent-workspace",
        image="python:3.12",
        memory_mb=512
    )
    
    # 密钥在网络层透明替换，沙箱内不可见
    result = await sandbox.exec(
        "curl -H 'Authorization: Bearer $API_KEY' https://api.example.com/data"
    )
    # $API_KEY 在沙箱内是占位符，实际请求由宿主机网络层注入真值
    
    await sandbox.stop()
```

技术实现上，Microsandbox使用libkrun作为虚拟化后端，支持Linux（KVM）和macOS（Apple Silicon，HVF）。它还内置了MCP服务器，可以直接被Claude Code、Cursor等AI编程工具调用，实现"Agent自己创建沙箱"的自主能力。可编程网络策略包括DNS检查、HTTP拦截、域名白名单和数据防泄漏（DLP）。

当前的限制在于：仍处于Beta阶段，API可能有Breaking Changes；仅支持macOS（Apple Silicon）和Linux；云托管版本尚未上线；不支持Windows。

**变现评估**：密钥安全是Enterprise客户的刚需。围绕"Microsandbox + AI Agent安全执行"的企业级培训有清晰的商业路径，尤其适合金融、医疗等强合规行业。

### 四、Sprites.dev：持久化的范式转移

Fly.io旗下的Sprites.dev代表了对"临时沙箱"范式的根本性质疑。当一个编程Agent需要跨越数十次交互来重构一个大型代码库时，临时执行模型意味着每次都需要重新安装依赖、重新加载项目文件——这是巨大的浪费。

Sprites的核心是持久化VM + 检查点/回滚。每个Sprite是一个真正的Linux计算机，拥有100GB持久化ext4文件系统，由对象存储支撑。空闲时自动休眠不收费，唤醒时数据完整保留。检查点功能约300ms完成，使用CoW只复制变更块，恢复时将一切放回原位。

```javascript
// Sprites JavaScript SDK
import { SpritesClient } from '@fly/sprites';

const client = new SpritesClient(process.env.SPRITES_TOKEN);

// 创建持久化沙箱
const sprite = client.sprite('my-agent-workspace');

// 第一轮：安装依赖
await sprite.exec('pip install pandas numpy scikit-learn');

// 检查点：保存当前状态
await sprite.checkpoint('deps-installed');

// 第二轮：运行分析
const { stdout } = await sprite.exec('python analyze.py');
console.log(stdout);

// 如果出错，回滚到检查点
await sprite.restore('deps-installed');

// 每个Sprite有独立URL，可对外提供HTTP服务
await sprite.exec('python -m http.server 8080');
```

```bash
# CLI操作
sprite create my-sprite
sprite exec -s my-sprite "pip install -r requirements.txt"
sprite console -s my-sprite  # 进入交互式终端
sprite checkpoint -s my-sprite -n "before-refactor"
sprite restore -s my-sprite -n "before-refactor"  # 回滚
```

成本模型极其透明：$0.07/CPU小时，$0.04375/GB小时内存。一个4小时的Claude Code会话约$0.44。$30试用额度可创建约500个Sprite。空闲期间不收费，仅在分配计算资源时计费。

关键差异化功能是Sprite URL。每个Sprite有独立的外部可访问URL，请求自动路由到port 8080。这意味着Agent可以在沙箱内启动Web服务器、接收Webhook、甚至对外提供完整的Web应用。

**变现评估**：Sprites的持久化+检查点模型特别适合编程Agent训练营。"从零搭建持久化编程Agent"的课程路径清晰，且实际使用成本低（$0.44/4小时会话）。

### 五、Daytona：Computer Use的破局者

Daytona在2026年2月完成2400万美元A轮融资，其差异化在于将沙箱从"代码执行容器"升级为"Agent的完整计算机"。27-90ms的沙箱创建速度是容器方案的优势，但真正的杀手级功能是Computer Use——Agent可以程序化控制Linux/Windows/macOS虚拟桌面。

```python
# Daytona沙箱创建
from daytona import Daytona

daytona = Daytona()
sandbox = daytona.create()

# Agent在沙箱中执行代码
response = sandbox.process.code_run('print("Hello from Daytona!")')
print(response.result)

# Computer Use - Agent控制虚拟桌面
desktop = sandbox.desktop
screenshot = desktop.screenshot()  # 截取桌面
desktop.click(x=500, y=300)       # 点击操作
desktop.type_text("Hello World")  # 键入文本

# 持久化工作空间
sandbox.files.upload("/app/config.yaml", config_content)
# 下次连接同一沙箱，文件仍然存在
```

Computer Use的能力使Daytona成为浏览器自动化、桌面应用测试、UI验证等场景的唯一选择。当Agent需要与图形界面交互而非仅执行命令行代码时，Daytona提供了从OpenAI Cookbook到实际生产的完整路径。

Daytona同时支持托管和自托管部署，这对企业客户极具吸引力——敏感代码可以留在自己的基础设施上运行。开源Apache 2.0协议降低了采用门槛。

**变现评估**：Computer Use + 沙箱是浏览器自动化测试领域的颠覆性组合。围绕"Daytona + Playwright构建自主UI测试Agent"的课程有强烈的市场需求。

### 六、OpenSandbox：阿里出品的协议驱动派

2026年3月1日，阿里开源了OpenSandbox，以"协议驱动"为核心理念，试图用统一的API协议标准化Agent沙箱交互。不同于其他平台各自为政的SDK设计，OpenSandbox定义了一套跨语言的标准交互协议，并通过多语言SDK（Java、Python、Go、C++）实现协议的一致性表达。

```yaml
# OpenSandbox协议定义示例
apiVersion: sandbox.alibaba.com/v1
kind: SandboxTemplate
spec:
  runtime: docker  # 或 kata-containers
  image: python:3.12-slim
  resources:
    cpu: "2"
    memory: "4Gi"
  network:
    egress: allow-specific
    allowedHosts:
      - api.openai.com
      - pypi.org
  security:
    readOnlyRootFS: true
    dropCapabilities: ["ALL"]
    seccompProfile: runtime/default
```

```java
// Java SDK - K8s原生部署
OpenSandbox sandbox = OpenSandbox.builder()
    .template("python-agent")
    .namespace("production")
    .kubernetesClient(k8sClient)  // 直接使用K8s客户端
    .build();

SandboxSession session = sandbox.create();
ExecutionResult result = session.execute("python train_model.py");
```

OpenSandbox的架构深植于Kubernetes生态。它不试图替代K8s的调度和编排能力，而是在K8s之上提供Agent沙箱的语义层。这意味着企业可以直接将OpenSandbox部署到现有K8s集群中，利用已有的网络策略、资源配额、监控体系。支持Docker和Kata Containers两种运行时，可根据安全需求在容器隔离和microVM隔离之间切换。

协议驱动的价值在于生态互通。当不同Agent框架（LangChain、CrewAI、AutoGen等）都遵循同一套沙箱交互协议时，沙箱变成了可替换的基础设施组件，而非被SDK锁定的平台服务。

**变现评估**：OpenSandbox对企业K8s用户是零摩擦的切入。在阿里云生态内推广的潜力巨大，适合作为企业内部Agent基础设施标准化的培训内容。

## 架构全景：六大沙箱的隔离层次

```mermaid
graph TB
    subgraph "硬件虚拟化层（最强隔离）"
        ZB["Zeroboot<br/>Firecracker CoW<br/>0.79ms派生"]
        E2B["E2B<br/>Firecracker microVM<br/>150ms启动"]
        SP["Sprites.dev<br/>Firecracker microVM<br/>1-12s启动 + 检查点"]
        MS["Microsandbox<br/>libkrun microVM<br/>187ms本地启动"]
    end

    subgraph "容器隔离层（最快启动）"
        DAY["Daytona<br/>Docker容器<br/>27-90ms创建<br/>+Computer Use"]
        OS["OpenSandbox<br/>Docker/Kata<br/>K8s原生编排"]
    end

    subgraph "持久化能力谱"
        EPHE["临时型<br/>E2B·Zeroboot"]
        PERS["持久型<br/>Daytona·Sprites·Microsandbox"]
        CONF["可配置<br/>OpenSandbox"]
    end

    subgraph "部署模型"
        CLOUD["纯托管<br/>E2B·Sprites"]
        HYBRID["托管+自托管<br/>Daytona·Zeroboot"]
        LOCAL["本地优先<br/>Microsandbox"]
        SELF["纯自托管<br/>OpenSandbox·AIO Sandbox"]
    end

    ZB --> EPHE
    E2B --> EPHE
    SP --> PERS
    DAY --> PERS
    MS --> PERS
    OS --> CONF

    E2B --> CLOUD
    SP --> CLOUD
    DAY --> HYBRID
    ZB --> HYBRID
    MS --> LOCAL
    OS --> SELF
```

## 沙箱选型决策矩阵

```mermaid
flowchart TD
    START[Agent需要执行代码] --> Q1{需要跨会话<br/>保持状态？}

    Q1 -->|否| Q2{延迟要求？}
    Q1 -->|是| Q3{需要检查点<br/>回滚能力？}

    Q2 -->|亚毫秒级| ZB[Zeroboot<br/>0.79ms CoW派生]
    Q2 -->|<100ms| Q2A{合规要求<br/>独立内核？}
    Q2 -->|<200ms可接受| E2B[E2B<br/>Firecracker 150ms]

    Q2A -->|是| E2B
    Q2A -->|否| DAY_SPEED[Daytona<br/>Docker 27ms]

    Q3 -->|是| SPRITES[Sprites.dev<br/>300ms检查点/回滚]
    Q3 -->|否| Q4{需要Computer Use<br/>桌面控制？}

    Q4 -->|是| DAY_CU[Daytona<br/>Computer Use沙箱]
    Q4 -->|否| Q5{必须本地运行？}

    Q5 -->|是| MSB[Microsandbox<br/>本地microVM + 密钥安全]
    Q5 -->|否| Q6{已有K8s集群？}

    Q6 -->|是| OSBOX[OpenSandbox<br/>K8s原生 + 协议驱动]
    Q6 -->|否| SPRITES2[Sprites.dev<br/>托管持久化]

    style ZB fill:#ff6b6b,color:#fff
    style E2B fill:#4ecdc4,color:#fff
    style DAY_SPEED fill:#45b7d1,color:#fff
    style DAY_CU fill:#45b7d1,color:#fff
    style SPRITES fill:#96ceb4,color:#fff
    style MSB fill:#feca57,color:#333
    style OSBOX fill:#ff9ff3,color:#333
```

## 成本实测对比

以"编程Agent运行4小时会话"为基准：

| 成本项 | E2B | Daytona | Sprites.dev | Microsandbox |
|--------|-----|---------|-------------|--------------|
| 计算资源 | ~$2.40 | ~$1.60 | ~$0.44 | 免费（本地） |
| 存储 | 包含 | 包含 | 按块计费 | 本地磁盘 |
| 网络出站 | 含 | 含 | 含 | N/A |
| 空闲费用 | 无 | 无 | **无（自动休眠）** | 无 |
| 100次检查点 | N/A | N/A | ~$0.01增量 | N/A |

关键发现：对于长时间运行的编程Agent，Sprites.dev的自动休眠+持久化模型将成本压缩至E2B的1/5。而Microsandbox作为本地方案，直接消除了基础设施成本，但需要自备硬件。

## 三大技术路线的本质分歧

Agent沙箱市场正在形成三个清晰的技术阵营，每个阵营背后是不同的安全哲学和使用场景假设。

**临时派（Ephemeral-first）**以E2B和Zeroboot为代表，认为每次Agent执行都应该是无状态的原子操作。优势是安全性最大化——没有持久状态意味着没有持久攻击面。劣势是无法支持需要多轮迭代的复杂Agent任务。适合评估管道、代码面试、单次数据分析等场景。

**持久派（Persistent-first）**以Sprites.dev和Daytona为代表，认为Agent需要像人类开发者一样拥有自己的工作空间。优势是状态连续性，Agent可以在之前的基础上继续工作。劣势是安全面扩大——持久化的文件和依赖可能成为攻击向量。适合编程助手、长期项目维护、自动化运维等场景。

**本地派（Local-first）**以Microsandbox为代表，认为代码永远不应该离开开发者的机器。优势是数据主权和密钥安全。劣势是可扩展性受限，无法支持需要大规模并发的生产场景。适合安全敏感型企业、本地开发工具、离线环境等场景。

```mermaid
graph LR
    subgraph "临时派 Ephemeral"
        E2B_F["E2B<br/>Firecracker<br/>200M+沙箱"]
        ZB_F["Zeroboot<br/>CoW派生<br/>亚毫秒"]
    end

    subgraph "持久派 Persistent"
        SP_F["Sprites.dev<br/>检查点/回滚<br/>100GB ext4"]
        DAY_F["Daytona<br/>Computer Use<br/>虚拟桌面"]
    end

    subgraph "本地派 Local"
        MS_F["Microsandbox<br/>密钥安全<br/>libkrun"]
        AIO_F["AIO Sandbox<br/>全家桶<br/>Docker"]
    end

    subgraph "企业派 Enterprise"
        OS_F["OpenSandbox<br/>协议驱动<br/>K8s原生"]
    end

    E2B_F -.->|安全最大化| SEC["高安全场景"]
    ZB_F -.->|极速迭代| PERF["高频调用"]
    SP_F -.->|状态连续| DEV["编程Agent"]
    DAY_F -.->|桌面控制| UI["UI自动化"]
    MS_F -.->|数据不出域| ENT["企业合规"]
    OS_F -.->|标准化| STD["规模化部署"]
```

## 训练营/产品化推荐矩阵

| 方向 | 推荐引擎 | 理由 | 目标人群 | 定价区间 |
|------|---------|------|---------|---------|
| AI编程助手构建 | Sprites.dev | 持久化+检查点完美匹配 | 全栈开发者 | ¥299-599 |
| 安全代码执行 | E2B | SDK最成熟，文档最全 | 后端工程师 | ¥399-699 |
| 浏览器自动化Agent | Daytona | Computer Use独一无二 | QA/测试工程师 | ¥499-899 |
| 企业安全部署 | Microsandbox | 密钥不外泄是杀手级卖点 | 安全工程师 | ¥699-1299 |
| 高频评估管道 | Zeroboot | 亚毫秒启动碾压级优势 | ML工程师 | ¥299-499 |
| K8s生态集成 | OpenSandbox | 协议驱动零摩擦 | 平台工程师 | ¥499-899 |

## 未来六个月趋势预判

**检查点将成为标配**。Sprites.dev的检查点/回滚功能已经证明了价值。预计到2027年，E2B和Daytona都会加入类似功能，可能基于Firecracker的快照能力实现。

**Computer Use将变为基础设施**。Daytona目前的独占优势不会持续太久。当浏览器自动化成为Agent的标配能力时，所有沙箱平台都需要支持虚拟桌面。

**本地优先的云扩展**。Microsandbox正在构建云托管版本，这将打破"本地vs云端"的二元对立——开发者可以在本地开发时使用microVM的密钥安全，生产环境无缝迁移到云。

**协议统一势在必行**。OpenSandbox的协议驱动思路将被更多平台采纳。当Agent框架需要支持多个沙箱后端时，统一的交互协议比SDK级别的适配更可持续。

**密钥安全将成硬需求**。Microsoft 2026年5月发布的研究揭示了Agent框架中Prompt注入导致RCE的漏洞路径。当Agent可以执行任意代码时，沙箱内密钥的外泄风险不再是理论问题，Microsandbox的网络层注入方案将成为行业标准。

## 参考来源

1. [AI Agent Sandboxes Compared — Ry Walker Research](https://rywalker.com/research/ai-agent-sandboxes) — 14家沙箱平台对比研究，2026年3月
2. [Daytona vs E2B in 2026 — Northflank Blog](https://northflank.com/blog/daytona-vs-e2b-ai-code-execution-sandboxes) — Daytona与E2B架构对比深度分析
3. [E2B, Daytona, Modal, and Sprites.dev — SoftwareSeni](https://www.softwareseni.com/e2b-daytona-modal-and-sprites-dev-choosing-the-right-ai-agent-sandbox-platform/) — 四大沙箱平台选型指南
4. [Zeroboot — GitHub](https://github.com/zerobootdev/zeroboot) — 亚毫秒VM沙箱，Firecracker CoW派生
5. [Microsandbox — GitHub](https://github.com/superradcompany/microsandbox) — 本地优先microVM沙箱，6.2K Star
6. [Alibaba OpenSandbox — GitHub](https://github.com/alibaba/OpenSandbox) — 阿里开源协议驱动沙箱平台
7. [Sprites.dev — Fly.io](https://sprites.dev/) — 持久化VM沙箱，检查点/回滚

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)