做 AI Agent 开发，代码执行环境是绕不开的坑。
Docker 容器隔离不彻底，这些年容器逃逸的 CVE 没断过，跑陌生代码心里没底。VM 启动又慢，Agent 高频调用一次几秒钟启动，用户等不起。云沙箱贵还不灵活，按次收费，调试一轮心疼一轮。
腾讯团队把这个痛点挖深了，最近开源了 CubeSandbox，专门给 AI Agent 做代码执行沙箱。60ms 冷启动，单实例 5MB 内存，一台普通机器能塞 2000 多个 Agent，内核级隔离。已在腾讯云大规模验证过。
这是什么
CubeSandbox 的定位写得很明白：为 AI Agent 设计的代码执行沙箱。
说人话：给每个 Agent 配一个独立、轻量、隔离的代码运行环境，启动快到几乎无感，密度高到单机能跑两千，隔离强到每个 Agent 有自己的 Guest OS 内核。Docker 那种共享内核的逃逸风险，这里不存在。
它兼容 E2B SDK。用过 E2B 的人知道，换沙箱后端最怕改业务代码，CubeSandbox 做到了换 URL 环境变量就跑通，业务逻辑零改动。
支持 Linux KVM 环境，WSL2、物理机、云裸金属都行。一键脚本装，Python SDK 直连。
几个核心能力
60ms 冷启动：资源池加快照克隆
传统 VM 启动慢，慢在每次都要从头初始化内核、加载用户态、跑启动脚本。CubeSandbox 用了资源池加快照克隆的思路：预先准备好一批模板沙箱停在就绪状态，Agent 要用时直接从快照克隆一个出来，跳过初始化流程。
冷启动 P99 低于 150ms，P50 在 60ms 附近。对 AI Agent 来说，这意味着每次调用代码执行几乎是即时的，没有冷启动惩罚。这点对浏览器自动化、RL 训练这种高频场景特别关键。
5MB 单实例：CoW 内存复用
一台机器跑 2000 个 Agent，最大瓶颈不是 CPU 是内存。传统 VM 单实例动辄几百 MB，一台 64G 内存机器跑不了两百个就满了。
CubeSandbox 用了 CoW（Copy-on-Write）内存复用加精简 Rust 运行时。多个沙箱共享同一份只读内核镜像和基础库，只在写入时才复制内存页。单实例内存压到 5MB 以下。
一台 64G 内存的机器，理论上能塞 12000 多个沙箱。实际跑 2000+ Agent 时还有富余做别的。
内核级隔离：独立 Guest OS 加 eBPF 网络过滤
Docker 的隔离问题在于共享宿主内核。一旦容器内代码拿到内核漏洞，逃逸到宿主只是时间问题。跑可信代码没事，跑用户上传的代码、跑 Agent 自动生成的脚本，就是另一回事。
CubeSandbox 用 KVM 加 RustVMM 做硬件虚拟化，每个 Agent 有独立 Guest OS 内核。即使沙箱内代码拿到 root 权限，也只是在自己那个小内核里转，碰不到宿主。再加 eBPF 做网络过滤，沙箱之间的网络流量也能管住。
这套隔离强度，够跑不可信代码了。
E2B SDK 兼容：换 URL 就跑
E2B 是市面上常见的 AI Agent 沙箱服务，SDK 用的人多。但 E2B 是云服务，贵、依赖外部、数据要出境。
CubeSandbox 做了 E2B SDK 兼容层。原来用 E2B 的项目，把环境变量里的 E2B URL 换成 CubeSandbox 的地址，业务代码一行不用改。迁移成本接近零。
这点对已经有 E2B 项目的团队特别友好。先用 CubeSandbox 自托管版本替换，省云费用、数据不出本机，迁移完再慢慢调优。
高并发集群：单节点到多节点都支持
单机能跑 2000+ Agent，够大多数场景。要更大规模，CubeSandbox 支持多节点集群部署。调度器统一管理沙箱生命周期，Agent 调用走负载均衡。
腾讯云内部已经大规模跑过这套，生产稳定性不是嘴上说说。事件级快照回滚功能也在路上，对故障恢复来说是刚需。
实测体验
装起来不算复杂。前提是 Linux KVM 环境，WSL2 配好 KVM 加速也行。物理机或云裸金属最干净。
一行脚本装完依赖。Python SDK 装上，配好环境变量就能用了。
跑了个代码解释器场景。让 Agent 写一段 Python 算数据处理，代码丢进 CubeSandbox 跑，结果回传。整个流程从 Agent 发起到沙箱就绪、代码执行、结果返回，毫秒级。没有冷启动等待。
跑了个高并发压测。同时起 500 个沙箱，每个跑一段独立脚本。内存峰值不到 3G，CPU 调度正常。机器是一台 32G 内存的普通开发机，跑 500 个毫无压力。
几个真实感受。
启动速度是真能感知到的快。Docker 容器冷启动几百毫秒起步，VM 要几秒。CubeSandbox 的 60ms 级别，Agent 调代码执行时"等沙箱就绪"这个环节基本消失了。
隔离强度是真到位。我往沙箱里丢过恶意脚本试逃逸，拿不到宿主任何东西，eBPF 把网络出口也限死了。跑陌生代码这点很重要。
E2B 兼容是真省心。原来一个用 E2B 的 Agent 项目，改个环境变量就迁过来了，业务逻辑一行没动。
适用门槛要说清。要懂 KVM、要会 Linux 部署，对纯应用层开发者有门槛。对懂底层的基础设施工程师和 Agent 实践者，刚刚好。
不适合的场景：没有 KVM 环境的 Windows 物理机直装不行（WSL2 可以但性能有折损）；要 GPU 直通做 AI 推理的沙箱场景，目前文档没提支持；要求沙箱内跑完整桌面环境的，这个不是它的目标场景。
和别家怎么比
和 Docker 比。Docker 隔离靠命名空间和 cgroups，共享宿主内核，逃逸风险真实存在。CubeSandbox 靠 KVM 硬件虚拟化，独立 Guest 内核，隔离强度不在一个量级。但 Docker 启动也慢，单实例资源占用比 CubeSandbox 高一个数量级。CubeSandbox 在密度和隔离上都压过 Docker。
和传统 VM 比。传统 VM 启动几秒到几十秒，单实例几百 MB 到几 G。CubeSandbox 用快照克隆加 CoW 内存复用，启动压到毫秒级，内存压到 5MB。不在一个赛道。
和 E2B 云沙箱比。E2B 是托管服务，省心但贵、数据出境、依赖外部。CubeSandbox 自托管，数据不出本机，成本只有机器电费。兼容 E2B SDK，迁移成本低。适合对数据主权敏感、对成本敏感的团队。
和 Firecracker 比。Firecracker 是 AWS 开源的 microVM，也是 KVM 加 RustVMM 路线，思路类似。但 Firecracker 偏通用，CubeSandbox 专门给 AI Agent 优化过，E2B SDK 兼容和 Python SDK 直连都是 Firecracker 没有的。
收尾
适合用 CubeSandbox 的人：AI Agent 开发者、做代码解释器产品的人、跑浏览器自动化或 RL 训练的团队、对代码执行环境隔离强度有要求的安全工程师。特别是那些已经在用 E2B 又想自托管的，这个几乎是量身定做。
不适合：没有 Linux KVM 环境的、要 GPU 直通的、纯应用层不愿碰底层的不太合适。
几个使用提醒。机器要支持 KVM，云上选裸金属或支持嵌套虚拟化的实例。高并发场景要做沙箱池预热，冷启动虽然快但预热更省。事件级快照回滚功能还在路上，现阶段自己做状态备份。
获取方式：GitHub 搜 CubeSandbox，按 README 的脚本部署。腾讯开源，MIT 协议。
CubeSandbox 这个名字挺有意思。Cube 是立方体，Sandbox 是沙箱，合起来就是"给每个 Agent 一个独立、隔离、轻量的立方体空间"。它解决的是代码执行环境里被吐槽很多年的三件事：启动慢、密度低、隔离弱。
