Cloudflare Durable Objects 用於 AI：狀態與恢復

Cloudflare Durable Objects 用於 AI，適合助手需要穩定位置來協調工作階段或任務的場景。困難的設計問題在於這些狀態意味著什麼。聊天記錄、執行中的任務和已批准的業務變更，不應僅因為屬於同一助手就變成同一條記錄。

使用 Durable Objects 協調身分明確的應用狀態，並區分對話歷史、任務狀態和外部業務結果。中斷後根據持久記錄重建工作，重連時檢查目前權限，將模型上下文與權威狀態分開。持久儲存是構建模組，並非完整恢復策略。

設想維護助手正在準備服務報告。它收集筆記、起草建議，然後等待主管。等待期間瀏覽器可能斷開，主管可能在其他地方開啟任務，而底層裝置記錄也可能在批准前改變。

本文為這種情況解釋建議的狀態設計，不聲稱有必要保留每條對話訊息，也不認為物件身分會自動匹配組織的存取邊界。

Cloudflare Durable Objects 用於 AI 需要身分模型

Cloudflare 將 Durable Objects 描述為協調有狀態應用的平臺。為 AI 功能分配物件前，先定義它代表什麼：對話、已接受任務、共享資源，還是其他範圍明確的單元。

每個對話一個物件，可能方便互動，但服務報告可能需要能夠延續到對話之外的身分。如果多位同事共同處理報告，將報告完全繫結到第一個瀏覽器工作階段，會使之後的存取和交接難以理解。

根據可信應用上下文推導路由識別碼。呼叫者猜到另一任務的識別碼，不應因此獲得內容存取權限。物件路由與應用授權是不同責任。

將權威事實保留在對話摘要之外

模型生成的摘要可以幫助助手繼續對話，但不應成為主管已批准建議的唯一證據。應將批准事件關聯到報告版本與已認證複核者。

同樣，應明確保留目前任務階段。“等待複核”應是應用記錄的狀態，而不是助手記得曾經說過的一句話。後續模型回應不能因為聊天記錄暗示工作大概已完成，就編造狀態轉換。

Cloudflare 的對話狀態與記憶指南 區分了持久對話歷史與提供給模型的上下文。這是重要的實現區別：儲存的資訊不必全部放進下一條提示詞。

對於報告，助手可以接收精簡任務摘要及選定的允許證據。應用則可單獨保留權威來源與事件記錄，分別採用自己的存取和保留規則。

設計能夠拒絕過時決定的狀態轉換

為每份可複核報告分配版本。主管的批准應標識這個版本。如果複核頁面開啟後出現新筆記，應用必須決定它們是否讓建議失效，還是可以分開處理。

操作到達時檢查目前任務狀態。過時標籤頁不應批准已取消報告，重複點擊也不應建立第二次業務操作。對於已接受操作，應返回已經確認的結果。

這些是應用規則。狀態平臺提供實現位置，卻不能決定維護筆記變化是否具有商業意義，也不能決定哪位主管擁有權限。

根據記錄恢復，而不是依靠程序記憶體

將記憶體值視為臨時工作狀態。記錄恢復任務所需事實，並識別已經發出的外部請求。重啟後，應無需將整段對話重新交給模型，就能重建目前階段。

對於維護報告，保留來源版本、草稿版本、批准狀態和目標操作編號。如果目標接受了報告卻丟失回應，這個編號比再次生成解釋更有用。

區分從未開始的工作與結果未知的工作。只有前者顯然可以安全啟動。對於後者，在再次提交前，應檢查目標系統，或使用其支援的防重複機制。

在有意義的階段之間中斷應用，測試恢復。然後讓另一位工程師根據儲存證據識別任務並確定下一步。這能暴露普通成功路徑演示無法發現的狀態缺失。

按目前權限重新連線

同事重連時，按照應用工作階段規則重新認證，並檢查目前任務權限。不要假定持有舊對話識別碼就能無限期保留存取。

