瀏覽器自動化 on KnightLi的博客

browser-harness 的 domain skills 機制：讓 AI Agent 不再重複踩網頁自動化的坑

Sun, 24 May 2026 23:43:35 +0800

browser-use/browser-harness 最有意思的地方，不只是讓 AI Agent 能控制真實 Chrome，而是它把網頁操作中的經驗變成了可以重用的 domain skills。

這件事很關鍵。瀏覽器自動化真正困難的地方，往往不是「能不能點擊按鈕」，而是每個網站都有自己的細節：

哪些頁面必須登入。
哪些資料可以直接走 API。
哪些按鈕用普通 DOM 點擊無效。
哪些 iframe、shadow DOM、彈窗會擋住流程。
哪些選擇器穩定，哪些只是臨時 class。
哪些操作涉及帳號、支付或不可逆變更，必須讓人確認。

如果這些經驗只留在一次任務日誌裡，Agent 下次還會重新踩坑。domain skills 的作用，就是把這些經驗沉澱下來，讓 Agent 不必每次都像第一次打開網站。

domain skills 是什麼

可以把 domain skills 理解成「給 Agent 看的站點操作手冊」。

它不是普通的使用者文件，也不是一次性腳本。它更像一組經過實測的站點級知識：

這個站點適不適合用瀏覽器。
如果有 API，應該優先用哪個 API。
如果必須操作網頁，應該從哪個 URL 進入。
哪些 DOM 結構、aria-label、按鈕行為經過驗證。
哪些常見寫法會失敗。
哪些場景要停止並請求人類介入。

這類內容既能被人類審查，也能被 Agent 在任務中讀取。它把「臨場摸索」變成「可維護經驗」。

它不是讓 Agent 盲目點擊

一個好的瀏覽器 Agent，不應該把所有問題都變成打開網頁、看截圖、點按鈕。

domain skills 裡很重要的一類經驗，恰恰是在告訴 Agent：什麼時候不要用瀏覽器。

比如 ArXiv 這類站點，論文搜尋、元資料和摘要可以透過 Atom API 或 HTML meta 標籤直接拿到。用 HTTP 請求通常比打開瀏覽器更快、更穩，也更容易解析。

GitHub 也是類似思路。倉庫、使用者、release 資料優先用 REST API；檔案內容優先讀 raw.githubusercontent.com；只有 GitHub Trending 這類沒有等價 API 的頁面，才需要進入瀏覽器。

這說明 browser-harness 的思路不是「瀏覽器萬能」，而是把瀏覽器放在正確位置：當 API、HTTP、靜態頁面無法解決問題時，再讓 Agent 操作真實頁面。

它記錄的是站點級知識

傳統自動化腳本通常圍繞一次任務寫，比如：

`1`	`打開頁面 -> 輸入關鍵詞 -> 點擊按鈕 -> 下載文件`

這種腳本可以完成任務，但經驗很容易散落在程式碼裡。站點一改版，腳本失效；換一個任務，很多經驗也沒法重用。

domain skills 的粒度更接近站點級知識庫。它關心的是：

Amazon 搜尋結果裡哪個容器選擇器穩定。
GitHub 哪些資料應該走 REST API。
LinkedIn 邀請管理頁的按鈕 aria-label 有什麼差異。
Shopify Admin 裡哪些頁面是嵌入式 app。
Shopify Polaris 輸入框為什麼不能只用普通 JS 設定 value。
Browser Use Cloud 的瀏覽器實例如何建立、列出和清理。

這些經驗不是一次任務的步驟，而是以後很多任務都會用到的判斷依據。

例子：Amazon 商品搜尋

Amazon 商品搜尋的經驗，重點不只是「怎麼搜尋商品」，而是哪些路徑更穩定。

比較可靠的做法是直接使用搜尋 URL，而不是每次都打開首頁再模擬輸入。搜尋結果可以從 [data-component-type="s-search-result"] 這樣的容器中提取。欄位提取也有細節：標題、價格、評分、評論數、是否贊助，都有各自更穩的 DOM 來源。

