WebMCP 會取代 Playwright 嗎？把「猜按鈕」改成網站主動提供工具

我替沒有公開 API 的 NotebookLM 做 MCP server 時，控制頁面的程式就是 Playwright：找輸入框、送出問題、等串流停止，再從畫面撈回答。第一版很快就能跑，後面花最多時間的，卻是替改版、舊答案和抓錯節點補防線。

所以看到 WebMCP 的第一個反應很直接：如果網站可以自己告訴 Agent「我有哪些工具、參數是什麼、呼叫後會發生什麼」，那些選擇器陣列是不是終於可以丟了？

我的答案是：一部分可以，但 Playwright 不會因此消失。要說清楚原因，得先拆掉一個常見誤會。

先把責任分清楚：Playwright 沒有在猜

一條已經寫好的 Playwright 測試是確定的程式。它會按照你指定的 locator 找元素；Playwright 還會自動等待元素可見、穩定、可接收事件而且已啟用，條件不符就失敗。

await page.getByLabel('問題').fill('WebMCP 是什麼？');
await page.getByRole('button', { name: '送出' }).click();
await expect(page.getByRole('status')).toContainText('已送出');

這段程式沒有猜。真正需要推測的是寫下這段程式之前：哪個欄位才是問題、哪個按鈕代表送出、點完要觀察哪個狀態。如果是人先讀產品再寫測試，這是測試設計；如果是 AI Agent 臨場讀 DOM、挑一個看起來最像的元素，才是大家說的「猜按鈕」。

Playwright 官方也不是鼓勵大家綁死一串脆弱的 CSS class。它優先推薦 role、label、文字等使用者看得到的語意，必要時再用明確的 test id 合約。好的 Playwright 測試，本來就在把猜測壓到最低。

WebMCP 改的是：工具合約由誰來寫

傳統瀏覽器自動化把合約寫在網站外面。腳本知道要開哪一頁、按哪裡、等什麼；網站本身不知道這個 Agent 想完成一個「送出客服單」的任務，只看到一連串滑鼠和鍵盤事件。

WebMCP 把合約搬回網站。頁面可以用 JavaScript 註冊一個有名稱、說明、輸入 schema 和執行函式的工具。Agent 不必先還原整段操作流程，而是直接看見網站願意提供的能力：

document.modelContext.registerTool({
    name: 'submit_support_request',
    description: '送出一筆客服需求，回傳案件編號',
    inputSchema: {
        type: 'object',
        properties: {
            subject: { type: 'string', description: '問題主旨' },
            details: { type: 'string', description: '問題內容' },
        },
        required: ['subject', 'details'],
    },
    execute: ({ subject, details }) =>
        submitSupportRequest({ subject, details }),
});

差別不只是「少點幾下」。原本 Agent 得從畫面猜出意圖，再把意圖翻成操作；現在網站直接提供一個具名工具，參數也能先驗證。介面改版時，只要工具合約不變，Agent 不需要知道按鈕搬去了哪裡。

但這也說明了它的邊界：WebMCP 需要網站開發者主動加入，而且工具跟目前開啟的頁面與工作階段綁在一起。它不是替所有網站突然補上一套萬用 API，也不是遠端後端 MCP server 的另一個名字。

HTML 表單也能直接變成工具，不必另做隱藏流程

WebMCP 還有一個我覺得比 JavaScript 註冊更值得注意的方向：宣告式 API。既有表單加上 toolname、tooldescription 與欄位說明，就能讓 Agent 讀到工具；表單仍然留在頁面上給人操作。

<form
    toolname="search_articles"
    tooldescription="搜尋網站文章"
    toolautosubmit
>
    <input
        name="query"
        required
        toolparamdescription="要搜尋的主題或關鍵字"
    />
    <button type="submit">搜尋</button>
</form>

這比做一條只有 Agent 知道的隱藏捷徑健康。人和 Agent 看的是同一張表單、走的是同一個送出事件，網站比較不容易長出兩套互相漂移的產品邏輯。

WebMCP 與 Playwright，實際上站在不同位置

如果任務是「讓 Agent 在合作網站完成一筆結構化操作」，WebMCP 可以拿掉大量 DOM 探索與點擊步驟。如果任務是「確認使用者真的能在 Safari 按下結帳，錯誤訊息也看得到」，WebMCP 完全沒有取代 Playwright。

