對 agent 來說，今天的網站仍然是為人設計的：要訂一張餐廳位子，它得先 scrape 表單 HTML、辨認姓名電話日期人數等欄位、逐一填值，再用截圖或 DOM 檢查確認送出結果。這條路每次都要重建對畫面的理解，token 成本隨欄位數膨脹，改版往往也讓既有的抓取流程失效。
Firecrawl 的 WebMCP 示範提出的解法是把方向反過來：不是訓練 agent 更會操作人類介面，而是讓網站自己宣告 agent 可用的工具。這篇文章拆解 WebMCP 的工具模型、Chrome 畫下的 headless 紅線，以及 Firecrawl 用雲端真實瀏覽器補位的方法。
WebMCP：網站自己宣告 Agent 工具
WebMCP 是 Google 與 Microsoft 工程師提出的 Web Platform 提案：開發者以 JavaScript（未來預計也能用 HTML）在頁面上註冊 tools，每個 tool 帶 name、description、JSON Schema 格式的 inputSchema，以及實際執行的 execute 邏輯——結構與一般 MCP tool 完全相同。註冊 API 是 document.modelContext.registerTool，schema 中的 required 欄位明確標示，agent 不必再 scrape DOM 猜測表單結構。
以示範的餐廳訂位為例：原本的逐欄填表變成一次 book_table_le_petit_bistro tool call。execute 收到驗證過的參數後填入表單欄位、執行頁面既有的 validateForm()；驗證失敗回傳 isError: true 與錯誤訊息，成功則顯示確認 modal 並回傳訂位結果。探索端則有 document.modelContext.getTools() 列出頁面註冊的 tools（name、description、inputSchema），再以 document.modelContext.executeTool() 依名稱帶 JSON 參數呼叫。
Chrome 官方畫下的硬限制：headless 不能呼叫
規格看起來齊全，問題出在執行環境。Chrome 的 WebMCP 文件（經文章轉述）明言：目前不支援 agent 在 headless browser 呼叫這些 tools；agent 必須直接驅動 live browser，瀏覽器本身要 onboard agent。Claude Code 這類終端機 harness 沒有可操作的真實分頁，也就看不到網站註冊的能力。
時程讓這個尷尬更明顯：WebMCP 預計隨 Chrome 157 原生出貨（依文章轉述約 2026 年 11 月進入 stable），但撰文當下 stable 版只到 150，功能靠 flag 與 origin trials 分階段開放，今天的示範依賴 @mcp-b/webmcp-polyfill。換句話說，就算等原生支援落地，headless 限制一天不解除，Claude Code 一樣被隔在門外。
本機替代：agent-browser 與它的代價
Vercel Labs 的 agent-browser 是本機路線：它在機器上跑一個可用程式碼驅動的瀏覽器，agent-browser eval 直接在頁面內執行 JavaScript，等同從 console 呼叫 getTools() 與 executeTool()。
但它有部署面的代價：機器上必須有真實瀏覽器，首次執行還會下載 Chrome for Testing。在 CI pipeline、鎖定的工作機或雲端 runtime 裡，安裝與維護瀏覽器並不實際。在作者看來，它最適合單機開發者快速驗證 WebMCP 效果；要把同一套流程搬進 CI 或多機部署，環境管理會是第一個撞上的問題。
Firecrawl interact：把真實瀏覽器搬進雲端
Firecrawl 的角色是補上這一環：interact endpoint 在 Firecrawl 雲端跑真實瀏覽器，headless harness 不必自帶瀏覽器就能取得 live tab。控制方式有兩種：用 prompt 描述意圖，或直接執行 code——瀏覽器位於 Firecrawl 的 cloud sandbox，本機零安裝。
流程是 scrape 再 interact：先以 scrape（maxAge: 0 強制真實瀏覽器載入）取得 scrapeId——快取命中的 scrapeId 背後沒有 live session——再對同一個 scrapeId 呼叫 interact，結束用 stopInteraction 收掉。interact 的 code 跑在雲端瀏覽器裡，page 是已連線 session 的 Playwright Page；Node Playwright 是預設 code mode，另支援 Python Playwright 與 bash 的 agent-browser 命令。
// 1. discover — list tools registered by the page
const tools = await page.evaluate(() => document.modelContext.getTools());
// 2. execute — arguments travel base64-encoded, decoded in-page
const result = await page.evaluate(async (b64) => {
const tool = (await document.modelContext.getTools())
.find((t) => t.name === "book_table_le_petit_bistro");
return document.modelContext.executeTool(tool, atob(b64));
}, argsB64);呼叫 tool 時參數以 base64（argsB64）傳入、頁內以 atob 解碼，確保跨 Firecrawl transport 的 quoting 可靠。對 agent 而言，整件事就是一次經 headless-friendly API 代理的 tool call。這條路之所以成立，純粹因為雲端跑的是 real browser——WebMCP 在真實瀏覽器裡本來就能用，Firecrawl 端不需要任何特殊整合。
訂位示範：一次 tool call 的完整流程
示範站改自 Google 的 French Bistro demo：作者先移除站上既有 tools 作為 before 基線——agent 只能走慢路，scrape 每個 input、逐一填值、再用截圖驗證——然後在 stage-1 分支把 tool 加回來。接著用一個小型 runner 包住 discovery 與執行兩次呼叫，作為單一入口，把 Claude Code 指向它：說「幫我訂下週四兩位」，agent 發現 tool、找出缺少的欄位（時間、電話）——源文提醒，這些欄位 agent 可能向使用者詢問，也可能自行編造——補齊後一次呼叫完成訂位，全程本機無瀏覽器、無 scrape、無截圖。
還在變動的 spec 與工程紅線
這套做法的每一步都踩在移動的地板上。API 命名空間已從 navigator.modelContext 改為 document.modelContext；官方也預告未來改以 plain HTML tags 宣告 tools，屆時這類 discovery script 需要改寫。工程上另有兩條紅線值得寫進預設值：每組 scrape-interact 都要求 live session，maxAge: 0 不能省；參數走 base64 雖然可靠，但多了一層除錯時要記得的編碼。
Builder 建議
三個落地判斷。第一，網站方現在就能用 polyfill 註冊 tools：工具介面比畫面結構穩定，等原生支援落地時這份投資直接延續。第二，agent 方把 interact 包成單一 tool 來治理：固定允許的網站清單、驗證 input schema、限制可執行動作、保留操作記錄——headless 只是執行位置，治理不能跟著無頭。第三，盯著 Chrome 157 與 spec 變動：在官方的 headless 支援出現之前，雲端真實瀏覽器這條路，在無法自帶本機瀏覽器的環境裡，是目前最務實的橋樑。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。