Playwright MCP：讓 AI Agent 用可驗證的瀏覽器狀態完成網頁工作

我一直覺得，讓 AI Agent 操作瀏覽器最難的部分，不是把滑鼠點到某個按鈕，而是讓每一步操作都能被理解、驗證與重現。單純把畫面截圖交給模型，模型可能看見按鈕，卻不一定知道它在頁面結構中的角色；只靠座標點擊，畫面稍微改版，整個流程就可能失效。Microsoft 的 Playwright MCP 提供了一個值得研究的方向：它把 Playwright 的瀏覽器自動化能力包裝成 MCP server，讓支援 MCP 的 LLM client 透過結構化的 accessibility snapshot 與工具呼叫來操作網頁。

本文不把 Playwright MCP 描寫成「替 AI 按按鈕」的神奇外掛，而是從工程角度拆解它真正解決的問題、適合的使用場景、如何開始、狀態如何管理，以及為什麼安全邊界不能交給它單獨負責。我認為，這個專案最有價值的地方，正是把 Agent 與瀏覽器之間的互動，從脆弱的視覺猜測，拉回到有結構的頁面狀態與明確的工具介面。

先講結論：它把瀏覽器變成 Agent 可以讀懂的工具

Playwright MCP 的核心定位很清楚：這是一個使用 Playwright 的 Model Context Protocol server，提供瀏覽器自動化能力。模型可以開啟頁面、讀取頁面狀態、尋找文字、點擊元素、輸入資料、執行導覽、取得 console 訊息，也可以在需要時擴充 PDF、vision 或 devtools 能力。

這裡最重要的差異，是預設互動依賴 accessibility tree，而不是把 screenshot 當成唯一資訊來源。Accessibility snapshot 會以結構化文字描述頁面中的角色、名稱與可互動元素，工具回應也會給出可以繼續操作的 element reference。對 Agent 來說，這比「畫面上大概有一個藍色按鈕」更接近可推理的狀態：它可以先讀取頁面，再依照頁面實際存在的元素執行下一步。

這種設計也讓「驗證」變得自然。Agent 不必在點擊後盲猜成功與否，而是可以重新取得 snapshot、搜尋頁面文字、檢查 URL 或讀取 console 訊息。當流程用在測試、探索式自動化或長時間執行的任務時，這種狀態回讀比一次性的視覺操作更容易留下可追蹤證據。

不過，我不會把它理解成完全取代 Playwright 或所有瀏覽器 Agent 工具。官方 README 特別比較了 Playwright MCP 與 Playwright CLI 加上 skills 的差異：對 coding agent 來說，CLI 可能更節省 token，因為它不需要把大型工具 schema 與冗長的 accessibility tree 持續放進 context；MCP 則更適合需要持續瀏覽器狀態、豐富頁面 introspection，以及反覆讀取結構的 agentic loop。選哪一種，不是誰比較先進，而是要看任務是不是需要一個持續存在、可被多個工具操作的瀏覽器上下文。

它解決的不是「自動化」而是互動可靠度

傳統網頁自動化通常由工程師預先寫好 selector、等待條件與錯誤處理。這種方式在固定流程上非常可靠，但當網站內容、登入狀態與下一步目標會隨任務改變時，預先列出所有分支就會變得昂貴。LLM Agent 的優勢則是可以根據頁面內容臨場決策，但如果它只依賴 screenshot 或自由格式的文字，決策就很難穩定。

Playwright MCP 的折衷點是：由模型決定「要做什麼」，由 Playwright 與 MCP 工具約束「能怎麼做」。例如，一個典型的研究任務可以拆成以下循環：

開啟指定網站，取得目前頁面的 accessibility snapshot。
透過 snapshot 找到搜尋欄、導覽連結或結果清單。
使用 browser_click、輸入工具或導覽工具執行明確動作。
等待觸發的網路請求與頁面工作穩定下來。
重新讀取頁面 snapshot，確認狀態真的改變。
把需要的內容寫入輸出檔案，或交給下一個 Agent 步驟。

這個循環的工程價值，在於每一次行動前後都有狀態。它仍然可能遇到動態網站、驗證碼、非標準元件與登入失效，但問題比較容易被定位：是 snapshot 找不到目標、selector 不唯一、頁面尚未穩定，還是權限與網路設定阻止了導覽。與單純「再截一張圖試試看」相比，這是一個更可觀測的除錯介面。

