摘要： Cloudflare 於 2026 年 11 月 13 日宣布，把專為 AI agent 設計的無狀態瀏覽器 Kitesurf 以 Apache 2.0 授權開源到 GitHub。它完全跑在 Workers 上，不需要瀏覽器容器，就能解析 HTML、套用 CSS、執行頁面 JavaScript 並渲染截圖。對手上正在維護瀏覽型 agent 的小團隊來說，多了一個可以自己部署、可以離開的輕量選項。
為 agent 而生的瀏覽器怎麼運作
Kitesurf 在今年 8 月首次發表，9 月加入 WebMCP 支援、新 API 與相容性改進。這次開源後，儲存庫裡的結構看得清楚：整個引擎是一套編譯成 WebAssembly 的 Rust 套件生態系——Blitz 負責 HTML 解析、DOM、版面與繪製；Stylo 負責 CSS 解析與樣式計算；Boa 則在 WebAssembly 裡執行 JavaScript，但只作為最後手段，用在無法於 Dynamic Workers 跑 JavaScript 的情況。另外 Linebender 系列函式庫處理文字排版與 2D 圖形，Krilla 產生 PDF 輸出。
架構上分三個主要部分：Engine 管理瀏覽器工作階段與用戶端連線，PageScript 負責執行頁面及其 JavaScript，PageRenderer 負責畫出結果。對外的介面是 Chrome DevTools Protocol（CDP），所以既有的 Puppeteer 或任何 CDP 用戶端都能直接接上——先前我們談過 Google 把代理開發帶進終端機，CDP 正是這類 agent harness 常見的驅動介面。
本機跑起來是一個下午的事
照儲存庫的建置需求 clone 下來、安裝依賴後啟動即可：
git clone https://github.com/cloudflare/kitesurf.git
cd kitesurf
pnpm install --frozen-lockfile
pnpm run dev第一次建置要編譯 Rust 核心，需要一點時間，之後會重用建置快取。接著 wrangler 會在本機 http://127.0.0.1:8787 起一個開發伺服器，用 Puppeteer 連上 websocket 就能導頁、截圖：
import puppeteer from "puppeteer-core";
const browser = await puppeteer.connect({
browserWSEndpoint: "ws://127.0.0.1:8787/devtools/browser",
});
try {
const page = await browser.newPage();
await page.goto("https://example.com/");
await page.screenshot({ path: "page.png" });
} finally {
await browser.disconnect();
}或者把你的 AI harness 直接指向本機 CDP 連接埠，讓 agent 接管整個瀏覽器。
部署之前，先算兩筆帳
要部署到自己的 Cloudflare 帳號，文件明確說需要 Workers Paid 方案，因為 Kitesurf 用 Dynamic Workers 為每個頁面建立隔離的 Worker。也就是說，自建這條路有最低門檻，不是零成本試玩；好消息是本機開發伺服器不花錢，足夠完成第一輪驗證。
第二筆帳是成熟度。Cloudflare 自己說 Kitesurf 仍在密集開發中，重點放在提升相容性（他們指向 Web Platform Tests 的演進）、可靠度與效率。至於它相較 Chromium 實際省下多少 CPU 與記憶體，公告只陳述了目標，沒有附上獨立數字——真實網站能不能正確渲染和執行 JavaScript，得自己驗。
我們的看法： 把它當成一個便宜、可逆的實驗，而不是一次遷移。如果你的 agent 目前靠無頭 Chromium 跑瀏覽任務，每個工作階段都在付容器的 CPU 和記憶體，那麼花一個下午在本機把現有 CDP harness 指向 Kitesurf、跑幾個真實任務，門檻夠低，值得現在做——假設你的任務主要是一般網頁讀取與截圖，而非重度依賴複雜前端行為。兩類團隊可以先跳過：agent 根本不瀏覽網頁的，以及已經有穩定瀏覽器基礎架構、不想引入一個密集開發期相依套件的。反轉這個建議的條件很具體：如果實測發現你的關鍵網站渲染失敗或 JavaScript 跑不動，輕量的省費就失去意義，屆時等 Web Platform Tests 相容性數據改善再回來看。