Playwright MCP 可以把 Playwright 的瀏覽器自動化能力，接到 Model Context Protocol（MCP）裡。換句話說，AI Agent 不只是在聊天視窗裡回答你，它可以真的打開瀏覽器、讀頁面狀態、點按鈕、填表單，再把結果帶回來。
如果你平常會做 AI Agent、網站測試、後台流程檢查，或想讓 Claude、Cursor、VS Code 這類工具幫忙操作網頁，Playwright MCP 是值得先摸一次的入口。
我覺得重點不在「讓 AI 看截圖猜畫面」，而是把頁面狀態變成比較結構化的資訊，讓模型有機會更穩地理解畫面、執行操作。
先講清楚：Playwright MCP 是什麼？
Playwright 本來就是成熟的瀏覽器自動化工具，可以控制 Chromium、Firefox、WebKit。它常被拿來做 E2E 測試、資料擷取，或把重複的網頁流程自動化。
MCP 則負責讓 AI 模型用標準方式連接外部工具。兩者接起來後，Playwright MCP 就像一個橋樑：模型負責判斷下一步，Playwright 負責真的去操作瀏覽器。
| 角色 | 負責的事 | 你可以怎麼理解 |
|---|---|---|
| LLM / Agent | 理解任務、規劃下一步 | 像負責判斷的操作者 |
| MCP Client | 連接模型與工具 | 像工具總管 |
| Playwright MCP Server | 提供瀏覽器操作能力 | 像瀏覽器遙控器 |
| Browser | 實際打開頁面並執行操作 | 真正被控制的瀏覽器 |
它真正解決的是哪一段痛點？
傳統瀏覽器自動化通常要寫不少程式碼：找 CSS selector、等元素載入、處理登入狀態、截圖、重試。這套方式很可靠，但如果只是臨時檢查一個後台流程，成本會稍微高一點。
Playwright MCP 有趣的地方，是把這些能力變成 Agent 可以呼叫的工具。你可以先用接近日常語言的方式描述目標，再讓 Agent 依照頁面回傳的狀態一步步調整操作。
| 傳統 Playwright | Playwright MCP |
|---|---|
| 工程師撰寫腳本 | AI Agent 透過工具操作 |
| 依賴 selector、程式碼與測試框架 | 依賴頁面快照、工具呼叫與推理 |
| 適合穩定、可重複的大量流程 | 適合探索式、互動式、自我修正的流程 |
| 維護重點在程式碼 | 維護重點在任務描述、工具設定與驗證 |
它大致怎麼工作？
官方 Playwright MCP 比較特別的是，它主要依賴 accessibility tree，也就是頁面的結構化可存取性資訊，而不是只丟一張截圖給模型看。這會讓模型讀到更明確的元素名稱與狀態，而不是一直在猜畫面上哪裡像按鈕。
使用者目標
↓
LLM / Agent 規劃操作
↓
MCP Client 呼叫 Playwright MCP 工具
↓
Playwright 控制瀏覽器
↓
回傳頁面快照、結果或錯誤
↓
Agent 判斷下一步這種模式適合那種需要邊看邊判斷的任務。像是打開某個後台、找到指定資料、確認目前狀態，必要時再往下一頁或下一步走。
安裝與基本設定
Playwright MCP 通常透過 Node.js 和 npx 啟動。官方需求是 Node.js 18 以上，MCP client 則可以是 VS Code、Cursor、Claude Desktop、Windsurf 這類支援 MCP 的工具。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}如果你用的是 Claude Code，也可以直接用 CLI 加進去：
claude mcp add playwright npx @playwright/mcp@latest設定好之後，我會先用很小的任務確認它真的有接上：
- 打開一個公開網站
- 讀取頁面標題
- 點擊一個明確的連結
- 回報目前頁面上看到的主要按鈕
我會在哪些場景使用它？
我不會把 Playwright MCP 當成傳統自動化腳本的替代品。它比較適合放在「需要理解畫面、途中還要做判斷」的流程裡。
| 場景 | 可以怎麼用 | 注意事項 |
|---|---|---|
| 後台流程檢查 | 登入後台、確認資料是否出現、檢查狀態 | 登入權限與敏感資料要控管 |
| 探索式測試 | 讓 Agent 嘗試操作新功能並回報卡點 | 需要明確驗證標準 |
| 資料擷取 | 從互動式頁面讀取表格或狀態 | 大量資料仍應優先找 API |
| 工作流自動化 | 幫忙填表、建立草稿、檢查設定 | 涉及外部送出前要人工確認 |
| UI 迴歸檢查 | 確認按鈕、表單、路由是否正常 | 穩定測試仍建議寫成正式測試碼 |
MCP 和 CLI 不要混在一起看
官方文件也有提醒：如果你用的是 coding agent，有些情境其實更適合 CLI 搭配 Skills，不一定要硬接 MCP。
原因很現實。MCP tool schema 和頁面的 accessibility snapshot 都會吃掉模型上下文；相較之下，CLI 指令通常短很多，對大型程式碼任務也比較省 token。
| 選擇 | 比較適合 | 原因 |
|---|---|---|
| Playwright MCP | 需要持續瀏覽器狀態、探索頁面、互動式操作 | Agent 可以一邊觀察頁面一邊決定下一步 |
| Playwright CLI + Skills | 大量程式碼修改、固定測試流程、高吞吐 coding agent | 指令更精簡，較不佔模型上下文 |
幾個實際使用建議
1. 先從小任務開始
不要一開始就丟一個很大的任務給 Agent。比較穩的做法，是先拆成幾個能驗證的小步驟：開頁面、確認登入、找到目標元素、執行操作、檢查結果。
2. 任務描述要明確
像「幫我檢查後台」就太模糊了。改成「打開訂單列表，確認最新一筆訂單狀態是不是已付款，並回報看到的欄位」，Agent 比較知道該看什麼、回什麼。
3. 外部送出前要停下來
只要流程牽涉送出表單、建立資料、刪除資料、發佈文章或付款，我會要求 Agent 在最後一步前停住，先說明它準備做什麼。
4. 大量批次任務優先找 API
瀏覽器自動化很方便，但不是每件事都該從瀏覽器做。如果網站有 API，大量而穩定的任務通常還是走 API 比較好；Playwright MCP 適合補上那些真的需要看頁面、理解狀態的部分。
常見卡關點
| 問題 | 可能原因 | 建議處理 |
|---|---|---|
| Agent 找不到按鈕 | 元素沒有清楚的可存取名稱，或頁面還沒載入 | 先要求讀取頁面快照，再確認元素名稱 |
| 操作偶爾失敗 | 網路延遲、動畫、非同步資料載入 | 把流程拆小，加入確認步驟與重試策略 |
| 登入狀態不穩 | session 過期或瀏覽器 profile 沒保留 | 確認使用的瀏覽器環境與登入保存方式 |
| 上下文很快爆掉 | 頁面快照太大或任務太長 | 縮小任務範圍，必要時改用 CLI 或測試腳本 |
| 網站阻擋自動化 | 反機器人機制或權限限制 | 不要硬繞限制，改用官方 API 或人工流程 |
一個比較貼近日常的工作流範例
假設我要請 Agent 檢查某個管理後台的新功能，我會把指令寫得像這樣：
請打開本機開發環境的管理後台。
確認側邊欄是否有「專案」入口。
進入專案列表後，檢查是否能看到至少一筆資料。
不要建立、刪除或送出任何資料。
最後請整理：目前頁面狀態、看到的主要按鈕、任何錯誤訊息。這類指令的好處是目標明確、限制清楚，而且最後有可驗證的輸出。比起只說「幫我測一下」，穩定很多。
收尾：它適合放在哪裡
我會把 Playwright MCP 看成一個介於「人工操作」和「完整自動化腳本」之間的工具。它不是要取代所有 Playwright 測試，而是讓 Agent 多了一種可以直接碰瀏覽器的能力。
當任務需要看頁面、理解狀態、做多輪判斷時，它很有用；但如果流程大量、固定、可程式化，傳統 Playwright 測試、CLI 或 API 還是比較可靠。
比較務實的用法是：把 Playwright MCP 當成探索式、互動式自動化工具。它很好用，但不是所有瀏覽器任務的萬用解法。
