容器关不住 AI Agent：Docker 沙箱搬上云，关掉笔记本它还在跑一夜

你给 Agent 开了全权限，等于把家门钥匙交给一个会照着网页上任何一句话做事的实习生。它读到一条指令就照做，不问这句话是谁写的，也不问后果归谁。

结果呢，大多数人卡在同一个地方：不敢放权，只能盯着。它每跑一步你都要回头看一眼，那点省下来的时间又原样还回去了。

说实话，这一年 Agent 的能力涨得飞快，涨得慢的是信任。真正的瓶颈从来不是它会不会做，而是你敢不敢让它自己做。

容器关不住 AI Agent：Docker 把隔离搬上了云

2026 年 9 月 24 日，WeAreDevelopers North America 现场，Docker 发布了 Cloud Sandboxes，当天就能用。

结论先说，这次解决的是信任问题，不是算力问题。Cloud Sandboxes 用 microVM 做隔离，和本地沙箱共用同一套 CLI、同一个信任模型、同一套 Kits。算力从 1 到 16 vCPU 由 Docker 全托管，启动低至几百毫秒，secrets、policy、MCP gateway、agent 配置全部内置。

Docker 总裁 Mark Cavage 的说法很直白：容器仍然关键，但它不是为 Agent 需要的隔离级别设计的。所以 Docker 今年早些时候先落地了本地沙箱，现在把同样的隔离和控制延伸到云。

这句话值得琢磨。容器的边界是进程和资源，Agent 需要的边界是权限和后果。你可以把一个进程关进容器，但你关不住一个会读网页、会调工具、会自己决定下一步的东西。

给 Agent 一间单向玻璃的房间，它能看见、能干活，但手伸不出这间屋子。这就是沙箱。

还有一条必须先讲清楚：沙箱挡不住 prompt injection。沙箱不解决注入，它只改变一个被攻陷的 Agent 能做什么。真正的防线是分层的，提示过滤，工具权限，沙箱，网络策略，凭证隔离，人工审批。少任何一层，都谈不上安全。想在自己机器上做类似的隔离，可以看看 腾讯云 Octop 1.0 自托管。

五分钟装好 sbx：装完默认是锁着的

结论很简单，装、登录、选网络档位，三步走完就能跑。

brew install docker/tap/sbx
sbx login

安装输出里有一行要留意：Network policy: deny all, allow 42 hostnames。装上就是默认拒绝，只放行一份开发常用站点清单。

sbx login 走浏览器 OAuth，登录一次即可，后面不用反复验身份。

本地跑起来只有两行：

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

当前目录会以读写方式挂成 workspace，这是宿主机唯一暴露给 Agent 的部分。沙箱删掉之后，里面装的包和镜像全没了，宿主机工作区的文件不受影响。多个 Agent 要跑同一个仓库，用 clone mode 给它们各自的私有克隆，避免互相踩文件。

sbx ls 看列表，sbx stop 停，sbx rm 删。

系统要求这条要标清楚：macOS Sonoma 14 及以上加 Apple silicon，来自社区的 dev.to 记录，不是 Docker 官方文档写的。

网络策略才是真防线：三档选一个，别急着开 Open

结论：网络出口比文件系统危险得多。Agent 能往外连到哪儿，才是真正的边界。

三档策略按收紧程度排：

• Open：全部放行。
• Balanced：默认拒绝，放行常见开发站点，包括 AI provider API、包管理器、代码托管、容器 registry、常见云服务。
• Locked Down：全断，需要显式 allow 才能出网。

常用命令就三条：

sbx policy reset
sbx policy ls
sbx policy allow network registry.npmjs.org

规则语法记住这几种：

• example.com：精确主机名，不匹配子域。
• *.example.com：单级通配，不匹配根域。
• **.example.com：多级通配。
• host:port、IPv4 与 IPv6 CIDR 都支持。

叠加顺序上，allow 规则会合并，deny 优先。

怎么选档：如果你只让它装个依赖，Locked Down 加一条 allow 就够；如果你要它自己查文档、装包、推代码，选 Balanced；Open 只在排查网络问题时临时开一下。

一个容易忽略的点，先选 Open 再选 Balanced，访问范围并不会收窄。Open 里那条 ** 规则已经放行了所有目的地，后面的 allow 列表不会产生任何限制。想用白名单收窄，得先取消 Open。

