Docker发布Sandboxes CLI,支持在丢弃式microVM中运行Claude Code、Gemini CLI等AI代理,只挂载项目workspace,主机文件网络全程隔离。
Docker 发布了 Sandboxes,这是一款在一次性 microVM 中运行代码 Agent(如 Claude Code、Codex 或 Gemini CLI)的工具,将每个会话与主机其他部分隔离开来。核心理念很直接:让 Agent 以 YOLO 模式工作,无需逐个审批每条命令,不用担心 Agent 破坏主机文件系统或网络。
这一工具诞生的时机恰到好处:如今整支团队都在把长任务委托给自主运行的 Agent,亟需在"Agent 随意行事"和"Agent 搞垮生产环境"之间建立一道真正的安全屏障。
Docker Sandboxes 提供了一个专用隔离层,让代码 Agent 在无需人工持续监控的情况下执行长任务。其核心思路是:每个 Agent 运行在一个一次性 microVM 中,仅挂载项目工作区,主机系统其余部分对 Agent 不可见。
根据官方产品页,内置支持的 Agent 包括 Claude Code、Gemini CLI、Copilot CLI、Codex、OpenCode 和 Kiro。在 sandbox 内,Agent 可以安装包、修改配置文件,甚至启动自己的 Docker 容器——整个过程无需开发人员手动逐步审批。
安装过程极简:macOS 和 Windows 各一条命令,无需后台运行 Docker Desktop。Docker Sandboxes 安装是一条命令,无需 Docker Desktop。
Docker Sandboxes 解决的问题并不新鲜:源于将任务委托给自动化进程时速度与安全之间的矛盾。传统容器共享主机内核,轻量但不够坚固——一旦容器内进程突破隔离就会波及主机。完整虚拟机提供更强的隔离(因为虚拟化了整个硬件),但启动需要数秒甚至数分钟,且消耗更多资源。
microVM(由 AWS 的 Firecracker 等项目推广)在两者之间找到了平衡点:拥有接近容器级别的启动速度,同时具备 hypervisor 级别的隔离性。Docker 在发布时未公开 sbx 底层使用的 hypervisor,但总体方案(每会话专用一次性 microVM)与该技术路线完全吻合。
Sandboxes 的不同之处在于目标用户:它不是用来跑无服务器函数的基础设施,而是专门为代码 Agent 打造的运行环境——默认启用 --dangerously-skip-permissions 标志。在此之前,大多数团队在手动配置的 VM 外是不敢这么做的。
每个 sandbox 都是一个专用 microVM,内置用户开发环境,仅挂载项目工作区。主机文件系统其他部分对 Agent 完全不可见。网络也可通过自定义策略限制,但要全团队集中应用策略,需要额外层 Docker AI Governance。
一个重要细节:Agent 可以在 sandbox 内运行 Docker。需要拉起测试数据库或辅助服务的 Agent 可以用嵌套容器实现,不影响真实主机。
| 选项 | 何时使用 | 优势 | 局限性 |
|---|---|---|---|
| Docker Sandboxes(microVM) | 在无需持续监控的情况下运行 AI Agent | 强隔离、快速启动、一次性 | 依赖 CLI sbx;高级策略需要 Docker AI Governance |
| 经典容器(Docker Desktop) | 日常开发,不向 Agent 委托全部控制权 | 共享主机内核,开销最小 | 面对拥有广泛权限的进程时隔离较弱 |
| 传统 VM(VirtualBox/VMware) | 硬件级完全隔离或多租户场景 | 最高隔离级别 | 启动慢,资源消耗高 |
简化的流程是:主机启动 CLI,CLI 创建 microVM,Agent 在该 microVM 内以广泛权限运行,包括嵌套运行自己的容器的能力。
flowchart TD
A["Tu máquina host"] --> B["CLI sbx"]
B --> C["Sandbox microVM"]
C --> D["Agente de IA: Claude Code"]
D --> E["Contenedor Docker anidado"]
subgraph Aislado
C
D
E
end
💡 Tip: 在未安装 Docker Desktop 的情况下运行 sbx:CLI 自带 microVMs 运行时。
安装 Docker Sandboxes 在不同操作系统上都是一条命令。在 macOS 上:
brew trust docker/tap && brew install docker/tap/sbx
该命令将 Docker 官方 tap 添加到 Homebrew,然后安装 sbx 二进制文件。在 Windows 上等价命令是:
winget install Docker.sbx
发布时,Docker 未在官方产品页公布面向 Linux 的等效包管理器安装程序;Linux 用户需查阅官方文档获取其发行版的支持路径。
安装完成后,在 sandbox 中启动 Agent 的一般模式与 Docker 文档一致:创建 microVM,在其中以宽松模式运行 Agent CLI,例如:
# 说明性模式,请参阅官方文档确认确切语法
sbx run -- claude --dangerously-skip-permissions
为确认 sandbox 确实隔离了 Agent,最简单的办法是对比从内部可见的文件系统(仅项目工作区)与主机真实文件系统:如果 Agent 能列出项目外的目录,说明隔离未按预期生效。
⚠️ 注意:在 sandbox 外使用 --dangerously-skip-permissions 会让 Agent 完全访问真实系统:该标志只有在 Sandboxes 提供的隔离内才是安全的。
Docker 发布了已将 Sandboxes 集成到自有产品的合作伙伴证言。NanoClaw 创建者 Gavriel Cohen 总结了发布背后的理念:"you don't trust agents with security, you build walls around them",并称 Docker Sandboxes 为平台级隔离基础设施。
Warp 工程负责人 Ben Navetta 指出,Sandboxes 使 Agent 能在不危及安全的情况下执行长任务,Warp 正在集成该工具,使 Agent 无论在本地还是云端都能以一致的环境运行。
这一举动契合更宏观的趋势:随着更多团队在数小时内以自主模式运行 Agent 而无持续人工审查,拥有广泛权限的单个进程风险面不断增大。Docker 打赌:比完整 VM 启动更快的 microVM 隔离,将成为此类工作负载的默认标准。每个 sandbox 仅挂载项目工作区,主机其他部分一律不可见。
对于需要比单 sandbox 隔离更多防护的组织,Docker 提供 Docker AI Governance 作为额外层级:sandbox 环境的网络访问策略、文件系统访问管控与限制,以及覆盖整个组织的 MCP 集中治理——定义一次,应用到每位开发者的机器上。
Docker Sandboxes 也不依赖 Docker Desktop 来运行,这表明该公司将此产品定位为独立基础设施,专门面向已在生产或 CI 环境中使用代码 Agent 的团队。
📖 Telegram 摘要:在 Telegram 查看摘要
立即试用:运行 brew trust docker/tap && brew install docker/tap/sbx,在隔离 sandbox 内启动你的第一个 YOLO 模式 Agent。
一种隔离 microVM 环境,保护主机文件系统和网络免受 Agent 在内部操作的影响。Docker Sandboxes 仅挂载项目工作区:磁盘其余部分均在 Agent 触及范围之外。
内置支持 Claude Code、Gemini CLI、Copilot CLI、Codex、OpenCode 和 Kiro。也可以为其他 Agent 定义自定义 sandbox。
YOLO 模式即以 --dangerously-skip-permissions 标志运行 Agent,无需对每个操作请求批准。这是 Agent 快速、无监督工作的必要条件,但在隔离环境外有风险。Sandboxes 将其封装在专用 microVM 中,使其变得安全。
sandbox 完全在 microVM 内隔离运行,相比容器提供更强隔离,同时无需付出完整 VM 的启动成本。这使得它们能够安全地执行需要更多权限的操作,比如在内部运行自己的 Docker 容器。
可以定义自定义网络和文件系统策略。要在全团队集中应用(网络访问策略、文件系统规则和 MCP 治理),可使用面向组织的 Docker AI Governance。
不需要。Docker Sandboxes 独立运行,不依赖主机上安装的 Docker Desktop。
📱 喜欢这类内容?加入我们的 Telegram 频道 @programacion,每日发布科技、AI 和开发领域最相关的内容。每天快速摘要,新鲜内容不断。