瀏覽器自動化新選擇：超越 CDP 的精準定位與 Hybrid 架構實戰指南

AI
, , , ,
1

深入解析 Accessibility Tree + Ref 為何優於 CDP 與視覺點擊，掌握 Playwright MCP、Extension Relay、WebMCP 等 2025-2026 前沿工具鏈，打造高準度、可重現的 AI 瀏覽器代理。

為什麼 CDP 不是唯一、也非最佳解

ChatGPT Codex、Claude Chrome Extension 等主流產品多透過 chrome.debugger 取得 CDP（Chrome DevTools Protocol）控制權，操作使用者已登入的真實瀏覽器。這條路能力強，但不是唯一、也不一定最精準的 browser automation 方式。

核心結論：若目標是「對元素操作很準、可重現、適合 AI agent」，目前更常被採用的是 Accessibility Tree（無障礙樹）+ 結構化 ref 定位（以 Playwright MCP / CLI 為代表），而非直接裸打 CDP 或用截圖座標點擊。

常見「非 CDP」手法其底層實際關係

表象做法 實際底層（Chromium） 是否仍算 CDP 路線
Chrome Extension + chrome.debugger CDP handle 是
Puppeteer 直接包 CDP 是
Playwright（Chromium） CDP abstraction 是（Firefox/WebKit 用各家協定）
Selenium WebDriver WebDriver 協定（經 driver 轉譯） 否（協定層不同）
WebDriver BiDi W3C 雙向標準協定 否（新一代標準）
Computer Use / 視覺點擊 螢幕截圖 + 座標 否（OS/像素層）
純 content script / chrome.scripting 頁面 JS 注入 否（權限與能力較窄）

關鍵洞察：Codex / Claude extension「連 CDP」只是其中一種連線與控制平面；真正決定「準不準」的，往往是 LLM 看到什麼（DOM / a11y tree / screenshot），以及 怎麼定位元素（selector / role+name / ref / 座標）。

方法一：Accessibility Tree + Ref（目前 AI 最準的主流）

這是 2025–2026 年 AI browser agent 最重要的轉向。Playwright MCP / Playwright CLI 預設用 Snapshot Mode：每次操作後回傳頁面的 accessibility tree（YAML），每個可互動元素帶 role、name 與穩定 ref（如 e5）。Agent 用 ref 點擊／填表，而不是猜 CSS、也不是看像素。

text- heading "todos" [level=1]
- textbox "What needs to be done?" [ref=e5]
- button "Add" [ref=e10]

為什麼通常比裸 CDP / 視覺點擊更準

  • 讀的是語意結構，不是畫面像素；按鈕移 2px 通常不會壞
  • 不需要 vision model，定位確定性高
  • Playwright 內建 auto-wait，SPA 動態渲染較穩
  • getByRole() 這類 locator 本來就走 a11y tree，和真實使用者／輔助科技的觀點一致

代表工具

工具 官方入口 適合場景
Playwright MCP npx @playwright/mcp@latest 給 Claude / Cursor 等 MCP client 完整 browser control
Playwright CLI @playwright/cli coding agent、token 成本更敏感的工作流
Playwright 官方 library E2E、CI、跨瀏覽器、self-healing tests

準度定位：結構化 UI（表單、後台、儀表板、CRUD）通常是目前最穩的一檔。
限制：獨立 browser instance（預設），要重用本機登入態需額外接 CDP endpoint 或 persistent profile；a11y 很差的頁面（無 role/name）會變難操作。

方法二：DOM / JS 注入（Content Script、chrome.scripting）

不走 chrome.debugger、不開 remote debugging，也能很準：extension 或 content script 直接在頁面執行 JS，用 selector / XPath / 文字匹配操作 DOM。

典型能力

  • document.querySelector 點擊、填值
  • 對 React 受控元件補 dispatch input / change
  • 讀取文字、屬性、表格
  • 監聽 network（能力取決於權限與是否另接 debugger）

優缺點權衡

優點

  • 不需 --remote-debugging-port
  • 可作用在使用者已開著的真實 session
  • 對「已知 DOM 結構」的任務極準、延遲低

缺點

  • 跨 origin、chrome://、Chrome Web Store 等受限
  • 沒有完整 CDP 的 network/performance/service worker 深度控制
  • 對 shadow DOM、canvas、跨 frame 要自己處理
  • 動態 class 名一變，硬編 selector 就碎

