Cloudflare Containers 提速：面向 AI Agent 沙箱的运行时重构
Cloudflare Containers 正在面向 AI Agent 工作负载进行一次重要调整：应用代码可以在运行时为每个沙箱选择镜像和实例类型，容器启动速度显著提升，并开始支持文件系统快照公测。
这次变化的核心，是把沙箱的配置、调度和生命周期控制进一步交给 Durable Object，让每个 Agent 任务可以按需创建、快速启动、暂停与恢复自己的 Linux 工作空间。
为什么 Agent 沙箱需要不同的容器模型
传统容器平台通常围绕“应用部署”组织：镜像、计算资源和发布策略在部署时确定，然后作为一组应用配置统一管理。
但 Agent 工作空间的使用方式不同：
- 沙箱通常在任务开始时临时创建；
- 不同任务可能需要不同语言、工具链和依赖；
- 有的任务只运行几分钟，有的需要暂停后继续；
- 一些场景需要从固定文件系统状态开始；
- 长任务需要保存 Agent 生成的文件，以便之后恢复。
例如，代码 Agent 可能需要仓库、包管理器、编译器、测试运行器和开发服务器；评测任务需要可重复的初始环境；强化学习系统可能要大规模创建、评分并重置环境。
这些需求推动了 Cloudflare Containers 的新调度方式：durable_object scheduling policy。
运行时选择镜像和实例类型
此前，Cloudflare Containers 中影响 Agent 沙箱的两个关键决策——使用哪个镜像、分配多少计算资源——需要在部署时确定。每一种镜像和实例类型组合，都需要单独的 Containers 应用、Durable Object 命名空间和部署流程。
新策略改变了这一点。应用代码可以在任务到来后，再决定：
- 这个沙箱使用 Node.js、Python，还是其他工具链；
- 需要小规格还是大规格实例；
- 是否使用新的环境版本；
- 是否继续固定在旧镜像上。
也就是说，一个 Durable Object 类可以并行启动不同镜像、不同规格的沙箱。新增环境更多是代码变更，而不是创建新应用和重复部署。
发布策略也变成代码逻辑
过去更新镜像通常意味着更新整个应用配置，并设置灰度比例、宽限期和替换策略。平台负责决定哪些实例何时被替换，这对正在执行任务的 Agent 并不总是理想。
在新的 durable_object 调度策略下，已经运行的 Container 可以继续使用启动时的镜像，直到应用代码主动停止它。下一次 Durable Object 启动 Container 时，再根据代码选择新的镜像。
这让发布策略可以直接写在 Durable Object 逻辑里，例如：
- 对 5% 的新沙箱启用新工具链做金丝雀测试；
- 将活跃项目固定在当前镜像，避免任务中途环境变化；
- 在下一次会话或快照之后迁移工作空间；
- 通过改变未来启动时选择的镜像实现回滚。
这种方式把发布控制权放到更接近任务上下文的位置。
启动速度：中位数降至 648 毫秒
此前启动 Container 时，需要全局控制平面解析应用配置、查找容量并协调放置位置。这个模式适合应用级容器集群，但会把部署流程放在 Agent 执行第一条命令之前。
新策略让需求从 Durable Object 发起。调度系统会优先在同一台机器上寻找容量，如果需要再扩展到同一位置内的其他机器。同时，系统会优先选择本地已有目标镜像或快照的主机，避免启动前再下载。
运行时也做了优化：不再从零启动新的虚拟机，而是恢复一个已准备但尚未分配的虚拟机；同时复用网络和文件系统设置，批处理重复操作，并减少首条命令不需要等待的服务。
在 ComputeSDK 的独立 Burst TTI Benchmark 中，测试同时启动 100 个沙箱，并从客户端测量到可交互状态的时间：
| 启动指标 | 旧调度路径 | 新调度策略 | 改进 |
|---|---|---|---|
| 中位数 | 4.049 秒 | 648 毫秒 | 6.2 倍 |
| P95 | 5.839 秒 | 910 毫秒 | 6.4 倍 |
| P99 | 6.717 秒 | 1129 毫秒 | 5.9 倍 |
在 Cloudflare 的初步突发测试中，单个账户在 6 个位置内用 5.387 秒启动了 100,000 个 Containers。
文件系统快照进入公测
面向 Agent 沙箱的另一个关键能力是保存与恢复工作空间。Cloudflare Containers 现在支持文件系统快照公测，用于保存沙箱状态，并在之后恢复。
这对以下场景尤其重要：
- Agent 生成文件后需要暂停任务；
- 长时间运行的开发环境需要稍后继续；
- 评测或训练环境需要从固定状态恢复；
- 多轮会话需要保留中间产物。
Durable Object 成为沙箱控制器
Cloudflare Containers 的一个设计特点是：每个 Container 都关联一个 Durable Object。这个 Durable Object 具备稳定身份，可持久运行在容器旁边，用于管理生命周期、出站流量和状态。
此次更新继续强化这一模型。更多能力会进入原生 ctx.container API，使 Durable Object 不需要额外包装类，也能直接控制对应 Container。Cloudflare 还计划将这一模式延续到 Sandbox SDK 1.0。
对开发者意味着什么
这次更新的重点不是单纯提升容器启动速度，而是让沙箱基础设施更贴近 Agent 的实际执行方式：
- 沙箱可以在请求时按需决定环境；
- 发布、灰度和回滚可以由代码控制；
- 启动路径减少部署控制面的参与；
- 文件系统状态可以保存和恢复；
- Durable Object 继续承担工作空间身份与生命周期管理。
对于需要完整 Linux 工作空间的 AI Agent，Cloudflare Containers 正在从“提前部署好的容器应用”转向“由任务驱动、运行时编排的沙箱环境”。