Cloudflare Kitesurf 是什麼？Agent-first 瀏覽器的 3–7 倍真相（2026）

Cloudflare Kitesurf 在 2026 年 8 月 6 日正式亮相。Cloudflare 的 Celso Martinho、Ruskin Constant、Rui Figueira 與 Luís Duarte 在 Cloudflare Blog 發布這個新引擎：它為 AI Agent 工作負載重新設計，不啟動完整 Chromium，而是在 Cloudflare Workers 上，以 CDP 接收 Playwright、Puppeteer 等客戶端的指令，再用 V8 isolates 與 Rust／Wasm 元件完成 DOM、JavaScript、CSS、網路與畫面輸出。Kitesurf 目前是 Browser Run 裡的免費 beta 選項，並受帳號額度限制。

這個方向很快引起開發者注意。截至 2026 年 8 月 9 日 20:20（台北時間），Hacker News 討論串有 215 points、61 comments。Kitesurf 最吸引人的產品命題，不是「Cloudflare 做了另一個瀏覽器 UI」，而是大量只需要擷取 HTML、產生 PDF 或點幾個按鈕的 Agent，或許不必再為整套 Chromium 付出同樣的 CPU 與記憶體成本。但這個故事最容易被誤讀的地方，也正是「輕量」：Kitesurf 不是 Playwright 的替代品，更不是已經能通吃所有網站的 Chromium 替代品。

先把原文放在桌上。點擊下面的瀏覽器截圖，會在新分頁開啟 Cloudflare 公告。接下來我會先還原 Kitesurf 的架構，再逐項檢查 3–7 倍資源優勢、CDP 相容性、WPT 數字與 beta 限制，最後給出它真正適合放進哪一段 Agent 流程的判斷。

---

一、Kitesurf 是什麼？不是「把 Chromium 搬進 Workers」

一般瀏覽器自動化的思路，是先啟動一個成熟、完整、能播放影片與執行幾乎所有 Web API 的瀏覽器，再讓 Agent 遙控它。這個選擇換來高相容性，也帶著昂貴的多程序架構、圖形堆疊與大量對一次性任務未必必要的功能。當一個 Agent 只想讀取商品頁、擷取表格或輸出發票 PDF，完整瀏覽器可能像為了寄一封信而啟動一架貨機。

Kitesurf 反過來問：如果預設工作不是「讓人長時間瀏覽」，而是「讓 Agent 在短任務中取得可用的網頁語意與輸出」，最小需要哪些零件？Cloudflare 對它的定位是：

“Think of Kitesurf as an ephemeral, fully-isolated, stateless engine designed to exist only for the duration of a task.”

中文：「把 Kitesurf 想成一個短暫、完全隔離、無狀態，且只在任務期間存在的引擎。」

— Cloudflare Blog

不過「stateless」不能理解成執行期間完全沒有狀態。原文的架構說明明確指出，公開入口 Engine 會保存每個 session 的狀態；每個頁面有自己的 cookie jar，PageScript 也會在 navigation 期間長駐。這裡的無狀態偏向不替不同任務維持長期、持久的瀏覽器人格，以及元件可重建；官方明確說 PageRenderer 不保存 page state、只持有 disposable cache。更準確的說法是：Kitesurf 以短暫任務為中心，而不是一個永遠不保存任何狀態的引擎。這個差異也能和 AlphaLab 的Stateless MCP 與 Edge 架構對照：無狀態常是部署與工作分配策略，不等於單次互動中沒有 session。

---

二、三個主要元件加網路閘道：CDP 是插頭，isolate 是執行單位

Kitesurf 對外露出 Chrome DevTools Protocol（CDP）的 WebSocket／HTTP 介面，因此既有客戶端可以用熟悉的方式送出 Page.navigate、讀 DOM、執行 JavaScript、截圖或產生 PDF。內部卻不是 Chromium，而是官方所稱的三個主要元件，再加上一個網路閘道：

• Engine：唯一公開入口，接收 CDP 指令、管理頁面，並保存當次 session state。
• PageScript：每次 navigation，以及每個 OOPIF，都由 Dynamic Workers 建立 long-lived PageScript isolate；Blitz 與 Stylo 的 Rust 元件編譯成 Wasm，負責 HTML／CSS 解析，解析結果再與頁面 JavaScript 共同建立、更新 DOM。
• SandboxOutbound：唯一能向外連線的元件，處理 CORS、headers、回應過濾與每頁 cookie jar，避免不受信任頁面直接碰到平台網路能力。
• PageRenderer：取得 PageScript 的 scene／draw list，透過 blitz-paint 與 Parley rasterize 成 image buffer，再回傳 PNG、JPEG 或 PDF；只保留可丟棄快取。

