讲一下这个https://blog.cloudflare.com/faster-agent-sandboxes/

回复 joye： 这篇是 Cloudflare 今天发的 Containers 重做公告，主题一句话：把容器从「部署导向」改成「Agent 沙箱导向」。它开篇的判断我认同——Agent 不会提前部署沙箱，而是每个任务现场开一个，要求立刻可用，还得能暂停、恢复。所以整个调度和运行时都推翻重做了。 核心是三件事：镜像和实例规格改成运行时由代码选、启动快 6 倍、文件系统快照进公测。 先说为什么以前的模型别扭。以前 Containers 是围绕「应用部署」组织的：镜像和算力在 deploy 时就锁死，每种「镜像 × 实例类型」组合就是一个独立应用，有自己的 Durable Object namespace，得 wrangler deploy 一次。所以一个 Agent 要小型 Node 盘、另一个要大型 Python 盘，就是两个应用、两个 namespace，再加 Worker 里的路由逻辑。新的 durable_object 调度策略把这两个决定变成启动沙箱时传的参数，一个 DO 类可以并排开不同规格的 Node 和 Python 沙箱，加环境是改代码而不是新部署。 顺带的收益是「滚动发布」这件事消失了。以前更新镜像等于更新整个应用，你得设 grace period 让实例排空、配百分比灰度、再调 API 推配置，平台决定谁什么时候被替换。现在容器可以一直跑它启动时那个镜像直到你的代码停它，下次启动用哪个镜像由代码决定。所以灰度就是拿 DO ID 做个哈希挑 5%、pin 住活跃项目不被换环境、在会话边界或快照后迁移、回滚就是换掉未来启动选的镜像，几行代码搞定。 速度这块的数据：ComputeSDK 的独立 Burst TTI 基准（并发起 100 个沙箱，从客户端侧量到能交互），中位数从 4.049 秒降到 648 毫秒，6.2 倍；p95 从 5.839 秒到 910 毫秒；p99 从 6.717 秒到 1129 毫秒。他们自己初步压测单个账号 5.387 秒内在六个地区起了 10 万个容器。怎么做到的：需求起点从控制面挪到了 DO 本身，调度先在同一台机器上找容量，不够再在同地区扩大，并且优先挑本地已缓存该镜像或快照的宿主机；运行时那边不再从零引导虚拟机，而是恢复一台已备好但还没分配的 VM，复用网络和文件系统设置、批量合并重复操作、第一跳不要的服务先不等。 另外他们放了一个 cloudflare/debian-trixie 系统镜像，Debian Trixie Slim 加 Node.js 24.20.0 LTS。这个是给「运行时自己配环境」的 Agent 用的：不用写 Dockerfile、不用构建推送，直接 start 起来再 exec 去 clone 仓库装依赖。关键点是 Cloudflare 自己控制这个镜像，可以在请求到达前就分发预热到合规宿主机上，省掉下载和解包那段等待。这其实点出了一个现实：调度快了之后，镜像准备才是剩下的大头。 然后是快照，公测。snapshotContainer 存一份，Durable Object storage 里放引用，恢复时 start 加 containerSnapshot。两个用法值得分开看：一是同一个工作区跨多次会话续上，比如用户今天干完存快照，明天回来仓库、依赖、build cache、配置、改动都还在，不用重建；二是快照不可变可复用，所以可以拿同一个基线快照 fork 出 N 个隔离环境——这正是 eval 和 RL 要的，同一道题跑不同 system prompt、skill、模型或版本时，仓库、依赖、工具、输入文件必须完全一致，一个基线快照既省 setup 时间，又避免环境漂移污染对比结果。它跟上面的系统镜像是叠加的：从 debian-trixie 起步，exec 配好，存成快照，以后都从快照起。 架构上它想把 Durable Object 抬成显式主角。每个 Container 本来都挂着一个有状态的 DO，同机跑，管身份、状态、生命周期。新策略下 DO 能直接控制它的容器，中间没有 wrapper class，exec 直接跑在 Workers runtime 里，出口请求拦截、运行时选镜像选实例、快照全在 ctx.container 上，还能和 DO 的 storage、alarm、WebSocket、RPC 混着用。容器就成了 DO 的算力延伸：容器给 Linux 环境，DO 留住身份、状态、策略和生命周期。 它举了几个因此成立的模式。Agent 主循环放 DO 里，管会话状态、通过 WebSocket 跟用户说话、调模型，需要 shell 或编译器时才唤醒容器，等用户或等模型的时候把 Linux 算力停掉，空闲不烧钱。DO 还能给自己的容器编排安全边界，记住用户授权过哪些服务、仓库、操作，然后更新容器的 Outbound Request Handler 去注入凭据、加策略、记行为，他们说这类似 Cloudflare OS 里的 Gatekeeper 模式，只是按每个 Agent 电脑来。再就是 eval / RL 把监督放在被测环境外面：协调者存基线、fork 成 N 份，每份一个 DO 加一个容器，各自跑各自的尝试，容器崩了结果也保得住，协调者打分、存最好的那份、再从那 fork。 需要留意的破坏性变化：新能力是 native-only，durable_object 调度、快启动、运行时选镜像选实例、快照只走 ctx.container。Container 类和老的 Sandbox 类会维护到 2026 年 12 月 31 日，之后已有部署继续能跑但不再更新；Sandbox SDK 1.0 退化成一堆工具函数而不是基类，helper 在你自己的 DO 类里跟 ctx.container 一起用。迁移大体上就是把 extends Container 改成 extends DurableObject，然后直接用 this.ctx.container。想要更高层的环境可以用 @cloudflare/computer，把 Dynamic Workers 和 Containers 加一个同步文件系统拼起来。 我自己的看法：这篇的价值主要不在「快 6 倍」这个数字，而在于它承认了 Agent 沙箱的生命周期跟传统应用不是一个东西。启动延迟是被用户直接感知的成本，但克隆仓库、装依赖往往比启动本身更久，所以快照这一手其实比调度优化更解决痛点——它把「准备一个环境」从每次任务都做，变成做一次然后反复 fork。代价是控制权交给你了：滚动策略、睡眠策略、凭据处理、eval 编排，都从平台的配置项变成你 DO 里的代码，灵活但也更要求你自己想清楚生命周期。