這種經驗對 Agent 很有價值。沒有它時，Agent 可能會從截圖裡猜按鈕、反覆嘗試選擇器；有了它之後，Agent 可以直接進入更穩定的資料提取路徑。

更重要的是，這類 skill 還會記錄陷阱。例如某些看似可用的選擇器，在贊助結果或交叉推薦區域裡會誤讀。這種坑只有實測過才知道。

例子：LinkedIn 邀請管理

LinkedIn 這類站點更接近真實帳號工作流，風險也更高。

在邀請管理頁裡，Accept 和 Ignore 按鈕的 aria-label 格式不同，不能簡單地從一個推導另一個。有些邀請卡片裡的 Accept 控件甚至不是 <button>，而是 <a>，普通 CDP 點擊不一定能觸發接受動作。

這種細節說明，真實網頁自動化不是「定位到元素就結束」。按鈕標籤、事件綁定、軟導航、元件實作方式，都會影響操作是否真的生效。

對 Agent 來說，這類經驗還有一個安全含義：涉及社交帳號、邀請、消息、發文的操作，不應該完全託管。skill 可以記錄路徑和陷阱，但批量接受邀請、對外發送內容、修改帳號資料這類動作，最好保留人工確認。

例子：Shopify Admin

Shopify Admin 的經驗說明了另一個問題：後台系統往往不是一個頁面，而是一堆嵌入式應用和複雜元件的組合。

很多 Shopify app 會運行在 iframe 裡。Polaris React 輸入框、Web Components、嵌入式 app 的互動方式也不同。某些輸入框不能只用 element.value = ...，需要使用更接近真實鍵盤輸入的 CDP keystrokes。

這類 skill 的價值在於，它讓 Agent 先判斷目前頁面屬於哪類 UI，再選擇合適的操作方式。

同時，Shopify 的經驗也強調「能不用瀏覽器就不用瀏覽器」：

唯讀商品和庫存資料，優先用 Storefront API。
有 Admin API token 時，優先用 Admin API。
編輯主題程式碼時，優先用 Shopify CLI。
只有沒有 API、一次性設定、探索後台時，才適合讓瀏覽器介入。

這才是成熟的 Agent 工具選擇邏輯。

例子：Browser Use Cloud

domain skills 不只服務網頁點擊，也可以記錄圍繞瀏覽器執行環境的 API 經驗。

Browser Use Cloud 的經驗裡，會記錄如何透過 REST API 建立 cloud browser、列出正在運行的瀏覽器、清理 zombie browser、取得 liveUrl 和 cdpUrl 等資訊。

這說明 skill 的邊界並不侷限於「某個網頁按鈕怎麼點」。只要某類任務會反覆出現，而且有穩定做法，就可以沉澱成 skill：

API 呼叫方式。
鑑權頭格式。
請求和回應結構。
已驗證狀態碼。
常見失敗模式。
清理和回收資源的方法。

對 Agent 來說，這些都是可重用能力。

為什麼這比臨場推理更可靠

很多人期待大模型每次都能「自己看懂網頁」。但真實任務裡，只靠臨場推理並不穩定。

原因很簡單：

網頁 UI 經常變化。
同一按鈕可能有多種實作。
看得見不代表點得動。
能點擊不代表操作真的生效。
有些任務本來就應該用 API，而不是瀏覽器。
有些操作需要人類確認，不能讓模型自己決定。

domain skills 把這些經驗寫成文件後，有幾個好處：

人類可以 review。
錯誤經驗可以修正。
同一站點的經驗可以持續積累。
新 Agent 可以直接繼承舊經驗。
臨時任務發現可以變成長期知識。

這比把一切都塞進 prompt 或聊天上下文更穩。

團隊可以怎麼用

如果把 browser-harness 用在團隊裡，domain skills 可以變成一種輕量自動化知識庫。

比較適合沉澱的內容包括：

內部後台的登入後路徑。
報表匯出流程。
常見彈窗處理方式。
哪些按鈕需要人工確認。
哪些頁面有 API 替代方案。
哪些選擇器經過實測可靠。
哪些任務不允許 Agent 自動執行。

