Cloudflare Containers 启动提速 6 倍，支持 Agent 运行时选配沙箱

Cloudflare 重新构建 Containers，让 AI 智能体沙箱更具可扩展性

今天，我们让 Cloudflare Containers 变得更加可编程，并针对 AI 智能体工作负载进行了优化。AI 智能体不会提前部署沙箱，而是在需要时为每个任务即时创建沙箱，并能够暂停和恢复。因此我们重新架构了 Containers 以满足这些需求：你的代码现在可以在运行时选择每个沙箱的镜像和实例类型，Containers 启动速度提升 6 倍，文件系统快照已进入公开测试阶段。

为了实现这一点，我们从底层重新思考了 Containers 基础设施。新的调度策略将每个沙箱的控制权移至应用程序代码中，而重新设计的运行时提供了更快的容器启动路径。在 Compute SDK 的独立基准测试中，中位启动时间从 4 秒多降至 648 毫秒，在我们自己的初步测试中，突发测试成功在数秒内创建了数十万个容器。

所有这些都建立在 Cloudflare Containers 一直以来的独特优势之上：每个 Container 都有自己的 Durable Object，这是一个持久、可编程的控制器，运行在容器旁边，管理其生命周期、出站流量等。我们正在将更多能力直接带到原生 ctx.container API，使 Durable Object 无需中间的包装类即可控制其容器，我们将把这个模型带入 Sandbox SDK 1.0。正如我们今年早些时候写的，你的 AI 智能体需要一台计算机。这些变化使 Containers 成为 Workers、Dynamic Workers 和 Durable Objects 的更好补充，当 AI 智能体需要完整的 Linux 工作空间时。

重新思考面向 AI 智能体的 Containers 运行时

到目前为止，Cloudflare Containers 一直围绕应用程序部署进行组织。你在部署时选择镜像和计算资源，将该配置滚动部署到整个应用程序中，并集中管理它。应用程序是配置和部署的单位。

AI 智能体工作空间则不同：它在 AI 智能体工作时按需创建。任务决定其镜像、资源、工具和起始文件系统。它可能只存在几分钟，在请求之间休眠，或者几天后被恢复。这些决策需要与处理任务的应用程序代码共存，而且 AI 智能体的沙箱需要快速启动，因为启动的每一秒都是你的用户在等待的时间。

我们已经看到 Base44 在应用构建工作空间和 Kilo Code 在云 AI 智能体会话中采用了这种模式。这也出现在我们与 Cursor Cloud Agents、Devin Outposts、OpenAI Agents API 和 Claude Managed Agents 的集成中。

这些工作负载中的每一个都需要从工作空间中获得不同的东西。编码 AI 智能体需要代码仓库、包管理器、编译器、测试运行器和开发服务器。评估需要从已知状态开始的沙箱。强化学习系统需要创建、评分和重置大量环境。运行时间较长的任务需要保留 AI 智能体产生的文件，以便稍后可以继续工作。

这些需求促使我们从根本上重新思考 Cloudflare Containers 的配置、调度和保存方式。结果是一种新的配置和调度 Containers 的方式：durable_object 调度策略。它允许你的代码在运行时选择每个沙箱的镜像和计算资源，Containers 启动速度提升 6 倍以上，并支持文件系统快照，因此工作空间可以被保存和恢复。

"在 Base44，我们帮助任何人将一个想法变成一个可用的应用。Cloudflare Containers 为每个应用提供了一个隔离的开发环境，我们的 AI 可以在其中执行命令、安装依赖项，并在实时预览中实现变更。"

Dolev Epshtein，Base44 应用基础设施软件工程师

"在 Kilo Code，每个云 AI 智能体会话都需要自己的工作和环境，包括正确的代码仓库、工具和用户配置。Cloudflare Containers 让我们能够按需创建这些隔离环境，让我们的 AI 智能体能够快速开始运行命令，为我们的客户工作。"

Emilie Schario，Kilo Code 联合创始人，Anaconda AI 工作空间工程副总裁

从代码中选择 AI 智能体需要的沙箱

从一开始，每个 Cloudflare Container 实例都附加到一个 Durable Object。 Durable Object 为环境提供了稳定的标识，并让应用程序代码控制它的启动、休眠和停止。这个模型已被证明特别适合 AI 智能体沙箱。

然而到目前为止，对 AI 智能体沙箱最重要的两个决策都是在部署时锁定的：它运行什么镜像以及获得多少计算资源。每种镜像和实例类型的组合都是自己的 Containers 应用程序，有自己的 Durable Object 命名空间，通过 wrangler deploy 提前设置。

