Docker Sandboxes 实战教程：AI 代理敢开最高权限模式了，本地免费跑、关掉笔记本搬到云，2026 官方指南

👁 106 次阅读

一、引言：AI 代理不敢放开手，不是模型不行，是家里没墙

过去半年，AI 编码代理的能力曲线很陡：一个大型重构、一次跨版本依赖迁移、一套跑一个小时的测试，都已经可以『丢给它，明天早上来看结果』。但真这么用的开发者很少——因为代理跑起来之后，每一步都要弹一次授权提示。你变成了瓶颈，从『决定做什么』退化成『批准它做什么』。

于是有了大家熟悉的那个参数：--dangerously-skip-permissions，社区管它叫 YOLO 模式。它能一口气跑完，但代价也很直白：一条误输的 rm -rf、一个被读到的环境变量、一次对 .ssh 目录的误改，都是真实会发生的事。

Docker 的判断是：护栏必须建立在代理『外面』，而不是由代理自己守着自己。为此他们做了一个专门的产品线叫 Docker Sandboxes——每个代理跑在一个独立的 microVM 里，有自己的内核、自己的 Docker daemon、自己的网络，只把你的项目目录挂进去。9 月 24 日，Docker 在加州 Palo Alto 的 WeAreDevelopers North America 大会把它推进了一步：Cloud Sandboxes，同样的 microVM，跑在 Docker 托管的计算上，一条命令就能从本地搬到云端。

AI 代理任务从本地沙箱迁移到云端沙箱 — 概念示意：本地代理跑不完的任务，一条命令迁移到云端继续（AI 生成示意图，非 Docker 官方配图）

二、先搞清楚三件事：沙箱是什么、要什么条件、多少钱

2.1 它解决的核心问题

Sandboxes 官网给出的定位是：一次性的、隔离的、专为编码代理设计的环境。落到具体行为上就是四条——代理可以装系统包、改配置、删文件、跑自己的 Docker 容器；代理唯一能看到的主机内容只有它的项目工作区；沙箱跑完直接删掉，几秒钟内恢复；这些都不需要 Docker Desktop。

Docker 特意强调了一个对比：挂载 Docker socket 会把宿主 daemon 暴露出去，Docker-in-Docker 依赖特权访问，直接在宿主机跑几乎等于没有隔离。microVM 方案是绕开这些取舍的做法，也是目前唯一能让代理『既用 Docker、又和宿主隔离』的方案。

2.2 系统要求（本地）

本地沙箱要求 CPU 支持并启用 KVM 硬件虚拟化。官方文档给的检查命令是：

$ lsmod | grep kvm

在虚拟机或 VDI 里跑的话，还要额外开启嵌套虚拟化（nested virtualization）。macOS 与 Windows 已经支持（Windows 的正式支持是今年 1 月 30 日随 microVM 版本一起推出的），文档也说明安装沙箱不依赖 Docker Desktop。

2.3 价格：这是最容易被忽略的一点

按 Docker 的官方说明，sbx 命令行工具和『本地』沙箱计算完全免费，商业使用也算，模型服务商的费用另算。付费的只有云沙箱——按秒计费的即用即付计划，挂在 Docker Personal 与 Pro 账号下。

档位	vCPU	内存	每小时	跑满 30 天（744 小时）
Micro	1	2 GiB	$0.07	约 $52
Small（默认）	2	4 GiB	$0.14	约 $104
Medium	4	8 GiB	$0.28	约 $208
Large	8	16 GiB	$0.56	约 $417
XL	16	32 GiB	$1.12	约 $833

数字看起来不便宜，但有两个关键约束：沙箱默认只跑 1 小时，单次会话最长 24 小时；暂停状态完全不计费；存储卷、公网出口流量、托管公开镜像和 Kit 都免费。所以上表更像是『一个代理 7×24 常驻』的上限参考，而不是正常使用成本。另外新账号目前有 $250 免费额度（限时活动）。

三、实战步骤一：安装 sbx 并登录

三个平台各自一条命令。官方产品页给的原样写法如下：

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install Docker.sbx

# Linux (Ubuntu)
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx

第一条命令只是把 Docker 的 apt 仓库加进来。如果手动装，官方建议直接从 sbx-releases 仓库下载二进制。装完登录：

$ sbx login

这一步会打开浏览器走 Docker OAuth。文档特别说明：使用 Claude 订阅（Max、Team、Enterprise）跑 Claude Code 时不需要预先配置任何密钥，直接在沙箱里用 /login 走 OAuth 即可，会话令牌留在宿主上，不会存进沙箱。想用 API key 的话走 secret 存进去，见后面第六步。

