腾讯开源 CubeSandbox：当 AI 开始替你动手，Sandbox 就不再是可选项

当模型开始运行命令、改代码、访问网络和执行测试时，sandbox 就不再是产品功能，而是训练/推理系统的一层基础设施。

如果你第一次接触 AI Agent，可以先把 sandbox 理解成“给模型临时分配的一台隔离小电脑”。模型可以在里面运行 Python、Shell、测试命令，读写文件，甚至启动一个本地服务；任务结束后，这台小电脑可以销毁、暂停、恢复，或者回滚到某个干净状态。

CubeSandbox 是腾讯云开源的 AI Agent 沙箱项目，GitHub 仓库位于 TencentCloud/CubeSandbox。它是一个快速发展的开源社区项目：仓库创建于 2026-04-10，本地 Git 历史里的首个开源提交是 2026-04-16；截至 2026-07-10，GitHub 公开数据约为 9.5k stars。快速的增长信号不能直接等同于生产成熟度，但说明 AI sandbox / agent runtime 正在成为社区集中关注的基础设施方向。

本文要回答的问题是：为什么 CubeSandbox 这类系统不能简单理解成“启动更快的 Docker”？核心判断是：对 coding agent 和 agent RL 来说，sandbox 需要同时解决隔离、状态复用、调度、网络治理和审计。Docker 主要是应用运行时；CubeSandbox 更接近一个面向 AI Agent 的环境执行层。

先看它在训练/推理系统里的位置。读图时注意，sandbox 不在 GPU 训练链路内部，但它会同时影响 rollout 和 reward：模型动作要进环境，环境结果又会回到上下文或评分系统。

训练/推理架构中的 sandbox 位置

这张图说明了一个容易被忽略的事实：Agent RL 的系统瓶颈不只在 GPU。只要任务要求模型跑代码、访问仓库、执行测试，环境层的创建速度、隔离强度、网络策略和失败归因，都会影响训练吞吐和 reward 质量。

1. 先把 sandbox 讲清楚

传统 LLM 训练里，模型通常只做一件事：给定 prompt，生成 tokens。到了 coding agent，模型会多做几件事：

• 读取仓库里的文件；
• 运行 pytest、npm test或编译命令；
• 根据错误日志继续修改代码；
• 访问包管理器、文档站点或内部服务；
• 最后提交 patch 或答案。

这些动作不能直接跑在 trainer 进程或宿主机上。原因很简单：模型生成的命令不可信，任务依赖也可能互相污染，网络访问还可能泄露 secret。于是平台需要给每条任务准备一个隔离环境，这就是 sandbox 的基本角色。

CubeSandbox README 把自己定位为基于 RustVMM 与 KVM 的安全沙箱服务，支持单机和多机集群，并兼容 E2B SDK。这句话里有三个关键词：

• KVM/MicroVM：隔离边界接近虚拟机，不是普通进程隔离。
• E2B 兼容：已有 Agent 代码可以用熟悉的 Sandbox.create()、commands.run()、files.read()等接口迁移。
• 集群服务：它不是单机命令执行器，而是有 API、调度、代理、网络和存储的数据面。

对新读者来说，可以先记住一句话：sandbox 不是“让模型能跑代码”的按钮，而是“让模型安全、可重复、可规模化地跑代码”的系统。

2. CubeSandbox 的核心定位是环境执行层

下面这张图把 CubeSandbox 的主要组件放在一起。读图时重点看两条链路：创建沙箱走控制面，执行命令和访问服务走数据面。

CubeSandbox 总体架构

CubeSandbox 的组件大致可以分成四类：

官方架构文档也采用控制面和数据面的划分：控制面包括 CubeAPI、CubeMaster、WebUI 和 Redis；数据面包括 Cubelet、CubeShim、CubeHypervisor、CubeCoW、CubeVS、CubeEgress、CubeProxy。README 中的组件表也明确列出了 CubeAPI、CubeMaster、CubeProxy、Cubelet、CubeVS、CubeEgress、CubeHypervisor 和 CubeShim 的职责。

