别再让AI代理在你的电脑上无人监管地运行
让编程智能体在你的开发机上随意运行，是一种重大且不必要的风险。自主智能体可以装包、跑测试、改代码，便利性毋庸置疑，但安全模型一直是块短板。现在有了一款新工具，补上了缺失的隔离环节，让本地智能体执行从负担变成了可行实践。
Docker Sandboxes 为你的智能体提供了一个基于虚拟机监控程序（hypervisor）的隔离沙箱。这不只是又一个容器，而是一个专门构建的轻量微虚拟机（microVM），每个智能体都拥有自己的内核、文件系统和网络栈。它实现了与宿主机的硬隔离——任何自主执行的工具，都理应默认具备这种隔离能力。
智能体管控难题
核心问题在于，功能强大的智能体要想有用，就必须拥有宽泛的权限。它需要访问你的 shell、文件系统和网络。普通容器和宿主机共享内核，攻击面很大。我们已经多次看到，一些大实验室的智能体因为配置错误而突破了测试环境的报道。智能体既会写文件，又能执行命令，一个小疏忽就可能导致整台机器被入侵。
以往的解决办法是不断弹出权限确认框，但这反而让自主工作流失去了意义。完整虚拟机又太笨重、太缓慢，不适合智能体开发所需的快速、用完即弃的环境。Docker Sandboxes 正是冲着这个空缺来的：既具备虚拟机的安全性，又保持了容器的易用性。
微虚拟机隔离的工作原理
与标准容器不同，微虚拟机（microVM，以下简称 mVM）不与宿主机共享内核。当你在沙箱里启动一个智能体时，Docker 会拉起一个拥有独立专用资源的 mVM。你的项目目录会挂载进去，但智能体看不到、也碰不到工作区以外的任何东西。它可以安装包、构建容器，甚至执行 rm -rf，都不会影响到宿主机。
这种架构也为网络和凭据安全提供了关键保障。网络访问默认全部拒绝，迫使你选择类似 "Balanced" 或 "Locked Down" 的策略。
这样智能体就无法意外泄露数据。LLM API 密钥同样受到保护：密钥由宿主机侧的代理注入，智能体本身始终接触不到原始凭证。
开始使用 sbx CLI
你可以通过 sbx 命令行工具与沙箱交互。安装通过标准包管理器完成，macOS 上可以使用 Homebrew。
# Install the CLI on macOS
brew install docker/tap/sbx
# Authenticate with Docker
sbx login
# Navigate to your project and run an agent
cd ~/your-project
sbx run claude
sbx run 命令会在一个独立的沙箱微型虚拟机（mVM）中启动指定的代理。目前支持 Claude Code、Gemini CLI、Copilot CLI 等。首次运行它时，系统会提示你设置默认网络策略。“平衡”选项是一个合理的起点，它允许访问常见的包管理器和代码托管平台，同时阻止其他流量。还有更高级的选项，包括一个 --dangerously-skip-permissions 标志，用于需要在沙箱内授予代理完全自主权的情况。请谨慎使用，但要明白这正是关键所在：危险现在完全被限制在一个可丢弃的环境中。
技术栈中的必要一环
代理式工作流正从一种新奇事物演变为开发流程的核心部分。但迄今为止，在本地运行它们一直需要在实用性和安全性之间进行直接权衡。默认将代理封装在隔离的微虚拟机中，是正确架构模式。这让尝试不同代理以及复杂的多步骤任务变得更加安全。如果代理破坏了其环境，你只需销毁沙箱并重新开始。这不仅仅是一个新功能；它是当今任何用AI构建应用的工程师的基础设施基石。