第六章 · E2B——沙箱即服务的「标准化者」

这章为谁设计

你想理解「E2B SDK 为什么成为事实标准」，以及 CubeSandbox 兼容它意味着什么。

一句话定位

开源但以云服务为核心的 AI 代码沙箱平台，定义了「AI Agent 代码执行 SDK」的接口标准。Perplexity 和 Manus 在用它。

日常类比

E2B 像一个网约车平台（Uber）：

你不需要买车（自己搭 Firecracker）
你不需要考驾照（学 KVM 虚拟化）
你只需要打开 App、输入目的地、确认叫车
车到了你上车，到了目的地下车付钱

翻译成技术语言：

from e2b import Sandbox
with Sandbox.create() as sandbox:           # 叫车（创建沙箱）
    result = sandbox.commands.run('echo hi') # 坐车（执行代码）
# 自动下车（沙箱销毁）

三行代码，背后是一个完整的 KVM microVM 生命周期管理。

类比边界：Uber 的车是物理的（数量有限），E2B 的沙箱是虚拟的（按需创建）。但 E2B 也有类似 Uber 的商业模式——免费试用有额度限制，大规模使用需要付费。

E2B 做了什么：三层架构

┌─────────────────────────────────────────┐
│  SDK 层（开源，你安装的 pip/npm 包）     │
│  from e2b import Sandbox               │
├─────────────────────────────────────────┤
│  API 层（60+ REST 端点）                │
│  生命周期 / 命令 / 文件 / 快照 / 网络  │
├─────────────────────────────────────────┤
│  基础设施层（不公开）                   │
│  Firecracker + AWS + Terraform          │
└─────────────────────────────────────────┘

你能看到的是 SDK 层——几行代码就能用。你看不到的是底层的 Firecracker VM、AWS 基础设施、计费系统。

E2B SDK 的完整 API 面

E2B 定义了一套被市场接受的接口标准。理解这套接口，就理解了 CubeSandbox 在兼容什么：

生命周期管理：

Sandbox.create() — 创建沙箱
sandbox.kill() — 销毁沙箱
sandbox.pause() / sandbox.resume() — 暂停/恢复
sandbox.set_timeout() — 设置超时自动销毁

代码执行：

sandbox.commands.run('python script.py') — 运行命令
sandbox.run_code('print(1+1)') — 代码解释器模式（像 Jupyter）

文件系统：

sandbox.files.read('/path') — 读文件
sandbox.files.write('/path', content) — 写文件
sandbox.files.list('/dir') — 列目录

快照：

sandbox.create_snapshot() — 保存当前状态
Sandbox.create(snapshot_id=...) — 从快照恢复

网络策略：

allow_out / deny_out — 出站域名/IP 白名单/黑名单
allow_internet_access — 总开关

为什么 E2B SDK 成为事实标准

一个 API 标准能被市场接受，通常满足三个条件：

足够简单：三行代码完成「创建 → 执行 → 销毁」
足够完整：生命周期 + 文件 + 命令 + 快照 + 网络，Agent 场景需要的全覆盖
有真实大客户在用：Perplexity、Manus 等产品验证了这套接口的可用性

所以 CubeSandbox 选择兼容 E2B SDK 是一个聪明的市场策略——不重新定义标准，而是让已有的 E2B 用户零改动切换。

E2B 的「开放核心」商业模式

Open Core：核心代码开源，但某些关键能力（通常是运维、规模化、企业功能）收费。类比：软件本体免费下载，但云端同步、团队协作需要订阅。

E2B 的开源部分：SDK 代码、API 规范、自托管指南（Terraform）。 E2B 的收费部分：API Key（按调用量计费）、云端运维、SLA 保障。

对你意味着什么：

小规模试用 E2B 是免费的
大规模生产使用需要付费
如果你想免费 + 大规模 → 用 CubeSandbox 自托管（API 兼容）

E2B 的局限

云端锁定：只支持 AWS 和 GCP（因为底层是 Firecracker，需要 KVM）
无 Azure 支持：Azure 的嵌套虚拟化限制导致 KVM 不可用
自托管复杂：虽然有 Terraform 指南，但实际部署需要 KVM/网络/存储专业知识
API 不稳定风险：E2B 是商业产品，接口可能随时变更

一个从 CLAUDE.md 发现的秘密

E2B 的 CLAUDE.md（给 AI Agent 的配置文件）有一条关键约束：

“Equivalent changes are applied to both JS as well as sync and async Python implementations.”

E2B 同时维护 3 个 SDK 实现（JavaScript / Python 同步 / Python 异步），任何 API 变更必须三个都同步。这是一个显著的隐性维护成本——CubeSandbox 选择兼容 E2B SDK 时，也需要意识到这个「跟随成本」。

读完这章你应该能回答

E2B 和 Firecracker 的关系是什么？（E2B 是 Firecracker 的最佳客户——底层用 Firecracker，上层加 SDK + 计费）
E2B SDK 的核心 API 有哪些？（create/kill/commands.run/files/snapshot）
为什么 CubeSandbox 选择兼容 E2B 而不是自己定义接口？（借力已有的市场标准，降低用户切换成本）
E2B 的 Open Core 模式意味着什么？（SDK 免费，大规模使用付费，替代方案是 CubeSandbox 自托管）

导读目录：README.md 上一章：第五章 · CubeSandbox——为 AI Agent 而生的「最后一公里」下一章：第七章 · Daytona——星数最高的 AI 沙箱平台