這類知識不必一開始就很完整。更實際的做法是從低風險、高頻、可回復的流程開始：先讓 Agent 做唯讀、下載、整理、檢查類任務。等流程穩定後，再把經驗整理成 skill。

對團隊管理者來說，skill 文件還有一個好處：它讓自動化邊界變得可見。你可以審查 Agent 知道什麼、能做什麼、應該停在哪裡。

需要注意的邊界

domain skills 能提高 Agent 成功率，但它不應該讓高風險操作完全自動化。

幾個邊界要守住：

不記錄密碼、Cookie、token、客戶資料和內部敏感 URL。
支付、刪除、批量提交、帳號變更、對外發布內容，要保留人工確認。
skill 要寫明驗證日期和適用範圍。
站點改版後，要允許 skill 失效並重新驗證。
不要把繞過風控、規避平台限制當成目標。

換句話說，domain skill 是讓 Agent 更穩，不是讓 Agent 無限制地做事。

簡單結論

browser-harness 的 domain skills 機制說明了一件事：AI Agent 的瀏覽器自動化，不能只靠模型臨場發揮。

一個可用的瀏覽器 Agent，至少需要三層能力：

底層控制能力：截圖、點擊、輸入、下載、CDP、HTTP。
站點級知識：API 優先級、穩定選擇器、元件陷阱、登入邊界。
人類安全規則：憑據不交給模型，高風險操作要確認，敏感資訊不寫進 skill。

domain skills 補的是第二層。它讓 Agent 帶著驗證過的經驗進入網頁任務，而不是每次都重新摸索。

參考資料：

browser-harness domain skills：https://github.com/browser-use/browser-harness/tree/main/agent-workspace/domain-skills
Amazon product-search skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/amazon/product-search.md
ArXiv scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/arxiv/scraping.md
GitHub scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/github/scraping.md
LinkedIn invitation-manager skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/linkedin/invitation-manager.md
Shopify admin skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/shopify-admin/README.md
Browser Use Cloud skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/browser-use-cloud/cloud.md

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/

browser-harness 是什麼？讓 AI Agent 接管真實 Chrome 的瀏覽器自動化工具

Sun, 24 May 2026 17:19:54 +0800

browser-use/browser-harness 是一個面向 AI Agent 的瀏覽器控制工具。它的目標不是再做一層複雜的自動化框架，而是把大模型直接連到真實 Chrome，透過 CDP 完成瀏覽、點擊、截圖、下載、上傳和表單操作。

專案 README 對自己的定位很明確：用一層很薄、可編輯的 CDP harness，讓 LLM 直接連接真實瀏覽器；當任務中缺少 helper 時，Agent 可以在執行過程中補上程式碼，並把可重用經驗沉澱成 domain skills。

這類工具值得關注，是因為瀏覽器仍然是很多真實工作的入口：後台系統、SaaS 面板、電商頁面、招聘網站、CRM、報銷系統、雲控制台、文件平台，往往沒有穩定 API，或者 API 權限比網頁權限更難拿到。讓 Agent 能可靠操作瀏覽器，本質上是在補齊自動化的最後一段距離。

browser-harness 是什麼

從結構看，browser-harness 更像一個給 Agent 用的瀏覽器執行環境，而不是普通使用者手動點擊的瀏覽器外掛。

它的核心思路有幾個：

直接連接 Chrome 或 Chromium。
透過 CDP WebSocket 操作頁面。
讓 Agent 組合截圖、座標點擊、DOM、網路請求和原始 CDP 完成任務。
把任務相關 helper 放在 agent-workspace/agent_helpers.py。
把站點相關經驗沉澱到 agent-workspace/domain-skills/。
保持核心很薄，避免做成龐大的自動化平台。

README 提到，專案核心架構大約是 4 個核心檔案、約 1000 行程式碼，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。

這種設計的重點不是內建所有網站能力，而是給 Agent 一個足夠貼近真實瀏覽器的操作層，讓它在具體任務裡補齊缺失能力。

它和傳統瀏覽器自動化有什麼不同

