用 Docker 沙盒隔离 AI 编程 Agent：安全运行指南

Blog 1 — Docker Sandboxes 系列

Docker Sandboxes 入门——什么是它、为何存在、如何配置、第一个 Sandbox 及基础隔离

读完这篇博客，你将理解为什么在普通笔记本上运行 AI 编程 Agent 存在风险，学会安装 sbx CLI、启动你的第一个隔离沙箱、亲眼看到隔离边界，并正确清理所有资源。

不需要付费 AI 订阅。我们使用 shell agent。

AI 编程 Agent 的价值在于它们能自主行动。它们安装依赖包、编辑文件、运行测试、构建 Docker 镜像，有时还会执行你绝不会亲自动手的命令。

如果直接在宿主机上运行，它们可以：

• 修改或删除项目目录之外的文件
• 安装系统包，破坏现有环境
• 访问宿主机的 Docker daemon
• 连接到任意网络地址
• 意外暴露环境中已存在的凭据

普通容器共享宿主内核。挂载 Docker socket 等于把和你同等的权限给了 Agent。完整的虚拟机又重又慢，启动时间长。

Docker Sandboxes 通过为每个 Agent 提供独立的轻量级 microVM 来解决这一问题。

Before vs After — 核心问题

图示说明：左侧展示危险默认状态——Agent 在宿主机上拥有和你一样的权限。右侧展示沙箱方案——Agent 被锁定在一个 microVM 内部。只有项目文件夹被共享，其他一切保持隔离。

开始之前你需要了解的事

• 熟悉终端操作
• 支持平台：
  • macOS
  • Windows 11（需启用 Windows Hypervisor Platform）
  • Ubuntu 24.04+（需 KVM 正常工作）

Docker Desktop 不是必须的。（对企业用户没有阻碍……）

安装方式：

macOS：

brew trust docker/tap
brew install docker/tap/sbx

Linux：

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm

Windows：

winget install -h Docker.sbx

验证安装：

sbx version

登录：

sbx login

步骤 1 — 创建简单项目

mkdir -p ~/sandbox-lab
cd ~/sandbox-lab
echo "hello from the host" > note.txt

步骤 2 — 启动第一个 Sandbox

sbx run --name first-sandbox shell

首次运行选择 Balanced 网络预设（推荐）。

你现在进入的是一个运行在 microVM 内部的 Bash shell。

步骤 3 — 在 Sandbox 内部查看环境

pwd
ls -la
cat note.txt
whoami
docker version

在宿主机上打开第二个终端：

sbx ls

高级 Sandbox 架构（你刚才创建的内容）

图示说明：你通过 sbx CLI 进行交互。CLI 启动一个 microVM。在 microVM 内部运行着 Agent、它的 Docker daemon 和文件系统。唯一连接回宿主机的路径是你选择的工作区文件夹。

步骤 4 — 验证隔离效果

在 sandbox 内部执行：

echo "written from inside the sandbox" >> note.txt
echo "created inside sandbox" > from-sandbox.txt
docker pull alpine:latest
docker images

在宿主机上检查：

cat ~/sandbox-lab/note.txt
ls ~/sandbox-lab
docker images | grep alpine || echo "alpine image is NOT on the host"

注意：理想情况下你应该看到输出中包含 alpine image is NOT on the host，但由于我在另一个应用中也使用了 postgres alpine 镜像，所以它显示了——不过你可以观察到，在 sandbox 中拉取的 alpine 镜像并不在宿主机上。

隔离边界图示

图示说明：项目文件夹中的文件可以双向流动（实时挂载）。sandbox 内的 Docker daemon 没有路径通向宿主机的 Docker daemon。镜像和容器都停留在 microVM 内部。

内部发生了什么

microVM 有自己的内核。Agent 在 microVM 内部拥有完整权限（包括 sudo）。网络流量通过宿主机侧的代理转发，由你选择的策略进行控制。凭据（后续用到时）由代理注入，绝不会存储在 VM 内部。

让我们来测试一下（温和地）

在 sandbox 内部尝试：

curl -I https://koti.dev

如果在 Balanced 策略下被阻止，这是预期行为。

在宿主机上放行：

sbx policy allow network koti.dev

重试。现在应该可以工作了。

实际工作中的我的习惯：

• 从 Balanced 或更严格的策略开始
• 为每个 sandbox 设置清晰的名字
• 对实验性或不信任的 Agent 工作优先使用 --clone
• 把 sbx rm 当作结束会话的正常方式

安全注意事项

Agent 在 sandbox 内部权限很大。不要把它当成普通的受限容器来对待。

• 工作区默认是可读写的。
• 永远不要把长期有效的密钥作为普通环境变量放在 sandbox 内部（proper way 会在下一篇博客中介绍）。
• 忘记将用户加入 Linux 上的 kvm 组 → sandbox 无法启动
• 期望宿主 Docker 能看到在 sandbox 内部构建的镜像
• 留下多个运行中的 sandbox → 磁盘被填满

诊断：

sbx diagnose

清理：

sbx stop first-sandbox
sbx rm first-sandbox
sbx ls

你的 ~/sandbox-lab 文件夹仍然存在。只有 microVM 被删除了。

小结

AI Agent 需要强隔离。MicroVM 在不带来完整 VM 重量的情况下提供了这种隔离。

sbx CLI 是目前使用 Docker Sandboxes 的免费方式。

工作区是共享的；几乎所有其他东西都停留在 sandbox 内部。

你现在可以安装、启动、检查和干净地移除一个 sandbox。

在 Blog 2 中，我们将完全掌控环境：文件如何持久化、直接挂载和 clone 模式的区别、网络策略深度讲解，以及安全注入密钥的正确方式——让 Agent 永远看不到真实的值。

官方文档链接：

https://docs.docker.com/ai/sandboxes/ — 官方概览

https://docs.docker.com/ai/sandboxes/get-started/ — 安装和首次运行

https://docs.docker.com/ai/sandboxes/architecture/ — microVM 和隔离细节

https://docs.docker.com/reference/cli/sbx/ — 命令参考

所有命令和行为均已对照当前官方文档（2026 年 8 月）进行验证。