AI Agent 跑代码，你最担心什么？不是跑不跑得对，而是跑不跑得住。
一个 LLM 生成的脚本，可能是删库、挖矿、反弹 shell——你根本不知道。所以几乎所有严肃的 Agent 框架都在找一种方案：跑代码，但要跑在笼子里。
问题是，现有的"笼子"太重了。Docker 容器启动动辄几百毫秒，E2B 的云沙箱一次 fork 要 150ms，吃掉 128MB 内存。当你需要同时启动几百个隔离环境——比如一个 Agent 同时分析 200 个用户上传的文件——这些方案全趴下。
zeroboot 给出了一个不同的答案：0.79 毫秒创建一个沙箱，每个只占 265KB 内存。
zeroboot 的核心思路极其简洁——它没有发明新的虚拟化技术，而是把 Linux 内核已有的能力用到极致。
Copy-on-Write (COW) 是 Linux fork 系统调用的一个特性。当进程调用 fork() 创建子进程时，内核并不立即复制父进程的内存，而是让父子进程共享同一块物理内存。只有当某一方尝试写入时，内核才按页复制被修改的内存页。
这意味着：如果子进程只读不写，fork 几乎是零成本的。
zeroboot 做的事情是：
┌─────────────────────────────────────────────┐
│ Pre-forked VM │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Python │ │ NumPy │ │ Stdlib │ │
│ └────┬────┘ └────┬────┘ └────┬────┘ │
│ └────────────┼────────────┘ │
│ Shared Memory │
│ (Read-Only) │
└──────────────┬──────────────────────────────┘
│ fork() → 0.79ms
┌───────┴───────┐
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Sandbox A │ │ Sandbox B │
│ (COW Page) │ │ (COW Page) │
│ ~265KB │ │ ~265KB │
│ Isolated │ │ Isolated │
└──────────────┘ └──────────────┘
关键数字：每个沙箱只占 ~265KB 内存（因为大部分内存页是共享的，只有被修改的页才占新空间）。作为对比，E2B 每个沙箱要 128MB——差了接近 500 倍。
zeroboot 官方给出了与三个主流沙箱方案的对比数据：
| 指标 | zeroboot | E2B | microsandbox | Daytona |
|---|---|---|---|---|
| 创建延迟 p50 | 0.79ms | ~150ms | ~200ms | ~27ms |
| 创建延迟 p99 | 1.74ms | ~300ms | ~400ms | ~90ms |
| 每沙箱内存 | ~265KB | ~128MB | ~50MB | ~50MB |
| Fork+执行 Python | ~8ms | - | - | - |
| 1000 并发 fork | 815ms | - | - | - |
几个值得注意的点：
zeroboot 提供了公开的 demo API，不需要安装任何东西就能试：
curl -X POST https://api.zeroboot.dev/v1/exec \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer zb_demo_hn2026' \
-d '{"code":"import numpy as np; print(np.random.rand(3))"}'
返回结果：
[0.5488135 0.71518937 0.60276338]
从发送请求到拿到结果，体感确实在毫秒级。这行 curl 背后发生的事：请求打到 zeroboot 的 API 网关，网关触发一次 COW fork，在隔离沙箱中执行 Python 代码，捕获 stdout 返回，销毁沙箱。整个过程一气呵成。
zeroboot/
├── src/ # 核心引擎（Rust）
├── guest/ # Guest VM 镜像构建
├── sdk/ # Python/TypeScript SDK
├── demo/ # 使用示例
├── deploy/ # Prometheus + Grafana 监控部署
├── docs/ # 文档
└── assets/ # Logo 等资源
项目用 Rust 编写，Apache-2.0 协议开源。目录结构清晰，核心代码在 src/，沙箱引擎利用 Rust 的零成本抽象直接操作 Linux 系统调用。deploy/ 目录自带 Prometheus + Grafana 配置，说明作者考虑了生产环境的可观测性。
SDK 层面支持 Python 和 TypeScript，对 AI Agent 开发者友好——LangChain、CrewAI 这类框架可以直接集成。
MERMAID_BLOCK_0
最适合的：
不太适合的：
zeroboot 不是银弹，有几个已知的限制：
很多人会问：我已经在用 E2B 了，为什么要看 zeroboot？
答案取决于你的需求架构：
E2B 是云原生沙箱——代码在 E2B 的云端运行，你通过 SDK 调用。好处是零运维，坏处是网络延迟不可避免（光速限制），且每个沙箱成本较高。
zeroboot 是本地沙箱引擎——代码在你自己的机器上运行，通过 COW fork 实现隔离。好处是极致性能（0.79ms），坏处是你需要自己管理基础设施。
一个合理的架构是：开发阶段用 zeroboot 本地快速迭代，生产阶段根据规模选择自托管 zeroboot 或云沙箱。
自托管 zeroboot 只需几步：
# 克隆仓库
git clone https://github.com/zerobootdev/zeroboot.git
cd zeroboot
# 构建（需要 Rust 工具链）
make build
# 启动服务
make run
# 用 Python SDK 调用
pip install zeroboot
from zeroboot import ZerobootClient
client = ZerobootClient("http://localhost:8080")
result = client.exec("print('Hello from sandbox!')")
print(result.stdout) # Hello from sandbox!
zeroboot 目前 2.3k stars，101 forks，Apache-2.0 协议。对于一个 2026 年 3 月才发布的项目，这个增速说明开发者对"亚毫秒沙箱"这件事有真实的需求。
在 AI Agent 安全执行这个赛道上，E2B、Daytona、microsandbox 都在做，但 zeroboot 是唯一从"裸金属性能"切入的——它不试图在云上做沙箱即服务，而是直接回答"一台机器上能同时安全跑多少个不受信任的代码"这个问题。
答案是：数千个，每个 0.79 毫秒。
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。