如果你的 AI Agent 能写代码，那它完全可能写出糟糕的代码。如果它能调用工具，那它也可能用错参数、调错工具。问题的关键不在于设计更精巧的提示词，而在于模型输出和实际运行环境之间，必须存在一道隔离墙。CubeSandbox 就是为构建这道墙而生的系统之一。理解它是什么、它和其他方案有何不同，以及当你的 Agent 开始触碰真实的 API 和数据时它扮演什么角色，这非常值得。
CubeSandbox 是腾讯云开源的一款硬件隔离沙箱服务，专门用于运行 AI Agent 的代码。每个沙箱都通过 KVM 拥有独立的客户机操作系统内核，启动时间大约 60毫秒，内存开销不到 5MB。它采用 Apache 2.0 协议授权，并且与 E2B SDK 无缝兼容。
简介
现在，Agent 系统已经在生产环境中编写并执行代码了。编码 Agent 生成 Python 脚本然后运行；研究 Agent 抓取页面、解析内容再把结果传到下一步；数据 Agent 加载 CSV 文件，执行运行时才决定的转换逻辑。这些代码在运行之前，都没有经过人工审核。这就是 Agent 沙箱要解决的核心问题：你得执行这些不可信的、模型生成的指令，但不让它们碰到宿主机、文件系统、凭据或者网络。
随着 Agent 获得越来越多的自主权，这一点变得尤其关键。一个写错 SQL 查询的模型顶多让人头疼，但一个写错 rm -rf 或者执行了网页中注入指令的模型，那就是一起安全事故。沙箱划定了一道硬性防线：Agent 可以在一次性的、隔离的环境里做任何想做的事，而它的任何行为都不会泄露出去。
还有一个更隐蔽的问题。Agent 不只是运行代码，它们还会调用 API 和工具。在你信任 Agent 从沙箱内部访问你的支付 API 或内部服务之前，你得先确保这些 API 的行为是正确的，并且 Agent 确实按你预期的方式调用了它们。这就是 API 工具在运行时隔离之外的价值所在。像 Apifox 这样的平台可以让你模拟和测试 Agent 将要调用的端点，从而在自主系统开始驱动真实环境之前，先验证好契约。如果你已经在思考 Agent 架构，那 Agentic AI 架构指南 会详细解释这些执行层和工具层是如何结合在一起的。
接下来，我们来具体看看什么是 CubeSandbox，为什么 Agent 根本需要沙箱，不同的隔离模型有何区别，以及这和测试 Agent 所依赖的 API 有什么联系。
什么是 CubeSandbox？
CubeSandbox 是一个用于运行 AI Agent 代码的安全沙箱系统，由腾讯云于 2026 年 4 月以 Apache 2.0 协议开源。它的 GitHub 标语很简洁：“为 AI Agent 打造的即时、并发、安全且轻量级的沙箱”。这不只是一个 SDK，而是一整套沙箱即服务的技术栈，主要由 Rust 编写，你可以自行部署。
这套架构基于 RustVMM 和 KVM 构建，KVM 是很多云虚拟化程序使用的 Linux 内核虚拟化层。根据项目文档和官方公告，系统分为几个组件：
- CubeAPI：一个镜像了 E2B 沙箱接口的 REST 网关。
- CubeMaster：负责在节点间调度沙箱的集群编排器。
- CubeHypervisor 和 CubeShim：负责启动和管理每个 microVM 的 KVM 虚拟化层。
- Cubelet 和 CubeProxy：运行并路由至沙箱的节点级袋里。
- CubeVS：基于 eBPF 的网络层，在内核级别强制执行沙箱间的网络隔离。
它的核心特征在于，每个沙箱都拥有自己专用的 Guest OS 内核。这是一种比容器更强大、更稳固的隔离模型，因为容器是共享宿主机内核的。腾讯发布的数据显示，在单并发下冷启动时间约为 60 毫秒（50 个并发创建时平均 67 毫秒，P95 约 90 毫秒），每个实例的内存开销低于 5MB，一台大型宿主机上可以运行数千个沙箱。新闻资料提到，一台 96-vCPU 的服务器能支持 2,000 多个并发沙箱。腾讯表示，CubeSandbox 已经在他们的内部基础设施中大规模运行，MiniMax 也用它来进行跨异构环境的大规模 Agent 强化学习训练。
一些高级功能，比如用于检查点和恢复沙箱状态的事件级快照回滚，目前仍在开发中。对于这些前瞻性项目，最好把它们看作路线图，而不是已经交付的承诺，具体状态可以参考代码仓库。另外，除了厂商自己的数据，公开的基准测试方法比较有限，所以性能声明最好还是根据你自己的实际工作负载来验证。
想了解更权威的细节，可以直接看 CubeSandbox 的 GitHub 仓库和官方文档网站。
为什么 AI Agent 需要沙箱
把威胁具体化会很有帮助，因为“安全”这个词对于设计来说实在太笼统了。有三种典型的失效模式，会推动团队走向沙箱化。
有风险的生成代码。 模型生成了它认为正确的代码，但现实往往不是这样。它可能删错了目录、在死循环里耗尽内存，或者在不该写文件的地方写入文件。这些都不是恶意，只是错误，但拥有宿主机访问权限的错误代码是危险的。除非你给 Agent 设定一个爆炸半径，否则它根本没有这个概念。
不可信的工具调用。 Agent 根据模型在运行时的决定来调用工具和 API。如果模型受到了文档、网页或工具响应中埋藏的提示词注入的引导，它可能会调用具有破坏性的工具，传递受攻击者控制的参数，或者以你从未预料的方式串联调用。在这里，模型不是一个可信的角色，它只是任何进入其上下文窗口的文本的解释器。我们在 AI Agent 作为新的 API 消费者 一文中深入探讨过这个问题，解释了为什么传统的 API 信任假设在面对自主调用者时会失效。
数据泄露。 这一点人们最容易低估。一个拥有网络访问权限和密钥访问权限的 Agent，可能会变成一个泄露通道。一条被污染的指令，可能会告诉 Agent 读取保存 API 密钥的环境变量，然后把它 POST 到外部端点。如果没有出口过滤和凭据隔离，沙箱边界就毫无意义，因为数据会从大门溜走。这就是为什么 CubeSandbox 把内核级隔离和通过 CubeVS 实现的基于 eBPF 的出口过滤结合起来；如果网络完全开放，仅靠进程隔离是不够的。
它们的共同点是：你不能假设 Agent 会表现良好，因为 Agent 的行为部分受它摄入的任何不可信数据控制。沙箱让你不再纠结于模型是否值得信任，而是开始思考一个无论如何都能守住的边界。如果想了解在生产环境之前探测这些行为的实战视角，可以看看 如何测试调用 API 的 AI Agent。
Agent 沙箱如何工作：隔离模型
并非所有沙箱的隔离方式都一样，它们的差异对安全性和性能都有影响。在 Agent 生态系统中，你会看到四种主要方法。
进程级隔离。 使用 seccomp 过滤器、丢弃能力、命名空间和 cgroups，把代码作为受限的操作系统进程运行。这是最轻量但也最薄弱的选择。它共享宿主机内核，所以内核漏洞就意味着宿主机沦陷。对于基本信任的代码还行，但对于任意模型输出就显得单薄了。
容器。 Docker 风格的容器增加了命名空间和资源限制，在操作上也很熟悉。但容器在设计上就是共享宿主机内核的。容器逃逸漏洞是一类真实且反复出现的 Bug，“在共享内核容器中运行不可信代码”是一个已知的薄弱环节。很多团队因为简单而从这里开始，但之后就会遇到隔离瓶颈。
微虚拟机 (MicroVMs)。 MicroVM 在硬件虚拟化 (KVM) 内部启动一个极简的 Guest 内核。Agent 的代码在自己的内核上运行，所以内核级漏洞被限制在一个可以丢弃的虚拟机中，而不是宿主机。Firecracker 为无服务器工作负载普及了这种模型，CubeSandbox 也属于这一类，它使用 RustVMM 和 KVM，为每个沙箱提供独立的 Guest 内核。历史上的权衡是启动时间；MicroVM 的启动速度曾经比容器慢。现代实现通过快照和资源预配置解决了这个问题，这也是 CubeSandbox 报告亚秒级（低于 100 毫秒）启动的原因。
应用内核。 gVisor 走了一条不同的路：它在用户空间拦截系统调用，自己实现类似 Linux 的接口，所以工作负载永远不会直接和宿主机内核通信。这是一个强大的隔离层，不需要完整的虚拟机，但在系统调用兼容性和性能上需要做一些取舍。
下面这个表格，从对 Agent 至关重要的几个维度，对比了这些方法：
| 方法 | 隔离强度 | 冷启动 | 开销 | 内核共享 | 示例 |
|---|---|---|---|---|---|
| 进程 + seccomp | 低 | 即时 | 极小 | 共享宿主机内核 | Restricted subprocess, nsjail |
| 容器 | 中 | ~数十毫秒 | 低 | 共享宿主机内核 | Docker, containerd |
| MicroVM | 高 | ~50–150ms | 低–中 | 专用 Guest 内核 | CubeSandbox, Firecracker |
| 应用内核 | 高 | ~数十毫秒 | 低–中 | 在用户空间拦截 | gVisor |
| 托管沙箱 API | 高 (托管) | 视情况而定 | 为你托管 | 为你托管 | E2B, 托管服务 |
没有唯一的赢家。正确的选择取决于你对代码的信任程度、对冷启动速度的要求、是否支持 KVM，以及你是想自己运维基础设施，还是作为服务来消费。
CubeSandbox 在领域中的位置
CubeSandbox 的定位非常明确：硬件级隔离，冷启动速度快到感觉像容器，并且是以可运行的软件形式部署，而不是租用的服务。这就让它和三个参考点形成了直接对比。
对比容器。 容器共享宿主机内核；CubeSandbox 为每个沙箱提供独立内核。对于任意 Agent 生成的代码，这就是安全论据。代价是你需要一个支持 KVM 的 x86_64 Linux 宿主机（比如裸金属服务器、支持嵌套虚拟化的云虚拟机，或者本地用 WSL 2）。如果你的平台无法暴露 KVM，那基于 MicroVM 的隔离对你来说就不可用，这时像 gVisor 这样的用户空间方法或托管 API 可能更合适。
对比 Firecracker。 Firecracker 是著名的用于无服务器的 MicroVM，它本身是一个构建块，而不是一个 Agent 沙箱产品。CubeSandbox 同样基于 KVM/RustVMM，但它在技术栈中处于更高层级：包含了编排器、E2B 兼容的 API 网关和 eBPF 网络隔离，所以你部署的是一个 Agent 沙箱服务，而不是在组装零件。如果你想要原语，选 Firecracker。如果你想要一个带有 Agent 风格 API 的沙箱服务，CubeSandbox 正是为此而生。
对比 E2B 和托管沙箱。 E2B 把隔离沙箱作为托管服务提供；你只要调用 API，基础设施是别人的事。CubeSandbox 一个值得注意的设计选择是 E2B SDK 兼容性。文档把它描述为无缝替换：把 E2B_API_URL 指向你自托管的 Cube 实例，现有代码就可以继续工作。这样一来，真正的决定就不再是“用哪个沙箱”，而是“用托管服务还是自托管基础设施”，数据驻留、规模化成本和运维所有权才是决定因素。根据腾讯的公告，它还原生支持 OpenAI Python SDK。
诚实地总结一下：CubeSandbox 是 Agent 沙箱领域一个可靠的竞争者，有着清晰的论点（强隔离、快启动、自托管、E2B 兼容）。但它也很新，大部分文档由厂商提供，独立的基准测试较少。在投入使用前，最好针对你的工作负载做个原型测试，亲自衡量冷启动、密度和隔离行为。
这与测试 Agent 调用的 API 和工具如何联系
运行时隔离回答了“如果代码很糟糕怎么办”。它没有回答“如果 Agent 调用的 API 很糟糕，或者 Agent 调用方式错误怎么办”。这是不同的问题，你需要两者兼顾。
想象一个预订旅行的沙箱化 Agent。代码在 CubeSandbox 内部安全运行。但 Agent 仍然会调用航班 API、支付 API 和内部行程服务。如果其中任何一个返回了格式错误的响应，Agent 可能会陷入循环、幻觉出一个恢复方案，或者把错误数据传递到下游。如果它用错误的幂等键调用支付 API，隔离也救不了你；钱还是会被转走。沙箱保护宿主机免受 Agent 侵害，但它不能保护你的系统免受一个向真实服务发起真实调用的混乱 Agent 的侵害。
因此，真正站得住脚的工作流有两个协作层：
- 隔离执行，让模型生成的代码和工具调用无法伤害宿主机或泄露数据。这是 CubeSandbox 的职责。
- 验证契约，在沙箱运行之前和期间，验证 Agent 能接触到的每个 API 和工具。这是 API 工具的职责。
对于第二层，可以模拟依赖项，这样在测试行为时 Agent 和受控的替代品通信，然后测试真实端点的模式一致性、错误处理、认证和边缘情况。使用 Apifox，你可以构建一个返回确定性、符合模式响应的 Mock 服务器，把沙箱化的 Agent 指向它，然后观察 Agent 对成功和失败路径的反应，而不用触及生产环境。当你准备好后，再针对实时 API 运行同样的场景，确认契约有效。我们在 沙箱测试 中的演练，涵盖了在隔离、受控环境中进行测试的一般实践，这里直接适用。
这种配对非常重要，因为 Agent 会放大契约漂移。人类能注意到 API 响应看起来不对劲，但 Agent 通常不会；它直接摄入响应并据此行动。通过 Mock 和测试来强化的严密 API 契约，可以防止自主调用者把单个错误响应复合为连锁反应。如果你的 Agent 使用 Model Context Protocol，那么用 Apifox 测试 MCP 服务器，可以把同样的纪律延伸到工具层。如果你正在为 Agent 消费者设计 API，为 AI Agent 设计 API 涵盖了让自主调用变得可预测的契约模式。
现实世界的用例
在以下几种模式中，隔离加契约的方法显示出它的价值：
编码 Agent 和代码解释器。 模型编写并运行代码来回答问题、转换数据或生成图表。这是最典型的沙箱用例，也是 E2B 兼容 API 直接针对的场景。CubeSandbox 的每个沙箱独立内核在这里很重要，因为代码是完全任意的，每次运行都在变化。
多租户 Agent 平台。 如果很多客户的 Agent 在共享基础设施上执行代码，租户之间的容器级隔离是有风险的。每个沙箱的硬件隔离，给你提供了一个即使某个租户的 Agent 具有敌意也能守住的租户边界。所报告的密度（每台宿主机数千个沙箱）让这种方案变得可行，而不是每个租户一个虚拟机。
Agent 强化学习（RL）和训练循环。 用强化学习训练 Agent，意味着要运行大量短寿命、不可信的 Rollout。腾讯提到，MiniMax 正是在异构环境中把 CubeSandbox 用于这个目的。快速冷启动和低单实例开销，是训练运行能否可行的关键。
使用工具的研究和数据 Agent。 Agent 获取外部内容、解析内容并调用下游 API。获取的内容是不可信的（提示词注入风险），所以解析和生成的代码属于沙箱，而下游 API 应该先针对 Mock 进行演练。这是把隔离和 API 契约测试结合起来收益最高的地方。
不可信的插件或扩展执行。 如果用户可以提供你的 Agent 运行的工具或代码，那么根据定义你就是在执行第三方不可信代码。每个执行一个 MicroVM 边界是合适的姿态，这和当初无服务器平台采用 Firecracker 的理由是一样的。
结论
从 Agent 开始在没有人工审核的情况下执行代码和调用工具那一刻起，Agent 沙箱化就不再是可选项。CubeSandbox 是针对该问题中隔离部分的具体、开源的答案。
关键要点：
- CubeSandbox 是真实且具体的：腾讯云基于 RustVMM 和 KVM 构建的 Apache 2.0 开源 AI Agent 沙箱，每个沙箱有独立的 Guest 内核。
- 隔离模型是核心：对于任意模型生成的代码，每个沙箱专用内核比容器隔离更强大，据报告冷启动低于 100 毫秒，开销低于 5MB。
- E2B 兼容性降低了迁移成本：如果你在用 E2B，文档化的无缝替换路径把选择重新定义为“托管还是自托管”，而不是重写代码。
- 把厂商数据视为起点：性能和密度声明主要来自腾讯；请针对你自己的工作负载进行基准测试，并查看仓库了解哪些功能已发布，哪些仍在开发中。
- 隔离是必要但不充分的：沙箱保护你的宿主机免受 Agent 侵害；它不能保护你的 API 免受调用它们的混乱 Agent 的侵害。
- 将运行时隔离与 API 契约测试相结合：模拟并测试 Agent 能接触到的每个端点，这样单个错误响应就不会引发连锁反应。
如果你的 Agent 会调用你拥有或依赖的 API，请在建立隔离层的同时，也建立契约层。