四、实战步骤二：跑第一个沙箱，顺手选网络策略

进到项目目录，用 sbx run 起一个代理。注意 Docker Agent 的默认启动命令是 docker-agent run –yolo，也就是说最激进的权限模式在这个产品里是默认值：

$ cd ~/my-project
$ sbx run --name my-sandbox claude

第一次运行会让你为所有沙箱选一个全局网络策略，这是本教程最容易被跳过但最该认真选的一步：

Initialize the global network policy for your sandboxes:
  Applies to all sandboxes, current and future — change it later with
  "sbx policy allow/deny/rm".

     1. Open         — All network traffic allowed, no restrictions.
     2. Balanced     — Default deny, with common dev sites allowed.
     3. Locked Down  — All network traffic blocked unless you allow it.

三种模式的行为差别很关键。Open 是全放行；Balanced 是默认拒绝、只放常见开发站点，官方文档明确建议从这里开始；Locked Down 是全阻断，你不开通就不通。特别提醒：在 Locked Down 下，连模型服务商的 API 都会被拦，必须显式放行。首次运行还要多花一些时间拉取代理镜像，之后走缓存，几秒钟就能起。

沙箱网络策略的三档选择 — 三档网络策略：Open、Balanced、Locked Down（AI 生成示意图）

五、实战步骤三：弄懂工作区，这一步决定你能不能并行

sbx 不带参数直接回车会打开交互面板，每个沙箱一行，能看到名字、里面跑的代理、状态、已发布端口和工作区。工作区是宿主上共享进沙箱的那个目录，也是代理唯一能看见的部分。

默认工作区是读写共享的。代理对你的项目做的每一处改动，都会实时出现在你的工作树里，你像看普通 Git diff 一样评审它，然后决定要不要提交。沙箱里其他一切都是隔离的：代理装的包、拉的镜像、起的容器都留在沙箱内，宿主毫发无损，删掉沙箱这些也跟着消失。

但如果你要在同一个仓库上并行跑多个代理，就不该让它们共用工作树。这时候用 clone 模式，官方会给它一份私有克隆：

$ sbx run claude -- --clone

文档的原话是：当你想在同一个仓库上跑多个代理时，用 clone 模式给它一个 private clone，这样它完全不碰你的工作树。用 clone 模式的话，删沙箱时会连那份沙箱内的 Git 克隆一起删掉，宿主工作树不受影响。

六、实战步骤四：给代理配密钥，注意它看不到真值

想让代理去 GitHub 建 PR、提 issue，就把 token 存成 secret：

$ sbx secret set github -t "$(gh auth token)"

云沙箱在这件事上多做了一层：密钥只存一次，沙箱在代理每个请求上代为注入，代理本身永远看不到真实值。Docker 对这条的表述很直接——提示词注入（prompt injection）碰不到代理根本没有的密钥。

这里有一个必须知道的坑：沙箱不会读取宿主上的用户级配置，只有工作目录里的项目级配置在沙箱内可用。换句话讲，你本机的 .claude 用户配置、shell 里的环境变量，进沙箱就没了，得靠 secret 或项目级文件重新声明。

七、实战步骤五：管好网络与生命周期

策略随时可以查、可以改：

# 查看当前生效的规则
$ sbx policy ls

# 放行某个具体域名
$ sbx policy allow network registry.npmjs.org

# 打开面板（不带参数直接跑）
$ sbx

# 停掉但不删（包、镜像、配置都保留）
$ sbx stop my-sandbox

# 彻底删除，立刻回收磁盘
$ sbx rm my-sandbox

stop 和 rm 的差别要记牢：stop 之后包、Docker 镜像、配置改动全部保留，下次接着干；rm 则是连沙箱里的包、镜像、clone 模式下的克隆全部删除。宿主工作区的文件两种情况都不受影响。

八、实战步骤六：把长任务搬上云

这是 Cloud Sandboxes 真正的价值点，也是本站之前只在日报里提过一句话的地方。它的场景假设很具体：代理已经开始干『以小时计』的活，笔记本却是围着一个人转的设备。

官方给的典型流程是先本地迭代，任务变大就一条命令交出去：

$ sbx move my-project --to cloud

move 会把沙箱的文件系统打包，在另一侧重建，所以你的工作进度会完整带过去，而且双向都支持。直接开云沙箱也可以：

$ sbx --cloud run claude
$sbx --cloud run codex

