Claude Code 很強,它能寫程式、跑指令。
但是它有個天生的限制——看不到瀏覽器。
雖然它可以透過解析頁面結構的方式來取得資料,但假如資料是動態的、有反爬蟲機制的,甚至是你想讓它操作你的瀏覽器——在過去,是做不到的。
好消息是,2025 年底到 2026 年初,社群和官方都在瘋狂補這個缺口。現在至少有 9 種方式可以讓 Claude Code 操作 Chrome,但每種的定位、優缺點差很多。
我把它們全整理了一遍,加上網友實測的 Token 消耗數據,幫你搞清楚該用哪個。
先講結論
如果你懶得看完整篇,這是我的建議:
日常讀網頁、截圖、抓資料 → PinchTab(每頁只要 ~800 tokens)
抓特定平台資料(Twitter、GitHub、YouTube⋯) → bb-browser(用你的登入狀態,36 個平台直接用)
輕量自動化、表單擷取 → agent-browser(省 token 又穩定)
複雜的多步驟自動化 → browser-use(AI 自己判斷下一步)
Web 開發除錯 → Chrome DevTools MCP(完整的 DevTools 能力)
快速看一下網頁 → Claude in Chrome(零設定,但 Beta 品質)
下面一個一個講。
先搞懂一件事:Token 消耗為什麼重要?
很多人選工具只看功能,忽略 Token 消耗。但這其實是最關鍵的指標。
Context window 就是電池。每次讓 AI 讀一個網頁,就消耗一塊電。如果一個工具每頁吃 10,000+ tokens,跑個 10 步驟的自動化流程就燒掉 100,000+ tokens。而另一個工具每頁只要 800 tokens,同樣 10 步只要 8,000 tokens。
差距是 12 倍。這不是小事——token 燒完了,要不就是對話被壓縮(AI 忘記前面做了什麼),要不就是直接撞到 rate limit。
網友 Benson Sun 實測了抓取 Hacker News 首頁同一個任務:
工具 Token 消耗 資料大小 agent-browser 3,500 tokens 13.5 KB Chrome DevTools MCP 9,500 tokens 32 KB Playwright MCP 16,000 tokens 58 KB
同一個任務,最多差 4.5 倍。所以選對工具真的有差。
1. Claude in Chrome 擴充套件(官方)
Anthropic 自己出的,2025 年 8 月研究預覽,12 月開放所有付費方案。
裝好 Chrome 擴充套件之後,Claude Code 就能直接控制你的瀏覽器。它會開新分頁執行操作,而且共用你的登入狀態——你已經登入的 Gmail、Notion、GitHub,它都能直接用。
優點:
零設定,裝完擴充套件就能用
用你真實的瀏覽器 profile,cookies 和登入狀態都在
操作在你面前即時執行,看得到它在幹嘛
缺點:
Beta 品質,會隨機斷線
文字輸入有 bug,會掉第一個字元
多行文字輸入直接壞掉
每頁消耗 10,000+ tokens
適合: 偶爾需要快速看一下網頁、簡單點擊互動。不適合大量自動化。
Chrome DevTools 團隊維護的 MCP server,讓 Claude Code 擁有完整的 DevTools 能力。
原理很直覺:Chrome 啟動時加上 --remote-debugging-port=9222,MCP server 透過 Chrome DevTools Protocol 連上去控制。你能用 DevTools 做的事,它基本上都能做。
google-chrome --remote-debugging-port=9222
優點:
官方 Chrome 團隊維護,穩定
完整的 DevTools 能力:Network 監控、Console 訊息、Performance 分析、JS 執行
社群實測可以減少 40% 除錯時間
缺點:
每次都要重新啟動 Chrome
用獨立 profile,不共用你的 cookies 和登入狀態
每頁 10,000+ tokens(光是工具定義就要 ~17,000 tokens)
文字輸入有跟 Claude in Chrome 一樣的 bug
省 Token 技巧: 加上 --slim 參數啟動精簡模式,只保留 3 個工具(navigate、execute JS、screenshot),大幅降低 context 消耗。如果你只是要看看頁面狀況,不需要完整的 Network/Performance 分析,用精簡模式就夠了。
適合: Web 開發除錯、效能分析、Network 監控。如果你是前端工程師,這是除錯利器。
3. Playwright MCP(微軟)
微軟維護的 MCP server,用 Playwright 引擎驅動。特別的是它不靠截圖,而是用 accessibility snapshot 來理解頁面結構。
"args" : [ "@playwright/mcp@latest" ]
優點:
跨瀏覽器支援:Chrome、Firefox、Safari
Accessibility tree 解析比截圖更精準
微軟維護,品質有保障
Auto-wait 機制:自動等元素可見、沒有彈窗遮擋、位置穩定後才執行操作,不會因為時機問題出錯
支援 --extension 模式連接現有瀏覽器(保留登入狀態)
支援 --device "iPhone 15" 模擬裝置
缺點:
Token 消耗比預期高——實測每頁 ~15,000 tokens,10 步驟工作流累積約 114,000 tokens
工具定義本身就佔 ~13,700 tokens
預設啟動獨立瀏覽器實例(除非用 --extension 或 --cdp-endpoint 模式)
適合: 自動化測試、需要跨瀏覽器驗證的場景。如果你的工作是 QA 或前端測試,首選這個。
騰訊雲技術社群的結論:「Playwright 是預設選擇,DevTools 做補充診斷,大約 95:5 的工作量分配。」但要注意 token 消耗——如果你的任務不需要跨瀏覽器,其他工具可能更划算。
4. PinchTab — 社群實測最推薦
這個工具在社群裡被稱為「改變標準的存在」。有人把市面上所有工具都測過一輪,最後日常首選就是 PinchTab。
原理:它跑一個常駐的 HTTP server(port 9867),用 Chrome accessibility tree 來解析頁面。
為什麼它特別?看數字就知道:
工具 每頁 Token 消耗 Chrome DevTools MCP 10,000+ Claude in Chrome 10,000+ browser-use 10,000+ agent-browser 3,000-5,000 PinchTab ~800
每頁只要 800 tokens。是 Chrome DevTools MCP 的 十二分之一 。
優點:
每頁 ~800 tokens,超省 token
用你真實的瀏覽器 profile,cookies 登入狀態都在
Windows、Mac 都穩定
多種模式:pinchtab text(~800 tokens)、pinchtab snap(~2,000 tokens)、pinchtab ss 截圖(~2,000 tokens)
啟動一次就好,不用每次重啟
缺點:
適合: 日常讀網頁、抓資料、截圖、UI 測試。如果你每天都需要讓 Claude Code 看網頁,選這個。Context 就是電池,省 token 就是省錢。
5. agent-browser(Vercel)
Vercel 出品,主打 token 效率。它的核心設計理念是:只回傳 AI 需要的資訊,過濾掉靜態內容。
別的工具回傳整個 DOM 或完整的 accessibility tree,agent-browser 只回傳可互動的元素(按鈕、輸入框、連結)。結果就是:
Token 消耗對比(10 步驟自動化工作流):
工具 累積 Token Playwright MCP ~114,000 Chrome DevTools MCP ~50,000 agent-browser ~7,000
同樣的工作流,agent-browser 只用了 Playwright MCP 的 十六分之一 。
Vercel 內部測試的數據更誇張:從 17 個工具精簡到 2 個之後,執行速度快 3.5 倍、token 省 37%、成功率從 80% 提升到 100%。
優點:
極低的 token 消耗(每頁 ~1,000 tokens,工具定義 0 tokens)
穩定
有 Auth Vault 存憑證
支援 Network mocking 和 visual diffs
缺點:
每次啟動新的 Chromium 實例,cookies 不持久化
Windows 有 UNC 路徑 bug(需設定 AGENT_BROWSER_HOME 繞過)
對社群網站的文字擷取還是偏重
適合: 日常自動化、資料擷取、表單填寫。如果你最在意 token 效率又不需要持久化登入狀態,這是很好的選擇。
6. bb-browser — 你的瀏覽器就是 API
這個工具的思路跟前面的都不一樣。它的口號是:「Your browser is the API. No keys. No bots. No scrapers.」
其他工具是讓 AI 操控一個瀏覽器實例去瀏覽網頁。bb-browser 的做法是:直接利用你已經登入的 Chrome,透過你的身份去抓資料。因為流量來自你真實的登入 session,網站根本分不出來這是人還是 AI 在操作。
npm install -g bb-browser
覆蓋 36 個平台、103 個指令:
搜尋引擎:Google、Bing、DuckDuckGo、百度
社群:Twitter/X、Reddit、LinkedIn、微博、知乎
開發者:GitHub、Stack Overflow、arXiv
影音:YouTube、Bilibili
財經:Yahoo Finance
新聞:BBC、Reuters
不用寫爬蟲、不用找 API key、不用處理反爬機制。你在 Chrome 裡能看到的資料,bb-browser 都能抓。
優點:
用你真實的登入 session,完全繞過反爬偵測
36 個平台開箱即用,不需要各自設定 API
支援 MCP 協議,直接整合 Claude Code
社群驅動的 adapter 生態,新平台持續增加
支援多 tab 並行操作
2,000+ GitHub stars,MIT 授權
缺點:
依賴 Chrome 擴充套件(或 OpenClaw)
需要跑 local daemon(port 19824)
只能操作有寫好 adapter 的平台,通用性不如 Playwright
適合: 需要從特定平台抓資料(Twitter timeline、GitHub issues、YouTube 影片資訊、Reddit 討論串⋯),而且這些平台有登入牆或反爬機制。簡單講:你平常手動開 Chrome 去看的那些網站,它都能幫你自動化。
7. Browser MCP(browsermcp.io)
Chrome 擴充套件 + MCP server 的組合。在 Chrome Web Store 有 10 萬用戶,4.9 星評分。
優點:
本地執行,速度快、隱私好
用你真實的瀏覽器 profile
可以避開基本的 bot 偵測(因為用你真實的瀏覽器指紋)
支援 VS Code、Cursor、Claude Code 等多種 AI 工具
缺點:
適合: 表單填寫、資料擷取、需要登入狀態的操作。如果你同時用多種 AI 工具,它的通用性是優勢。
8. dev-browser(SawyerHood)
以 Claude Code Skill 形式存在的瀏覽器控制工具。
/plugin marketplace add sawyerhood/dev-browser
/plugin install dev-browser@sawyerhood/dev-browser
優點:
頁面狀態持久化:cookies、localStorage 跨操作保留
用 ARIA snapshot 探索元素,對複雜頁面很有效
有 Chrome 擴充套件可以控制你現有的 tabs
缺點:
適合: 多步驟表單填寫、需要維持登入狀態的連續操作。適合那種要登入 → 點三個按鈕 → 填一堆欄位的場景。
9. browser-use(Python)
這個跟前面的都不一樣。它不只是讓 Claude Code「看到」瀏覽器,而是讓 AI 自己決定下一步要做什麼。
GitHub 8 萬+ stars,MIT 授權。
原理: 你告訴它目標(「幫我在這個網站投履歷」),它自己判斷要開哪個頁面、點哪個按鈕、填什麼欄位。人類只需要在旁邊監督。
優點:
全自動多步驟操作:填表單、投履歷、跨頁面流程
AI 自己判斷步驟,你不用一步一步教
社群活躍,8 萬+ stars
缺點:
每頁 10,000+ tokens
每一步都呼叫一次 LLM,token 成本高
比手動指定步驟慢
適合: 複雜的多步驟自動化流程。如果你要做的事情步驟很多、頁面會變、需要 AI 判斷,這是唯一能做到「AI 填、人監督」的方案。
完整比較表
工具 每頁 Tokens 工具定義開銷 10 步驟累積 設定難度 用真實 Profile 穩定性 最佳用途 Claude in Chrome 10,000+ — 100,000+ 低 ✅ ⚠️ Beta 快速瀏覽 DevTools MCP 9,500 ~17,000 ~50,000 中 ❌ ✅ 開發除錯 Playwright MCP ~15,000 ~13,700 ~114,000 中 ⚠️ 需 extension 模式 ✅ 自動化測試 PinchTab ~800 低 ~8,000 低 ✅ ✅ 日常萬用 agent-browser ~1,000 0 ~7,000 中 ❌ ✅ 輕量自動化 bb-browser 低(結構化) 低 低 中 ✅ ✅ 特定平台抓資料 Browser MCP 中等 — — 低 ✅ ✅ 表單/擷取 dev-browser 中等 — — 中 ✅(擴充) ✅ 持久操作 browser-use 10,000+ — 100,000+ 中 ✅ ✅ 複雜自動流程
Token 數據來源:Benson Sun 實測 、DEV Community 社群實測 、騰訊雲技術社群
網友怎麼選?社群觀點整理
Benson Sun 的實測結論
他用同一個任務(抓 Hacker News 首頁文章)測試三個工具,發現 token 消耗最多差 4.5 倍。他的建議是:依場景切換工具 。日常任務用 agent-browser 省 token,除錯用 DevTools MCP,複雜流程用 Playwright。
騰訊雲技術社群的選擇框架
他們提出了一個很清楚的分法:
需要判斷的流程 (填表、導航、E2E 測試、跨瀏覽器)→ Playwright MCP
需要診斷的場景 (效能追蹤、Network 瀑布圖、Console 錯誤深挖)→ Chrome DevTools MCP
工作量分配大約是 95:5
他們還指出一個重要數據:同一個頁面,原始 DOM 消耗 50,000-100,000 tokens,但 accessibility tree 只需要 2,000-5,000 tokens。所以用 accessibility tree 解析的工具(Playwright、PinchTab)在效率上天生佔優勢。
有人把所有工具都測過一輪,最後的推薦順序是:
PinchTab — 日常首選(「自行車」:省油、通勤用)
browser-use — 複雜流程(「汽車」:載重、長途用)
agent-browser — 備用方案(「機車」:靈活)
WebFetch — 只能看靜態頁面(「走路」:最後手段)
他給了一個很有畫面的總結:「Context 就是電池。」選工具的第一優先是看它多省電。
Reddit r/claude 社群
關於 DevTools MCP vs Playwright MCP 的討論中,多數人認為 Playwright 的 accessibility tree 方式比 DevTools 的原始 DOM 省了 70-80% 的 token。但也有人指出 Playwright 每次操作都回傳完整的 tree,累積下來其實不少。
怎麼選?看你的場景
你是前端工程師,想用 AI 幫你除錯?
→ Chrome DevTools MCP。它有完整的 Network、Console、Performance 工具。如果不需要全部功能,用 --slim 模式省 token。
你每天都需要讓 Claude Code 讀網頁內容?
→ PinchTab。每頁 800 tokens vs 10,000+ tokens,長期下來差很多。Context window 就是電池,能省則省。
你想要省 token 的自動化操作?
→ agent-browser。10 步驟工作流只要 ~7,000 tokens,比 Playwright MCP 省 16 倍。不需要持久登入狀態的場景,它是效率王。
你想從 Twitter、GitHub、YouTube 等平台抓資料?
→ bb-browser。36 個平台開箱即用,用你的登入 session,不用處理 API key 和反爬。你平常手動開 Chrome 去看的那些網站,它都能幫你自動化。
你想自動化填表單、投履歷這種多步驟流程?
→ browser-use。它是唯一能讓 AI 自己判斷下一步的方案。token 消耗高,但這種場景沒有替代品。
你只是偶爾想讓 Claude Code 看一下網頁?
→ Claude in Chrome。零設定,裝個擴充套件就好。但要注意它是 Beta,偶爾會斷線。
你需要跨瀏覽器測試?
→ Playwright MCP。Chrome、Firefox、Safari 都支援。記得用 --extension 模式連接現有瀏覽器,不然每次都開新實例。
一個現實的建議
截至 2026 年 3 月,瀏覽器操作對 AI 來說還是一個「未完全解決的問題」。沒有一個工具是完美的。
但好消息是,你不需要只用一個。這些工具之間不衝突,你完全可以:
日常用 PinchTab 省 token
遇到複雜流程用 browser-use
除錯時切換到 DevTools MCP
靜態文檔頁面用內建的 WebFetch
就像工具箱裡的不同工具,螺絲起子和扳手各有用途,不需要選一個打天下。
重點不是找到「最好的工具」,而是搞清楚每個工具的定位,在對的場景用對的工具。
相關資源
官方工具:
社群工具:
實測文章與社群討論: