用 AI 接活最怕 Agent 乱删文件乱刷 API。Docker 刚把 v3 规范提交给 CNCF，直接把权限打包成 1 个标准 OCI 镜像。
核心看点
- 权限与代码一起打包，告别手动配环境
- 声明类型化能力，拒绝 API 额度被乱刷
- 目前仅 Docker Sandboxes 运行时支持，跨平台还得等
你接自动化排版或批量生图的活，给 AI 开权限就像给实习生开公司后台。以前是“全给”，现在是“按需分配”。这能帮你避免客户数据泄露或 API 账单爆炸。它把推理和执行的边界划清楚了，你下半年用 agent 跑长任务，等待感和风险都会明显变短。
▎把权限塞进标准镜像
以前跑 Claude Code 或 Codex，权限都在 shell 历史或仪表盘里。现在 v3 规范里，Kit 不再是独立类型，manifest 声明 vnd.docker.sandbox.kit.descriptor。你可以用 docker buildx build 直接打包。这相当于给 AI 配了一套标准的工作服，走到哪都能穿。
声明是类型化和版本化的能力，比如 com.docker.sandbox/network-policy@2 和 com.docker.sandbox/credential@1。Docker 联合 AWS、Box、Datadog 等 9 家大厂搞这个，就是为了解决碎片化。每个运行时不再自己发明轮子，而是统一用这套标准。
▎权限控制细到文件级
拿 GitHub CLI 例子来说，规范允许访问 api.github.com，但直接拒绝 DELETE 于 /repos/**，拒绝优先级最高。凭证可以代理管理，沙箱里只存一个哨兵值，真 token 由运行时注入。
启动时结合一个 workload Kit 和多个 mixin overlays。Mixins 按 provides/requires 依赖图排序，而不是 flag 顺序。如果依赖没满足，或者两个 Kit 提供了同名内容，直接报错拒绝启动。网络规则可以合并，不兼容的直接算错。
▎实操部署与避坑
项目托管在 docker/sandbox-kit-spec 仓库。你可以用 sbx CLI 测试，比如跑 sbx run ./hello --kit ./gh。现有的注册表和扫描工具不用改就能处理 Kits。但注意，描述符语法和每个能力的语义是新的，需要花时间学。
官方博文：
Claude Code：
Codex：
规范详情：
▎接单决策与选型框架
对于想靠 AI 接单的设计师，这套规范决定了你能接多大的活。如果你只接单张海报生成，用普通 API 就够了。但如果你接的是企业级自动化工作流，比如让 AI 自动抓取素材、调用内部 API 生成并上传，权限管理就是生死线。用 Docker 这套规范，你可以把“只读素材库”和“可写发布目录”严格分开。选不选它，取决于你的客户是否要求数据隔离和审计日志。
▎适用边界与失败条件
别以为打包了 OCI 镜像就能到处跑。这里的失败条件非常明确：没有兼容运行时，注解就是 inert（无效的）。如果你习惯用 Compose 或者普通的 Docker Engine 跑任务，这套 v3 规范根本不会生效。它必须依赖像 Docker Sandboxes 这样带独立内核的 microVMs 环境。这意味着你的宿主机需要支持硬件虚拟化，且会吃掉额外的内存和 CPU 资源。在给客户报价时，必须把这部分硬件损耗算进成本里。
▎落地排查清单
落地时怎么排查问题？第一步，检查 manifest 里有没有 vnd.docker.sandbox.kit.descriptor 声明，漏了就等于没打包权限。第二步，看 requires 字段，如果上游 mixin 没提供对应的 provides，启动会直接 fail。第三步，核对网络策略，deny 规则永远优先于 allow，别指望用 allow 去覆盖 deny。第四步，确认你的运行时版本是否支持 v3 的 descriptor 语法，老版本会直接忽略。
讲真，这规范看着美好，落地还得看运行时。原文明确指出，执行完全依赖运行时，目前只有 Docker Sandboxes 是唯一的兼容实现。如果你用其他容器工具，这些权限注解就是摆设。接活时别盲目跟风，先确认你的部署环境支不支持这种微虚拟机隔离。跨运行时的可移植性目前还没被证明，别在交付节点给自己挖坑。
点个赞再走？
你接活时给 AI 工具开过最高权限吗？踩过什么坑？
往期推荐
- ·图灵奖得主对AI末日零担忧，60人新公司押注物理世界
- ·算力消耗直降 30%，Google 新方案让 Agent 不背题
- ·Meta 高管称用户自愿授权，安全专家打脸 AI 代理隐私
点击公众号头像 → 历史消息，可翻阅以上文章