這種組合不是把 Chromium 刪掉 UI，而是用相容介面包住另一套選擇性 Web runtime。甚至 eval 目前也有一個過渡層：因 Workers 不允許在網頁執行期間使用原生 eval()，Kitesurf 暫時用 Rust 寫的 Boa JavaScript 引擎處理偶發 eval。它展示了架構的可塑性，也提醒我們 Kitesurf 仍在補齊引擎能力，而不是一套已和 Chromium 對齊的成熟實作。

隔離也不該被外推成「比 Chromium 更安全」。每頁 isolate、OOPIF 與受控網路出口，確實縮小頁面碰觸宿主或其他租戶的路徑；Chromium 則有成熟的多程序 sandbox 與 Site Isolation，兩者防禦模型不同，不能只看「isolate」就排出安全高下。更重要的是，runtime 隔離保護平台邊界，並不會阻止惡意網頁用 prompt injection 誘導 Agent 濫用已被授權的工具。這仍需要Agent 網頁提示注入防線與最小權限設計。

---

三、Cloudflare Kitesurf 的 3–7 倍真相：省的是 CPU／記憶體

Cloudflare 公布的效能表很吸睛，但必須先把單位拆開。官方方法寫的是：跨一組Cloudflare 公開的 14 個 URL執行五次 Browser Run Quick Action runs、取中位數，並以 warm pool 中的 Chromium 比較；文件沒有進一步交代跨網址如何聚合。結果如下：

任務／指標	Kitesurf	Chromium warm pool	正確解讀
Screenshot CPU	380 ms	1,173 ms	Chromium／Kitesurf = 3.1×
HTML CPU	229 ms	877 ms	Chromium／Kitesurf = 3.8×
Screenshot 記憶體	57.8 MiB	271.0 MiB	Chromium／Kitesurf = 4.7×
HTML 記憶體	39.4 MiB	273.7 MiB	Chromium／Kitesurf = 7.0×
Screenshot wall time	1,148 ms	637 ms	Kitesurf／Chromium = 1.8×
HTML wall time	820 ms	472 ms	Kitesurf／Chromium = 1.7×

所以最重要的修正是：Kitesurf 在這組測試裡沒有更快。3.1–3.8 倍是 Chromium 與 Kitesurf 的 CPU 用量比值，4.7–7.0 倍是記憶體比值；真正從呼叫到結果的 wall time 反而多了 70%–80%。這張已披露的基準表也沒有單列 cold start 或啟動延遲，因此不能把 isolate 的架構直覺寫成「已證實啟動更快」。

Corpus 本身也限制了外推範圍。14 個網址包含五種 TodoMVC、example.com、兩個 Cloudflare 自家頁面，以及 HN、Wikipedia、MDN、新聞網站等內容型頁面；它沒有設計專門驗證影片播放、WebGL、登入流程、bot challenge 或重型 SaaS 操作的任務。測試沒有公開每個網站的輸出完整性門檻、逐次數據與 p95，也沒有證明兩個引擎完成了像素或 DOM 等價的工作。這是一個有價值的供應商初測，不是「所有網頁自動化都省 3–7 倍」的證明。

資源密度仍可能是重要進步。當平台要平行處理成千上萬個一次性擷取任務，較低 CPU 與記憶體可以讓同一台機器承載更多工作；但Browser Run 正式方案的 Quick Actions 按 browser hours 計價，Browser Sessions 才另外計 session concurrency。Kitesurf 官方頁面截至 2026 年 8 月 9 日只列免費 beta，未列 beta 後價格。供應商節省的基礎設施成本，是否會變成使用者更低的帳單，現在仍沒有答案。

---

四、約 215,000 個 WPT 通過，不等於 215,000 個網站可用

為了追趕 Web 相容性，Cloudflare 用 Web Platform Tests（WPT）作為開發迴圈。8 月 6 日發布文寫約 215,000 個 WPT tests；8 月 7 日更新的官方文件則寫超過 235,000 個 subtests。這是兩個不同日期、用詞也不同的供應商快照；官方沒有一併公開 run manifest、計數範圍與整體分母，因此不能直接解讀成隔夜固定增加 20,000 個，也不能省略「Cloudflare 自報」。

