Browser Automation 工具選型：agent-browser 省 90% Token 的 CLI-first 架構

[annie]

深度比較 5 款瀏覽器自動化工具 Token 效率，揭露 Vercel agent-browser 如何以 Snapshot+Refs 機制將單頁成本從 1.3 萬 tokens 降至 200-400，並提供 CLI→browser-use→GPT Agent 三層 fallback 實作藍圖。

核心結論

若目標是減少 GPT Token 消耗並建立「確定性 CLI 先行、語意理解才呼叫 LLM」的分層架構，Vercel Labs 的 agent-browser 是目前最貼合的選擇。其「Snapshot + Refs」機制讓單頁操作 Token 從 Playwright MCP 的 13,700 降至 200–400（效率提升 35–70 倍），並原生支援 agent-browser chat 指令作為輕量 fallback，無需每步都仰賴外部 GPT Agent。

---

主流工具效能對比

工具	核心機制	單頁 Token 消耗	10 步驟流程估算	適合場景
Playwright MCP	完整 Accessibility Tree 直接塞入 context	~13,700–15,000	~137,000+	Sandbox 環境、無 shell 權限時的備援
Playwright CLI	資料寫入磁碟（YAML/PNG），Agent 需要時才讀取	~200（僅回傳檔案路徑）	~27,000	Claude Code / Cursor 等 coding agent 官方推薦預設
agent-browser (Vercel Labs)	Snapshot + Refs（@e1 短參照），Rust CLI + Node daemon	200–400	~7,000	日常瀏覽、表單填寫，Token 效率最高
browser-use	State + Index，支援本機/真實 Chrome Profile/雲端三模式	與 agent-browser 相近	相近	需要登入態、反爬蟲、多站平行爬取的複雜任務
camhahu/browser	比 agent-browser 更輕量的 CLI 實作	官方宣稱快 3 倍	未公開	早期實驗性專案，社群測試中

資料來源：GitHub 專案文件與社群實測（heyuan110 技術部落格 2026-01-28）

---

為何 agent-browser 具備架構優勢

Snapshot + Refs 機制

傳統 Playwright MCP 將完整 DOM/Accessibility Tree 直接塞入 LLM context，導致 Token 暴增。agent-browser 採用不同策略：

1. Snapshot：回傳精簡的無障礙樹，僅保留互動相關節點
2. Refs：每個可互動元素分配短參照 ID（如 @e1、@btn-submit）
3. 後續操作：直接用參照 ID 執行 click、fill 等動作，不重複傳送頁面結構

這使單頁操作 Token 成本降低 82%–93%，且 Rust CLI 啟動極快，Node.js daemon 負責管理底層 Chrome CDP 連線。

原生雙模式切換

• agent-browser CLI 模式：確定性操作（導航、點擊、填寫、截圖）
• agent-browser mcp 模式：需 LLP 理解語意時切換
• agent-browser chat "<instruction>"：內建輕量 AI 修正，等同「CLI 失敗才調用 Agent」的設計，無需額外整合 GPT API

---

落地架構：三層 Fallback 設計

第 1 層：agent-browser CLI（確定性操作，Token 極低）
    ↓ 失敗（element covered、selector not found、動態內容）
第 2 層：agent-browser chat / browser-use（語意修正 / 登入態 / 平行任務）
    ↓ 仍失敗（非標準表單、複雜業務邏輯、需人類判斷）
第 3 層：GPT Agent（完整語意理解、規劃與恢復）

判斷失敗的實務指標

失敗類型	偵測方式	建議升級層級
Selector 失效 / 元素被遮擋	agent-browser diff snapshot 比對操作前後狀態	第 2 層（chat 指令修正）
需登入態 / Cookie 持久化	browser-use 真實 Chrome Profile 模式	第 2 層（browser-use）
多站點平行爬取	browser-use 雲端模式 Session 持久化	第 2 層（browser-use）
非標準表單 / 動態渲染 / 業務邏輯判斷	規則無法覆蓋的語意場景	第 3 層（GPT Agent）