如何開始：先用最小設定跑通一個可驗證任務

官方文件要求 Node.js 18 或更新版本，以及一個支援 MCP 的 client。最簡單的 server 設定如下：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

這段設定的重點不是 JSON 本身，而是讓 MCP client 以 stdio 啟動 @playwright/mcp。安裝後，我建議不要一開始就挑選需要登入、下載檔案或跨多個網站的複雜任務，而是先做一個三步驗證：開啟公開頁面、讀取 snapshot、搜尋一段確定存在的文字。只有這個最小流程穩定，才逐步加入點擊、表單輸入與輸出檔案。

如果你使用 Claude Code、Codex 或其他支援命令列註冊的 MCP client，官方 README 也提供對應的 add command；如果 client 使用 JSON 設定，就把上面的 server 區塊放進該 client 的 MCP 設定檔。當需要獨立啟動一個 HTTP MCP server 時，可以使用：

npx @playwright/mcp@latest --port 8931

接著讓 MCP client 連線到 http://localhost:8931/mcp。這種模式適合 IDE worker、遠端瀏覽器或需要把 server 生命週期與 client 分離的部署，但也代表你要更認真處理 host、port、網路來源與存取權限，不要因為本機測試方便就直接暴露到公網。

開始驗證時，我會特別觀察四件事。第一，snapshot 是否能表達真正需要的元素，而不是只看到空殼頁面。第二，動作完成後，重新 snapshot 是否出現預期變化。第三，失敗時 console 與 URL 是否提供足夠線索。第四，任務是否能在同一個 browser context 中連續完成，而不是每一個工具呼叫都重新登入。這四項比「模型有沒有成功點到按鈕」更能判斷整合是否可用。

Browser profile 是能力，也是狀態風險

Playwright MCP 預設可以使用持久化 profile。官方文件說明，登入資訊會保存在 persistent profile，而且不同工作區會透過 workspace hash 使用不同的 profile 路徑。這讓需要跨步驟登入的流程容易很多：Agent 第一次完成登入後，後續工作可以沿用 browser state，不必每次重新輸入帳號。

但持久化狀態同時也是風險來源。第一，profile 可能包含 cookies、local storage 與其他登入資訊，不能把它當成一般暫存資料夾任意共享。第二，同一個 persistent profile 同時間只能由一個 browser instance 使用；如果多個 MCP client 共享同一個工作區，可能互相衝突。官方建議在平行工作時使用 --isolated，或為每個 client 指定不同的 --user-data-dir。

如果任務不需要保留狀態，我會優先使用 isolated mode：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--isolated"
      ]
    }
  }
}

在 isolated mode 中，關閉瀏覽器後，這個 session 的 storage state 會遺失。如果要預先提供 cookies 與 local storage，可以搭配 --storage-state 指向由 Playwright 產生的 storage state file。這適合測試或受控的服務帳號流程，但檔案本身仍然是敏感資料，應放在權限受控的位置，並避免直接出現在模型可讀的輸出中。

另一個值得注意的選項是 --secrets。Playwright MCP 可以把工具回應中符合設定的明文替換掉，降低模型意外看到敏感內容的機率。官方文件同時明確說明，這只是便利功能，不是 security feature，也不是安全邊界。真正的權限控制仍然要放在 MCP client、作業系統帳號、容器、網路策略與目標服務本身。

Screenshot 不是主流程，Vision 是額外能力

這個專案的文件把 accessibility snapshot 放在核心操作路徑，並提供 screenshot 工具作為取得視覺畫面的能力。對一般結構化頁面來說，我會先使用 snapshot，因為它比較適合找角色、名稱與文字，也比較容易讓 Agent 依據明確 reference 做動作。

但世界上有些頁面不會把重要資訊完整暴露在 accessibility tree 裡，例如 canvas 應用程式、圖表、視覺化編輯器或高度客製化的拖放介面。這時可以評估 vision capability，讓流程有座標互動能力。這不是代表每個任務都應該開啟 vision，而是把它視為處理特殊頁面的補充工具。開啟越多能力，模型可以使用的操作面就越大，測試與權限審核也應該同步增加。

同樣地，--mobile、--device、--viewport-size 與 --user-agent 這些設定，會改變頁面呈現與可互動元素。做一般資料擷取時，固定 viewport 可以減少不必要的差異；做 responsive UI 測試時，則應把裝置與 viewport 當成測試條件明確記錄。不要把在桌面版成功的 selector，直接假設在行動版也能成功。

