~/blog/webmcp-corporate-website-agent-ready.md
AI 自動化與智慧應用 ·

客戶帶著 AI 來詢價:企業官網接上 WebMCP 會怎樣、現在該不該做

Eric,浪花科技創辦人 / AI 架構師
Eric
浪花科技創辦人 · AI 架構師
客戶帶著 AI 來詢價:企業官網接上 WebMCP 會怎樣、現在該不該做
目錄 table-of-contents.md
font-size:

假設有一天,一個潛在客戶要找承包商做辦公室的空調工程。他沒有自己開十幾個分頁比較,而是叫他慣用的 AI 助理去查:預算大概多少、多久能到場勘、有沒有做過同類型的案子。這個助理會依序打開幾家公司的官網,然後在你的網站上卡住,因為它看不懂哪個按鈕是「索取報價」,也不知道那張表單的必填欄位要填什麼。它試了兩次,放棄,轉去下一家。

這個情境現在還不常見,但技術上已經開始成形。最近看到一部影片示範的 WebMCP,講的正是怎麼讓網站被 AI 助理讀懂、而且能直接操作。看完之後我們把它套到最熟悉的場景上推演:如果是一個企業官網接上這套東西,實際會變成什麼樣子?哪些地方會變好、哪些麻煩會跟著來、現在動手划不划算。對大部分企業官網來說,現在還不是動工的時機,但有一件相關的功課值得馬上做。

先看這部影片

影片出自創投與連續創業者 Greg Isenberg 的 The Startup Ideas Podcast,這一集找來開發者 Vinny 實際示範,標題是《WebMCP: Let AI Agents pay you money》,全長約 29 分鐘。他用一個賣義式咖啡機的店做例子:AI 助理把兩台機器並排比較、確認檯面 32 公分放不放得下、挑好相容配件、加進購物車、套上折扣碼,全程沒有人自己點過按鈕。以下是我們看完後的重述與評論,想看原始示範請直接看影片:

影片來源:The Startup Ideas Podcast(Greg Isenberg),2026 年 8 月 26 日發布。版權屬原作者所有,本文為觀後介紹與評論。

WebMCP 是什麼:網站自己長出給 AI 按的按鈕

如果看過我們寫的 MCP、API、CLI 差在哪,概念會很好接:MCP 是讓 AI 呼叫外部工具的標準介面,通常跑在伺服器端,要另外架 MCP Server、處理金鑰跟認證。WebMCP 把同一件事搬進瀏覽器:網頁用 JavaScript 註冊一組工具,瀏覽器負責端給 AI 助理看。影片主持人的說法是,說穿了就是網站上多了一排專門給 AI 按的按鈕。

要理解它解決什麼,得先知道現在的 AI 助理怎麼用網站。它只有兩條路:截圖看畫面,或把整份 HTML 抓下來猜哪裡能點。兩種都慢,版面一改就壞,我們在讓 Agent 操作瀏覽器那篇談過這種脆弱。WebMCP 換掉的就是這個猜的過程:網站直接說明「查服務項目長這樣、索取報價要這幾個欄位、預約要挑時段」,參數與回傳都寫明白,照著呼叫就好。

WebMCP 運作示意:企業官網註冊索取報價、預約諮詢等工具給瀏覽器,訪客自備的 AI 助理讀取工具清單後直接呼叫,不需截圖或解析 HTML

換成企業官網,實際會是什麼情況

影片的示範是電商,但企業官網的結構其實更單純,要開的工具數量也少得多。一個做工程、顧問、醫療或專業服務的官網,訪客真正想完成的動作攤開來就那幾件:搞清楚你做不做他要的那類案子、拿到報價或估算、約一個時間談、看看類似的案例、找到聯絡方式。這幾件事對應的工具,大概十個以內就能覆蓋八成需求。

接上之後,前面那個空調工程的情境會變成另一個樣子。客戶的 AI 助理打開你的官網,讀到工具清單,先呼叫「查詢服務範圍」確認你做商辦空調、也做這個縣市,接著呼叫「取得初步估算」把坪數與需求丟進去拿回一個級距,最後呼叫「預約現場勘查」,把客戶的聯絡方式與偏好時段送出。整段對話發生在客戶的 AI 助理裡,他本人可能只看了最後的摘要。你的收穫是一張資訊完整的詢問單,而且是在對手網站讓 AI 卡住的那個下午拿到的。

