Cloudflare Containers 为扩展 Agent 沙箱而重构：以运行时控制取代静态部署

据该公司称，为扩展 Agent 沙箱而重构的 Cloudflare Containers，如今启动速度提升至原来的六倍以上。9 月 30 日发布的更新还在公开测试中加入了运行时镜像选择、运行时实例规格调整和文件系统快照功能。

关键变化并不只是冷启动缩短。Cloudflare 已将每个沙箱的控制权移入 Durable Object——这是一种用于协调请求与持久化应用状态的有状态无服务器组件。这一决定挑战了塑造第一版 Cloudflare Containers 的静态部署模式。

开发者现在可以让 Agent 为每项任务选择所需环境。编码任务可能需要更大的实例和完整的 Linux 工具链；较小的自动化任务则可以采用更轻量的环境。当工作暂停时，系统可以保存文件系统、停止计算资源，并在稍后恢复工作区。

这让 Cloudflare 更直接地进入竞争激烈的 Agent 基础设施市场。E2B、Modal、Daytona、Vercel 以及超大规模云服务商，已经针对隔离执行提供了不同方案。Cloudflare 的主张是：一个可全球寻址的控制器、隔离的 Linux 工作区和持久状态，应作为一个可编程单元协同运行。

这一架构似乎适用于编码 Agent、评估及长时间运行的工作流。不过，启动速度提升六倍的说法来自 Cloudflare，快照功能仍处于公开测试阶段，而且多项运行限制同样重要。真正的考验在于，团队能否获得可靠控制，同时又不承受过多生命周期管理复杂度。

为扩展 Agent 沙箱而重构的 Cloudflare Containers 改变了控制平面

Cloudflare 的核心变化，是将沙箱配置从部署时移至 Agent 启动任务的时刻。

在此前的模式下，应用通常会在部署配置中声明一种容器镜像和实例类型。修改任一设置都会触发应用级发布。这种模式适合可预测的服务，但 Agent 产生的工作负载会因请求而异。

代码修复 Agent 可能需要代码仓库、编译器、包管理器、浏览器和测试套件。评估工作器可能需要输入受到严格控制的、干净且可重复的环境。另一项任务或许只需要一个内存受限、无法访问互联网的短脚本。

Cloudflare 新推出的 durable_object 调度策略，让应用代码能在运行时作出这些选择。负责控制的 Durable Object 调用 ctx.container.start()，并为该任务提供适当的镜像、快照和实例配置。

可用的预定义规格包括 lite 以及四种 standard 配置。开发者也可以在平台限制范围内传入自定义的 CPU、内存和磁盘值。运行时调度策略以每个沙箱单独决策，取代了统一选定的单一配置。

镜像选择也遵循同一模式。开发者通过 Cloudflare 的命令行部署工具 Wrangler 声明具名镜像。平台会准备不可变引用，而 Durable Object 会在启动沙箱时选择其中之一。

这种安排使一个应用可以支持多种 Agent 角色，而无需为每种角色单独部署一个容器应用。协调器可以将轻量级研究任务导向一种镜像，随后将构建任务分配给资源更充足的另一种镜像。

Cloudflare 还推出了 cloudflare/debian-trixie，这是一个包含 Node.js 的托管 Debian 镜像。Agent 可以以此为基础，通过 exec() 安装工具，并将生成的工作区保留为快照。

根据 Cloudflare 的沙箱公告，新的调度路径使 Containers 的启动速度提升至原来的六倍以上。该公司表示，它移除了此前位于 Durable Object 与容器运行时之间的多个协调步骤。

这一说法需要谨慎解读。Cloudflare 尚未展示独立基准测试，以比较具有代表性的镜像、区域或工作负载类型。容器就绪时间还取决于镜像大小、入口点行为、容量以及应用层健康检查。

Cloudflare 自身的架构文档称，冷启动通常在一至三秒内完成。文档也指出，启动时间会随镜像及其初始化工作而变化。更快的调度器无法消除镜像内部造成的延迟。

平台会在进程未必已准备好接收流量前暴露 running 属性。开发者在发送首个请求前，仍必须检查端口是否就绪。对于 Agent 而言，“容器已启动”与“工作区已可开展有效工作”仍是不同的衡量标准。

即使存在这些限定条件，运行时配置仍改变了产品的运行模式。Cloudflare Containers 不再只是 Agent 恰好会使用的已部署服务；它们成为 Agent 控制器可围绕单项任务组装、调整规格、停止和重建的资源。

更快的 Agent 沙箱给静态部署模式带来压力

Agent 工作负载需要的是能在任务之间改变形态的基础设施，而不只是高效运行单一镜像的基础设施。