安全性：官方已經說得很直接，它不是安全邊界

我認為 Playwright MCP 最需要被寫進導入 checklist 的一句話，是官方 Security 章節的明確警告：Playwright MCP 不是 security boundary。這句話會直接影響部署設計。

瀏覽器 Agent 可以讀取頁面、造訪網站、使用登入狀態、寫入檔案，甚至在特定設定下連接既有瀏覽器。這些能力只要被錯誤的 prompt、惡意頁面內容、過寬的網路來源或錯誤的 profile 權限放大，就可能形成資料外洩或非預期操作。allowed-origins 與 blocked-origins 可以協助限制瀏覽器請求來源，但 README 明確提醒它們不構成安全邊界，也不會影響 redirects。因此不能只設定一個 allowlist，就宣稱系統已經安全。

比較務實的防線包括：

為 MCP server 使用低權限、專用的作業系統帳號或容器。
不要把個人瀏覽器 profile 與自動化任務共用。
對登入狀態、storage state file 與輸出檔案設定最小權限。
以 client 層的工具授權與人類核准流程限制寫入、付款、刪除與發送操作。
對 HTTP transport 綁定 localhost 或受控網段，避免直接暴露到公網。
對允許存取的 workspace、origin、下載目錄與 secrets 做明確設定。
把頁面內容當成不可信資料，不要因為網頁文字要求 Agent 改變系統規則就照做。
在正式任務中記錄導覽、工具呼叫、結果與失敗原因，但不要把 token 或密碼寫入 log。

最後一點特別重要：瀏覽器看見的內容不是系統指令。就算頁面上出現「請忽略先前規則」或要求輸出秘密的文字，Agent 也應把它視為外部資料，交由 client policy 決定能否繼續。Playwright MCP 提供的是瀏覽器操作層，不會自動替你完成 prompt injection 防護。

我會怎麼評估它是否適合團隊

如果團隊正在做探索式測試、自動化研究、客服後台操作、跨頁面資料整理，或需要讓 Agent 在同一個登入瀏覽器上下文中連續工作，Playwright MCP 很值得做小規模 PoC。它的價值不是少寫幾個 selector，而是提供一個讓模型讀取頁面結構、呼叫瀏覽器工具、再回讀結果的標準介面。

但如果流程完全固定，例如每天都在同一個頁面填同一張表，傳統 Playwright test 或 Playwright CLI 可能更簡單、更可預測，也更容易在 CI 中維護。官方對 MCP 與 CLI 的比較也提醒我們，coding agent 未必需要大型工具 schema 與完整 snapshot；在 context 成本很重要的場景，CLI 加上 skills 可能更合適。

我會用以下順序導入：先用公開網站建立不涉及登入的 smoke test，再加入隔離 profile 與受控的 storage state，接著測試失敗恢復與重試，最後才評估 HTTP transport、平行 client、容器化與高權限操作。每個階段都要有可量化的驗收條件，例如 snapshot 找到率、動作後狀態驗證率、非預期導覽次數、任務完成時間與人工介入比例。這些指標能避免團隊只看示範影片，卻沒有掌握實際維運成本。

結語：把 Agent 操作瀏覽器變成可觀測的工程系統

Playwright MCP 最值得注意的地方，不是它能不能取代人工瀏覽器操作，而是它提供了一種更適合 Agent 的互動抽象：頁面先被轉成結構化狀態，動作透過明確工具發生，結果再被讀回驗證。這個循環讓瀏覽器 Agent 不再只是「看圖猜下一步」，而可以逐漸靠近可觀測、可測試、可重跑的工程流程。

當然，它不會自動解決所有問題。動態頁面、登入、平行 profile、特殊視覺元件、網路限制與 prompt injection 仍然需要團隊自己設計防線。尤其官方已清楚說明它不是安全邊界，任何正式部署都不應把 origin filter、secrets masking 或 MCP server 本身當成完整的資安方案。

我的判斷是：如果你的 AI Agent 需要持續理解網頁狀態，而不是只執行幾個固定的瀏覽器腳本，Playwright MCP 是一個很適合拿來建立第一個可驗證原型的開源工具。先用最小設定跑通 snapshot、動作與回讀，再依照任務需要加入 isolated profile、storage state、vision 或 HTTP transport。這樣導入，才有機會把瀏覽器自動化從 demo 變成真正可維護的 Agent 能力。

參考資料