Zeroboot API完整参考从/v1/exec到批量并行执行的4个核心端点详解【免费下载链接】zerobootSub-millisecond VM sandboxes for AI agents via copy-on-write forking项目地址: https://gitcode.com/gh_mirrors/ze/zerobootZeroboot是一个用 Rust 编写的子毫秒级 VM 沙箱服务专为 AI Agent 设计每个请求都会通过 copy-on-write 分叉出一台真正的 KVM 虚拟机来执行代码fork 延迟 p50 仅0.79ms。本文是它的 API 完整参考带你逐一拆解/v1/exec、/v1/exec/batch、/v1/health、/v1/metrics这 4 个核心端点从请求参数到响应字段看完即可上手调用。上图是官方 AI Agent 演示Claude 通过run_python和run_parallel两个工具把生成的代码交给 Zeroboot 沙箱执行支持多方案并行对比。完整说明见 demo/README.md。为什么需要子毫秒级代码沙箱AI Agent 生成代码后需要安全地跑一下。传统方案容器、完整 VM冷启动要几十到几百毫秒而 Zeroboot 的思路是一次性用 Firecracker 启动 VM、预加载运行时Python numpy、Node.js并快照内存 CPU 状态每次请求通过mmap(MAP_PRIVATE)以写时复制方式把快照映射进新 KVM VM恢复 CPU 状态——约0.8ms完成分叉每个沙箱拥有独立的 KVM VM隔离由 Intel VT-x/AMD-V 硬件强制而非容器或 namespace。官方基准p50 延迟指标ZerobootE2BmicrosandboxDaytona创建延迟 p500.79ms~150ms~200ms~27ms创建延迟 p991.74ms~300ms~400ms~90ms每沙箱内存~265KB~128MB~50MB~50MBFork exec (Python)~8ms---架构全貌见 docs/ARCHITECTURE.md。4 个核心端点一览端点方法作用/v1/execPOST在隔离沙箱中执行一段代码/v1/exec/batchPOST并行执行多段代码/v1/healthGET查看模板状态与就绪情况/v1/metricsGETPrometheus 格式监控指标完整定义见 docs/API.md实现位于 src/api/handlers.rs。端点 1POST /v1/exec —— 单次代码执行这是最核心的端点每调用一次Zeroboot 就 fork 一台新 VM 沙箱执行你的代码。请求体参数字段类型必填说明codestring✅要执行的代码languagestring❌python默认/node/javascripttimeout_secondsint❌超时秒数默认 30上限 300响应字段解读这是 API 最有价值的部分字段含义id本次执行的 UUIDstdout/stderr标准输出 / 标准错误exit_code0 表示成功-1 表示失败或超时fork_time_msVM 分叉耗时——通常不到 1msexec_time_ms代码执行耗时total_time_ms端到端总耗时curl 示例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))}响应示例{ id: 019cf684-1fd5-73c0-9299-52253f9aa79c, stdout: [0.5488 0.7152 0.6028], stderr: , exit_code: 0, fork_time_ms: 0.75, exec_time_ms: 7.2, total_time_ms: 8.0 } 注意沙箱内无网络代码通过串口 I/O 通信fork 间共享快照的 CSPRNG 状态涉及随机数的场景建议每次显式重播种。端点 2POST /v1/exec/batch —— 批量并行执行当 AI Agent 需要用 5 种不同方法解同一个问题再对比时就靠这个端点。一次请求里的每段代码都会跑在各自独立的 VM fork中并行执行、互不干扰。请求体{ executions: [ {code: print(1), language: python}, {code: console.log(2), language: node} ] }响应体是一个results数组每项字段与/v1/exec的响应完全一致按输入顺序排列。/v1/exec/batch的批量并行正是官方 AI Agent 演示里run_parallel工具背后的能力——Agent 一次并行跑多个方案用一次往返拿到全部对比结果。端点 3GET /v1/health —— 健康检查与模板状态无需鉴权即可调用返回服务状态和每种语言模板是否就绪{ status: ok, templates: { python: {ready: true, memory_mb: 256}, node: {ready: true, memory_mb: 256} } }ready: true表示对应语言的快照模板已加载完毕此时调用/v1/exec即可走子毫秒路径。端点 4GET /v1/metrics —— 监控指标返回 Prometheus 文本格式可直接被 Grafana / Prometheus 抓取。核心指标包括zeroboot_fork_time_milliseconds—— fork 耗时直方图桶边界 0.1ms~1000mszeroboot_exec_time_milliseconds—— 代码执行耗时直方图zeroboot_total_time_milliseconds—— 端到端耗时直方图zeroboot_concurrent_forks—— 当前并发 fork 数zeroboot_total_executions—— 成功 / 失败 / 超时执行总数配套的监控面板模板在 deploy/grafana-dashboard.json直方图的桶实现见 src/api/handlers.rs。认证与速率限制API Key放在api_keys.json或设置ZEROBOOT_API_KEYS_FILE环境变量通过Authorization: Bearer key请求头携带未配置 key 文件时认证自动关闭适合本地自托管无效 / 缺失 key 返回HTTP 401正式 key 限流100 req/s超出返回HTTP 429zb_demo_开头的演示 key 限10 次/分钟且按客户端 IP 隔离——官方源码中该逻辑见 src/api/handlers.rs。不手写 HTTP两个零依赖 SDK不想直接调 REST API官方提供 Python 和 TypeScript 两套 SDKPythonsdk/python/纯标准库实现from zeroboot import Sandbox sb Sandbox(zb_live_your_key) result sb.run(print(1 1)) # 单次执行 → /v1/exec results sb.run_batch([print(1), print(2)]) # 并行执行 → /v1/exec/batchTypeScriptsdk/node/基于 fetchimport { Sandbox } from zeroboot/sdk; const result await new Sandbox(zb_live_your_key).run(console.log(11));常见问题Qfork 这么快隔离安全吗每个沙箱是独立的 KVM VM内存页写时复制硬件级隔离fork 间看不到彼此的数据。Q每个沙箱多少资源每 fork 单 vCPU、快照默认 256MB但实际 RSS 只有 ~265KB——未触碰的内存页仍共享快照文件。Q有哪些已知限制fork 内暂无网络仅串口 I/O、单 vCPU、更新模板需重新全量快照约 15s。详见 README.md。总结Zeroboot 的 API 设计极简但信息密度很高端点一句话总结POST /v1/exec一次调用 一台 ~0.8ms 的新 VM 沙箱执行代码POST /v1/exec/batchAI Agent 并行多方案对比的利器GET /v1/health确认语言模板就绪GET /v1/metrics直方图级监控对接 Grafana核心关键词回顾子毫秒 VM 沙箱、代码执行 API、批量并行执行、AI Agent 沙箱。想深入实现细节推荐按顺序阅读 docs/ARCHITECTURE.md → src/vmm/kvm.rsfork 引擎→ src/api/handlers.rsAPI 层。【免费下载链接】zerobootSub-millisecond VM sandboxes for AI agents via copy-on-write forking项目地址: https://gitcode.com/gh_mirrors/ze/zeroboot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考