这和我们前面讲 train/serve 系统时的思路一致：上层不要直接关心每个 worker 怎么启动进程，而是通过一个控制器把资源、状态和路由管理起来。区别在于，训练系统管理的是 GPU worker；CubeSandbox 管理的是可执行环境。

3. 为什么它不是普通 Docker wrapper

很多人看到 sandbox 会自然联想到 Docker。这个类比有帮助，但不能停在这里。Docker 容器通常共享宿主机内核，隔离主要依赖 namespace、cgroup、seccomp 等机制。CubeSandbox 的设计重点是 MicroVM：每个 sandbox 在 KVM MicroVM 中运行，有独立 guest kernel。

这张图展示了关键路径。读图时注意，containerd 还在，但它不是终点；CubeShim 把 containerd 的生命周期接口接到 CubeHypervisor，最后启动的是 MicroVM。

containerd 到 MicroVM 的执行路径

CubeSandbox 架构文档里说，CubeShim 实现 containerd Shim v2 接口，作为容器运行时抽象与实际 MicroVM 之间的桥梁；CubeHypervisor 基于 RustVMM 和 KVM 管理 MicroVM 的 vCPU、内存、virtio 设备、启动、暂停、快照和恢复。README 也把 CubeHypervisor 和 CubeShim 放在虚拟化层：CubeShim 实现 containerd Shim v2，CubeHypervisor 管理 KVM MicroVM。

所以更准确的理解是：CubeSandbox 借用了 container-like 的生命周期和镜像生态，但把执行隔离放到了 VM 级别。这一点对 AI Agent 很关键，因为模型生成的代码默认不可信。

4. Snapshot 和 Rollback 解决的是“环境复用”

如果只做一次代码执行，创建一个环境慢一点也许还能忍。训练和评测不一样：一批样本可能要成百上千次创建环境，同一个题目还可能采样多条 trajectory。每次都从零安装依赖，会让 GPU 等 CPU、等磁盘、等网络。

下面这张图解释 template、snapshot、clone 和 rollback 的关系。读图时重点看：训练阶段希望从一个干净、已预热的环境快速派生很多副本，然后在执行完后回收或回滚。

Template、Snapshot、Clone 与 Rollback

CubeSandbox 的示例把 snapshot、rollback、clone 作为一组 API 展示：可以创建快照、列出快照、从快照启动新沙箱、从运行中沙箱克隆多个沙箱，也可以原地 rollback。架构文档还说明，CubeCoW 通过内核 FICLONE在 XFS reflink 上实现快照和克隆，模板启动时会克隆 rootfs 与内存卷，再由 CubeShim 从内存快照恢复 VM。

放到 coding RL 里，这个能力对应一个非常朴素的需求：同一条 SWE-bench 样本要从固定 commit、固定依赖、固定初始文件系统出发。否则 reward 结果可能不是模型能力差异，而是环境漂移。

5. 网络和 secret 是 Agent 环境的硬边界

模型能运行命令之后，安全问题不再只是“别破坏宿主机”。还包括：能不能访问公网？能不能访问内网？API key 怎么给？日志里会不会泄露 secret？

这张图展示 CubeVS 和 CubeEgress 的分工。读图时注意，CubeVS 更靠近内核态网络路径，CubeEgress 更靠近 L7 出站策略、凭证注入和审计。

CubeVS 与 CubeEgress 出站治理

网络架构文档说明，CubeVS 用三个 eBPF 程序替代传统 Linux Bridge、OVS 或基于 iptables 的路径，并在 TAP 设备、宿主机网卡和本机代理边界处理 NAT、策略和端口映射。逐沙箱网络策略用 allow_out和 deny_out两组 LPM Trie 表达，策略可在运行时更新。

CubeEgress 则处理更上层的 HTTP/HTTPS 请求。安全代理文档写明，它会拦截沙箱发起的出方向 HTTP/HTTPS 请求，按规则做域名过滤、凭证注入和访问审计。凭证注入的关键点是：工作负载发请求时不带 Authorization，CubeEgress 命中规则后再注入 header，secret 不进入沙箱环境变量、文件系统或进程空间。

