用於 AI Agent 的 Docker Sandboxes

Docker Sandboxes 為 AI Agent 提供安全的自主權

Docker Sandboxes 提供專為 AI 編碼代理（例如 Claude Code、Gemini CLI、Copilot CLI、Codex、OpenCode 和 Kiro）設計的拋棄式、隔離環境，這些代理需要進行無人值守的執行。透過將代理隔離在專用的 microVM 中，開發者可以賦予代理安裝套件、修改配置和運行 Docker 容器的自主權，而不會冒著破壞主機系統完整性的風險。

核心架構：MicroVMs vs. Containers

與標準的 Docker 容器不同，Docker Sandboxes 利用 microVM 架構在代理與主機之間建立更強大的安全邊界。

• MicroVM 隔離： 每個代理都在一個擁有獨立核心的專用 microVM 中運行，利用平台的原生 Hypervisor（macOS 上的 Hypervisor.framework、Windows 上的 WHP 以及 Linux 上的 KVM）。
• 技術實現： 系統使用新的 VMM (Virtual Machine Monitor)，並透過 nerdbox 與 containerd 整合，以管理這些輕量級虛擬機。
• 效能： 這些環境的設計目標是比傳統 VM 更快地啟動與銷毀，同時提供比基於 cgroups 的容器更強大的隔離性。

關鍵能力與「YOLO Mode」

Docker Sandboxes 的設計旨在消除手動權限提示的摩擦，讓代理能夠全速運作。

• 無人值守執行： 代理可以執行長時間運行的任務，包括安裝系統依賴項並在沙盒內啟動自己的容器。
• YOLO Mode： --dangerously-skip-permissions 旗標允許代理在沒有核准提示的情況下運作。這之所以安全，是因為任何破壞性行為都僅限於拋棄式的 microVM 中。
• 可自定義的控制： 使用者可以定義網路和檔案系統控制，以限制代理可以存取的內容。對於組織層級的強制執行，這些控制可以透過 Docker AI Governance 進行管理。
• 工作區掛載： 只有專案工作區會從主機掛載到 microVM 中，確保主機檔案系統的其他部分保持不變。

安裝與相容性

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。

社群見解與技術評論

開發者之間的技術討論揭示了關於代理沙盒化的幾個爭議點和替代方案：

安全性與信任

一些使用者認為沒有任何沙盒是完美的，並表示更偏好可以審核安全邊界的開源替代方案。有人擔心 AI 代理可能會為了達成模糊的提示而採取「極端、具破壞性的手段」，這使得強大的隔離成為必要條件。

使用者體驗摩擦

多位使用者反映，使用該工具需要登入 Docker 帳戶，這對開發者工具來說是一個顯著的採用障礙。

替代實現方案

開發者分享了各種自行構建的替代方案，包括：

• 基於 Podman 的設置： 使用具有使用者命名空間映射的無根 (rootless)、無守護進程 (daemonless) 容器。
• QEMU/KVM： 使用 QEMU 的 microVM 機器類型，在禁用權限檢查的情況下運行代理。
• 基於 Wasm 的執行： 使用 Wasm 執行器實現 bash 腳本解析器和解釋器，以進行極小運算。
• 全 VM 隔離： 在具有專用防火牆區域的完整 Linux VM 中運行代理，並在主機上進行手動 git diff 審核。

功能缺失

使用者指出目前功能中的局限性，例如無法配置當前工作目錄以外的自定義磁碟卷掛載，這使得需要為代理配置多個上下文目錄的設置變得複雜。