Docker Cloud Sandboxes：把 AI 编码智能体的沙箱从笔记本延伸到云端
Docker 发布 Cloud Sandboxes，为 AI 编码智能体提供托管执行环境，与本地版共用同一套 microVM 隔离模型和同一套 CLI，一条命令即可把沙箱连同文件系统搬到另一端。配套的 Kits 规范升级到 v3，沙箱模板改为标准 OCI 镜像。社区则提醒：沙箱只解决了隔离问题的一半，智能体对外部服务的必要访问仍是攻击面。
为什么要把沙箱搬到云端
Docker Cloud Sandboxes 为在 Docker 管理的基础设施上运行 AI 编码智能体提供托管执行环境。底层使用硬件强制隔离的 microVM：每个沙箱跑在独立的小型虚拟机里，借助 CPU 虚拟化能力做隔离，比普通容器更难越界。
它是此前 Docker Sandboxes 的演进版本。早先的版本只做本地 microVM 环境，让编码智能体自主、安全地运行。但 Docker 观察到，开发者现在越来越多地并行运行多个长周期任务，本地机器的限制开始成为瓶颈。Docker 的表述是：智能体只做短时突发工作时，人们关心模型能否连贯地把任务做下去；当任务持续数小时，问题就变成「这些工作到底在哪里发生」。笔记本是围绕人设计的——合上盖子就休眠，用电池会降速，人一移动就断网。
一致的抽象：同一隔离模型、同一套 CLI
Cloud Sandboxes 沿用本地版的隔离模型，也通过相同的 CLI 管理。开发者可以在本地启动任务，需要更多资源时迁到云端；也可以在下班前把任务移交给云端继续跑。按 Docker 的说法，这样可以同时运行十几个智能体，每个跑 5 小时、10 小时甚至 21 小时，无需人工监视。另一个典型场景是把数十个任务并行化，各自跑在独立的云端沙箱里。
在本地机器与 Docker 基础设施之间迁移只需一条命令，两个方向都支持。该命令会捕获沙箱的文件系统，并在另一端重新创建，因此工作成果会跟着一起过去。
对开发者来说，这意味着不必为「本地跑」和「云端跑」维护两套流程，智能体工作流可以像容器一样被整体搬迁。对于氛围编程这类强调快速试错、让智能体长时间自主改代码的用法，持久化、可扩展的执行环境比一台笔记本更实际。
Kits v3：沙箱模板变成标准 OCI 镜像
除 Cloud Sandboxes 外，Docker 还发布了多个 Kits，即按照 Docker Sandbox Kit Specification 定义的预配置、预构建沙箱。最新的 v3 规范带来一个关键变化：Kits 不再作为单独的构件存在，而是打包成标准 OCI 镜像（也就是 Docker 镜像的通用格式）。因此它们能像普通镜像一样使用 build、pull 等命令，也可以作为基础去构建更复杂的 Kit。
社区反馈：隔离之外还有对外通信的风险
德意志银行首席 DevOps 工程师 Florin Lungu 评论认为，在 microVM 中安全、自主地编码增强了工作流的灵活性，这一点很有意思。
但 Reddit 用户 CircumspectCapybara 指出，沙箱化只解决了部分问题：任何真正有用的智能体任务，都必须让沙箱里的智能体连接有限的外部服务，以访问它在现实中会调用的工具、真实依赖库或构建产物，以及它可能从 PyPI、Docker Hub、Hugging Face 拉取的内容。即便智能体被限制在沙箱内部，这些连接依然构成潜在攻击面：它可以只与被授权的少数服务通信，同时借这条通道去破坏这些服务。
Hacker News 读者 ongedierte 表达了类似担忧，认为传统沙箱不是正确的抽象层；基于对象能力（object capabilities，一种「持有凭证才能访问特定资源」的权限模型）构建约束机制，并精确限定智能体以何种方式访问哪些资源，才是未来的方向。
关键要点
- Docker Cloud Sandboxes 把本地 AI 编码智能体沙箱扩展到云端，隔离模型和 CLI 与本地版保持一致，一条命令即可迁移文件系统与工作成果。
- 核心动机是长周期、多并行的智能体任务不适合笔记本：休眠、降速、断网都会中断工作。
- Kits v3 把沙箱定义打包为标准 OCI 镜像，可 build、可 pull，也能作为其他 Kit 的基础。
- 社区提醒：沙箱内的隔离不等于整体安全，智能体对外部服务的必要访问仍是攻击面，对象能力模型被认为是更细粒度的解决方向。