AI 编码代理需要运行代码、安装包和构建容器。这正是它们的功能所在。但给一个自主代理全权访问你的机器是可怕的。一次幻觉的 rm -rf 就意味着你需要从备份中恢复。

Docker 的答案是沙箱 —— 微虚拟机隔离环境，每个代理都有自己的 Linux 内核、Docker 守护进程、文件系统和网络。命令行接口称为 sbx。你安装它，使用 Docker 登录，然后通过一个命令在沙箱中启动一个代理。

sbx run claude --name my-project

就是这样。代理在虚拟机中运行。它可以在里面做任何它想做的事情。你的主机保持干净。

为什么是微虚拟机而不是容器

容器共享主机内核。对于受信任的工作负载，这是可以接受的。但对于一个可能会产生破坏性命令的 AI 代理来说，这就不行了。一个挂载了 Docker 套接字的容器给了代理对你环境的全权访问。这不是隔离 —— 这只是一个行为建议。

Docker 沙箱使用轻量级的微虚拟机。每个沙箱都有自己的 Linux 内核。虚拟机的边界是隔离控制，而不是命名空间的把戏。虚拟机中的进程对你的主机是不可见的。代理看不到你的其他容器、工作区之外的文件或主机网络。

代价是资源开销。一个虚拟机加上它自己的 Docker 守护进程比一个容器重。但对于自主代理来说，完全的隔离是值得的。

五层隔离

这里有趣的是，Docker 并没有简单地把一个虚拟机套在代理外面就完事了。这里有五层不同的隔离：

1. 虚拟机 — 每个沙箱都有一个独立的内核。进程对主机不可见。指向工作区之外的符号链接不会被跟随。

2. 网络 — 每个沙箱都有自己的隔离网络。所有 HTTP/HTTPS 通信都通过主机侧代理路由。网络层阻止了原始 TCP、UDP 和 ICMP。沙箱之间以及与主机的 localhost 之间不能互相通信。

3. Docker 引擎 — 每个沙箱运行自己的 Docker 守护进程。当代理运行 docker build 或 docker compose up 时，这些命令执行在沙箱的引擎上。没有通往主机 Docker 的路径。

4. 工作区 — 有两种模式。直接挂载（默认）模式共享你的工作目录的读写权限 —— 变更会立即反映在主机上。克隆模式（--clone）在沙箱内部创建一个私有的 Git 克隆 —— 代理的更改只有在你拉取它们之前不会到达主机。

5. 凭证代理 — 这是聪明的一招。主机侧代理拦截出站 API 请求并注入认证头。真正的 API 密钥从未进入沙箱。代理只能看到一个哨兵值，如 proxy-managed。一个被攻破的沙箱无法读取你的 Anthropic 密钥，因为它从未在那里。

凭证模型

代理为所有主要提供商管理凭证 —— Anthropic、OpenAI、Google、GitHub、Groq、Mistral、xAI 等。你通过 sbx secret set 一次存储密钥，然后代理会在每个沙箱中处理注入。

sbx secret set anthropic
sbx secret set openai --sandbox my-sandbox  # 仅限一个沙箱

在沙箱内部访问 GitHub：

echo "$(gh auth token)" | sbx secret set github

代理可以创建 PR、打开问题并交互式使用 GitHub API。令牌从未以明文形式存储在沙箱内部。

SSH 代理转发也适用。你的私钥保留在主机上。沙箱可以请求签名以用于提交签名，但无法读取或复制密钥。

如果你使用 1Password，你可以在每次启动时从你的密钥库中获取凭证：

ANTHROPIC_API_KEY="op://Work/Anthropic/credential" op run -- sbx run claude

真正的价值保留在 1Password 中。沙箱从未见过它。

网络治理

网络策略系统展示了 Docker 的企业级 DNA。有三种预设：

  • 开放 — 允许一切。适合个人实验。
  • 平衡 — 默认拒绝，允许常见开发站点。这是正确的起点。
  • 严格限制 — 完全阻止，包括模型提供商 API。你必须显式地进行白名单。
