Kitesurf 把 Workers 變成代理瀏覽器

以前我用完整瀏覽器跑自動化，現在我會先問能不能把它縮成 agent-first browser。

我用 browser automation 一陣子了，老實說，常常覺得自己在養一台太胖的機器。Chromium 要顧、記憶體要盯、timeout 要調，模型還得吞一堆它根本不懂的頁面狀態。能跑是能跑，但每次都像在拿人類用的工具硬塞給 agent。它會點、會填、會跳頁，可是整個流程一直有種不順手的噁心感，像是你明明只想搬一箱東西，卻被迫租了一台貨車。

我最近看了 Cloudflare 的 Kitesurf，第一次覺得這題有人講到骨頭裡。它不是在跟你炫耀怎麼把瀏覽器自動化做得更花，而是在逼你承認：我們一直把人類瀏覽器當成 agent 的預設答案，這件事本身就很怪。Cloudflare 這篇把 Workers、Wasm、Durable Objects、worker-to-worker RPC 串起來，我讀完只剩一句話：原來可以不要那麼笨重。

我先把 Chromium 當成預設值這件事丟掉

Browser engines like Chromium were built for humans, not agents, and they come with overhead that AI models simply do not need.

這句話我很買單。翻譯一下就是，Cloudflare 不是想把 Chrome 修得更快，而是在懷疑整個前提：agent 真的需要完整的人類瀏覽器嗎？

我自己踩過太多這種坑。很多任務其實只需要導航、讀 DOM、填表、送出、拿結果，結果我們卻先拉一個完整桌面級引擎進來，再一路用 Playwright、截圖、重試去補洞。能做，但成本很不乾脆。你不是在做 automation，你是在替一個本來不該存在的巨大 runtime 找理由。

Cloudflare 的意思很直白：agent 需要的是 browser primitives，不是人類那套完整視覺與相容性包袱。人類瀏覽器在乎的是字型、影片、外掛、標籤頁、各種怪站相容；agent 在乎的是狀態可控、執行可重現、啟動夠快、成本夠低。這兩個目標本來就不同，硬混只會讓你多付錢。

我之前幫一個內部流程做自動化，前半段只是登入、找資料、複製結果。整套流程最麻煩的不是 AI 不會操作，而是 browser 太大台，session 一多就開始不穩。那時我才真的懂，很多時候問題不在模型，而在你拿錯工具。

實操寫法很簡單：先列出你真的需要的 browser 能力，像是 navigation、form input、script execution、screenshot、session persistence。只要你回答「差不多就是 Chromium 吧」，我會直接叫你停一下。先砍需求，再談 runtime。

• 把任務拆成 browser primitives，不要直接對齊整個 UI stack。
• 把 rendering fidelity 跟 automation 能力分開想。
• 先量 memory、startup time、retry 成本，再決定要不要上完整 Chromium。

Wasm 在 Workers 裡成熟了，這才是底層條件

Cloudflare 在文中很明白地說，WebAssembly in Workers is now very mature。這不是順手帶過的背景句，這是整個架構能站起來的地基。

它們還提到 dynamic workers、SQLite-based Durable Objects、worker-to-worker RPC、service bindings、Node.js 相容性提升，還有更高的限制。這些字看起來很 boring，但我反而覺得這才是重點。沒有這些底層能力，你根本不可能把 browser-shaped workload 放進 edge runtime 裡，還期待它不要炸。

我見過太多平台嘴上說支援 advanced workloads，結果一碰到 state、isolated execution、concurrency 三件事一起來，就立刻露餡。Cloudflare 這次的訊號是：Workers 不再只是跑輕量函式，它已經可以承接更像 browser runtime 的工作，只是你要用對方式。

這代表 browser 不必再站在系統外面當一個特例。它可以跟 agent orchestration、state store、routing、RPC 放在同一個平台裡。架構一旦收斂，glue code 就少，延遲就少，debug 也比較不會像在追鬼。

