Day 06｜Playwright、REST API、MCP 與 WebMCP，各自負責哪一段？

本文同步自 2026 iThome 鐵人賽原文 。完整系列可見 iThome 系列頁 。

安安～我是ChiYu～

昨天 Playwright 因為按鈕改名而停在 click 以前。看到這個結果，很容易順手得出一個省事的 結論：「Browser Automation 太脆弱，換 WebMCP 就好了。」

有一說一，這個結論下得太快。Playwright 在驗收人類看得見的 UI，WebMCP 則讓目前分頁公開 任務能力；兩者本來就沒有在搶同一份工作。把其中一個失敗拿來替另一個頒獎，多少有點像 螺絲起子不好敲釘子，所以宣布榔頭贏得軟體架構大賽。

我把 Browser Automation、REST API、MCP 與 WebMCP 放進同一個活動搜尋任務，才看清楚 真正的差別：誰在呼叫、執行位置在哪裡，以及各自能讀到哪一種狀態。

同一個活動搜尋，四種技術站在不同位置

假設使用者說：「幫我找台北、免費，而且適合入門者的活動。」四種技術都可能出現在流程裡：

• Playwright 操作搜尋表單。
• REST API 接收條件並查詢活動。
• MCP Server 向外部 Agent Host 提供 Tool。
• WebMCP 讓目前網站分頁公開 search_events。

聽起來都在「搜尋活動」，執行位置卻完全不同：

圖 1：四種技術可以出現在同一條任務鏈，但呼叫者、狀態來源與驗證方式不同。

MCP 架構 描述的是 Host、Client 與 Server 之間如何協商能力。MCP Server 可以獨立存在，不需要使用者先打開某個網站分頁。

Chrome 的 WebMCP 與 MCP 比較 則把 WebMCP 放在瀏覽器前端。Tool 跟著目前頁面與 route 出現，可以使用該分頁的 session 與可見狀態；離開頁面後，這份能力也應該跟著解除。

所以 WebMCP 最有意思的地方，不是把所有 API 換一個名字，而是讓網站用目前分頁的情境描述： 「這個頁面現在願意提供哪些任務能力？」

WebMCP Tool 仍然要回到既有 REST API

AgentReady Events 的搜尋資料由這支 API 提供：

GET /api/events?location=taipei&price=free&level=beginner

Server 會驗證輸入、查詢活動，再回傳公開摘要。之後加入 WebMCP 時，呼叫鏈會長成：

Agent 選擇 search_events
          ↓
網站共用 search action
          ↓
REST API /api/events
          ↓
server validation 與活動資料

我沒有把查詢規則、授權與資料處理全部搬進 Tool description。這麼做看似少繞一層，實際上 會在前端複製另一套商業規則。人類表單走一套，Agent Tool 再走一套，兩邊早晚會各自長出 自己的脾氣。

這個專案的判斷很明確：REST API 仍是資料、授權與商業行為的事實來源；WebMCP 負責公開 任務語意，最後呼叫共用 action。Tool 宣告不會替 request 增加權限，也不能取代 server-side validation。

Playwright 繼續驗收人類 UI，不會被 WebMCP 取代

昨天的 timeout 正好證明 Playwright 還有工作。按鈕能不能被找到、表單能不能用鍵盤操作、 搜尋結果有沒有出現，以及取消 dialog 是否真的擋在最後確認前，這些都屬於人類 UI 契約。

WebMCP 加入後，反而多了一條交叉檢查線索：

• Playwright 失敗、Tool 成功：先查 UI、可及性或 Locator regression。
• Playwright 成功、Tool 失敗：先查 schema、註冊、執行或 browser capability。
• 兩邊都失敗：回頭查共用 client action、REST API 或 server state。

如果把 Playwright 拿掉，只保留 Agent trace，網站很可能變成「Agent 用得動，人類按不下去」。 反過來，只有 UI 測試，也回答不了模型是否從自然語言選對 Tool。兩條路驗收的是不同問題， 不該硬湊成淘汰賽。

用三個問題分配責任

之後每碰到一項新能力，我會先問：

1. 任務發生在目前分頁、外部 Agent Host，還是一般 client／server？
2. 它需要的是 DOM／route、MCP Server 資源，還是後端資料？
3. 應該用 UI 回歸測試、API test，還是自然語言 Agent trace 驗收？

答案通常不只落在一種技術。完整產品很可能同時保留四層：

MCP：跨系統、背景執行、長期存在的外部能力
WebMCP：目前分頁提供的情境化任務能力
REST API：後端資料、授權與商業規則
Playwright：人類 UI 與整合流程的回歸測試

昨天的按鈕改名屬於 UI 契約，所以由 Playwright 抓到。未來若 Tool schema 少了必要欄位， 問題會落在 WebMCP contract；如果 Agent 已送出正確 input，Server 卻接受過期報名，則要回到 REST API 與商業規則。先找對樓層，才不會每次報錯都把整棟房子翻修一遍。

E0～E5 標示證據進度，不是 WebMCP 規範

技術位置排好後，還有一件事不能混在一起：程式存在、Chrome 看見 Tool，以及 Agent 真的從 自然語言呼叫成功，是三種不同強度的證據。

我在系列裡使用 E0～E5 當內部標籤。這不是 WebMCP 規範，也不是鐵人賽的評分門檻；它只是 避免我把「程式寫好了」講成「Agent 已經會用了」。

目前網站有穩定的人類流程與 Playwright 測試，可以主張到 E2；四種技術的責任分工則是 接下來的設計契約。WebMCP Tool 尚未開始實作，所以沒有 E3，也不能提前寫成 E4。

系列開場曾看過一份完成版搜尋 trace，那是終點預覽，只屬於當時的固定版本與那一題。它 不會倒灌回來，讓今天尚未完成的 Tool 自動升級。

UI 基線已經站穩，第一支 Tool 還沒開始寫

走到今天，活動網站已經能由人類搜尋、收藏、準備報名與取消；固定版本可以重播，Playwright 也把 UI 劇本依賴的畫面線索攤開了。現在至少能分辨：按鈕改名造成 Locator timeout，和未來的 Tool 註冊或 Agent 選擇失敗，不是同一類問題。

這裡是第一個階段停靠點。WebMCP 此刻仍是待實作、待驗證的方向，下一步才會開始設計 Tool、 讓 Chrome 看見 catalog，再觀察 Agent 是否真的選對能力。

不過在寫第一支 Tool 以前，我還缺一份考卷。Agent 偶爾選對一次 search_events，不能順便替 參數、操作順序、人類確認與失敗復原背書。明天先列出十種行為、二十道固定題目；後面每完成 一小段，就拿對應題目來撞一次。成功要記，撞歪了也不能偷偷擦掉重考。