Kits 本来就有，新的是「它成了一个标准工件」

Docker 在 9 月 24 日的官方博客里把问题说得很直白：容器的普及靠的是一个可移植的镜像格式加一个中立治理，现在 agent 面临的是同一个问题——没有共享格式来描述「一个 agent 被允许做什么」。他们给的办法是沿用同一套答案：做一个基于 OCI 的工件，放在开放治理下。

一个 Kit 里装三样东西

  • agent 本身；
  • 它的工具；
  • 一份带类型的访问申请清单——比如主机、凭据、卷。

关键在第三项也在镜像里：这意味着 pin 住镜像就等于同时 pin 住了 agent 和它要求的权限，两者不会漂移。规范以 Apache 2.0 开源，与此同时 Docker 宣布把这份规范交给 CNCF，走与当年镜像格式进入 OCI 相同的中立治理路径。

落地成本为什么可能是零

因为 Kit 就是一张 OCI 镜像，现成的 registry、扫描器和签名工具不需要任何改动就能处理它——官方原话是「不需要新部署任何东西」。对已经在跑容器供应链的团队，这是这套方案最实在的地方：新增的是表达方式，不是基础设施。

和当下的痛点对得上

过去一年 agent 出错的方式，很多不是模型答错，而是它访问了不该访问的东西：能读到不该读的凭据、能连到不该连的主机。这类问题在部署脚本与运行时配置里是散落的、不可扫描的。把权限清单变成镜像的一部分之后，它能被 code review、被策略校验、被扫描器读——这正是「agent 能不能上生产」最常卡住的一关。

现在就能做的两件事

  1. 给自己在跑的 agent 补一份显式访问清单（主机 / 凭据 / 卷），哪怕先不套规范，也让它能在 review 里被看见；
  2. 如果规范里表达不出你的场景、或某个运行时实现不了某条规则，去 docker/sandbox-kit-spec 提 issue——标准早期的可塑性最高。
让 agent 的权限像镜像一样可以按摘要固定，比让它「更听话」更容易落地。