这对训练系统很重要。很多任务需要访问 PyPI、npm、GitHub 或内部制品库，但不应该允许模型随便扫内网、读取 secret，或者把 key 写进日志。把这些边界放在 sandbox 平台层，比在 reward 脚本里临时过滤字符串可靠得多。

6. 什么时候应该用 CubeSandbox

CubeSandbox 不是所有场景的默认答案。它的价值来自“强隔离 + 快速复用 + 网络治理 + 集群化管理”，也会带来 KVM、Linux 网络、节点运维和模板管理成本。

下面这张图给出一个选型判断。读图时不要只看“能不能跑代码”，而要看任务是否需要不可信代码、多租户隔离、可复现环境和大批量并发。

CubeSandbox 选型判断

一个务实判断是：

• 如果只是本地 PoC，普通 Docker 或托管 sandbox 可能更快。
• 如果运行的是内部可信代码，Kubernetes/Docker 通常够用。
• 如果任务来自模型生成代码、需要多租户隔离、要保留审计，MicroVM sandbox 更值得评估。
• 如果要做 coding agent eval、SWE-bench rollout 或 agent RL，template/snapshot/egress/metadata 会直接影响系统稳定性。
• 如果团队没有 KVM、Linux 网络和节点运维能力，自托管成本需要提前计算。

7. 相关开源项目地图

为了把 CubeSandbox 放进更大的生态里，可以把相关项目按“离业务有多近”分层看。下面不是完整榜单，而是帮助读者建立全局坐标：有的项目提供托管 sandbox 和 SDK，有的项目做通用 sandbox API，有的项目更靠近底层隔离运行时。

这样看，CubeSandbox 处在中间层：比 Firecracker/Kata/gVisor 更靠近 Agent 平台，因为它提供 API、调度、template、snapshot、proxy 和 egress；又比纯 SDK/托管服务更靠近基础设施，因为它需要团队自己管理节点、网络、存储和安全策略。

8. 趋势判断：OpenClaw 热度会波动，环境执行层会变重

OpenClaw 这类项目的热度可能会起伏。一个具体项目从爆红到回落，并不稀奇：早期用户会被“个人 AI 助手”“聊天入口控制工具”“本地运行 Agent”吸引，随后真正留下来的，是办公、研发、运维、数据分析等场景里那些需要长期稳定运行的任务。

但 CubeSandbox 的价值不完全依赖某一个 Agent 项目的热度。更大的趋势是：AI 会进入越来越多办公场景，从“回答问题”走向“执行任务”。当 Agent 开始帮人处理邮件、改表格、跑脚本、查日志、改代码、调用内部系统时，企业和团队首先要问的不是“模型聪不聪明”，而是：

• 这些动作在哪里执行？
• 会不会误删文件或污染宿主机？
• 能不能限制访问哪些网络和 API？
• secret 会不会进入模型上下文或日志？
• 出错以后能不能复现、回滚和审计？

从这个角度看，OpenClaw-style agent 解决的是“用户从哪里发起任务、Agent 如何组织工具和上下文”；CubeSandbox 解决的是“这些工具动作在哪里安全执行、如何复现、如何限制网络和 secret、如何审计失败”。前者更像入口和控制面，后者是环境执行层。

所以即使 OpenClaw 项目本身热度回落，CubeSandbox 这类执行层的价值反而可能继续放大。只要 Agent 从个人玩具进入真实办公和企业流程，就需要把不可信代码、文件操作、网络访问和外部凭证放进一个可治理的边界里。热度会迁移，执行层需求不会消失。

小结：环境执行层进入 train/serve 系统

CubeSandbox 不是“更快的 Docker”这个判断，背后有一条更大的系统线索：

LLM generates actions
-> sandbox executes actions
-> files / logs / tests / network become observations
-> reward or next turn depends on environment result
-> training system updates policy

当模型只是生成文本时，训练系统主要关心 token、logprob、reward 和 GPU worker。当模型开始操作环境时，训练系统还必须关心环境的隔离、复用、网络、secret、审计、失败类型和容量规划。

下一篇会继续往 veRL 里走：CubeSandbox 作为环境层，究竟是接到 reward function，还是接到 AgentLoop？这两个路径的训练含义完全不同。