這條路適合「已知站點、已知流程」的 RPA；不太適合開放式「去任意網站幫我搞定」的 general agent。

方法三：WebDriver 與 WebDriver BiDi（協定層真替代）

若要在協定層上不依賴 CDP，這兩條才是真正不同的控制平面。

Selenium / classic WebDriver

  • 透過 HTTP 的 WebDriver 協定，經 ChromeDriver 等中介層轉成瀏覽器動作
  • 跨瀏覽器生態最久、文件最多
  • 對 Chrome 來說最終仍可能落到瀏覽器內部自動化，但client 寫的不是 CDP
  • 代價：多一層轉譯，延遲與複雜度通常高於直接 CDP / Playwright

WebDriver BiDi

  • W3C 新一代雙向協定，目標是結合 WebDriver 的標準化與 CDP 類的即時事件能力
  • 設計上跨瀏覽器，不是 Chrome-only
  • 對 scraper / multi-browser agent 長期更乾淨，但生態成熟度與工具豐富度仍追趕 Playwright/CDP 系

準度定位：元素定位仍可做到很準（尤其配合明確 selector / role）；勝在標準化與跨瀏覽器，不在 AI-native 體驗。

方法四：Computer Use / Vision（截圖 + 座標）

OpenAI / Anthropic 等 Computer Use 路線：看螢幕截圖 → 輸出點擊座標 / 鍵盤事件。這完全不必理解 DOM 或 CDP，也能操作瀏覽器，甚至桌面 App。

何時有用

  • Canvas、地圖、自訂繪圖 UI
  • 無良好 a11y / 無穩定 DOM 的介面
  • 需要「像人一樣看畫面」的驗證

為何通常比較不準（對一般網頁）

  • 解析度、縮放、動畫、ads 會讓座標漂移
  • 同色按鈕、小 icon 容易誤點
  • token 與延遲成本高
  • 可重現性差，不適合嚴格 E2E

社群共識：結構化網頁任務，DOM / a11y 路線通常明顯勝過純 vision；vision 當 fallback 或特殊 UI 補強較合理。

方法五：Hybrid —— 現有瀏覽器 + 高階 API（兼顧登入態與準度）

很多正式方案其實是「連線方式」與「定位方式」的組合：

  1. Extension Relay：本機 WebSocket / loopback → extension →（可選）chrome.debugger 或 chrome.scripting
  2. Playwright connectOverCDP：接上你已開的 Chrome，沿用 cookies / SSO，但操作仍用 Playwright locator / snapshot
  3. Persistent profile / headed browser：保留登入，同時用 a11y ref 操作

這能同時拿到：

  • 真實 session（已登入 Gmail、後台、2FA 後狀態）
  • 結構化定位的準度（不是盲點座標）

也是 Codex / Claude extension 體驗好的主因之一：不是因為 CDP 魔法，而是重用你的瀏覽器狀態。

準度怎麼排（針對「要操作對、可重現」）

以下以「一般商業網頁 / SaaS 後台 / 表單流程」為前提：

排名 方法 準度特質 最怕什麼
1 Accessibility tree + ref（Playwright MCP/CLI） 語意定位、auto-wait、對 AI 最友善 頁面 a11y 極差、純 canvas
2 DOM/JS + 穩定 selector / testid 工程可控、極快 前端亂改 class、shadow/complex frame
3 高階 library（Playwright/Puppeteer API） 生態成熟、trace/debug 強 過度依賴脆弱 CSS
4 直接 CDP 裸呼叫 能力最全、效能高 樣板碼多、自己處理 wait/race
5 WebDriver / BiDi 標準化、跨瀏覽器 延遲/生態或成熟度取捨
6 Vision Computer Use 通用、可跨 App 座標漂移、成本、不穩

補充：若任務是「只要查公開資訊」，根本不必 browser automation，用 Web Search API 往往更準更快；browser 留給登入牆、CSR 動態頁、互動流程。

與 Codex / Claude Extension 對照