---

實作步驟速查

1. 安裝與基礎驗證

# 安裝 agent-browser（需 Rust toolchain + Node.js）
cargo install agent-browser
# 或使用 npm
npm i -g @vercel-labs/agent-browser

# 驗證 CLI 可用
agent-browser --version
agent-browser snapshot https://example.com

2. 建立確定性技能腳本

# skills/login.yaml
steps:
  - goto: https://app.example.com/login
  - fill: '@e1'  # username input ref
    value: ${USERNAME}
  - fill: '@e2'  # password input ref
    value: ${PASSWORD}
  - click: '@e3' # submit button ref
  - wait: networkidle
  - snapshot: login-success

agent-browser run skills/login.yaml

3. 整合 Fallback 邏輯（伪代碼）

def execute_with_fallback(task: str, max_retries: int = 2):
    # Layer 1: Deterministic CLI
    for attempt in range(max_retries):
        result = agent_browser_cli(task)
        if result.success:
            return result
        if is_recoverable_error(result.error):
            continue  # retry with adjusted selector
        break
    
    # Layer 2: Semantic correction via built-in chat
    result = agent_browser_chat(f"Fix this: {task}. Error: {result.error}" )
    if result.success:
        return result
    
    # Layer 2b: browser-use for authenticated/parallel scenarios
    if requires_auth_or_parallel(task):
        result = browser_use_cloud(task, profile="persistent" )
        if result.success:
            return result
    
    # Layer 3: Full GPT Agent
    return gpt_agent_plan_and_execute(task)

4. 狀態比對驗證操作成效

# 操作前快照
agent-browser snapshot https://app.example.com/dashboard --output before.json

# 執行操作
agent-browser run skills/export-report.yaml

# 操作後快照並比對
agent-browser snapshot https://app.example.com/dashboard --output after.json
agent-browser diff before.json after.json

diff 輸出會顯示 DOM 結構變化、網路請求、Console 錯誤，作為判斷是否升級 Layer 2/3 的客觀依據。

---

常見陷阱與避坑指南

陷阱	徵兆	解決方案
過度依賴 LLM 判斷每一步	Token 成本失控、延遲高	嚴格區分「確定性操作」與「語意理解」，只在後者用 LLM
忽略登入態持久化	每次執行都需重新登入、觸發風控	引入 browser-use 真實 Chrome Profile 或雲端 Session 模式
Selector 硬編碼	頁面微調即失效	善用 agent-browser 的 Refs（@e1）與 diff 機制動態定位
缺乏可觀測性	失敗原因難以複現	每步驟自動產生 snapshot + PNG + network log，建立可重放軌跡
單一工具試圖解決所有場景	複雜任務成功率低	採用分層架構，各層工具專注各自強項

---

何時選擇其他工具

• Playwright MCP：受限於無 shell 環境（如某些 Sandbox、Serverless 容器），且 Token 成本可接受時
• Playwright CLI：團隊已深度使用 Claude Code / Cursor 內建 browser tool，遷移成本高時
• browser-use：核心需求為多站點平行爬取、需真實瀏覽器指紋/登入態、雲端無頭運行時
• camhahu/browser：願意承擔早期專案風險、追求極致啟動速度的實驗性專案

---

總結

決策維度	推薦方案
Token 成本最低	agent-browser (200–400 tokens/頁)
架構最貼合 CLI-first + Agent fallback	agent-browser 內建 chat 指令 + diff 驗證
需登入態 / 平行 / 反爬蟲	疊加 browser-use 作為第 2 層
完全語意理解 / 複雜決策	保留 GPT Agent 作為第 3 層兜底

採用 agent-browser → browser-use → GPT Agent 三層架構，可在保持高成功率的前提下，將 Token 成本壓縮至原本 Playwright MCP 方案的 <10%，並獲得清晰的可觀測與除錯路徑。