这周 Docker 圈被沙箱刷屏了。
8 月 13 日腾讯云开源 CubeSandbox，8 月 15 日阿里开源 OpenSandbox，当天冲上 GitHub Trending；几乎同一时间，Claude Code 把 Pro/Max/Team 用户的默认权限模式切成了"自动"——Agent 默认不再逐条请示，知乎上"为什么自动反而比手动安全"的问题吵了好几天。知乎
Agent 的权限越来越大，所有人都在找笼子。最正统的那个笼子其实是 Docker 自己出的：Docker Sandboxes，今年 2 月底发布，官方定位是"第四级沙箱"——比容器隔离强、比完整虚拟机轻，每个 Agent 单独跑在一台 microVM 里。知乎半年过去，sbx CLI 迭代到了 v0.38.0，知乎上张善友的 5 篇实测系列这周连更四篇，刚好收尾。
工作区怎么接（Direct 还是 Clone）、凭证隔离（API Key 全程不进虚拟机）这两块，我之前都拆过了。今天说这个系列里最让人后背发凉的一篇：隔离例外。
一句话版本：Docker 官方给沙箱划了五层隔离，但其中两扇门，是它自己开的。知乎
先看明面：五层隔离都是"默认关"的
官方口径划了五层：Hypervisor、网络、Docker Engine、workspace、凭证。
前三层不用多说：独立内核、独立出站网络、独立 Docker 守护进程——沙箱里 docker ps 看不到宿主机的容器，宿主机也看不到沙箱（它是 microVM，得用 sbx 命令查）。workspace 和凭证两层我拆过：Direct 模式工作区是读写直挂，选错接法会悄悄丢提交；sbx secret 存的 API Key 从不进 microVM，Agent 环境变量里看到的是 proxy-managed 这种占位符，真实请求由宿主机侧代理签好再转发。知乎知乎
如果故事到这里结束，Docker Sandboxes 就是个完美产品。但官方文档自己承认：还有两个接口，是设计上就要打通的，不算漏洞。知乎
例外一：共享 Skills，多个 Agent 共用一份能被互相改写的技能库
`sbx skills import` 会按顺序扫描宿主机五个目录：~/.agents/skills、~/.claude/skills、~/.copilot/skills、~/.cursor/skills、~/.factory/skills，把里面的 Skill 拷进一份持久化存储（Mac 上位于 ~/Library/Application Support/com.docker.sandboxes/sandboxes/agent-skills）。
关键在于它怎么挂。这份 store 是以读写方式挂进沙箱的——实测在 Claude 的沙箱里写一个文件，Codex 的沙箱立刻能读到，背后是同一份宿主机目录。
这意味着：你并行跑两个 Agent，其中一个"顺手"改了某个 Skill（或者被提示词诱导写进了别的东西），另一个 Agent 下次调用时直接吃下。沙箱之间的隔离墙没破，但技能库是一根总线。
更有意思的是，这扇门还不是对所有人开的。把 sbx 支持的 10 个 Agent 逐个起一遍沙箱核对挂载：只有 Claude、Codex、Copilot、Cursor、Droid 五个挂上了共享 Skills（各自挂在原生配置路径，不是统一目录）；opencode、gemini、kiro、shell 的挂载列表里没有任何 skills 条目。
这条"区别对待"的证据链值得展开。官方文档只枚举了五个，没写"不支持 OpenCode/Gemini"；官方 FAQ 说沙箱默认完全不导入宿主机的用户级 Agent 配置，只补了一句"Shared agent skills are the exception"——例外就这一个，但没说只对谁。
于是实测验证了三层：第一，OpenCode 官方文档写明它会扫描包括 ~/.agents/skills/ 在内的六个位置，Gemini CLI 更是把这个目录当作官方跨工具互通 alias——这俩本来有能力读共享技能，只是 Docker 没给接；第二，干净的 opencode 沙箱里，/home/agent/.agents 这个目录压根不存在；第三，直接 strings 本机 v0.38.0 二进制（Go 编译、未 strip），负责挂载的 SharedSkillsMountSpecs 符号相关的路径字符串只有那五条，.gemini/skills、.kiro/skills、.config/opencode/skills 一条都搜不到。
而同一份二进制里，agentkits 的 Load(“opencode”)、Load(“gemini”)、Load(“kiro”) 明明都在——Agent 本身是 sbx 认得的，沙箱照起，只是共享 Skills 这条例外没带上它们。知乎这是代码现状，不是文档遗漏，官方没解释原因。
还有一个藏得很深的细节：sbx create --help 里没有任何关闭共享 Skills 的参数，但二进制确实支持 --no-share-skills，五种受支持的 Agent 都能用。知乎一个没写进帮助文档的安全开关，不翻字符串根本发现不了。
例外二：本地 MCP，从设计起就跑在你的宿主机上
Docker 的 MCP Gateway 在宿主机侧，不在 microVM 里。
注册远程 HTTP 的 MCP endpoint 还只是出站网络的问题；但注册一个本地 stdio 类型的 MCP Server，它就是在你开发机上跑的真实进程。实测用了一个假 MCP 脚本——启动时只把自己的 pid、cwd、hostname 写进日志：sbx mcp load 报 502（假脚本不会回应 initialize 握手，失败在预期内），但日志已经落在宿主机上，hostname 是那台 Mac 的名字，不是 microVM 里的机器名。知乎进程真实地在宿主机上起来过。
所以这条边界是：如果你的本地 MCP Server 能操作文件、执行 Shell、动 Git、调云资源，Agent 调用它的那一刻，能力就已经绕过了 microVM。这不叫隔离被攻破——这条通路本来就是设计成宿主机侧的受信任集成，隔离边界覆盖不到它。
顺手补一个关联细节：sbx rm 删沙箱，VM 内部状态清空，但宿主机侧配置原地不动——sbx secret 存的凭证、注册过的 MCP Server、共享 Skills store，都不会跟着沙箱一起消失。清理要分别 sbx secret rm、sbx mcp rm。以为"删了沙箱就一干二净"，是另一种盲区。
把两个例外放一起看：隔离边界不能当整体看
Docker Sandboxes 的设计其实很诚实：五层默认关，挡住工作区之外几乎所有东西；但共享 Skills 和本地 MCP 这两扇门，是设计上主动开的。
前者让你多个 Agent 复用一份技能库，代价是技能库成为沙箱之间可写的共享资源；后者让 Agent 用上你宿主机已经在跑的能力，代价是这部分能力本质是以你本人的权限在执行。
一个能用的心智模型：沙箱不是保险柜，是权限栅栏加几扇刻意留的门。你获得多少隔离，取决于五层墙，也取决于你自己开了几扇门、把钥匙给了谁。
决策清单：门关不关，看场景
日常开发、人在旁边：默认配置就够了。共享 Skills 的便利大于风险，本地 MCP 调的也是你自己装的工具。
测安全边界、跑不信任的 Agent 或项目：sbx create 时带上 --no-share-skills，本地 MCP 一个都别接。记住这个参数不在帮助文档里。
无人值守跑：先把工作区接成 Clone 模式验证一遍（Direct 的安全边界依赖你在场，人不在边界就没了），再检查接过的本地 MCP 有没有删库、推生产这类高危权限。知乎
OpenCode、Gemini CLI、Kiro 用户：共享 Skills 这扇门对你根本不存在——不用担心沙箱间交叉污染，但也享受不到共享技能库；想要共享，目前只能自己把目录放进 ~/.agents/skills，等 Docker 哪天接上。
三个值得继续盯的信号
一是 sbx 本体闭源。docker/sbx-releases 仓库只有 LICENSE（Proprietary）、README 和 SECURITY.md，边界行为只能靠实测加二进制字符串确认。知乎一天不开源，这种"考古式验证"就得继续做下去。
二是系列作者留了个尾巴：Kimaki、omp 这类非官方 Agent 能不能接进这套体系？目前产品级支持只有官方那份 Agent 名单。
三是看这个月的时间线：腾讯 CubeSandbox、阿里 OpenSandbox、E2B、Kubernetes 社区的 AgentSandbox——Agent 沙箱正在从 Docker 一家变成多家入场。知乎对 Docker 用户来说，好处是竞争会逼着闭源的部分开口；要提醒的是，"沙箱"这个词目前没有统一标准，选任何一个之前，先想清楚自己要把什么放进去、把什么留在外面。
