Cloudflare cf CLI 開放測試：Agent 操作雲端，權限誰把關？（2026）

2026 年 9 月 28 日，Cloudflare 的 Matt “TK” Taylor 與 Samuel Macleod 在官方部落格發布〈Introducing cf: the agentic CLI for the entire Cloudflare API〉，宣布 Cloudflare cf CLI 進入開放測試。它試圖讓 AI Agent 從同一個命令列入口尋找、執行 Cloudflare API 操作。真正值得問的是：指令變容易找之後，誰決定 Agent 能改動哪些雲端資源？

這篇先還原 Cloudflare 提出的產品設計與數據，再對照公開程式庫、文件與權限機制，最後判斷開發團隊該如何試用，而不把發布文章當作實測報告。

Cloudflare cf CLI 從 Wrangler 接手什麼？

Cloudflare 說，既有 Wrangler 由不同產品團隊逐步加上命令，約涵蓋 280 個操作；Cloudflare API 則有超過 3,000 個操作。這兩個數字出自同一家公司的產品盤點，本文無法從公開介面逐項重算。它們說明的方向很清楚：Agent 即使會呼叫命令，也得先找到命令，而且不同產品的命名、輸出方式若不一致，就會增加探索成本。

Cloudflare 在 2026 年 4 月的技術預覽文章仍說 cf 只覆蓋少數產品；9 月文章則宣稱，新的開放測試版已能從 API 規格產生涵蓋整個 API 表面的命令。這是同一產品從預覽走向擴大覆蓋的時間線，不宜把早期預覽的限制直接套到現在，也不宜把宣稱的路由數當作每一條工作流程均已驗證成功。

48% 是什麼：採用訊號，還是效能證據？

Last week, agent usage reached 48%.

中文：前一週，Agent 用量達到 48%。

Cloudflare，〈Introducing cf〉

原文指的是 Cloudflare 自行統計的 Wrangler 使用：2026 年 3 月約四分之一、發布前一週為 48%。它沒有公開完整的計數口徑、抽樣方式或底層事件資料，因此 48% 應視為公司自述的使用結構，而非獨立審核的市場占有率，更不是「Agent 完成任務的成功率」。原文另稱 Agent 每日使用的不同命令近乎人類兩倍，使用六個以上命令的機率近四倍；同樣缺少公開的分母和分組資料。

這些數字仍有產品意義：若命令列操作相當一部分已由 Agent 發起，讓輸出容易被機器解析、讓命令可被搜尋，確實對準一個可能存在的使用摩擦。但「更多 Agent 在用」只能支持介面設計的動機，無法證明新 CLI 更快、更可靠或更安全。

Cloudflare cf CLI 把哪些動作變得好找？

第一個改變是找得到命令。原文介紹 cf cli search：Agent 可以用自然語言搜尋 API 描述與參數，而不必把數千個命令一次塞進模型上下文。第二個是看得懂結果：cf 以 JSON 為預設輸出，Agent 可以擷取需要的欄位；這減少了從終端表格解析結果的負擔。對購買網域等必填欄位較多的操作，原文還展示由 API 要求組成的互動表單，方便人逐項確認輸入。Cloudflare 的公開程式庫 README也列出命令搜尋、JSON 預設輸出和開放測試安裝方式，能獨立於宣傳文章確認這些設計確實已對外發布。

JSON is the default interface

中文：JSON 是預設介面。

Cloudflare，〈Introducing cf〉

第三個改變是把設定放進型別系統。Cloudflare 展示 cloudflare.config.ts，讓編輯器與具備語言伺服器能力的 Agent 能看到欄位型別、補全與錯誤。原文說這個格式「從 Workers 開始」，將來才擴展到更多 Cloudflare 產品；所以「CLI 的 API 命令範圍」與「TypeScript 宣告式設定的範圍」不能畫上等號。這套命令與設定由 Cloudflare 的Forge 產生流程支撐；Forge 同日以開源專案公開，說明公司希望用共同 API 規格減少產品間的介面差異。

遷移承諾裡，哪些已經到位？

Cloudflare 把 Vite 設為 cf 的主要開發路線，並提供 cf migrate 協助既有 Worker 轉換。原文同時說明，仍依賴 Wrangler esbuild 流程、Rust 或 Python Worker 的部分開發與部署會交由 Wrangler 處理。這代表「開始使用 cf」與「完全脫離 Wrangler」是兩件事；對既有專案，能否順利遷移取決於目前的建置方式。

Cloudflare 另承諾在開放測試結束後推出最後一個 Wrangler 主要版本，並在測試結束後提供 18 個月維護支援。這是未來承諾，不是現在就開始倒數的終止日期。若要規劃團隊遷移，應以正式版發布和後續維護公告重新對帳，而不是只讀這篇發布文。

AlphaLab 的判讀：覆蓋面擴大，控制面也要跟上

「有命令」不等於「有權限」

cf 把 API 操作變成容易搜尋的命令；真正決定操作能否執行的，仍是身分與憑證。Cloudflare 的API 權限文件把權限分為 Zone、Account、User 類別，Token 政策可指定權限群組與資源。這也揭示一個容易忽略的風險：當 Agent 更容易發現「購買網域」「修改 DNS」「變更存取政策」等操作時，若直接給它橫跨帳號的高權限憑證，出錯的影響範圍會跟著放大。命令的易用性，不能替權限設計把關。

JSON 與型別提高可讀性，驗收仍要看結果

JSON 方便 Agent 擷取欄位，TypeScript 型別能在編輯時抓到部分配置錯誤；兩者都無法保證「選對資源」「沒有造成非預期變更」。例如一次部署命令成功回傳，還需要讀回 Worker 名稱、版本與目標環境；一次 DNS 變更成功回傳，也要確認實際記錄符合預期。這不是對 cf 的特殊指控，而是任何把外部系統交給 Agent 操作時，都必須分開處理的「命令執行」與「結果驗證」。

真正值得追的，是可重複驗證的能力

我同意 Cloudflare 把指令搜尋、結構化輸出和規格產生放在同一條產品路線上：大型 API 的人手命令維護確實容易出現不一致。但我對「整個 API」的保留是，公開的發表文與 README 足以證明設計方向，仍不足以證明每項操作在不同帳號權限、錯誤回應和產品版本下都可由 Agent 穩定完成。Cloudflare 自身也把 cf 標示為開放測試；下一步值得看的，是操作清單、已知限制、失敗回報與版本更新如何持續公開。

若你負責 Agent，先怎麼試？

先挑一個低影響、可回查的任務：例如在測試帳號查詢特定 Worker 的設定。讓 Agent 先用搜尋找到命令，列出它準備使用的帳號、資源與參數；再用只讀或範圍受限的 Token 執行。接著由另一個查詢讀回結果，記錄命令、回應、實際狀態與人工核准點。若要進一步測試寫入，才把同一套檢查放到獨立測試資源，並事先寫好撤銷或回復路徑。Cloudflare 的Token 政策文件可作為權限設計的起點。

Cloudflare cf CLI 的價值，不在「Agent 終於能碰雲端」這句口號，而在它把大平台 API 的發現、輸出與設定整合成更容易讓 Agent 使用的介面。值得採用的門檻也應一樣具體：命令找得準、權限縮得住、結果查得到、失敗收得回。這四件事成立，介面變得更強才真的幫得上工程團隊。