Zeroboot Python SDK实战教程:3行代码搭建零依赖的代码执行沙箱
【免费下载链接】zerobootSub-millisecond VM sandboxes for AI agents via copy-on-write forking项目地址: https://gitcode.com/gh_mirrors/ze/zeroboot
Zeroboot 是一个基于写时复制(copy-on-write)虚拟机分叉技术的亚毫秒级代码沙箱系统,其 Python SDK 仅用 3 行代码即可搭建零依赖的代码执行沙箱:真实 KVM 虚拟机隔离、单次 fork 仅需约 0.8 毫秒、每个沙箱内存占用约 265KB,专为 AI Agent 安全执行代码而生。
为什么需要 Zeroboot 代码执行沙箱
让 AI Agent 执行代码时,最让人头疼的问题有两个:
- 隔离不牢:Docker 容器属于内核级共享,一个
rm -rf或内核漏洞就可能逃逸; - 启动太慢:传统沙箱(E2B 约 150ms、Daytona 约 27ms)冷启动需要百毫秒级,而 Agent 每轮对话可能调用多次,延迟会被成倍放大。
Zeroboot 的思路完全不同——每个沙箱都是一台真实的 KVM 虚拟机,隔离由硬件强制(Intel VT-x / AMD-V),不是容器或 namespace:
| 指标 | Zeroboot | E2B | Daytona |
|---|---|---|---|
| Fork 延迟 p50 | 0.79ms | ~150ms | ~27ms |
| Fork 延迟 p99 | 1.74ms | ~300ms | ~90ms |
| 每沙箱内存 | ~265KB | ~128MB | ~50MB |
| Fork + 执行 Python | ~8ms | - | - |
| 1000 并发 fork | 815ms | - | - |
👉 0.8ms 的 fork 延迟意味着:一次对话里让 Agent 跑 10 段代码,沙箱开销不到 1 毫秒,快到你几乎感觉不到沙箱的存在。
零依赖 Python SDK:为什么值得注意
打开 sdk/python/ 你会发现,整个 SDK 只有两个文件:
- client.py ——
Sandbox与Result的全部实现 - init.py —— 导出入口
关键点:它只使用 Python 标准库urllib,不需要requests、httpx或任何第三方包。也就是说:
# 克隆仓库 git clone https://gitcode.com/gh_mirrors/ze/zeroboot # SDK 直接可用,无需 pip install 任何依赖这对生产环境极其友好——没有依赖冲突、没有版本地狱,甚至可以直接拷贝client.py单个文件进项目。
3行代码运行你的第一段沙箱代码
from zeroboot import Sandbox sb = Sandbox("zb_live_your_api_key") result = sb.run("print(1 + 1)") print(result.stdout) # 2就这么简单。Sandbox构造时只需传入 API Key,代码会在一个全新 fork 出的 KVM 虚拟机中执行,默认超时 30 秒。沙箱模板已预装 Python + numpy + pandas,也可以切换语言执行:
sb.run("console.log(1 + 1)", language="node") # 执行 Node.js读懂执行结果:Result 返回字段
每次执行返回一个 Result 对象,字段设计非常实用:
| 字段 | 含义 |
|---|---|
stdout/stderr | 捕获的标准输出 / 错误输出 |
exit_code | 退出码,0 表示成功 |
fork_time_ms | 虚拟机 fork 耗时(通常 < 1ms) |
exec_time_ms | 代码执行耗时 |
total_time_ms | 端到端总耗时 |
把fork_time_ms单独暴露出来,正是 Zeroboot 的招牌指标——你可以亲眼看到每次执行前那 0.7ms 级的虚拟机分叉。
批量并行执行:多路方案对比的利器
Agent 场景中经常需要"同一问题、多种解法并行验证"。Zeroboot 提供了run_batch,多条代码在互相隔离的并行沙箱中同时执行:
results = sb.run_batch([ "print(1 + 1)", "print(2 * 3)", "import math; print(math.pi)", ]) for r in results: print(r.stdout)官方基准显示,1000 个并发 fork 仅需 815ms,且每个 fork 都拥有独立的内存页——fork 之间完全看不到彼此的数据。
AI Agent 实战:对话式代码执行
仓库提供了一个完整示例 demo/agent.py:一个基于 Claude tool_use 的对话式 Agent,它拥有run_python(单次执行)和run_parallel(5 路并行方案对比)两个工具。用户提一个问题,Agent 自动生成多种解法代码,并行丢进沙箱执行,再用终端表格展示每个方案的 fork/exec 耗时——整个演示细节见 demo/README.md。
这正是"亚毫秒 fork"价值的最佳注脚:Agent 一轮回答里跑 5 个方案,沙箱开销仍可忽略不计。
自建部署:KVM 服务器上一键托管
不想用托管 API?Zeroboot 是开源的,可在任何带 KVM 的 Linux 机器上自托管(Apache-2.0 协议)。部署只需三步:
- 构建:
cargo build --release - 创建模板:Firecracker 启动虚拟机预载运行时并快照(一次性约 15 秒)
- 启动服务:
zeroboot serve workdir-python 8080
完整的 部署指南 还包含了 systemd 服务安装(deploy/zeroboot.service)和多机集群部署脚本 deploy/deploy.sh。API 细节(/v1/exec、/v1/exec/batch、鉴权、限流)参考 API 文档。
已知局限与适用场景
坦诚地看,当前版本的限制(来自 架构文档):
- ❗ 每个 fork 单 vCPU,暂不支持多核;
- ❗ fork 内无网络,沙箱仅通过串口 I/O 通信;
- ❗ 用户态 PRNG(numpy、OpenSSL)需要每个 fork 显式重新播种随机数。
适合的场景:AI Agent 代码执行、批量数据分析任务、不可信代码的安全隔离评测。不适合:需要网络访问或长时间有状态会话的负载。
总结
| 特性 | 说明 |
|---|---|
| 隔离强度 | 真实 KVM 虚拟机,硬件强制隔离 |
| Fork 延迟 | p50 约 0.79ms,比传统沙箱快 2~3 个数量级 |
| SDK 依赖 | 零第三方依赖,纯标准库实现 |
| 上手成本 | 3 行 Python 代码 |
如果你正在为 AI Agent 寻找安全又快的代码执行方案,Zeroboot 的"写时复制 fork + 亚毫秒启动"组合,目前是该赛道里最值得关注的开源选择。
【免费下载链接】zerobootSub-millisecond VM sandboxes for AI agents via copy-on-write forking项目地址: https://gitcode.com/gh_mirrors/ze/zeroboot
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考