沙箱分三档价钱：你的Agent在替谁看门

📋 目录

• 🚪 开场：四个卖沙箱的，四种沙箱
• 🧱 隔离强度分三档，不是分四档
• 💰 计费口径才是真账单：等审批时也在扣钱
• ⏱️ 冷启动那些数字，差的不是技术是口径
• ⚠️ 六个必须核实的口径问题
• 🏗️ 领码 SPARK 融合平台：给沙箱这件事装上仪表盘
• 🎯 给采购和架构师的六条判断标准

🚪 开场：四个卖沙箱的，四种沙箱

这期内容来自晓辉博士（袁晓辉，前腾讯研究院副院长）的视频号《Agent越来越多企业怎么管?》，时长 4 分 51 秒。她在视频里逛展时提到一个概念：当越来越多 Agent 加入团队，为什么需要关注智能体基础设施？导航里排在第一位的技术点是「01:38 为什么需要沙箱」。

这句话本身没什么新意。但有意思的是，她逛的那场展，恰好是过去一个月里中国厂商把"Agent 沙箱"这个词推得最猛的一次集中发布期。2026 年 10 月 29 到 30 日，2026 腾讯全球数字生态大会在深圳开，Agent Infra 落地实践专场里腾讯云发布了 Agent Runtime 产品矩阵升级，明确讲了 Agent 沙箱、状态管理、Agent 可观测；9 月 23 日的 2026 云栖大会上，阿里云百炼在"企业级 Agent 基础设施"分论坛发布了 Agent Studio 全栈服务，同样把运行时沙箱摆在核心位置。

于是问题来了："沙箱"这两个字，在 2026 年 10 月的市场上，至少指四种技术上完全不同的东西，而它们的价格表长得几乎一模一样。

先把四家的原始公开数据摆出来。注意：下面每一个数字都来自厂商自己的定价页或官方文档，我只标出处，不做二次加工：

看完这张表，最容易得出的结论是"E2B 和 Daytona 一样便宜，Modal 贵 41%"。这个结论对了一半——单价部分是对的，Modal 确实比另外两家贵约 41%（$0.071 vs $0.0504）。但它漏掉了三件事，而这三件事恰好是决定你要花多少钱的东西。

🧱 隔离强度分三档，不是分四档

先说技术，因为它是后面所有账的基础。

第一档：Linux 容器（共享内核）。Docker 和它的同类。这是绝大多数"我们也有沙箱"的产品实际所在的位置。它的隔离边界是命名空间 + cgroup：进程看到的文件系统被隔开，内核资源被限住，但内核本身是共享的。这意味着一旦有人拿到内核层面的提权漏洞，理论上可以横向影响同一宿主机上的其他容器。

第二档：gVisor（用户态内核）。Google 开源。用 Go 写的一个用户态内核拦截并重新实现系统调用，应用发起的 syscall 先到 gVisor 的 Sentry，再由 Sentry 决定是否放行到宿主内核。gVisor 官方自己的安全模型里写得很直接：“gVisor does not provide protection against hardware side channels.”（不防硬件侧信道），以及“A sandbox is not a substitute for a secure architecture.”（沙箱不能替代安全架构本身）。Modal 的安全指南写的是 “Compute jobs at Modal are containerized and virtualized using gVisor”。

第三档：Firecracker microVM（硬件级虚拟化）。AWS 2018 年开源的技术，现在用来隔离 Lambda。每个沙箱是一个独立的轻量虚拟机，有自己的 guest 内核，跑在 KVM 之上。E2B 的企业页把边界说得最清楚：“A kernel exploit inside the sandbox still needs a Firecracker escape to reach the host.”（沙箱内的内核漏洞，还需要一次 Firecracker 逃逸才能碰到宿主机。）

腾讯云 Cube Sandbox 走的是第三条路线，但换了个实现：RustVMM + KVM，官方文档说每个沙箱有"its own dedicated Guest OS kernel"，并用 eBPF 做沙箱间的网络隔离和细粒度出站过滤。

于是三档的实际差别可以这样理解：

⚠️ 这里有一个必须点出来的口径问题：Daytona 自己的文档是自相矛盾的。它的隔离文档里，容器类写的是 “Isolated container with dedicated namespaces and enforced resource limits”，VM 类写的是 “Full virtual machine with its own kernel”。但它的沙箱总览页却写每个沙箱都有“a dedicated kernel, filesystem, network stack”——这句话如果成立，容器类也就有独立内核，那三档对比就不存在了。

