Docker Sandboxes vs. Containers: Choosing the Right Isolation for AI Agents

Docker 沠箱与容器：关键区别 | Docker

Docker 沠箱与容器：为 AI 代理选择合适的隔离方式

发布于 2026 年 11 月 5 日

Srini Sekaran

和

Oleg Selajev

如果你已经使用 Docker 有一段时间，"Docker 沠箱"可能听起来像是"一个装有 AI 代理的容器"。容器在过去十年中一直是 Docker 几乎所有功能的单位，而沙箱可能听起来只是另一种打包工作负载的方式。

实际上它们是不同的技术。容器是一个与机器上其他所有内容共享主机内核的隔离进程。Docker 沠箱是专为需要完整开发环境的自主编码代理设计的微型虚拟机，拥有自己的 Linux 内核、文件系统、网络和 Docker 引擎。沙箱可以运行容器，这也是两者容易混淆的部分原因之一。

在 WeAreDevelopers 主题演讲中，Docker 首席执行官 Mark Cavage 表示，容器正在准确执行它们被设计来完成的任务，但我们却要求它们去做不同的工作。

容器最初设计用于隔离应用程序，它们在这方面仍然表现良好。但编码代理是一个行动者：它像开发者使用笔记本电脑一样在你的系统上做决策和操作。它会克隆仓库、安装软件包、启动数据库、构建镜像，并持续数小时反复尝试。它还可以根据文件、网页和未经审查的工具输出中的指令采取行动。

这种不同的任务需要不同的边界，而这个边界的设置决定了代理的错误能造成多大影响。本文将介绍 Docker 沠箱和容器如何隔离工作负载，内核之外发生了哪些变化，设置沙箱需要付出什么代价，以及如何选择。

关键要点 容器是与主机内核共享的隔离进程。Docker 沠箱是拥有自己内核、文件系统、网络和 Docker 引擎的微型虚拟机。容器仍然是打包应用程序、CI 任务和短暂执行的正确选择。Docker 沠箱适合需要 sudo 权限、私有 Docker 引擎、长期状态以及主机强制网络和凭证控制的自主代理。容器可以作为代理的隔离部分，而沙箱可以运行它们。隔离代理，容器化它所操作的应用程序。

什么是容器？

容器是一个进程或一组进程，在主机上运行，拥有自己的文件系统视图、进程树和网络视图。Linux 命名空间提供了这种视图，而 cgroups 用于计量 CPU、内存和 I/O。机器上的每个容器都共享主机内核，这就是为什么容器启动速度快、密度高且开销极小的原因。

这种设计背后有十多年工具链的支持。Compose、Kubernetes、OCI 仓库、镜像扫描器和几乎所有 CI 系统都将容器视为通用的原始单位。如果任务是运行服务、执行代码片段、处理一个请求或运行评估后消失，容器通常是显而易见的选择，而且会继续保持这样。

ⓘ 即使在虚拟机中，容器也共享一个内核。在 macOS 和 Windows 上，Docker Desktop 在虚拟机中运行你的 Linux 容器，这使它们与你的主机操作系统隔离。该虚拟机中的每个容器仍然共享其单个内核，因此一个容器与另一个容器之间的隔离性保持不变。

什么是 Docker 沠箱？

Docker 沠箱在拥有独立 Linux 内核、独立文件系统和网络栈以及私有 Docker 引擎的微虚拟机（microVM）中运行 AI 编码代理。代理在隔离环境中获得 sudo 权限，可以安装软件包、运行服务、构建镜像，并在不接触宿主机 Docker 守护进程、工作区外的宿主机文件系统或其他同机沙箱的情况下，启动完整的 Compose 应用。

启动一个沙箱只需一条命令，使用 sbx，即 Docker 沠箱的 CLI 工具：

sbx run claude

这将创建沙箱并启动代理。你可以停止它、恢复它，并在删除沙箱前随时返回到代理安装的所有内容。

为什么编码代理需要完整的机器？

编码代理需要完整机器是因为它们的会话会在数小时内积累状态，并且需要执行未经验证的指令。容器是为具有已知依赖关系的进程设计的，而代理的工作方式与容器的这种设计并不匹配。

代理需要整个机器的权限和专为其设计的边界。使代理有用的功能（如运行代码、安装软件包和访问网络）也是可能侵蚀其边界的功能。代理需要探测环境边界，因为工作本身需要改变环境。

代理会在数小时内积累状态

编码代理的会话就像开发者的下午工作：克隆仓库、安装软件包、启动 PostgreSQL、运行迁移、构建镜像、使用 Compose 启动应用、查看日志、修改代码并再次尝试。这个循环可能持续数小时，每一步都依赖于前一步留下的状态。

