Browserbase vs Lightpanda：headless browser 怎麼挑

把瀏覽器塞進 AI agent 工具鏈這幾年變成主流選項。LLM 自己會 reasoning、寫 code、呼叫 API，但只要任務需要登入後台、跑 SPA、把表單填到後送，最後還是得開一個 browser 出去。問題是 Chrome headless 不是為這個場景設計的——它本來服務的是「人在看」的網頁，所以 GPU、字型、layout、動畫、合成圖層通通要算，跑 100 個 instance 你會看到 RAM 條跟著爆掉。

最近兩個極端方向的產品同時冒出來：Browserbase 把 browser 變成完全託管的 SaaS、靠規模平攤運維成本；Lightpanda 走另一條路，乾脆用 Zig 從零寫一個只給機器讀的 headless browser，把 GUI render、CSS layout、圖片字型那些「給人看的」全部砍掉，只保留 DOM、JavaScript、HTTP、CDP，省到 123 MB 一隻 instance、9x faster than Chrome 的等級。

這篇想把兩邊的技術選擇、效能數據、定價結構、適用情境攤開比一比。我自己最近在規劃內部 agent 平台時剛好碰到這個分岔點，把研究筆記整理一下方便之後其他人省時間。

一、為什麼 Chrome headless 不夠用

Chrome headless 的核心價值是「跟一般 Chrome 行為一致」——這對網頁測試、視覺回歸測試很重要，因為你要的是 user 看到什麼你就跑什麼。但對 AI agent 場景，這個一致性反而變成成本：

• 整個 GPU 合成 pipeline 還在跑，即使沒有顯示
• 字型載入、文字 layout、CSS 計算照做
• 圖片、影片、字型 asset 全下載
• 動畫、過場、scroll behavior 全都模擬

實測一個典型 Chrome headless instance 跑起來會吃 250-500 MB 記憶體，AWS m5.large（8 GB RAM）大概只能塞 15-20 個 concurrent。要做大規模 scraping 或 agent fleet，光 EC2 帳單就會嚇人，更別提還要處理 IP rotation、captcha、proxy、session 持久化這些運維事。

於是市場分裂出兩條解法：

SaaS 解（Browserbase）：你不要管那些，我幫你跑、幫你 rotate、幫你解 captcha、給你一個 connection URL。

自寫解（Lightpanda）：與其優化 Chrome，不如砍掉 90% 給人看的功能，只留 LLM 真的會用到的部分。

二、Browserbase：把瀏覽器變成 API

2.1 規模與定位

Browserbase 是這個賽道目前規模最大的玩家。根據官網最新數字：

• 36.9 million unique browser sessions（2026 年 3 月單月）
• 每週 800,000 次 SDK 下載
• 100,000+ 開發者
• 客戶名單包括 Microsoft、DeepMind、Clay、Amplitude、Ramp、Lovable

它把 Chrome 包成 BaaS（Browser-as-a-Service），你的 agent 用 Puppeteer 或 Playwright 連到 Browserbase 給的 WebSocket endpoint，剩下的 chrome instance lifecycle、proxy rotation、residential IP、auto-captcha solving、stealth mode 全部由它處理。

開源生態系也算用心：他們維護了 Stagehand（agent-friendly browser framework）、Director（觀察 / debug UI）、Browse CLI 這幾個工具，目的是讓你寫 agent 不用碰太多底層細節。

2.2 定價結構

從官網 pricing 頁面拉出來的 4 個 tier：

• Free：$0、3 並發、1 browser-hour、1k Search calls、1k Fetch calls、session 上限 15 分鐘、資料保留 7 天
• Developer：$20/月、25 並發、100 browser-hours（超量 $0.12/hr）、auto-captcha
• Startup（Most Popular）：$99/月、100 並發、500 browser-hours（超量 $0.10/hr）、5 GB proxy、auto-captcha
• Scale：客製、250+ 並發、HIPAA BAA / DPA / SSO 等企業合規

對「我的 agent 一天跑幾百次、最多十幾個並發」的個人 / 小團隊用，Developer 或 Startup 完全夠。但量一旦上去——例如一天跑幾萬次 scraping、500 並發——帳單會線性成長到一個月幾千美金。這就是後面要談的「成本拐點」。

2.3 為什麼會有人付這個錢

