Brood Box - 把 AI coding agent 关进 microVM 再审查改动
AI coding agent 的矛盾越来越明显。它们要真正帮你改代码，就需要读工作区、运行命令、安装依赖、访问模型 API，甚至使用 Git 凭据。但这些权限一旦直接落在宿主机上，agent 的每一个误操作也都会变成真实操作。
今天推荐的 stacklok/brood-box 就是围绕这个问题设计的工具。它是一个 Go 写的 CLI，命令名是 bbox，用于把 Claude Code、Codex、OpenCode、Gemini 这类 coding agent 放进硬件隔离的 microVM 里运行。agent 面对的是当前工作区的 copy-on-write 快照；会话结束后，你再逐文件查看 diff，并决定哪些改动写回真实项目。
发布时 GitHub 页面和搜索结果显示项目约 40 stars、9 forks，主要语言是 Go，许可为 Apache-2.0。项目创建于 2026-02-13，最近仍在活跃更新；releases 页面显示最新版本为 v0.0.22，发布时间为 2026-05-29。README 也明确标注它仍是 experimental 项目，CLI flags、配置格式和行为都可能变化。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | stacklok/brood-box |
| 定位 | 在 microVM 中运行 AI coding agent 的本地 CLI |
| Stars | 约 40 |
| Forks | 约 9 |
| 主要语言 | Go |
| 许可 | Apache-2.0 |
| Latest release | v0.0.22 |
它解决的是 agent 的本地执行边界
Brood Box 的核心命令很短：
bbox claude-code
bbox codex
bbox opencode
bbox gemini但这个命令背后做了很多事。它会解析 agent 配置，收集允许转发的环境变量，为当前目录创建 copy-on-write 快照，拉取或使用对应的 OCI image，启动 libkrun microVM，然后通过 SSH 把你放进一个交互式终端会话里。
这不是把 agent 做成网页服务，也不是再包一层普通 Docker 命令。它的目标是让 agent 仍然像本地终端工具一样工作，但实际写入发生在 disposable workspace 里。真实项目目录不会在 agent 会话中被直接修改。
Snapshot + diff review 是关键动作
Brood Box 默认让 agent 对工作区快照动手。agent 可以编辑文件、跑测试、生成代码，甚至把某些东西弄坏；但这些都发生在快照里。会话结束后，VM 会先停止，然后工具比较快照和原始目录之间的差异，再展示逐文件 review。
这个顺序很重要。review 发生前 VM 已经停止，避免 agent 一边继续写文件、一边让你审查旧 diff。文档还提到写回前会用 hash 做校验，减少检查和写回之间状态变化带来的风险。
这种体验更像“给 agent 一个临时工作台”，而不是“把整个 home directory 交给 agent”。如果结果不可信，退出会话就可以丢掉快照；如果结果有价值，再把接受的文件写回真实工作区。
microVM 不是普通容器
Brood Box 使用 libkrun，在 Linux 上依赖 KVM，在 Apple Silicon macOS 上依赖 Hypervisor.framework。README 强调它不是只靠容器边界，而是通过 microVM 给 coding agent 一个更硬的执行隔离层。
普通容器已经能解决很多环境复现问题，但它仍然共享宿主机内核。Brood Box 的判断是：当 agent 需要跑任意代码、安装依赖、执行 shell 命令时，仅靠“我相信这个容器配置”还不够，最好把执行环境推进到 VM 边界里。
当然，这也带来部署条件。Linux 需要可访问 /dev/kvm；macOS 目标是 Apple Silicon；Windows 并不是它当前 README 里的主路径。也就是说，它更适合愿意为 agent 安全边界付出环境成本的开发者，而不是所有机器上都能无感启用的小工具。
支持多种 agent，但保留明确的环境变量边界
User guide 里列出的内置 agent 包括 Claude Code、Codex、OpenCode 和 Gemini。每个 agent 都有对应的 image 和命令，也有自己的环境变量转发规则。例如 Claude Code 相关的是 ANTHROPIC_API_KEY、CLAUDE_*，Codex 相关的是 OPENAI_API_KEY、CODEX_*。
这比“把所有环境变量复制进 VM”更谨慎。agent 需要模型凭据才能工作，但不应该默认看到宿主机上所有配置。Brood Box 还提供 --no-git-token、--no-git-ssh-agent、--no-settings、--seed-credentials 等选项，让你决定 Git token、SSH agent、host-side agent settings 和凭据保存方式。
如果你在公司项目里试用，这些开关值得逐一看清楚。AI agent sandbox 的风险通常不只在文件系统，也在凭据、网络、MCP 工具和 Git 权限的组合上。
egress firewall 让网络权限可收窄
另一个值得注意的设计是 DNS-aware egress firewall。Brood Box 提供 permissive、standard、locked 三种 profile，并允许用 --allow-host 加额外 DNS hostname。README 里还特别说明 allow-host 接受 DNS hostname，而不是任意 IP。
这对 coding agent 很现实。完全断网会让很多任务无法完成：模型 API、包管理器、GitHub、文档站点都可能需要网络。但完全放开网络又会让 prompt injection、依赖脚本或误操作有更多出口。
Brood Box 不会替你定义“安全网络策略”，但它把网络边界放到了 CLI surface 上。你可以先用默认策略试跑，再对高风险仓库或敏感项目切到更窄的 egress profile。
MCP 和 Git 集成是实用但也要审查的部分
Brood Box 会在 ToolHive 运行时自动发现并代理 MCP servers，把工具能力暴露给 VM 里的 agent。文档里描述的方式是：host 侧运行 embedded Virtual MCP Server，把多个 backend 聚合成一个 VM 内可访问的 MCP endpoint，并可通过授权配置控制工具请求。
这对真实工作流有用，因为 coding agent 经常需要调用外部工具，而不只是改文件。但这也意味着 Brood Box 不只是“一个 VM wrapper”，它还在 host 和 guest 之间建立了工具通道。要用于敏感项目时，MCP group、授权策略和 --no-mcp 这些选项需要认真配置。
Git 集成也类似。默认情况下，它可以转发 git identity、GITHUB_TOKEN / GH_TOKEN 和 SSH agent，让 VM 内的 agent 可以执行 Git 操作。snapshot 模式下，.git/config 会被清理以移除敏感值。这个默认值对便利性友好，但如果你只想让 agent 写代码、不想让它触碰远端仓库，就应该显式关掉 token 或 SSH agent forwarding。
它适合什么人先试
我会优先把 Brood Box 推荐给这几类用户：
- 已经把 Claude Code、Codex、OpenCode 或 Gemini CLI 用在真实仓库里，但希望加一层本地执行隔离。
- 经常让 agent 跑测试、装依赖、批量修改文件，希望在写回前有逐文件 review。
- 愿意在 Linux KVM 或 Apple Silicon macOS 上配置 microVM 运行环境。
- 对凭据转发、Git 权限、MCP 工具和 egress policy 有明确安全要求。
- 能接受 experimental 项目，愿意跟随 CLI flag 和配置格式变化。
如果你只是偶尔让 agent 改一个小文件，或者当前机器无法使用 KVM / Hypervisor.framework，那么它可能过重。普通容器、临时 worktree、Git 分支和人工 review 已经能覆盖不少低风险场景。Brood Box 的价值主要出现在“agent 需要更自由地工作，但真实工作区不能直接暴露”的场景。
小结
stacklok/brood-box 的意义不在于再发明一个 coding agent，而是把现有 agent 的本地执行环境做得更可控。它用 microVM 建立执行边界，用 copy-on-write snapshot 隔离工作区，用 diff review 决定写回，用 egress、MCP 和 Git 选项收窄能力面。
它还年轻，也明显更偏安全意识强的 power user。但方向很清楚：当 AI coding agent 不再只是生成建议，而是能在你的机器上运行命令和改文件时，运行边界本身就应该成为开发工具的一部分。Brood Box 正是在补这块缺口。