> ## Content Index > Fetch the complete content index at: https://growthhackers.tw/llms.txt > Use this file to discover other available public pages before exploring further. # WebMCP 是什麼？跟 MCP 差在哪？台灣電商先別急著動工 - URL: https://growthhackers.tw/blog/webmcp-vs-mcp-browser-agent-tools/ - Published: 2026-09-06T01:00:00.000Z - Updated: 2026-09-06T01:00:00.000Z - Description: WebMCP 想讓網頁把能力直接交給 AI agent，不用再猜 DOM。但這份草案連 API 入口都剛從 navigator 搬到 document。先搞懂它跟 MCP 的三個差別，再回頭看你的站台到底是不是你的。 - Author: Lewis wang - Tags: WebMCP, MCP, AI agent, 電商經營, 網站架構 我最近在看一個 [WebMCP 的官方示範網站](https://webmcp-demo-sdras.netlify.app/?ref=growthhackers.tw)，一個線上預約的 demo，程式碼寫得很乾淨。我順手把它的程式碼，跟 [W3C 的規格原文](https://github.com/webmachinelearning/webmcp?ref=growthhackers.tw)擺在一起對照。 然後就對不上了。 demo 裡註冊工具的入口寫的是 `navigator.modelContext.registerTool()`，規格現在寫的卻是 `document.modelContext.registerTool()`。這不是誰手滑打錯字。規格自己把入口從 `navigator` 搬到了 `document`，而 Chrome 150 已經把舊的那個標記成 deprecated（即將淘汰），未來版本會直接移除。 一個 2025 年 8 月才首次發布的草案，幾個月內改掉了自己的名字。 所以你現在 Google 得到的 WebMCP 教學，不少還在教一個已經被改掉的寫法。 ## 先別急著問「要不要接」 我知道你看到這裡在想什麼：「所以我是不是又落後了？要不要叫工程師趕快接一下？」 如果你問我，這是錯的問題。 看一下這份規格現在的體檢報告：狀態標示是 experimental（實驗性），截至 2026 年 8 月底，倉庫裡躺著大約 108 個 open issues（未解決的討論），Chrome 從 149 版開始才開放 origin trial（來源試用），本機想測還得手動去開 `chrome://flags/#enable-webmcp-testing` 這個旗標。規格文件自己開宗明義寫著：這是 Draft Community Group Report，不是 W3C 標準，也還沒進標準軌道。推手是微軟和 Google，掛在 Web Machine Learning 社群組底下。 翻成白話：**WebMCP 還不是瀏覽器預設就能用的功能。** 現階段它適合拿去 origin trial 或測試站踩踩看，不適合當成正式環境的依賴。 做過百貨專櫃的都知道，櫃位一改陳列，熟客就找不到原本那排貨。這幾年看規格草案，我養成一個習慣：先看它改過幾次名字。改名字代表底層的想法還在動，而底層還在動的東西，你花錢接上去，改的成本是你自己吸收。 錯的問題會讓你把預算丟進一個還在改的規格。對的問題只有一個：**這件事裡面，哪一部分不會變？我現在只投那一塊。** ## WebMCP 是什麼？ 用一句話講：WebMCP 是一個瀏覽器端的標準草案，讓網頁主動把「我這頁能做哪些事」宣告成結構化的工具，AI agent 直接呼叫，不用再去猜你的畫面。 以前 agent 要幫你在一個網頁上訂位，它得截圖、讀 DOM（網頁的元素結構）、猜哪個輸入框是日期、猜哪顆按鈕才是真的送出。現在網頁直接給它一份契約：這個工具叫 `bookSlot`，需要日期、時間、姓名、email，格式長這樣，跑完會回你什麼。 每個工具有名稱、說明、JSON Schema 定義的參數、annotations（標註，例如 `readOnlyHint` 告訴 agent 這個動作只讀不寫），還有實際執行的函式。這個描述形狀刻意貼著 server 端的 MCP 工具長，但它不是把 MCP 直接搬進瀏覽器：執行位置、生命週期、協定層都不一樣。 寫法有兩種。一種是用 JavaScript 呼叫 `registerTool()`。另一種更簡單，直接在 HTML 的 `
` 上加幾個屬性，像 `toolname`、`tooldescription`、`toolautosubmit`，各欄位再補上 `toolparamdescription`，完全不用寫 JS。 瀏覽器或擴充功能會把註冊好的工具收集起來，連同頁面網址、標題、來源權限範圍一起交給使用者的 agent。使用者還是在流程裡，該授權該確認的一樣要按。 這就像從「讓客人自己在賣場貨架間亂找」，進化到「直接遞一張菜單過去」。貨架重新陳列，客人就迷路；菜單上的品項不變，店裡裝潢改幾次都不影響點餐。 ## WebMCP 跟 MCP 差在哪？三個差別 這是最多人搞混的地方，名字只差兩個字母。 **► 差別一：位置。** MCP 在 server 端，連的是你的資料庫、API、後台系統。WebMCP 在瀏覽器端，連的是使用者現在正開著的那一個頁面。 **► 差別二：生命週期。** MCP 是 persistent（持續存在）的，Google 官方的說法是讓資料和動作「anywhere, anytime」都能用。WebMCP 是 ephemeral（短暫的），綁在那個分頁上，使用者一關頁面就沒了。 **► 差別三：控制權。** MCP 你自己開一台 server 就有了，主導權在你手上。WebMCP 要瀏覽器支援、使用者授權、你的站台有註冊工具，三方到齊才成立。少一邊都不算數。對租平台開店的台灣品牌來說，第三邊還不在你手上。 ![MCP 是 server-side、隨時可用；WebMCP 是 browser-side、綁在分頁上，關掉就沒了](https://growthhackers.tw/content/images/2026/08/webmcp-inline-webmcp-vs-mcp-v1.png) MCP 是 server-side、隨時可用；WebMCP 是 browser-side、綁在分頁上，關掉就沒了 我自己是這樣記的：MCP 像打給總公司的訂貨專線，你人在不在店裡都能打，隨時有效。WebMCP 像你已經坐在這家店裡，桌上那顆服務鈴，只在你這一桌、這個當下有效，起身走人就沒了。 那它們會打架嗎？不會。[Chrome 官方文件](https://developer.chrome.com/docs/ai/webmcp/compare-mcp?ref=growthhackers.tw)講得很直接：partners, not opponents（是夥伴，不是對手）。官方建議的分工是核心商業邏輯、資料取得、背景任務走 MCP，WebMCP 只負責使用者當下那一頁的情境層。 這個邏輯我們之前聊過類似的：開了 MCP server 就等於做完了嗎？[Linear 為什麼還要自己做原生 agent](https://growthhackers.tw/blog/native-agent-vs-mcp-server/) 那篇講的就是同一件事，通道打開不等於體驗做好。 ## 台灣電商該怎麼辦？先看你的站台是不是你的 台灣讀者要先過一關：這個站台，你到底能不能改。 很多英文教學預設你改得動自己的 HTML，想加什麼屬性就加什麼屬性。台灣很多人不是這樣。 **► 第一，先分清你是哪一種處境。** 你是開店平台的房客（用 SaaS 開店系統）、marketplace 的攤商（蝦皮、momo、PChome），還是自己有站的站主？這三種的動作完全不一樣。 ![開店平台房客、marketplace 攤商、自架站站主，三種處境對站台的控制程度完全不同](https://growthhackers.tw/content/images/2026/08/webmcp-inline-taiwan-three-situations-v1.png) 開店平台房客、marketplace 攤商、自架站站主，三種處境對站台的控制程度完全不同 **► 第二，如果你是房客，這是平台 roadmap 題，不是工程題。** 就算平台開放你改佈景或塞腳本，核心表單和結帳流程通常還是碰不到，而那才是 agent 想呼叫的地方。你要做的是打電話問你的平台窗口：有沒有在追這份規格？會不會支援表單標註？roadmap 上排在哪？別急著找工程師報價，報了也動不了。 **► 第三，marketplace 的攤商更現實一點。** 你的商品頁本來就不是你的，agent 進來看到的是平台的頁面結構，不是你的。這題你連問的對象都沒有，先放著。 **► 第四，不管哪個標準最後贏，這件事現在做都不虧：把「哪些動作值得被 agent 呼叫」列成一張表。** 欄位就六個：動作名稱、需要哪些參數、成功回什麼、失敗回什麼、需要什麼權限、資料從哪來。先挑三個流程填填看，例如查訂單狀態、查可預約時段、查庫存。WebMCP 要用這張表，MCP 要用這張表，以後冒出來的第三個標準也要用這張表。填它花的是腦袋，不是工程時數。 **► 第五，ship 了不等於被找到。** 下面這個例子不是 WebMCP，是另一份叫 Agentic Resource Discovery（讓 agent 找到你的能力清單）的規格，但它講的道理一模一樣。工程師 Suganthan 在他的[實作紀錄](https://suganthan.com/blog/agentic-resource-discovery/?ref=growthhackers.tw)裡寫了一個很值得記下來的坑：他把能力清單檔案放上線，也通過了官方驗證，結果官方驗證工具第一次跑回來是 403。原因是那個工具用 Python 標準函式庫發請求，user-agent 是 `Python-urllib`，被 Cloudflare 的 managed bot rules 在邊緣直接擋掉。同一個檔案，瀏覽器 200、ClaudeBot 和 GPTBot 200、curl 200、空 user-agent 也 200，唯獨規格自己的官方驗證工具吃 403。 ![同一個檔案，有些用戶端拿到 200，規格自己的官方驗證工具卻被防火牆擋成 403](https://growthhackers.tw/content/images/2026/08/webmcp-inline-shipped-not-found-v1.png) 同一個檔案，有些用戶端拿到 200，規格自己的官方驗證工具卻被防火牆擋成 403 台灣站台為了擋刷單、擋惡意爬蟲，WAF 和防爬蟲規則通常開得比國外還兇。你猜這件事會不會發生在你身上？ 再補一個。同一份規格的 11 家發起公司，在發布三天後，主網域上幾乎都沒有真的部署那個檔案，多數回 404 或 403。新聞稿只代表共識開始形成，不代表平台已經部署。你的採用判斷要看的是平台有沒有給你可測的東西，不是誰簽了名。 **► 第六，預約型生意比純電商更早吃到紅利。** 你注意到沒有，那個 demo 做的是 booking，不是購物車。餐廳訂位、醫美諮詢、課程報名，這類動作天生就有清楚的契約：時間、人數、姓名、聯絡方式，跑完就結束。台灣電商的「加入購物車到結帳」綁死金流、物流、發票、超商取貨，那遠遠不只是一個 form。誰先被 agent 操作，順序很清楚。 ## 標準會一直疊上來 如果你想先把 server 端那條路走順，站上有兩篇可以接著看：[MCP stateless vs stateful 差在哪](https://growthhackers.tw/blog/mcp-stateless-vs-stateful/)講的是部署決策，[MCP stateless 新規格解讀](https://growthhackers.tw/blog/mcp-stateless-core-spec/)講的則是規格變動會怎麼讓你的舊連線變成技術債，跟今天這篇 deprecated 的故事是同一個劇本。想直接動手跑一次的，[GA4 MCP Server 安裝教學](https://growthhackers.tw/blog/ga4-mcp-server-install-tutorial-2026/)是門檻最低的入口。 這年頭就是規格、規格、規格。一層疊一層，而且每一層攤開來看，其實都只是一個小檔案、幾個屬性。 真正稀缺的從來不是接規格的工程時數。 是想清楚你的站台對 agent 來說，到底能做什麼。 **協作聲明與免責** 這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 `[來源名稱](URL)` 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。 內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。