容器的设计是通过镜像和少量显式卷重新构建。代理在这些卷之外创建的软件包、数据库和构建输出会在容器被重新创建时丢失。这对于每个步骤都依赖于前一步的会话来说并不理想。

Box by ASCII 对这一区别做了精妙描述："它使用沙箱的方式就像开发者使用笔记本电脑一样，因此沙箱必须表现得像一台笔记本电脑。"

代理会执行不可信的指令

决定运行哪个命令的程序是概率性的，它可以同时从多个来源读取指令，包括源文件、问题描述、网页、包元数据和 MCP 工具输出。其中一些输入是不可信的，恶意指令可能被植入 README 或工具描述中，从而有意引导代理。代理生成的代码也可能错误或具有敌意。

我们已经看到过因误解任务而删除生产数据库的代理实例。一旦代理在 YOLO 模式下无监督运行，就再也没有权限提示可以阻止它。具有如此高权限和低可预测性的任务需要专为其设计的边界。

将这些事实综合起来，你就理解了我们为何要构建 Docker 沠箱。自主编码代理需要机器级别的能力，但又不能访问开发者机器上的所有内容，这归结为四个关键要素：

• 隔离：模型无法修改的边界
• 控制：对代理行为的可观测性以及停止它的能力
• 选择：在不重建配置的情况下更换代理、模型和工具的自由
• 容量：其他开发者可以复现并扩展到多台机器的配置

下一节将展示这些要素的具体实现，首先从隔离开始。

隔离机制：容器与 Docker 沙箱的隔离差异

简而言之，容器的边界是它所共享的宿主机内核，而 Docker 沙箱则通过虚拟化管理程序为代理节点提供独立的内核。这一关键差异决定了攻击者能渗透的范围，也解答了代理节点如何访问 Docker 的这个令人困惑的问题。

这正是容器与隔离机制分道扬镳的地方。容器可以作为隔离机制的一部分，且通常应该如此，但完整的隔离机制需要覆盖代理节点所处的整个环境。它始于模型无法修改的边界，这也是 Docker 为自主代理节点使用独立内核的微虚拟机（microVM）的原因。

共享内核 vs 独占内核

容器的边界由其共享的内核强制实施，因此突破该边界需要内核漏洞或侧信道攻击。这些情况并不常见。但一旦突破该边界，攻击者将获得对整个宿主机内核、机器上所有其他进程以及挂载的凭证的访问权限。

ⓘ 此场景特指 Linux 环境。在 Docker Desktop（macOS 和 Windows）中，共享的内核是 Docker Desktop 虚拟机的内核，而非宿主机内核，因此攻击者突破后将进入该虚拟机而非操作系统。

Docker 沙箱通过虚拟化管理程序为代理节点提供独立的内核。如果代理节点突破其容器，它将进入一个一次性使用的微虚拟机，宿主机则完全不受影响。你可以删除沙箱并重新创建新的实例。每个代理节点都拥有独立的微虚拟机，因此同一台机器上运行的两个代理节点也无法访问彼此的沙箱。不过，代理节点仍然可以访问你主动共享给它的资源，包括工作区、允许访问的网络目标、MCP 服务器和技能模块。

Docker 套接字问题

将 /var/run/docker.sock 挂载到容器中是长期以来赋予容器 Docker 访问权限的标准方式，这种做法常见于 Compose 配置、CI 流水线和可观测性工具中。但这也让容器获得了对宿主机 Docker 守护进程的控制权，而 Docker 通常只允许受信任用户使用该功能，因为容器可以挂载宿主机路径并启动特权容器。

代理节点无需利用漏洞即可使用该功能。只要将包含该套接字的容器启动，代理节点就会探测周围环境，识别出自己处于容器中，并发现配置中的漏洞。在 Mark 的主题演讲演示中，仅凭这一点就足以让代理节点在不依赖零日漏洞的情况下访问宿主机上的密钥文件。

套接字只是多个漏洞之一，代理节点会发现这些漏洞，因为环境探测是其工作的一部分。Docker-in-Docker、挂载的凭证和广泛的宿主机挂载路径都是其他常见漏洞。容器的设计初衷是隔离按配置运行的应用程序。但代理节点会持续测试该配置，因此如果存在漏洞，它很可能率先发现。

假设你让运行在 Docker 沙箱中的代理查找主机上的 secrets 文件。它会找到 Docker 套接字，尝试用它挂载主机路径并启动特权容器，但无法访问主机本身。与容器相比，微虚拟机可以为代理提供更强的信任边界。Docker 沙箱背后的技术架构进一步解释了为什么微虚拟机是这种场景的更优选择。

控制：内核之外你能看到并阻止的内容