凭证别进沙箱：给它一张只能刷指定商户的副卡

结论：真凭证留在宿主机，沙箱里只放哨兵值。

sbx secret set github --command 'gh auth token'
sbx secret ls
sbx secret rm github

可以全局设，加一个 -g，也可以按单个沙箱设。设完之后 Agent 在沙箱里看到的是一个 sentinel 值，不是你的真 token。真凭证始终躺在宿主机上，由 CLI 在出口这一侧代理掉。说白了，它拿的是一张只能刷指定商户的副卡，卡号不是你的主卡号。

如果你用 Claude Code 且有订阅，还有一条更省事的路线：在沙箱里直接 /login 走 OAuth，token 不落进沙箱。

本地到云只差一个 –cloud

结论：命令不用重学，前面加 --cloud，机器的事交给 Docker。

sbx --cloud run claude --name cloud-project
sbx --cloud create
sbx --cloud attach
sbx --cloud exec cloud-project pwd
sbx --cloud cp ./src cloud-project:/home/agent/workspace/src
sbx --cloud ports cloud-project --publish 8080
sbx --cloud ls
sbx --cloud setup ssh

ports 那条会返回一个公网 HTTPS URL，做临时预览很方便。

规格档位一共五档：micro 1 核 2G，small 2 核 4G，medium 4 核 8G，large 8 核 16G，xl 16 核 32G。不给参数默认 2 核 4G。

生命周期上，云沙箱默认 1 小时过期，可以配 1 到 24 小时，到期动作三选一：Stop、Delete、Restart。

Kits 把规则跟着镜像走

下一代 Kits 是开放规范，打包成标准 OCI 镜像，和容器用的是同一个开放标准，没有私有格式，也没有锁定。这玩意儿的好处是访问规则随 Kit 走，一次定义处处强制。发它就用发布容器镜像的同一套流程，推到 Docker Hub 即可。Kits 里内置了 MCP gateway，Agent 通过 MCP 协议 去接外部能力时，走的还是同一套策略。

顺带一提，如果你更关心 agent loop 本身怎么被托管，可以看 OpenAI Agents API。

长任务过夜：关掉笔记本，它还在跑

结论：真正的变化在这里，任务不再依赖你的终端活着。

sbx --cloud run --detached claude --name cloud-task

detached 之后沙箱自己跑。想进去看就 attach，取文件用 cp，拷代码进去还是 cp，跑单条命令用 exec，要看起的服务用 ports。

交互会话里想先退出来，按 Ctrl+\，之后 attach 回同一个会话，上下文还在。

这个组合的意义很直接：你把一整晚的时间还给 Agent，它把第二天早上的结果交给你。让 Agent 在仓库里自己干活这件事，还可以看看 GitHub 官方 gh-aw。

这四个坑，README 里都不写

坑1：装了沙箱就以为安全了。prompt injection 照样能影响 Agent 的判断。根因是沙箱只限制它能做什么，不限制它想做什么。解法是把防御当分层来做，别指望单点兜住。

坑2：sbx --cloud run claude . 直接报错。根因是 cloud 模式不接受 workspace 路径，那个点指的是你本地的文件系统。解法是用 --name 给沙箱命名，进去之后再 git clone。

坑3：本地配好的凭证，云沙箱一启动就报认证失败。根因是本地保存的凭证不会自动同步到云端。解法是先配 cloud credential，再起 Agent。

坑4：resume 已有沙箱时被拒绝。--cpus、--memory、--platform、--ttl、--env、--allow-network 都是创建期参数，不支持原地改。解法是要改配置就加 --new 新建一个。

另外，cloud 沙箱名至少 2 个字符，只能用字母数字和连字符，default 是保留名，本地允许的点号在 cloud 不合法。

敢放手，Agent 才算 Agent

回到开头那把家门钥匙。现在可以交出去了，但只交这一间屋子的。

能力的上限由模型决定，产出的上限由你敢放多少权决定。

沙箱做的事情很朴素，它把”我不确定它会不会乱来”变成”就算它乱来，也就这样”。仅此而已。

关掉笔记本的那一刻，它还在云端跑着。这才是 Agent 该有的样子。

关注圈圈，持续带你玩转 AI 工具。