傳統瀏覽器自動化通常圍繞測試框架展開，例如 Playwright、Selenium 或 Puppeteer。它們適合寫確定性的測試腳本：打開頁面、定位元素、點擊、斷言結果。

browser-harness 面向的是另一類任務：使用者說一句目標，Agent 自己探索頁面、判斷狀態、處理彈窗、補 helper、複用站點經驗。它強調的是互動過程中的適應性。

差異可以這樣理解：

Playwright 更適合人寫腳本，Agent 執行腳本。
browser-harness 更適合 Agent 邊看頁面邊行動。
傳統自動化偏固定流程。
browser-harness 偏開放任務。
傳統腳本常依賴選擇器。
browser-harness 鼓勵先截圖、再按可見介面行動，必要時再回到 DOM 或 CDP。

這不表示它要取代 Playwright。對穩定測試來說，Playwright 仍然更成熟。browser-harness 的價值在於把真實網頁變成 Agent 可操作的環境，尤其適合頁面結構複雜、步驟不固定、需要臨場判斷的任務。

為什麼強調真實 Chrome

很多瀏覽器 Agent 工具會使用隔離的無頭瀏覽器。這樣部署簡單，也適合批量任務，但它有一個現實問題：使用者真實工作裡的登入狀態、擴充功能、歷史記錄、書籤和日常瀏覽器環境，不一定能直接複用。

browser-harness 支援連接本機 Chrome，也支援 Browser Use cloud browser。對本機瀏覽器，它提供兩種方式：

透過 chrome://inspect/#remote-debugging 允許目前 Chrome 實例被連接。
用 --remote-debugging-port=9222 --user-data-dir=... 啟動一個隔離 profile。

如果要讓 Agent 幫你處理真實帳號裡的任務，專案文件更傾向第一種方式，因為它能複用日常 Chrome 的登入狀態、擴充功能和書籤。如果要做無人值守自動化，或者不希望被彈窗打斷，則更適合使用隔離 profile 或雲瀏覽器。

這裡的取捨很清楚：真實瀏覽器更貼近使用者工作流，但安全邊界也更敏感；隔離瀏覽器更適合自動化，但需要重新處理登入和環境。

可編輯 helper 與 domain skills

browser-harness 最有意思的地方，是它把「Agent 會學到什麼」設計進了專案結構。

agent-workspace/agent_helpers.py 用來放任務中臨時補出的 helper。比如 Agent 做檔案上傳時發現現有能力不夠，可以補一個穩定的上傳函式；下次再遇到類似頁面，就不用從零開始。

agent-workspace/domain-skills/ 則用來放站點級經驗。README 裡舉的方向包括 LinkedIn outreach、Amazon 下單、報銷系統等。專案建議不要手寫這些 skill，而是讓 Agent 在真實任務中發現可重用流程後再生成，這樣更貼近實際頁面行為。

這個思路很適合瀏覽器自動化。因為網頁自動化的難點往往不是「怎麼點擊按鈕」，而是：

某個網站的登入後頁面怎麼跳轉。
哪些彈窗會擋住主流程。
哪些 selector 穩定，哪些只是臨時樣式名。
上傳、下載、iframe、shadow DOM、跨域元件怎麼處理。
某個後台系統有哪些隱藏等待和非同步狀態。

這些知識如果只留在一次執行日誌裡，很快就會丟掉。把它們沉澱成 domain skills，才可能讓 Agent 越用越順。

適合哪些場景

browser-harness 更適合以下任務：

幫使用者操作真實網頁後台。
在沒有 API 的系統裡完成重複流程。
登入狀態依賴強的個人或企業網頁任務。
需要截圖判斷頁面狀態的複雜互動。
Agent 需要在執行中補工具、補站點經驗。
多個子 Agent 各自使用獨立瀏覽器執行任務。
研究瀏覽器 Agent 的執行環境設計。

具體例子包括：整理網頁表格、提交內部系統表單、下載帳單、上傳檔案、處理報銷流程、檢查訂單狀態、在 SaaS 控制台裡配置資源、從登入後的網頁提取資訊。