這裡有一個技術細節值得單獨講,因為它對有客戶專區的官網特別有用。WebMCP 的工具可以做成條件式的:影片裡示範者登入後看到完整工具清單,登出後只剩三個。原因是 AI 助理跟網站共用同一個瀏覽器 session,誰能用哪些工具,你原本的登入機制就決定了,不必另外發 API 金鑰、不必處理 token 過期。換到企業官網上,這代表未登入的訪客只能查公開資訊與送詢問,登入的既有客戶則可以讓 AI 幫他查合約狀態、下載對帳單、開報修單。我們在替 AI 代理人設計後端認證時最花時間的那一段,在這個模型下省掉了。

影片還提了一條演進線,我們認同:SEO 問的是 Google 看不看得懂這一頁,AEO 問的是 AI 會不會引用你的答案,WebMCP 問的則是 AI 有沒有真的把事情辦完。對企業官網來說,這條線的終點就是詢問單。被 AI 引用只是被看見,而我們追蹤 AI 導流的經驗是,看見到聯繫之間掉的人非常多,中間那段路現在還沒鋪好。

跟著來的三個麻煩

推演到這裡都很美好,但真的上線會遇到幾件事,而且都不是技術問題。

詢問單的品質會變。表單一旦變得好填,灌進來的東西也會變多。企業官網的聯絡表單本來就是機器人重災區,我們自己站上是靠 reCAPTCHA v3 在擋,但那是為了擋機器人設計的,而 AI 助理送出的詢問單是真人授意的,不該被當成攻擊擋掉。這兩者要怎麼分,現在沒有現成答案,務實的做法是工具端多要一點結構化資訊(預算級距、時程、聯絡人身分),用資訊完整度去分辨,而不是用「是不是機器」去分辨。

工具回什麼,你要負責。網頁上寫錯一行字,人看到會自己判斷;但工具回傳的價格級距或服務範圍,AI 助理會直接當成事實轉述給客戶。一個「我們服務範圍含全台」的工具回應,配上實際上不跑外島的現況,製造的是後續的爭議。這件事跟結構化資料的紀律一樣:機器讀的欄位要比給人看的文案更保守、更精確。

沒人維護的工具比沒有更糟。官網改版、服務項目調整、價目更新,工具清單要跟著改。企業官網最常見的狀態是上線之後三年沒動過,如果工具清單也停在三年前,AI 助理就會拿舊資訊去回答客戶。誰來維護、多久檢查一次,這件事要在做之前就講定,不然只是多埋一顆地雷。

影片沒講到的:這半年規格已經動過

這段是我們自己查證後補的。影片提到 WebMCP 是「今年二月 Google 與 Microsoft 聯手推出的 Chrome 實驗功能」,那對應的是二月的參考實作,而規格從那之後改過不只一次。以下查證於 2026 年 8 月 29 日:

  • API 位置搬家了。原本掛在 navigator.modelContext,7 月 21 日的規格草案把它移到 document.modelContext,理由是工具屬於特定頁面而不是整個瀏覽器。Chrome 150 已把舊位置標為棄用,照二月的範例抄會踩雷。
  • 目前是 Chrome 的 origin trial,不是穩定功能。試用涵蓋 Chrome 149 到 156,Edge 有實驗性支援但要開旗標,Firefox 與 Safari 只在討論桌上,沒有承諾。
  • 規格還沒進 W3C 標準軌。它現在是 Web Machine Learning 社群群組的草案報告,由 Google 與 Microsoft 共同編輯。四家瀏覽器都在談是好訊號,但離定案還有距離。
  • 供給跑在需求前面。Shopify 已經在所有 Liquid 店面內建 WebMCP 工具,不用安裝;但截至目前,主流的 AI 助理還沒有真的去呼叫這些工具。工具鋪好了,客人還沒到。

最後這點決定了現階段的投報率。方向是對的,只是中間那段空窗期要自己撐過去,而企業官網的流量規模通常撐不出什麼實驗數據。

那企業官網現在該不該做

我們最近正好在做一個用上 WebMCP 的專案,實際動手後的體感是:寫工具本身不難,難的是想清楚要開哪幾個、開了之後誰會來用。所以判斷標準不在技術可不可行,在划不划算。

