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

在瀏覽器自動化和自動化測試領域，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 的優勢在 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 更像直接控制 Chrome：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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 和自動等待：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

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/