本文目录

部署托管 Durable Objects 的 Worker 之后，流量还在跑，实例却可能继续执行上一版代码长达约五分钟。多半是默认延迟更新在起作用。自 2026-10-30 起，Cloudflare 的 Durable Objects 文档与 Changelog 把默认代码更新策略设为 deferred，默认 max_delay 为 300 秒。活跃对象可以一直用当前版本，直到休眠——或延迟到期、运行时重置并装上新代码。

在 Durable Objects 上跑 AI Agent、长会话或 Hibernation WebSocket 时，关键是搞清部署何时真正换码。规则以 2026 年 10 月 30 日的 Cloudflare Changelog，以及同日最后更新的 Durable Objects 代码更新文档为准。Wrangler、渐进放量与 REST Create deployment 的每条路径我们暂时还没有都测过；用过可通过底部站长联系方式反馈。

站内相关：Cloudflare 已修复 Workers AI 上 GLM-5.3 的跨请求 KV 缓存暴露、AWS 开源 Infinity：面向高并发 Agent 的研究型运行时、Cursor Agent SDK 发布：文件夹定义、Eval 与部署、同一个模型换套 coding harness，通过率几乎不动，账单为什么差这么多？。

2026-10-30 起默认改了什么

在这套默认之前，不少团队会把「部署完成」读成「每个 Durable Object 实例都已切完」。Changelog 与 Durable Objects 文档给出的新基线正好相反：

  • 默认模式： deferred
  • 默认延迟： 省略字段时 max_delay ＝ 300 秒（5 分钟）
  • 允许范围： 0–86400 秒（24 小时）；API 接受处可到毫秒精度

活跃的 Durable Object 可以继续跑当前代码，直到休眠或触及 max_delay。延迟到期时若仍活跃，运行时会重置对象并加载新代码。休眠之后，唤醒它的下一次请求使用新版本。

所以 CI 里部署已经绿了，粘着的 Agent 会话、alarm 处理或 WebSocket 仍可能像昨天的构建一样跑上几分钟。

immediate 与 deferred

实务上就两种模式：

模式行为（按 Durable Objects 文档）
immediate立刻重置并采用新代码，不等休眠。
deferred尽力等待休眠，上限是 max_delay。

还有紧凑写法：{ "mode": "deferred", "max_delay": 0 } 实质立刻应用。意图若是「现在就重置」，显式 immediate 半年后再看也不费解。

Hibernation WebSocket。 Changelog 写明：使用 Hibernation API 的 WebSocket，在对象休眠并随后采纳新码时可以保留连接。这对 Agent UI、长聊天套接字很有用——也正因为如此，不能把「连接还在」读成「代码已经换完」。我们暂时还没有针对 2026-10-30 默认把每条 Hibernation WebSocket 路径都测过；以 Changelog 原文为准。

Wrangler：durable_objects.code_update_strategy

在 wrangler.toml／Wrangler 配置里，把策略写在 Durable Object bindings 同级（也包括只有 ctx.exports、没有显式 bindings 列表的 Worker）：

toml
[durable_objects]
# 示意形状 — 以当前 Wrangler schema 字段名为准
code_update_strategy = { mode = "deferred", max_delay = 300 }

具体 TOML／JSON 写法随 Wrangler 代际可能不同；Durable Objects 文档里的字段名是 durable_objects.code_update_strategy（mode 与可选 max_delay）。省略该块的部署会回到平台默认 { deferred, 300 }——而且这次选择不会自动继承到下一次部署。每次省略都会重新落回默认。

CLI 优先于配置，且 deferred 必须带时长

Wrangler CLI 标志适用于 wrangler deploy、versions deploy 与 rollback：

  • --durable-objects-code-update-mode immediate
  • --durable-objects-code-update-mode deferred <duration>——例如 deferred 30s

按 Durable Objects 文档（不只看 Changelog 示例）：CLI 上模式为 deferred 时必须带时长。优先级为：

  1. CLI 标志
  2. Wrangler 配置（durable_objects.code_update_strategy）
  3. 平台默认 { deferred, 300 }