传统容器平台假定开发者在部署前已知应用形态。团队选择镜像、资源分配、网络策略和扩缩容配置，随后调度器创建在这些属性上大致相同的副本。

Agent 系统打破了这一假设。它们的下一步行动取决于用户请求、模型决策、工具结果，以及先前工作留下的状态。同一产品中的两个连续任务，可能需要不同的操作系统、依赖项、资源限制和网络权限。

这种可变性给围绕静态应用配置构建的提供商带来压力。团队当然仍可部署多个服务并在其间路由工作；但每增加一种工作负载类型，就会增加一个部署单元、发布路径、容量决策和配置漂移来源。

Cloudflare 的运行时模式将部分决策移入应用代码。Agent 控制器可以在检查任务后选择沙箱镜像和实例类型，也可以决定沙箱是否获得互联网访问权限，或是否从已存储的快照启动。

因此，主要对手并非某一家具名厂商，而是将应用内所有沙箱视为同一预定义服务副本的静态部署模式。

E2B、Modal、Daytona 和 Vercel 已通过各自的抽象方式进入这一市场。一些产品强调对开发者友好的沙箱 API；另一些则围绕函数、虚拟机、工作区或更广泛的云编排构建。直接运行 Kubernetes 或 Firecracker 的团队拥有更多控制权，但也需承担更多基础设施责任。

Cloudflare 的差异化在于每个容器与其 Durable Object 之间的关系。Durable Object 在 Linux 环境之外提供稳定身份、应用代码、存储、闹钟和协调功能；容器则为需要传统操作系统的工具提供隔离计算资源。

当 Linux 工作区休眠时，Agent 的决策循环仍可持续运行。它可以与用户通信、保留授权状态并调用模型，而无需持续运行更重的沙箱。当编译器或开发服务器变得必要时，控制器会唤醒容器。

Cloudflare 将这种分离描述为让 Agent 的“脑”与“手”相互独立。控制器保留意图和状态，而沙箱则执行可能失败、停止或需要更换的命令。

这种分离同时带来安全和运行层面的益处。Durable Object 可以将凭据保留在容器之外，并中介出站请求。Agent 不一定需要直接访问完成已获授权服务调用所需的全部密钥。

Cloudflare 此前曾指出，动态生成的 Agent 代码需要隔离执行环境。其早期的代码沙箱模型专注于轻量级 Dynamic Workers，适用于不需要完整 Linux 系统的任务。

Containers 覆盖了这一划分中更重的一侧。它们支持包管理器、原生二进制文件、代码仓库、编译器、终端和开发服务器。Dynamic Workers 则可以以更受限的运行时处理较小的代码执行任务。

这形成了一种分层执行策略。控制器可以为简短的 API 工作流使用轻量级沙箱，并将需要 Linux 的工作留给容器。运行时选择之所以重要，是因为让每项任务都运行在完整容器中会浪费启动时间和资源。

这种压力并不限于沙箱供应商。内部平台团队往往维护预热开发环境池，以掩盖配置延迟。更快的冷启动和可恢复的文件系统，削弱了维持大量空闲资源池的必要性。

不过，Cloudflare 并未消除编排，而是将编排迁移至 Durable Object 及其应用代码之中。团队仍须设计准入规则、并发控制、重试行为、授权、清理和可观测性。

胜出的模式不会是报告最低单独启动数值的平台，而是能将 Agent 决策至经验证任务结果的总耗时降至最低的模式。

这包括镜像准备、代码仓库访问、依赖恢复、命令执行、网络延迟和拆除，也包括由失败会话或丢失工作造成的人为延误。

对于比较不同方案的工程团队而言，相关的基准测试应复现其完整工作流。合成的空容器测试无法代表大型代码仓库、包安装、浏览器启动或测试套件。

这些评估还会产生团队需要保留的设计知识。可搜索的工程知识库可以将基准假设、安全决策和迁移发现与实现一并保存。

Durable Objects 将 Containers 转化为任务专用计算资源

此次发布背后的机制，是一个有状态控制器：它将容器视为可替换的计算资源，而非永久的应用状态。

每个 Cloudflare Container 都关联一个 Durable Object。请求会先到达 Worker，再经由该对象路由至容器。Durable Object 可以寻址特定工作区，并保留与其身份关联的状态。

借助新的 API，开发者可以直接扩展 DurableObject，并通过 this.ctx.container 访问附加容器。这移除了 Cloudflare 最初为使 Containers 类似传统沙箱服务而采用的包装类。

控制器可以启动容器、执行命令、检查容器状态、监控退出、发送进程信号、设置非活动超时，以及销毁实例。它还能将这些控制能力与 Durable Object 存储、闹钟、WebSockets 和远程过程调用结合使用。