对比文档里既没有说容器类的内核是否共享，也没有点名它用的运行时。所以你没法从 Daytona 的公开文档判断它的默认容器类到底隔离到哪一档。这不是吹毛求疵——它直接决定了你该不该把用户上传的代码放进去。第三方评测给出的结论是：Daytona 只有在不可信代码走 VM 类时才算安全选择。

💰 计费口径才是真账单：等审批时也在扣钱

现在讲那个被忽略的账。

看回单价表：E2B、Daytona 是 $0.0504/vCPU-hr，Modal 是 $0.071。但这些单价不是最终账单，因为它们各自对应着不同的计费口径。

关键区别在于：Agent 到底把时间花在哪里？

一个典型的企业 Agent 任务是这样的：调模型 → 等返回 → 调工具 → 等工具 → 遇到一个需要人审批的动作 →停下来，等人点确认→ 继续。按你的直觉，等待的时间里 CPU 是闲的，不该计费。

但如果沙箱按"存活时长"（wall-clock）计费，你等审批的那十分钟，沙箱是活着的，钱在走。

有一份 2026 年 10 月的横向评测把这件事讲得非常直白：“If your agents mostly wait on the model, billing shape matters more than rate.”（如果你的 Agent 大部分时间在等模型，计费形态比单价更重要。）它给出的对比是：

评测给出的量化结论是：按活跃 CPU 计费的这几家，在有长空闲尾巴的月份里，单价优势能放大到 3 到 10 倍以上。

注意这个 3~10 倍是怎么来的。它不是单价乘出来的（$0.128 比 $0.0504 还贵），而是分母变了：如果一个沙箱 90% 的时间在等模型、按活跃 CPU 计费，你的有效单价就除以了 0.1。

所以真正的采购决策不是"哪家单价低"，而是"我的 Agent 的空闲比例是多少"。一个跑批量代码转换的 Agent，空闲比例可能是 5%；一个跑"每一步都要人确认"的审批流 Agent，空闲比例可能是 80%。同样的两家里，后者选错计费口径就是 10 倍差距。

这也解释了为什么腾讯云 Cube Sandbox 把"自动暂停 / 自动恢复"做成一等能力，而不是一个附加功能：官方文档写“Idle sandboxes are automatically snapshot-suspended (zero resource cost) and transparently restored on the next request — hundred-millisecond resume, zero caller awareness.”（空闲沙箱自动快照挂起，零资源占用，下次请求透明恢复，百毫秒级恢复，调用方无感。）腾讯云在数字生态大会上讲的那句"Agent 等待用户或外部反馈时，可以暂停环境、释放计算资源，恢复后继续工作"，说的就是同一件事。

下面这张图把两种计费形态在同一根时间轴上摊开。灰色段是 Agent 在等（等模型、等工具、等审批），橙色段是真正在算：

同一条任务、同样 4 秒实际计算，第一种口径付 24 秒的钱，第二种只付 4 秒的钱。这就是 3 到 10 倍差距的真正来源——不是单价差，是分母差。

顺带说一个容易被当成小账的数：空闲 10 分钟，按 $0.0504/vCPU-hr、一个 2 vCPU 沙箱算，是 $0.0168。听起来不多。但如果是 1000 个并发 Agent、每个每天空闲 4 小时，一个月就是$201,600。这个量级上，"要不要自动挂起"就不是个功能选择，是财务决策。

⏱️ 冷启动那些数字，差的不是技术是口径

冷启动是这块最热闹的数字竞赛。先把所有人说的放在一起：

第一处需要拆的，是 Cube Sandbox 的 “60 毫秒”。

Cube 官方文档 introduction 页给的完整数据是这样的：平均冷启动 <60ms，内存开销 <5MB；而在"并发 50 以下创建"这个具体条件下：avg 67ms，P95 90ms，P99 137ms。

注意这里的矛盾：宣传语说"平均 <60ms"，但在同一份文档的详细条件里，avg 写的是 67ms——67 > 60。这不一定是错，可能是因为"总体平均"和"50 并发以下平均"是两个不同的统计范围。但结果是："60 毫秒"是一个在特定负载下测出的最好成绩，不是你能指望的 P95 或 P99。

真正能用来做容量规划的数字是 P95 90ms、P99 137ms这两个。腾讯云在 10 月 30 日大会上的公开表述也是"在相关压力测试中，沙箱最快 60 毫秒启动"——"最快"和"压力测试中"两个限定词都在，这是严谨的表述方式。

