@playwright/mcp:微軟官方的瀏覽器自動化 MCP Server
@playwright/mcp 預設用 accessibility tree(browser_snapshot)取代截圖,大幅省下 token,加上 Playwright 原生 auto-wait,是 AI agent 做網頁自動化的合理起點。要注意它預設是 headed、預設帶持久 profile,而且進階工具群組要用 --caps 開。
讓 agent 開瀏覽器的幾條路線:Playwright、Puppeteer、Chrome DevTools 三個 MCP server 的取捨,視覺驅動的 Midscene,以及各家 CLI agent 內建瀏覽器能力的差別。重點在什麼情況下哪條路線會失敗。
@playwright/mcp 預設用 accessibility tree(browser_snapshot)取代截圖,大幅省下 token,加上 Playwright 原生 auto-wait,是 AI agent 做網頁自動化的合理起點。要注意它預設是 headed、預設帶持久 profile,而且進階工具群組要用 --caps 開。
server-puppeteer 是 MCP 官方 monorepo 裡的 Puppeteer 封裝,工具集精簡、以截圖 + evaluate 為核心。但它已被官方封存(移到 servers-archived、不再更新),新專案不該再選它——想要 Puppeteer 血統的 MCP,現在該看 Chrome 團隊的 chrome-devtools-mcp。
Chrome 團隊官方維護的 chrome-devtools-mcp,把 DevTools 的能力包成 MCP server:效能 trace 與洞察、Lighthouse 稽核、heap snapshot、擴充功能管理,都是 Playwright MCP 拿不到的。底層是 Puppeteer,所以互動有 auto-wait;代價是只支援 Chrome,而且預設會回傳使用統計給 Google。
這題現在其實是二選一:@playwright/mcp(跨瀏覽器、accessibility tree 省 token)對上 chrome-devtools-mcp(Chrome 官方、效能與記憶體診斷);@modelcontextprotocol/server-puppeteer 已被封存,不再是選項。分野也不再是抽象層級高低,而是「操作網頁」還是「診斷 Chrome」。
字節跳動開源(MIT)的 UI 自動化框架。UI 動作只靠截圖餵給視覺語言模型,不解析 DOM;一套 JS API 跨 Web / Android / iOS / 桌面。代價是每步較慢、token 較貴,而且高度綁在模型的 grounding 能力上。注意它已在 1.9.8 之後停掉 MCP,改走 Skills + CLI。
Browserbase 在 2026-05 推出的 browse.sh,是「瀏覽器技能目錄 + Browse CLI」兩件事。核心論點:瀏覽器 Agent 的瓶頸是健忘症不是推理,把學過的網站操作存成純文字 SKILL.md,Craigslist 任務官方自評從 ~$0.22 降到 ~$0.12。注意它跟 2018 年的 Browsh 文字瀏覽器毫無關係。
三家原本走三條路:Anthropic 做擴充、OpenAI 蓋自己的瀏覽器、Google 直接焊進 Chrome。到 2026-08 已經變成兩條——OpenAI 的 Atlas 在 8/9 停止運作,能力收回 ChatGPT 桌面版與 Codex。剩下的分歧是「寄生在 Chrome 上」對「Chrome 本身就是」。