设想一个编程智能体响应一份 bug 报告。Durable Object 可以存储会话标识符、已批准的代码仓库、用户权限和当前任务阶段。随后，它可以选择包含相应语言工具链的镜像，并启动合适的实例。

容器会克隆代码仓库、安装依赖、运行测试套件并编辑文件。与此同时，Durable Object 可以通过 WebSocket 发送进度，并在容器之外记录检查点。

如果容器进程退出，控制器仍会保留会话的身份和元数据。它可以检查失败原因、从已知状态重启，或报告问题，而不会丢失整个交互。

Cloudflare 在 Firecracker microVM 中运行每个容器；这是一种拥有独立内核和网络的轻量级虚拟机。客户镜像则作为 Linux 容器运行在该虚拟机内部。

该平台的容器架构说明，其他 Cloudflare 工作负载不会共享该内核。这种隔离至关重要，因为由智能体生成的命令不应直接在处理受信任用户数据的应用程序中执行。

部署位置仍然是动态的。Cloudflare 会在所需镜像可用的合格容量中进行选择，路由和启动速度都会影响具体位置。Durable Object 与容器并不保证运行在同一地点。

这一限制对于延迟敏感型控制循环很重要。一个可全局寻址的身份，并不意味着每项操作都会在用户、模型提供商或沙箱旁边执行。团队应在预期区域内测量完整请求路径。

容量也可能在不同会话之间迁移。如果容器停止后稍后重启，Cloudflare 可能会将替代实例部署到其他位置。应用程序不能将某台机器的本地身份视为永久不变。

Durable Object 成为连续性层。它存储查找、重建或恢复工作区所需的信息。Linux 实例则成为一种执行资源，在空闲时可以消失。

这种架构同样支持分支型工作负载。协调器可以从同一准备完成的基线启动多个独立尝试。每次尝试都可以测试不同模型、系统提示词、技能集或修复策略。

控制器可以监控这些运行、比较结果，并保留首选输出。强化学习系统也可采用类似模式，创建受控环境、评估结果，并在每次试验之间重置状态。

运行时实例规格进一步强化了这一模型。控制器可以为构建任务分配更多资源，并为较轻量的命令缩减资源。静态的全应用规格会迫使团队为最常见的最大任务进行配置，或维护彼此独立的部署。

但可编程性也将责任转移给应用程序。控制器必须防止模型无限制地选择资源。它应将智能体请求映射到已批准的策略，而不是把任意模型输出直接传入基础设施 API。

同一原则也适用于镜像。允许在运行时选择，不代表允许智能体执行任何未经审核的镜像。Cloudflare 要求使用已声明且按摘要固定的镜像引用，这有助于保持部署的可复现性。

团队仍应维护镜像允许列表、扫描依赖项、限制出站访问，并将凭据与客户环境隔离。沙箱能够降低暴露风险，但并不能定义完整的安全策略。

在运维层面，Durable Object 应始终是生命周期状态的唯一事实来源。Cloudflare 的直接 API 提供控制能力，但应用程序必须自行决定任务何时可恢复、已放弃、已完成，或可安全重试。

这才是更快智能体沙箱背后的真正机制。调度器改进固然重要，但持久的变化是一个能够超越任何单一容器进程而存在的显式控制平面。

文件系统快照保留文件，而非运行中的会话

快照可减少重复的环境准备工作，但它们是不可变的文件系统检查点，而不是完整的暂停与恢复镜像。

Cloudflare 的原生文件系统快照目前通过 durable_object 调度策略以公开测试版形式提供。运行中的容器调用 snapshotContainer()，即可在某一时刻捕获其可写根文件系统。

返回的句柄包含标识符、大小和可选名称。开发者必须保存该句柄，通常存入 Durable Object 存储中，因为 Worker API 不提供列出快照的命令。

后续容器可以从已存储的句柄启动。这样一来，即使原始计算资源停止，编程工作区仍可恢复。代码仓库、已安装依赖、构建缓存、配置文件和编辑内容，都能随恢复后的文件系统一同返回。

这一模型解决了智能体基础设施中的常见错配。启动一个空沙箱可能只需数秒，而准备一个实用的开发环境却可能需要数分钟。重复安装依赖，可能会主导用户实际感受到的启动耗时。

快照还为评估提供了稳定基线。团队可以准备一个代码仓库和工具链，将其保存，并从同一检查点启动多个实验。恢复后，每个沙箱都会获得独立的可写环境。