維度 Codex / Claude Chrome extension Playwright MCP/CLI 路線 純 Vision Computer Use
連線 Extension relay → 常經 debugger/CDP 本機 browser process 或接 CDP OS/螢幕層
看頁面方式 產品內部實作（多為結構+必要時視覺） 預設 a11y snapshot 截圖
登入態 極佳（你的真實 Chrome） 需設定才等同 看你開哪個畫面
元素準度 高（實務夠用） 通常最高且可重現 中到不穩
可腳本化 / CI 偏互動式 強 弱
跨瀏覽器 基本 Chrome Chromium/Firefox/WebKit 視實作
適合 日常已登入任務、人工協作 Agent、測試、自動化管線 怪 UI / 桌面混合

Claude 生態甚至同時存在「Claude in Chrome」與「Playwright MCP」兩條：前者吃真實 session，後者吃 deterministic automation；進階使用者常依任務切換，而不是只押一條。

實務選法（精準優先）

  • 要最準、可重現、給 AI agent 長期跑 → Playwright accessibility snapshot（MCP 或 CLI）
  • 要操作「我已經登入的 Chrome」 → Extension relay（Claude/Codex 型）或 Playwright connectOverCDP + 既有 profile
  • 只要固定站點 RPA、不想開 debugger → Content script / chrome.scripting DOM 操作
  • 要跨 Firefox/WebKit 或符合 W3C 方向 → Playwright 多瀏覽器，或評估 WebDriver BiDi
  • 頁面幾乎沒 DOM 語意（canvas/遊戲式 UI） → Vision Computer Use 當主路徑或 fallback
  • 公開資料蒐集 → 先 Search API，失敗再 browser

一個常被忽略的準度關鍵

「準不準」常常不是協定選 CDP 或非 CDP，而是這三層有沒有對齊：

  1. Perception（感知）：a11y tree > 精簡 DOM > 全 HTML > screenshot
  2. Grounding（定位）：role+name/ref/testid > 穩定 CSS > XPath > 像素座標
  3. Action + Wait（動作與等待）：auto-wait / network idle / 明確條件 > sleep

Codex / Claude extension 的價值，主要在把 1–3 包成產品，並掛上你的真實 browser session；若你自建 agent，用 Playwright snapshot 路線，通常能在「準度與可維護性」上追平甚至超過「只是連上 CDP」。

簡短架構圖

LLM / Agent
    │
    ├─ MCP / CLI / SDK
    │
    ├─ 控制平面（擇一或混合）
    │     • Extension Relay（真實 session）
    │     • Playwright/Puppeteer
    │     • Direct CDP
    │     • WebDriver / BiDi
    │     • OS Vision hooks
    │
    └─ 感知與定位（決定準度）
          • Accessibility tree + ref   ← 目前最推薦
          • DOM + testid/selector
          • Screenshot + coordinates

Hybrid Chrome Extension 高準度 Browser Automation：2026 前沿地圖

你要的是這條路：用 Chrome Extension 掛在「真實、已登入的瀏覽器」上，同時用結構化定位（a11y snapshot / ref）把準度拉到接近 Playwright E2E。2025–2026 這條 Hybrid 路線已從實驗變成主流產品形態；最值得跟的不是「再包一層 CDP」，而是 Extension Relay + Accessibility Snapshot +（可選）網站原生 WebMCP tools。

這條賽道在解什麼

痛點 Hybrid 怎麼解
獨立 headless 沒有你的 cookies / SSO / 2FA Extension 連既有 tab / profile
純 vision 點擊不穩 用 a11y tree + ref 操作
裸 CDP 樣板多、難給 LLM 用 MCP / CLI 把動作收成工具
Bot detection 擋自動化 browser 用真實 fingerprint + 真實 session

架構可簡化成：

AI Client (Claude / Cursor / Codex / 自建 agent)
        │  MCP / local WS
        ▼
   Local MCP Server
        │  token / loopback
        ▼
 Chrome Extension (relay)
        │  debugger / scripting / page bridge
        ▼
  真實 Chrome tabs（cookies、extensions、登入態）
        │
        ▼
 Perception: a11y snapshot / DOM / (fallback) screenshot
 Action: click(ref) · type(ref) · navigate · tabs

前沿發展（2025 下半～2026）

1. Extension Mode 成為一等公民

Microsoft 把 Playwright MCP 的 --extension 做成正式連線模式：裝 companion extension 後，MCP 不再另開空 browser，而是接管你已開的 tabs，沿用登入態、cookies、其他 extension。