如果任務只是抓取靜態網頁，未必需要瀏覽器。專案自己的 SKILL.md 也提到，靜態頁面可以直接用 HTTP 批量取得；瀏覽器應該留給真正需要頁面狀態、登入狀態和互動的場景。

需要注意的風險

讓 AI Agent 接管真實 Chrome，很強，也很危險。

第一，權限邊界要清楚。真實 Chrome 裡可能有信箱、支付後台、雲控制台、公司系統和個人帳號。Agent 一旦能操作瀏覽器，就等於獲得了這些網頁權限的一部分。

第二，不要把憑證交給模型。遇到登入頁、支付驗證、二次確認等敏感步驟，應該讓使用者自己處理。Agent 可以等待登入完成，但不應該從截圖裡讀取或輸入密碼、驗證碼、支付資訊。

第三，自動化不等於可託管。很多網頁任務看似簡單，但中間可能出現風控、誤點擊、資料刪除、批量提交、不可逆操作。適合先從唯讀、低風險、可回復的流程開始。

第四，domain skills 需要避免洩露隱私。站點經驗可以公開，但不要把帳號、內部 URL、客戶資料、座標流水或一次性任務細節寫進去。

第五，真實瀏覽器連接方式要謹慎選擇。如果要複用日常登入狀態，使用目前 Chrome 很方便；如果要跑長時間自動化，隔離 profile 或雲瀏覽器更可控。

對 AI Agent 工具的意義

browser-harness 代表了一種很務實的 Agent 工具路線：少做平台，多給模型一個可以直接觸達真實環境的介面。

過去很多 Agent 失敗在兩端。一端是模型會推理，但摸不到真實頁面；另一端是自動化框架很強，但需要人先把流程寫死。browser-harness 試圖把這兩端接起來：瀏覽器負責真實世界的狀態，Agent 負責觀察、判斷和補工具。

這也是「自我改進 harness」的意義。它不是說 Agent 會神奇地變聰明，而是把可重用的操作經驗放到專案結構裡，讓下一次任務少走彎路。

對開發者來說，browser-harness 的價值主要在三個層面：

作為個人 Agent 的瀏覽器控制層。
作為研究瀏覽器自動化和 Agent 工作流的樣本。
作為把網頁流程變成可重用技能的實驗框架。

它不是所有瀏覽器自動化問題的答案，但它給出了一個清晰方向：當 Agent 真正要幫人做事時，工具層不只要能呼叫 API，也要能理解和操作人類每天使用的網頁介面。

簡單結論

browser-use/browser-harness 值得關注，不是因為它包裝了多少高階功能，而是因為它把瀏覽器 Agent 的幾個關鍵問題擺在了台面上：真實 Chrome、CDP、截圖驅動、可編輯 helper、站點技能沉澱，以及使用者權限邊界。

如果你只是寫穩定端到端測試，繼續用 Playwright 或 Selenium 就很好。如果你想讓 Codex、Claude Code 這類 Agent 直接幫你處理真實網頁任務，browser-harness 提供了一個更貼近 Agent 工作方式的入口。

真正使用時，建議從低風險任務開始：先讓它讀頁面、截圖、提取資訊，再逐步嘗試點擊和提交。等你確認它能穩定識別頁面狀態，再考慮讓它接管更長的流程。

參考資料：

GitHub 專案：https://github.com/browser-use/browser-harness
README：https://github.com/browser-use/browser-harness/blob/main/README.md
安裝文件：https://github.com/browser-use/browser-harness/blob/main/install.md
使用說明：https://github.com/browser-use/browser-harness/blob/main/SKILL.md

CloakBrowser 是什麼？給 Playwright 和 Puppeteer 換一個更像真實用戶的瀏覽器

Tue, 19 May 2026 10:56:50 +0800

CloakHQ/CloakBrowser 是一個面向瀏覽器自動化的開源項目。它不是普通的 Playwright 配置，也不是單純注入一段 JavaScript，而是圍繞自定義 Chromium 二進制構建，讓瀏覽器指紋、WebGL、Canvas、音頻、字體、GPU、屏幕信息、WebRTC、網絡時序等信號更接近真實瀏覽器。

