面向 AI 代理的 Docker Sandboxes

Docker Sandboxes Enable Safe Autonomy for AI Agents

Docker Sandboxes 为 AI 编程代理（如 Claude Code, Gemini CLI, Copilot CLI, Codex, OpenCode, 和 Kiro）提供专门设计的、可丢弃的隔离环境，这些代理需要无人值守的执行。通过将代理隔离在专用的 microVM 中，开发者可以授予代理安装包、修改配置以及运行 Docker 容器的自主权，而不会危及宿主系统的完整性。

Core Architecture: MicroVMs vs. Containers

与标准的 Docker 容器不同，Docker Sandboxes 利用 microVM 架构在代理与宿主之间创建了更强的安全边界。

MicroVM Isolation: 每个代理都在一个拥有独立内核的专用 microVM 中运行，利用平台的原生 hypervisor（macOS 上的 Hypervisor.framework，Windows 上的 WHP，以及 Linux 上的 KVM）。
Technical Implementation: 系统使用了一种新的 VMM (Virtual Machine Monitor) 并通过 nerdbox 与 containerd 集成，以管理这些轻量级虚拟机。
Performance: 这些环境旨在比传统 VM 更快地启动和销毁，同时提供比基于 cgroups 的容器更强的隔离性。

Key Capabilities and "YOLO Mode"

Docker Sandboxes 旨在消除手动权限提示带来的摩擦，允许代理以全速运行。

Unattended Execution: 代理可以执行长时间运行的任务，包括安装系统依赖项并在沙箱内启动它们自己的容器。
YOLO Mode: --dangerously-skip-permissions 标志允许代理在无需审批提示的情况下运行。由于任何破坏性操作都被限制在可丢弃的 microVM 中，因此这种模式是安全的。
Customizable Controls: 用户可以定义网络和文件系统控制，以限制代理可以访问的内容。对于组织层面的强制执行，这些控制可以通过 Docker AI Governance 进行管理。
Workspace Mounting: 只有项目工作区从宿主挂载到 microVM 中，确保宿主文件系统的其余部分保持不变。

Installation and Compatibility

Docker Sandboxes 目前适用于 macOS 和 Windows：

macOS: brew trust docker/tap && brew install docker/tap/sbx
Windows: winget install Docker.sbx

值得注意的是，该产品不需要 Docker Desktop 即可运行。虽然营销重点在于 macOS 和 Windows，但社区讨论指出，目前主产品页面上缺乏明确的 Linux 安装说明，尽管底层架构支持 KVM。

Community Insights and Technical Critiques

开发者之间的技术讨论揭示了关于代理沙箱化的几个争议点和替代方案：

Security and Trust

一些用户认为没有任何沙箱是完美的，并表示更倾向于开源替代方案，以便可以审计安全边界。有人担心 AI 代理可能会为了实现模糊的提示词而采取“极端、破坏性的手段”，从而使强大的隔离成为一种必要。

User Experience Friction

多名用户反映，使用该工具需要登录 Docker 账号的限制令人沮丧，并将其描述为开发者工具采用过程中的一个重大障碍。

Alternative Implementations

开发者们分享了各种自建的替代方案，包括：

Podman-based setups: 使用带有用户命名空间映射的 rootless、daemonless 容器。
QEMU/KVM: 使用 QEMU 的 microVM 机器类型在禁用权限检查的情况下运行代理。
Wasm-based execution: 实现一个 bash 脚本解析器和解释器，并配合 Wasm 执行器进行极简计算。
Full VM Isolation: 在一个带有专用防火墙区域的完整 Linux VM 中运行代理，并在宿主上进行手动 git diff 审查。

Feature Gaps

用户指出当前功能存在一些局限性，例如无法配置自定义卷挂载，除了当前工作目录之外，这使得需要为代理配置多个上下文目录的设置变得复杂化。