WPT 能回答某個 DOM、CSS、URL、XHR 或 CORS 行為是否符合規格，不能直接回答一個真實網站能否完整登入、支付、渲染與互動。官方文件自己也提醒，conformance 並不保證每個網站都能工作；發布文則承認 CSS 解析可能略有差異、畫面不一定 pixel-perfect，截圖／PDF fidelity 與更多 Web API 仍在 roadmap。Kitesurf 的可靠性原則甚至偏向「遇到失敗時留下空白 frame 或缺少元素，也不要讓整個 session 死掉」。對批次擷取是可用性取捨，對 UI 回歸或交易流程卻可能變成安靜漏資料。

因此，Kitesurf 的相容性不能只用一個 WPT 總數判斷。Agent 真正在意的是任務級完整性：必要欄位有沒有抓齊、互動後狀態有沒有更新、frame 是否空白、第三方 widget 是否存在，以及缺資料時能否被偵測並回退。這也是為什麼Agent Observability在這類架構裡不是加分項，而是 routing 能否安全運作的前提。

---

五、Kitesurf 不是 Playwright 替代品：要換的是瀏覽器後端

Playwright／Puppeteer 是控制層，Chromium／Kitesurf 才是被控制的瀏覽器後端。Kitesurf 接受一部分 CDP 指令，所以適合的描述是：既有 Playwright 或 Puppeteer 客戶端，可以經 CDP 改連 Kitesurf，並在相容的一次性任務中嘗試替代 Chromium 後端。它不是拿另一套 API 取代 Playwright。

「改一個 endpoint 就全部可用」也不能當成完整相容承諾。Cloudflare 原文明說 Kitesurf 目前只實作 CDP 子集，roadmap 還包括補更多 CDP coverage。Playwright 官方文件則提醒，透過 CDP 連線的 fidelity 明顯低於 Playwright 自己的 protocol，而且 upstream 只正式說支援 Chromium-based browser。另一條 Browser Run SDK 路徑使用 Cloudflare 的 @cloudflare/playwright fork；官方相容性頁列出的不完整能力包括 Playwright Test、Components、Firefox／Android／Electron、其他 Chrome 版本與影片，並註明清單並非全部。這不是 Kitesurf 專屬差異表，但足以提醒讀者：Browser Run 的「Playwright compatible」不等於 upstream 全功能等價。

任務	目前較合理的後端	原因
相容內容頁的一次性 HTML 擷取、PDF、截圖	先試 Kitesurf	正是 beta 的目標工作負載，可換取較低 CPU／記憶體
需要低延遲的多步 Agent loop	實測後 routing	供應商測試中 Kitesurf wall time 較慢，連續步驟可能累積
影片、WebGL	Chromium	官方明列 Kitesurf 尚不適合
要求真實 TLS fingerprint 的 bot challenge	Chromium／站方授權流程	Kitesurf 無法模擬；Browser Run 也不是 stealth 工具
需要持久狀態的長時間登入	Chromium	Kitesurf 的短暫 session 設計不適合
像素級 UI 回歸、關鍵交易流程	Chromium 為主	渲染 fidelity 與缺失元素仍是 tail risk

反機器人邊界也要說清楚。Browser Run 會加入不可移除的識別 headers 與 Web Bot Auth 簽章；官方 FAQ明確表示請求始終會被 Cloudflare 識別為 bot traffic，是否放行由站方的 bot policy 決定；若目標站會攔截，需由站方調整規則或 allowlist。Kitesurf 是透明自動化基礎設施，不是繞過 CAPTCHA、TLS 指紋或 bot management 的 stealth browser。

---

六、Hacker News 在吵什麼？「瀏覽器」可能不是最難的部分

HN 討論比「能不能取代 Chromium」更分散。最大的可見分支其實在問：大家究竟拿 browser agent 做什麼？留言者分享購物車、管理後台、收據、跨網站比較與篩選等案例；另一群人討論底層 Blitz、CDP 與 WebDriver BiDi；還有人質疑這到底算 browser，還是一個更窄的 web-data runtime。這些都是使用者軼聞，不是代表性需求調查。

更尖銳的批評集中在身份與信任：如果自動化流量很容易被辨識，Agent 要如何通過 CAPTCHA、登入、付款與高風險操作？如果頁面內容能指揮 Agent，isolate 是否只是保護 Cloudflare，卻沒有保護使用者免於提示注入？答案是：Kitesurf 只處理其中一層。它可能降低「取得和操作網頁」的資源成本，不會自動解決身份、授權、支付責任與 Agent policy。對真正端到端的 browser agent，後面這些問題很可能比 rendering 更早成為瓶頸。想看完整控制層，可以延伸到 AlphaLab 的AI Agent Browser 架構與登入安全。

