Cloudflare Containers 架构重构：启动提速 6 倍，让智能体按需拉起沙箱

Cloudflare Blog 发布日期待确认

Cloudflare 重新设计了 Containers 的底层架构，专门面向智能体（agent）负载优化：应用代码现在能在运行时决定每个沙箱用哪个镜像、分配多少算力，容器启动速度提升 6 倍，文件系统快照进入公开测试。在第三方基准测试中，启动中位数从 4 秒多降到 648 毫秒。

发生了什么：Containers 为智能体重写底层

Cloudflare 让 Containers 变得更好编程，并针对智能体负载做了优化。原因是智能体不会提前把沙箱部署好——它们是按需创建：接一个任务就建一个沙箱，要求立刻能用，还要能随时暂停和恢复。

为了满足这些需求，Cloudflare 把 Containers 的底层基础设施从头重新设计了一遍。现在，你的代码可以在运行时决定每个沙箱用哪个镜像、哪种实例类型；容器启动速度提升了 6 倍；文件系统快照进入公开测试。

具体做法是两条：新的调度策略把每个沙箱的控制权交给应用代码；重新设计的运行时让容器跑起来更快。在 ComputeSDK 的独立基准测试中，启动中位数从 4 秒多降到 648 毫秒；在 Cloudflare 自己的初步测试里，突发测试能在几秒内成功创建数十万个容器。

这些能力建立在 Containers 一直以来的一个独特设计上：每个 Container 都配有自己的 Durable Object——一个常驻、可编程的控制器，就运行在容器旁边，负责管理它的生命周期、出站流量等。现在 Cloudflare 把更多能力直接开放到原生的 ctx.container API 上，Durable Object 不用再套一层包装类就能控制自己的 Container，并且会把这套模式延续到 Sandbox SDK 1.0。

正如 Cloudflare 今年早些时候所说，你的智能体需要一台计算机。这次改动让 Containers 在智能体需要完整 Linux 工作区时，能更好地和 Workers、Dynamic Workers、Durable Objects 搭配使用。

为智能体重思容器运行时

在此之前，Cloudflare Containers 是围绕「应用部署」来组织的：你在部署时选好镜像和计算资源，把这份配置在整个应用上推出去，再集中管理。应用才是配置和发布的基本单位。

而智能体工作区不一样：它是在智能体干活的过程中按需创建的。任务决定了它用什么镜像、多少资源、哪些工具、起始文件系统长什么样。它可能只活几分钟，也可能在两次请求之间休眠，或者过几天才被恢复出来。

这些决策需要和应用处理任务的代码放在一起。同时，智能体沙箱必须启动得够快——启动花掉的每一秒，都是用户在等待。

这种模式已经出现在多个产品里：Base44 的应用构建工作区、Kilo Code 的云端 agent 会话，以及 Cursor Cloud Agents、Devin Outposts、OpenAI Agents API、Claude Managed Agents 等集成中。

不同工作负载对工作空间的要求也各不相同：

• 编程 agent 需要代码仓库、包管理器、编译器、测试运行器和开发服务器；
• 评估任务需要从已知状态启动的沙箱；
• 强化学习系统需要批量创建、评分并重置大量环境；
• 运行时间较长的任务需要保留 agent 生成的文件，以便之后继续工作。

这些需求促使 Cloudflare 从根本上重新思考 Containers 的配置、调度和保存方式。最终成果是一套全新的容器创建与调度方式——durable_object 调度策略。它让代码可以在运行时为每个沙箱选择镜像和计算资源，容器启动速度提升 6 倍以上，并支持文件系统快照，因此工作空间可以保存和恢复。

“在 Base44，我们帮助任何人把一个想法变成能跑起来的应用。Cloudflare Containers 为每个应用提供独立的开发环境，我们的 AI 可以在其中执行命令、安装依赖，并在实时预览中呈现改动。”
—— Dolev Epshtein，Base44 应用基础设施软件工程师

“在 Kilo Code，每个云端 agent 会话都需要自己的工作空间和环境，包含正确的代码仓库、工具和用户配置。Cloudflare Containers 让我们可以按需创建这些隔离环境，agent 能快速开始执行命令，为我们的客户干活。”
—— Emilie Schario，Kilo Code 联合创始人、Anaconda AI 工作空间工程副总裁

