瀏覽器操作 Agent 實作課：別再寫選擇器，讓 Agent 自己看懂網頁

今日主題：瀏覽器操作 Agent：DOM＋視覺 grounding 與三路線選型

2026-10-29 | 資料來源：browser-use、Stagehand、Playwright MCP、WebVoyager、開源瀏覽器 Agent 橫向評測

前言

寫過網頁自動化的人都遇過同一種崩潰：昨天還能跑的腳本，今天因為前端換了一個 class 名稱就全線陣亡。Playwright 與 Selenium 的世界裡，自動化建立在一個脆弱的假設上——你事先知道頁面長什麼樣子，而且它不會變。但真實的網頁每天都在變：版面重排、彈出視窗、登入流程多了一道驗證、分頁載入改成無限捲動。選擇器寫得再精準，也追不上變化的速度。

瀏覽器操作 Agent 換了一個思路：不再事先寫死每一步，而是讓模型在執行時自己看懂頁面、自己決定下一步。如圖一，這是一個感知、推理、動作、驗證的迴路，而不是一張寫死的操作清單。這篇文章講清楚這個迴路怎麼實作、三種主流路線怎麼選，以及上線前必須先裝好的安全護欄。

一、先搞懂敵人：為什麼選擇器一定會斷

傳統自動化的失效模式幾乎都來自同一個根源：它把「頁面的結構」當成穩定的契約，但前端根本沒有承諾過這件事。元件庫升級會改變巢狀結構，CSS-in-JS 會產生隨機的 class 名稱，A/B 測試會讓同一批使用者看到不同的版面。腳本斷掉時，錯誤訊息往往只是「找不到元素」，你得自己重跑、重看頁面、重寫選擇器。

更麻煩的是，選擇器只能表達「去哪裡點」，不能表達「為什麼點」。一個表單流程裡，某個欄位突然變成必填、某個按鈕被移到第二頁、某個步驟多了一道確認對話框，寫死的腳本沒有任何應變能力，只能在原地失敗。瀏覽器 Agent 的價值不在於點得比較快，而在於它能把「目標」與「步驟」分開：你給它目標，它在執行時自己找出路。

二、感知是關鍵：模型到底看到什麼

瀏覽器 Agent 的第一個實作決策是感知方式，也就是模型每一回合收到什麼資訊。主流做法是三種訊號混用，各有代價。

第一種是精簡過的 DOM。現代單頁應用的原始 HTML 動輒數百 KB，直接塞進提示詞既貴又會稀釋注意力。實務做法是先過濾：去掉 script、style、隱藏元素，只留下可互動的節點（按鈕、輸入框、連結、下拉選單），再附上每個元素的邊界框與是否在可視範圍內。精簡後的語義樹通常只有數 KB，模型可以直接用編號指名要操作的元素，精準又便宜。

第二種是截圖。DOM 看不見的東西，截圖看得見：Canvas 畫出來的圖表、以圖片呈現的按鈕、刻意把結構藏起來的反爬蟲頁面。視覺 grounding 的標準做法是 Set-of-Mark：在截圖上把可互動元素標上編號，讓模型回傳編號而不是座標，避免座標漂移造成的誤點。DOM 為主、視覺為輔，是目前多數實作的預設組合。

第三種是無障礙樹（accessibility tree）。瀏覽器本來就會為輔助技術產生一棵語義樹，節點帶有角色與名稱，結構比 DOM 乾淨，又比截圖便宜。Stagehand 這類框架就大量依賴這棵樹來定位元素。選哪一種感知方式，基本上決定了你的 Agent 在哪類頁面上會失靈，先想清楚目標網站的形態再選。

三、三條路線：誰握方向盤

如圖二，三種開源路線真正的差別不在功能清單，而在「誰握方向盤」。

第一條是 browser-use：方向盤交給模型。你用 Python 描述任務，Agent 自己規劃步驟、自己操作瀏覽器，底層走 Playwright。它是目前社群最大的開源瀏覽器 Agent，適合目標明確、步驟不固定的任務，例如跨站比價、資料蒐集、例行後台操作。代價是控制力最弱：你很難精確規定它在某一步一定要怎麼做。

第二條是 Stagehand：方向盤留在你的程式碼裡。它由 Browserbase 開發，建立在 Playwright 之上，提供四個原語：observe() 先看有哪些可操作的元素，act() 用自然語言執行動作，extract() 按結構描述抽取資料，agent() 則在需要時把整個多步驟任務交出去。你的主流程仍是確定性的程式碼，只在選擇器容易斷的角落讓模型接手。寫 TypeScript、又想保留控制力的團隊，通常從這條路線開始。