社群也關心它是否會開源。Kitesurf 目前本身尚未公開原始碼；Cloudflare 的承諾是準備好後開源，而底層 Blitz 已經開源、repo 仍自稱 pre-alpha。這不等於 Cloudflare 的部署一定不穩，但外部目前無法完整審核 Kitesurf；公開材料也不足以重現同一聚合方式與供應商 CPU／RAM 計量，儘管任何人仍可用公開 API 做自己的端到端測試。beta 階段最重要的問題，不是發布文有多漂亮，而是相容性、fallback 與正式價格何時能被外界驗證。

---

七、AlphaLab 的判讀：它是 workload router，不是通用瀏覽器革命

判讀一：真正的產品單位不是「瀏覽器」，而是完成任務的 lane

Kitesurf 最合理的落點，不是要求團隊在它與 Chromium 之間二選一，而是建立兩條 lane：相容、一次性、容許少量渲染差異的任務先走 Kitesurf；需要影片、WebGL、持久登入、真實 TLS 或高 fidelity 的任務走 Chromium。CDP 讓兩條路能共用部分客戶端程式碼，這才是它對 Agent infrastructure 的真正價值。它和Agent Harness 的 loop／router 設計本質相同：系統不是押注單一模型或單一工具永不失敗，而是根據任務與檢查結果選路。

判讀二：密度與延遲是兩個不同的優化目標

對批次擷取，低 CPU／RAM 可能讓平台同時跑更多 session，1.7–1.8 倍 wall time 未必致命；對一步等一步的 Agent，慢 300–500 ms 若連續累積十次，就會直接傷害互動體驗。Kitesurf 的初步數據指向「提高密度、犧牲單次延遲」的可能交換，而不是全面勝出。團隊該先決定自己要優化的是每台機器吞吐量、使用者等待時間，還是每個成功任務的總成本。

判讀三：相容性的尾端風險，會吃掉平均資源優勢

如果 Kitesurf 成功一次很省，但每十次就有三次漏欄位、重試後仍要回退 Chromium，那真正成本應包含失敗偵測、重試、第二次執行與錯誤輸出的人工處理。最值得追蹤的指標不是 WPT 總數，也不是成功樣本的 CPU，而是 completed-task cost、fallback rate 與 silent omission rate。這三個數字會決定 Kitesurf 是實際降低成本，還是只把成本從算力搬到可靠性工程。

判讀四：Cloudflare 的資源優勢，還沒變成使用者的經濟優勢

免費 beta 適合收集工作負載與補相容性，不能拿來推導正式價格。若日後 Kitesurf 仍按 browser hour 計價，較慢 wall time 甚至可能抵銷部分底層資源節省；若改按成功任務或以較低費率計價，密度優勢才會明確傳到使用者。截至 2026 年 8 月 9 日，官方頁面仍未列 beta 後價格，所以「可能降低大量自動化的成本」是合理方向，不是已證實的 ROI。

---

八、現在怎麼測 Kitesurf，才不會把 beta demo 當 production？

1. 先做 20–50 個代表性 URL 的任務集。不要只選內容頁；加入 SPA、iframe、表單、不同語系、第三方 widget、登入後頁面與你最常失敗的真實案例。
2. 替每個任務定義完整性 gate。檢查必要 selector、欄位數量、文字長度、狀態轉換與截圖區域；空白 frame 或缺少元素必須被判成失敗，不能讓 Agent 帶著殘缺資料繼續推理。
3. 同時量 p50、p95 與整段 loop。不要只看單次 CPU。分別記錄 Kitesurf／Chromium 的 wall time、CPU、記憶體、重試與 fallback，最後算每個成功任務的總資源與等待時間。
4. 把 routing 寫成可回退的政策。影片、WebGL、持久登入、bot challenge 與像素 fidelity 直接走 Chromium；其他任務先跑 Kitesurf，未過 gate 就帶著明確原因回退，避免無限重試。
5. 把身份與安全獨立測試。確認目標站允許 Browser Run bot 流量；用惡意頁面測 prompt injection、工具越權與資料外傳，不要把 isolate 通過當成 Agent 安全通過。

Cloudflare 自己的Kitesurf Playground適合先做相容性快測；要進入工程評估，則應把結果接進可觀測與回歸系統。AlphaLab 先前拆解的Cloudflare OS Agent 工作台也提供一個更大的脈絡：Kitesurf 不是獨立終點，而是 Cloudflare 把 Agent runtime、瀏覽器、權限與邊緣運算組成平台的一塊基礎設施。

---