CubeSandbox 与 E2B：生产环境智能体对比

我是 Dora。最近，我们有一个 agent 在生产环境中进行工具调用。编排器没问题，LLM 也没问题，瓶颈在于沙箱层——每次 agent 需要运行一段生成的代码时，我们就要承受 200ms 的冷启动延迟，有时更长，有时队列会变得很奇怪。每个会话大约 40 次工具调用，这些延迟累积起来就是一大块墙钟时间。

于是我开始研究替代方案。目前大家都在做的对比是 CubeSandbox vs E2B。这篇文章是我花了两周时间阅读这两个项目、部署其中一个、以及无法部署另一个（后面会讲到）之后的总结。

先说明：我与这两个项目都没有商业关系。两者都是开源的。下面的讨论是托管与自托管之间的权衡，而不是”好人/坏人”的对立。

CubeSandbox vs E2B 一览

两个项目解决的是同一个问题，方式也大致相同：启动一个 microVM，运行不可信代码，然后销毁它。两者发布的性能数据处于同一量级。真正的差异在于产品形态。

CubeSandbox 是腾讯云于 2026 年 4 月以 Apache 2.0 协议开源的沙箱即服务栈。基于 RustVMM 和 KVM 构建。其仓库中的核心数据：冷启动低于 60ms，每个沙箱约 5MB 内存，原生兼容 E2B SDK（替换一个 URL 环境变量即可）。以完整的可自托管栈形式发布，而不仅仅是一个库。

E2B 同样开源（也是 Apache 2.0），基于 Firecracker microVM 构建。成立于 2023 年。通过预热快照池，沙箱初始化约 150–200ms。通过 Terraform 脚本支持自托管，但主要发行方式是托管云服务——Hobby（免费，$100 额度）、Pro（$150/月 + 用量）、Enterprise（BYOC，本地部署）。自托管用户是少数，托管是默认方案。

所以真正的维度不是”哪个沙箱更好”，而是：

特性	CubeSandbox	E2B
许可证	Apache 2.0	Apache 2.0
主要模式	自托管	托管 SaaS（可自托管）
底层 VMM	RustVMM + KVM	Firecracker（KVM）
公布的冷启动	`<60ms`	~150–200ms
每沙箱内存	~5MB	~5MB
SDK 兼容性	E2B SDK 直接替换	原生 E2B SDK
GPU 支持	需要启用 KVM 的 x86_64 Linux；上游不支持原生直通	与 Firecracker 相同的 GPU 限制
运维负担	自行管理集群	E2B 管理集群（托管）

以上数据来自各项目自己的仓库和发布说明，并非我自己跑的基准测试。请将其视为厂商公布数据——方向性有参考价值，但不能替代你自己的测试。

托管 vs 自托管的权衡

这才是真正的决策，而且大多不是技术问题。

选择 E2B 托管，意味着你不用再操心 microVM 内核、快照池、KVM 主机和编排器故障转移。同时也不用思考成本优化，因为定价已经帮你定好了。我所在的团队试用了两周 E2B Pro——接入确实只需要一个小时，SDK 很简洁，节省下来的工程时间是实实在在的。

选择 CubeSandbox 自托管，意味着你拥有这台机器。成本变成”底层服务器花多少钱”，而不是”我们的用量曲线花多少钱”。合规性更容易满足，因为数据不会越过你的边界。但你也要负责值班轮换、内核更新、eBPF 策略调优。CubeSandbox 提供了单节点和集群的一键部署，这有所帮助，但”一键部署”和”生产就绪集群”不是同一个概念。

我在这里停顿了几天，因为答案确实取决于团队构成。一个四人初创公司下个季度就要上线 agent 产品，可能不应该自己运营 microVM 集群。有基础设施工程师且有合规约束的团队，可能就应该这样做。

兼容性与迁移问题

CubeSandbox E2B 兼容性是 CubeSandbox 发布中最有趣的技术声明。根据其文档，现有的基于 E2B 的 agent 只需替换一个环境变量，即可将流量路由到自托管的 CubeSandbox 集群——无需修改代码。我个人尚未将生产 E2B 工作负载迁移过去，所以目前只能姑且相信这个声明，但可以通过阅读双方接受的 SDK 调用来验证。接口面很小。双方都遵循相同的沙箱生命周期：创建、运行命令、运行代码、终止。

这里有个实用之处：这意味着 CubeSandbox 本质上是 E2B SDK 的自带基础设施后端。你可以在 E2B 的托管云上开发，当用量足以证明自建合理时，再将指向切换到自己的集群。两边的锁定论据都变弱了——我认为这对这个领域是健康的。

CubeSandbox 的优势所在

控制权、成本结构与基础设施所有权

对于任何运行量已大到托管沙箱定价开始出现在月度账单上的 agent 团队，CubeSandbox 是更诚实的选择。你为自己已经理解的硬件付费。通过 eBPF（CubeVS）的出口过滤可在内核层面配置。如果你的数据驻留规则要求”不能离开我们的 VPC”，与自托管沙箱的沟通只需 30 秒，而与托管方的沟通则要长得多。

有一点说得不够多：自托管的 agent 运行时并非免费的午餐。每次执行的边际成本下降，固定成本上升。盈亏平衡点对每个团队的用量曲线都是独特的。在做决定之前先算好账。如果答案是”每月节省 300 美元，增加两小时的每周运维工作”，那并不是胜利。

