Docker Sandboxes 横空出世：一条命令让 AI Agent 进入隔离 microVM，YOLO 模式终于不用提心吊胆了
Docker Sandboxes 横空出世：一条命令让 AI Agent 进入隔离 microVM，YOLO 模式终于不用提心吊胆了
你有没有过这种体验？
你给 Claude Code 开了 Full Auto 模式，然后去倒杯咖啡。
回来发现：
- 它把你 ~/.ssh 目录里的密钥读了一遍
- 它 rm -rf 了一个它以为没用的目录，结果里面有你的配置文件
- 它 npm install 装了一堆东西，把你的全局 node_modules 搞乱了
- 它跑了一个 curl 把你的代码上传到了某个地方做"分析"
你的心脏骤停了三秒。
然后你发誓再也不开 YOLO 模式了。
但是不开 YOLO 模式，每一步都要人工确认，Agent 的效率直接砍掉 80%。你又回到了"人工审批员"的日子。
这个矛盾，从 AI Coding Agent 诞生的第一天就存在，一直没有人真正解决。
直到现在。
Docker Sandboxes，Docker 官方出品，专门为 AI Coding Agent 设计的隔离运行环境。
官方文档：https://docs.docker.com/ai/sandboxes/
一句话定位：一条命令让 Agent 进入独立 microVM 沙箱，Agent 可以随便折腾，但碰不到你的宿主机。
这不是又一个 Docker 容器方案。这是真正的虚拟机级隔离，有独立的 Linux 内核。
它到底是什么？不是容器，是 microVM
很多人的第一反应是：这不就是把 Agent 塞进一个 Docker 容器里吗？我早就这么干了。
不是。区别大了。
Docker 容器：共享内核
普通 Docker 容器和宿主机共享同一个 Linux 内核。容器隔离靠的是 namespace 和 cgroups，这是进程级别的隔离，不是内核级别的。
这意味着什么？
- 容器逃逸漏洞（如 CVE-2024-21626）可以让容器内的进程直接访问宿主机文件系统
- Agent 如果拿到了容器内的 root 权限，利用内核漏洞就能逃逸到宿主机
- 你的 SSH 密钥、AWS 凭证、环境变量，都有可能被泄露
对于一个可能执行任意代码的 AI Agent 来说，这个隔离级别远远不够。
Docker Sandboxes：独立内核
Docker Sandboxes 用的是 microVM 技术。每个沙箱有：
- 独立的 Linux 内核：和宿主机内核完全隔离，不存在逃逸问题
- 独立的 Docker Engine：沙箱里可以跑 Docker，但这个 Docker 和宿主机的 Docker 完全独立
- 独立的文件系统：沙箱只能看到自己的文件系统，宿主机的文件对它不可见
- 独立的网络栈：沙箱有独立的网络命名空间，可以做网络策略管控
这意味着 Agent 可以在沙箱里面：
- ✅ 执行 sudo 命令
- ✅ 安装任意依赖包
- ✅ 跑 Docker 容器
- ✅ 修改文件
- ✅ 执行任何 Linux 命令
但是它无法：
- ❌ 读取你宿主机的 SSH 密钥
- ❌ 修改你宿主机的文件
- ❌ 访问你宿主机的网络
- ❌ 逃逸到宿主机
这才是 AI Agent 应该有的安全基线。
一条命令上手
安装 sbx CLI
# macOS / Linux / Windows
# 安装命令见官方文档
启动 Agent
cd ~/my-project
sbx run claude # 启动 Claude Code
sbx run codex # 启动 Codex
sbx run gemini # 启动 Gemini CLI
sbx run cursor # 启动 Cursor Agent
sbx run opencode # 启动 OpenCode
sbx run copilot # 启动 GitHub Copilot CLI
sbx run kiro # 启动 Kiro
一条命令。Agent 就在一个完全隔离的 microVM 里运行了。
你在沙箱里的项目目录，会通过安全的方式挂载进去。Agent 可以读写项目文件，但是它看不到项目目录之外的任何东西。
Editor 集成
你还可以用 VS Code 或 Cursor 通过 SSH 连接到沙箱：
sbx ssh --editor vscode
sbx ssh --editor cursor
这样你的编辑器在宿主机上运行，但代码执行在沙箱里。两全其美。
支持的 Agent：7 大主流全覆盖
| Agent | 命令 | 说明 |
|---|---|---|
| Claude Code | sbx run claude |
Anthropic 官方 CLI |
| Codex | sbx run codex |
OpenAI 官方 CLI |
| Gemini CLI | sbx run gemini |
Google 官方 CLI |
| Cursor Agent | sbx run cursor |
Cursor 的 Agent 模式 |
| OpenCode | sbx run opencode |
开源编码 Agent |
| GitHub Copilot CLI | sbx run copilot |
GitHub 官方 CLI |
| Kiro | sbx run kiro |
AWS 的编码 Agent |
基本上你能叫得出名字的 AI Coding Agent，全都支持了。
而且 sbx CLI 是免费的，包括商业用途。只有组织级的治理功能（集中管理策略）才需要付费订阅。
核心能力：Agent 在沙箱里能做什么？
这是最让人兴奋的部分。因为沙箱有独立的 Docker Engine，Agent 可以在沙箱里面做任何事情：
1. 构建和运行容器
Agent 可以在沙箱里 docker build 和 docker run。
这意味着 Agent 可以帮你构建 Docker 镜像、跑数据库容器、启动微服务——全部在隔离环境里。
2. 安装系统级依赖
Agent 可以 sudo apt install 或 brew install 任何东西。
不用担心搞乱你的宿主机环境。
3. 跑测试套件
Agent 可以跑完整的测试套件，包括需要数据库、Redis、Kafka 的集成测试。
4. 执行任意 shell 命令
find、grep、curl、ping、nslookup——所有 Linux 命令随便用。
5. MCP Gateway
Docker Sandboxes 内置了 MCP Gateway，你可以注册 MCP 服务器，让沙箱里的 Agent 连接外部工具和资源。
关键点：所有这些操作都在 microVM 里
Agent 在沙箱里跑的每一个命令、装的每一个包、建的每一个容器，都在 microVM 里。
关掉沙箱，一切消失。你的宿主机干干净净，什么都没动过。
安全模型：四层隔离
Docker Sandboxes 的安全模型可以从四个层面理解：
第一层：内核隔离
microVM 有自己的 Linux 内核。这是最根本的隔离层。
不存在"容器逃逸"的问题，因为 Agent 根本不在宿主机的内核空间里。
第二层：文件系统隔离
沙箱只能看到自己的文件系统。
你的项目目录通过安全挂载的方式映射进去，但宿主机的其他目录（~/.ssh、~/.aws、~/.env）对沙箱完全不可见。
第三层：网络隔离
沙箱有独立的网络命名空间。
你可以配置网络策略，控制沙箱能访问哪些外部地址。防止 Agent 把你的代码上传到不该上传的地方。
第四层：治理层（企业级）
组织管理员可以集中管理所有开发者的沙箱策略：
- 网络策略：哪些域名可以访问，哪些不行
- 文件系统策略：哪些路径可以挂载，哪些不行
- MCP 策略：哪些 MCP 服务器可以连接
这些策略在所有开发者的机器上统一生效，不需要每个人单独配置。
和其他方案的对比
| 方案 | 隔离级别 | Agent 可sudo | 可跑Docker | 易用性 | 免费 |
|---|---|---|---|---|---|
| 裸跑 Agent | ❌ 无 | ✅ | ✅ | 极简 | ✅ |
| Docker 容器 | 共享内核 | ✅ | ❌ | 简单 | ✅ |
| gVisor | 用户态内核 | 有限 | ❌ | 中等 | ✅ |
| Kata Containers | ✅ 独立内核 | ✅ | ✅ | 复杂 | ✅ |
| NVIDIA OpenShell | ✅ 独立内核 | ✅ | ✅ | 简单 | ✅ |
| Docker Sandboxes | ✅ 独立内核 | ✅ | ✅ | 极简 | ✅ |
Docker Sandboxes 最大的优势是易用性。
一条 sbx run 命令，不需要配置 microVM、不需要装 Kata、不需要写安全策略。
开箱即用，零门槛。
而且它背靠 Docker 生态，和 Docker Desktop、Docker Compose、Docker Scout 等工具无缝集成。
这个功能真正的意义
1. YOLO 模式终于可以安心开了
以前开 Full Auto / YOLO 模式，你是在赌 Agent 不会干蠢事。
现在开 YOLO 模式，Agent 在 microVM 里随便折腾，最坏的情况也就是沙箱被搞崩了，重建一个就行。
宿主机毫发无损。
2. Agent 权限可以放得更大了
以前你不敢给 Agent sudo 权限，不敢让它跑 Docker，不敢让它装系统包。
现在这些都可以给了。Agent 的能力边界，从"只敢让它改代码"，扩展到了"可以让它搭完整的开发环境"。
3. 企业级安全治理有了标准方案
以前企业想用 AI Coding Agent，最大的顾虑就是安全。每个开发者本地跑 Agent，IT 部门根本管不了。
Docker Sandboxes 的组织治理功能，让 IT 部门可以集中管控所有开发者的沙箱策略，统一安全基线。
4. Sandbox 会成为 Agent 基础设施的标配
我们之前看到了 NVIDIA OpenShell、Kubernetes Agent Sandbox、E2B 等各种沙箱方案。
Docker Sandboxes 的加入，标志着这个赛道已经从"实验性探索"进入了"主流采用"阶段。
未来一年内，不做沙箱隔离的 Agent 工具，会越来越难被企业接受。
写在最后
AI Coding Agent 的能力越来越强，权限越来越大。
从只能改代码，到能跑命令、装依赖、构建镜像、部署服务。
能力越大，风险越大。
Docker Sandboxes 给出了一个优雅的答案：
不是限制 Agent 的能力，而是限制 Agent 的爆炸半径。
让 Agent 在 microVM 里尽情发挥，想干什么干什么。
但是它的手，伸不到你的宿主机上来。
一条 sbx run 命令，解决整个安全问题。
这就是好的基础设施应该有的样子：强大到你看不到它存在，简单到你只需要一条命令。
非常推荐所有人去试一试。从今天起，开 YOLO 模式，不用再提心吊胆了。
作者: itech001
来源: 公众号：AI人工智能时代
网站: https://www.theaiera.cn/
每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
