如何使用斯莫尔虚拟机（开源微虚拟机沙箱）安全运行人工智能生成的代码

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

你的人工智能代理刚刚编写了一些 Python 代码。你敢在自己的笔记本电脑上运行它吗？

如果答案是“不太敢”——你并不孤单。每个构建智能代理的团队最终都会遇到同样的瓶颈：大型语言模型生成的代码是新的不可信输入，而我们常用的大多数工具（Docker、子进程、exec）并非为此设计。

我们构建了 SmolVM 来解决这个问题。它是一个开源的、基于 Firecracker 的微虚拟机沙箱，为人工智能代理提供专属的一次性计算机——启动时间不到一秒，在硬件级别实现隔离，并在代理任务完成后自动销毁。

在本文中，我将详细介绍：

• 为什么在 Docker 中运行人工智能生成的代码是个坏主意
• 微虚拟机能提供而容器无法提供的优势
• SmolVM 快速入门（只需三行 Python 代码）
• 实际用例：编程代理、浏览器代理，以及赋予代理访问你的代码仓库的权限
• SmolVM 与 Docker、E2B 和 firecracker-containerd 的对比
• 常见问题解答

让我们开始吧。

问题所在：大型语言模型生成的代码是不可信输入

任何发布编程代理、应用构建器、设计转代码工具或工作流自动化产品的团队，最终都需要执行由模型编写的代码。这些代码可能会：

• 使用 rm -rf 删除你在乎的重要文件
• 从你的环境中窃取机密信息
• 向攻击者控制的服务器发起出站调用
• 安装执行上述任何操作的依赖项
• 将中央处理器占用率锁定在 100%，导致主机过热或崩溃

即使模型对齐良好，来自工具输出、网页或粘贴文档的提示词注入也可能重定向其行为。正确的思维模式是：将每一个代码建议都视为来自互联网上的随机陌生人，因为实际上确实如此。

这意味着你需要一个沙箱环境。而大多数团队此时会选择 Docker——这正是麻烦开始的地方。

为什么 Docker 不足以作为人工智能代理的沙箱

容器在打包和部署方面表现出色。但对于不可信代码的执行，它们并不是你想要依赖的安全边界。

核心问题在于：容器共享宿主机的内核。容器内的进程只是一个包裹在某些命名空间和控制组中的普通 Linux 进程。如果内核存在提权漏洞（每年都会有新漏洞出现），容器逃逸就会导致宿主机被攻陷。runc 的通用漏洞披露事件屡见不鲜。攻击面巨大。

微虚拟机采取了不同的方法：在代理代码和你的宿主机之间，使用真正的管理程序、真正的 guest 内核以及硬件虚拟化边界（Intel VT-x、AMD-V、ARM 虚拟化扩展）。攻击面大幅缩小。

过去的权衡因素是速度——完整的虚拟机需要 30 秒以上才能启动，这对于 ephemeral（短暂存在）的代理沙箱来说是无法使用的。Firecracker（支持 AWS Lambda 和 Fargate 的微虚拟机）解决了这个问题。如今，微虚拟机的启动时间在 500 毫秒以内，这使得它们在实际应用中能够为每个请求提供隔离环境。

SmolVM 将 Firecracker（在 Linux 上）和 QEMU（在 macOS 上）封装在一个简洁的 Python API 中，因此你无需手动处理 TAP 设备、根文件系统镜像或 vsock。

SmolVM 快速入门

只需一条命令即可安装 SmolVM：

curl -sSL https://celesto.ai/install.sh | bash

这将安装你所需的一切（包括 Python），配置你的机器，并验证设置。