每家沙箱厂商都拿冷启动数字打头阵，而这些数字描述的全都是「一次创建一个沙箱」——那恰恰是智能体集群从不会做的事。关于并发创建，唯一公开过的测量把同一类平台摊在了 0.67 秒到 5.06 秒之间，与营销数字相差一个数量级；而这里的四个平台中，有两个压根没有公开过突发场景下的数字。第二件没人给它定价的事：编码智能体的沙箱，其挂钟时间的大部分是在等模型作答——所以「等待期间计价器跑不跑」这件事，比任何毫秒之争都更值钱。请按突发与闲置来选。隔离对照表反倒是容易的那部分；而到 2026 年 6 月，退出这道门已经窄到只剩四家里的两家。
速览
四个可以让智能体运行不可信代码的平台，而它们并不是同一种产品的四个版本——一个是沙箱公司，一个是带沙箱 API 的算力平台，一个是通用应用平台，还有一个今年改了许可证。
| 平台 | 隔离边界 | 闲置时计价器 | 自托管或退出路径 |
|---|---|---|---|
| E2B | Firecracker microVM，每个沙箱独立内核 | 在跑——只要活着就计费 | 开源；支持自托管 |
| Daytona | 默认容器；可按需换 Kata 或 Sysbox | 在跑——按秒计，无月度门槛 | 生产代码库自 2026 年 6 月起闭源 |
| Modal | gVisor | 无代码执行时归零 | 仅托管 |
| Northflank | Kata Containers、Firecracker、gVisor | 在跑；无强制会话时长上限 | 自助式 BYOC，跑进你自己的云账号 |
有一条前提影响着下文的一切：这个品类里相当一部分公开的对比文章，是 Northflank 发在 Northflank 博客上、拿 Northflank 与其竞品作比较的。那些数字具体且可核对，我也确实用了；但厂商自家的对比是一个有方向的信源，而这里每一个落地页上的「低于 90 毫秒」同样如此。凡是第三方测得的数字，我会注明；凡是厂商自述的，我也会注明——因为在最要紧的那条轴上，这两类数字相差大约十倍。
大家在比的那个冷启动数字，量的是错误的工作负载
Daytona 的营销材料给出低于 90 毫秒的冷启动，并称优化配置下可达 27 毫秒；E2B 的默认模板通常被引作 150 毫秒上下。两者都是对一项真实操作的真实测量：创建一个沙箱、等待、再创建下一个。现在看看创建请求一起涌来时会发生什么——那是智能体平台唯一会产生的形状：一个队列被排空、一批运行同时启动、一秒之内有五十个沙箱被申请。2026 年 8 月公布的第三方突发数字是：Vercel 中位数 0.67 秒、p99 为 1.12 秒，Modal 0.88 秒，E2B 1.61 秒，Cloudflare 5.06 秒。这是提供商之间 7 倍的跨度，也是 E2B 自家顺序数字与其被测突发数字之间约 10 倍的落差。
两个数字都不算不诚实。它们量的是不同的东西，而顺序那个更好测——所以它才是被公布出来的那个。对买家的后果很具体：一份按顺序那一列排出来的候选名单，在负载下可能整个颠倒过来；而在这场比较里，冷启动营销最强的那家（Daytona）和隔离栈最强的那家（Northflank），我都找不到任何已公开的突发测量。这并不能证明它们慢，它证明的是：在这个数字对你有意义之前，你得自己按自己的并发度把这个实验跑一遍。
同一列里还有两个坑。Modal 没有原地恢复，所以为它引用的「恢复」数字是快照启动时间，与那些能原地恢复暂停沙箱的平台不可比。另外，冷启动的中位数对一个交互式智能体近乎无用：用户体验到的是 p99，因为一次智能体轮次可能创建好几个沙箱，并且要等最慢的那个。要么按你真实的并发度测 p99，要么干脆别测——这也正是 负载测试 那一页对智能体本身所主张的纪律。
模型在思考时，计价器在跑
给一次智能体轮次计个时。沙箱被创建出来，然后它就在那儿待着——模型正在读上一次的工具结果、生成下一次调用；接着某条命令跑了不到一秒；然后它又在那儿待着。在编码智能体上，真正执行的部分通常只占沙箱生命周期的个位数百分比，其余都在等推理，而且越来越多是在等一个要先思考好几秒才吐字的推理模型。E2B 自己的文档对这在它的计价器上意味着什么直言不讳：这个时钟并不区分活跃执行与闲置，只要沙箱存在，你就在付钱。Daytona 与 Northflank 用的是同一种「按存活时长」的形状。Modal 是那个异类——无代码执行时算力费用归零——这把「一个长期等模型的沙箱」从最大的一笔开销变成了几乎为零。
这并不是判 Modal 胜诉，因为费率不同、门槛也不同。E2B 的 Pro 档每月 150 美元、含 500 小时，超出后按秒计——那是一笔无论用不用都要背的固定成本，也是低用量用户会多付钱的原因。Daytona 没有月度门槛，从免费额度起按秒计，对间歇性负载更有利。Northflank 公开的价格是每 vCPU 小时 0.01667 美元、每 GB 小时 0.00833 美元，并且是四家里唯一提供自助式「自带云」的：沙箱改为记在你自己的云账号上——它自己的数字是 200 个沙箱在 BYOC 上花 2,060 美元、在其托管平台上花 7,200 美元；那是一家厂商谈自家产品的数字，但论证的形状是对的。
所以在你把任何东西列进候选名单之前，先算这一笔：给一周的真实智能体运行装上仪表，记两个数——沙箱存活秒数，和沙箱执行秒数。如果这个比值高于大约 5:1，那么按存活时长计费的平台主要是在向你收「等待费」，在开始比较费率之前，按执行时长计费就已经在价格上赢了。如果比值接近 1:1，你跑的其实是批处理算力而不是交互式智能体，那就由费率来定胜负。没有人能从一个定价页面替你算出这笔账——而这恰恰是那些定价页面被排布成那个样子的原因。这个陷阱的一般形式在 预测智能体开支 里：均值什么都说明不了，账单的形状是由「有意思的时刻之间发生了什么」决定的。
隔离那一列是真的，但它不是难做的那个决定
智能体写出的代码是不可信代码——不是因为模型心怀恶意，而是因为它的输入受攻击者影响；这正是 沙箱与代码执行 长篇论证的那件事。所以边界是要紧的。它同时也是这四家最容易排出高低、而排出高低之后改变最小的那条轴。
E2B 跑的是 Firecracker microVM，每个沙箱一个独立内核——这是这一组里最强的边界，也是能扛住「容器逃逸」那一类漏洞的那种。Northflank 通过 Kata Containers 与 Firecracker 提供 microVM，另有 gVisor，并称每月在这些之上处理超过两百万个隔离工作负载。Modal 用 gVisor，一种系统调用拦截式的边界：明显强于普通容器，也明显弱于一个独立内核。Daytona 默认跑容器，Kata 或 Sysbox 作为可配置项——这是这里最弱的默认值，也最可能被某个「读完冷启动数字就没往下看」的团队原样部署上线。
为什么这条轴的分量比看上去要轻：隔离边界约束的是「代码执行逃逸」的爆炸半径，而代码执行逃逸并不是常见的失败。常见的失败是沙箱一丝不苟地做了被要求做的事，然后碰到了它本不该碰到的东西——一个内部元数据端点、一条没被过滤的出站连接、一份图省事挂进环境变量的凭据。那是网络与能力的问题，不是内核的问题，而这里每一个平台都把其中大部分留给了你。如果你还没定下出站策略，那么把 gVisor 升级成 Firecracker 买到的东西非常有限；参见 智能体的出站控制 与 沙箱与隔离模式。
有一项能力确实会封死选择，而且方向与隔离相反：Modal 是这四家里唯一能让沙箱持有 GPU 的——H100、H200、A100、B200、L4、T4——与 CPU、内存一并按秒计费。如果你的智能体需要在「跑工具调用的那同一个隔离进程」里做推理、微调或处理图像，那就是一条硬性要求，它自己就把选择定在了 Modal。在别处的变通办法是从沙箱内部调用外部推理 API，那要多付一跳网络和第二份账单。
2026 年 6 月，退出这道门变窄了
Daytona 在 2026 年 6 月把生产代码库转为闭源，理由是「AI 辅助的漏洞发现」让一个开放的沙箱仓库成了负债。原来的仓库仍然公开、仍可使用，但不再有任何更新、修复或发布，而完整自托管这个平台已不再可能。无论你怎么看这套理由——它其实比多数许可证变更所得到的评价要更值得琢磨——实际效果是：「如果厂商在定价、可用性或路线图上让你失望，就自己跑一套」这个选项被拿掉了。
于是这四家里只剩两条退路。E2B 开源且可自托管，这在如今这个品类里已属罕见。Northflank 的那条退路性质不同：它并不开源，但提供跨 AWS、GCP、Azure、Oracle、Civo、CoreWeave、本地机房与裸金属的自助式 BYOC，工作负载跑在你本就掌控的基础设施里，账单落在你自己的云账号上。Modal 只做托管，并且对此毫不含糊。
沙箱值得当作一个「切换成本」决策而非「功能」决策来对待，因为它垫在一切之下：智能体的文件系统约定、进程模型、网络形状与失败语义，全都是对着某一家提供商的 SDK 表达出来的。迁移不是改个配置。如果你的组织对「厂商退出」有政策——在智能体基础设施这个品类过完这一年之后，它理应有——那么许可证与部署这一列是第一道筛子，不是最后一道。
什么时候选哪个
| 情形 | 选 | 因为 |
|---|---|---|
| 智能体需要在沙箱内用 GPU | Modal | 四家里唯一能让沙箱持有 GPU 的；其余都要求一次外部推理调用和第二份账单 |
| 沙箱长期存活，且大部分时间在等模型 | Modal | 无代码执行时算力费用归零，而那正是编码智能体沙箱生命周期的绝大部分 |
| 要跑不可信的第三方代码，隔离是硬要求 | E2B | Firecracker microVM、每个沙箱独立内核，而且开源——边界是可查验的，不是被断言的 |
| 有合规或数据驻留约束，或有真正的退出政策 | Northflank | 跨八种目标的自助式 BYOC，跑进你自己的云账号，并可选 microVM 隔离；工作负载从不离开你掌控的基础设施 |
| 间歇性、低用量、对成本敏感 | Daytona | 没有月度门槛，从免费额度起按秒计——代价是接受容器作为默认边界，以及自 2026 年 6 月起没有自托管路径 |
| 高突发并发，且处在一次轮次的关键路径上 | 先自己测 | 每一个公开的顺序数字量的都是你并不会跑的负载，而这四家里有两家根本没有公开的突发数字 |
不该由它来定的：落地页上的冷启动数字，以及某篇对比博客把谁排在第一——当那篇博客本身属于其中一个平台的时候。该由它来定的：你自己的「存活比执行」之比、你自己在自己并发度下的 p99 创建延迟，以及你走不走得掉。
常见问题
为什么突发冷启动和顺序冷启动差这么多？
一次只创建一个，提供商可以从热池里取，而每一个共享组件——调度器、镜像缓存、网络挂载——都在无竞争状态下工作。一次创建五十个会耗尽热池并在这些共享组件上排队，所以你测到的是这个平台的容量，而不是它的创建路径。智能体负载几乎只产生第二种形状，因为运行是成批派发的，而一次轮次可能同时需要好几个沙箱。
microVM 真的必要吗，还是 gVisor 就够了？
对于「你自己的智能体针对你自己的仓库生成的代码」，gVisor 是一个合理的边界，实际风险在别处——出站、挂进去的凭据，以及沙箱在你网络里够得着什么。「每个沙箱一个独立内核」值回成本的场景，是代码来自你的信任边界之外：客户的一段代码、运行时装上来的一个包，任何攻击者可以直接（而不是经由你的提示词）影响的东西。按代码从哪儿来决定，别按哪个听起来更强决定。
在工具调用之间把沙箱拆掉，能不能绕开闲置计费？
能绕开一部分，而代价是你原本要优化的那个东西。每条命令之后就销毁沙箱，意味着后续每一次调用都要付一次完整的创建，于是突发冷启动被放回到每一轮的关键路径上，智能体攒下的文件系统状态也丢了。在支持原地暂停/恢复的平台上，暂停与恢复是中间那条路。诚实的说法是：按存活时长计费与创建延迟是彼此对冲的，而选一个「计价器会停下来」的平台，是一种不必去做这笔取舍的办法。
如果我反正要用托管产品，开源在这里还重要吗？
它对两件不是「我要自托管」的事很重要。第一，隔离边界成了一项你可以读的安全声明，而不是一项你只能接受的安全声明——这与一页合规说明是不同质量的保证。第二，它是那条约束着这段关系的可信退路——这也正是「即便对那些本来就不打算自己跑代码的客户来说，一次许可证变更依然算新闻」的原因。
「存活比执行」这个比值到底怎么测？
在任何已经记录你的运行的地方，给每个沙箱打两个时间戳：创建与销毁得出存活秒数，命令「开始到退出」区间之和得出执行秒数。在一周的真实流量上做聚合，而不是在一次基准测试上。如果你的追踪里已经为每次工具调用带了一个 span——那正是 智能体可观测性 的用途——第二个数你已经有了，只需要把沙箱生命周期挂到同一条追踪上。
延伸阅读
本站相关：
- 沙箱与代码执行——五条彼此独立的隔离决策，内核边界只是其中之一。
- 沙箱与安全执行——当代码受攻击者影响时，如何为爆炸半径做设计。
- 沙箱与隔离模式——这些产品底下的那套模式目录。
- 智能体的出站控制——隔离强度并不能处理的那种失败。
- 并发与扩缩——智能体负载一开始为什么就是成批到来的。
- 预测智能体开支——这些计价器最终会撞上的那条重尾。
项目来源：
- E2B——开源，Firecracker microVM。
- Daytona——以及 2026 年 6 月关于转为闭源的说明。
- Modal——可用 GPU 的沙箱，按执行时长计费。
- Northflank——支持自助式 BYOC 的 microVM 沙箱。