过去一年编码 Agent 最明显的变化，不是「写得更好」，而是能连续工作的时间变长了。
以前一个任务几分钟到几十分钟，你得盯着；现在一次重构、一次依赖迁移、一轮跑满一小时的测试，可以整段交出去，几小时后再看结果。问题随之从「模型能不能把任务连贯做完」，变成了另一个更朴素的问题：这几小时应该发生在哪里？
笔记本是围绕人设计的：合盖就睡、用电池就降频、换个地方就断网。三十秒的任务无所谓，干一整晚的任务全都有所谓。
Docker 本周在 WeAreDevelopers 北美站的主题演讲里给出了它的答案。
事实梳理：Docker 发布 Cloud Sandboxes
先把事情本身说清楚。这次发布由 Docker 总裁 Mark Cavage 在台上宣布，围绕三块内容展开。
一、Cloud Sandboxes：把同一套沙箱搬到云上。
Docker 年初发布过 Docker Sandboxes，思路是给每个编码 Agent 一个独立 microVM——有自己独立的内核，也有自己的私有 Docker 引擎，和开发者的主机隔离。这次的新东西是：同一套 microVM 隔离模型，跑在 Docker 托管的算力上。
关键在这个命令：
sbx move my-project --to cloud它在本地和云之间双向搬运沙箱。要注意搬运的是文件系统，不是接管一个正在运行的进程——沙箱在目的地被重新创建，工作成果跟着过去。官方给的用法很直白：可以在本地和 Agent 迭代，然后把耗时的长任务交出去；也可以在下班前把任务扔上云，断开连接，第二天早上看结果；还可以一次并行跑一批任务，不用自己准备任何基础设施。
二、Kits v3：把「授权」打包成标准镜像。
这一块在我看来是整场发布里分量最重的，但很容易被「沙箱上云」的标题盖过去。
Kit 的定义是：把一个 Agent、它的工具、以及这个沙箱被允许访问什么，打包成一个带版本的、可分享的产物。最新一版的 Kits 规范里，它不再是一个独立的私有格式，而是打包成标准 OCI 镜像——也就是说可以像普通容器镜像一样 build 和 pull，也能作为基础继续构建更复杂的 Kit。
官方那句话说得挺到位：Dockerfile 让软件变得可复现，Kits 让「授权」变得可复现。Docker 同时承诺把这套 Kit 规范提交给 CNCF，走中立治理。
三、配套的治理与接入能力。
- MCP 网关：把 Agent 需要的 MCP 服务器接一次，本地、云、其他客户端都能通过同一个网关访问；也可以在单个沙箱里用
sbx mcp按需启用目录里的服务，凭据放在独立的密钥存储里。 - 密钥代理注入：密钥只存一次，由代理在每次请求时注入，Agent 全程看不到真值。官方的说法是「提示词注入碰不到 Agent 从来没有过的密钥」。
- 网络策略：能访问哪些端点，定义一次、处处生效。企业侧的 Docker AI Governance 提供网络、文件系统与 MCP 策略的集中管控。
- 现成可用的 Agent：Claude Code、Codex、Copilot、Cursor、Devin、OpenCode，以及 NanoClaw 这类自主系统；Nous Research 的 Hermes 作为一等 Kit 被搬上台演示。启动一条比如
sbx --cloud run codex。
几个必须一起交代的细节：
- 计费按秒：暂停的沙箱不计费。标准规格（2 vCPU / 4 GB）为 0.14 美元/小时，可选规格区间为 0.07 到 1.12 美元/小时。需要 sbx 0.45.1 以上版本和按量计费套餐。
- 运行时长：默认 1 小时，可设 1 到 24 小时；到期后可恢复的会被暂停，其余的删除。
- 本地和云并非完全一致：尽管隔离模型相同，但凭据与网络策略是分开管理的；云沙箱也访问不到本地主机路径与硬件。这一点官方没有回避。
- 模型请求用的还是你自己的密钥和供应商，Docker 不管模型这一层。
社区的另一半声音
这类基础设施发布，最有价值的信息往往在评论里。InfoQ 的报道引了两个值得转述的质疑：
第一，沙箱只解决了一半问题。有开发者指出，任何真正有用的 Agent 任务都需要连接有限的外部服务——真实的库、制品、要从 PyPI、Docker Hub、Hugging Face 拉的东西。这就产生了新的攻击面：Agent 可以老老实实待在沙箱里，然后通过它被允许访问的那一小撮服务去做事。换句话说，边界收紧并不等于风险归零。
第二，沙箱可能不是正确的抽象层。有观点认为，未来的方向是基于对象能力（object capabilities）的 harness——精确限定某个 Agent 能以什么方式访问什么，而不是给一个环境、再在外面围一圈策略。这个判断和站内 Agent 自己越界那篇 里「边界要按能力组合来审」是同一个思路。
影响分析：这件事真正的分量在哪
第一，「算力在哪」正式取代「模型行不行」，成了长时 Agent 的主要问题。过去半年关于长时任务的文章（比如站内 长时任务怎么设计）大多在讲任务拆解和状态恢复，默认算力是有的。这次发布把前提挑明了：算力不仅要够，还得在人走开之后依然在。这解释了两周前两朵云同时把 Agent 运行底座产品化（阿里云 AgentCore 与 Google AX）之后，为什么 Docker 也要挤进来——大方向是同一个：Agent 的运行环境正在从「开发者自己搭」变成「基础设施厂商直接提供」。
第二，真正被标准化的不是环境，是授权。这才是 Kits v3 的意义。以前「这个 Agent 能访问哪些文件、哪些网络、拿着哪些密钥」写在一份没人 review 的配置里；现在它是 OCI 镜像的一部分，可以 build、可以 pull、可以版本对比、可以在流水线里被审查。环境可复现这件事容器时代就解决了，授权可复现是新的一步——它把权限从「口头约定」推进到了「可 diff 的产物」。对做 Agent 治理的人来说，价值在这里。
第三，对站内讲过的「沙箱四种方案」意味着什么。沙箱要隔离哪四样东西 那篇里比较过进程级、容器级、微虚机、托管四种方案，当时托管方案的问题是「你的配置和密钥也跟着交出去了」。这次 Docker 的隔离模型是 microVM 且本地云端一致，算是托管路线里比较少见的一种取舍：把隔离做到自建的水平，但把策略的存放位置放在了厂商侧。好处是省事，代价是治理依赖厂商的控制台。
第四，计费口径又一次改变了成本算法。按秒计费、暂停不计费，听起来很省，但它把一个问题明确地甩给了使用者：空闲时间算不算你的成本？长时 Agent 的成本结构里现在多了一块「算力在跑但没在思考」的钱——等待、重试、空转、以及忘了关掉的沙箱。站内 自建推理服务那篇 讲过「成本要按实际产出算、把闲置率算进去」，这个道理在云沙箱上同样成立，只不过闲置这次是按秒计的。
第五，企业侧要额外想两件事。一是本地与云策略分开管理带来的漂移——同一套 Kit 在本地跑和云上跑，网络策略与凭据是两套，很容易出现「本地能跑、云上失败」或反过来「云上放得太开」的情况。二是跨边界的文件系统搬运：把沙箱从本地搬到云上，等于把工作目录连同里面的数据一起转移，如果涉及业务数据或者个人信息，这就是一个需要单独评估的合规动作，判断标准和 Agent 处理个人信息怎么合规 里那套分级脱敏是同一套逻辑。鉴权与密钥的集中管理还有一层风险要说清楚：凭证轮换 那套纪律在「密钥由代理注入」的模式下依然要做，只是轮换的位置变了。
老达点评
第一，这条新闻真正的看点不是「沙箱能上云」，而是「权限第一次有了版本号。」沙箱上云是能力问题，Kits 打进 OCI 是治理问题。以前你想知道「上个版本这个 Agent 被允许访问什么」，答案是去翻 Git 记录和运维的脑子；现在它和镜像是同一种东西，可以对比、可以回归、可以进流水线审。对企业来说，能归档、能 diff、能追责，比「隔离得多严密」重要得多。
第二，我对「关掉笔记本它继续干」这个卖点持保留意见。它解决的是算力持续性，不是任务质量。Agent 跑 12 小时不睡觉，不代表它 12 小时都在干有效的事——它也可能在重试、在绕圈、在把同一个错误做三遍。站内 异常分级 和 失败升级规则 讲的那些机制，在「无人看管的 12 小时」里不是可选项，是必需品。云沙箱让你敢放开时间，但真正决定产出的是你有没有给这 12 小时装上刹车。
第三，给团队的实用建议：先分清你缺的是「隔离」还是「算力」。如果你只是本地机器扛不住长时间任务，一台常开的机器或者一台闲置服务器可能比按秒计费的云沙箱更便宜，而且没有跨边界搬数据的麻烦。真正值得上云沙箱的是两种情况：要并行跑很多个互不干扰的任务，以及需要一个强边界来放那些你不太放心的 Agent 行为。这两条不成立，先别急。
第四，对国内团队，合规要放在技术选型之前考虑。把工作目录搬到境外托管算力上，涉及数据出境判断；如果 Agent 处理的是客户资料或者个人信息，这个动作不能靠「技术上很方便」来推动。前面那五个影响点里，我认为这一条最容易被忽略，也最容易被事后追责。
第五，社区那两句质疑比发布稿更值得记住。「沙箱只解决一半问题」——因为 Agent 总要通过被允许的那几个服务跟外界打交道；「对象能力才是方向」——因为真正要管的不是「在哪个环境里跑」，而是「能以什么方式碰到什么」。第二条和站内 沙箱四层隔离 里讲的凭证与网络边界是同一件事的两种说法。结论不是别用沙箱，而是别把沙箱当成终点。它是地板，不是天花板。
总结
- 事件：Docker 在 WeAreDevelopers 北美站宣布 Cloud Sandboxes，把与本地一致的 microVM 沙箱搬到 Docker 托管算力上；
sbx move可在本地与云之间双向搬运文件系统；同时发布 Kits v3，将 Agent、工具与其访问权限打包为标准 OCI 镜像，并承诺把规范提交 CNCF。 - 配套能力：MCP 统一网关、密钥代理注入（Agent 看不到真值）、网络策略、企业侧集中治理；支持 Claude Code、Codex、Copilot、Cursor、Devin 等主流编码 Agent。
- 计费：按秒计费、暂停不计费；标准 2 vCPU/4 GB 为 0.14 美元/小时，区间 0.07–1.12 美元/小时；默认运行 1 小时，可设 1–24 小时。
- 关键判断一：「算力在哪」正式成为长时 Agent 的主要问题，运行环境正在从自建变成基础设施厂商的产品。
- 关键判断二：被标准化的是授权而不是环境——权限变成了可版本化、可评审、可回归的产物。这是本次发布最实质的进步。
- 关键判断三：沙箱不是终点。Agent 仍要通过被允许的外部服务与外界交互，边界要按能力组合来审；社区提出的「对象能力」方向值得跟。
- 需要注意：本地与云策略分开管理容易产生漂移；跨边界的文件系统搬运在涉及业务数据与个人信息时，是需要单独评估的合规动作。
最后一句：长时 Agent 这一年的进步，一半来自模型能连续干活，另一半来自基础设施终于开始认真回答「它该在哪儿干、能碰到什么」。这次发布把第二个问题往前推了一大步，但只推了一半——剩下那一半，仍然要靠每个团队自己去定义「能以什么方式碰到什么」。
来源说明
本文事实依据 Docker 官方博客与产品页（Manufacturing Trust for AI Agents 主题演讲纪要、Docker Sandboxes 产品说明）、Docker 官方发布文《Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud》、InfoQ 报道《Docker Cloud Sandboxes Provide a Consistent Sandbox Abstraction Across Laptop and Cloud》以及 heise 的报道整理。涉及的具体参数（0.14 美元/小时标准规格、0.07–1.12 美元/小时区间、默认 1 小时与 1–24 小时可设区间、sbx 0.45.1 版本要求、Kits v3 采用 OCI 镜像格式、规范提交 CNCF 的承诺、MCP 网关与密钥代理注入机制）均出自上述官方与公开报道。文中的社区质疑引自 InfoQ 报道中转述的开发者与 Hacker News 评论观点。