實操寫法：如果你現在做 agent infra，先別把「browser service」跟「agent service」切成兩個宇宙。把 stateful 的東西放回 runtime 原生支援的地方，能用 Wasm 的就用 Wasm，能用平台內建 state 的就別再自己外掛一個 sidecar DB。

• 讓 browser execution 盡量靠近 agent orchestration。
• 優先使用平台原生 state，而不是每層都外接資料庫。
• 用隔離執行單元取代一個超長壽命的大 process。

Cloudflare 真正在意的是成本密度

這篇最實際的地方，是它沒有只談能力，還直接碰成本。agent 需要 browser 才能做事沒錯，但如果每個 session 都得扛一個完整 Chromium，那很多 use case 根本做不起來。

我很常看到 agent demo 很漂亮，因為它只跑一個 session、一條 happy path。等你真的要上量，記憶體、CPU、cold start、retries 全部一起冒出來，然後你就開始像在配給瀏覽器使用權。這很荒謬，因為 browser 本來應該是 agent 的手，不是公司裡最貴的稀有資產。

Cloudflare 的方向是把 browser access 壓到一個夠低的成本，讓它能變成更普遍的基礎能力，而不是只有大模型、大預算才玩得起的功能。這件事很現實。只要 browser access 還是昂貴門票，agent automation 就會卡在少數團隊手上，做不成真正可擴張的基礎設施。

我自己看系統時，現在都會直接問 task cost，不看 instance cost 而已。因為一個 browser task 的真實成本，包含 idle memory、cold start、重試、session 保活、失敗後重跑。你只看單次執行，常常是在自我安慰。

實操寫法：把設計目標改成 density。短生命週期 session、可預測的啟動、明確的回收、能重試但不依賴人工盯場。你越早把 browser 當成大量可消耗的 runtime，而不是珍貴器材，系統越容易長大。

重點其實是控制面，不是畫面有多像

Cloudflare 其實早就有 Browser Rendering 這類 headless browser automation API，這次 Kitesurf 不是否定它，而是把問題重新定義。它說的是：AI 起來之後，browser 的角色變了。

我最在意的也是這個。傳統 browser automation 很愛講 rendering、compatibility、像不像真的人類在看頁面。可 agent 真正在乎的是控制面：我能不能讀 state、能不能下指令、能不能回復、能不能穩定重播。這些東西比畫面長得像不像更重要。

我以前做過一個流程，頁面看起來完全正常，截圖也沒問題，結果 agent 就是找不到按鈕。後來我才承認，這不是 rendering 問題，這是 control problem。當 browser 太重、太黑箱、太像人類工具，agent 就會一直被環境拖住。

Cloudflare 這種 agent-first browser 的思路，是把最小但夠用的控制能力交給 agent：夠用的 DOM、夠用的 state、夠用的 scripting、夠用的 introspection。不是把整個人類網頁瀏覽體驗搬過來，而是把 task 完成所需的控制點留下來。

實操寫法：你評估 browser tooling 時，不要先看它能不能把網頁渲染得漂漂亮亮。先問：agent 能不能不靠截圖就讀狀態？能不能 deterministic replay？失敗後能不能局部恢復？如果答案都不漂亮，你買到的還是人類瀏覽器。

這是一個更短的 agent loop

我覺得 Kitesurf 最有價值的地方，是它把 agent 跟 page 之間的 loop 壓短了。agent 思考，browser 執行，結果回來，下一步再做。這個 loop 一旦拉遠，整個系統就開始變笨、變慢、變貴。

Cloudflare 的平台組合剛好對上這件事：Workers 靠近 edge，Wasm 提供受控執行，Durable Objects 管 state，RPC 和 service bindings 負責串接。Kitesurf 不是孤立的產品，它是這堆東西湊在一起後，長出來的一個合理結果。

我很喜歡這個方向，因為它符合我看過最多的失敗模式。agent 通常不是死在模型不夠聰明，而是死在 loop 太慢、state 太散、browser session 一下就掉。你把 loop 縮短，debug 就容易很多，agent 也比較不會像一個在等回音的白癡。

