摘要： 對 agent 而言，它面對的網站至今仍是替人打造的：想訂一張餐廳的位子，得先把表單的 HTML scrape 下來，從中認出姓名、電話、日期、人數是哪幾個欄位，一欄一欄填好，再靠截圖或 DOM 檢查確認送出結果。這條路每跑一次都要把對畫面的理解重拼一遍，欄位越多 token 成本越是往上堆，而一次改版往往就讓原本的抓取流程整組失效。
對 agent 而言，它面對的網站至今仍是替人打造的：想訂一張餐廳的位子，得先把表單的 HTML scrape 下來，從中認出姓名、電話、日期、人數是哪幾個欄位，一欄一欄填好，再靠截圖或 DOM 檢查確認送出結果。這條路每跑一次都要把對畫面的理解重拼一遍，欄位越多 token 成本越是往上堆，而一次改版往往就讓原本的抓取流程整組失效。
Firecrawl 的 WebMCP 示範把方向倒了過來：與其訓練 agent 更懂得操作人類介面，不如讓網站主動宣告 agent 能用的工具。以下依序拆解 WebMCP 的工具模型、Chrome 為 headless 劃下的那條紅線，以及 Firecrawl 如何以雲端真實瀏覽器補上缺口。
WebMCP：由網站宣告自己的 Agent 工具
WebMCP 是 Google 與 Microsoft 工程師提出的 Web Platform 提案。開發者在頁面上以 JavaScript 註冊 tools（未來預計也能改用 HTML），每個 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，瀏覽器本身也得完成 agent 的 onboarding。像 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；預設 code mode 為 Node Playwright，另支援 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 只剩慢路可走：把每個 input 都 scrape 下來、逐欄填值、再用截圖驗證——之後在 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 支援出現之前，對無法自帶本機瀏覽器的環境來說，雲端真實瀏覽器仍是目前最務實的橋樑。