browser-harness、Playwright、Puppeteer 怎麼選？瀏覽器自動化工具對比

Sun, 24 May 2026 17:51:28 +0800

在瀏覽器自動化和自動化測試領域，Playwright 和 Puppeteer 是最常被拿來比較的兩個工具。它們都可以控制瀏覽器、點擊頁面、抓取內容、產生截圖或 PDF，也都和 Chrome DevTools Protocol 有很深關係。

但如果把 browser-use/browser-harness 放進來，問題就不只是「哪個測試框架更強」，而是變成兩類工具的對比：

Playwright / Puppeteer：面向人類工程師寫確定性腳本。
browser-harness：面向 AI Agent 操作真實瀏覽器。

前者適合測試、爬蟲和工程化自動化；後者更像給 Claude Code、Codex CLI、Gemini 這類 Agent 準備的瀏覽器控制層。

Playwright 和 Puppeteer 的關係

Puppeteer 最早由 Google Chrome 團隊推出，天然服務於 Chromium 和 Chrome 自動化。它的 API 簡潔，生態成熟，特別適合圍繞 Chrome 做截圖、PDF、頁面抓取和輕量自動化。

Playwright 由 Microsoft 維護，背後團隊和早期 Puppeteer 有很深淵源。它吸收了 Puppeteer 的很多經驗，同時把跨瀏覽器、自動等待、上下文隔離、測試報告和調試工具鏈做得更完整。

簡單說：

只圍繞 Chrome 做輕量任務，Puppeteer 仍然很順手。
做跨瀏覽器 E2E 測試、複雜 SPA 自動化和團隊測試工程，Playwright 通常更合適。

核心區別總覽

維度	Puppeteer	Playwright
主導方	Google	Microsoft
瀏覽器支援	主要面向 Chrome / Chromium	Chromium、Firefox、WebKit
語言支援	主要是 JavaScript / TypeScript	JavaScript / TypeScript、Python、Java、.NET
自動等待	需要更多顯式等待	Locator 和 auto-waiting 更完整
多上下文隔離	支援，但不是最突出的優勢	BrowserContext 體驗很強
工具鏈	簡潔、成熟、偏基礎	Codegen、Trace Viewer、測試報告更完整
典型場景	Chrome 自動化、截圖、PDF、輕量抓取	跨瀏覽器 E2E 測試、複雜前端應用自動化

瀏覽器支援

Puppeteer 的優勢在 Chrome。它和 Chromium 結合緊密，如果你的目標就是控制 Chrome、產生 PDF、截圖、跑簡單爬蟲，Puppeteer 的心智負擔很低。

Playwright 的優勢在跨瀏覽器。它原生支援 Chromium、Firefox 和 WebKit。WebKit 這一點很關鍵，因為很多 Safari 相關問題不能只靠 Chrome 測出來。對需要覆蓋桌面端、行動端和不同瀏覽器核心的應用來說，Playwright 更適合作為主力工具。

這也是兩者選擇的第一道分界線：只看 Chrome，可以用 Puppeteer；要認真做跨瀏覽器測試，優先 Playwright。

自動等待與穩定性

瀏覽器自動化最煩人的問題，往往不是「不會點擊」，而是頁面還沒準備好。元素可能還沒掛到 DOM，可能被遮擋，可能正在動畫中，可能按鈕還是 disabled。

Puppeteer 裡經常會寫：

1
2

await page.waitForSelector('#submit-btn');
await page.click('#submit-btn');

這沒有問題，但等待邏輯需要工程師自己想清楚。頁面越複雜，腳本裡越容易出現各種 waitForSelector、waitForTimeout 和重試邏輯。

Playwright 的 Locator 機制和自動等待更完整：

`1`	`await page.locator('#submit-btn').click();`

在點擊之前，Playwright 會自動檢查元素是否可見、可操作、穩定、沒有被遮擋，並在合理時間內重試。這對 React、Vue、Next.js 這類非同步渲染很多的現代 Web 應用尤其重要，可以明顯減少 flaky test。

多帳號和上下文隔離

如果你要模擬多個使用者，或者想讓多個任務共享同一個瀏覽器行程但隔離 Cookie、LocalStorage 和 Session，BrowserContext 就很重要。

Puppeteer 也支援上下文隔離，但 Playwright 把這件事做成了核心能力。你可以在一個瀏覽器實例裡快速建立多個獨立 context，每個 context 像一個乾淨的瀏覽器環境，卻不需要反覆啟動完整瀏覽器行程。

這對這些場景很有價值：

多帳號並發測試。
多角色協作流程測試。
電商、IM、協作文檔等多使用者場景。
需要隔離 Cookie 和登入狀態的爬取任務。

工具鏈差異

Playwright 是更工程化的方案。它內建了很多測試開發會用到的工具：

codegen：在網頁上操作，自動產生腳本。
Trace Viewer：失敗後回看每一步的截圖、DOM、網路請求和 console 日誌。
Test Runner：支援斷言、並行、重試、報告和專案矩陣。
Locator：支援按文字、角色、label、test id 等方式定位元素。

Puppeteer 則更像一個輕量瀏覽器控制庫。它不臃腫，API 直接，適合嵌入腳本、服務端任務和自定義自動化流程。