从代码出发，选择 agent 需要的沙箱

从一开始，每个 Cloudflare Container 实例都绑定到一个 Durable Object。Durable Object 为环境提供稳定的身份标识，并让应用代码控制它何时启动、休眠和停止。

这套模式特别适合 agent sandbox（智能体沙箱）。只不过在这之前，对 agent sandbox 影响最大的两个决定，在部署时就已经被锁死了：运行哪个镜像、分配多少算力。

关键要点

• Containers 底层架构为智能体负载重写，应用代码可在运行时决定每个沙箱的镜像与实例类型；
• 启动速度提升 6 倍，独立基准测试中启动中位数从 4 秒多降至 648 毫秒；
• 文件系统快照进入公开测试，工作空间可保存与恢复；
• 新引入 durable_object 调度策略，把每个沙箱的控制权交还应用代码；
• 每个容器仍绑定一个 Durable Object，负责生命周期与出站流量管理。

镜像和实例类型，从「提前部署」变成「运行时传参」

过去，每一种「镜像 + 实例类型」的组合都是一个独立的 Containers 应用，各自带着自己的 Durable Object 命名空间，还得提前用 wrangler deploy 部署好。

打个比方：一个 agent 需要一个小型 Node.js 沙箱，另一个需要大型 Python 沙箱来跑构建。按以前的方案，这要两个应用、两个命名空间，还得在 Worker 里写路由逻辑，把每个任务分发到对应的那个。每新增一种环境，就得多部署一次。

新的 durable_object 调度策略把这些都省掉了。镜像和实例类型现在变成了代码在沙箱启动时传入的参数。要启用它，只需设置调度策略，并声明 Durable Object 可以选用的镜像：

你声明的每个镜像，在 Durable Object 里都能通过 this.ctx.container.images.<name> 访问。任务到来时，代码再为这个任务挑镜像和实例类型：

这段代码在知道任务是什么之后做两个决定：工作区需要哪套工具链，该分多少算力。以前要单独建应用、单独跑一次 wrangler deploy 的事，现在一句 if 判断就搞定。一个 Durable Object 类可以同时启动不同规格的 Node.js 和 Python 沙箱；新增一种环境只是改代码，不用重新部署。这就是整个更新的核心思路：基础设施变成在请求时运行的代码，连环境本身也是。

发布，现在只是代码

在启动时才选镜像，还顺手解决了跑 Containers 时最头疼的环节之一：发布（rollout）。以前更新一个镜像，等于更新整个应用。你得设置宽限期，让运行中的实例慢慢退出；定义按百分比切分的流量，一步步迁移；再调用 API 推送新配置。整个过程中，由平台决定哪些实例何时被替换——根本不管 agent 是不是正处理到一半。

用了 durable_object 调度策略之后，发布配置就完全不存在了。

Container 会一直跑着启动时用的镜像，直到你的代码把它停掉。等这个 Durable Object 下次启动 Container 时，用哪个镜像完全由你的代码决定。这意味着你想怎么做灰度发布，都只需要几行代码。举个例子，你可以：

• 用 Durable Object ID 做哈希，把新工具链只放给 5% 的新沙箱。
• 把正在进行的项目钉在它当前的镜像上，这样 agent 干活干到一半，环境不会被换掉。
• 在自然的检查点迁移工作区，比如下一次会话开始前，或者快照之后。
• 想回滚，只要改一下后续启动用哪个镜像就行。不用推配置，也不用等排空。

发布策略就写在你的 Durable Object 代码里，跟其他逻辑放一起，想简单就简单，想精细就精细。这些改进说到底，都是更多地依赖 Durable Object——它本来就管着工作区的身份、状态和生命周期。让它来挑选和掌控自己的 Container，你对每个实例以及它的发布就有了更多控制权。同时，调度器也找到了更好的启动位置：Durable Object 已经在哪台机器上跑，就在哪台机器上启动 Container。这正是让 agent 更快跑到第一条命令的原因。

更快的首条命令

以前启动一个 Container，得靠我们的全球控制面去解析应用配置、找容量、协调放置位置。这套做法对面向整个应用的集群很好用，但它把部署机制塞进了 agent 执行第一条命令的必经之路上。

