每一份沙箱对比都以冷启动毫秒数开场，而在智能体循环里，这恰恰是最不要紧的那个数字。一个服务二十步智能体的沙箱，大约七分之六的寿命都在空转，等一个模型思考完——所以决定你账单的不是它启动得多快，而是等待时段收不收费；决定你爆炸半径的，是它的出站网络默认是什么。这两个答案在 E2B、Daytona、Modal 与 Cloudflare 之间差别悬殊，而它们都不出现在跑分表里。
一眼概览
四个都在运行智能体所写的不可信代码的平台，建立在四种确实不同的隔离原语之上。其余一切都从这个原语推导出来。
| 平台 | 隔离原语 | 计费形态 | 出站默认 |
|---|---|---|---|
| E2B | Firecracker 微虚拟机——每个沙箱一套独立的 guest 内核。 | 沙箱存活期间按秒计费。 | 敞开；可配允许/拒绝清单，支持域名。 |
| Daytona | 由预热快照启动的容器。 | 存活期间按秒计费；靠自动停止与自动归档结束。 | 由一层有文档的网络限制管理；姿态随档位而异。 |
| Modal | gVisor——一个拦截系统调用的用户态内核。 | 按实际计算时长按秒计费；空闲不计费。 | 敞开；每个沙箱可设 block_network 与 outbound_cidr_allowlist。 |
| Cloudflare Sandbox | 挂在 Worker 上、跑在边缘的容器。 | 按容器运行时长；sleepAfter 结束它（默认 10 分钟）。 |
enableInternet 默认开启；前面的 Worker 可以做中介。 |
一点背景值得一提：2026 年 4 月 OpenAI 发布 Agents SDK v2 时，原生接入了七家沙箱厂商——Blaxel、Cloudflare、Daytona、E2B、Modal、Runloop 与 Vercel。换厂商如今接近一次配置改动，这让"照错误的维度去选"变得很容易，也让"事后发现"变得很贵。
空闲问题，附带算术
设想一个做数据分析的智能体：二十步，每一步是大约十二秒的模型调用，接着约两秒的代码执行。沙箱必须在整个过程中一直存在，因为文件系统与 Python 内核要在步与步之间携带状态。
那就是 280 秒的沙箱寿命里包着 40 秒的计算。在"存活即计费"的模型下你付 280 秒；在"活跃才计费"的模型下你付 40 秒。比值是七比一，而它由推理延迟决定——一个你无法掌控、并且会随着推理强度上升而增大的变量。冷启动跑分对它没有任何预测力。
随之有两个后果。第一，除非按计费形态做归一，否则每 vCPU 小时单价作为比较依据几乎毫无意义；一个每活跃小时明显更贵的平台，在智能体负载上可能便宜得多。第二，空闲占比会随着你模型质量的提升而上升，因为更好的模型思考得更久。用一个又快又小的模型做基准、却拿一个推理模型上线的团队，会看到沙箱这条开销朝着表格没有预测到的方向移动。
反方意见是真实的：一个"存活即计费"的平台，配上很短的自动停止间隔与很快的恢复，能逼近同样的效果，而 Daytona 的自动停止与自动归档控制正是为此存在。但那是一项你必须针对每个负载调对的配置，而它对抗的是一个会花你钱的默认值；Modal 那种模型本身就是默认。默认值决定了大多数团队实际上付多少。
隔离：对同一个威胁的四种不同回答
威胁是代码，不是用户
四个平台都假定工作负载是敌意的，这是对的：智能体所写的代码即便出自你自己的智能体，也依然是不可信代码，因为它的行为取决于一些你并不掌控的输入——检索到的文档、issue 评论、网页。差别在于这些代码能够到宿主内核的多少。
E2B 的 Firecracker 微虚拟机给每个沙箱一套自己的 guest 内核，于是内核漏洞要逃逸的是一层 hypervisor 而不是一组命名空间。Modal 的 gVisor 位于中间：一个用户态内核在系统调用抵达宿主之前把它拦下来，这个攻击面比共享内核小得多，又比硬件虚拟化大一些——而且有个实用的好处，它让 GPU 直通保持简单，这一点是微虚拟机做起来别扭的。Daytona 由快照启动的容器启动最快、也最常规，这就是它做的取舍。Cloudflare 的容器继承了 Workers 平台的边界，并且独一份地把沙箱放在了紧挨请求的边缘。
差别真正咬人的地方
对大多数智能体负载来说，隔离层级并不是决定性因素，把这一点讲出来比装作不是更有用。如果你的智能体在自己的账户里，拿自己的数据跑自己生成的 Python，容器就够了。层级开始要紧，是当你在跑别人的智能体——一个多租户产品，一个客户的提示词注入不该够到另一个客户的执行——而在那里，微虚拟机边界是你能写进安全问卷、不必附脚注的那一条。
更大的现实约束是 GPU。如果被沙箱包住的工作会碰到模型——跑一遍嵌入、执行生成出来的 CUDA、驱动一个强化学习环境——Modal 是这组里为此而建的平台。其余几家是 CPU 形态的，而这是一个架构事实，不是路线图上的缺口。
存活与持久化：步与步之间什么活下来
智能体循环需要状态跨越模型调用而存续，而每个平台表达它的方式都不同。这是选错了最可能逼你重写的一个维度。
会话长度。E2B 在付费档上支持以小时计的长寿沙箱，适合一个整下午都在啃同一个问题的研究型智能体。Cloudflare 的沙箱是为更短的交互塑形的，并在一段不活跃窗口后休眠——默认十分钟，可配——这适合一个请求作用域的代码解释器，不适合一个要想一小时的任务。Modal 与 Daytona 都允许沙箱一直活到你结束它，以空闲超时与自动停止间隔作为安全网。
文件系统状态。Daytona 的快照模型在这里最成熟：一次对文件系统、软件包与设置的时间点捕获，任意数量的新沙箱都能从它启动，外加从 Dockerfile 声明式地构建镜像。如果你的智能体需要一个已经克隆好的仓库和已经装好的依赖，这就是"每次运行五分钟的税"与"热启动"之间的差别——而它比那个通常与之并列引用的冷启动数字重要得多。
恢复语义。要向每个平台问的问题是：一个沙箱停下再启动之后会怎样——文件系统回来吗，进程树回来吗，一条打开的网络连接回来吗。答案各不相同，而一个假定"进程能跨越恢复而存活"的智能体架构，会以一种看起来像模型回归的方式失败。按更弱的保证来设计——从文件系统重建——平台选择就不再约束你了。
出站：真正要紧的那个控制，与那个错误的默认
这是没人跑分、却决定一次成功的提示词注入能干什么的维度。如果智能体的沙箱能够到任意主机，那么任何抵达智能体的指令——来自被抓取的网页、某个依赖的安装后脚本、一条 issue 评论——就为沙箱读得到的一切准备好了一条出去的通道。
四个平台如今都提供了控制。Modal 接受每沙箱的 block_network 或 outbound_cidr_allowlist。E2B 支持覆盖 IP、CIDR 段与域名的允许与拒绝清单，域名在 80 端口靠 Host 头、在 443 端口靠 SNI 解析，并且允许在不重启的情况下替换一个运行中沙箱的规则——这是四者里最贴合智能体形态的设计，因为它让你能为某一步放宽访问、随后再收紧。Cloudflare 把 enableInternet 做成一个开关，而更有意思的是，它让容器前面的 Worker 去中介出站请求，于是策略可以是代码而不是配置。Daytona 有一层有文档的网络限制，其默认姿态随账户档位而异——去查你自己的，别想当然。
共同的问题是：宽松那一档在所有地方都是默认。用 SDK 的最简构造函数创建出来的沙箱能上网，而那些让厂商可互换的框架集成层，恰恰是这项配置最容易被漏掉不设的地方。默认拒绝出站、只留一个小白名单——你的包仓库、你的代码托管、这项任务需要的那一个 API——是整份对比里杠杆最高的控制，而在四个平台里的三个上，它是构造时的一行。
凭据那一半是同一个故事。一个握着长期有效、范围很宽 API 密钥的沙箱，已经输掉了这场争论，因为出站控制救不了你——那把密钥本来就是智能体有权使用的。按次注入的、范围窄、寿命短的凭据，是出站白名单的配对项；只有其中一个，另一个的洞就照样开着。
什么时候选哪个
| 情形 | 选 | 因为 |
|---|---|---|
| 模型延迟很重的长智能体循环 | Modal | 空闲不计费，于是沙箱七分之六用来等待的寿命是免费的。 |
| 跑别人智能体的多租户产品 | E2B | 每沙箱一套 guest 内核是你能在安全评审里守住的边界，而且它的出站规则是这里最细的。 |
| 环境准备很重——仓库、依赖、fixture | Daytona | 快照与声明式镜像让热启动成为常态，而不是一项优化。 |
| 在既有 Workers 应用里做请求作用域的代码执行 | Cloudflare | 沙箱就住在请求旁边，而出站策略可以是 Worker 代码而不是配置。 |
| 任何会碰到 GPU 的东西 | Modal | gVisor 让 GPU 访问保持可行；这组里的其他几家是 CPU 形态的。 |
| 极高频、极短的执行 | Daytona | 这是冷启动数字真正占主导的唯一情形，而它最快。 |
对以上一切的一句提醒：费率与限制按季度变动，本对比里引用的每一个数字，在你据以建立成本模型之前都应当回到厂商自己的文档里重新核对。计费形态——存活 vs 活跃——是架构性的，变得比挂在它上面的费率慢得多，而这正是它值得作为选择依据的原因。
常见问题
沙箱冷启动对智能体重要吗？
比那些对比所暗示的重要性小得多。如果你为每次工具调用新建一个沙箱，它就重要，而那通常是错误的架构——智能体需要的是步与步之间的状态。对极高频的短执行它非常重要，但那是另一种负载。对一个正常的多步智能体来说，环境准备时间与空闲计费都比它更占主导。
对智能体代码来说，微虚拟机真的比容器更安全吗？
是的，在"内核漏洞要跨越的是 hypervisor 而不是命名空间"这个意义上。这个差别值不值得花钱，取决于你的租户结构：在自己的数据上跑自己的智能体，容器通常够用；把不可信的第三方智能体并排跑起来，更强的边界才是让这个答案对别人也站得住的东西。
最重要的那一项沙箱设置是什么？
出站网络策略。默认拒绝加一个窄白名单，框住了一次成功的提示词注入能外泄什么，而且它是模型已经被说服与攻击者合作之后唯一还起作用的控制。这里的每一个平台默认都是宽松的。
以后还能换厂商吗？
执行 API 已接近商品化，而框架层的集成让换厂商近乎不费力。不能平移的是你建立在厂商专有原语上的东西——快照、恢复语义、边缘部署——外加你的成本模型，它会在计费形态变化时反转。
我一定需要托管沙箱吗？
不一定。对一个单租户的内部智能体来说，自己跑一个配了严格网络策略的容器是正当答案，而且更便宜。你买的是供给速度、快照管理，以及一个比你自己造得出来的更强的隔离边界；如果这三样都不构成约束，自托管完全可以。
GPU 支持会改变隔离上的取舍吗？
会。硬件虚拟化让 GPU 直通变得别扭，这正是这组里 GPU 故事最好的平台，同时也是那个用用户态内核而非微虚拟机的平台的原因。如果你既要最强隔离又要 GPU，预期得在其中一头付出代价。
延伸阅读
本站相关：
- 沙箱与代码执行——这个选择底下那五条彼此独立的隔离决策。
- 沙箱与隔离模式——厂商之上的那层架构。
- 沙箱与执行——具体到跑编码智能体写出的代码。
- 后台编码智能体——环境快照与出站策略回报最高的地方。
- 为智能体划定凭据范围——出站故事的另一半。