团队应当测试的性能与密度声明

CubeSandbox 公布了低于 60ms 的冷启动时间，腾讯云发布说明通过 HPCwire 将其描述为”行业平均水平（150ms）的三分之一”。他们还声称单台物理机可支持 2000 个以上沙箱。这些数据来自腾讯云内部的生产工作负载，而非合成基准测试——这比合成测试要好，但仍然是他们的工作负载，不是你的。

在相信这些数字之前，我会测试以下几点：

在你实际的快照大小下的冷启动（5GB 模板与 200MB 模板的表现截然不同）
p99 下的并发行为，而不仅仅是平均值——CubeSandbox 公布了 50 并发下 67ms 的平均响应时间，这令人鼓舞，但与 p99 不是同一回事
你的特定依赖是否能在 RustVMM 精简内核上正常运行，而不会出现意外

我的数据到此为止。我在一台启用 KVM 的虚拟机上部署了 CubeSandbox，用了半个下午就让它提供沙箱服务了。我还没有在发布说明中那样的密度数字下进行压力测试。任何人告诉你他们已经做到了，而这个项目才公开了三周，那大概是在夸大其词。

E2B 仍然占优的地方

CubeSandbox vs E2B 比较的另一面：如果你不想操心基础设施，E2B 胜出。这句话听起来像是在敷衍，但这确实是实际结论。

具体来说：

托管的 E2B SDK 更成熟。有更多的示例教程，更多 LangChain/LlamaIndex 集成，更长的使用记录。
Manus、Perplexity 的代码分析、Hugging Face 的 Open R1——大规模生产案例已经存在。CubeSandbox 在腾讯云内部有生产案例，这是真实的，但外部案例研究仍在撰写中。
E2B 文档涵盖了桌面沙箱、从 Dockerfile 创建模板、文件持久化以及开箱即用的 24 小时会话生命周期。CubeSandbox 较为简洁——README 和示例覆盖了核心生命周期，而非长尾功能。
Firecracker 本身是一个已知的量。AWS Lambda 在它上面运行。Firecracker 项目自 2018 年起投入生产。CubeSandbox 基于 RustVMM 的栈在公众视野中较新，即使它在腾讯内部已经运行了一段时间。

如果你下个季度要上线 v1 agent 产品且没有基础设施工程师，E2B 的托管方案是摩擦更少的路径。不用与沙箱集群搏斗的时间，就是花在 agent 本身上的时间。对很多团队来说，这值 $150/月。

Agent 团队的决策框架

经过两周的研究，这是我实际会用的框架。这是我找到的最有用的 AI agent 沙箱对比决策捷径之一：

月用量低于约 5 万沙箱小时、无合规约束、无基础设施团队 → E2B 托管。不用再读了。
用量超过此数，或有严格的数据驻留要求，或已经在运营 Kubernetes/microVM → CubeSandbox 自托管。经济账翻转了，且你有能力运营它。
介于两者之间 → 从 E2B 托管开始。用 SDK 构建。当账单开始令人痛苦或合规部门提出问题时，SDK 兼容性意味着迁移只需改一个 URL。这种可选性是整个对比中最被低估的特性。
需要在沙箱内进行 agent 推理的 GPU 直通 → 两者都不理想。上游 Firecracker 不原生支持 GPU 直通，CubeSandbox 继承了类似限制。那种工作负载可以考虑 gVisor 或 Daytona。

我会抵制的思维框架是：“CubeSandbox 技术更好，所以它胜出。“microVM 沙箱的选择是产品形态的选择。在已公布规格上，技术大致相当。日常成本是运营层面的。

常见问题

这些是我在进行 CubeSandbox vs E2B 评估期间，队友们不断问我的问题。

CubeSandbox 是 E2B 的直接替代品吗？

对于 E2B SDK 的接口面，是的——这是设计使然。该项目将自己定位为一个 E2B 兼容的运行时，你只需替换一个环境变量。对于核心沙箱生命周期之外的功能（从 Dockerfile 创建模板、桌面沙箱、托管可观测性），答案是”暂时还不行”。

自托管实际上会增加多少工作量？

一台（或一批）启用 KVM 的主机、内核/镜像管理、监控、快照池调优、网络出口策略以及值班。腾讯云的发布说明描述了单节点和集群的”一键部署”，但将其等同于生产级集群是过于乐观的。计划投入 1–2 周进行设置，并占用某人少量的持续精力。

哪些工作负载最能从 microVM 沙箱中受益？

任何需要大规模对不可信输入执行模型生成代码的场景。普通 Docker 的共享内核风险是反对将容器用于此场景的标准论据——每个主要 agent 平台都因此从共享内核隔离方案迁移出去了。如果你的 agent 只从固定的可信脚本白名单中运行沙箱代码，可能根本不需要 microVM。

团队应该首先对什么进行基准测试？

按以下顺序测试三件事：在你实际模板大小下的 p99 冷启动；每美元硬件成本的沙箱密度（自托管）或每美元账单的沙箱密度（托管）；突发负载下的失败模式。核心数据——低于 60ms vs 约 150ms——是真实的，但它们描述的是厂商有利条件下的平均值。你的工作负载不会与任何厂商的完全匹配，这也是进行基准测试的唯一理由。