託管的真正價值不是 Chrome 本身，是反爬蟲對抗。

實務上做 web automation 最痛的不是寫 Puppeteer code，是處理：

• Cloudflare、PerimeterX、DataDome 這類 bot detection 一直更新
• residential IP rotation、各國 geo
• captcha solving（圖片、reCAPTCHA、hCaptcha 多種）
• TLS fingerprint、navigator.webdriver、canvas fingerprint 等識別點
• 一被偵測就要換 IP、換 user-agent、改 fingerprint 重來

這些東西要自己維護是個全職工作。Browserbase 把這層抽象掉，你的 agent 寫得好像在跑 Puppeteer，背後它幫你處理所有反爬鬥智。所以說它賣的不是 Chrome，是「規模化的 stealth 能力」。

三、Lightpanda：用 Zig 從零寫一個 AI 用的瀏覽器

3.1 設計哲學：給機器看，不給人看

Lightpanda 在官網第一句寫的是「The first browser for machines, not humans」。它不是 Chromium fork、不是 WebKit fork、不是基於 servo，而是用 Zig 從頭寫一個 browser engine。

從 GitHub 看程式碼結構：75% Zig、其餘 Rust 與 HTML。執行流程裡保留：

• HTTP loading（用 libcurl）
• HTML5 parsing
• DOM tree 建構與操作
• JavaScript 執行（V8 引擎，含 snapshot 加速啟動）
• AJAX（XHR / Fetch API）
• DOM dumping 成 HTML / Markdown
• Chrome DevTools Protocol（CDP）server，預設 :9222
• 滑鼠點擊、表單輸入、cookie、custom header、proxy、network interception、robots.txt

明顯砍掉的：

• GUI rendering（沒有 raster pipeline）
• CSS layout 計算
• 圖片、字型、影片載入
• 視覺合成、scroll behavior、動畫

這個切割很乾脆——只要你的場景是「LLM 需要讀 DOM、執行 JS、跟 API 互動」，這些被砍的東西本來就用不到。

3.2 為什麼是 Zig

Zig 比 Rust 更貼近 C 的記憶體模型，對 systems programming 的 binary size 與啟動延遲控制更直接。對一個強調「instant startup、minimal footprint」的 browser 來說，Zig 比 Rust 多了幾個關鍵優勢：

• 編譯出來的 binary 小很多（沒有 borrow checker overhead）
• 啟動延遲低（cold start 對 short-lived agent task 很重要）
• 跟 V8 / libcurl 這類 C 介面整合最直接

當然代價是生態圈遠比 Rust 小、開發人才稀少。對 Lightpanda 自己作為 contributor 來說是負擔，但對使用者完全沒影響——你接的是 CDP，跟底層用什麼語言寫無關。

3.3 性能數字

官方在 2026 年 1 月發過一個 benchmark report，跑 933 個真實網頁、每次 25 個 concurrent、走 chromedp 量測，環境是 AWS m5.large EC2：

• 執行時間：Lightpanda 5 秒 vs Chrome headless 46 秒，9x faster
• 峰值記憶體：Lightpanda 123 MB vs Chrome 2 GB，16x less

DeveloperHub.io 在 2026 年 4 月發了案例：他們把 prerender service 從 Chrome headless 換到 Lightpanda 後，pages serve 4x faster、load average 下降 10x。

換算成基礎建設成本：原本要 20 台 m5.large 的 Chrome fleet，理論上 2-3 台 Lightpanda 就扛得住同樣 throughput。當然這是 best case，實際要看你的網頁是不是依賴 CSS layout 才能 scrape（後面 §6 會談）。

3.4 Drop-in Puppeteer / Playwright 相容

Lightpanda 實作完整的 Chrome DevTools Protocol，意思是你現有 Puppeteer / Playwright code 幾乎不用動：

# 原本
const browser = await puppeteer.connect({
  browserWSEndpoint: "ws://localhost:9222"
});

# 換成 Lightpanda
$ lightpanda serve --port 9222
# 然後一樣那行 puppeteer.connect 就接上了

Vercel、Dust、Trigger.dev 都已經把 Lightpanda 整合進自己的框架。從框架商背書這點看，CDP 相容性沒有重大問題，可以當 production drop-in 看待——不過要記得 Lightpanda 自己標 Beta，下一節談這個。