如果你要搭企業級測試體系，Playwright 的配套工具會省很多事。如果你只是要寫一個 Node.js 腳本，把網頁轉 PDF 或定時截圖，Puppeteer 反而更乾脆。

browser-harness 放在哪裡

browser-harness 和 Playwright、Puppeteer 不是同一類工具。

Playwright 和 Puppeteer 主要假設「人類寫腳本」。人類工程師要決定選擇器、等待條件、斷言邏輯和異常處理。它們追求的是確定性：同樣的腳本，在同樣的頁面狀態下，應該給出同樣的結果。

browser-harness 主要假設「AI Agent 操作瀏覽器」。它的目標不是提供一套巨大的高階 API，而是透過 CDP 連接真實 Chrome，把截圖、座標點擊、DOM、網路請求和 helper 暴露給 Agent。Agent 可以觀察頁面、判斷下一步、遇到缺能力時補 helper，再把站點經驗沉澱成 skill。

這就讓它更適合開放任務：

登入後台後下載帳單。
在內部系統裡填一組表單。
處理經常改版的 OA 或 SaaS 頁面。
按使用者目標探索頁面，而不是執行固定腳本。
讓 Claude Code、Codex CLI 這類工具擁有瀏覽器操作能力。

三者核心對比

維度	Puppeteer	Playwright	browser-harness
面向對象	人類工程師	人類工程師和測試團隊	AI Agent
主要目標	控制 Chrome	穩定跨瀏覽器自動化	讓 Agent 操作真實瀏覽器
腳本方式	手寫 JS/TS 自動化	手寫腳本 + 測試框架	使用者下目標，Agent 分步執行
元素定位	CSS、XPath、DOM API	Locator、文字、角色、CSS	截圖視覺、座標、DOM、CDP
等待機制	更多手動控制	自動等待很強	由 Agent 觀察和調整
瀏覽器環境	通常啟動自動化瀏覽器	通常啟動測試瀏覽器	常連接真實 Chrome
最適合	Chrome 腳本、截圖、PDF、輕量抓取	E2E 測試、跨瀏覽器驗證、複雜 SPA	AI 助手、開放網頁任務、真實帳號工作流

程式碼體感對比

Puppeteer 更像直接控制 Chrome：

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.waitForSelector('#submit-btn');
  await page.click('#submit-btn');

  await browser.close();
})();

Playwright 更強調 Locator 和自動等待：

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.locator('#submit-btn').click();

  await browser.close();
})();

browser-harness 的使用體感則完全不同。你通常不是寫完整腳本，而是在 Agent 環境裡下達目標：

`1`	`幫我打開後台，下載上個月的帳單，並整理成報銷用的文件。`

Agent 會借助 browser-harness 反覆執行類似流程：

截圖，理解目前頁面。
點擊某個座標或定位某個元素。
輸入文字、上傳檔案、下載檔案。
遇到彈窗時判斷如何關閉。
缺少 helper 時補充程式碼。
把可重用流程沉澱為 domain skill。

這不是傳統測試腳本的寫法，而是瀏覽器 Agent 的工作方式。

怎麼選

選擇 Puppeteer，通常是因為：

專案主要跑在 Node.js 裡。
只需要 Chrome 或 Chromium。
任務是截圖、PDF、簡單頁面抓取或輕量自動化。
你希望 API 簡潔、依賴少，自己控制更多細節。
你對 Chrome DevTools Protocol 有較深依賴。

選擇 Playwright，通常是因為：

你要做標準 UI 自動化或 E2E 測試。
需要覆蓋 Chromium、Firefox 和 WebKit。
團隊主語言可能是 Python、Java 或 C#。
頁面是複雜 SPA，非同步狀態多，容易出現 flaky test。
你需要 codegen、Trace Viewer、測試報告和並行測試。

選擇 browser-harness，通常是因為：

你在開發或使用 AI Agent。
你希望模型像人一樣操作真實瀏覽器。
任務步驟不固定，需要邊看頁面邊判斷。
目標網站經常改版，或者彈窗、iframe、shadow DOM 很多。
你想把真實網頁工作流交給 Claude Code、Codex CLI 等工具處理。

簡單結論

Playwright 和 Puppeteer 是瀏覽器自動化工具，核心是讓人寫出可靠腳本。兩者相比，Puppeteer 更輕、更貼近 Chrome；Playwright 更完整、更適合跨瀏覽器測試和複雜前端應用。

browser-harness 則是另一個方向：它不是為了取代 Playwright 或 Puppeteer 寫測試，而是為了讓 AI Agent 接管真實瀏覽器。它犧牲了一部分傳統腳本的確定性，換來更強的開放任務適應能力。

所以答案不是三選一，而是按任務分層：

測試工程：優先 Playwright。
Chrome 輕量腳本：Puppeteer 很合適。
AI Agent 上網辦事：看 browser-harness。

參考資料：

browser-use/browser-harness：https://github.com/browser-use/browser-harness
Playwright 官方文件：https://playwright.dev/
Puppeteer 官方文件：https://pptr.dev/
Chrome DevTools Protocol：https://chromedevtools.github.io/devtools-protocol/

Puppeteer on KnightLi的博客