Playwright 還能攔截網路、模擬回應、保留 trace、比對畫面，並在 Chromium、Firefox、WebKit 跑同一條流程。這些是測試與瀏覽器控制能力，不會因為頁面多了一份工具 schema 就失去價值。

所以真正會被取代的是哪一段？

最可能被 WebMCP 取代的，是 Agent 的「臨場介面翻譯層」：掃描 DOM、推測控制項用途、決定點擊順序，再從版面變化判斷任務是否成功。合作網站若把能力宣告成工具，這一大段可以縮成一次結構化呼叫。

比較不會被取代的，是瀏覽器工作階段、登入狀態、真實 UI 驗證、跨瀏覽器相容性，以及沒有提供 WebMCP 的網站。換句話說，WebMCP 可能讓 Agent 少用一部分 Playwright 動作，不會讓 Playwright 這個工具失去用途。

這篇沒有做「完成任務快幾倍」的量化實驗。WebMCP 的工具選擇仍由模型決定，官方文件也把 eval 列為必要工作：Agent 有沒有選對工具、填對參數、接受正確結果，都要實測。把 click 換成 tool call，不代表機率性就跟著消失。

最合理的架構，是兩個一起用

如果是我自己的產品，我不會替 WebMCP 另外寫一套商業邏輯。我會先把真正的動作收斂成同一個 domain function，畫面按鈕和 WebMCP tool 都呼叫它：

const createTicket = (input: TicketInput) =>
    supportService.create(input);

form.addEventListener('submit', async (event) => {
    event.preventDefault();
    await createTicket(readTicketForm(form));
});

document.modelContext.registerTool({
    name: 'create_support_ticket',
    description: '建立客服案件',
    inputSchema: ticketSchema,
    execute: createTicket,
});

接著用 Playwright 驗兩件事：人走畫面流程能完成任務；頁面在正確狀態下有註冊工具，而且工具最後走到同一套權限、驗證與資料寫入。這樣 WebMCP 是產品能力的另一個入口，不是躲過 UI 測試的捷徑。

Agent 端則可以採用很務實的順序：先找網站提供的工具；沒有合適工具，才退回 role、label 與 test id 等語意 locator；再不行才使用更寬的 DOM 探索。這才是真正把猜測逐層往後推。

工具變清楚，安全問題沒有消失

網站主動提供工具，並不代表 Agent 自動取得更多權限。登入、授權、輸入驗證、CSRF 防護、速率限制與重要操作確認，仍要由網站執行。工具 description 只是告訴模型用途，不是安全邊界。

WebMCP 規格提供 readOnlyHint、untrustedContentHint 等註記，讓 Agent 知道工具是否唯讀、結果是否含不可信內容；但它們是提示，不是強制機制。官方安全文件也直接列出工具描述污染、輸出提示注入與過度暴露工具等風險。

比較穩妥的做法是：工具只做一件事、名稱不要重疊、只在相關頁面狀態註冊、預設同源，會付款、刪除或送出資料的操作則保留清楚的人類確認。工具愈多不一定愈好；它們會占用 Agent 的上下文，也會增加選錯工具的機會。

現在該不該做 WebMCP？

截至 2026 年 8 月，WebMCP 是 W3C Web Machine Learning Community Group 的 Draft Community Group Report，不是 W3C Standard，也不在 Standards Track。Chrome 從 149 版提供 origin trial；API、行為和支援範圍都還可能改。

因此，我會把它當成值得做小型 prototype 的新入口，不會當成已經可以刪掉既有自動化的通用標準。最適合先試的是自家網站裡高頻、步驟多、參數清楚的任務，例如建立工單、搜尋庫存或填寫預約；單純閱讀文章、點一個連結，未必值得多一層工具。

至於第三方網站、自動化回歸、跨瀏覽器驗證，或任何必須確認「人真的能完成」的流程，Playwright 仍然是比較對的工具。WebMCP 解決的是網站如何對 Agent 說明能力；Playwright 驗證的是瀏覽器裡實際發生了什麼。

我現在不會刪掉任何一條 Playwright 測試。如果哪天替產品加上第一個 WebMCP tool，我接著寫的，仍然會是一條 Playwright 測試。