给 AI Agent 造笼子的人，正在卷到 60 毫秒
原创 · 约 30 分钟阅读 · 阅读 --

给 AI Agent 造笼子的人，正在卷到 60 毫秒

作者: Alex Xiang

人工智能工程实践

古董级程序员，前百度/微博工程师，现在关注 AI 工程化与开发者工具。
微信公众号「字与码」，记录技术思考与行业观察。
本文同步发布于 zicode.com

今年 4 月 21 日，腾讯云把内部用了很久的 Cube Sandbox 全栈开源了——冷启动 ＜60ms、单实例内存 ＜5MB、单机跑 2000+ 沙箱、原生兼容 E2B SDK、Apache 2.0。这件事本来只是中国云厂商之间”补一句”，但我把它当成一个信号重新翻了一遍 2026 年还活着的开源沙箱：阿里 OpenSandbox、CNCF agent-sandbox、E2B、Daytona、Firecracker、gVisor、bubblewrap、Landlock……画完图之后最大的发现不是”哪家最强”，而是接口层正在悄悄收敛到 E2B。Cube 选择”100% 兼容 E2B”这件事本身，比它跑到 60 毫秒更值得讲。

01Agent 沙箱突然成了标配组件

过去两年我观察到一个非常具体的曲线：Agent 项目越来越多地内置一个”代码执行环境”模块，而不再是让用户自己开 Docker。Manus、OpenAI Agents SDK、Perplexity、Claude 的 computer use、阿里元宝、Hugging Face Agents——没有一个是直接落到用户机器上跑的，它们都跑在一个被远端平台托管的”虚拟电脑”里。这不是简单的”安全考虑”，而是产品定义：Agent 是要替你动手的，没有执行环境它就只是一只会说话的鹦鹉。

于是”沙箱”这个本来属于安全圈的小众词，被拽到了 AI Agent 基础设施的台面上。它的威胁模型也不再只是”别让病毒跑出来”，而是”别让一个被 prompt injection 拐走的 Agent 把用户的 ~/.ssh/ 拷走、把 API key 发到外网、把磁盘塞满、把隔壁用户的会话搞挂”。范围一下子大了三倍。

从隔离技术上看，做这件事的人选择其实只有几条路线，我画在下面这张图里。

2026 开源 AI Agent 沙箱生态地图 图 1 · 2026 开源 AI Agent 沙箱生态地图（★ 数取自 GitHub API 2026-09-09 抓取）——服务级、隔离运行时、本地进程级、WASM·边缘、浏览器与安全 五大类别一目了然。

02腾讯 CubeSandbox：60 毫秒的硬件隔离

Cube 是这次调研里最让我意外的一个。先说数字：冷启动 ＜60ms（50 并发均值 67ms、P95 90ms、P99 137ms），单实例 ＜5MB，单台 96 vCPU 跑 2000+ 沙箱，瞬时调度 100K+ 实例、平台 P99 ＜200ms。这些数字不是空喊——腾讯内部元宝迁移到 Cube 之后资源核时降了 95.8%，MiniMax 的 Agentic RL 训练用它支撑了分钟级数十万沙箱的并发。

它做的事并不新鲜：每个沙箱跑在独立的 Guest OS 内核上，靠 KVM 硬件虚拟化做隔离——和 Firecracker、Kata Containers 一个思路。但 Cube 在两条细节上拉开了身位：它的内存裁剪做到 5MB 而 Firecracker 是 5MB 的”最低值”而非”典型值”，启动比 E2B 的 150ms 还快一半。同时它自研了一个 eBPF 虚拟交换机 CubeVS，把”沙箱间网络隔离 + 出站白名单”做在了内核态，加上 v0.4 加进来的凭证保险库和 Web 控制台，已经是一个能直接上生产的栈。

还有一个不那么显眼、但更关键的决策：Cube 选择 100% 兼容 E2B SDK。这意味着如果你已经在用 E2B，把 E2B_API_URL 改一个地址就能切过去，业务代码零改动。这件事让整个市场发生了一个非常微妙的变化：以后写”沙箱应用”的人不用再选执行环境，而是写”用 E2B SDK 的应用”，底层换哪家是部署侧的决策。

维度Docker 容器传统 VMCubeSandbox
隔离级别低（共享内核）高（独立内核）极高（独立内核 + eBPF）
启动速度~200ms秒级＜60ms
内存开销低高极低（＜5MB）
单机密度高低极高（2000+/节点）
E2B SDK 兼容——✓ 完全兼容
License——Apache 2.0