項目地址：https://github.com/CloakHQ/CloakBrowser

截至寫作時，GitHub API 顯示這個倉庫已有約 1.5 萬 star，主要語言是 Python，許可證爲 MIT。README 對它的定位很直接：一個可替代 Playwright / Puppeteer 啓動器的 Stealth Chromium。

它解決什麼問題

很多自動化腳本在普通 Headless Chromium 下會暴露明顯自動化特徵，例如：

navigator.webdriver。
Headless UA 泄漏。
插件、字體、屏幕、GPU 等指紋不自然。
CDP 行爲和真實用戶輸入不一致。
默認臨時 profile 缺少正常瀏覽痕跡。

CloakBrowser 的思路是把一部分指紋修改放到 Chromium 源碼層，而不是隻在運行時做配置或 JS patch。這樣對 Playwright 用戶來說，使用方式仍然接近原來的瀏覽器自動化 API，但底層瀏覽器換成了項目提供的自定義構建。

這類工具適合做合規的自動化測試、站點兼容性驗證、反爬系統自測、Agent 瀏覽器環境實驗。不要把它用於未授權訪問、賬號濫用、繞過平臺風控或違反服務條款的場景。

基本使用方式

Python 安裝：

`1`	`pip install cloakbrowser`

JavaScript / Node.js 安裝：

`1`	`npm install cloakbrowser playwright-core`

README 給出的 Python 示例很接近 Playwright：

from cloakbrowser import launch

browser = launch()
page = browser.new_page()
page.goto("https://protected-site.com")
browser.close()

JavaScript 示例：

import { launch } from 'cloakbrowser';

const browser = await launch();
const page = await browser.newPage();
await page.goto('https://protected-site.com');
await browser.close();

第一次運行時，項目會自動下載對應平臺的 Chromium 二進制文件，README 提到體積約 200MB，並會緩存到本地。

Browser Profile Manager

CloakBrowser 還提供一個 Browser Profile Manager，可以自託管瀏覽器 profile，管理不同指紋、代理和持久會話。README 中的 Docker 啓動方式如下：

`1`	`docker run -p 8080:8080 -v cloakprofiles:/data cloakhq/cloakbrowser-manager`

啓動後打開：

`1`	`http://localhost:8080`

這個方向更像開源的瀏覽器 profile 管理工具，適合需要多 profile、持久 cookie、隔離會話的自動化測試或內部 QA 場景。

和普通 Playwright 有什麼差別

普通 Playwright 的優點是穩定、官方維護、API 成熟。CloakBrowser 的差別在於它使用自定義 Chromium，並提供一組源代碼級別的指紋 patch。

README 裏列出的能力包括：

Canvas、WebGL、Audio、Fonts、GPU、Screen 等指紋處理。
WebRTC IP spoofing。
代理相關信號處理。
humanize=True 模擬更自然的鼠標、鍵盤和滾動行爲。
Python 與 JavaScript 雙端 API。
Docker 鏡像與 CDP server 模式。
持久 profile。

也就是說，它更適合對“瀏覽器環境真實性”有要求的自動化任務，而不是替代所有 Playwright 使用場景。

使用時要注意什麼

第一，瀏覽器自動化和反檢測相關工具有很強的合規邊界。它可以用於測試自己的站點、驗證自動化環境、做內部 QA，也可以用於研究瀏覽器指紋；但不應被用於未經授權的抓取、賬號批量註冊、繞過訪問控制、攻擊或濫用服務。

第二，README 中也說明，CloakBrowser 不內置代理輪換，也不是驗證碼解決服務。它提供瀏覽器層能力，網絡信譽、賬號信譽、行爲策略和目標站點規則仍然會影響結果。

第三，自定義 Chromium 二進制意味着供應鏈安全要額外關注。正式使用前建議檢查版本、二進制來源、簽名說明、許可證和更新機制。

適合誰

適合三類用戶：

已經在用 Playwright / Puppeteer，但需要更接近真實瀏覽器環境的開發者。
做瀏覽器自動化測試、兼容性測試或反爬策略驗證的團隊。
需要給 AI Agent 提供瀏覽器執行環境的開發者。