这能减少不同尝试之间的环境漂移。如果两个模型版本看到不同的依赖状态，测试结果就更难比较。共享的不可变检查点有助于隔离待评估变量。

这一功能还支持更长期的项目。用户离开时，智能体可以保存工作区、停止计算资源；用户返回时，再恢复文件。这将文件系统连续性与持续资源消耗分离开来。

不过，“快照”一词可能暗示 Cloudflare 当前实际保留的内容更多。快照文档指出，系统会捕获完整的容器文件系统，但不包括内存、运行中的进程或单独挂载的文件系统。

恢复后的容器会重新运行其入口点。内存中的构建过程、活动调试器、终端进程或开发服务器，都不会从停止时的精确指令位置继续执行。应用程序必须重建这些进程。

快照还与创建它们时所使用的镜像版本绑定。开发者不能将其恢复到不同镜像中。当基础镜像变更时，团队必须创建新的兼容快照。

每个快照句柄都带有隐含的 30 天存活期。恢复快照会刷新这段期限，但开发者目前无法配置其他保留时间。若没有外部保存方案，这一限制使快照不适合作为无限期归档。

快照是不可变的。恢复后所做的更改，如需保留，团队必须再创建一个快照。因此，应用程序需要制定检查点策略，在恢复价值与存储、延迟及运维复杂性之间取得平衡。

公开测试版状态也带来了额外的谨慎理由。生产团队应在中断、并发访问、镜像更新和区域部署变化的条件下，验证快照的创建与恢复。

他们还应测试故障边界。如果容器在创建检查点期间停止，应用程序需要明确记录哪个快照仍然有效。如果某项任务改变了外部系统，恢复其文件系统并不会撤销该外部操作。

这一差异对于自主智能体尤为重要。回滚可以恢复本地文件，却可能让拉取请求、数据库更新、电子邮件或云资源保持不变。盲目重试任务可能会重复执行不可逆操作。

因此，控制器需要在沙箱之外维护任务账本。它应记录已批准的操作、外部副作用和已完成的检查点。仅靠文件系统无法呈现智能体工作的完整事实。

安全团队还需要审查快照会保留哪些内容。代码仓库、生成的代码、日志、缓存的软件包和临时凭据都可能进入可写文件系统。快照保存敏感材料的时间可能比运行会话更长。

Cloudflare 提供出站请求拦截和外部凭据处理，可减少客户环境中的密钥暴露。开发者仍应验证工具不会将令牌复制到配置文件、Shell 历史记录或软件包缓存中。

该公司的迁移方向还带来了另一个实际问题。包括更快路径和原生快照在内的新功能，都要求直接访问 ctx.container。Cloudflare 表示，将在 2026 年 12 月 31 日前继续维护较旧的 Container 和旧版 Sandbox 类。

据该公司称，现有部署在该日期后仍会继续运行，但这些类将不再获得更新。希望使用新功能的团队必须将其生命周期逻辑迁移至直接 Durable Object API。

这是一项重大的架构变更，而非每支团队都能安全启用的开关。直接 API 暴露了更多系统的身份和协调模型，也要求开发者明确承担此前由基类隐藏的行为责任。

Cloudflare 正将 Sandbox SDK 1.0 转变为一组实用工具，而不是一个超类。这应让团队能够将便捷的辅助工具与原生生命周期控制相结合。它也确认了 Cloudflare 希望由 Durable Object 而非 SDK 包装器来定义核心抽象。

接下来的考验是可靠性、采用情况与竞争回应

只有当真实的智能体系统将这些新控制能力转化为更低的任务延迟和可靠恢复时，此次发布才会产生实质影响。

首个值得关注的信号，是完整工作负载下的生产性能。Cloudflare 所称的六倍提升针对其启动路径，但开发者需要从任务分发到应用程序就绪的全程测量数据。

有价值的测试应覆盖小型和大型镜像、多个区域、恢复后的快照、全新文件系统以及不同实例规格。它们应区分调度器延迟、镜像初始化、依赖恢复和服务就绪时间。

如果这些测量显示端到端延迟持续缩短，Cloudflare 的论点就会更有说服力。若一旦代码仓库和开发服务器进入工作流，这些收益便消失，启动速度就只是更狭窄的优势。

第二个信号，是公开测试版进入高要求工作负载后的快照可靠性。团队应关注恢复失败率、检查点耗时、存储行为、镜像升级流程，以及中断会话后的恢复能力。

编程智能体的成功采用将尤其具有启示意义。Cloudflare 已将 Base44 和 Kilo Code 列为使用隔离环境进行智能体工作的客户。Cloudflare 此前的材料还将 Figma Make 列为用于执行不受信任代码的 Containers 客户。

