如果團隊已經讓 AI coding agent 改 React 表單、修 onboarding bug 或補 E2E 測試，下一個痛點通常是驗證：它改完後有沒有真的打開頁面、點按鈕、看 console，並把失敗原因帶回來。GitHub Copilot browser tools 在 VS Code 正式可用後，這件事的起手式變簡單：VS Code 使用者可以先讓 agent 驗證本機畫面，再決定是否需要 Playwright MCP、Browserbase 或 Stagehand。
選型不要從工具名開始。先問：這次只是開發者檢查 localhost，還是要把瀏覽器操作變成可被使用者觸發的產品能力？前者重視快、低設定與可中止；後者需要 session 隔離、權限邊界、操作紀錄、重播與誰看最後輸出。需要工具背景時，可搭配 Playwright MCP 指南、Browserbase 指南 與 Stagehand 指南 讀。
先做這個決定：只是驗證，還是要變成服務能力？
| 讀者情境 | 先選 | 為什麼 |
|---|---|---|
| VS Code 裡剛改完 UI，想讓 agent 開本機頁面檢查 | Copilot browser tools | 已在 editor／Agents window 內，適合快速驗證與回報 console、截圖 |
| 想讓 Claude Code、Codex、Cursor 等不同助理都能操作瀏覽器 | Playwright MCP | 把 Playwright 能力包成 MCP 工具，較容易接到不同 agent |
| 已有固定 E2E 流程，要進 CI 或每天重跑 | Playwright 原生腳本 | 固定流程不必交給 LLM 判斷，明確 selector 與斷言更穩 |
| 需要雲端瀏覽器、保存 session、併發、代理或長任務 | Browserbase | 重點是瀏覽器執行環境與隔離，不只是點網頁 |
| 要把自然語言理解、頁面判斷與程式動作接在一起 | Stagehand | 適合半固定頁面與需要模型判斷的產品流程 |
| 會付款、刪資料、寄信、改權限或碰到正式客戶資料 | 先停在人工確認 | 讓 agent 準備草稿或差異摘要，最後一步由人確認並保留撤銷路徑 |
這張表的取捨是：Copilot browser tools 是 VS Code 使用者的低門檻入口，Playwright MCP 是跨助理的本機／MCP 入口，Browserbase 是雲端執行層，Stagehand 是把 LLM 判斷寫進程式的抽象層。四者可以互補，不必硬選一個取代全部。
新狀態：VS Code 裡已經有 Copilot browser tools
GitHub 2026 年 7 月 1 日在 changelog 宣布，VS Code 的 Copilot browser tools 已經 generally available，並且隨正式可用預設開啟。官方描述的能力包含開頁與導覽、點擊、輸入、hover、拖曳、處理 dialog、讀頁面內容、擷取 console error、截圖，以及在適合時執行 scripted flows。這讓「AI 改完前端後自己看畫面」不再一定要先裝 MCP server。
它同時帶來幾個邊界：你手動開的分頁預設是私人的，必須選擇 Share with Agent 才能讓 agent 讀取或互動，而且可以撤回；agent 自己開的分頁使用新的 session，不會拿到日常瀏覽器的 cookie 與 storage。camera、microphone、location、notification、clipboard reads 等敏感權限不會自動開給 agent。企業管理員也能用 workbench.browser.enableChatTools 關閉功能，並用 chat.agent.allowedNetworkDomains、chat.agent.deniedNetworkDomains 搭配 network filter 控制 agent 可連到哪些網域。
這些設定讓 Copilot browser tools 很適合「開發者監督下的驗證」，但它不是生產級瀏覽器平台。只要任務要被排程、併發執行、跨帳號保留狀態或交給非工程使用者觸發，就要再評估 Browserbase、Stagehand 或自建 Playwright 架構。
四條路線怎麼分
Copilot browser tools 和 Playwright MCP 最容易被混在一起。實務上可以這樣分：如果團隊主要待在 VS Code，且只要 agent 幫忙打開剛改完的頁面、點一次流程、讀錯誤訊息，Copilot 內建工具先試。如果團隊同時使用 Claude Code、Codex、Cursor 或其他支援 MCP 的助理，Playwright MCP 比較像共用接口。
Browserbase 解決的是「瀏覽器跑在哪裡」：正式流程不能永遠依賴某位工程師的筆電。當任務需要隔離 session、代理、併發、下載檔案、長時間等待或集中保存執行紀錄，雲端瀏覽器平台才有價值。只想偶爾檢查 localhost 的個人開發者，不需要一開始就買這一層。
Stagehand 解決的是「程式怎麼描述不完全固定的網頁任務」：傳統 Playwright 擅長明確 selector，Stagehand 則讓開發者把自然語言頁面判斷、抽取與動作包進程式。它適合客戶後台欄位名稱會變、頁面順序不固定，但仍需要工程師把任務邊界寫清楚的情境。
五個選型問題
一、使用者在哪裡？如果使用者是工程師本人，而且畫面在 localhost，優先用 Copilot browser tools 或 Playwright MCP；如果使用者是客戶、客服或營運同事，就要先設計帳號隔離、任務邊界與人工確認。
二、流程有多固定？「登入測試帳號、填三個欄位、確認列表出現」這類固定流程，仍應寫成 Playwright 測試。LLM 適合用來探索、生成草稿或處理欄位變動，不適合取代所有斷言。
三、是否需要雲端 session？只要出現排程、併發、代理、跨地區測試、長任務或多使用者狀態，本機瀏覽器就會成為瓶頸。這時再看 Browserbase，而不是一開始就把簡單驗證搬到雲端。
四、失敗時誰能查原因？至少要留下每一步 action、目標元素、輸入內容、screenshot 或 accessibility snapshot、console／network error、session ID、使用者與任務 ID。沒有這些紀錄，客服和工程只能猜是網站改版、模型判斷錯、權限設定錯，還是使用者要求本身不清楚。
五、最後一步是否會造成真實損失？付款、刪除、寄信、改權限、送出政府或金融表單、處理醫療與法務資料，都不該只靠 prompt 約束。讓 agent 準備資料、填草稿、列出差異；真正送出前，安排明確的人看最後輸出。
常見組合
個人開發者或小型工程團隊可以從 Copilot browser tools 開始：改完畫面後請 agent 開本機頁面、重現 bug、看 console，再回到程式碼修正。若團隊不只用 VS Code，下一步才把 Playwright MCP 當成共用瀏覽器入口。
已經有 Playwright 測試的團隊，通常不需要把固定測試全部改成 agent。較好的做法是保留 CI 測試，讓 agent 在開發階段探索錯誤、補測試草稿、找出 selector 或流程變更，再由工程師把穩定步驟寫回測試碼。
要把瀏覽器 agent 做成產品能力的團隊，常見組合是 Browserbase 提供雲端 session，Stagehand 或 Playwright 寫任務步驟，再用人審節點處理高風險操作。這條路要先選低風險流程試跑，例如公開資料查詢、表單草稿、內部後台狀態檢查，不要一開始就碰正式付款、刪除或大量客戶資料。
成本、隱私與風險底線
瀏覽器 agent 的成本不只模型 token。還要計算瀏覽器 session 時間、併發、代理、重試、截圖／影片保存、觀測資料、失敗人工處理，以及網站改版後的維護成本。若只是偶爾檢查 UI，內建 browser tools 或本機 MCP 已經足夠；雲端平台要等到任務量、隔離需求或產品責任出現後再買。
隱私面先問三件事：agent 會不會看到客戶個資、交易資料或內部文件；截圖、DOM、console log、prompt 與模型輸出會存在哪裡；測試帳號、正式帳號、API key 與 session cookie 是否分開。這三題回答不清楚，就不要把瀏覽器 agent 放進高風險正式流程。
FAQ
Copilot browser tools 可以取代 Playwright MCP 嗎？
對只用 VS Code 的開發者，它可以先取代一部分本機驗證需求；對需要跨助理、跨 IDE 或標準 MCP 入口的團隊，Playwright MCP 仍有價值。
Playwright MCP 可以取代 Playwright 測試嗎？
不建議。固定、可重複、要進 CI 的流程仍應寫成明確 Playwright 測試。Playwright MCP 更適合讓 AI assistant 探索頁面、重現問題、協助生成測試草稿與做本機互動式驗證。
Browserbase 和 Stagehand 是競爭關係嗎？
不是。Browserbase 偏雲端瀏覽器平台，Stagehand 偏 LLM 原生瀏覽器自動化 SDK。實務上可以用 Stagehand 寫任務步驟，再把瀏覽器 session 跑在 Browserbase 上。
AI 瀏覽器自動化適合拿來爬資料嗎？
先確認網站條款、robots 政策與資料使用限制。若只是讀公開頁面，普通 fetch 或官方 API 可能更穩、更便宜。瀏覽器自動化適合需要登入、互動、等待動態內容或多步驟操作的情境，但風險與成本也更高。
企業或新創最先該補什麼？
先補測試帳號、最小權限、操作紀錄、截圖／重播、人審節點與錯誤回復。這些保護做好後，再把低風險流程交給 agent 試跑。
參考來源
- GitHub Changelog：Browser tools for GitHub Copilot in VS Code are generally available
- Visual Studio Code Docs：Browser tools for agents
- Visual Studio Code Docs：Browser agent testing guide
- Microsoft GitHub：Playwright MCP
- Browserbase Documentation：Introduction
- Browserbase Documentation：Stagehand quickstart
- Browserbase GitHub：Stagehand