三个配套能力值得单独说。Kits 是预装好的代理沙箱定义，官方说 Claude Code、Codex、Copilot、Antigravity、Open Code、Hermes 都已经现成可用；下一代 Kit 规范把网络规则、凭据、卷打包成标准的 OCI 镜像，用容器那套流程发布到 Docker Hub，没有私有格式、没有厂商锁定。MCP 是接一次 Jira、Linear、Grafana、incident.io 这类服务器，之后所有代理通过单一网关访问，不管它们跑在云端、本地还是 ChatGPT 桌面端。Policies 则是网络规则定义一次、到处生效，企业级的集中治理走 Docker AI Governance（单独付费订阅）。

需要留意的是，本地和云端的凭据、模板、网络策略是分开的两套。Docker 在文档里专门提醒：在把一个本地工作流搬上云之前，先读清楚本地与云沙箱的差异说明。

九、费用与时长：算一笔实际的账

前面给过 30 天满跑的参考，这里换成更贴近真实的算法：假设一个长任务在云沙箱里跑 8 小时，Small 档就是 8 × $0.14 = $1.12。同一档位在本地跑，成本是 0 元——本地沙箱免费。

所以选择逻辑其实很清晰：交互性的、随时要盯着的活儿留在本地；需要挂着跑几小时的活儿丢上云。Docker 自己的定位也是这么说的——这不该是两个产品，互动属于笔记本，以小时计的工作属于云端，大多数开发者两个都要，而现在不用二选一。

场景	推荐	关键理由
本地调试、边改边看	本地沙箱	免费、秒级起停、直接用你现有的开发环境
跨版本迁移、批量重构等长任务	云沙箱	笔记本可以合上，任务继续跑
一次性验证想法	云沙箱	默认 1 小时，跑完即弃，暂停不花钱
同一仓库多代理并行	本地 + clone 模式	私有克隆互不干扰，宿主工作树干净
企业统一管控	Docker AI Governance	网络/文件系统/MCP 策略统一定义

十、坑与限制：官方文档里明写的六条

1. 用户级配置进不去。沙箱只认工作目录里的项目级配置，宿主上的用户级 agent 配置、环境变量、shell 设置一概不带入。

2. Locked Down 会把模型 API 一起拦掉。选这档之前想清楚，否则代理连模型都调不到。

3. 本地和云是两套凭据。secret、模板、网络策略互不共享，迁移前先看差异文档。

4. 版本有门槛。用云沙箱需要 sbx 0.45.1 或更高，外加一个即用即付计划（Docker Personal 或 Pro 账号可用）。

5. 时长有硬顶。默认 1 小时，单次会话最多 24 小时。超过就得重新规划。

6. 本地要虚拟化。没有 KVM 的机器跑不了本地沙箱；套在虚拟机里还要额外开嵌套虚拟化。

十一、总结：值得上手吗？

值得，而且门槛比预期低。它的价值链条其实只有三环：第一环是隔离让你敢放开权限，代理从『每步等批准』变成『丢出去等结果』，这是 Docker 引用数据时说的那部分——超过四分之一的生产代码现在由 AI 撰写，用代理的开发者合并 PR 的数量大约多 60%，但这些都只在代理真正自主跑起来时才成立；第二环是本地免费，个人开发者不需要为隔离付一分钱；第三环是云端按秒计费、暂停免费，把长任务从笔记本上解绑。

上手路径可以压缩成三句：先本地装 sbx 跑通一个代理，把工作区和网络策略调到舒服；把真正耗时的活儿用一条 sbx move 丢上云；再用 Kits 把团队常用的那套环境固化下来，一次定义、处处复用。

最后提醒一句最实际的：先领那个 $250 的免费额度再动手，够你把这个产品线的边角摸个遍。

十二、参考资料

本文所有版本号、命令、价格与时长数据均来自 Docker 官方渠道，可逐条核对：

Docker 官方博客《Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud》（2026 年 9 月 24 日）：https://www.docker.com/blog/introducing-cloud-sandboxes-start-on-your-laptop-finish-in-the-cloud/
Docker 新闻稿《Docker Launches Cloud Sandboxes, Extending Secure AI Agent Isolation Beyond the Laptop》（2026 年 9 月 24 日，Palo Alto）
Docker Sandboxes 文档总览与上手指南：https://docs.docker.com/ai/sandboxes/get-started/
产品页 Sandboxes for Coding Agents：https://www.docker.com/products/docker-sandboxes/
官方博客《Docker Sandboxes: Run Agents in YOLO Mode, Safely》（2026 年 3 月 31 日，YOLO 模式与 microVM 隔离对比）
官方博客《Docker Sandboxes: Run Claude Code and More Safely》（2026 年 1 月 30 日，microVM 与网络隔离首发）