文章目录

1. 为什么要聊 CubeSandbox？

在前面博主聊了 Anthropic 的一篇文章《https://www.anthropic.com/engineering/managed-agents》，这篇文章主要围绕如下几个观点来写：

  1. 未来的 AI Agent，不应该被塞进一个大容器里。
  2. 大脑负责思考，双手负责执行，状态单独保存。
  3. 只有这样，Agent 才能长期运行、可靠恢复、安全扩展。

对于小白来说，这听起来有点抽象，可以换个更生活化的说法：一个 AI Agent 可以理解成一个 “会思考、会干活的数字员工”。

  • 它的大脑，是大模型，比如 ：Claude、GPT、DeepSeek。
  • 它的双手，是它能调用的工具，比如：执行 Python 代码、操作 Shell、读写文件、 跑测试、打开浏览器、克隆 Git 仓库、修改代码、部署服务等

问题来了：如果 AI 写了一段代码，要在哪里运行？

  • 直接在你的电脑上运行？太危险。
  • 直接在服务器上运行？也危险。
  • 放进默认 Docker 容器？有隔离，但面对不可信代码时，安全边界还不够彻底。
  • 用传统虚拟机？安全，但启动慢、资源重。

这时候，就需要一个东西：沙箱。而今天要聊的 CubeSandbox，就是腾讯云开源的一个面向 AI Agent 的高性能安全沙箱，它的定位非常直接：

一个极速启动、高并发、安全且轻量化的 AI Agent 沙箱服务。

在这里插入图片描述

2. 为什么 AI Agent 需要沙箱？

过去我们使用 AI，大多数时候只是“问答”，你问一句，它答一句，比如：

“帮我写一个排序算法。”

AI 返回一段代码，这个过程基本是安全的，因为它只是生成文本，但 Agent 不一样，Agent 不只是回答，它还要执行，比如你对一个编程 Agent 说：

“帮我修复这个项目里的 Bug，并跑一下单元测试。”

它可能会自动执行：

git clone xxx
npm install
npm test
python script.py
rm -rf temp
curl some-url

这时候风险就来了，例如：

  • 大模型生成的代码不一定可靠。
  • 外部仓库里的代码也不一定安全。
  • Prompt Injection 甚至可能诱导 Agent 读取环境变量、访问密钥、连接外部网络。

Anthropic 在 Managed Agents 那篇文章里也提到过一个关键问题：如果让模型生成的代码和凭证处在同一个容器里，一旦发生提示词注入，攻击者可能诱导模型读取环境变量里的 token。

Anthropic 的解决思路是：凭证不要出现在沙箱里，沙箱只负责执行。这就是“大脑”和“双手”解耦的价值。

  • 大脑负责推理。
  • 沙箱负责执行。
  • 凭证、状态、上下文，都不要随便暴露给执行环境。

所以Agent 越强，沙箱越重要。

3. 沙箱到底解决什么问题？

很多人一听 “沙箱” 就觉得很底层。其实它并不难理解，可以把沙箱想象成一个“隔离实验室”。

  • AI 想运行代码，可以。
  • AI 想操作文件，可以。
  • AI 想安装依赖，也可以。

但所有动作都发生在一个隔离环境里。它就像一个临时房间：

  • AI 可以在里面干活
  • 干坏了可以直接销毁
  • 不影响宿主机
  • 不污染真实系统
  • 不轻易接触敏感凭证
  • 必要时还能限制网络访问

对于普通开发者来说，沙箱就是：

给 AI Agent 准备的一台“用完即扔”的安全电脑。

4. 为什么 Docker 容器还不够？

很多人可能会问：“这不就是 Docker 吗？”。确实，Docker 也能做隔离，而且非常常见，但在 AI Agent 场景下，Docker 有几个问题。

第一：默认 Docker 容器共享宿主机内核。
它的隔离主要依赖 Namespace、Cgroups 等机制。对于普通应用部署来说够用，但如果你要运行“未知代码”“模型生成代码”“不可信任务”，安全边界就会更敏感。当然，Docker 也可以配合 seccomp、AppArmor、SELinux、rootless、gVisor、Kata 等方案增强隔离，但这已经不是最基础的默认容器隔离模型了。

