【摘要】
第一，Docker Cloud Sandboxes 的本质不是“又一个容器”，而是把“不可信的 Agent 代码必须隔离运行”从工程建议变成了默认产品形态。AI 编程 Agent（Claude Code、Codex 这类）要跑命令、装依赖、发网络，Docker 用 microVM 给它一个“真实但隔离”的环境：能干活，碰不到宿主机。
第二，“按需运行”和前面分析过的 Solid“给 Agent 配独立电脑与预算”是同一思路：不为 Agent 常驻一台全功能机器，而是用时起一个沙箱、用完即焚。隔离优先，同时也是攻击面与成本优先——沙箱寿命越短，可被利用的窗口越小。
第三，要分清沙箱管得了什么、管不了什么。microVM 硬件级隔离解决的是“执行面”风险：防 Agent 逃逸到宿主机、防横向移动到内网。但它管不了“决策面”风险——Agent 在沙箱里合法地删文件、发邮件、调 API，隔离拦不住。这正是和前面写过的 Koreshield（行动前检查隐藏指令）互补的地方：Docker 管“在哪跑”，Koreshield 管“跑之前查”。
第四，Docker 把 Sandboxes 做成 standalone、不依赖 Docker Desktop，且可本地或云端运行，说明隔离能力正在“下沉为基础设施层”。任何 Agent 框架都能接，会推动“隔离优先”从大厂实践变成默认门槛，而不是可选项。
一、先把事实摆正
下面按 Docker 官方页面与公开报道梳理可验证事实，未确认部分明确标注。
| 事项 | 时间/来源 | 已确认的关键事实 | 口径边界/待核实 |
|---|---|---|---|
| Docker Sandboxes 产品定位 | Docker 官方产品页与博客（2026 年 4–8 月陆续发布） | 面向 AI 编程 Agent 的隔离运行环境；Agent 可自主做长任务而不牺牲安全；可本地或云端运行；已集成进 Warp | “Cloud Sandboxes”这一具体命名与 9-25 的云端按需形态，以 Docker 官方 9-25 发布为准 |
| 隔离技术 | Docker 官方博客 | 采用 microVM（硬件级隔离），区别于共享内核的普通容器 | 具体底层（Firecracker/gVisor 等）以官方实现说明为准 |
| 独立可用 | Docker 官方博客（4 月） | Sandboxes 是 standalone，不需要 Docker Desktop；用边界（boundary）定义自主范围 | 边界的具体配置项以官方文档为准 |
| 安全控制 | 公开解读与官方文档 | 控制网络访问、挂载项目目录、转发端口、在宿主机侧保存 secret，避免把宿主机钥匙交给 Agent | secret/网络策略的默认值与可配置项以官方文档为准 |
| Agent 隔离趋势 | 行业报道 | 对标企业级 Agent 安全部署的“隔离优先”趋势，防越权与横向移动 | “隔离优先”为行业共识性表述，非 Docker 单一口径 |
二、沙箱到底隔离了什么
理解 Cloud Sandboxes，先要分清“容器”和“沙箱”在这波 Agent 浪潮里的差别。普通容器靠命名空间做隔离，但和宿主机共享内核——Agent 一旦被提示注入或幻觉指令利用，仍有逃逸到宿主、或借宿主网络横向移动的空间。Docker Sandboxes 用的是 microVM：每个 Agent 拿到一个轻量虚拟机，内核独立、边界由你定义，能跑命令、装依赖、连网络，但碰不到宿主机文件系统和进程。
这不是“限制 Agent”，而是给它一个可以放心犯错的边界。Agent 越能干（写文件、跑 Shell、调 API），执行面越危险；沙箱把执行面关进笼子，让“手”再快也伸不出笼外。Docker 官方把这种状态叫“YOLO 模式也安全”——Agent 可以全自主，但边界是你画的。
但边界画在哪，决定安全上限。若沙箱挂载了整个 home、开了 docker.sock、放行了全部出站，隔离就名存实亡。所以“沙箱”不是开关，而是一组配置：挂哪些目录、放哪些端口、secret 留宿主机还是进沙箱、出站网络默认可否全开。
三、按需运行：隔离也是成本与攻击面管理
“按需运行”四个字，把隔离和前面分析过的 Solid 思路连起来了。Solid 给 Agent 分配独立电脑、账号、预算，本质是“给 Agent 一块专属资源”；Docker Cloud Sandboxes 更进一步——不养常驻机器，而是“提需求就起一个沙箱，干完即焚”。
这有两个实在好处。一是攻击面小：沙箱生命周期短，Agent 被攻陷后可利用的窗口也短，横向移动需要先突破 microVM 再找出口，难度陡增。二是成本清晰：按需计费、按需起停，比常驻一台全功能云主机便宜，也避免“Agent 工位”长期在线带来的泄露面。
对前面提到的“给 Agent 开预算、设熔断”是一个技术补充：预算管的是钱，沙箱管的是执行环境。两者叠起来，才是“既能放手让 Agent 干、又不让一次失控拖垮全局”的完整闭环。
四、隔离能管什么，管不了什么
这是最容易写歪的地方。Docker Sandboxes 解决的是“执行面”的越权与横向移动：Agent 跑在 microVM 里，拿不到宿主机权限，也借不到宿主网络去摸内网。这是真实且重要的进步。
但它解决不了“决策面”的问题。Agent 在沙箱里被允许删文件，它就会合法地删；被允许调某个 API，它就会合法地调。隔离保证“它只能在笼子里动作”，保证不了“它做的动作都对”。提示注入、幻觉指令、恶意检索文档，都能让一个被好好隔离的 Agent 干出坏事——只是坏事被关在笼子里。
所以“隔离优先”之外，还需要“检查优先”。前面写过的 Koreshield 是在模型行动前筛查客户消息、检索文档、建议工具里的隐藏指令与政策偏差，并对每个决策留痕。Docker 管“在哪跑”，Koreshield 管“跑之前查”；一个堵执行面，一个堵决策面。企业级 Agent 安全部署，大概率是“沙箱 + 审计”两层都要，而不是二选一。
五、能力对照与边界
| 维度 | Docker Cloud Sandboxes | 已披露边界 | 主要不确定性 |
|---|---|---|---|
| 隔离技术 | microVM 硬件级隔离 | 区别于共享内核普通容器 | 具体底层实现以官方为准 |
| 运行位置 | 本地或云端，standalone | 不依赖 Docker Desktop | 云端形态计费与配额以官方为准 |
| 安全控制 | 网络/目录/端口/secret 可控 | secret 留宿主机侧 | 默认值与可配置项以文档为准 |
| 防越权/横移 | 解决执行面越权与横移 | 不解决决策面误动作 | 需配合行动前检查（如 Koreshield） |
| 按需运行 | 用时起、用完即焚 | 缩短攻击面与窗口 | 生命周期与计费的精确策略以官方为准 |
判断时别被“沙箱”两个字安慰到。隔离强不代表万无一失：边界配置松了，沙箱形同虚设；决策面没查，笼子里也能闯祸。看一款 Agent 安全方案，至少问两句——它隔离到哪一层、它查不查行动前的指令。
六、图表：三类 Agent 运行环境的隔离强度
下图按公开技术描述，对 Agent 常见运行环境的隔离强度做定性示意。条长表示隔离程度，非精确测速。
Agent 运行环境隔离强度（定性示意）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本机直接运行 ███ 低（共享内核与宿主）
普通容器 ████████ 中（命名空间隔离，仍共享内核）
Docker Sandboxes ████████████████████ 高（microVM 硬件级隔离）图：三类 Agent 运行环境的隔离强度示意（依据 Docker 官方对 Sandboxes 采用 microVM 的描述；强度为定性对比，非基准测试数据）
从隔离强度看，microVM 沙箱显著高于“本机直跑”和“普通容器”。但强度只是下限，真实安全还取决于边界配置（挂什么目录、开什么网络）和决策面检查（是否审指令）。把“用了沙箱”当成“绝对安全”，是这类部署最常见的误判。
七、结论
Docker Cloud Sandboxes 把“不可信 Agent 代码必须隔离运行”从工程建议做成默认产品：microVM 给 Agent 一个真实但隔离的环境，按需起、用完焚，防的是执行面的越权与横向移动。它和 Solid 的“独立电脑/预算”、Koreshield 的“行动前检查”是同一股“隔离优先”潮流的三块拼图——一个管资源、一个管环境、一个管决策。
两句实话要写清。一是 Docker Sandboxes 产品官方语境早在 2026 年上半年就有博客与产品页，本次 9-25 焦点是云端按需形态，不宜写成“从零发布”；二是沙箱只堵执行面，堵不了决策面，企业级部署应是“沙箱 + 审计”两层，而非只上一个。把“用了沙箱”当成“安全到位”，会漏掉真正的高风险——那个在笼子里、但被错误指令驱动、合法干坏事的 Agent。