sbx policy allow network api.example.com
sbx policy deny network ads.example.com
sbx policy check network api.anthropic.com  # 在运行前测试

你可以将规则限定到特定的沙箱，检查流量日志，并查看哪些规则匹配了每个请求。对于从沙箱内部访问主机服务，使用 host.docker.internal — 但你必须首先将 localhost 地址添加到允许列表。

企业治理

对于组织来说，Docker 添加了完整的治理层：

  • 组织策略 通过 Docker Home UI 或治理 API 中心化管理
  • 团队限定 — 不同的规则适用于不同的团队，从你的身份提供商同步
  • MCP 访问策略 使用 Cedar 编写 — 控制代理可以使用的 Model Context Protocol 服务器，每个请求都有审批闸门
  • 文件系统策略 — 控制沙箱可以挂载的主机路径
  • 登录强制执行 — 限制沙箱仅限特定 Docker 组织中的用户，通过 MDM 或组策略部署

当组织治理生效时，只有组织允许规则授予访问权限。本地允许规则变得无效。本地拒绝规则仍然适用，因此开发人员可以进一步限制但不能放松限制。这是受监管环境中正确的模型。

审计一切

每个策略决策都被记录下来。本地审计日志是主机上的 JSON Lines 文件。云交付将事件存储在 Docker Cloud 中，保留时间可配置。SIEM 转发支持 Splunk、Dynatrace 和自定义 HTTPS 端点。

记录只捕获元数据 — 资源、操作、裁决和拒绝原因。没有提示内容，没有代理输出。这正是你在不侵犯隐私的情况下进行合规所需的内容。

对于任何处于受监管行业的人来说 — GxP、CSV/CSA、验证系统 — 这个审计轨迹意味着从“我们认为我们的代理是安全的”到“这是证据”。元数据仅策略意味着你可以证明治理而不暴露代理实际生成的内容。

默认被阻止的内容

有些事情不能通过策略改变：

  • 主机文件系统的访问，超出挂载的工作区之外
  • 主机 Docker 守护进程
  • 主机网络和 localhost
  • 沙箱之间的直接通信
  • 原始 TCP、UDP 和 ICMP
  • 私有 IP 范围和链路本地地址的流量

这是合理的默认设置。你不会不小心打开通往主机 Docker 套接字的漏洞或暴露你的本地网络。

陷阱

没有什么是免费的。每个沙箱运行一个完整的虚拟机，有自己的 Docker 守护进程。这是真实的内存和磁盘开销。如果你并行运行多个沙箱，你的机器需要处理这些。

克隆模式保护了你的主机仓库免受修改，但不是免受检查。你的 .env 文件、未跟踪的文件以及 .gitignore 下的内容仍然可以被沙箱内部的代理读取。如果你的工作目录中有秘密，它们是可见的。

共享技能存储默认以读写模式挂载。任何沙箱都可以修改其他沙箱加载的技能。这将每个共享存储的沙箱置于相同的信任边界内。使用 --no-share-skills 选项可以退出。

而且 Docker Desktop 不是必需的 — 但 Docker 账户登录是必需的。命令行使用 Docker OAuth。对于 CI，你需要一个个人访问令牌。

最后的话

Docker 沙箱是我见过的对“如何让 AI 代理自由运行而不破坏系统”问题的最完整答案。五层隔离模型是纵深防御的正确实现。凭证代理真正聪明 — 完全将真实 API 密钥保留在沙箱之外是那种实际有效的安全设计。

对于个人开发者来说，这是使用 AI 代理的更好方式。对于组织来说，治理和审计层使其在受监管环境中可行。基于 Cedar 的 MCP 策略和 SIEM 转发的审计日志不是玩具 — 它们是合规团队真正接受的控制。

资源开销是真实的，克隆模式的只读但可检查边界存在漏洞。但这都是工程权衡，而不是设计缺陷。如果你在任何你关心的地方运行 AI 代理，这值得一看。