近日，Cube Sandbox v0.7.0 正式发布，欢迎大家点亮项目：https://github.com/tencentcloud/CubeSandbox
4 月第一次开源时，Cube Sandbox 最容易被记住的是“快”：基于 RustVMM 与 KVM，面向 Agent 提供硬件级隔离沙箱，端到端冷启动可以做到 60ms 以内，单实例额外内存开销低于 5MB。
但一个 Sandbox 项目要真正进入开发者的生产环境，光跑得快还不够。
上一个版本，Cube 一口气补上了社区呼声最高的两大能力：Kubernetes 部署和 Volume。v0.6.0 支持通过 Helm Chart 将控制面和计算节点直接部署到 Kubernetes 集群，同时引入兼容 E2B 标准的 Volume 框架，让 Cube Sandbox 更容易接进开发者已有的计算和存储体系。
当 Sandbox 开始以集群化方式运行，新的问题也随之出现：沙箱能不能跨节点恢复？集群升级后，已有的 Template 和 Snapshot 还能不能继续用？这就是 v0.7.0 要解决的问题。
v0.7.0 发布：沙箱终于可以在机器之间“流动”了
在 v0.6.0 中，CubeSandbox 开始进入 Kubernetes 集群，并补齐了兼容 E2B 的 Volume 框架。但当不少团队真正把集群跑起来后，一个问题很快暴露出来：沙箱只能待在一开始的那台机器上。
过去，沙箱的 pause/resume 与基于快照的创建都绑定在单台宿主机上。在哪台机器暂停，就只能在哪台机器恢复，在生产环境里，这可能直接影响节点运维。比如，一台计算节点需要下线检修，如果上面还挂着一批暂停的沙箱，过去只能等待它们在本机恢复，或者直接丢弃。对于 Agent 训练这类需要大规模并行、频繁暂停恢复的场景，调度器也无法根据各节点的实时负载，把沙箱重新放到更空闲的机器上。
最新发布的 v0.7.0，重点解决的就是这个问题。v0.7.0 基于 S3 后端存储，将沙箱的内存与文件系统状态落到共享对象存储，从而支持在 A 节点暂停、在 B 节点恢复，也支持在任意已同步节点上用同一份快照拉起新沙箱。
这项升级更重要的变化，是沙箱的状态开始与单台宿主机解耦。对一个集群来说，暂停后的沙箱不再被固定在某个节点上，节点排空、资源调度也因此有了更大的操作空间。换句话说，跨机恢复解决的不只是一次 pause/resume 能不能换台机器完成的问题，它也让 Cube 开始具备更灵活地管理集群状态的基础。
跨机流动之外，v0.7.0 还补上了另一个与生产集群密切相关的问题：升级。过去，不同时间构建的模板和快照可能依赖不同版本的运行时组件。一旦组件升级，老模板和快照就可能失效，只能重新制作。v0.7.0 支持组件多版本共存，让计算节点保留历史版本组件，模板和快照不再因为组件升级而失效，已有实例的 pause/resume 也不会被升级打断。
另外两项核心更新分别落在网络和运维上。网络侧，NetworkAgent 被整体合并到 Cubelet，减少沙箱创建过程中的 RPC 调用，同时优化 eBPF 网络策略下发和高并发下的 TAP 设备分配；运维侧，节点管理从 CubeMaster 迁移至 CubeOps，进一步明确“CubeMaster 负责调度、CubeOps 负责运维”的职责边界。
从跨机暂停恢复、组件多版本共存，到网络和运维架构调整，Cube 开始从关注单个 Sandbox 的启动与运行，继续往集群级状态管理和生产运维演进。这些能力最终有没有价值，还是要回到真实业务里看。
联想研究院 AI Lab 和云知声的两个案例，恰好提供了两个不同的观察切面。
从云端 Agent 到 RL rollout，Cube 正跑进更多生产场景
案例一：联想云端 Agent 的沙箱迁移与演进
联想研究院 AI Lab 的云端 Agent 最初使用 Daytona 作为沙箱，用户通过会话与 Agent 交互时，代码执行、文件操作、浏览器自动化等动作都会放到沙箱中完成，每次会话启动时新建一个沙箱。
随着产品功能增加，沙箱里预装的 Playwright、noVNC 等软件越来越多，启动时间一度超过 10 秒。团队经过优化，将其压缩到 5 秒左右，但代码复杂度也明显增加。与此同时，Daytona SaaS 版需要通过企业 VPN 访问，还会产生 SaaS 服务费用。启动速度、网络和成本几个问题叠加后，团队开始寻找替代方案。
联想研究院 AI Lab 在相同配置下对 Cube 进行了测试，沙箱启动时间从 10 秒以上降到了 100 毫秒以下。本地部署也省去了 SaaS 服务费用，以及通过企业 VPN 访问的限制。
谈到迁移经验时，联想 AI 研发工程师李健表示，“其实没有想象的麻烦，我们的迁移还是比较顺利的，功能方面基本都能覆盖住 Daytona 的功能”。
在他看来，迁移的关键不是直接替换，而是先做好适配层，在过渡阶段同时支持 Daytona 和 E2B 两套接口，尽量保证业务连续性。模板制作的成本也比预想中低，Cube 本地部署后，可以借助 AI 辅助完成镜像制作，再转换成 Cube 模板。
真正需要提前规划的，是 Volume 和快照策略。尤其当沙箱从 1.0 的短生命周期环境走向 2.0 的长期运行模式后，哪些数据需要持久化、哪些沙箱需要定时快照、节点重启后如何恢复，都会成为需要提前考虑的问题。
案例二：云知声 RL rollout 场景下的 CubeSandbox 密度边界压测
云知声用 Cube 支撑的是 SWE Agent 数据合成和 Agent RL 环境训练。这类任务里的沙箱通常只有分钟级生命周期，但数量大、创建和销毁频繁。每条轨迹都需要一个干净、隔离、可复现的执行环境，而沙箱里运行的又是模型生成的任意代码，死循环、内存泄漏、fork 炸弹等情况都可能出现，因此隔离能力和创建吞吐都是选型时的重要指标。
Cube 的每个沙箱运行在独立的 KVM MicroVM 中，拥有自己的内核，同时兼容 E2B 协议，云知声训练侧可以直接通过 E2B SDK 接入。毫秒级启动能力，也更适合 rollout 场景下高频创建和销毁沙箱的负载特点。
真正进入实际训练后，云知声进一步测试了 Cube 的单机密度边界。
在 128 核、251 GiB 的单机上，单个沙箱配置为 1 核、4096 MiB 内存。按照当时的资源预留和超卖配置，单节点账面并发上限约为 117 个；不依赖内存超卖时约为 58 个；实际运行中，单节点稳态并发落在 80-100 个左右。
给开源同路人的彩蛋
如果你也在关注 Agent Sandbox、Agent Infra，或者正在实际评估这类技术，欢迎顺手把 Cube 分享给更多开发者。
参与方式很简单：
将本文，或 Cube Sandbox 项目截图、项目链接，分享至朋友圈、技术社群、小红书等平台，分享时请附上简要的观点或思考，内容无需太长，100 字左右即可；
分享完成后，扫描下方二维码，发送分享截图；
即可领取一份 Cube 为开发者准备的神秘礼品。
Cube Sandbox 项目地址：
https://github.com/tencentcloud/CubeSandbox
不需要复杂任务，也不需要集赞。一次分享，就算加入这场开源同行。礼品数量有限（限量 20 份），先到先得！
活动截止日期：2026 年 9 月 24 日
