本地跑 AI 任务最怕笔记本合盖休眠。Docker 刚发的 Cloud Sandboxes 让你一条命令把任务扔到云端，连跑 21 小时不用盯。
- 本地与云端一键切换：用 sbx move 命令就能把本地微虚拟机环境平移到云端，进度不丢。
- 并行处理长任务：支持同时跑十几个独立沙盒，每个跑 5 到 21 小时，适合批量渲染或生图。
- 安全与隔离争议：底层是硬件级 microVM 隔离，但连接外部服务时仍存在潜在攻击面。
这工具对咱们接大单太实用了。以前接个几十小时的批量渲染或视频生成，人根本不敢离开电脑。现在把环境打包扔到云端，你该睡觉睡觉，该接新单接新单，生产力直接翻倍。
本地跑一半，云端接着干
Docker 这次把早期的本地 Docker Sandboxes 升级了，底层用的是硬件强制的 microVM 隔离。最核心的是那个统一 CLI 工作流。你在本地笔记本上起个任务，跑到一半觉得本地算力不够或者要出门，直接敲一行命令：$ sbx move my-project --to cloud。它会把沙盒的文件系统直接抓过去，在云端原样重建。你的工作进度一点不丢。
对于咱们视觉工作者，这功能特别适合两种场景。第一种是“算力不够云来凑”，本地显卡跑个复杂的 ComfyUI 工作流，显存快爆了，直接切到云端的高配机器上继续。第二种是“时间换空间”，接了个需要跑 21 小时的批量素材生成大单，本地电脑还得干别的活，直接扔云端后台跑。但要注意，这要求你的任务状态必须能完全保存在文件系统里，如果是纯内存态的长连接服务，切换时可能会断。
Kits v3 规范与并行能力
除了环境切换，Docker 还更新了 Docker Sandbox Kit Specification。在最新的 Kits v3 规范里，Kits 不再是单独的产物，而是直接打包成标准的 OCI 镜像。你可以像用普通 Docker 镜像一样去 build 和 pull，甚至拿它当基础镜像去搭更复杂的沙盒环境。
如果你打算用这套工作流接活，建议先做这三步测试。第一步，先用短任务跑通 move 命令，确认你的项目依赖在云端环境里没报错。第二步，测试断网和休眠恢复，看看本地状态同步是否真的无缝。第三步，尝试并行起 3 个以上的沙盒，观察云端资源的计费情况和调度延迟。别一上来就扔个 21 小时的大单，万一环境配置有坑，沉没成本太高。
官方入门指南：
Kits v3 规范仓库：
InfoQ 底层技术解析：
官方资源与社区避坑指南
别觉得上了沙盒就万事大吉。Reddit 用户 CircumspectCapybara 就泼了盆冷水。他指出，沙盒只解决了执行环境的隔离，但真正有用的 AI 任务必须连外部服务，比如去 PyPI 拉库，去 Hugging Face 下模型。这些外部连接依然是潜在的攻击面。代理在沙盒里照样能通过窄权限的外部接口把服务搞崩。Hacker News 的 ongedierte 也同意这观点，认为传统沙盒不是终极答案，未来得靠基于对象能力的细粒度访问控制。
这对咱们接活的启示是，沙盒防的是乱搞系统文件，防不住合法调用外部接口。如果你在云端跑的任务需要频繁调用第三方 API 或者下载外部资产，一定要在沙盒配置里把网络权限卡死，只放行你需要的白名单域名。别为了图省事给全开权限，不然云端机器被当成肉鸡，你的客户数据就全漏了。
Docker 这次推 Cloud Sandboxes，实际作用是让 AI 编码代理的运行环境从单机玩具变成了工业流水线。你不再被绑死在一台高配电脑上，笔记本可以是轻薄的，重活全扔云端。但技术红利永远伴随着新坑。环境切换的无缝感，掩盖了网络权限管理的复杂性。下次接长周期大单时，先把网络隔离策略摸透，再谈生产力解放。
看完想聊两句？
你跑批量生图或渲染时遇到过电脑断电休眠导致前功尽弃吗？说说你的血泪史。
往期推荐
- ·67%调用份额，全球开发者正悄悄把 API 换成中国模型
- ·12万张论文图像入库，OpenAI复古设计告别塑料味
- ·15国客户实测，1人团队干几百人的活？
点击公众号头像 → 历史消息，可翻阅以上文章