隔离划定边界，而控制决定了边界内部你能看到并阻止的内容：代理被允许访问的范围，以及当它试图访问不应访问的区域时阻止它的能力。在沙箱中，这些控制由主机执行，超出代理的控制范围，因此代理无法关闭或绕过这些规则。出站流量、凭证和组织级策略均采用这种方式运作。控制还意味着了解代理仍能访问的内容，因为微虚拟机无法隐藏你选择与它共享的内容。

标准容器中的代理

Docker 沙箱中的代理

内核

共享主机内核

在微虚拟机中运行自己的 Linux 内核

Docker

需要主机套接字或嵌套守护进程

在微虚拟机内部使用私有 Docker 引擎

工作区

能看到你挂载的主机路径

使用直接读写挂载或虚拟机内私有克隆

网络

使用容器网络和操作员提供的控制策略

通过具有默认拒绝策略的主机代理发送出站流量

凭证

通常接收环境变量、文件或挂载的套接字

对支持的 HTTP 服务使用主机侧凭证注入

状态

通常从镜像和明确卷重新构建

保留软件包、镜像、容器和代理历史记录直到执行 sbx rm

编排

兼容 Compose、Kubernetes 和大多数 CI 系统

使用 sbx 生命周期和实验性环境文件

主机强制执行控制规则

这些控制规则之所以有效，是因为它们在代理进程之外运行。代理能够访问的规则意味着它可能找到绕过方法，因此真正重要的规则存储在主机上。出站流量通过具有默认拒绝策略的主机代理，这意味着代理想要访问的目标会保持被阻止状态，直到有人将其添加到允许列表。凭证遵循相同的逻辑。对于支持的 HTTP 服务，代理会将凭证注入出站请求，因此代理可以使用凭证而无需原始凭证值进入虚拟机。

当某个开发者的配置需要转变为团队标准时，Docker AI 治理可以将网络、文件系统和 MCP 策略迁移至组织级控制。

代理仍能访问的内容

微虚拟机无法隐藏你选择与它共享的内容，因此共享部分需要特别关注。

工作区是其中最大的部分。默认以读写方式挂载，因此代理可以编辑或删除项目中的文件。克隆模式为代理提供一个私有的虚拟机内克隆工作区，这保护了主机的工作树，但原始仓库在沙箱内仍保持可读性。

MCP 服务器和技能也共享。主机上运行着本地 stdio MCP 服务器，共享代理技能使用主机侧存储，因此代理的访问范围扩展至这两者。

因此无论选择哪种模式，在运行修改后的代码前，请务必查看差异内容。

Docker 沠箱可能需要一些配置和受支持的虚拟机管理程序。但工具包和环境文件已经涵盖了这些配置，它们也是你选择代理、工具以及在团队中复现环境的所在。

工具包和环境文件

工具包通过封装工具、文件、命令、网络规则、凭证和代理指令，使环境配置可重复。它们为不同的代理、工具和 IDE 发布，因此你可以在不重建外围环境的情况下，切换沙箱内部的运行内容。一个 sbxenv.yaml 文件记录了一个项目的沙箱配置，将其提交到代码仓库后，团队成员可以通过一条命令重新创建相同的沙箱，使每位开发者都能从相同的环境出发。（工具包目前处于早期访问阶段，环境文件属于实验性功能，因此需要为两者的变化做好准备。）

主机强制控制也需要一些设置。网络策略需要有人决定哪些目标属于工作流，凭证中介会添加服务绑定和批准的域名，克隆模式则在更改提交到主机仓库前添加了一个获取步骤。

虚拟机管理程序和资源需求

运行沙箱对机器的消耗比运行容器更大。它需要受支持的虚拟机管理程序，目前这意味着 macOS 14 或更高版本上的 Apple 芯片、Windows 虚拟机管理程序平台，或受支持的 Ubuntu 系统上的 KVM，且在另一个虚拟机中运行需要嵌套虚拟化。独立的内核和 Docker 引擎也会消耗比额外容器更多的内存和磁盘空间。

如果机器性能是限制因素，Docker Cloud 沠箱会在 Docker 管理的计算资源上运行相同的微虚拟机隔离，一条命令即可将沙箱在你的笔记本电脑和云端之间迁移。本地和云端沙箱会分别保存独立的凭证和网络策略。

如何在容器和 Docker 沚箱之间做出选择？

当你可以控制代码及其依赖项时选择容器，当工作负载在运行时生成或获取代码且需要独立边界时选择 Docker 沚箱。

选择容器时

选择 Docker 沚箱时

你可以控制代码及其依赖项

工作负载在运行时生成或获取代码

执行是短暂的且从镜像重新构建

会话持续数小时并累积状态

工作负载不需要 Docker，或已在提供 Docker 的 CI 中运行

工作负载需要自己的 Docker 引擎且无法访问主机套接字