代价是它依赖 KVM（x86_64 Linux 物理机或裸金属），不能直接跑在 macOS 或普通云主机上——不过这本来也是”硬件隔离”的成本。

03阿里 OpenSandbox 与 CNCF agent-sandbox：K8S 调度路线

如果说 Cube 是”单机极致密度”路线，阿里 1 月开源的 OpenSandbox 走的就是”K8s 原生派”。它没有去重写 microVM（默认基于 Kata/Firecracker/gVisor 可插拔），而是把功夫下在了两件事上。

第一件是 Pool CRD：维护一个预热完毕的沙箱实例池，业务 SDK 来了直接”领走”，绕过镜像拉取和系统初始化。传统的 SIG Agent-Sandbox 方案创建 100 个沙箱需要 ~76s，OpenSandbox 0.92s，差距来自这里。第二件是 BatchSandbox：把”批量创建 N 个沙箱”这件事的复杂度从 O(N) 压到 O(1)，不论你开 10 个还是 10,000 个，API Server 都只写一次状态。这一步对 Agentic RL 训练尤其重要。

另一条 K8s 路线来自 CNCF SIG Apps：kubernetes-sigs/agent-sandbox（★3.8k），它已经是 Google GKE Agent Sandbox 的开源底座，本质是一组 CRD + SDK + gVisor/Kata 运行时模板。两条路并不冲突：阿里 OpenSandbox 更适合”已经在阿里云 + 有大量异构镜像”的场景，CNCF agent-sandbox 更适合”想用 GKE 或者自建 K8s + 中立开源”的场景。

04海外参照系：E2B 与 Daytona 的 star 陷阱

海外这一波其实只有两个真正能打的”沙箱服务”——E2B 和 Daytona。E2B 是行业事实标准：Firecracker microVM + 持久 Jupyter 内核 + 88% 财富 500 都在用、Perplexity/HF/Groq/Manus 都在跑，SDK 兼容性是它的护城河。Cube 选择兼容它，等于承认了这一点。

Daytona 是另一个故事。它的仓库 ★72k，是这个赛道 star 最高的项目，比 E2B（13.7k）和 Cube（11.9k）都高出五倍以上——但它的主仓库 2026 年 7 月以后基本停更，更像是一个”开发环境管理”的全家桶，把”AI sandbox”当作了其中一个子方向。我去查了 commit history 才敢下这个判断，因为只看 star 的人很容易被误导：star 数字告诉你”曾经有多少人关注过”，但不告诉你”现在还活着没有”。

这一波我调低了 Daytona 的权重。真正在更新的同类项目是 agent-infra/sandbox（★5.9k，单 Docker 多能力单容器）、llm-sandbox（★1.1k，Python 库式）、omnigent（★10k，meta-harness）、tensorlake（★971，serverless 后台 + 沙箱），它们各自找了一个细分场景去切。

05本地进程级：Landlock / bubblewrap / Seatbelt 正在革 Docker 的命

如果说云上是一片内卷，更值得每个开发者认真看的是本地的”内核原语派”。2025-2026 年最大的反直觉信号是：Claude Code 和 Codex CLI 都不用 Docker 了。它们直接用 Linux 内核自带的能力把自己圈起来。

具体来说，Linux 上的方案是 bubblewrap（★8.7k，无 root 命名空间，Flatpak 那套）+ Landlock（内核 LSM，5.13+ 起支持文件系统、6.7+ 起支持网络）。bubblewrap 解决”我想要独立的命名空间（PID/网络/挂载点）但又不想装 Docker daemon”这件事，Landlock 解决”进程自己声明一个文件系统白名单然后内核强制执行”，免 root、零常驻、毫秒级。macOS 那边对应的是已经被 Apple 标 deprecated 的 Seatbelt（sandbox-exec），但因为没有替代品，事实上仍然是所有 macOS 上 coding agent 的默认底层。Anthropic 把这两套打包成了一个统一的 npm 包 sandbox-runtime（★5.2k，Apache 2.0），Linux 走 bubblewrap、macOS 走 Seatbelt——如果你要用 Claude Code 的方式做 agent，这套是最直接的参照实现。

为什么要走这条路？因为本地 Agent 要的不是”另一台机器”，而是”按一下 F5 跑下一个命令时只能动我让它动的文件”。Docker 启动 200ms、还要装 daemon，对一个每天按几百次 F5 的人来说体感是灾难性的。内核原语派给你的是”按一次命令的延迟多 1 毫秒”，这个差距决定了 Agent 是”丝滑的工具人”还是”等半天才能跑一步的笨重容器”。

