客戶在網站找到服務介紹後，仍要自己挑選條件、填表、確認資料，才能完成一件事。如果使用者的 AI 助理能協助查詢與準備申請，網站就多了一種服務方式。真正值得企業思考的是：哪些功能適合交給代理，哪些步驟必須由人確認？
近期訊號：網站開始提供可操作的能力
2026 年 8 月至 9 月的 WebMCP Challenge，邀請開發者建立代理可用的應用，或替既有網站加入支援。官方頁面展示協作寫作、行程整理與資料探索等方向。這些是探索性示範，不等於企業導入成效；但它提醒我們，網站與 AI 的連接正在從讀取資訊，延伸到協助完成操作。
WebMCP 是什麼？把功能說清楚給代理聽
依官方專案說明，WebMCP 可將網頁中的 JavaScript 功能或 HTML 表單，以自然語言描述及結構化欄位提供為工具。可以把它想成一份功能說明書：這個功能做什麼、需要什麼資料、會回傳什麼。代理因此多了一條明確的操作途徑，而不只依賴畫面位置猜按鈕。WebMCP 仍屬實驗性標準，瀏覽器與代理的支援情況要在選定環境實測。
先分清楚瀏覽器與後台的角色
WebMCP 著重使用者所在網頁與互動情境；後端 MCP 或一般 API 則可提供伺服器端整合。兩者可以互補，不能視為同一種部署方式。網站既有的登入、資料驗證、交易規則與權限仍要在後台執行。替表單加上工具入口，不會自動讓舊系統具備可靠的授權或資料品質。
一個服務預約的假設情境
以下是設計示例，並非米亞科技已交付案例。使用者請助理查詢某地區下週可預約時段；網站提供查詢工具，回傳時段編號、時區、可用狀態與查詢時間。助理選好選項並預填聯絡資料後，畫面顯示完整預約草稿，由使用者確認再送出。送出時後台重新檢查名額，成功才回傳預約編號；若已額滿，就提供重新選擇的路徑。
把查詢、草稿與提交拆開
以下是米亞科技的流程建議，而非標準自動保證的能力。查詢工具只讀取可見資料；草稿工具整理欄位並回報缺漏；提交工具才改變業務狀態。提交前應確認具體對象、時段、費用與聯絡方式，任何重要欄位更動都需重新確認。後台要用同一請求的識別碼防止重複送單，逾時後先查狀態，不能直接假設失敗再做一次。
第一個試點，先測能不能順利收尾
選一項經常發生、結果清楚、容易覆核的工作，例如查詢申請進度或準備預約草稿。驗收要包含缺少欄位、登入過期、名額變動、重複提交、使用者取消及不支援 WebMCP 的環境。保留原本可用的表單與人工入口，再比較完成率、修正次數、耗時與錯誤送單。工具回傳成功，不代表後台真的完成交易；必須以系統紀錄為準。
米亞科技的觀察
企業不必為了追趕新名詞重做整個網站。更有價值的起點，是把一項服務的輸入、狀態、例外與責任整理清楚，再接上適合的代理入口。米亞科技從網站、APP 與後台整合的角度看，能讓人與代理共用可靠流程，會比增加一個聊天視窗更接近實際營運價值。先小規模驗證，隨標準與支援度成熟逐步擴展。