重點能力：

  • SSO / 2FA 後狀態直接重用
  • PLAYWRIGHT_MCP_EXTENSION_TOKEN 做本機安全綁定，減少每次手動核准
  • 操作層仍是 Playwright 的 snapshot / ref，不是盲點座標

這幾乎就是「方法 5」的官方標準答案。

2. Accessibility Snapshot 持續為 AI 優化

Playwright MCP 持續強化 token 效率與可重現性，例如：

  • Incremental page snapshots（未變元素標 [unchanged]，降噪、降 token）
  • Secrets 處理（使用者提示中的密文不送進 LLM）
  • form filling、verification tools、shared browser context 等 agent 向工具

Hybrid 的準度分水嶺在這裡：連線用 extension，定位用 a11y ref。

3. WebMCP：網站主動暴露「可呼叫工具」

Google / W3C 方向的 WebMCP 讓網站用 Declarative（HTML form）與 Imperative（JS）API，把 searchFlights()、bookTicket() 這類動作直接暴露給 in-browser agent，而不是靠 DOM 猜測。

  • Chrome Early Preview / Origin Trials 推進中
  • Cloudflare Browser Run 已接 WebMCP，可與 CDP 並用
  • 目標：比 screenshot-analyze-click 更快、更準、更省算力

對 Hybrid 的意義：extension agent 未來可走**「先 listTools → 有原生 tool 就直呼；沒有再 fallback a11y/DOM」**。

4. Chrome DevTools for Agents（官方 agent 除錯面）

Chrome 把 DevTools 能力做成給 coding agent 用的套件，並支援 extension 除錯：安裝/卸載 extension、重載、觸發 action、檢查 popup 與 service worker。這代表 Google 正式承認：agent 要能穩定操作「帶 extension 的真實 Chrome」，而不只是 headless 沙箱。

5. 產品化 Hybrid：Codex / Claude in Chrome

閉源產品端（ChatGPT Codex Chrome、Claude in Chrome / Claude Code Browser Control）驗證了同一架構：local extension bridge + 真實 session + 多 tab agent。開源與官方工具則在把同等能力拆成可組合元件（MCP server + extension + snapshot）。

必看 GitHub / 工具清單

A. 核心：Extension + 高準度操作（最優先）

專案 類型 為什麼重要 成熟度
microsoft/playwright-mcp MCP server + 官方 Extension mode Hybrid 準度基準；a11y snapshot + 連既有 Chrome 生產可用（生態最大）
playwright/packages/extension Companion Chrome Extension 預設 profile、登入態、token 綁定 官方維護
BrowserMCP/mcp MCP + Chrome extension 明確 fork/adapt Playwright MCP，專注「自動化你的瀏覽器」而非新 instance；強調 stealth + logged-in 熱門開源（約 4.7k★）
Chrome Web Store: Playwright Extension Extension 與 @playwright/mcp --extension 成對使用 官方

建議起手式（目前最接近「高準 Hybrid」）：

{
  "mcpServers": {
    "playwright-extension": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--extension"],
      "env": {
        "PLAYWRIGHT_MCP_EXTENSION_TOKEN": "your-token-from-extension-ui"
      }
    }
  }
}

若暫時不裝 extension，也可用 channel / CDP 接既有 Chrome（準度同屬 Playwright 系，但連線方式不同）：

npx @playwright/mcp@latest --cdp-endpoint=chrome
# 或
npx @playwright/mcp@latest --cdp-endpoint=http://localhost:9222

B. 官方 / 標準層（決定未來 1–2 年）

專案 / 文件 角色 你該關注什麼
Playwright MCP：Connecting to Browsers 官方連線文件 channel / CDP / extension 三種接法
Chrome: WebMCP early preview 網站側 agent API Declarative + Imperative tools
GoogleChromeLabs/webmcp-tools WebMCP 工具與範例 站方如何 register tools
webmcpnet/awesome-webmcp 資源彙整 規格、demo、生態追蹤
Chrome DevTools for agents Agent 除錯 / 控制面 extension 安裝、reload、surface 檢查
Chrome Extensions + AI agents 用 coding agent 開發 extension 官方 skills / MWG 方向
Cloudflare Browser Run + WebMCP 雲端 browser + 原生 tools listTools / executeTool，可與 CDP 並用