Changelog 示例常突出 immediate。运维侧仍以 文档规则——CLI 写 deferred 必须带 duration——为硬约束。

连续部署与独立计时器

同一对象保持活跃时连续发版 A、B、C，每次部署都会为该对象各开一个独立的 max_delay 计时器。最先到期的计时器触发时，对象采用当时已经部署的最新版本——不一定是启动该计时器的那一版。中间若有 immediate 部署，会立刻强制更新，并可跳过中间版本。

对 AI Agent 集群的含义：快速连发不等于保证「A→B→C」三次软着陆。计时器在竞速；第一个到期时在场的最新代码胜出（除非已经被 immediate 提前切开）。

渐进部署（gradual）

渐进放量调高某个 Worker 版本流量百分比时，deferred／immediate 机制只作用于新划入该版本的对象。已经在该版本上的对象不会因为百分比上调再被延迟一次。可能在 deferred 窗口与 gradual 期间并存的版本之间，Durable Object 状态与协议仍需前后兼容。

REST Create deployment：只写不回显

Create deployment 请求体可以带 code_update_strategy。该字段属于 deployment，不属于 Worker version 资源，且为 write-only：Create／get／list 响应不会回显策略。去往返 deployment JSON 找「已保存的模式」不会出现在响应里——若需要非默认策略，下次 Create 再写一遍。

作用范围：哪些 class 共用策略

同一 Worker 导出的全部 Durable Object class 在该次部署共用一条策略——包括只经 ctx.exports 暴露的 class。经 script_name 引用其他 Worker 的 class，由被引用 Worker 自己的策略控制。跨脚本绑定不会悄悄沿用调用方的部署策略。

尽力而为——以及策略管不到的地方

Durable Objects 文档把 deferred 明确写成尽力而为（best effort）：

  • 不保证切换前每项进行中的操作都干净收尾。
  • 不保证对象跑满整个 max_delay（平台事件仍可能提前重置）。
  • 策略不会推迟与发布新 Worker 版本无关的重启——例如 Workers runtime 更新。

因此 deferred 只是尽力而为：不保证零中断，不保证任务跑完，也不等于省费用。我们暂时还没有在 2026-10-30 默认下测量中断率或账单影响。

Agent／WebSocket 运维清单

  1. 默认从哪天起。 自 2026-10-30 起，除非配置或 CLI 另有说明，按 deferred + 300 秒预期。
  2. 意图。 必须立刻切的热修 → immediate（或仅在有意时用 deferred + max_delay: 0）。可以等休眠 → deferred 并显式写 max_delay。
  3. CLI deferred 必带时长。 如 deferred 30s——不带 duration 的裸 deferred 不符合文档规则。
  4. 每次部署重新声明策略。 省略即回平台默认；跨部署不继承。
  5. 连续部署。 独立计时器；最先到期采用当时最新已部署版本。
  6. gradual ≠ 全员再延迟。 进入延迟路径的只有新划入该版本的对象。
  7. REST 不回显。 Create deployment 上的 code_update_strategy 只写不回。
  8. Hibernation WebSocket。 连接可能跨过休眠与换码仍存活；应用协议仍需单独确认。我们暂时还没有测过全部边角。
  9. 兼容性。 在可能重叠的版本之间，Durable Object 存储与消息格式保持兼容。
  10. 相关的 Workers AI 话题。 Workers AI 面上的缓存／隔离问题是另一篇——见上文 GLM-5.3 KV 缓存链接。

小结

Durable Objects 在部署成功之后，仍可能最多约五分钟继续提供旧代码，因为自 2026-10-30 起，平台基线就是 deferred 外加默认 300 秒 的 max_delay。重置才是正确产品行为时用 immediate；可以等休眠则保留 deferred——deferred 只是尽力而为，不保证任务完成或持续可用。改生产部署前，以 Durable Objects 文档核对现行 CLI 与配置 schema。