第二：Agent 的并发量可能非常大。
未来一个平台里可能同时跑几百、几千个 Agent，每个 Agent 都需要自己的执行环境。如果沙箱启动慢、内存重，成本会很快上去。

第三：Agent 的任务形态更复杂。
它不只是跑一个脚本，还可能要跑浏览器、Shell、代码解释器、文件系统、网络代理，甚至涉及暂停、恢复、快照、回滚等能力。

所以，AI Agent 需要的不是传统意义上的“应用容器”，而是一个更适合自动化执行、不可信代码执行、高并发调度的沙箱底座，这正是 CubeSandbox 想解决的问题。

5. CubeSandbox 是什么？

CubeSandbox 是腾讯云开源的 AI Agent 沙箱服务。

Github地址：https://github.com/TencentCloud/CubeSandbox

官方 README 里对它的描述是：它基于 RustVMM 与 KVM 构建，支持单机部署，也可以扩展到多机器集群，同时兼容 E2B SDK，可以在 60ms 左右创建一个具备服务能力的硬件隔离沙箱环境，并保持小于 5MB 的基础内存开销。

这句话信息量很大，这里拆开讲。

5.1 MicroVM 沙箱：比普通容器隔离更强

CubeSandbox 底层基于 KVM，也就是硬件虚拟化能力。

简单理解：如果把默认 Docker 容器理解为在同一个大楼里隔出很多房间，那么 CubeSandbox 更像是给每个 Agent 分配一个独立小房子。

每个沙箱都有独立的 Guest OS 内核，不是简单共享宿主机内核。官方也强调它具备“真正的内核级隔离”，每个 Agent 拥有独立 Guest OS 内核，用来降低容器逃逸风险，这对 AI Agent 很关键，因为 Agent 执行的代码经常是不确定的，你不能完全相信模型生成的代码，也不能完全相信外部项目里的脚本，所以隔离级别越强，越适合生产环境。

5.2 冷启动：百毫秒级创建执行环境

传统虚拟机安全但慢，一台完整 VM 启动可能要秒级甚至更久，但 Agent 调用工具时，用户最敏感的是等待时间。

Anthropic 在 Managed Agents 文章里提到，他们把大脑和双手解耦后，只有在真正需要执行环境时才创建容器，从而显著降低 Time-to-First-Token：p50 下降约 60%，p95 下降超过 90%。

这说明 Agent 系统不能一上来就把所有东西都启动好，它应该按需调用“手”，而一旦按需调用，沙箱启动速度就非常关键。
在这里插入图片描述

CubeSandbox 的卖点之一就是冷启动快，官方 README 写到，它 通过资源池化预置和快照克隆技术，端到端冷启动一个可服务沙箱平均小于 60ms。不过这里要注意官方给出的测试边界：这个冷启动数据基于裸金属环境；单并发下约 60ms，50 并发创建时平均 67ms，P95 90ms，P99 137ms，整体保持在百毫秒级。这意味着：

  • AI 需要执行代码时，沙箱可以很快拉起来。
  • 任务结束后，沙箱可以销毁。
  • 下一次再需要，再快速创建。

这就很适合 Agent 的调用模式。

5.3 低开销：单实例基础内存小于 5MB

安全的东西通常重，快的东西通常隔离弱，而 CubeSandbox 想做的是两者兼得。

在这里插入图片描述

官方数据里提到，CubeSandbox 基于 CoW 技术实现内存复用，并用 Rust 重构底层进行裁剪，单实例基础内存开销低至小于 5MB，可以在一台机器上跑数千个 Agent。官方同时说明，这个内存开销数据基于不超过 32GB 规格的沙箱测试，更大规格下开销可能会略有上升。

这点非常重要，因为 Agent 的未来不是“一个用户跑一个任务”，而可能是：

  • 一个用户开多个 Agent
  • 一个团队同时运行大量 Agent
  • 一个 SaaS 平台给很多客户提供 Agent 执行环境
  • 一个评测系统同时跑大量代码任务
  • 一个 RL 训练系统同时启动大量环境

如果每个沙箱都像传统 VM 一样重，成本会非常高。

CubeSandbox 的价值就在于 它试图把虚拟机级隔离做得像容器一样轻。

5.4 CubeSandbox 在 Agent 架构中的位置

如果用 Anthropic 的架构语言来看，一个完整 Agent 系统大概可以拆成三块：