假设一个 AI 智能体需要一个小型 Node.js 沙箱，另一个需要一个大型 Python 沙箱进行构建。使用我们之前的方法，这需要两个应用程序、两个命名空间，以及在 Worker 中进行路由逻辑以将每个任务发送到正确的目标。每个新环境都意味着另一次部署。

新的 durable_object 调度策略消除了这个问题。镜像和实例类型现在是你在沙箱启动时传递的参数。要选择加入，请设置调度策略并声明你的 Durable Object 可以选择的镜像：

// wrangler.jsonc
{
  "containers": [
    {
      "class_name": "AgentSandbox",
      "scheduling_policy": "durable_object",

      "images": {
        "node": { "dockerfile": "./images/node/Dockerfile" },
        "python": { "dockerfile": "./images/python/Dockerfile" }
      }

    }
  ],
  "durable_objects": {
    "bindings": [{ "name": "SANDBOX", "class_name": "AgentSandbox" }]
  }
}

你声明的每个镜像在 Durable Object 内都可用作 this.ctx.container.images.<name>。当任务到达时，你的代码为该任务选择镜像和实例类型：

import { DurableObject } from "cloudflare:workers";

export class AgentSandbox extends DurableObject {
  async startWorkspace(workspace) {
    if (this.ctx.container.running) {
      return;
    }

    const image =
      workspace.toolchain === "python"
        ? this.ctx.container.images.python
        : this.ctx.container.images.node;

    const instance =
      workspace.workload === "build"
        ? "standard-2"
        : "standard-1";

    this.ctx.container.start({
      image,
      instance,
      enableInternet: true,
    });
  }
}

这段代码在任务已知后做出了两个决策。它选择工作空间需要的工具链以及分配多少计算资源。过去需要一个单独的应用程序和单独的 wrangler 部署才能完成的事情，现在只是一个 if 语句。一个 Durable Object 类可以并行启动不同大小的 Node.js 和 Python 沙箱，而添加新环境是代码更改，而不是新的部署。这就是整个更新的理念：基础设施成为在请求时运行的代码，一直到环境本身。

部署现在只是代码

在启动时选择镜像也解决了一个运行 Containers 最痛苦的问题：部署。

以前，更新镜像意味着更新整个应用程序。你设置宽限期，以便运行的实例可以排空，定义百分比分割以逐步迁移流量，并调用我们的 API 来推送新配置。在整个过程中，平台决定哪些实例被替换以及何时替换，无论 AI 智能体是否正在执行任务。

使用 durable_object 调度策略，根本没有部署配置。容器可以继续运行它启动时的镜像，直到你的代码停止它。下次该 Durable Object 启动容器时，它使用你的代码选择的任何镜像。这意味着你想要的任何部署策略都是几行代码：

const image =
  (await this.ctx.storage.get("pinned-image")) ??
  (isCanary(this.ctx.id)
    ? this.ctx.container.images.nodeV2
    : this.ctx.container.images.node);

例如，你可以：

通过对 Durable Object ID 进行哈希运算，在 5% 的新沙箱上金丝雀发布新工具链。

将活跃项目固定到其当前镜像，这样 AI 智能体永远不会在任务中途被换掉环境。

在自然的检查点迁移工作空间，例如下次会话时或快照之后。

通过更改未来启动选择的镜像来回滚。不需要配置推送，不需要等待排空。

部署策略存在于你的 Durable Object 代码中，与你的其他逻辑放在一起，它可以像你需要的那样简单或复杂。

这些改进都来自于进一步依赖 Durable Object，它已经拥有了工作空间的标识、状态和生命周期。允许它选择和控制其容器，让你更好地控制每个实例及其部署。这也给了调度器一个更好的地方来启动容器：无论 Durable Object 已经在哪里运行。这就是让 AI 智能体更快地执行第一个命令的原因。

新的调度路径

此前，启动一个 Container 需要全局控制平面解析应用配置、寻找容量并协调放置。这套模型对应用级舰队运作良好，但将部署机制放在了智能体第一条命令的执行路径上。

使用 durable_object 调度策略，需求从 Durable Object 开始。服务于它的 Containers 基础设施首先在同一台机器上寻找容量，若需要再扩大至同一位置内搜索。它还优先选择宿主机上已存有该 Container 镜像或快照的节点，这样 Container 无需先行下载即可启动。

我们还削减了 Container 到达宿主机后的工作。新运行时不再从头启动虚拟机，而是恢复一个尚未分配的预准备虚拟机。它复用网络和文件系统配置，批量处理重复操作，不再等待首条命令不需要的服务。

这些改进大幅缩短了从创建沙箱到在其中执行命令的时间。在 ComputeSDK 独立的 Burst TTI Benchmark（并发启动 100 个沙箱并从客户端测量 time-to-interactive）中：