載入任務已記錄狀態和觀察時間，說明系統是在等待、處理、失敗，還是等待核對。如果無法確定進展，應展示不確定性，而不是讓模型提供令人安心的答案。

決定哪些記憶有用，哪些應過期

對話歷史、來源文件和維運證據可能有不同保留需求。加入自動記憶前，應先定義這些需求。永久保留每項輸入，會增加後續刪除與權限複核難度。

區分可重複使用的偏好與任務事實。偏好的報告格式可能跨工作階段仍有用，臨時存取權杖或已撤回客戶細節則不應成為助手永久記憶。

來源記錄被刪除或存取被撤銷時，也要考慮衍生狀態。摘要可能包含與來源相同的敏感事實。應用需要為已存草稿、檢索段落和面向模型的上下文制定策略。

關於檢索型記憶，我們的 RAG 資料時效指南 介紹索引中的更新與移除。不要將向量搜尋結果視為目前任務階段的權威陳述。

選擇能夠維運的狀態邊界

在負載尚無需求前，不要將每個關注點都拆成獨立物件。邊界過多會讓簡單任務更難追蹤。同樣，將所有客戶和任務放進沒有區分的共享狀態，也會造成存取和責任問題。

先繪製示意圖，說明已認證請求如何到達任務、哪些記錄具有權威性，以及外部業務影響在哪裡發生。明確哪個元件能夠解釋每種故障。

Cloudflare 的 Agents 概覽 提供更廣泛的執行時背景。使用適合所選版本、已有文件的 API，並在將實驗性介面納入支援承諾之前先測試。

驗收集應包含同時操作的複核者、重複操作、來源版本變化、重連和目標不可用。有用結果不只是狀態得以保留，而是應用以正確權限恢復正確工作。

估算狀態設計與交接工作

實施成本取決於任務轉換、協作、來源關係和恢復要求。聊天記錄儲存的範圍，遠小於具有批准和目標核對的協調任務系統。

要求 GBP 方案報價，明確狀態責任歸屬、存取規則、保留行為與恢復測試。包括應用程式碼變化時演進已存記錄的方案。現有任務不應在部署後變得無法讀取。

範圍明確的 AI 整合試點 可以圍繞一項有用任務建立這些契約。請提供任務生命週期、複核者和關聯系統，索取有狀態助手方案 。這能讓儲存設計服從實際工作，而不是偶然讓聊天記錄定義設計。

常見問題

AI 記憶與持久儲存相同嗎？ 不同。持久儲存保留應用資訊，模型上下文則是為某次推理提供的資訊。應決定哪些已存事實具有權威性，哪些資訊被選擇或概括後提供給助手。

每個對話都應該有自己的任務嗎？ 只有符合業務流程時才這樣做。一個對話可能討論多個潛在任務，一項已接受任務也可能跨多個對話繼續。應為已接受工作分配能夠延續到起始介面之外的身分。

物件識別碼能證明呼叫者擁有資料嗎？ 不能。返回狀態或接受操作前，應檢查已認證身分與目前權限。猜測或重用路由識別碼，不得擴大存取。

重啟後應該保留什麼？ 持久儲存確定任務階段所需事實、來源與草稿版本、批准和外部操作編號。臨時程序記憶體不應成為已接受工作的唯一證據。

對話摘要可以記錄批准嗎？ 可以描述批准，但權威批准應保留為已認證應用事件，並關聯精確建議版本。模型生成的句子不應授權業務變更。

過時瀏覽器操作應該如何處理？ 根據目前狀態與版本檢查。拒絕或重新整理過時決定，並在適當時為已接受操作返回記錄結果。不能僅因使用者再次點擊就產生另一次影響。

怎樣的有狀態助手試點才有用？ 應演示身分邊界、同時進行的操作、中斷、重連和目標結果不確定。另一位工程師應能根據儲存證據恢復任務，而不必要求模型重建發生過什麼。