背景与动机

传统 Cloudflare Containers 以应用部署为中心，镜像与计算资源在部署阶段固定，并由平台统一调度。然而 AI 代理（agent）的工作模式截然不同：它们需要在任务触发时即时创建隔离沙箱，任务决定所需的工具链、资源与初始文件系统，且沙箱可能短暂存在、按需休眠或数日后恢复。原有架构要求为每种环境组合预先部署独立应用，无法满足动态性与低延迟要求。

核心架构改进

Cloudflare 从底层重写了 Containers 基础设施，引入 durable_object 调度策略，将沙箱控制权移交应用代码，并实现多项提升：

  • 运行时定义环境：Durable Object 代码可在任务到达时选择镜像与实例类型，无需提前部署多个应用命名空间。
  • 启动速度提升：根据 ComputeSDK 独立基准，中位数启动时间从略超 4 秒降至 648 毫秒，提速超 6 倍；初步突发测试可在数秒内创建数十万个容器。
  • 文件系统快照：支持工作区状态的保存与恢复，目前已进入公开测试阶段。
  • 原生生命周期管理：每个容器仍绑定一个 Durable Object 作为持久化控制器，新版本将控制能力直接植入 ctx.container API，减少封装层。

调度与滚动更新代码化

旧模式中，更新镜像需平台级滚动配置，可能打断正在运行的代理任务。新架构下不再有平台滚动概念：容器持续运行原镜像直至代码停止；下次启动时由 Durable Object 代码决定镜像。这意味着金丝雀发布、环境固定、检查点迁移等策略均可通过几行代码实现，例如依据 Durable Object ID 哈希将 5% 新沙箱导向新工具链。

典型合作场景

Base44 利用该能力为每个生成式应用提供隔离开发环境；Kilo Code 为云代理会话按需拉起含特定仓库与工具的 workspace。类似模式也见于与 CodeBuddy、Devin 等代理平台的集成。

对读者的意义与技术解读

本站聚焦网络诊断与运维，本文虽属云厂商计算服务更新，但折射出两个值得关注的趋势：其一，基础设施即代码从部署时延伸到请求时，运维人员可通过编程精确控制隔离环境的规格与启停，对未来自动化故障排查沙箱、按需网络探测节点有借鉴价值；其二，调度策略强调将容器启动在 Durable Object 就近位置，隐含降低跨区协调延迟的意图，虽未直接涉及网络指标，但快速就绪的沙箱有助于在边缘执行 ping、traceroute 等诊断任务。读者可追踪其公开测试进展，评估是否适用于自身运维工具链。