旧的调度路径

新调度策略

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

从预准备系统镜像开始

随着调度路径变快，镜像准备成为剩余等待时间中更大的部分。在 Container 启动前，其镜像必须已在宿主机上并解压到文件系统。当这些工作在请求到达后才进行时，智能体就只能等待。

因此我们推出 cloudflare/debian-trixie：一个可供智能体使用的即用型系统镜像，可在运行时配置环境，包含 Debian Trixie Slim 和 Node.js 24.20.0 LTS：

this.ctx.container.start({
  image: "cloudflare/debian-trixie",
  instance: "standard-2",
  enableInternet: true,
  entrypoint: ["/bin/sleep", "infinity"]
});

这意味着你的智能体可以启动一个 Linux 沙箱，无需先创建 Dockerfile、构建镜像或将其推送到 Cloudflare。沙箱运行后，你的智能体可以使用 exec() 克隆仓库、安装包并为任务配置环境。

而且由于 Cloudflare 控制这个镜像，我们可以在请求到达前将其分发并准备到符合条件的所有 Container 宿主机上。启动时无需下载或解压基础镜像。

保存工作区并稍后恢复

快速启动仍然留下一个等待：设置工作区。克隆仓库、安装依赖和配置工具链可能比启动 Container 本身花费更长时间。智能体工作时也会产生你希望保留的文件。每次启动都重复设置会浪费时间，而丢失智能体的更改则使继续任务变得困难。

这就是为什么我们为 Container 添加了原生文件系统快照功能，公开 beta 版。快照让智能体可以在预准备环境中开始任务，在任务暂停时保存工作区，并在会话恢复时还原这些文件。

async saveWorkspace() {
  const snapshot = await this.ctx.container.snapshotContainer({
    name: "project-ready",
  });

await this.ctx.storage.put("workspace-snapshot", snapshot);
}

async restoreWorkspace() {
  const snapshot = await this.ctx.storage.get("workspace-snapshot");

if (!snapshot) {
    throw new Error("No workspace snapshot found");
  }

this.ctx.container.start({
    containerSnapshot: snapshot,
    instance: "standard-2",
    enableInternet: true,
  });
}

快照支持两种有用的模式。

首先，一个工作区可以跨多个会话继续。对于编码智能体，这可能意味着在用户完成工作时保存工作区，并在他们第二天返回时还原。仓库、已安装的依赖、构建缓存、配置和编辑内容都无需重建环境即可使用。

其次，快照可以为多个沙箱提供共享检查点。由于快照是不可变的且可复用的，多个 Container 可以独立地从同一个预准备环境启动，并从那里做出各自的更改。

智能体评估就是一个很好的例子。一次评估可能使用不同的系统提示词、技能、模型或智能体版本运行相同的任务。要比较结果，其他一切必须保持不变：仓库、依赖、工具和输入文件。一个快照可以从同一个基线启动多个隔离环境，减少设置时间，并防止环境漂移影响结果。

快照与我们上面引入的新系统镜像相得益彰。智能体可以从 cloudflare/debian-trixie 启动，用 exec() 设置环境，然后将其保存为快照。未来的沙箱随后从该快照启动，仓库、依赖和工具链已就位。

随着快照通过新的 durable_object 调度策略可用，Container 可以充当持久的智能体工作区。Compute 可以在工作暂停时停止，新的 Container 可以从最新的快照启动，从上次停下的地方继续。

Durable Object 对智能体沙箱的优势

更快的调度路径、运行时镜像选择和文件系统快照都来自同一个设计选择：进一步让 Durable Object 作为其附属 Container 的控制器。

智能体系统需要一个可编程的、有状态的环境来保存在 Container 外部的状态、持有凭证并控制沙箱的生命周期。你可以在那里运行智能体，遵循 Anthropic 描述的"将大脑与双手解耦"模式：当智能体与其工作的沙箱分离时，智能体保持可用，而其沙箱和工具可以独立地启动、停止、失败或被替换。或者，如果你选择在沙箱内部运行智能体，外部环境可以让你监督它并向用户报告进度。

这就是 Durable Object 和 Container 架构变得特别适合的地方。每个 Container 都连接到一个有状态的 Durable Object，它拥有自己的计算和存储，运行在紧邻的位置。你可以在 Durable Object 中运行智能体并将 Container 用作其工作区，或者在 Container 中运行智能体并用 Durable Object 来监督它。加上 Dynamic Workers 用于轻量级隔离执行，应用程序可以为每个任务选择所需的执行环境。

