Cloudflare 2026 年 6 月 19 日推出 Temporary Cloudflare Accounts for Agents，讓沒有既有 Cloudflare 登入狀態的 AI agent，可以用 wrangler deploy --temporary 先部署 Worker，拿到一個 60 分鐘內可認領的預覽帳號與 workers.dev URL。對正在讓 coding agent 自動寫程式、部署、curl 檢查結果的團隊，這個更新把一個很實際的問題推到檯面：agent 試錯要用哪種帳號，臨時憑證如何交接，什麼時候才該進正式環境。
這篇把 Temporary Accounts 放回 Cloudflare Agent Readiness 的五層檢查裡看。請把 --temporary 視為試作入口：先判斷它適合哪種流程、哪些限制要先知道、企業如何避免把臨時帳號變成看不見的部署風險。
如果你正在評估 Cloudflare agent 執行環境（runtime）的完整上線路線，可以搭配站內的 Cloudflare Agents SDK 與 Flue 檢查；那篇處理持久執行、沙盒與工作流，本文聚焦帳號、憑證與部署交接。
先回答：Temporary Accounts 解決哪一步？
Temporary Accounts 解決的是「agent 想部署，但沒有可用帳號與瀏覽器登入流程」這一步。過去 agent 執行 wrangler deploy 時，如果 Wrangler 沒有登入 Cloudflare，通常會卡在 OAuth、Dashboard、API token 或多因素驗證。這些流程對人類合理，對背景 agent 會變成中斷點。
Cloudflare 官方部落格與文件描述的流程是：
- agent 先嘗試正常部署。
- 如果 Wrangler 沒有憑證，CLI 會提示可改用
--temporary。 - agent 重新執行
wrangler deploy --temporary。 - Cloudflare 建立或重用一個臨時預覽帳號，部署 Worker 到
workers.devURL，並輸出認領連結（claim URL）。 - 人類在 60 分鐘內開啟 claim URL，登入或建立 Cloudflare 帳號後把臨時預覽帳號認領成自己的正式帳號資源。
這讓 agent 可以完成「寫程式 → 部署 → curl 驗證 → 回報結果」的閉環。對一次性原型很方便，對企業流程則必須加上帳號治理與審核。
Agent Readiness 的五層要重新補一格：帳號層
原本談 Cloudflare Agent Readiness 時，常見檢查會放在資料、工具、權限、執行環境與觀測。Temporary Accounts 讓「帳號層」變得更清楚：agent 不只要能呼叫工具，也需要被放進正確的帳號生命週期。
| 層級 | 這次要回答的問題 | Temporary Accounts 的提醒 |
|---|---|---|
| 帳號層 | agent 用誰的帳號部署？誰可以認領？claim URL 怎麼保存？ | 臨時預覽帳號有 60 分鐘窗口；claim URL 可取得所有權，必須當成敏感連結。 |
| 資料層 | agent 部署時會建立或接觸哪些資料資源？ | 文件列出 D1、KV、Hyperdrive、Queues 等支援與限制；試作資料不要直接混進正式資料。 |
| 工具層 | agent 可以跑哪些 Wrangler 指令與綁定？ | --temporary 只適合能使用短期臨時憑證的命令，不是所有 Wrangler 行為的通用旗標。 |
| 權限層 | 臨時憑證能做什麼？何時改用永久帳號？ | 若 Wrangler 已能用 OAuth、CLOUDFLARE_API_TOKEN 或 global API key，--temporary 會回傳錯誤；正式流程應改用明確授權。 |
| 執行層 | agent 能否重複部署、驗證、失敗後重試？ | 臨時預覽帳號在有效期內可重用，適合短時間內多次部署與驗證。 |
| 觀測層 | 誰知道 agent 建了什麼、何時過期、是否被認領？ | 未認領帳號會被刪除；企業仍要記錄 agent 任務、部署 URL、claim URL 處理方式與人工接管結果。 |
這一格很關鍵：agent 自動部署看起來像開發體驗問題，實際上牽涉帳號建立、憑證發放、資源所有權與回收。
什麼時候適合用 --temporary？
Temporary Accounts 最適合短時間、低風險、容易丟棄的工作。Cloudflare 文件也明確建議：production 與持續整合／持續部署（CI/CD）應使用永久 Cloudflare 帳號、wrangler login 或 Cloudflare API token，不應把 --temporary 當成正式部署入口。
| 情境 | 建議 | 原因 |
|---|---|---|
| AI 產生一個 Worker demo，想立刻部署並驗證 | 可以用 wrangler deploy --temporary | agent 能取得 URL、自行 curl 驗證，60 分鐘內由人類決定是否認領。 |
| 背景 coding agent 幫使用者做第一次 Workers 評估 | 可以用，但要回報 claim URL 與限制 | 使用者不必先登入 Cloudflare，降低試作摩擦；claim URL 需要妥善保存。 |
| 團隊內部沙盒測試、可丟棄原型 | 可以用，但要隔離資料與任務紀錄 | 適合短期試錯，不適合接正式資料或不可重建狀態。 |
| 正式網站、客戶 API、長期服務 | 改用永久帳號與明確 API token | 需要穩定所有權、權限審核、成本歸屬、監控與回滾。 |
| CI/CD 管線或定期部署 | 不建議用 --temporary | 官方文件建議正式環境和 CI/CD 使用永久帳號登入或 API token。 |
實務上，可以把 Temporary Accounts 當成「agent 試作區」。它讓 agent 快速證明一個想法能跑起來，但是否進入正式帳號，仍要由人類或既定變更流程判斷。
官方限制要先知道
Cloudflare 文件列出幾個導入前必須知道的限制：
- Temporary preview account 未在 60 分鐘內認領會過期，Cloudflare 會刪除帳號與部署。
- 使用前需要 Wrangler 4.102.0 或更新版本。
- 建立臨時預覽帳號前，Cloudflare 會做 proof-of-work 檢查；Wrangler 會自動處理，但可能造成短暫延遲。
- Cloudflare 會限制臨時預覽帳號建立速度，要求過快時需要等待或改用正式帳號。
--temporary僅供未登入使用；已經有 OAuth、CLOUDFLARE_API_TOKEN或 global API key 時會回傳錯誤。- claim URL 代表臨時預覽帳號所有權，應視為敏感連結，不應貼到公開 issue、聊天頻道或可被外部讀取的 log。
- 支援資源有範圍：Workers 的
workers.dev部署、Workers Static Assets、部分 Workers KV 命令、D1、Hyperdrive、Queues 與 SSL/TLS certificates；各項有對應限制。
這些限制顯示它屬於導入試用與試作工具，不能取代企業雲端帳號管理。若團隊需要把試作一路推到正式環境，建議另外用 AI Agent 開發生命週期 檢查建置、測試、部署、監控與治理的交接點。
實務情境：讓 coding agent 自己部署 demo，但不碰正式帳號
讀者情境：平台工程師想測試一個 coding agent 能不能從空專案產生 Cloudflare Worker、部署、驗證輸出，再把結果交給人類審核。
可以交給 agent 的任務：
建立一個最小 TypeScript Cloudflare Worker，回傳 JSON 健康檢查結果。用 Wrangler 部署；如果沒有 Cloudflare 憑證，依照 CLI 提示使用 temporary deploy。部署後 curl URL，確認回傳內容，最後只回報部署 URL、claim URL、Wrangler 版本、使用的資源與是否需要我認領。
預期輸出：agent 產生 Worker 程式、執行 wrangler deploy --temporary、拿到 workers.dev URL、用 curl 驗證 JSON 回應，並把 claim URL 交回人類。
怎麼驗證：人類檢查程式碼、curl 回應、Wrangler 輸出與 Cloudflare 文件限制；若要保留，再於 60 分鐘內認領帳號。若只是測試，讓它自然過期。
風險與不適用情境：不要在這種任務裡放正式 API key、客戶資料、內部資料庫連線字串或不可公開的環境變數。若這個 Worker 會服務真實使用者，應改走永久帳號、最小權限 token、審核流程與監控。
企業導入前的帳號與權限檢查
在允許 agent 自動部署前，建議先把下面幾件事寫進團隊規則：
- 臨時部署只用於試作：明確標示哪些任務可以用
--temporary，哪些任務一定要走正式帳號。 - claim URL 保護：agent 回報 claim URL 的位置要可控，避免出現在公開 log、公開 issue 或可被第三方搜尋的頁面。
- 資料隔離：臨時預覽帳號不要接正式資料來源；測試資料要能刪除或重建。
- 憑證升級流程：從臨時帳號轉正式帳號時，要重新設定正式的 API token、環境變數、權限 scope 與密鑰管理。
- 資源限制紀錄：記錄使用了 Workers、D1、KV、Queues 或其他資源，避免認領後不知道 agent 建了什麼。
- 觀測與回滾：部署 URL、commit、Wrangler 版本、agent 任務紀錄與驗證結果要留在團隊可追蹤的位置。
- 人工接管點：認領、升級到 production、接正式資料、接付款或客戶流量前，都應有明確人工批准。
這份清單的目的，是讓 agent 在低摩擦試作與企業治理之間有一道清楚閘門。Temporary Accounts 提供快速入口，治理工作仍要由團隊設計。
和 Cloudflare 其他 agent 更新怎麼接起來？
Temporary Accounts 補的是帳號與首次部署摩擦。它和 Cloudflare 最近幾個 agent 方向可以這樣分工：
- Cloudflare Agents SDK 與 Flue：處理 agent 長任務、狀態保存、沙盒與工作流，適合評估執行環境是否能上線。
- Cloudflare 漏洞 harness：處理 AI 資安掃描如何把發現、反駁、去重與人工審核做成工程流程。
- Zero Trust for AI Agents：補上 agent 身分、權限、資料邊界與工具使用的安全模型。
- OpenAI Agents SDK Sandbox：從另一個平台角度看 agent 執行程式時的沙盒與權限邊界。
對企業來說，這些更新共同指向同一件事：agent 會越來越能自己行動。部署摩擦下降後，帳號、憑證、沙盒、觀測與人工接管會變得更重要。
官方來源
- Cloudflare Blog，〈Temporary Cloudflare Accounts for AI agents〉，2026-06-19。
- Cloudflare Workers Docs，〈Claim deployments (temporary accounts)〉，文件
dateModified2026-06-19。 - Cloudflare Docs，〈Agents〉，用於確認 Cloudflare Agents SDK 的定位。
重點整理
Cloudflare Temporary Accounts 讓 AI agent 更容易把程式部署到可驗證的雲端環境，對原型、背景 agent session 與第一次 Workers 評估很有價值。
真正要管理的是部署之後的交接：claim URL 是敏感連結，60 分鐘窗口要有人接手，臨時帳號不能接正式資料，production 與 CI/CD 仍應走永久帳號與明確 API token。把這些規則先寫清楚，Temporary Accounts 才會是安全的試作加速器，而不是下一個難以追蹤的雲端入口。