Cloudflare 在 2026 年 8 月 6 日公開 Kitesurf，一個專門給 AI agent 使用、可在 Workers 上執行的瀏覽器引擎。它支援 Cloudflare Browser Run 的 Quick Actions，也能透過 Chrome DevTools Protocol（CDP）接到既有的 Playwright、Puppeteer 與 MCP 流程。
先講結論：Kitesurf 現階段無法全面取代 Chromium。它比較適合成為第二條、成本較低的執行通道，處理短時間、無狀態、網站相容性已驗證的擷取與轉檔任務。 遇到影片、WebGL、長登入、反機器人驗證或像素級視覺測試，仍要回到 Chromium。
這個區分很重要。Cloudflare 公布的 CPU、記憶體優勢確實明顯，但同一份測試也顯示 Kitesurf 完成截圖與 HTML 擷取的時間較久。團隊若只看「低 3 至 7 倍」就全面遷移，可能省到基礎設施資源，卻換來更多網站相容性問題與較慢回應。
Kitesurf 是什麼？和 AI 瀏覽器有何不同？
Kitesurf 沒有讓人日常上網用的分頁、主題、擴充功能與完整桌面介面。它是雲端的 headless browser engine，主要使用者是程式與 AI agent：agent 發出開網頁、讀 DOM、點擊、輸入、擷取 HTML、產生截圖或 PDF 等指令，再接收結構化結果。
一般 Chromium 要同時滿足影音、WebGL、擴充功能、像素一致性與大量互動情境。這些能力很完整，也帶來較高的記憶體與 CPU 負擔。Kitesurf 則把目標縮到 agent 常用的 DOM、HTML、CSS、XHR、CORS、文字選取與 SVG 等網頁能力，接受畫面未必與 Chrome 完全一致的取捨。
Cloudflare 公開的架構使用 Rust、WebAssembly 與多個既有元件，包括 Blitz 渲染引擎、Firefox 的 Stylo CSS 解析器與 Boa JavaScript 引擎。每次頁面載入以不受信任內容處理，元件盡量無狀態且相互隔離；網路請求集中經過指定的 outbound worker。這些設計有利於大量短任務，也符合 Workers 的隔離模型。
但隔離引擎不能替 agent 決定「可不可以做這個動作」。網頁提示注入、憑證權限、付款確認、資料外傳與操作稽核，仍要在 agent 與工具層另外治理。需要完整風險模型時，可搭配站內的 AI browsing agents 安全分析閱讀。
3 至 7 倍效能優勢，要怎麼解讀？
Cloudflare 以 14 個網址組成測試集，對 Browser Run Quick Actions 各跑五次並取中位數，拿 Kitesurf 與預熱池中的 Chromium 比較。官方文件列出的結果如下：
| 任務與指標 | Kitesurf | Chromium 預熱池 | Kitesurf 相對結果 |
|---|---|---|---|
| 截圖 CPU | 380 ms | 1,173 ms | 少用 3.1 倍 CPU |
| HTML 擷取 CPU | 229 ms | 877 ms | 少用 3.8 倍 CPU |
| 截圖記憶體 | 57.8 MiB | 271.0 MiB | 少用 4.7 倍記憶體 |
| HTML 擷取記憶體 | 39.4 MiB | 273.7 MiB | 少用 7.0 倍記憶體 |
| 截圖完成時間 | 1,148 ms | 637 ms | 慢 1.8 倍 |
| HTML 擷取完成時間 | 820 ms | 472 ms | 慢 1.7 倍 |
這份數字支持兩個不同結論：
- 若瓶頸是同時容納大量短任務，Kitesurf 的 CPU 與記憶體占用值得測。 同樣的資源理論上可以放進更多隔離工作，但真實併發量還會受 Cloudflare 帳戶限制、目標網站與任務內容影響。
- 若使用者正在等單次結果，Chromium 目前可能更快。 官方解釋是預熱 Chromium 的 JIT 對上 Kitesurf 的冷啟動軟體渲染，牆鐘時間仍由 Chromium 勝出。
這是 Cloudflare 自己在小型網址集上的產品測試，尚非獨立、跨地區、跨網站類型的 benchmark。上線判斷應以你的成功率、P95 完成時間、記憶體、CPU、重試率與每個成功任務成本為準，不能把 3 至 7 倍直接套到所有工作負載。
哪些任務適合 Kitesurf？哪些繼續用 Chromium？
優先測 Kitesurf： 單頁 HTML、Markdown、連結擷取，以及大量截圖、PDF 和短時間的突發式 agent 瀏覽。這些任務輸出偏結構化、不依賴像素級畫面，也較符合無狀態、隔離、快速啟動的設計。截圖與 PDF 仍要先確認目標網站的字型、排版和圖片有沒有跑掉，並接受單次完成時間可能較慢。
先跑真實流程再決定： 複雜 SPA 表單、多步操作、iframe 與下載流程。Kitesurf 只支援部分 CDP，網站 JavaScript 或 Playwright 高階 API 可能碰到缺口；同一框架的兩個網站也可能有不同結果，不能只看技術棧下判斷。
繼續用 Chromium： E2E 與視覺回歸測試、影片、WebGL、Canvas 重度應用、長時間登入與持續 session。Cloudflare 也明列 Kitesurf 無法用真實 TLS 指紋完成 bot challenge handshake；即使改用 Chromium，自動化仍要遵守目標網站規則，也不能假設一定能通過驗證。
付款、刪除、帳號或權限變更則不該只靠引擎選擇決定安全性。這些動作需要最小權限、人工確認、金額或範圍上限與完整稽核，無論最後跑 Kitesurf 或 Chromium 都一樣。
Cloudflare 表示 Kitesurf 已能處理 TodoMVC 的 React、Vue、Angular 等版本、Wikipedia、Hacker News、Cloudflare Blog 與部分 Cloudflare dashboard。這份清單只能證明特定頁面曾運作，不能推論你的網站也相容。
官方文件截至 8 月 7 日列出超過 23.5 萬個 Web Platform Tests（WPT）子測試通過，DOM、HTML、Selection、SVG 等部分覆蓋率達 96% 至 99%。WPT 是跨瀏覽器的 Web 標準測試套件，適合看規格相容程度；它不測你的登入流程、第三方 widget、反機器人規則與真實頁面組合。通過大量 WPT 不等同達到 Chrome 的實站相容性。
Playwright、CDP 與 MCP 要怎麼接？
Kitesurf 的遷移成本可能不高，原因是 Browser Run 讓現有 CDP client 透過查詢參數選擇引擎。Quick Actions 在 endpoint 加上 browser=kitesurf；CDP 則連到這類 WebSocket 位址：
wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurfPlaywright 或 Puppeteer 可以沿用既有 CDP 連線方式，支援 CDP 的 MCP client 也能把同一個 endpoint 交給 chrome-devtools-mcp。這表示團隊可以把引擎做成環境參數，不必維護兩套完全不同的操作腳本。
「可以連線」仍不表示所有 API 都能用。Kitesurf 目前只實作 CDP 的一部分，Playwright 的高階 API 最後仍可能呼叫尚未支援的指令。若你還在選自動化層，先讀 Playwright MCP 指南與 Stagehand 指南；需要雲端 session、代理與正式產品能力的比較，可直接看 AI 瀏覽器自動化工具選型。
實際遷移：先做雙引擎分流，不要一次換掉 Chromium
我不建議因為官方效能標題，就把現有 Playwright 工作全部改到 Kitesurf。較穩妥的上線方式是保留 Chromium，讓 Kitesurf 先承接相容性已知的低風險任務。
- 建立真實任務測試集。 挑出流量最高或成本最高的 20 至 50 個頁面與操作，不要只測
example.com。測試集至少涵蓋靜態頁、常見 SPA、登入頁、延遲載入、iframe、下載、不同語系與失敗頁。 - 把引擎與業務腳本拆開。 保留同一套 Playwright／CDP 步驟，只把 endpoint、驗證與 browser type 做成設定。輸入、預期輸出與停止條件固定，才看得出差異來自引擎或腳本。
- 同時量成功率與資源成本。 每個任務記錄成功率、P50／P95 完成時間、CPU、記憶體、Browser Run 用量、重試次數、DOM 差異與截圖差異。只算單次執行價格會漏掉失敗重試與人工排查成本。
- 只分流通過門檻的任務。 例如規定連續七天成功率至少 99%、關鍵欄位差異為零、P95 在服務目標內，才把該任務預設送往 Kitesurf。複雜互動、視覺驗收與已知不支援功能維持 Chromium。
- 加入可觀測的 Chromium fallback。 Kitesurf 遇到不支援 CDP 指令、渲染缺欄、超時或相容性錯誤時，可切到 Chromium 重跑一次；fallback 要有原因碼、比率與告警。若同一網站頻繁 fallback，就應直接回到 Chromium，避免每次先失敗一次。
- 最後才接敏感帳號。 初期使用測試帳號、唯讀資料與受限 API token。需要操作真實帳號前，先確認 Cloudflare 的資料處理、儲存地區、合約與組織政策，再加上短效憑證、操作確認、允許網域、輸出過濾與完整稽核。不要把生產 cookie 或可付款憑證放進 Beta 相容性測試。
Kitesurf 免費嗎？目前仍是 Beta
Cloudflare 文件寫明 Kitesurf Beta 期間免費，但受每個帳戶的限制；這不等於正式版會永久免費，也不代表所有 Browser Run 用量都免費。現有 Browser Run 的一般方案中，Workers Free 提供每日 10 分鐘瀏覽器時間與 3 個同時 session；Workers Paid 提供每月 10 小時，超出後按瀏覽器時間與 session concurrency 計費。
Kitesurf 正式版的價格、SLA 與相容性承諾尚未公布。評估時可先算「每個成功任務」的成本，並預留 Beta 規格、限額或計價改變的空間。若工作負載已有穩定 Chromium 成本，也不要在缺少實測資料時把預估節省寫進年度預算。
我的判斷是：Kitesurf 最有價值的地方，不在取代使用者熟悉的瀏覽器，而在讓 agent 工作負載出現輕、重兩個執行層。 結構化擷取、截圖與短任務走輕量引擎；真實瀏覽器相容性、長 session 與高風險操作留在 Chromium。能做好分流與 fallback 的團隊，才最可能吃到它的資源優勢。
常見問題
Kitesurf 可以取代 Chrome 或 Chromium 嗎？
目前不行。Kitesurf 適合短、無狀態、相容性已驗證的 agent 任務；影片、WebGL、bot challenge、長登入、完整 CDP 與像素級畫面仍需 Chromium。較實際的架構是雙引擎分流。
Kitesurf 比 Chromium 快 3 到 7 倍嗎？
不是。官方 14 個網址測試顯示的是 CPU 與記憶體用量少 3.1 至 7 倍；截圖與 HTML 擷取的完成時間反而慢 1.7 至 1.8 倍。這份公司自測也不能直接外推到所有網站。
現有 Playwright 程式可以直接使用 Kitesurf 嗎？
可以先透過 Browser Run 的 CDP endpoint 接入，並在網址指定 browser=kitesurf。但 Kitesurf 只支援部分 CDP，現有腳本仍須用真實網站逐條測試，不能只以成功連線判定相容。
Kitesurf 現在免費嗎？
Kitesurf 在 Beta 期間免費且受帳戶限制。Browser Run 其他引擎與正式用量有各自的免費額度、瀏覽器時間與 concurrency 計費；Cloudflare 尚未公布 Kitesurf 正式版價格，因此不宜假設會永久免費。