AI工具

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

解析 browser-harness 的 domain skills 機制，說明它如何把 Amazon、GitHub、ArXiv、LinkedIn、Shopify 等站點的操作經驗沉澱成可重用技能，以及對 AI Agent 瀏覽器自動化的啟發。

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 帶著驗證過的經驗進入網頁任務，而不是每次都重新摸索。

參考資料：

© 2022 - 2026 KnightLi的博客
记录并分享
使用 Hugo 建立
主題 Stack 由 Jimmy 設計