C. 開源 Hybrid / Relay 生態（可對照、可魔改）

專案 說明 適合
BrowserMCP/mcp MCP server + extension；local、private、logged-in、較不易觸發基礎 bot 偵測 想要「開源版 Claude/Codex 連本機 Chrome」
AgentDeskAI/browser-tools-mcp 讓 Cursor 等 IDE 讀 console / 瀏覽器訊號 除錯向，不完全是全自動 RPA
imprvhub/mcp-browser-agent Claude Desktop 用 Playwright MCP agent（偏 headful 新 instance） 對照「非 extension、但 MCP 化」基線
angrykoala/awesome-browser-automation 自動化工具策展清單 掃生態、找冷門工具
Chrome Web Store: Browser Use for AI Agents 本機 extension bridge（multiplexed browser MCP 方向） 接 browser-use 類 agent
Claude Code Browser Control 官方生態 extension：經 local MCP 操作 active tab 對齊 Claude 工作流
AutomaApp/automa 區塊式 extension 自動化（非 LLM-native，但 extension RPA 經典） 固定流程、低代碼；可當 hybrid 前身參考

D. 閉源產品（對標與 UX 借鏡）

產品 借鏡點
ChatGPT Codex Chrome extension 多 tab 並行、真實 Chrome session、agent 工作流產品化
Claude in Chrome / Claude Code + Chrome 真實 session + 可錄製/重播工作流；與 Playwright MCP 雙軌並用很常見

閉源通常不開核心 relay，但 UX 與權限模型（何時要人確認、多 agent 分 tab、background 執行）值得抄。

準度技術棧：Hybrid 專案該長什麼樣

若你要自建或評估「非常準」的 Extension Hybrid，建議對齊這組能力（Playwright MCP extension 路線已大半具備）：

層級 建議實作 避免
連線 Extension relay + 本機 token；可選 CDP fallback 把 debugging port 裸露到區網
感知 Accessibility snapshot（增量） 每次丟全 HTML / 全螢幕給 LLM
定位 ref / role+name / testid 純 CSS hash class、純座標
動作 click/type/select + auto-wait 固定 sleep
登入態 預設 profile / 既有 tabs 每次新 context 重登
安全 secrets redaction、origin allowlist、人在迴路確認敏感動作 extension 全域任意 JS 無審核
演進 偵測頁面 WebMCP tools → 優先直呼 永遠只 scrape DOM

怎麼選（務實決策）

你的目標 首選 備註
現在就要最高準度 Hybrid Playwright MCP + official extension 文件、生態、snapshot 品質最佳
要開源、專注「我的 Chrome」 BrowserMCP 從 Playwright MCP 改為 user browser 導向
對齊 Claude 日常 Claude Browser Control extension + 必要時 Playwright MCP 產品便利 vs 工程可控可並用
做網站/SaaS 給 agent 用 實作 WebMCP tools 比任何 client 端 selector 都穩
雲端 scale + 真實 browser 能力 Browserbase/Stagehand 或 CF Browser Run；有 WebMCP 更好 與本機 extension 是不同部署面
固定流程、少 LLM Automa 類 extension RPA 準，但不算 AI agent

建議追蹤清單（Repo / 文件 watch）

  1. microsoft/playwright-mcp — extension mode、snapshot、secrets、tool 表面
  2. microsoft/playwright packages/extension — companion extension 行為
  3. BrowserMCP/mcp — 開源 user-browser MCP 參考實作
  4. GoogleChromeLabs/webmcp-tools + Chrome WebMCP blog — 網站原生 tool 標準
  5. Chrome DevTools for agents — 官方 agent↔browser 控制面
  6. webmcpnet/awesome-webmcp — 規格與 demo 聚合

總結

2026 的 Hybrid 前沿 =「Chrome Extension 負責真實 session」+「Playwright-class a11y snapshot 負責準度」+「WebMCP 負責網站主動合作」。

若只選一個開源起點：先上 Playwright MCP --extension；若要研究可魔改的 relay 架構，並讀 BrowserMCP；若做產品/站方，同步跟 WebMCP。

協定可以換，結構化感知與定位才是準度的核心。