第三條是 Playwright MCP：它自己沒有方向盤，只是一根轉向柱。如果你的 Agent 已經會講 MCP（例如 Claude Code、Cursor），加一個 Playwright MCP 伺服器就能讓它操作瀏覽器，新增程式碼最少。代價是你得自己扛編排：步驟規劃、錯誤恢復、成本控管，全部落在宿主 Agent 身上。

選型建議很直接：Python 且想要自主規劃，選 browser-use；TypeScript 且想保留確定性主流程，選 Stagehand；已經有 MCP 宿主、只想快速接上瀏覽器能力，選 Playwright MCP。

四、最小可跑骨架：先讓迴路轉起來

下面是一段 browser-use 風格的最小骨架，重點不在語法，而在結構：任務描述、模型、瀏覽器設定、驗證步驟，四者分開。

from browser_use import Agent, Browser, ChatOpenAI

browser = Browser(headless=False)  # 除錯期先用有介面模式
agent = Agent(
    task="打開訂單後台，找出狀態為待出貨的訂單，匯出成 CSV",
    llm=ChatOpenAI(model="gpt-5-mini"),
    browser=browser,
)
history = await agent.run()
# 關鍵：不要只看最終回答，要驗證副作用
assert history.final_result() is not None

骨架跑通之後，真正決定成敗的是四個實作要點。第一，每一步都要驗證：動作執行後，重新讀取頁面狀態，確認預期的變化真的發生了，而不是假設點擊就等於成功。第二，步驟預算要封頂：設定最大步數與單任務 token 上限，避免 Agent 在某個頁面無限鬼打牆。第三，失敗要分級：找不到元素可以重試一次，登入失敗、驗證碼出現、網域跳轉到預期之外，應該立刻停下來交給人類，而不是繼續亂點。第四，全程錄影與留痕：把每一步的截圖、動作、頁面網址存下來，出事時才有辦法重建現場。

五、安全護欄：上線前先裝好，不能事後補

瀏覽器 Agent 的風險與一般 Agent 不同：它操作的是真實的帳號與真實的金錢。送出訂單、刪除資料、變更設定，都是一次點擊的事。以下四道護欄建議在第一次上線前就裝好。

第一道是網域白名單：Agent 只能造訪事先核準的網域，任何跳轉到白名單之外的行為直接中止。第二道是動作分級：讀取與查詢可以自主執行，寫入、送出、付款、刪除必須先經過人類確認，這正是人類在迴路在瀏覽器場景的具體落法。第三道是身分隔離：給 Agent 專用的測試帳號與最小權限，不要讓它拿著你的主帳號登入；登入憑證與 Cookie 存在受控的瀏覽器設定檔裡，不要塞進提示詞。第四道是反爬蟲與服務條款的紅線：驗證碼本來就是設計來擋自動化的，繞過它可能違反目標網站的條款；遇到驗證碼與雙重驗證，正確做法是停下來交給人類，而不是想辦法破解。

六、評測與成本：先看基準，再談導入

評估瀏覽器 Agent 時，廠商數字要先問清楚是哪張考卷。WebVoyager 這類基準測的是常見任務的成功率，而針對登入、雙重驗證、表單填寫、下載等硬場景設計的評測，天花板會低得多——近期一篇針對開源瀏覽器 Agent 的橫向評測就指出，在刻意 stress 寫入流程的評測上，全場最佳成績約六成四，遠低於讀取為主的排行榜數字。導入前，先用自己的真實任務做一組黃金案例，跑出自己的成功率，比引用任何公開數字都有用。

成本也要用每任務來算，而不是每 token。一次十步左右的任務，模型成本大約落在數美分等級；但步驟一多、截圖一多，成本就跟著線性上升。省錢的三個槓桿是：DOM 精簡做得越好，提示詞越短；能用確定性程式碼處理的步驟，就不要叫模型；驗證步驟只在關鍵節點做，而不是每步都截圖比對。

結論

瀏覽器操作 Agent 不是要取代 Playwright，而是要取代「假裝網頁不會變」的那部分自動化。確定性的流程繼續用確定性的程式碼寫；步驟不固定、版面常變、需要臨場判斷的任務，才交給 Agent。實作順序建議是：先選感知方式，再選握方向盤的路線，骨架跑通後立刻裝上網域白名單、動作分級、身分隔離三道護欄，最後用自己的黃金案例量出真實成功率。這個順序做對，瀏覽器 Agent 才會從展示品變成每天能跑的工具。