改成 durable_object 调度策略后，需求从 Durable Object 这里发起。承担它的 Containers 基础设施会先在同一台机器上找容量，不够就在同一个地点（location）内扩大搜索范围。它还会优先选本地已经存了该 Container 镜像或快照的主机，这样启动时不用先下载。

Container 到达主机之后，我们也砍掉了不少工作。新的运行时不再从头启动一台虚拟机，而是直接恢复一台已经准备好、但还没分配出去的虚拟机。它复用了网络和文件系统的初始化，把重复操作批量处理，也不再等待那些首条命令根本用不到的服务。

这些改动合在一起，大幅缩短了从创建沙箱到在其中运行命令所需的时间。在 ComputeSDK 的独立 Burst TTI 基准测试中，同时启动 100 个沙箱，并从客户端测量达到可交互状态的时间：

新路径在突发负载下同样表现稳定。在我们的初步突发测试中，单个账号在 5.387 秒内于六个地点启动了 100,000 个 Container。

从预构建的系统镜像开始

调度路径变快之后，准备镜像在剩余等待时间中占的比重就更大了。Container 启动前，镜像必须先落到宿主机上，并解包成文件系统。如果这步在请求到达后才做，Agent 就只能干等。

开箱可用的系统镜像：cloudflare/debian-trixie

Cloudflare 推出了 cloudflare/debian-trixie，一个开箱即用的智能体系统镜像。它内置 Debian Trixie Slim 和 Node.js 24.20.0 LTS，并且在运行时就能配置自己的环境。

这意味着智能体不必先写 Dockerfile、构建镜像、再推送到 Cloudflare，就能直接拉起一个 Linux 沙箱。沙箱启动后，智能体可以调用 exec() 克隆仓库、安装依赖，按手头任务的需要来搭环境。

由于这个镜像由 Cloudflare 自己维护，我们能在请求到达之前就把它预先分发到符合条件的 Container 宿主机上。启动时用户不必再等基础镜像下载和解包。

快照：保存工作区，下次接着干

启动快了，还有一处等待：搭工作区。克隆仓库、安装依赖、配置工具链，这些步骤往往比启动容器本身更耗时。智能体干活时还会产生一批你想保留的文件。每次启动都从头来一遍，既浪费时间，丢掉智能体的修改后，任务也很难接着往下做。

为此，我们给 Container 加入了原生文件系统快照，目前处于公开测试阶段。

快照让智能体从一个准备好的环境开始任务，在暂停时保存工作区，会话恢复时再把这些文件还原回来。它支持两种实用模式：

一是同一工作区跨多个会话沿用。 对编程智能体来说，用户收工时保存工作区，第二天回来再恢复。代码仓库、已安装依赖、构建缓存、配置和编辑内容都还在，不用重建环境。

二是快照充当多个沙箱的共享检查点。 快照不可变、可复用，多个容器可以从同一个准备好的环境各自独立启动，再各自修改。智能体评估是典型场景：一次评估可能用不同的系统提示词、技能、模型或智能体版本跑同一个任务。要比较结果，其他条件必须保持一致——代码仓库、依赖、工具和输入文件。一个快照就能从同一基线拉起多个隔离环境，既减少准备时间，也避免环境漂移干扰结果。

快照还能和我们前面提到的新系统镜像搭配使用：智能体从 cloudflare/debian-trixie 启动，用 exec() 配置环境，再把结果存成快照。之后的沙箱直接从这个快照启动，代码仓库、依赖和工具链全部就位。快照通过新的 durable_object 调度策略使用，容器因此可以作为持久化的智能体工作区：工作暂停时计算可以停掉，新容器从最新快照启动，接着之前的工作继续。

Durable Object 作为智能体沙箱的控制器

更快的调度路径、运行时镜像选择和文件系统快照，都来自同一个设计选择：进一步让 Durable Object 作为所连接容器的控制器。智能体系统需要在容器之外有一个可编程、有状态的环境，用来保存状态、保管凭证，并控制沙箱的生命周期。

你可以把智能体跑在 Durable Object 里，采用 Anthropic 提出的「大脑与双手解耦」思路：智能体和工作用的沙箱分开后，智能体始终在线，而它的沙箱和工具可以独立地启动、停止、失败或被替换。如果你把智能体跑在沙箱内部，外部环境也可以监督它，把进度回报给用户。这正是 Durable Object 与 Container 架构特别擅长的地方。

查看原文