组件 作用 类比
Brain 大模型 + Harness，负责思考和调度 大脑
Session 记录任务过程、上下文、事件日志 记忆
Sandbox / Tools 执行代码、操作文件、访问环境 双手

Managed Agents 强调的是：不要把大脑、记忆、双手全部塞进一个容器里。因为一旦耦合太深，就会遇到几个问题：

  • 容器挂了，状态可能丢
  • 执行环境卡住，大脑也受影响
  • 用户资源在不同网络里，很难接入
  • 凭证和代码执行环境混在一起，安全风险高
  • 很难扩展到“多个大脑、多个双手”

Anthropic 的做法是让沙箱变成一种工具接口：execute(name, input) → string。大脑只需要知道“我要调用哪个手、传什么参数、拿什么结果”，不需要关心这个手到底是容器、浏览器、手机，还是模拟器。而 CubeSandbox 正好可以被理解成这个架构里的“高性能双手”。

  • 它不负责替你做大模型推理。
  • 它不负责替你设计 Agent Harness。
  • 它主要解决的是：当 Agent 决定要执行代码时，去哪里安全、快速、低成本地执行？

所以，如果你已经有一个 Agent 框架，CubeSandbox 可以作为底层执行环境。如果你正在做 AI 编程助手、代码解释器、自动化测试、浏览器自动化、RL 训练环境，它就可以成为 Agent 的 “执行底座”。

6. CubeSandbox 的典型使用场景

场景一：AI 代码解释器

比如用户让 AI 写一段 Python 并执行：

print("Hello Agent")

如果直接在宿主机跑，有风险，每次启动传统 VM，太慢，而CubeSandbox 可以提供一个快速启动、隔离运行的代码解释器环境。

官方快速开始里也展示了用 E2B Code Interpreter SDK 创建沙箱并运行代码的示例。只需要设置 E2B_API_URL、E2B_API_KEY、CUBE_TEMPLATE_ID 等变量，就可以通过 E2B SDK 调用 CubeSandbox。

场景二：AI 编程助手

类似 Claude Code、Cursor Agent、OpenAI Codex 这类工具，未来都需要安全执行：

  • 安装依赖
  • 跑测试
  • 编译项目
  • 执行脚本
  • 修改文件
  • 验证结果

如果你要做企业内部的 AI 编程平台，就不能让 Agent 随便在真实服务器上跑命令，CubeSandbox 可以给每个任务分配一个独立环境，用完销毁。

场景三：自动化测试与评测

比如 SWE-Bench 这类代码修复评测，需要反复创建环境、运行测试、对比结果。

这类场景有几个特点：并发高、环境多、任务短、需要隔离以及成本敏感。

CubeSandbox 官方示例目录也覆盖代码执行、Shell 命令、文件操作、浏览器自动化、网络策略、暂停/恢复、OpenClaw 集成、RL 训练等场景。至于事件级快照回滚，官方 README 目前标注为 coming soon，更适合作为后续规划能力来理解。

场景四：浏览器自动化

很多 Agent 不只是写代码，还要打开网页、点击按钮、抓取内容、执行浏览器任务。这类任务也适合放在沙箱里，因为网页环境复杂，可能存在恶意内容、诱导提示词、下载脚本等风险。

场景五：企业内部 Agent 平台

如果企业想做自己的 Agent 平台，底层一定需要执行环境管理能力：

  • 谁创建了沙箱
  • 沙箱跑在哪台机器
  • 网络能不能访问外部
  • 能不能访问内网
  • 资源怎么限制
  • 任务失败怎么回收
  • 并发怎么调度

CubeSandbox 的架构里包含 CubeAPI、CubeMaster、CubeProxy、Cubelet、CubeVS、CubeHypervisor、CubeShim 等组件。其中 CubeMaster 负责编排调度，Cubelet 管理单节点沙箱生命周期，CubeVS 基于 eBPF 提供网络隔离与安全策略支持。

在这里插入图片描述

这说明它不是一个简单 demo，而是偏生产级的沙箱服务设计。

7. CubeSandbox 和 E2B 是什么关系？

如果大家关注 AI Agent 生态，可能听过 E2B，它是一个比较知名的 AI Agent 沙箱服务，很多代码解释器、Agent 项目会用它来执行代码。

