本文目錄

部署託管 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。