Docker Sandboxes 上手:从安装到第一次跑 Agent

TL;DR

在 Mac 上装好 Docker Sandboxes,把 Coding Agent 跑进一台可以随手删掉的微虚拟机。它自己的内核、文件系统、网络、Docker Engine,宿主机都碰不到------但你主动挂进去的项目目录是例外,Agent 在里面读写和你本人权限一样,不受额外限制。

安装到跑通 OpenCode,最短路径不到十分钟;真正费事的是模型登录:sandbox 不继承宿主机账号,SuperGrok 这类订阅还要单独 /connect 并放行网络策略。装完能人机协作改同一棵树,还不到无人值守的程度。

引言

给 Coding Agent 选运行环境时,「容器 vs 微虚拟机」不是选择题,是真问题。

Agent 要自己装依赖、跑测试、起 Compose,才算真的在干活。这些事权限不低。常见做法是把宿主机的 Docker socket 挂进容器,等于把整台机器的 Docker 交给它------风险出在共享宿主机内核和宿主机 Docker 上。

Docker Sandboxes 换了个方案:不共享内核和 Docker,而是给每个任务一个可以删掉的微虚拟机。项目还在你的 Mac 上,宿主机的 Docker 它碰不到。

下面只做一件事:在 Apple Silicon 的 Mac 上,从安装走到第一次跑起来。环境是 M1 Pro、sbx v0.38.0、OpenCode。宿主机上的 Docker 是 OrbStack。不是全 Agent 评测,也不讲隔离机制的全景。

能删的虚拟机,删不掉的工作区

一个 sandbox 对应一台微虚拟机,不是一次对话。Agent 退出后环境还在,再连上去,装过的包和拉过的镜像都在。只有 sbx rm 才拆掉。

里面有四样东西:

  • 自己的 Linux kernel,不是和 Mac 共用一个
  • 自己的文件系统,宿主机上的目录默认进不去
  • 自己的网络,出站走策略,宿主机 localhost 不是它的 localhost
  • 自己的 Docker Engine。在里面 docker ps,看到的不是 OrbStack

项目目录是挂进去的,路径和 Mac 上一样。Agent 改的文件,你这边立刻看得到。这是协作需要的,也是边界:工作区里的 .env.git 都能被 Agent 直接读到,没有额外的权限限制去挡它。

和「容器里再跑 Agent、再把 docker.sock 挂进去」的差别就在这里。后者共享的是宿主机内核和宿主机 Docker;前者把这两样留在微虚拟机里。

具体到 Agent 这边,Docker 给这条链路预置了 Claude Code、Codex、OpenCode 等几个 Agent,加上一个没有预装 Agent 的 shell。本文只测 OpenCode------Kimaki(我自己接的 Discord + OpenCode 方案)和 omp(Pi 的一个功能拉满的独立 fork,不是 Pi 的新版本)都是独立于 Docker Sandboxes 官方支持列表之外的工具,能不能接进来是另一个问题,不在这篇的范围内。

装得快,连得慢

官方名单里的 Mac 只有 Apple Silicon,系统至少 Sonoma 14。Homebrew cask 也写死 arm64,Intel Mac 现在装不上。这是产品支持范围,不是 Intel 机器不能做虚拟化。Docker Desktop 不是前置条件------sbx 自己拉微虚拟机,也不依赖我已经在用的 OrbStack。

bash 复制代码
brew trust docker/tap
brew install docker/tap/sbx
sbx login

sbx login 走浏览器里的 Docker 账号。装完 CLI 不会自动拉起后台进程。我这边要先常驻 daemon,再初始化网络策略,否则后面执行 sbx run 之类的命令会因为策略未初始化而报错:

bash 复制代码
sbx daemon start
sbx policy init balanced

daemon start 前台阻塞,适合丢给 launchd 一类的进程管理,不要挂在你正用的那个终端里不管。

daemon 起来之后,再看网络策略。官方把出站预设分成三档:Open 全开,Locked Down 全拦,Balanced 是居中那档------默认拒绝,只放行模型 API、包管理器、代码托管和 Registry 这类常见开发站点。文档里也可以在第一次 sbx run 时交互选;两条路选一条即可。

然后进项目目录:

bash 复制代码
cd ~/your-project
sbx run opencode

第一次会拉 OpenCode 的模板镜像,要等一会儿。起来的是 TUI,不是 Claude Code 那种自动跳过确认的会话。

模型不会跟过来。宿主机上已经登录的 OpenCode,sandbox 里看不到。

我用的是 xAI 的 SuperGrok 订阅,不是 console.x.ai 的 API Key。sbx secret set xai 只支持写入 API Key,不支持这种订阅制 OAuth 凭证,所以要在 TUI 里 /connect,选 xAI 的 Headless OAuth。balanced 默认不放行 xAI 的登录域名,device code 出不来,要先加规则:

bash 复制代码
sbx policy allow network "*.x.ai:443,api.x.ai:443,auth.x.ai:443,accounts.x.ai:443"

如果你走 Anthropic、OpenAI 这类 API Key,用 sbx secret set <provider> 即可,一般不必改策略。

连上之后就可以丢一个真任务进去,比如跑测试、补缺的函数。文件改动会出现在你的工作区里,用平时的 git diff 看就行。

停掉但留下环境用 sbx stop,下次 sbx run --name <sandbox> 再连。不要了再 sbx rm。需要进编辑器时,先 sbx setup ssh,然后 ssh <name>.sbx;VS Code 的 Remote-SSH 也能连这个主机名。

省的是确认,不是配置

工作区还在 Mac 上,OrbStack/Docker Desktop 还是你的 Docker,Agent 用它自己那一套。装依赖、跑测试、起容器,都可以在里面做,不必把宿主机的 Docker socket 交出去。

这条最短路径里,真正费事的不是拉镜像,是模型怎么进去。sandbox 不继承本机 OpenCode 登录;我用 SuperGrok,还要自己 /connect,并给 balanced 补上 xAI 的域名。YOLO 省掉的是一条条点确认,不是这些配置。

眼下这条路适合人在旁边、和 Agent 改同一棵树。装完不能当无人值守,Kimaki 和 omp 也开箱接不上。工作区挂进去之后,.env 对 Agent 是可见的:隔离挡的是工作区外面,不是工作区里面。工作区是不是必须直接读写、能不能换成给 Agent 一份隔离副本,这道边界具体打在哪,后面再写。

相关推荐
小马同学-2 小时前
高可用-Keepalived全解析
linux·运维
ziyun6668883 小时前
Docker 容器化 Web 服务架构搭建与自动化运维项目
运维·docker·架构
梦想的旅途23 小时前
企微 API 二次开发:利用 AI Agent 实现自动化运维
运维·人工智能·企业微信
安科瑞-小李3 小时前
铁路智能运维进化路线:自动化→状态可视→预测维护
运维·自动化·数据采集·能耗可视化
酷可达拉斯4 小时前
自动化运维-Ansible任务控制与流程控制
运维·自动化·ansible
HiDev_4 小时前
【非标自动化】2、认识元器件(电机保护器)
运维·自动化
heimeiyingwang5 小时前
【架构实战】Kubernetes故障排查全景图:从Pod异常到集群雪崩的诊断手册
容器·架构·kubernetes
骇客野人5 小时前
Docker Compose 部署多个独立 Jar 服务完整实操步骤
docker·容器·jar
AAA@峥5 小时前
K8s 资源管控:ResourceQuota 与 LimitRange 机制详解与实战
云原生·容器·kubernetes