Cloudflare AI Platform 的核心不是「Cloudflare 也有 AI 模型」。比較準確的理解是：Cloudflare 想把 AI 應用與 agents 的基礎設施做成平台。
AI 應用真正上線後，通常會遇到一整串問題：模型要怎麼選、流量要怎麼控、向量資料放哪裡、檔案放哪裡、使用者狀態怎麼保存、成本怎麼看、agent 任務怎麼重試、瀏覽器自動化怎麼做。
Cloudflare 的策略，是用既有 edge 與 developer platform 把這些問題串起來。
Cloudflare AI Platform 包含哪些能力？
可以把它拆成幾塊：
| 能力 | 代表服務 | 用途 |
|---|---|---|
| 執行層 | Workers | API、前後端邏輯、工具調用 |
| 模型層 | Workers AI | 在 Cloudflare 平台上使用模型 |
| 模型治理 | AI Gateway | 管理模型請求、快取、log、rate limit、成本 |
| 資料層 | R2、KV、D1 | 檔案、低延遲 key-value、結構化資料 |
| 語意搜尋 | Vectorize | RAG、embedding search、知識庫查詢 |
| 狀態協調 | Durable Objects | session、多人協作、agent state |
| 長流程 | Workflows | 多步驟任務、重試、等待與恢復 |
| 網頁操作 | Browser Rendering | 截圖、讀頁面、browser automation |
這些不是單點功能，而是一個 AI 應用 stack。
為什麼只接模型 API 不夠？
早期 AI app 可以很簡單：
- 前端送 prompt。
- 後端呼叫模型 API。
- 把答案回傳。
但只要產品稍微成熟，就會多出很多需求：
- 要支援多模型 fallback。
- 要看每個使用者花了多少 token。
- 要把文件切 chunk 做 embedding。
- 要限制某些資料只能特定角色查詢。
- 要快取相同問題。
- 要保存 conversation state。
- 要讓 agent 等待外部事件。
- 要把錯誤請求追蹤回來源。
這些問題和模型本身無關，卻決定 AI 產品能不能穩定運行。
AI Gateway 的角色
AI Gateway 很像模型流量的控制塔。
它能幫開發者處理：
- request logging。
- caching。
- rate limiting。
- cost tracking。
- provider routing。
- failure visibility。
企業導入 AI 後，常見痛點是看不到模型使用細節。哪個產品線最耗 token？哪個 prompt 最容易失敗？哪個模型供應商延遲最高？如果沒有 gateway 層，這些問題會分散在各個應用裡。
AI Gateway 的價值，是把模型使用變成可管理的 infrastructure。
Vectorize 與資料層的角色
大多數企業 AI 應用都離不開 retrieval。
原因很簡單：模型本身不知道你的公司文件、客戶資料、內部流程、最新產品規格。這些都需要從資料層取回。
Vectorize 負責語意搜尋，R2 可以放文件與大型物件，D1 可以放結構化資料，KV 可以放低延遲狀態。搭配 Workers，就能建立常見的 RAG 應用：
- 文件上傳到 R2。
- 文件切段後建立 embedding。
- embedding 存進 Vectorize。
- 使用者提問時檢索相關段落。
- Workers 組合 prompt 並呼叫模型。
- AI Gateway 追蹤請求與成本。
這種架構比單純把文件塞進 prompt 更可靠，也更容易控管權限。
為什麼 agents 需要 Workflows 和 Durable Objects？
Agent 和一般 AI app 最大差別，是 agent 通常不是一次請求就結束。
例如一個網站 QA agent 可能要：
- 打開頁面。
- 截圖。
- 檢查按鈕。
- 填表。
- 等待結果。
- 比對預期畫面。
- 產生報告。
這是一段流程，不是一個 prompt。
Durable Objects 可以保存狀態，Workflows 可以管理步驟、重試、等待與恢復。Browser Rendering 則讓 agent 能和真實網頁互動。
這些能力加起來，才比較接近可上線的 agent infrastructure。
什麼團隊適合用這種架構？
適合：
- 已經使用 Cloudflare Workers 的工程團隊。
- 想快速部署 AI API、RAG、agent workflow。
- 需要全球分散式低延遲。
- 希望統一觀測模型成本。
- 不想自行管理太多伺服器。
- 要把 AI 功能嵌進既有網站或 SaaS。
不一定適合：
- 主要需求是模型訓練。
- 需要重度 GPU batch processing。
- 公司所有資料都在封閉內網。
- 只想用現成 no-code chatbot。
- 沒有人負責權限與觀測設計。
官方來源
- Cloudflare Blog，Building the Cloudflare AI Platform，2026-04-16。
結論
Cloudflare AI Platform 的關鍵，是把 AI 應用從「呼叫模型」推到「完整平台」。
當 AI 功能變成正式產品的一部分，開發者需要的不只是模型 API，而是資料、狀態、流程、瀏覽器、自動化、觀測與成本治理。Cloudflare 的拼圖顯示，下一階段 AI infrastructure 會更像 web infrastructure：分散、可部署、可監控，也能支援大量小型 agents。