值得現在就評估的是這幾種官網:服務項目複雜、客戶要交叉比對條件才問得下去的(工程承包、設備代理、專業顧問);有客戶專區、登入後有一堆重複查詢動作的,可以先只做給既有客戶用,反正使用者是熟客,風險最低;還有受監管的產業,先開唯讀的查詢工具,不碰任何會改狀態的動作。

其他大部分的企業官網,現在該做的還是上一階段的功課:服務項目寫清楚、案例寫具體、結構化資料補齊、llms.txt 放好,讓 AI 讀得懂你在做什麼、服務範圍到哪。這件事的投報率現在就看得到,而且做完之後將來要加工具層是水到渠成。反過來,基礎沒鋪就先接 WebMCP,等於把工具開給一個看不懂你公司在幹嘛的 AI。這個順序我們在 台灣企業 AI Agent 導入指南裡反覆講過,新名詞冒出來的時候特別容易被跳過。

還有一條界線要先畫:一旦開工具給外部 AI 呼叫,等於多開了一個入口。唯讀查詢放心開,會改狀態的要有確認機制,牽涉付款、合約與帳號的先不要。這跟我們在該不該開權限給 Agent 講的判準是同一套,差別只在這次站在網站方,而不是使用者方。

如果你正在規劃官網改版,想把「讓 AI 讀得懂、將來能操作」一起考慮進去,或者想評估自家官網屬不屬於上面那幾種值得先做的類型,這正是浪花科技在處理的事。我們同時做AI 自動化開發與企業官網建置,兩邊都碰得到,比較容易幫你判斷哪些現在做、哪些等規格定案再說,也不會為了賣新名詞叫你做用不到的東西。跟我們聊聊你的情況,把官網網址帶著就行。

資料來源

規格狀態與瀏覽器支援查證於 2026 年 8 月 29 日。WebMCP 仍在 origin trial 階段,規格與 API 可能持續變動,實作前請以官方草案為準。

延伸閱讀

// 推薦服務
首月免費 · 月費 NT$249 起
想用 n8n、Dify、WordPress,卻不想自己養伺服器?

RoamerHost 幫你把開源 AI 與自動化工具一鍵代管:獨立 Docker、自動 SSL、24/7 監控,60 秒上線。省下租機器、裝環境、顧維運的力氣,訂閱就能開始用。

立即免費註冊
// FAQ

常見問題

企業官網現在就該做 WebMCP 嗎?
多數不用。WebMCP 目前是 Chrome 的 origin trial(涵蓋 Chrome 149 到 156),規格還在 W3C 社群群組草案階段,而且主流 AI 助理還沒有真的去呼叫這些工具。值得現在評估的是服務項目複雜、客戶要交叉比對條件的官網,以及有客戶專區、登入後有大量重複查詢的網站。其他情況先把服務說明、案例、結構化資料與 llms.txt 補齊,投報率更高。
WebMCP 跟一般的 MCP Server 差在哪?
MCP Server 跑在伺服器端,要另外架設、發放 API 金鑰、處理 token 認證與過期。WebMCP 跑在瀏覽器裡,網頁用 JavaScript 註冊工具,權限直接沿用訪客當下的登入 session,所以未登入只看得到公開工具、登入後才看得到完整清單。對已經有會員系統的網站來說,省掉的正是認證這一段工。
開了工具給 AI 呼叫,詢問單會不會被灌爆?
這是實務上第一個會遇到的問題。傳統的 reCAPTCHA 是為了擋機器人而設計,但 AI 助理送出的詢問單是真人授意的,不該被當成攻擊擋掉。務實的做法是讓工具端多要一點結構化資訊,例如預算級距、時程、聯絡人身分,用資訊完整度來分辨詢問單品質,而不是用是不是機器來分辨。
我的官網是 WordPress,可以做嗎?
技術上可以。WebMCP 是在前端用 JavaScript 註冊工具,不限定後端是什麼,WordPress 站一樣能加。但要注意兩件事:工具回傳的資料要接得到真實的服務項目與價格來源,不能寫死;以及官網改版或服務調整時,工具清單必須跟著維護,否則 AI 會拿舊資訊回答客戶。
#WebMCP #AI Agent #企業官網 #MCP #網站架構 #AEO
~/roamer-tech/newsletter // FREE
// newsletter

訂閱免費電子報

把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧,整理成電子報寄給你。只寄精選內容、不灌垃圾信,一鍵就能退訂。

$
// final.exec()

準備好讓你的網站開始為你工作了嗎?