這代表 browser 不再是遠端 appliance，而是分散式應用裡的一個本地能力。對 iterative automation 來說，這比什麼 fancy demo 都實在。

實操寫法：把 browser execution 盡量跟 decision layer co-locate。每一次 click 都不要跨太多服務。session 要持久就明確持久，不要靠一堆隱性狀態撐著。你要的是穩定 loop，不是華麗架構圖。

我把它當成 agent-native infra 的模板

我現在對 Kitesurf 的解讀，不只是一個 browser launch。它更像 Cloudflare 在說：app runtime 跟 automation runtime 的分界，正在變得很浪費。agent 一旦是產品的一部分，browser 就會變成 runtime 裡的一個普通執行目標，只是它剛好需要 state、隔離、低成本、靠近系統核心。

這也是為什麼我不會把這篇當成單純的 browser 新聞。我會把它看成平台策略：Cloudflare 把 AI、Workers、browser automation 三條線收成一條。這很合理，因為你既然已經有 edge compute、state、RPC，再把 agent-first browser 放進來，整套 stack 就完整了。

當然，我還是會追問一堆實務問題。高負載下穩不穩？隔離邊界多硬？支援的 web 範圍有多大？失敗模式是什麼？這些都不是看概念圖就能知道的。但方向我認為是對的，而且是那種我會願意拿來做系統設計的方向。

實操寫法：回頭檢查你現在的 agent stack，標出所有 browser work 離開主 runtime 的地方。那些 seam 就是 latency、錢、可靠性在流血的地方。能收回來的，先收回來。

• 把 browser 當 runtime 的一部分，不要當外掛服務。
• 把 state 留在原生可控的地方。
• 把控制面縮短，讓 agent 跟 page 互動更直接。

可抄的模板

# Agent-first browser 設計模板（可直接改成你自己的架構文件）

## 1. 先定義 browser 的任務
- 導航到目標頁
- 讀取 DOM 與頁面狀態
- 填表與送出
- 執行必要腳本
- 擷取結果或截圖
- 保留最小 session 狀態

## 2. 刪掉人類才需要的東西
- 不依賴 extension
- 沒必要就不要完整桌面渲染
- 不假設有人在看畫面
- 不把人工介入寫進 happy path

## 3. 把 browser 放進 agent 同一層 runtime
- browser execution 跟 orchestration 放同平台
- state 用原生 durable storage
- 用 RPC 或 service bindings 做本地協調
- 每一步操作都避免多餘 network hop

## 4. 用密度思維看成本
- session 盡量短命
- 量 memory per session
- 量 startup latency
- 量 retry cost
- 量每個完成任務的總成本

## 5. 把控制能力做清楚
- 提供 DOM inspection
- 提供 action API
- 提供可回復的 session state
- 支援 deterministic replay
- 定義失敗後怎麼恢復

## 6. 評估 browser stack 時直接問這些
- 我真的需要完整 Chromium 嗎？
- 這能不能跑在 Wasm 類型的隔離 runtime？
- state 到底放哪裡？
- 多一個 session 的成本是多少？
- 從 1 變 1,000 會先壞哪裡？

## 7. 預設架構
Agent
- 做決策
- 發送 action 給 browser runtime
- 接收 page state
- 更新 memory / store
- 重複直到任務完成

Browser runtime
- 隔離執行
- 最小權限
- 短生命週期 session
- 明確 state handoff

Storage
- session metadata
- task logs
- replay data
- recovery checkpoints

這版我會直接拿去改成團隊的設計草稿。它的好處很土，但很有用：browser 變小、state 變明確、loop 變短，agent 才不會一直在那邊跟系統互相折磨。

來源是 Cloudflare 官方文章 https://blog.cloudflare.com/kitesurf/，相關平台文件也可看 Workers、Durable Objects、RPC。上面這篇是我根據原文做的方法論拆解，模板段落是我自己整理成可落地版本。