forkd

在 101 毫秒内 Fork 100 个 microVM。在 56 毫秒内 BRANCH 一个正在运行的 VM（v0.4 实时模式）。

这是一个用于 AI Agent 分叉（fan-out） 的 microVM 沙盒运行时。子进程从预热的父进程快照中 fork 而来，继承其写时复制（copy-on-write）的地址空间，而不是冷启动它们自己的内核。

forkd 构建于 Firecracker 之上。父 VM 启动一次，导入您的运行时（Python + 依赖项、JIT 预热的 JVM、已加载的 ML 模型）并暂停至磁盘。每个子进程都是一个独立的 Firecracker 进程，使用 MAP_PRIVATE 对父进程的内存镜像执行 mmap；内核在页面级别实现写时复制，因此子进程在发生内存偏差之前共享父进程的常驻内存。

其结果是同时具备了两个特性：每个子进程拥有 KVM 隔离，且生成的成本更接近 fork(2) 而非冷启动 VM。

forkd 还支持 BRANCH：暂停一个运行中的沙盒，对其实时状态进行快照，并恢复运行 —— 所有过程仅需约 150 毫秒 —— 因此 Agent 不仅可以在预热时，还可以在“思考”过程中进行分叉。v0.3.4 修复了一个慢路径回归问题，即在同一个父进程上重复进行 BRANCH 操作会导致耗时从 150 毫秒膨胀到 2.7 秒（#146）；现在链式结构保持平坦（在第 6 次连续 BRANCH 时速度快了 17.6 倍）。

v0.4 实时 BRANCH 将源暂停窗口从约 200 毫秒（Diff 模式）缩短至 56 毫秒 (p50) / 64 毫秒 (p90)（基于 1.5 GiB 源）—— 测量于真实的 BRANCH 工作负载，详见 bench/live-fork-pause-window/RESULTS-v0.4.md。相比 v0.3 的 Diff 模式，p50 下的暂停速度快了 3.6 倍，并且在较慢的存储设备上差距会进一步拉大（因为实时模式的暂停与磁盘无关，内存拷贝在恢复后执行，而非期间）。使用 wait: false，调用方可在约 70 毫秒内返回，同时后台拷贝异步完成 —— 对于来自 Agent 代码的“即发即弃（fire-and-forget）”式 BRANCH，RT（响应时间）提升了 200 倍。在 CLI 中传入 --live / --no-wait，在 REST 中设置 mode: "live" / wait: false，或者在 Python / TypeScript / MCP SDK 中使用相同参数。

from forkd import Controller
c = Controller()
# 源必须使用 live_fork=True 启动（基于 memfd 的 RAM，这是 UFFD_WP 能够观察运行中父进程写操作的前提）。
parent = c.spawn_sandboxes("pyagent", n=1, live_fork=True)[0]
# ... 驱动父进程 ... 然后 BRANCH 实时 + 即发即弃：
branch = c.branch_sandbox(parent["id"], mode="live", wait=False)
# 在约 10 毫秒后返回，状态为 "writing"；轮询 list_snapshots
# 直到状态变为 "ready"，表示后台拷贝完成。

# CLI：在本地生成支持实时分叉的子进程，然后对被守护进程跟踪的子进程进行实时 BRANCH。
# 这两条路径目前尚未完全整合 —— 从 CLI 进行守护进程侧的生成是下一个补缺功能（详见 issue #209）。
sudo -E forkd fork --tag pyagent -n 1 --per-child-netns --live-fork
sudo -E forkd snapshot --from-sandbox  --live --no-wait

要求 Linux ≥ 5.7，vm.unprivileged_userfaultfd=1（或 CAP_SYS_PTRACE），以及来自 deeplethe/firecracker:forkd-v0.4-mem-backend-shared-v1.12 的 vendored Firecracker 分支 —— forkd doctor 可探测这两项。完整设计：DESIGN-v0.4.md。实验性 PoC 数据：experiments/v0.4-*-poc/。跟踪 issue #101。

演示：分叉一个正在思考的 Agent

一个 24 秒的 LangGraph 分叉与扇出（branch-and-fan-out）演示 —— 源 Agent 运行一个 ReAct 循环，在思考过程中被 BRANCH，三个孙子进程各自接收不同的指导提示，所有三个进程产生不同的路线规划，同时继承了相同的先前推理状态。

主要差异：源进程（无提示）选择锦市场（Nishiki Market）作为第 1 天行程；所有三个收到提示的子进程都独立地替换为岚山竹林（Arashiyama Bamboo Grove）。关注成本的子进程还添加了其他进程没有的“可能很昂贵”的注解。模型并没有被告知要切换地点 —— 每个提示扰动了下一次 LLM 调用，而其余先前的推理状态则原封不动地保留了下来。

完整的机制、数据和原始脚本见 recipes/langgraph-react/ 和 recipes/langgraph-react/DEMO.md。

以及：文件系统状态，不仅仅是推理

对于“难道你不能并行调用 3 次 LLM 吗？”这种质疑，请查看 recipes/coding-agent-fork/ —— 一个 50 MiB 的二进制文件通过单次 BRANCH 操作，以字节完全相同的方式在所有 4 个沙盒中传播。三个孙子进程各自对一个有 bug 的 Python 包应用不同的修复；它们的 __pycache__/ 和修改保持隔离，但 50 MiB 的继承部分是共享的。字节数据无法塞进 prompt 中。BRANCH 操作的暂停时间仅为 3.3 秒。

特性

• 硬件隔离。 每个子进程都是由 KVM 支持的独立 Firecracker microVM。逃逸需要利用 hypervisor 或内核漏洞，而不是 runc 回归。
• 预热的运行时可免费继承。 导入、JIT 编译、模型权重、预载入配置等均可继承。