2026 年 9 月 24 日，Docker 发布 Sandbox Kit 规范第三版（Spec v3），把「如何把一个智能体连同它的工具与权限声明，打包成一个可移植、可审计的单元」这件事，推进到一个更具体的工程形态。核心思路是用 Open Container Initiative（OCI）镜像作为载体：智能体本身、它可调用的工具、以及它被授予的权限声明，都被写进同一份镜像里，并通过一个标准的 OCI 注解 vnd.docker.sandbox.kit.descriptor 来标注这份镜像是一份「沙箱套件」描述。
把「智能体 + 工具 + 权限」打成一个镜像
过去，把一个会调用外部工具的智能体交付出去，往往意味着散落各处的配置：代码在一个仓库、工具凭据在另一个密钥库、权限边界又写在运行时的环境变量里。Sandbox Kit v3 的取向是把这些拼到一起：镜像内的描述符声明了智能体能做什么、不能做什么，运行环境据此在启动时就拉起对应的隔离边界。对一个要被多家团队复用的智能体来说，这种「自带权限说明书」的打包方式，降低了误配与越权的概率。
注解 vnd.docker.sandbox.kit.descriptor 是这套设计的支点。它把沙箱的描述从「运行时的隐式约定」变成「镜像里的显式字段」，任何兼容的运行时都能读取并据此建立隔离。这意味着同一个智能体套件，可以在本地、在 CI、在云端以一致的方式被实例化，而不必为每套环境重写权限逻辑。对需要合规与可复现的工程团队，这种一致性比单点能力更关键。
为什么会走向开源与中立治理
Docker 同时表示，Sandbox Kit 以 Apache 2.0 许可发布，并有意向把规范捐赠给云原生计算基金会（CNCF）。这一步的用意很清楚：沙箱与权限是跨厂商的底层契约，若由单一公司把持，采用率会受信任顾虑拖累；放进中立基金会，能让模型厂、平台方与工具提供方在同一套语义下互操作。对一个以容器标准立身的公司而言，把智能体沙箱做成「新时代的容器规范」，是一条与其基因吻合的扩张路径。
与 Sandbox Kit 配套的还有 Cloud Sandboxes 方向：把上述隔离单元直接跑在托管环境里，开发者无需自建运行时即可获得一个受控的智能体执行面。这与近年「把智能体放进按需沙箱」的趋势一致——既隔离了宿主资源，也隔离了凭据与网络边界。对安全团队，云沙箱的价值在于把「智能体能碰什么」收敛到平台侧策略，而非散落在每个智能体的提示词里。
值得跟踪的边界
客观地说，规范发布不等于生态就绪。其一，OCI 注解只是描述手段，真正的隔离强度仍取决于运行时实现，不同厂商的沙箱在系统调用、网络与文件系统边界上可能差异很大；其二，把权限写进镜像会带来「镜像即策略」的运维新负担，版本漂移与签名校验需要配套；其三，CNCF 捐赠尚在意向阶段，落地节奏未定。对准备采纳的团队，更务实的起步是先用 Sandbox Kit 统一内部智能体的交付格式，再逐步把执行面迁到合规沙箱。对国内团队而言，Sandbox Kit 的出现也意味着智能体交付格式的竞争正在上移：谁能把「权限如何声明、隔离如何验证」定义清楚，谁就更可能成为工具方接入时的默认选择。这对中国云厂商同样有借鉴意义：容器生态的话语权，可能正从「镜像格式」延伸到「智能体沙箱格式」。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。