你希望达到最大密度并兼容 Compose 或 Kubernetes

你需要主机强制实施的网络和凭证策略，且工作负载无法关闭

内核边界对运行的代码已足够

你希望在工作负载和内核之间有一个虚拟机管理程序

如果以下任何信号适用于你的项目，你应该从 Docker 沚箱开始。

• 代理无人值守运行，或其权限提示已自动批准
• 代理需要构建镜像或运行 Compose 或 Testcontainers
• 代理读取了你未编写的输入，例如问题、网页、包元数据或 MCP 输出
• 代理需要你不想放入其环境中的 API 密钥
• 会话持续时间超过单个任务

从 sbx run claude . 开始。随着工作流的发展，逐步添加克隆模式、工具包、网络策略、凭证中介和组织治理。

沚箱代理，容器化应用

容器技术不会消失。对于服务、CI任务以及任何需要打包部署的内容，它们划定了正确的边界，而围绕它们的生态系统正是它们持续执行这些工作的原因。一个编码代理若要被委派真实任务，仅依赖容器是不够的。它需要的是“隔离”——一个模型无法篡改的边界、一个代理无法绕过的控制机制，以及选择工具和扩展配置的自由。

Docker沙箱通过微虚拟机（microVM）提供了这种隔离能力，同时仍能运行你的容器。这种边界也让代理能够更高效地工作。一旦边界建立，你就可以停止逐条审批命令，让代理直接开始工作。

只需一条命令即可启动沙箱。从 sbx run claude 和 Docker沙箱快速入门指南开始。当某个开发者的配置需要成为团队标准时，Docker AI治理功能可以将相同的控制机制扩展到整个组织。

常见问题

Docker沙箱只是容器吗？

不是。容器是共享宿主机内核的隔离进程。Docker沙箱是拥有独立内核、文件系统、网络和Docker引擎的微虚拟机。沙箱可以运行容器，这也是两者容易混淆的原因。

我可以在Docker沙箱中运行Docker吗？

可以。每个沙箱都包含私有的Docker引擎，因此代理可以构建镜像、运行Testcontainers并启动Compose应用，而无需使用宿主机套接字或Docker-in-Docker方案。

Docker沙箱会取代容器吗？

不会。容器仍然是打包应用、CI任务和短时执行的正确工具。沙箱为自主代理提供了更强的边界控制，而容器仍会在沙箱内部正常运行。

容器与隔离（containment）的区别是什么？

容器隔离的是工作负载本身。而隔离（containment）涉及代理所处的整个环境：它运行的边界、可访问的范围、使用的工具，以及如何复现这些配置。容器可以是隔离的一部分，而Docker沙箱则为自主代理添加了必要的微虚拟机边界。

AI代理需要从环境获得什么？

Docker定义了四个要求：隔离（模型无法篡改的边界）、控制（对代理行为的可见性及终止能力）、选择（无需重建即可切换模型、代理和工具）和容量（其他开发者可复现并扩展到多台机器的配置）。

运行Docker沙箱需要什么？

需要支持的虚拟化平台，包括：macOS 14或更高版本的Apple芯片、Windows虚拟化平台，或支持的Ubuntu系统上的KVM。在另一个虚拟机中运行需要嵌套虚拟化支持。

作者简介

Docker AI业务线首席产品市场经理 Srini Sekaran 是Docker的AI首席产品市场经理，专注于Docker AI治理、Docker沙箱以及代理基础设施和开发者工作流的未来方向。

Docker社区成功经理 Agentic AI Cloud沙箱 概念 容器 Docker沙箱 安全

产品 目录

相关文章

• 2026年9月24日 制造AI代理的信任 | Docker WeAreDevelopers主题演讲

Docker WeAreDevelopers主题演讲展示了沙箱、工具包和云沙箱如何为AI代理提供强大的隔离和可复现的权限。Deanna Sparks 阅读全文

• 2026年11月5日 Docker 沙箱与容器：为AI代理选择合适的隔离方案 容器共享主机内核。Docker 沙箱是带有独立内核和私有 Docker Engine 的微型虚拟机。了解它们的差异以及何时使用各自方案。Srini Sekaran 和 Oleg Selajev 立即阅读

• 2026年11月5日 Docker 与 ActiveState 将安全默认值扩展至开发者安装的软件包 Docker 与 ActiveState 合作，持续为你们团队构建的所有内容提供统一的可信内容标准。Vishrut Iyengar 立即阅读

• 2026年11月5日 CNCF Score 项目通过加入 Docker 赞助的开源计划提升安全态势 了解 CNCF Score 如何通过 Docker Scout、强化镜像和 Docker 赞助的开源计划提升容器安全性。Mathieu Benoit 立即阅读