这些客户案例表明存在真实使用场景，但并未提供对比性能数据。独立工程报告的分量将高于发布宣传中的客户证言。

大型代码仓库下的快照行为同样值得关注。软件包目录和构建输出可能迅速膨胀。团队需要了解，随着工作区在反复检查点之间不断增长，快照是否仍能保持快速且易于管理。

如果 Cloudflare 扩展快照保留控制、列表 API、可观测性或跨版本迁移工具，这将表明该功能正在迈向更广泛的生产使用。若限制长期存在，则会削弱长期运行工作区的叙事。

第三个信号，是竞争对手将如何回应 Cloudflare 结合控制器与沙箱的模型。智能体沙箱市场既包括专注型供应商，也包括更广泛的计算平台，各自具备不同优势。

E2B 强调为 agent 专门打造的云环境。Modal 将沙箱计算连接到更大的无服务器平台。Daytona 聚焦开发环境，而 Vercel 则将沙箱能力整合到其应用平台中。

超大规模云通过虚拟机、容器、身份系统和编排服务，为团队提供广泛的控制能力。但其不足之处往往在于：要将这些组件组装成一款低延迟 agent 产品，需要投入大量工程工作。

Cloudflare 押注于 Durable Objects 能够压缩这一组装过程。身份、状态、通信、策略和生命周期都可以与沙箱控制器并置。其全球网络则提供路由和预置容量。

竞争对手可能会以多种形式应对。其他提供商可能增加更强的有状态协调能力、更灵活的快照、更细粒度的运行时规格，或更紧密的凭证调解机制。它们也可能发布基准测试，以质疑 Cloudflare 的启动速度主张。

如果竞争对手趋向采用外部有状态控制器，即使客户最终选择了其他平台，Cloudflare 的架构也会显得颇具前瞻性。如果开发者更偏好简单的托管沙箱 API，Durable Object 模型则可能显得过于偏基础设施导向。

采用情况在一定程度上取决于应用团队希望获得多少控制权。一家构建编程 agent 的初创公司可能重视直接的生命周期编程；而一个仅需增加代码执行功能的团队，可能更倾向于使用决策更少、观点更明确的服务。

Cloudflare 必须同时服务这两类用户，同时不能掩盖使其平台与众不同的能力。新的 SDK 方向试图通过围绕原生 API 提供实用工具，而不是再引入一层强制性抽象，来平衡两者需求。

安全事件将是另一项决定性衡量标准。Agent 沙箱会执行不受信任或不可预测的命令，通常具备网络访问能力，并且接近专有代码。一个会泄露凭证或允许跨租户访问的快速环境，将无法实现其核心目的。

Cloudflare 使用 Firecracker microVMs，在工作负载之间提供内核级隔离。不过，安全运行还取决于镜像卫生、出站控制、授权、密钥处理、日志记录和应用策略。

团队应将这一模型视为分层隔离，而不是将其当作信任 agent 生成代码的理由。Durable Object 可以成为策略执行点，但开发者仍必须实现并测试这些策略。

此次发布还引出了一个有关 agent 产品架构的更广泛问题：agent 应该运行在工作空间之外，并将其视为可替换工具，还是应该在自己的计算机内部运行？

Cloudflare 同时支持两种模式。在 Durable Object 中运行 agent，可在计算资源休眠时保持通信和状态可用；在容器内部运行 agent，则提供熟悉的 Linux 进程模型，同时由对象从外部进行监管。

第一种模式明确划分了“大脑”和“手”的边界。第二种模式可能简化那些依赖本地文件和进程的现有 agent 运行时。实际采用情况将显示，开发者认为哪种模型更容易运维。

为扩展 agent 沙箱而重建的 Cloudflare Containers，代表的远不只是冷启动改进。它将运行时选择、文件系统连续性和生命周期策略转变为由持久状态控制的应用级决策。

这一转变会给静态部署和过于简单的沙箱 API 带来压力，同时也让开发者有更多机会制造隐蔽故障。运行时灵活性需要严格的策略、持久化的任务记录，以及衡量有效就绪状态而非空进程的基准测试。

评估此次发布的团队应从一个真实工作负载开始。测量全新启动、恢复后启动、依赖项就绪情况、故障恢复和完整任务完成情况。随后测试控制器是否能在容器丢失后继续正常工作，而不会重复执行外部操作。

未来几个月将揭示 Cloudflare 的公开测试版快照是否持续可靠、客户是否会发布独立的延迟测试结果，以及竞争对手是否会采用类似的有状态控制机制。这些信号将决定该架构会成为长时间运行 agent 的常见基础，还是在日益拥挤的市场中成为又一个专用选项。