要解决的问题

编码智能体的权限默认是「你有的它都有」：能读家目录里的配置文件、能借用 SSH agent 和钥匙串、能联网装包、能往任何可写路径写东西。一个跑长任务的智能体如果中途判断失误，影响范围就是你整台机器。Brig 的定位很直接——智能体在无人看管时只能破坏你交给它的那部分，所以它把智能体关进本机的一个 microVM 里跑。

安装与首次检查

macOS 上走 Homebrew cask：先 tap 仓库、brew trust，再安装 cask，它会一并带上 hull 与 cosign。装完先跑一次自检命令，每条输出是一个检查项，带感叹号标记的行会直接在旁边给出修复方式。这一步值得做完再继续——它会检查虚拟化后端、所需组件与镜像资源是否就位。

跑起来是什么样

一条命令启动沙箱并在里面运行智能体，项目路径作为参数传入，会以读写方式挂载到沙箱内的 /work/<项目名>，智能体也从那里开始工作。关键设计是凭据按需递送：沙箱启动时不带任何凭据，智能体在需要时会要求你登录，登录动作发生在沙箱内部。会话用「智能体名」或「智能体名@标签」标识，前者如 claude 会解析到对应配置，后者的 guest home 是前者的同级目录而不是子目录，因此同一智能体的不同会话彼此独立。想清空状态时，丢掉沙箱重开即可。

平台限制与注意点

支持范围写得比较明确：Apple 芯片的 macOS 15 及以上；macOS 14 需要额外指定虚拟化后端环境变量；Intel Mac 不支持；Linux 需要 x86-64 或 arm64，并预先装好 nerdctl、containerd 与 urunc。官方也说明内置配置里有多项依赖新后端，所以 macOS 15 是实际下限。另外两点容易踩：沙箱内没有你宿主机的登录态，每个会话都要各自登录一次；会话与沙箱是一对一占用的，跑得多时需要自己留意清理。

  • 适合：让智能体长时间无人看管地改代码，或机器上存在不希望智能体读到的凭据与文件
  • 不适合：只是让智能体改一两个文件、且不在乎隔离成本的场景，直接在本机跑更省事
  • 验证顺序：先跑通自检 → 再用一个无关紧要的仓库走一遍完整任务 → 确认挂载范围与登录流程 → 最后才用于真实项目
隔离换来的不是更强的模型，而是「出事的损失有上界」——这一点在长任务里比性能更值钱。