CubeSandbox 的一个重要特点是：兼容 E2B SDK。

官方 README 里写到，它支持“零成本迁移”，原生兼容 E2B SDK 接口规范，只需要替换 URL 环境变量，无需业务代码改动就可以切换到 CubeSandbox。

这点很关键。因为开发者最怕不是新工具不好，而是迁移成本太高，如果原来已经基于 E2B SDK 写了代码，那么切换到底层 CubeSandbox，通常不需要大改业务调用逻辑，这就像数据库兼容 MySQL 协议，你不用重写应用，只需要换连接地址。当然，这里的“零成本迁移”主要指 SDK 接口和业务调用层面的兼容，实际部署时仍然需要准备 CubeSandbox 服务、模板 ID、证书等环境配置。

8. CubeSandbox 适合哪些人？

我觉得 CubeSandbox 不太像一个面向普通终端用户的软件，它更适合下面几类人：

  • Agent 平台开发者：如果你正在做自己的 AI Agent 平台，需要让 Agent 执行代码、跑命令、操作文件，那么需要一个安全执行环境，CubeSandbox 就是这类系统的底层基础设施。
  • AI 编程工具团队：如果你在做类似 Claude Code、Cursor、Devin、OpenHands 这类 AI 编程助手，那么沙箱几乎是必需品，否则你很难放心让 AI 自动跑项目里的命令。
  • 企业内部 AI 基础设施团队：企业内部使用 AI Agent，最敏感的是安全，代码、凭证、内网资源、数据库连接都不能随便暴露，这时候，使用强隔离沙箱会比简单 Docker 更稳妥。
  • 做 AI 评测、RL、自动化实验的人：高并发、低成本、快速创建、快速销毁，是这类场景的刚需，CubeSandbox 单机高密度部署、毫秒级启动、低内存开销的设计，正好对应这类需求。

9. CubeSandbox 怎么安装？

CubeSandbox 需要一台支持 KVM 的 x86_64 Linux 环境。官方说明里提到，WSL 2、Linux 物理机、云上裸金属、普通云服务器通过 PVM 都可以。官方快速开始大致分四步：

  1. 准备运行环境：可以克隆 CubeSandbox 仓库，并进入 dev-env 准备一次性 Linux 环境。
  2. 启动 Cube 沙箱服务：国内用户可以走 CDN 镜像，海外用户可以从 GitHub 下载一键安装脚本。
  3. 制作代码解释器沙箱模板：官方提供了预构建镜像，可以用 cubemastercli tpl create-from-image 创建模板。
  4. 运行第一段 Agent 代码：安装 e2b-code-interpreter，设置环境变量，然后直接使用 E2B SDK 创建沙箱并运行代码。

对于普通读者来说，可以不用记命令，只要理解一点：CubeSandbox 不是一个桌面 App，而是一个需要部署在支持 KVM 的 Linux 环境里的沙箱服务。部署好以后，Agent 平台或代码解释器可以通过 API 去调用它。

10. 总结

如果说 Managed Agents 告诉我们：

未来 Agent 架构应该把“大脑、记忆、双手”解耦。

那么 CubeSandbox 解决的就是其中非常关键的一环：

给 AI Agent 提供一双安全、快速、低成本、可规模化的“手”。

大模型越来越聪明，Agent 会越来越主动，它们不再只是回答问题，而是会写代码、跑命令、调工具、操作网页、完成任务。但 Agent 越能干，风险也越大，所以，真正的 Agent 基础设施，不只是模型，不只是 Prompt，不只是工作流，还必须有一个安全可靠的执行环境。CubeSandbox 的价值就在这里：

它让 AI Agent 的“执行”从危险的真实世界里抽离出来，放进一个可以快速创建、强隔离、可销毁、可调度的沙箱中。

未来的 Agent 不是只有一个聪明的大脑，它还需要很多双手，而 CubeSandbox，就是在给这些“手”打造基础设施。

Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

cover

深度拆解 Headroom：AI Agent 的「上下文压缩层」，Token 暴降 60-95% 的背后原理

avatar AI Agent技术社区
cover

接手项目后，我对 Claude Code 说的第一句话（附 Prompt 模板）

avatar AI Agent技术社区
cover

ChatGPT生成excel表格，AI导出鸭帮工程师终结格式乱码噩梦

avatar AI Agent技术社区