durable_object 调度策略的新特性是 Durable Object 现在可以直接控制其 Container，中间无需包装类。exec() 直接在 Workers 运行时中运行，出站请求拦截、运行时镜像和实例选择以及文件系统快照都可通过 ctx.container 获得。你可以将它们与 Durable Object 存储、告警、WebSocket、RPC 以及你的其余代码结合使用。

这使得 Container 成为 Durable Object 的计算扩展。Container 提供 Linux 环境，而你的 Durable Object 保留沙箱的身份、状态、策略和生命周期。这种分工特别适合以下几种模式：

智能体可以在其 Linux 工作区休眠时保持可用。智能体循环可以在 Durable Object 中运行，它维护会话状态、通过 WebSocket 与用户通信并调用模型。它在需要 shell、编译器或开发服务器时唤醒 Container，然后在等待用户或模型时停止该计算，无需为空闲的 Linux 计算付费。

Durable Object 可以为其 Container 编程安全边界。它可以记住用户授权了哪些服务、仓库和操作，然后更新 Container 的出站请求处理器以注入新授予的凭证、执行新策略或记录额外活动。这类似于 Cloudflare OS 使用的 Gatekeeper 模式，应用于每个智能体计算机。

评估和强化学习系统可以从被测试环境的外部监督每次尝试。协调器快照一个基础工作区并将其 fork 到 N 个尝试，每个都有自己独立的 Durable Object 和 Container。每个 Durable Object 运行其尝试、监控运行过程并保存结果，即使 Container 崩溃。协调器对尝试进行评分，快照最好的一个，并从那里再次 fork。

这些模式不适合一种通用的生命周期。本地 API 让你将 Container 与应用程序需要的 Durable Object 原语结合使用，同时在有帮助的地方使用更高级的工具。你保留对 Container 生命周期、策略和状态的控制权。

这对 Container 类和 Sandbox SDK 意味着什么

当 Containers 发布时，我们有意将 Durable Object 隐藏在 Container 类背后。我们希望沙盒让开发者感到熟悉，符合他们对其他平台的预期。Sandbox SDK 就建立在这个类之上，它填补了真实的空白：当时运行时没有原生命令执行、出站请求拦截或快照功能，所以我们自己在用户空间里实现了这些能力。

自那以后，AI 智能体工作空间已成为塑造 Containers 的主要工作负载之一，而这一层抽象的代价也日益明显。通过将 Durable Object 隐藏起来，我们让开发者更难看清它所提供的身份、状态和协调能力，也更难将其与它所管理的 Container 结合起来。我们合作过的几乎每个团队都对通用生命周期有各自不同的需求：自定义的睡眠策略、凭证处理方式，以及追踪评估运行的方法。

这些能力如今已成为原生功能，所以我们将在开发者体验中显式暴露 Durable Object：

新功能仅在原生版本中提供。durable_object 调度策略、更快的启动速度、运行时镜像和实例选择，以及文件系统快照等功能只能通过 ctx.container 来使用。

我们将维护 Container 类和旧版 Sandbox 类至 2026 年 12 月 31 日。现有部署在该日期后仍可继续运行，但这些类将不再获得更新。我们建议迁移至 ctx.container。

Sandbox SDK 1.0 是一组工具库，而非基类。它的辅助函数可以在你自己的 Durable Object 类中运行，与 ctx.container 共存。

如需更高层级的环境，@cloudflare/computer 将 Dynamic Workers 和 Containers 与同步文件系统相结合。

迁移通常意味着将 extends Container 改为 extends DurableObject，并直接调用 this.ctx.container。详见迁移指南。或者，用以下方式开始为你的 AI 智能体构建：

如今，大多数 AI 智能体的能力是通过单个会话中完成的任务来衡量的。但随着 AI 智能体承担起跨越数小时、数天乃至数周的项目时，它们的工作环境也需要随之演进。

我们期望每个 AI 智能体都能为其任务创建沙盒，在工作暂停时释放计算资源，并在项目继续时返回到相同的工作空间。今日的变更使我们更接近于打造出与使用它们的 AI 智能体一样可编程、持久且随时待命的沙盒。

立即体验新的 durable_object 调度策略——今日已向所有用户开放公开 beta——看看更快的启动速度、文件系统快照和运行时配置能为你的 AI 智能体带来什么：

使用新的 Durable Object 调度策略管理 Containers

使用文件系统快照保存和恢复文件

从 GitHub 部署一个使用 Durable Object 调度策略的完整沙盒示例

从 Cursor Cloud Agents、Devin Outposts 或 OpenAI Agents API 的集成开始

致谢：Greg Anders、Andrew Martinez、Nafeez Nazer、Kian Newman-Hazel、Sebastien Pahl、Naresh Ramesh、Cody Roseborough、Nikita Sharma 和 Sarah Snell 的贡献使本项目成为可能。