Cloudflare 重构容器，加速 AI 智能体沙箱。
Cloudflare AI··作者 Thomas Lefebvre
关键信息
Cloudflare 表示，在 ComputeSDK 的独立基准测试中，中位启动时间从略高于四秒降至 648 毫秒；其内部初步突发测试则在数秒内创建了数十万个容器。快照会捕获完整文件系统且不可变，因此恢复后产生的修改需要通过新快照保存；同时，由于部分性能和突发容量数据仍属初步结果并由厂商报告，解读时应保持谨慎。
资讯摘要
Cloudflare 围绕 AI 智能体的需求重新设计了 Containers，因为这类智能体会按需创建隔离工作区，并要求工作区几乎立即可用。新的 durable_object 调度策略把容器镜像和计算资源的选择权从部署阶段转移到处理具体任务的应用代码中。Cloudflare 还重新设计了运行时，以缩短容器进入可用状态的路径；ComputeSDK 的基准测试显示，其中位启动时间从此前略高于四秒降至 648 毫秒。在 Cloudflare 的内部初步突发测试中，该平台能够在数秒内创建数十万个容器，但这些数据尚不能视为最终的独立基准结果。
每个容器仍会配备一个 Durable Object，作为持久且可编程的控制器，负责管理容器生命周期、出站流量及相关行为。Cloudflare 正把更多控制能力直接加入原生 ctx.container API，并计划将这一模型延伸至 Sandbox SDK 1.0。处于公开测试阶段的文件系统快照可以保存和恢复智能体工作区，从而支持在请求之间休眠或数天后继续执行的任务。当智能体需要包含代码仓库、包管理器、编译器、测试工具或开发服务器的完整 Linux 工作区时，Cloudflare 将重构后的 Containers 定位为 Workers、Dynamic Workers 和 Durable Objects 的补充。
资讯正文
今天，我们将让 Cloudflare Containers 具备更强的可编程性，并针对代理工作负载进行优化。代理不会提前部署沙箱，而是会针对每项任务按需创建沙箱，希望沙箱能够立即准备就绪，并且可以暂停和恢复。因此，我们重新设计了 Containers，以满足这些要求：现在，你的代码可以在运行时选择每个沙箱的镜像和实例类型；Containers 的启动速度提升了 6 倍；文件系统快照也已进入公开测试阶段。
为了实现这一点，我们从底层开始重新思考 Containers 的基础设施。新的调度策略将每个沙箱的控制权交给应用代码，而重新设计的运行时则为启动运行中的 Container 提供了更快的路径。在 ComputeSDK 的独立基准测试中，启动时间中位数从略高于 4 秒降至 648 毫秒；在我们自己的初步测试中，突发测试成功地在几秒内创建了数十万个容器。
所有这些都建立在 Cloudflare Containers 一直以来区别于其他方案的特性之上：每个 Container 都拥有自己的 Durable Object——一个在其旁边持续运行、可编程的控制器，负责管理容器的生命周期、出站流量等。我们正在将更多能力直接引入原生的
ctx.container
API，这样 Durable Object 就可以直接控制其 Container，中间无需再通过包装类；同时，我们也会将这一模型延伸到 Sandbox SDK 1.0 中。
正如我们在今年早些时候所写的：
你的代理需要一台计算机。
当代理需要完整的 Linux 工作区时，这些变化让 Containers 成为 Workers、Dynamic Workers 和 Durable Objects 的更佳补充。
重新思考面向代理的 Containers 运行时
到目前为止，Cloudflare Containers 一直围绕应用部署进行组织。你会在部署时选择镜像和计算资源，将这套配置推广到整个应用，并对其进行集中管理。应用是配置和发布的基本单位。
代理工作区则有所不同：它是在代理工作期间按需创建的。任务决定了工作区所使用的镜像、资源、工具以及初始文件系统。工作区可能只存在几分钟，也可能在请求之间休眠，或者在数天后恢复。这些决策需要由处理任务的应用代码来决定；同时，代理的沙箱必须快速启动，因为启动过程中的每一秒，都是用户需要等待的时间。
我们已经在 Base44 的应用构建工作区和 Kilo Code 的云代理会话中看到了这种模式。它也出现在我们与
Cursor Cloud Agents
Devin Outposts
、
OpenAI Agents API
以及
Claude Managed Agents
的集成中。
这些工作负载对工作区各有不同需求。编程代理需要代码仓库、包管理器、编译器、测试运行器和开发服务器。评测需要从已知状态开始的沙箱。强化学习系统需要创建、评分并重置大量环境。运行时间更长的任务则需要保留代理生成的文件，以便之后继续工作。
这些要求促使我们从根本上重新思考 Cloudflare Containers 的配置、调度和保存方式。最终，我们形成了一种配置和调度 Containers 的新方式：
durable_object 调度策略。它允许你的代码在运行时选择每个沙箱所使用的镜像和计算资源，使 Containers 的启动速度提升至原来的 6 倍以上，并支持文件系统快照，从而可以保存和恢复工作区。
“在 Base44，我们帮助任何人把想法变成可运行的应用。Cloudflare Containers 为每个应用提供隔离的开发环境，让我们的 AI 能够执行命令、安装依赖，并通过实时预览让更改真正运行起来。”
Dolev Epshtein，Base44 应用基础设施软件工程师
“在 Kilo Code，每个云代理会话都需要自己的工作区和环境，其中包括正确的代码仓库、工具和用户配置。Cloudflare Containers 让我们能够按需创建这些隔离环境，因此我们的代理可以快速开始运行命令，为客户投入工作。”
Emilie Schario，Kilo Code 联合创始人、Anaconda AI Workspaces 工程副总裁
通过代码选择代理所需的沙箱
从一开始，每个 Cloudflare Container 实例都会关联到一个 Durable Object。Durable Object 为环境提供稳定的身份，并允许应用程序代码控制环境何时启动、休眠和停止。这种模型已被证明非常适合代理沙箱。
不过，在此之前，代理沙箱最重要的两个决策都必须在部署时确定：它运行哪个镜像，以及获得多少计算资源。每种镜像与实例类型的组合都对应一个独立的 Containers 应用，并拥有自己的 Durable Object 命名空间，需要提前通过 wrangler deploy 完成设置。
假设一个代理需要一个小型 Node.js 沙箱，而另一个代理需要一个用于构建的大型 Python 沙箱。按照此前的方法，这需要两个应用、两个命名空间，以及 Worker 中的路由逻辑，以便将每项任务发送到正确的应用。每增加一个新环境，就意味着又要进行一次部署。
新的 durable_object 调度策略解决了这个问题。镜像和实例类型现在变成了由代码在沙箱启动时传入的参数。要启用这一功能，请设置调度策略，并声明 Durable Object 可以选择的镜像：
你声明的每个镜像都会在 Durable Object 中以 this.ctx.container.images.<name> 的形式提供。当任务到达时，你的代码可以为该任务选择镜像和实例类型：
这段代码会在确定任务后作出两个决定：选择工作区所需的工具链，以及为其分配多少计算资源。过去需要一个独立应用和一次单独的 wrangler deploy，现在只需要一个 if 语句。一个 Durable Object 类可以并行启动不同大小的 Node.js 和 Python 沙箱，而添加新环境变成了代码变更，而不是新的部署。这正是此次更新的核心理念：基础设施变成了在请求时运行的代码，甚至环境本身也不例外。
发布现在只需修改代码
在启动时选择镜像，也解决了运行 Containers 时最棘手的问题之一：发布新版本。
Cloudflare Containers：重构以扩展代理沙箱
过去，更新镜像意味着更新整个应用程序。你需要设置宽限期，以便正在运行的实例能够逐步退出；定义百分比分流，以逐步转移流量；并调用我们的 API 推送新配置。在整个过程中，平台会决定替换哪些实例以及何时替换，而不管代理是否正处于任务执行过程中。
借助 durable_object 调度策略，完全不需要配置发布流程。Container 可以一直运行它启动时使用的镜像，直到你的代码将其停止。下一次该 Durable Object 启动 Container 时，它会使用你的代码所选择的镜像。这意味着，你想采用的任何发布策略都只需要几行代码即可实现：
例如，你可以：
通过对 Durable Object ID 进行哈希，在 5% 的新沙箱中对新的工具链进行金丝雀发布。
将活跃项目固定到当前镜像，这样代理的环境就不会在任务执行过程中被替换。
在自然检查点迁移工作区，例如下一次会话开始时，或创建快照之后。
通过更改未来启动时所选择的镜像来回滚。不需要推送配置，也不需要等待实例退出。
发布策略位于你的 Durable Object 代码中，与其余逻辑相邻；它可以像你所需的那样简单或复杂。
这些改进都源于对 Durable Object 的进一步深入利用。Durable Object 原本就负责管理工作区的身份、状态和生命周期。让它选择并控制自己的 Container，意味着你可以更好地控制每个实例及其发布流程。这也为调度器提供了更合适的 Container 启动位置：就在 Durable Object 已经运行的地方。这能让代理更快执行第一条命令。
更快执行第一条命令
此前，启动 Container 需要我们的全局控制平面解析应用程序配置、寻找容量并协调放置。对于面向整个应用的实例群组而言，这种模式运行良好，但它让部署机制介入了代理执行第一条命令的路径。
借助 durable_object 调度策略，需求从 Durable Object 发起。为其提供服务的 Containers 基础设施会首先在同一台机器上寻找容量；如果需要，则会在同一位置内扩大搜索范围。它还会优先选择本地存储中已经拥有该 Container 镜像或快照的主机，这样 Container 无需先下载镜像即可启动。
在 Container 到达主机之后，我们也减少了需要执行的工作。新的运行时不再从头启动一台新的虚拟机，而是恢复一台尚未分配、已经准备好的虚拟机。它会复用网络和文件系统设置，将重复操作批量处理，并且不再等待第一条命令不需要的服务。
这些变化结合起来，大幅缩短了从创建沙箱到在其中运行命令所需的时间。在 ComputeSDK 独立进行的 Burst TTI Benchmark 中，测试会并发启动 100 个沙箱，并从客户端测量达到可交互状态所需的时间：
启动测量：之前的调度路径；新的调度策略；改进幅度。
中位数：4.049 秒；648 毫秒；快 6.2 倍。
第 95 百分位：5.839 秒；910 毫秒；快 6.4 倍。
第 99 百分位：6.717 秒；1129 毫秒；快 5.9 倍。
新路径在突发负载下同样表现良好。在我们的初步突发测试中，单个账户在 5.387 秒内、跨越 6 个位置启动了 100,000 个 Containers。
从准备好的系统镜像开始
随着调度路径变得更快，准备镜像在剩余等待时间中所占的比重也越来越大。Container 启动前，其镜像必须位于主机上，并解压到文件系统中。如果这项工作要等到请求到达后才进行，代理就只能等待。
因此，我们推出了 cloudflare/debian-trixie：这是一个可直接使用的代理系统镜像，其中包含 Debian Trixie Slim 和 Node.js 24.20.0 LTS，代理可以在运行时配置自己的环境。
这意味着，你的代理可以启动一个 Linux 沙箱，而无需先创建 Dockerfile、构建镜像，或将镜像推送到 Cloudflare。沙箱运行后，代理可以使用 exec() 克隆代码仓库、安装软件包，并为任务配置环境。
由于该镜像由 Cloudflare 控制，我们可以在请求到达前，将其分发到符合条件的 Containers 主机并完成准备。启动时，用户无需等待下载或解压基础镜像。
保存工作区，稍后继续使用
快速启动仍然无法消除另一个等待环节：设置工作区。克隆代码仓库、安装依赖项和配置工具链所需的时间，可能远远超过启动 Container 本身的时间。代理工作时还会生成需要保留的文件。每次启动都重复设置会浪费时间，而丢失代理所做的修改也会让任务难以继续。
因此，我们正在为 Containers 添加原生文件系统快照功能，目前处于公开测试阶段。快照可以让代理在准备好的环境中开始任务，在任务暂停时保存工作区，并在会话恢复时还原这些文件。
快照支持两种有用的使用模式。
第一，一个工作区可以跨多个会话继续使用。对于编码代理而言，这可能意味着用户结束工作时保存工作区，第二天回来时再将其恢复。代码仓库、已安装的依赖项、构建缓存、配置和编辑内容都可以直接使用，无需重新构建环境。
第二，一个快照可以为多个沙箱提供共享检查点。由于快照是不可变且可复用的，多个 Containers 可以从同一个准备好的环境独立启动，并在此基础上进行各自的修改。
代理评测就是一个很好的例子。一次评测可能会使用不同的系统提示词、技能、模型或代理版本来运行同一项任务。为了比较结果，其他所有条件都必须保持不变：代码仓库、依赖项、工具和输入文件都要一致。一个快照可以从同一基线启动多个彼此隔离的环境，从而减少设置时间，并防止环境漂移影响结果。
快照也能与我们上文介绍的新系统镜像互相补充。代理可以从 cloudflare/debian-trixie 启动，使用 exec() 设置环境，然后将结果保存为快照。之后的沙箱便可以从该快照启动，代码仓库、依赖项和工具链都已经就绪。
随着快照通过新的 durable_object 提供
借助这种调度策略，Containers 可以充当持久化的代理工作区。工作暂停时，计算资源可以停止；之后，新 Container 可以从最新快照启动，接着完成未竟工作。
代理沙箱的 Durable Object 优势
更快的调度路径、运行时镜像选择以及文件系统快照，都源于同一个设计选择：进一步将 Durable Object 作为其所附加 Container 的控制器。
代理系统需要一个位于 Container 外部、可编程且有状态的环境，用于保存状态、存储凭据并控制沙箱的生命周期。你可以在那里运行代理，遵循 Anthropic 所描述的“将大脑与双手解耦”模式：当代理与其工作的沙箱分离时，即使沙箱和工具可以独立启动、停止、失败或被替换，代理仍能保持可用。或者，如果你在沙箱内部运行代理，外部环境则可以对其进行监督，并向用户报告进度。
这正是 Durable Object 与 Container 架构特别适合这一场景的原因。每个 Container 都附加到一个有状态的 Durable Object，而后者拥有自己的计算和存储，并在 Container 旁边运行。你可以在 Durable Object 中运行代理，把 Container 作为其工作区；也可以在 Container 中运行代理，再利用 Durable Object 对其进行监督。再加入用于轻量级隔离执行的 Dynamic Workers，应用就可以为每项任务选择所需的执行环境。
新的 durable_object 调度策略带来的变化是，Durable Object 现在可以直接控制其 Container，中间不再需要包装类。
exec() 直接运行在 Workers 运行时中；出站请求拦截、运行时镜像与实例选择，以及文件系统快照功能，都可以通过 ctx.container 使用。
你可以将这些功能与 Durable Object 存储、alarms、WebSockets、RPC 以及其余代码结合起来。
这使得 Container 成为 Durable Object 的计算扩展。Container 提供 Linux 环境，而你的 Durable Object 则保留沙箱的身份、状态、策略和生命周期。这种分工尤其适合以下几种模式：
代理可以在其 Linux 工作区休眠时保持可用。
代理循环可以运行在 Durable Object 中，由它维护会话状态、通过 WebSockets 与用户通信并调用模型。当需要 shell、编译器或开发服务器时，它可以唤醒 Container；在等待用户或模型期间，再停止这些计算资源，从而无需为闲置的 Linux 计算付费。
Durable Object 可以在其 Container 周围编程构建安全边界。
它可以记住用户授权使用的服务、代码仓库和操作，然后更新 Container 的 Outbound Request Handler，以注入新获准的凭据、执行新的策略或记录额外活动。这类似于 Cloudflare OS 所采用的 Gatekeeper 模式，只不过应用对象变成了每台代理计算机。
评测和强化学习系统可以从被测试环境外部监督每一次尝试。
Cloudflare Containers 重构，以扩展代理沙箱的规模
协调器会对基础工作区进行快照，并将其分叉为 N 次尝试，每次尝试都拥有各自的 Durable Object 和 Container。每个 Durable Object 负责运行尝试、监控运行过程，并保存结果，即使 Container 发生崩溃也不例外。协调器会对这些尝试进行评分，对表现最佳的尝试创建快照，然后再次从该快照分叉。
这些模式并不适合采用一种通用的生命周期。原生 API 允许你将 Container 与应用所需的 Durable Object 原语组合起来，同时在适用的地方继续使用更高级别的工具。你可以控制 Container 的生命周期、策略和状态。
Container 类和 Sandbox SDK 的变化
我们推出 Containers 时，特意将 Durable Object 隐藏在 Container 类之后。我们的目标是让沙箱给人熟悉的感觉，并符合开发者对其他平台的预期。Sandbox SDK 构建在这个类之上，并填补了一些实际存在的空白：当时，运行时还不具备原生命令执行、出站请求拦截或快照功能，因此我们在用户空间中实现了这些功能。
从那以后，代理工作区已经成为塑造 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。详情请参阅迁移指南。或者，也可以从你的代理开始：
将此项目的 Cloudflare Containers 集成迁移到 Durable Object Container API（this.ctx.container）以及“durable_object”调度策略。如果项目使用 @cloudflare/sandbox 0.x，则将其迁移到 Sandbox SDK 1.0。仅在确实有帮助的地方添加 Container 快照。保留现有行为和用户数据。
文档是唯一依据。请先阅读文档，按照与代码库各部分相匹配的指南执行，并验证已发布的软件包、镜像和 Wrangler 版本（在任何 URL 后追加 /index.md 以获取 Markdown）：
https://developers.cloudflare.com/containers/llms.txt
Cloudflare Containers 重构，以扩展代理沙箱的规模
- https://developers.cloudflare.com/containers/guides/migrate-to-durable-object-scheduling-policy/
- https://developers.cloudflare.com/containers/guides/migrate-to-durable-object-container-api/
- https://developers.cloudflare.com/containers/guides/snapshots/
- 如果项目使用 @cloudflare/sandbox：https://developers.cloudflare.com/sandbox/sdk/migrate/，以及该页面所映射到的、与本仓库调用对应的功能页面。
1. 检测每个 Container 应用和环境的起始点：由什么控制它（Container 类、Sandbox SDK 0.x 或 1.x，还是直接使用 ctx.container）、其调度策略是什么、是否已部署，以及其状态存储在哪里。一个仓库可能混用这些方式。请根据实际镜像和代码检查行为，而不只是查看文档。如果没有 Containers 集成，请说明这一点并停止。
2. 报告现有资源清单、你将采用的策略，以及该策略对容器文件、Durable Object 存储、正在运行的命令和开放连接的影响。仅当策略尚未确定时才停止并在编辑前询问我：也就是 Sandbox 应采用原地迁移还是并行部署，或者长生命周期容器的状态是否需要迁移。如果无法询问，请将报告写入 MIGRATION_PLAN.md，然后停止。
3. 在新分支上实施。以下是由我决定、而文档留给我决定的事项：
- 绝不要更改现有容器应用的 scheduling_policy。请遵循指南中的替换方式。
- 不要构建状态转移机制。保留现有容器的原位置，并将新容器路由到新的应用；每个逻辑容器使用一个绑定。每项路由决策只记录一次。对每个名称查询旧命名空间最多一次，或者预先写入已知名称，这样新名称就不会在旧命名空间中创建对象，回访用户也不会被错误路由。请解释状态转移需要做什么，并让我来决定。
- 继续将现有的文件级备份（Sandbox 目录备份、R2 或自定义备份）作为用户文件的事实来源。快照是增量措施：快照只能在创建它的镜像上恢复，因此部署新镜像会使用户无法访问仅存在于快照中的工作区。如果文件只存在于快照中，请标记这一点，并提出文件级备份方案或保留旧镜像的方式。明确处理已过期或不匹配的快照，绝不要静默恢复一个空工作区。
4. 验证：运行类型检查、测试和 wrangler dev。交付补丁、行为发生的变化、哪些检查已通过以及哪些检查需要已部署的环境，并提供按顺序排列的 staging、部署、切换、恢复和清理计划及命令。请明确说明哪些地方不支持回滚。在清理计划中注明：删除 Worker 不会删除其容器应用。
规则：
- 仅进行本地更改。不要运行 wrangler deploy、wrangler versions upload 或 deploy，也不要运行 wrangler containers delete；请提供这些命令，而不是执行它们，也不要更改生产环境路由或删除任何远程资源。
- 将任何对已部署应用的请求视为写操作，除非代码证明它不是：GET 请求可能会启动容器或更改存储状态。
- 只能停止由你启动的进程和容器。
- 如果文档彼此不一致，或者文档与代码不一致，不要猜测。指出该决策点，暂停那一部分工作，并继续处理其余部分。
开始吧
如今，大多数智能体的衡量标准，仍是它们在单次会话中能够完成什么。随着智能体开始负责需要持续数小时、数天乃至数周才能完成的项目，它们工作所在的环境也需要跟上这一变化。
我们的目标是让每个智能体都能为当前任务创建沙盒，在工作暂停时释放计算资源，并在项目继续时返回同一个工作空间。今天的更新让我们距离这样的沙盒更近了一步：它们应当像所服务的智能体一样具备可编程性、持久性，并且随时可以投入工作。
现在，所有用户都可以在公开测试版中使用新的 durable_object 调度策略。你可以借此了解更快的启动速度、文件系统快照和运行时配置将如何为你的智能体带来更多可能：
使用适用于 Containers 的新 Durable Object 调度策略。
利用文件系统快照保存和恢复文件。
从 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 的贡献也促成了这一项目。
来源与参考
收录于 2026-10-01