3.5 Beta 階段的真實狀態

GitHub README 老實寫著：「Lightpanda is in Beta. Stability and coverage are improving. You may still encounter errors or crashes.」

從 issue tracker 看，目前主要問題集中在：

• 部分 Web API 還沒實作（網頁有「上百個 Web APIs」，coverage 還不齊）
• 某些 SPA 的 hydration 流程依賴 Lightpanda 還沒支援的瀏覽器行為
• 偶發 JS 執行 crash，要自己加 retry

如果你的 use case 是高同質性的網頁（例如固定幾個目標網站做 scraping），Lightpanda 大概九成跑得起來；如果是高度多樣化的「LLM 會去任何網頁」場景，目前還是要保留 Chrome headless 當 fallback。

四、定位光譜：從 Lightpanda 到 Browserbase 之間還有誰

兩邊不是只有這兩家，順便補一下其他相關玩家的位置。

• Steel：開源 + SaaS 雙模式，比較像「half-managed」，自架也有、雲端也有
• Anchor Browser：和 Browserbase 很像的競品，主打 enterprise
• Browser Use：agent 框架，不是 browser 本身
• nodriver：Python 生態的 stealth Chrome 包裝
• Crawl4AI / Firecrawl：偏 scraping 場景，把 LLM 友善的 markdown 抽取做進去
• Skyvern：agent + browser 整合方案

光譜兩端是 Lightpanda（極致自架 / raw performance）和 Browserbase（極致託管 / reliability without ops），中間 Steel 提供折衷、Crawl4AI 偏垂直化於 scraping。

選型決定的關鍵不是「哪個最好」，是「我的瓶頸在哪」：

• 瓶頸是 infra cost → Lightpanda
• 瓶頸是 anti-bot 對抗 → Browserbase
• 瓶頸是 資料合規 / 不能外送 → Lightpanda（self-host）
• 瓶頸是 沒人力做運維 → Browserbase
• 瓶頸是 要全功能 render（截圖、PDF、SPA） → Chrome headless 或 Browserbase

五、實務切換的踩雷

把現有 Puppeteer 服務切到 Lightpanda 時遇過幾個典型問題，列出來給之後想試的人省時間。

SPA hydration：某些 React / Vue SPA 在 hydration 階段需要等 layout、measure DOM 尺寸，Lightpanda 沒有 layout engine，這條 code path 會卡或拋 exception。解法是改寫 wait 條件，從等 layout-dependent event 改成等網路 idle 或特定 selector 出現。

CSS-aware scraping：如果你的 scraper 邏輯靠 getBoundingClientRect() 或 offsetWidth 來判斷元素是否可見、是否在 viewport，Lightpanda 都會回 0。這類邏輯要重寫，改用 DOM tree 結構判斷而不是視覺位置。

截圖與 PDF：完全不支援。需要這些功能就要回 Chrome 或 Browserbase。

檔案上傳：CDP 的 file upload 流程在 Lightpanda 還沒完全實作（依版本而定），實測下來有些 case 會 hang。

Captcha：Lightpanda 沒有內建 solving，所以遇到 captcha 站點要自己接 2Captcha 或 Anti-Captcha 這種第三方 solver；Browserbase 是內建 auto-captcha solving。

實務上如果是混合場景（80% 簡單頁面 + 20% 麻煩頁面），可以做雙路徑：簡單頁面走 Lightpanda 省成本，麻煩頁面 fallback 到 Chrome 或 Browserbase。架構上加一個 dispatcher 判斷網域決定走哪條路，整體成本可以壓很低又保住完整 coverage。

六、AI agent 場景的成本拐點

回到開頭那個問題：規模上來之後，Browserbase 的成本成長曲線怎麼看。

舉個粗略的算式（不是官方數字，僅供推估）：

• 假設 agent 一天跑 10,000 次 browser session，每次平均 2 分鐘
• Browserbase Startup tier $99/月 包 500 browser-hours，超量 $0.10/hr
• 這個 workload 一個月 ≈ 10,000 × 30 × 2/60 = 10,000 hours
• 帳單 ≈ $99 + (10,000 - 500) × $0.10 = $1,049/月，加上 proxy 額外計費

同樣 workload 用 Lightpanda 自架估：