第二处要拆的，是腾讯云 Cube 的另一个数字。中国日报 2026 年 4 月报道 Cube 沙箱开源时的表述是：“实际场景冷启动速度仅 60ms，比行业均值（150ms）低三分之二”。这里的 150ms 被明确标注为"行业均值"，它对应的是 E2B 那一档的公开数字。把 Cube 和 E2B 的数字直接比，量纲不一致——一个是中国厂商自建 MicroVM 集群的压测结果，一个是海外厂商的宣称值，中间还隔着 gVisor 和容器两档。

第三处，阿里云那个"1200 秒缩短到 70 秒"根本不是沙箱指标。它出现在千问 AI 平台的模型服务介绍里，讲的是模型弹性启动（拉起模型实例），不是沙箱冷启动。这两个数字经常在 Agent 基础设施的通稿里混着用，因为它们都跟"Agent 跑得快"有关。但如果你拿它去算沙箱容量，会算错一个数量级。

第四处最容易被忽略：冷启动不是沙箱唯一的延迟来源。一个 Agent 冷启动 60ms，然后去调一个模型——模型那边排队 + 首 token 生成，通常是秒级。所以 60ms 相对整个链路是个小项。这正是为什么腾讯云 Agent 沙箱在宣传时把"快照、暂停、恢复与克隆"和冷启动并列——快照恢复（百毫秒级）在很多真实场景里比冷启动更重要，因为失败重试和分支探索走的都是快照路径，不是冷启动路径。

⚠️ 六个必须核实的口径问题

做沙箱选型的时候，下面六件事必须自己去厂商页面核一遍。任何一条核不清楚，报价单上的那个数字就没法用。

一、你的不可信代码，走的是哪个类

上面说过了，Daytona 的文档自相矛盾。核法：直接问客服"默认容器类的内核是否共享"，要写进合同或工单答复。文档描述不算数。

二、"独立内核"这句话指的是沙箱还是宿主机

腾讯云 Agent 沙箱的公开表述是"每个沙箱通过独立内核隔离运行"，Cube Sandbox 文档写的是 “its own dedicated Guest OS kernel”。这两句都指向 guest 内核独立。但 Modal 的写法是 “gVisor”，而 gVisor 官方明确说它不防硬件侧信道、不替代安全架构。核法：确认"独立内核"指的是 guest 内核独立（microVM 路线）还是用户态内核（gVisor 路线）。这两者的成本模型和攻击面完全不同。

三、单价的计价单位和最低消费

四、计费依据是"存活"还是"活跃"

这是本文最重要的一张表。核法：拿你自己的一批真实任务，估一个"存活时长 ÷ 实际计算时长"的比值。这个比值直接决定你该选哪一档计费。

五、并发上限和会话时长上限

Modal 的"默认 5 分钟"是个坑：如果你的 Agent 任务需要跑更久（比如一个半小时的数据处理），默认配置下它会被掐断，得显式改配置。

六、你自己的东西会不会被记录

沙箱类产品的日志策略差异极大。Cube Sandbox 的文档里有一个值得抄的设计：“Credential Vault: Keys never enter the sandbox, model context, or logs. Secrets stay in the control plane.”（密钥永不进入沙箱、不进入模型上下文、不进入日志，留在控制面里。）腾讯云在数字生态大会上的表述也是"敏感凭证托管在沙箱外并按任务授权"。

反过来，有些沙箱会把完整的命令、stdout/stderr、环境变量原样落到日志里。核法：问清楚默认的日志保留策略、脱敏规则、以及能不能配置成"只记调用不记入参"。

🏗️ 领码 SPARK 融合平台：给沙箱这件事装上仪表盘

这一节写给正在做企业 Agent 平台的人。

上面这些坑，在企业里会以完全不同的形式重演一遍。不是技术问题，是账的问题：

这些都不是恶意，是口径没有唯一事实源。而口径一旦不唯一，企业就没法算账。

这张图想说的是一条边界：规则在治理层，判断在应用层，权限在最外层。

对应一：iPaaS 接数据——把"沙箱规格"当成一条要登记的属性，不是一个下拉选项

企业里的 Agent 执行环境登记，通常只记一个名字：“我们的 Agent 在 XX 沙箱里跑”。

接进来，然后登记元数据。一次沙箱执行的记录至少要挂五个属性：隔离档位（容器 / 用户态内核 / microVM）、计费依据（存活时长 / 活跃 CPU / 混合）、单价与单位、空闲比例实测值、并发与会话上限。