如果只是普通網頁測試，原生 Playwright 已經夠用。如果目標是研究瀏覽器指紋、profile 隔離和真實瀏覽器行爲，CloakBrowser 值得關注。

小結

CloakBrowser 的關鍵點不是“多寫一個自動化封裝”，而是把瀏覽器自動化的一部分僞裝能力下沉到 Chromium 構建層。它保留了 Playwright / Puppeteer 的使用習慣，同時提供自定義瀏覽器、profile 管理、Docker 和 CDP server。

這類工具能力強，也更需要謹慎使用。判斷是否值得接入，重點看你的場景是否真的需要自定義 Chromium，而不是只因爲普通 Headless 瀏覽器被某些檢測服務標記。

參考項目：https://github.com/CloakHQ/CloakBrowser

Playwright CLI 會話管理：多瀏覽器會話、隔離、持久化與清理

Wed, 15 Apr 2026 08:15:12 +0800

如果你在用 Playwright CLI 做自動化，很快就會碰到一個實際問題：同一時間裡，能不能開多個互不干擾的瀏覽器會話？答案是可以，而且 Playwright CLI 已經把這套機制做得很直接。

這篇就按照官方 session-management 參考文件，整理它最實用的幾個部分：命名會話、會話隔離、持久化 profile、並發模式，以及常見清理命令。文中的命令列與命令區塊說明均按參考內容保留。

01 命名瀏覽器會話

官方建議用 -s 參數隔離不同瀏覽器上下文：

# Browser 1: Authentication flow
playwright-cli -s=auth open https://app.example.com/login

# Browser 2: Public browsing (separate cookies, storage)
playwright-cli -s=public open https://example.com

# Commands are isolated by browser session
playwright-cli -s=auth fill e1 "user@example.com"
playwright-cli -s=public snapshot

這裡的重點是：不同 session 名稱對應不同瀏覽器上下文。你可以把 auth 用在登入流程，把 public 用在匿名存取，它們之間不會共用 cookies 或本地狀態。

02 瀏覽器會話隔離了什麼

每個瀏覽器會話都會獨立維護下面這些內容：

Cookies
LocalStorage / SessionStorage
IndexedDB
Cache
Browsing history
Open tabs

這意味著如果你在 auth 會話裡登入了某個網站，並不會自動影響 public 會話。做多帳號測試、登入態驗證、匿名對比時，這一點尤其重要。

03 瀏覽器會話相關命令

官方文件把會話管理裡最常用的一組命令放在了一起：

# List all browser sessions
playwright-cli list

# Stop a browser session (close the browser)
playwright-cli close                 # stop the default browser
playwright-cli -s=mysession close   # stop a named browser

# Stop all browser sessions
playwright-cli close-all

# Forcefully kill all daemon processes (for stale/zombie processes)
playwright-cli kill-all

# Delete browser session user data (profile directory)
playwright-cli delete-data              # delete default browser data
playwright-cli -s=mysession delete-data # delete named browser data

可以把它們理解成三類操作：

list：看目前有哪些會話
close / close-all / kill-all：結束會話或清理卡住的瀏覽器程序
delete-data：刪除某個會話對應的使用者資料目錄

如果你只是結束瀏覽器，通常先用 close；如果已經出現殘留程序或殭屍程序，再用 kill-all 會更合適。

04 用環境變數設定預設會話

如果你不想每條命令都重複寫 -s=mysession，官方還提供了環境變數方式：

1
2

export PLAYWRIGHT_CLI_SESSION="mysession"
playwright-cli open example.com  # Uses "mysession" automatically

這樣之後不顯式指定 -s 時，命令就會預設使用 mysession 這個瀏覽器會話。

05 常見模式：並發抓取

參考文件給了一個很典型的並發抓取例子：

#!/bin/bash
# Scrape multiple sites concurrently

# Start all browsers
playwright-cli -s=site1 open https://site1.com &
playwright-cli -s=site2 open https://site2.com &
playwright-cli -s=site3 open https://site3.com &
wait

# Take snapshots from each
playwright-cli -s=site1 snapshot
playwright-cli -s=site2 snapshot
playwright-cli -s=site3 snapshot

