讓 AI agent 暫時部署 Cloudflare Worker 前：帳號認領與交接檢查表
把 AI agent 接到部署流程後，最容易被誤解的一步是「它已經有一個可開啟的網址」，於是直接把它視為正式環境。Cloudflare 在 2026-06-19 公告的 Temporary Accounts API，提供的是另一種流程；相關 claim deployments 文件於 2026-07-14 更新：平台可先把 Worker 部署到暫時帳號，之後再讓使用者透過 claim URL 認領並保留資源。
這篇要解決的是：當你要讓 agent 或內部平台替使用者建立預覽 Worker 時，怎麼把「能測試」和「已交接」明確分開。可記住一句話：temporary deployment 的完成條件不是網址能開，而是帳號、資源與後續維護責任都已被認領。
先把 temporary account 當成預覽環境
Cloudflare 說明，Temporary Accounts API 可讓平台在使用者還沒有既有 Cloudflare 帳號時，建立 Worker 與支援的資源；API 會回傳 claim URL，供使用者把暫時帳號認領為永久帳號。這很適合讓 agent 在 onboarding 流程中先部署、測試、再交給使用者。
截至 2026-08-04，官方文件另外把這條路拆成兩種整合方式：由 agent 或工具執行 Wrangler 時使用 wrangler deploy --temporary；由平台後端控制流程時，使用 api.cloudflare.com/client/v4/provisioning/previews。Cloudflare Drop 則是靜態網站的 preview-and-claim 範例，不代表所有部署都應改成同一個產品流程。
但這不等於可以省略帳號治理。預覽網址只證明這次部署能被存取；它沒有回答誰日後能看 logs、誰能改環境變數、資源的帳單歸屬在哪裡，以及使用者是否已看過部署的內容。
建立前先列出 agent 能碰的資源
在發出部署請求前，將本次允許的範圍寫成可 review 的清單。不要把「建立一個網站」直接翻成無邊界的平台權限。
| 檢查項目 | 建議先決定的內容 | 為什麼重要 |
|---|---|---|
| Worker 名稱與路由 | 預覽名稱、是否綁自訂網域 | 避免誤碰正式網域或既有服務 |
| 可建立的資源 | 只列此次需要的 bindings 與產品 | 讓 agent 不會把額外儲存或資料服務當成預設選項 |
| Secrets 與外部 API | 誰提供、何時寫入、誰可輪替 | temporary deployment 不應成為傳遞長期密鑰的捷徑 |
| 資料與測試內容 | 是否可用真實個資或 production 資料 | 預覽環境仍可能被公開網址存取 |
| 認領期限 | claim URL 的交接責任人與完成時間 | 防止工作完成後只留下無主的測試環境 |
這張表不需要很長，但要能讓下一位維護者回答：「這個網址現在屬於誰、可以安全刪掉嗎？」
把部署拆成預覽、驗證、認領三個關卡
比較穩妥的流程如下：
- 預覽部署：agent 只在 temporary account 建立本次所需的 Worker 與支援資源。
- 受限驗證：用明確 URL、基本 smoke test 與預期回應確認產物；若有登入、付款、資料寫入等功能，先用測試資料。
- 使用者認領：將 claim URL 交給正確的帳號持有人，並確認資源已變成其永久帳號的一部分。
- 交接後再擴權：自訂網域、正式 secrets、監控通知與 CI 部署權限，放到認領完成後的變更中處理。
這個切法的好處是，agent 可以協助縮短第一個可用版本的時間，但不能默默跳過擁有權確認。若認領尚未完成，部署紀錄應標為 preview，而不是 production-ready。
不要把 claim URL 當成一般分享連結claim URL 是帳號與資源交接的一環。只交給預定的帳號持有人，不要貼在公開 issue、聊天室截圖或文件範本中；交接完成後，仍應回到平台確認實際的帳號與資源歸屬。
認領完成後，立刻補上四個正式設定
認領不是流程的收尾，而是正式維運的開始。至少檢查下面四件事：
- 部署來源：確認 repository、分支與 CI 身分；不要繼續依賴臨時對話中的手動部署。
- 密鑰管理：把暫時測試值替換為正式 secret，並記錄輪替位置，不把值寫入 repository 或輸出日誌。
- 網域與存取：若要接自訂網域，確認 DNS、TLS、redirect 與存取控制分別由誰負責。
- 可觀測性與刪除責任：確認 logs、錯誤通知與資源清理的責任人，尤其是已不再使用的預覽部署。
Cloudflare 的 temporary account 設計讓「先部署再認領」成為可行的產品流程；真正要補上的，是把每個權限提升和正式資源綁定留到可審核的交接後。
Wrangler temporary deployment 的有效期限
如果是 agent 在本機或 CI 外的互動流程執行 Wrangler，Cloudflare 文件目前要求使用 Wrangler 4.102.0 以上；未登入部署時，工具會提示改用 temporary deployment：
pnpm wrangler deploy --temporary輸出會同時包含預覽網址與 claim URL，並標示 Claim within: 60 minutes。在這段時間內可以重新部署變更；Wrangler 也會在憑證與 claim URL 有效時快取並重用暫時帳號。執行 wrangler login 或 wrangler logout 後，快取的暫時帳號資料會被清除。
這裡有兩個實務邊界：
- 60 分鐘是認領與預覽的時間窗，不是正式服務的 uptime 保證。
- Wrangler 會把暫時值放在目前作業系統使用者的全域設定目錄，不要讓多個平台使用者共用該目錄。
如果流程是由平台後端呼叫 REST API，暫時 API token 應只留在後端；前端最多取得預覽網址和只交給預定使用者的 claim URL。Cloudflare 文件將 claim URL 視為 bearer credential，不應貼到公開 issue、聊天紀錄或截圖中。
把網址可開，改成可驗證的交接完成條件
如果你用 agent 產生 Worker，最實用的完成條件可以寫成：預覽已通過指定 smoke test、使用者已認領帳號、正式部署來源與 secrets 已建立、暫時資源有明確清理或保留決策。這比「agent 幫我部署好了」更容易交給團隊接手。
常見問題
Q: Temporary Accounts API 能取代 Cloudflare 的正式帳號嗎？
A: 不能。它的用途是讓平台在使用者尚未登入或沒有既有帳號時建立暫時部署；Cloudflare 透過 claim URL 讓使用者認領，成為可保留的永久帳號與資源。正式維運仍要由認領後的帳號、權限與部署流程負責。
Q: temporary deployment 可以直接放 production secret 嗎？
A: 不應把它當成預設做法。先確認 secret 的擁有者、輪替方式和可見範圍；比較安全的安排是先用測試值驗證流程，認領後再由正式帳號以既定的 secret 管理方式寫入。
Q: 使用者認領前，哪些事情最不該自動化？
A: 不應自動綁定正式自訂網域、導入真實個資、開啟未經審核的外部整合，或把長期維運權限交給 agent。這些都會把預覽步驟變成難以回收的正式變更。
參考資料：
Cloudflare Changelog：Temporary accounts for AI agent deployments
回報錯字、失效連結，或告訴我你想看的延伸主題。