有了这五个属性，“我们三家沙箱单价一样"这句话才会变成"我们三家沙箱在空闲 80% 的场景下实际成本差 3.8 倍”——后者才是能进采购报告的结论。

同理，一个沙箱的"冷启动最快 60ms"必须和"实测 P95 90ms"分开存。厂商标称是标称，你的压测是压测，两者在一张表里混列，容量规划一定会错。

对应二：治理中心前置——"标称能力"和"实测能力"必须在结构上就分开

这是本文最实用的一条治理规则。

很多企业的 Agent 平台文档里，“最高并发 1000”、“冷启动 60ms”、"支持 50 并发"这几个数字是混在一起的，因为它们都是数字，都能填进模板。

治理中心该做的，是让这两类数在结构上就分得开：

• 标称值带"厂商声明"属性和出处链接（哪个版本的文档、哪天核的），到期未复核自动转成待核记录
• 实测值带"已验证"属性，带时间戳、压测脚本版本和样本量
• 两者之间的差额自动生成偏差说明，不允许人工覆盖

一个同时跑着 30 个 Agent 团队的平台，如果没有这层结构，半年后你手里会有五套"我们能撑多少并发"的说法，而且每一套都能拿出自己的依据。

对应三：全域守卫划权限——沙箱能力看得见，凭证名单看不见

沙箱隔离能力和凭证持有情况是两类信息，可见性必须不一样。

隔离档位、单价、并发上限——这些可以全公司可见，因为它们是能力描述。但"我们有哪些 Agent 拿到了生产库的长期凭证"“沙箱里能不能看到客户原始数据”——这是安全信息。

全域守卫这一层做的事是：同一个数字，对不同角色可见的精度不同。运维看沙箱隔离档位和并发上限，安全团队看凭证发放清单和留痕范围，业务团队看自己的任务队列长度。权限跟着数据走，而不是靠人记着哪些文件不能外发。

顺带说，"标称"和"实测"的可见性也要分开：跨部门看板上可以看实测值（这是我们真实的能力），标称值作为参考项展示。如果看板上的数字全是厂商标称值，整个组织的容量规划会跟着偏。

对应四：与 Dify 分工——平台定规则，应用层做判断

Dify 这类编排层适合做的是"调度这个 Agent 去跑这个任务"“把执行状态画成看板”。但**"这个沙箱能不能放用户上传的代码"这种判断，编排层做不了**——它需要的是隔离档位、凭证范围、可信度这些治理属性。

分工应该是：

反过来做就危险了：让编排层直接连各个沙箱厂商的 API 然后自己判断，那隔离档位的知识就散落在各个 prompt 和工作流配置里，改一次要改一百个地方，而且没人说得清现在用的是哪一档。

🎯 给采购和架构师的六条判断标准

1. 先量自己的空闲比例，再看单价。拿一批真实任务统计"存活时长 ÷ 实际计算时长"。超过 50% 空闲，选按活跃 CPU 计费的方案，即使它的挂牌单价更高。

2. 不可信代码必须走 microVM 档。用户上传的代码、公开 API 的输入、第三方插件生成的代码——这三种一律走独立 guest 内核（Firecracker / MicroVM 路线），容器类只放你自己写的内部脚本。gVisor 档位是折中，不是等价。

3. 把"标称冷启动"换成"你的 P95"。厂商的"最快 60ms"是压测最好成绩。容量规划用 P95 和 P99，标称值只做参考。

4. 凭证不进沙箱，这是硬要求，不是最佳实践。参考 Cube Sandbox 的做法：密钥留在控制面，按任务授权给沙箱。做不到这一点的方案，在合规审查时会被卡。

5. 会话时长和并发上限写进架构文档。Modal 默认 5 分钟会话、Daytona 无公开硬上限、E2B Pro 24 小时——这三个数决定了你的 Agent 能不能跑长任务、能不能并发扩容。

6. 每条链路都要留可回放的记录。模型调用、工具调用、沙箱创建销毁、审批等待时长，全部落成带时间戳和父子关系的记录。出事时能回放，比"当时日志里有"强十倍——这一点是下一篇要展开的。

关于本期数据的一处说明：文中所有价格都来自厂商公开定价页或官方文档，核对时间为 2026 年 10 月至 11 月初。厂商价格随时可能调整，正式采购请以合同报价为准。凡是本文标注"厂商自述"“文档自相矛盾”"第三方评测"的地方，都请以自己的实测和合同条款为准。

你手上有几个 Agent 会在等人点审批？评论区贴一下你的空闲比例，我帮你判断该选哪种计费口径。