GitHub 上有个 Rust 仓库，三个多月攒了 1.08 万颗星，背后是腾讯云。它不训练模型、不做编辑器、不提供 Agent 框架，只干一件事：给 AI agent 一个能跑代码的安全隔离环境。这就是 TencentCloud/CubeSandbox。截至 2026 年 8 月 1 日，仓库有 10,818 颗星、996 个 fork，主语言 Rust，创建于 2026 年 4 月 10 日，最近一次推送在 8 月 1 日。README 一句话定位："Instant, Concurrent, Secure & Lightweight Sandbox Service for AI Agents"——为 AI agent 提供即时、并发、安全、轻量的沙箱服务。它已进入 CNCF Landscape，PyPI 上有官方包 cubesandbox 0.3.0。
许可证有个坑值得先说清楚：README 徽章和 LICENSE 文件都标的是 Apache 2.0，但 GitHub API 的 SPDX 字段返回的是 NOASSERTION（未自动识别）。实际许可证就是 Apache 2.0，这个 NOASSERTION 只是 GitHub 的许可证检测没能自动匹配，不影响你按 Apache 2.0 使用。写自动化合规脚本读许可证字段时别被这个 NOASSERTION 坑到——要结合 LICENSE 文件和 README 徽章一起判断。
解决什么问题：Agent 跑代码不能在宿主机裸跑
AI agent 写完代码要跑、要验证，这是基本需求。但让 agent 生成的代码直接在你宿主机上执行，风险不言自明：一段被 prompt 注入的代码可能 rm -rf 你的目录、窃取环境变量里的密钥、扫内网、把你的机器当跳板。Docker 容器是常见的隔离手段，但容器共享宿主机内核，隔离层级偏低——一个内核漏洞或配置失误就可能逃逸。传统虚拟机隔离够强，但启动要几秒、内存开销动辄几百 MB，扛不住 agent 高频、高并发的代码执行场景。
CubeSandbox 解决的就是这个矛盾：要硬件级隔离的安全，又要毫秒级的启动和个位数 MB 的内存开销，还要能扛住单机几千个沙箱的密度。它不是通用虚拟化平台，是专门为 AI agent 代码执行场景设计的 MicroVM 沙箱服务。
核心机制：RustVMM + KVM 硬件级隔离，60ms 拉起一个沙箱
CubeSandbox 基于 RustVMM 和 KVM 构建。每个沙箱是一个独立的 MicroVM，跑自己的专用 OS 内核——这是硬件级隔离，不是容器的命名空间隔离。README 给的基准数据：
冷启动（bare-metal 实测）：单并发下 60ms；50 并发创建时，平均 67ms，P95 90ms，P99 137ms——始终低于 150ms。内存开销：每个沙箱基础内存开销低于 5MB（沙箱规格 ≤ 32GB 时测量；更大规格可能略增）。靠内核共享和写时复制（CoW），单节点能跑到几千个沙箱实例。
E2B SDK 兼容是它一个关键卖点：接口兼容 E2B，从 E2B Cloud 迁移只需改一个环境变量，客户端代码零改动。E2B 是市面上主流的 AI agent 沙箱云服务，CubeSandbox 等于给了你一个可以自托管的 E2B 替代品——数据不出你的基础设施。
它的高密度靠两个机制：资源池化 + 快照克隆跳过冷启动开销；以及 v0.5 引入的 AutoPause/AutoResume——空闲沙箱自动挂起，下次请求来了再唤醒，进一步压低常驻内存、提高部署密度和成本效率。
架构拆解：七个组件各司其职
README 的架构图把 CubeSandbox 拆成七个核心组件：
CubeAPI：高并发 REST API 网关，Rust 写的，E2B 兼容。换 URL 就能无缝迁移。
CubeMaster：集群编排器，接收 API 请求并分发到对应的 Cubelet，管理资源调度和集群状态。
CubeProxy：反向代理，兼容 E2B 协议，把请求路由到对应的沙箱实例。
Cubelet：计算节点本地调度组件，管理节点上所有沙箱实例的完整生命周期。
CubeVS：基于 eBPF 的虚拟交换机，提供内核级的网络隔离和安全策略执行。这是它相比普通 MicroVM 多出来的一层——沙箱之间的网络流量在内核层就被 eBPF 隔开。
CubeEgress：基于 OpenResty 的出口安全网关，做 L7 域名过滤、凭证注入和访问审计。配合 CubeVS 的内核策略，沙箱流量没法绕过检查。
CubeHypervisor 和 CubeShim：虚拟化层。CubeHypervisor 管理 KVM MicroVM；CubeShim 实现 containerd Shim v2 API，把沙箱接进容器运行时。
这套架构的思路是：用 KVM MicroVM 拿到硬件隔离，用 eBPF 拿到内核级网络隔离，用 containerd Shim 接进现有容器生态，再用 E2B 兼容接口接进 AI agent 生态。四层各管一段。
版本演进：四个月六个版本
CubeSandbox 开源节奏很快，从 4 月到 7 月发了六个版本：
v0.1（2026-04-20）：首次开源发布。毫秒级启动、硬件级隔离、E2B 兼容的 AI agent 沙箱。
v0.3（2026-06-02）：引入 CubeCoW 写时复制快照引擎，支持事件级快照、即时克隆、回滚到任意保存状态。快照和回滚粒度到百毫秒级——可以在运行中的沙箱上建检查点，随时回滚，或者从某个状态 fork 出去并行探索。
v0.4（2026-06-14）：Credential Vault（密钥库，agent 调外部 API 但密钥不进沙箱）和 Dashboard（版本矩阵 + 模板健康检查，升级后一眼看出模板要不要重建）。
v0.5（2026-07-03）：三个重点。AutoPause/AutoResume，空闲沙箱自动挂起、请求时唤醒；Terraform 一键集群部署；ARM64 原生全栈支持；还有网络策略加固——每个沙箱的流量令牌、策略路由出口。
v0.6（2026-07-24）：三个重点。K8s 部署，在 Kubernetes 上部署 Cube 控制面组件和计算节点；Volume 框架，E2B 兼容、可插拔自定义后端存储，Volume 有独立生命周期、可跨沙箱共享；模板别名，建模板时设个别名，建沙箱时直接指定别名。
从版本节奏能看出它的发力方向：先做核心隔离和启动性能，再做状态管理（快照/克隆/回滚），再补安全（凭证库/网络加固），最后做生产部署（Terraform/K8s）和生态兼容（Volume/E2B）。v0.6 的 K8s 部署还在快速完善中——Roadmap 写明下一步要从 Helm 部署演进到 CRD 和 Operator 原生管理。
部署：三条路径，单节点到 K8s 集群
CubeSandbox 要求 x86_64 Linux + KVM 支持。三条部署路径：
PVM 云虚拟机（推荐）：普通云 VM 就能跑，不需要裸金属或嵌套虚拟化。腾讯云 PVM 服务器有官方部署文档。
裸金属：直接在物理机上部署，性能最好。
开发环境（QEMU VM）：没有 KVM 访问权限时，在一个一次性 OpenCloudOS 9 VM 里跑 CubeSandbox。README 明确标注"不推荐——性能差"，仅供开发调试。
部署完打开浏览器访问 http://<控制节点 IP>:12088 进 WebUI 控制台，看节点状态、装模板、建沙箱、看实时日志。生产部署支持两种：腾讯云上用 Terraform 一键拉集群；标准 K8s 集群部署（v0.6 引入，预览阶段）。
同类对比：vs E2B、vs Docker、vs Firecracker
这三类是 AI agent 代码执行隔离的主流方案，定位差异明显。
vs E2B：E2B 是托管的沙箱云服务，你调它的 SDK，沙箱跑在 E2B 的基础设施上。CubeSandbox 接口兼容 E2B SDK，从 E2B Cloud 迁移改一个环境变量、客户端代码零改动。区别在于部署模式：E2B 是 SaaS，CubeSandbox 是自托管——数据不出你的基础设施，成本可控，但要自己运维。Roadmap 里 CubeSandbox 还在持续补齐 E2B API 的剩余差距，目标是完全 drop-in 兼容。
vs Docker 容器：Docker 隔离层级低（共享内核命名空间），但生态成熟、镜像丰富、启动也不慢（README 基准表给的是约 200ms 量级）。CubeSandbox 隔离更强（专用内核 + eBPF，README 用的是 "Extreme"），启动更快（<60ms vs ~200ms），内存开销更低（<5MB），单机密度更高（数千 vs 高）。代价是 CubeSandbox 需要 KVM，不是随便一台机器都能跑；Docker 几乎到处能跑。如果只是跑可信代码做 CI，Docker 够用；如果跑的是 agent 生成的、可能被 prompt 注入的不可信代码，硬件级隔离更稳。
vs Firecracker：Firecracker 是 AWS 开源的 Rust 写的 KVM MicroVM，用在 Lambda 和 Fargate 上，主打多租户 serverless 计算隔离。两者技术路线相近（都是 Rust + KVM MicroVM），但定位不同：Firecracker 是通用计算隔离的基础设施，CubeSandbox 是专门为 AI agent 代码执行设计的——带 E2B SDK 兼容、写时复制快照、AutoPause、凭证库、出口审计这些 agent 场景才需要的能力。README 没有发布对 Firecracker 的直接基准对比，这里只能从架构定位上比较。另一个细节：CubeSandbox 在致谢里专门感谢了 Cloud Hypervisor（另一个 Rust 写的 VMM）和 Kata Containers，说明它的 MicroVM 实现站在这些项目肩膀上，而不是从零造轮子。
安全设计：三层防御
CubeSandbox 的安全设计值得单独说，因为它直接关系到"敢不敢让 agent 跑代码"。
第一层，硬件隔离：每个沙箱跑专用内核，MicroVM 级别。这是最强的隔离边界——沙箱里的代码即便拿到 root，也只在自己的 MicroVM 里，碰不到宿主机内核。
第二层，网络隔离：CubeVS 用 eBPF 在内核层做沙箱之间的网络隔离和出口过滤。CubeEgress 在 L7 做域名/路径/方法级别的策略控制，配合 CubeVS 的内核策略，沙箱流量没法绕过检查。
第三层，凭证隔离：v0.4 的 Credential Vault 让 agent 调外部 API 时密钥不进沙箱——密钥在网关层注入，沙箱里的代码全程看不到。这堵住了"让 agent 把环境变量里的 key 打印出来"这类最常见的窃密路径。
三层叠在一起，即便 agent 被 prompt 注入跑了恶意代码，它也：出不去（网络隔离）、看不到密钥（凭证隔离）、逃不出沙箱（硬件隔离）。
适用场景与踩坑
适合：跑 AI agent 代码执行平台（代码解释器、数据分析、agent 工作流）的团队；对数据合规要求高、不能把代码发到第三方托管沙箱的企业；从 E2B 迁移想自托管的团队；做 RL 训练（SWE-Bench 这类）需要大量短命沙箱的场景——README 的 Demo 里就有 RL 训练和快照/克隆/回滚的演示。
踩坑注意四点。一是 KVM 是硬性前提，没有嵌套虚拟化的云 VM 上跑不了（得选 PVM 或裸金属）。二是 v0.6 的 K8s 部署还是预览阶段，生产用建议先跑 Terraform 单节点或腾讯云部署，K8s 等 Roadmap 里的 CRD/Operator 成熟。三是 E2B 兼容还在补齐中（Roadmap 明确写了 "Close remaining gaps"），个别 E2B 高级特性可能还没对上，迁移前先跑一遍你用到的接口。四是许可证字段的 NOASSERTION 坑——自动化合规扫描时别只信 GitHub API 的 SPDX 字段，要结合 LICENSE 文件和 README 徽章一起判断，实际是 Apache 2.0。
另一个值得留意的是它的社区运营：Cube 100 Program 在找前 100 个在生产环境跑 AI agent 的团队，名额限 100。如果你正好在落地 agent 代码执行，这是个直接和官方互动的入口。
CubeSandbox 不复杂——它不碰模型，只管给 agent 跑代码提供一个硬件隔离的盒子。它做的事是把 MicroVM 的启动压到 60ms、内存压到 5MB、单机密度拉到几千个，再配上 E2B 兼容接口让你无缝接进现有 agent 栈。1.08 万颗星的背后，是 AI agent 从"能写代码"到"能安全地跑代码"这一步被认真对待了。
参考来源
- CubeSandbox GitHub 仓库（10,818 star / 996 fork，Rust，Apache 2.0）：https://github.com/TencentCloud/CubeSandbox
- README 原文（定位、基准、架构、版本）：https://github.com/TencentCloud/CubeSandbox/blob/main/README.md
- 性能基准报告（裸金属）：https://github.com/TencentCloud/CubeSandbox/blob/main/docs/blog/posts/2026-06-01-cubesandbox-perf-benchmark.md
- PVM 云服务器基准报告：https://github.com/TencentCloud/CubeSandbox/blob/main/docs/blog/posts/2026-06-03-cubesandbox-perf-benchmark-pvm.md
- PyPI 包 cubesandbox 0.3.0：https://pypi.org/project/cubesandbox/
- CNCF Landscape 收录：https://landscape.cncf.io/