# Cleanup
playwright-cli close-all

這個模式適合同時打開多個站點，各自抓取頁面狀態，再統一清理。因為每個站點都跑在獨立會話裡，所以不會互相污染本地狀態。

06 常見模式：A/B 測試會話

另一個常見場景，是同時對比不同實驗版本：

# Test different user experiences
playwright-cli -s=variant-a open "https://app.com?variant=a"
playwright-cli -s=variant-b open "https://app.com?variant=b"

# Compare
playwright-cli -s=variant-a screenshot
playwright-cli -s=variant-b screenshot

這種寫法很適合做 A/B 頁面差異對比，因為兩個版本在獨立會話裡運行，截圖和狀態檢查也更容易分開管理。

07 持久化瀏覽器 profile

官方文件特別說明：預設情況下，瀏覽器 profile 只保存在記憶體裡。

如果你希望把瀏覽器 profile 持久化到磁碟，需要在 open 時加上 --persistent：

# Use persistent profile (auto-generated location)
playwright-cli open https://example.com --persistent

# Use persistent profile with custom directory
playwright-cli open https://example.com --profile=/path/to/profile

這個能力適合需要長期複用登入態、本地快取或擴充除錯環境的場景。尤其在反覆除錯同一站點時，持久化 profile 往往會比每次從零開始更高效。

08 預設瀏覽器會話

如果沒有顯式傳入 -s，那麼命令會使用預設瀏覽器會話：

# These use the same default browser session
playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli close  # Stops default browser

也就是說，不帶 -s 的幾條命令預設是在同一個預設會話裡連續執行的。

09 打開時附帶會話配置

除了會話名，官方也給出了幾種常見的啟動配置方式：

# Open with config file
playwright-cli open https://example.com --config=.playwright/my-cli.json

# Open with specific browser
playwright-cli open https://example.com --browser=firefox

# Open in headed mode
playwright-cli open https://example.com --headed

# Open with persistent profile
playwright-cli open https://example.com --persistent

這些參數可以和會話管理一起搭配使用。比如你可以讓某個命名會話固定跑在 firefox，或者讓某個會話始終以 headed 模式啟動，方便人工觀察。

10 官方給出的最佳實務

參考文件列了三條很實用的最佳實務。

1. 用有語義的會話名

# GOOD: Clear purpose
playwright-cli -s=github-auth open https://github.com
playwright-cli -s=docs-scrape open https://docs.example.com

# AVOID: Generic names
playwright-cli -s=s1 open https://github.com

會話名最好能直接表達用途。像 github-auth、docs-scrape 這種名字，後面維護腳本時會清楚很多。

2. 用完及時清理

# Stop browsers when done
playwright-cli -s=auth close
playwright-cli -s=scrape close

# Or stop all at once
playwright-cli close-all

# If browsers become unresponsive or zombie processes remain
playwright-cli kill-all

如果任務結束後不關瀏覽器，會話和背景程序會一直留著。短期看問題不大，但任務一多，很容易把環境弄亂。

3. 刪除陳舊瀏覽器資料

1
2

# Remove old browser data to free disk space
playwright-cli -s=oldsession delete-data

當某些舊會話已經不用時，刪除對應資料目錄可以節省磁碟空間，也能避免後面誤用過期狀態。

11 快速總結

如果只抓重點，可以記住下面這幾件事：

-s=<name> 用來建立並使用獨立瀏覽器會話
不同會話之間會隔離 cookies、各種儲存、快取、歷史紀錄和分頁
close-all 適合統一關閉，kill-all 適合處理異常殘留程序
--persistent 用來把 profile 落盤，適合長期複用狀態
會話名盡量語義化，舊資料定期清理

如果你的工作流裡已經有登入態複用、多帳號並行、A/B 對比或批次抓取需求，那麼 session management 基本就是 Playwright CLI 裡最值得先掌握的一塊能力。

參考連結

Playwright CLI session-management 參考文件：https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/session-management.md
Playwright CLI 專案首頁：https://github.com/microsoft/playwright-cli