AI编程代理失控正成为开发者的普遍困扰：模型在执行重构任务时，常越权访问凭证或删除受限文件。针对这一痛点，Docker在强化本地隔离机制的基础上，进一步扩展至云端，正式推出“云沙箱”（Cloud Sandboxes）。
云端隔离与弹性算力
云沙箱将原本运行于本地的微虚拟机（MicroVM）隔离技术迁移至Docker管理的云端实例。开发者只需一条命令，即可将工作负载从本地无缝迁移至远程。即便本地设备关闭，代理仍可在云端持续运行，且安全边界保持一致。
该方案旨在解决长时任务的管理难题。AI代理的运行时长已从几分钟延长至数小时，部分任务甚至超过20小时，单靠人工监控十几个并行进程并不现实。云沙箱提供弹性算力，会话最长支持24小时，足以覆盖大多数自主工作流。定价方面，最小实例费用为每小时7美分，并随资源需求线性扩展。
Kits：标准化的权限声明
硬件隔离仅解决了部分信任问题，Docker的核心创新在于定义了代理的访问边界，即“Kits”概念。Kits是标准的OCI镜像，内含三个关键要素：代理程序、所需工具集，以及一份类型化的权限列表（明确指定可访问的主机、凭证和数据卷）。一旦镜像锁定，权限随之固定。
Docker已将Kits规范以Apache 2.0许可证提交至云原生计算基金会（CNCF）。这一开放标准旨在实现授权的可移植性，任何兼容运行时均可解析同一Kit。Docker沙箱目前是首个强制执行该标准的平台。
Docker规范作者Christian Dupuis指出，沙箱仅提供隔离环境，而Kit则声明了“谁在运行、拥有什么权限、能接触什么”。这种机制将权限定义嵌入镜像，随注册表流转，确保团队共享时的安全一致性。
五层隔离与零信任架构
相较于共享内核的传统容器，微虚拟机提供了更严格的硬件级隔离：独立内核、无共享内存，VM内进程对主机不可见。Docker文档披露了其五层隔离机制：Hypervisor、网络、私有Docker引擎、工作区控制及凭证代理。
其中，凭证代理机制尤为关键：密钥永不进入VM内部。主机按需注入密钥，代理无法获取实际令牌，从而从根本上杜绝了提示注入窃取凭证的风险。网络策略同样采用白名单机制，沙箱间禁止直接通信，开发者可选择开放、平衡或严格锁定等预设配置，亦可自定义规则。
生态集成与行业影响
目前，云沙箱已支持Claude Code、Codex、Copilot、Antigravity、Open Code和Hermes等主流AI代理，并提供对应Kits。命令行工具保持简洁，sbx --cloud run codex即可启动云端实例，sbx move可实现本地与云端会话的双向迁移，完整保留安装包、构建镜像及工作状态。
生态合作同步推进：BAND将其多代理协作层与Docker沙箱集成，确保代理在隔离执行的同时通过“房间”机制与团队沟通；Chainloop则增加证明功能，允许组织在合并代码前验证代理构建内容。
尽管面临长期运行成本累积及24小时会话限制等挑战，且Kits规范的广泛采纳仍需时间，但Docker此举方向明确。正如十年前容器技术通过OCI标准实现软件可移植性，Docker正试图为AI代理建立类似的权限与隔离标准。通过赋予代理自由同时机械化其边界，Docker为开发者提供了清晰的护栏，大幅降低数据泄露与误操作风险，让AI代理在生产环境中的无人值守运行成为可能。