唯一的限制是它不是”完整机器”——你不能在里面 apt install 一个新系统包（如果你需要 apt 装包，那应该用 Firecracker 或 Kata）。但对一个被 sandbox 约束的 Agent 来说，这恰恰是优势。

06浏览器与 WASM：两个被忽略的角落

两件事容易被混在一起，但其实是两个独立赛道。

浏览器沙箱是给”Agent 要操作浏览器”准备的，代表项目是 browser-use（★114k，WebVoyager 上 88.3%）、Skyvern（★23k，AGPL，视觉驱动可自托管）、browserless（★14k，老牌开源浏览器即服务）、Steel（★8k，开源浏览器 API）。它们解决的核心问题是”Agent 要填表 / 抓数据 / 操作企业内网 Web”，纯代码脚本在 UI 一变就崩，于是需要视觉理解 + 浏览器内核隔离。这里值得盯的是 browser-use 的 star 增速——114k star、MIT 许可，已经事实上成为这个子赛道的默认框架。

WASM 沙箱是另一回事。它在隔离光谱里处于”指令级 + 能力模型”那一端，启动延迟可以压到毫秒以下，安全性来自运行时本身的内存隔离。代表项目是 Wasmtime（★19k，Bytecode Alliance 参考实现）、WasmEdge（★11k，CNCF，AI 推理扩展）、Wassette（★942，微软背书，WASM + MCP 工具发现协议，2025 年 8 月发布）、wasmCloud（★2.4k，分布式组件模型）。WASM 是”理想很美”的方案，但现实里最大的问题是Python 生态对 WASM 不友好——绝大多数 data science 包没有 WASM 构建，强行走 WASM 等于自废武功。所以现在 WASM 在 Agent 沙箱这条线上更多是”插件 / 边缘函数 / 小工具”的用场，不是”代替容器”的角色。

07一张图选型 + 一句结论

把所有路线收束成一张决策图，按场景给推荐。

按场景的推荐路径 图 2 · 按场景的推荐路径：5 类工作负载对应 5 套沙箱。

最后一句结论：沙箱层正在从”选型”走向”换 driver”。以前你写一段 Agent 代码要先决定”我跑在 Docker 还是 KVM”，现在是写”我用 E2B SDK”，底层是 E2B / Cube / OpenSandbox / 自建 K8s 那是部署侧的决策，调用方不关心。这件事在 2026 年因为 Cube 选择兼容 E2B 而正式坐实——OpenSandbox 没做这一步，所以它不会成为这个标准的中心，只是阿里云的强方案。

真正值得继续盯的，是谁能把每秒钟执行成本再降一个数量级。现在 Cube 把 microVM 干到 60ms / 5MB 已经接近容器水平，再往下，要么靠 WASM 在 Python 生态上突破，要么靠硬件层的新指令集（机密计算、TEE）做隔离下沉。无论走哪条路，沙箱这场战争的赢家不会是”最快”或”最安全”的那家，而是”接口最稳 + 单次执行最便宜”的那家。

信息来源：腾讯云 CubeSandbox GitHub README 与 v0.4 / v0.5 release notes（仓库 TencentCloud/CubeSandbox，★11.9k）；阿里 OpenSandbox GitHub README（仓库 opensandbox-group/OpenSandbox，★15.1k）；E2B（e2b-dev/E2B，★13.7k）；Daytona（daytonaio/daytona，★71.8k，主体仓库 2026-07 后停更）；CNCF agent-sandbox（kubernetes-sigs/agent-sandbox，★3.8k）；bubblewrap（containers/bubblewrap，★8.7k）；firejail（netblue30/firejail，★7.6k）；nsjail（google/nsjail，★4.1k）；Anthropic sandbox-runtime（anthropics/sandbox-runtime，★5.2k）；Wasmtime（bytecodealliance/wasmtime，★18.6k）；WasmEdge（WasmEdge/WasmEdge，★10.8k）；Wassette（microsoft/wassette，★942）；browser-use（browser-use/browser-use，★113.9k）；Skyvern（Skyvern-AI/skyvern，★22.9k）。所有 Star 数据通过 GitHub API 在 2026-09-09 当日实时抓取；隔离技术数字来自各项目自述 benchmark，已注明测试条件。

打开原图 ↗