档案库 · 开发与企业工具 · 技术决策 · 2026
Zeroboot押注AI代理获得原生KVM隔离，派生成本低于毫秒
Zeroboot通过写时复制在约0.8毫秒内派生Firecracker虚拟机，押注AI代理会把沙箱执行视为廉价的函数调用
Zeroboot (zerobootdev)
做的是什么生意
Zeroboot builds sandboxed code execution for AI agents: an open-source Rust engine that forks Firecracker microVMs from a copy-on-write memory snapshot (p50 spawn ~0.79ms, ~265KB per sandbox), plus a managed HTTP API that the author plans to run multi-region with usage-based pricing
起因
Adam Miribyan built the engine as a working prototype in Rust on Firecracker and KVM, then posted Show HN on 2026-03-17. In the thread he described the fork engine as general purpose but aimed it at AI agents because that is where the demand is now: agent frameworks such as LangChain, CrewAI and OpenAI Assistants need sandboxed code execution as a tool call, and the existing options (E2B, Daytona, Modal) boot or restore a VM per execution.
经过
The thread drew 311 points and 72 comments. Engineers compared the approach with CodeSandbox's microVM cloning and Cloud Hypervisor's userfaultfd work; Miribyan answered that single-node density is the near-term point — 1,000 concurrent sandboxes on one roughly $50 box — and that the API in the README was already live, with plans for a multi-region managed service, custom templates and usage-based pricing. The README benchmarks p50 spawn at 0.79ms against ~150ms (E2B), ~200ms (microsandbox) and ~27ms (Daytona), and lists honest limitations: single vCPU per fork, no networking inside forks (serial I/O only), snapshot-shared CSPRNG state, and a ~15s full re-snapshot for template updates.
还没有结局，它还在跑。
背景
Zeroboot是一个开源基础设施项目和早期初创公司，押注如果成本像函数调用一样低，AI代理将在真正的虚拟机中执行不可信代码。其Rust引擎从写时复制内存快照派生Firecracker微虚拟机：p50派生延迟0.79毫秒，每个沙箱约265KB内存，每个都是独立的KVM虚拟机，具有硬件强制的内存隔离。
机制就是赌注：启动一个模板一次，预加载运行时，快照内存和CPU状态，然后mmap(MAP_PRIVATE)派生数千个虚拟机。这使得投机性并行执行变得实用——派生十个虚拟机，尝试十种方案，保住最好的——并将代码执行从基础设施决策变成廉价的工具调用，这正是LangChain、CrewAI和OpenAI Assistants等代理框架所需的。
2026年3月17日的Show HN获得311分和72条评论，工程师们将这种方法与CodeSandbox的微虚拟机克隆和Cloud Hypervisor的userfaultfd工作进行比较。作者回答说，近期的重点是单节点密度（一台约50美元的机器上1000个并发沙箱），并且托管API已经上线，计划多区域部署、自定义模板和按用量定价。
截至2026年9月5日，仓库显示2.4k星和108个分支，README仍将项目标记为工作原型：派生原语、基准测试和API是真实的，但尚未生产强化，记录了每个派生一个vCPU、派生内无网络以及模板更新约15秒全新重新快照的局限性。
这件事要成立，得有什么
- 现有的代理沙箱每次执行启动或恢复虚拟机，耗时100毫秒以上，因此在写时复制派生使其约0.8毫秒之前，将代码执行视为廉价调用是不可能的
- 尽管引擎是通用的，但瞄准AI代理顺应了现在存在的需求：每个主要代理框架都需要沙箱代码执行作为工具调用
- mmap(MAP_PRIVATE)快照方法在保持硬件隔离的同时，将每个沙箱内存降至约265KB，使单台机器上数千个并发派生成为现实
- 开源核心同时构建按用量定价的托管API，提供了楔子：开发者先在本地试用派生原语，然后购买隔离即服务
可借鉴之处
100倍的延迟降低改变了产品类别：当隔离比函数调用还便宜时，要卖的是它解锁的行为——投机性并行执行——而不是基准测试本身
后续进展
截至2026年9月5日，Zeroboot仍是一个工作原型：README称派生原语、基准测试和API是真实的，但尚未生产强化，托管服务处于早期阶段，只有报名表，没有公布定价。开源仓库（zerobootdev/zeroboot）在2026年9月5日抓取时显示2.4k星和108个分支。来源中未披露资金、收入、团队规模或客户名称。
资料来源
发现哪里写错了？告诉我们。
轮到你了
你刚读完一家。说说你在做什么，看看谁在赌同一件事。
免费账号 · 3 次免费提问 · 不用绑卡