• 兩三台 m5.large（共 8 vCPU、16 GB RAM）大約 $200/月（reserved instance 更便宜）
• 自己處理 proxy、anti-bot 額外加 $200-500（買 residential proxy 服務或自架）
• 工程運維成本：每月幾天的維護時間

純帳單看 Lightpanda 約 50% 便宜；但加上工程時間、anti-bot 失敗導致重跑的 cost、需要自己處理 captcha 等等，實際差距會縮小。Browserbase 的 pitch 不是「最便宜」，是「不用你管」。

我自己的判斷分界：

• 月帳單 < $500：Browserbase（不值得自己維運）
• 月帳單 $500-3000：看資料合規與 anti-bot 強度，兩邊都合理
• 月帳單 > $3000：Lightpanda 自架的 ROI 開始明顯，可以開始投資自己的 browser fleet

七、何時還是該用 full Chrome

聊完了兩個極端，留一段給「兩邊都不適合」的場景。有幾類情境目前還是建議直接用 full Chrome 或 Browserbase 後面那條 Chrome stack：

視覺回歸測試：你需要拿 Chromium 渲染出的 pixel 跟 baseline 比對。Lightpanda 沒有 raster pipeline，整條路走不通。

SPA 高度動態渲染：例如 Next.js App Router、Nuxt SSR 加上 client-side hydration 大量依賴 layout 計算的場景，這類網頁在 Lightpanda 上的相容性還不穩，跑得起來但常常 hydration 失敗。

檔案上傳 / 下載操作：CDP 的 file upload 流程在 Lightpanda 還是 partial 支援，PDF 下載、自動填表上傳照片這類操作目前比較吃力。

需要 service worker 行為：例如某些 PWA 的離線快取、推播驗證流程，Lightpanda 對 service worker 與 web push 的支援還沒到 production-ready 等級。

截圖 / PDF 匯出：如同前面提到，沒有 render 就沒有截圖。需要這類功能直接走 Chrome。

WebRTC / WebGL / 音訊互動：目標網頁如果用到 WebRTC（例如某些線上會議介面、即時影音站台）或 WebGL canvas（線上 3D 建模、地圖軌跡），Lightpanda 的引擎完全不處理這層，硬接會直接 fail。Browserbase 後面是真 Chrome，這幾個 API 都還在。

實務上「全 Chrome」這條路依然會佔一段時間的市場，只是它從「預設選項」變成「特殊需求才用的選項」。

八、結語

挑 headless browser 這件事，過去十年答案幾乎都是「裝 Puppeteer 接 Chrome」。但 AI agent 把使用情境推到極端：高並發、低互動、機器讀為主，這些都不是 Chrome headless 原本被設計來服務的場景。

Browserbase 走 SaaS 化、把所有 ops 抽象掉，用規模壓成本；Lightpanda 走 minimalism、用 Zig 從零寫一個只給機器用的 browser，效能贏 Chrome 一個數量級。兩個方向都對，端看你的瓶頸在哪。

未來幾年我預期會看到更多分裂——可能會有針對特定領域進一步特化的 browser 出現（例如專做 e-commerce scraping 的 vertical browser），也可能會看到 Lightpanda 這種 minimalist 方向繼續吃下原本 Chrome headless 的市場。對我自己的 agent 平台規劃，目前打算先在 staging 用 Lightpanda 跑簡單 task、production 麻煩 task 仍走 Browserbase，等 Lightpanda Beta 穩定後再看要不要把更多 workload 遷過去。整體節奏會比較像漸進切換，先用 Lightpanda 跑 80% 高同質性的任務、留 20% 高難度給 Browserbase 兜，慢慢觀察 Lightpanda 在這 80% 上的崩潰率與例外處理成本，再決定下一階段比例。

參考資料

• Lightpanda 官網：https://lightpanda.io/
• Lightpanda GitHub repo：https://github.com/lightpanda-io/browser
• Lightpanda benchmark blog（933 pages）：https://lightpanda.io/blog
• Browserbase 官網：https://www.browserbase.com/
• Browserbase 定價：https://www.browserbase.com/pricing
• OpenAlternative Lightpanda 條目：https://openalternative.co/lightpanda
• Chrome DevTools Protocol：https://chromedevtools.github.io/devtools-protocol/