在今年二月「WebMCP」進入早期預覽計畫後，Google Chrome 開發團隊針對 WebMCP 與「Model Context Protocol（MCP）」的用途發布了官方指南。開發者普遍提出疑問：WebMCP 是否會取代 MCP？實際上這是一個誤解。兩項技術並非對立關係，而是針對不同需求設計，可以協同運作。 最好的類比是公司客服中心與門市專家的差異。MCP 是通用型協議，可在任何平台任何時間運作，負責資料檢索與核心任務處理；WebMCP 則侷限於網站環境，專門幫助 AI Agent 理解為人類設計的使用者介面。 兩項技術共享同一哲學基礎：為應用程式提供標準化、可靠的方式來向 AI Agent 公開工具。在實務上包括三大功能。第一是結構化工具發現，提供機器可讀的方式讓 Agent 查詢「你能做什麼」並取得可用工具清單、參數與用途。第二是可預測的執行結果，以明確的函式呼叫取代猜測，Agent 呼叫定義好的工具會得到可預期的結果，不同於模擬點擊可能產生的不確定性。第三是明確的意圖宣告，不需要 Agent 從 UI 元素推斷行動。 核心差異在於應用功能位置不同。MCP 是連接 AI Agent 與外部系統（包括資料源、工具、工作流程）的通用標準，使用 JSON-RPC 且透過特定語言 SDK（如 Rust、Python、TypeScript）實現，屬於後端解決方案。WebMCP 則是提議的瀏覽器標準，包含兩組 API 專門與瀏覽器內建 Agent 互動，可用 JavaScript 或 HTML 屬性實現，瀏覽器充當網站與 Agent 的溝通橋樑。WebMCP 可視為「受 MCP 啟發的 API」而非直接的 JavaScript 實現，專為瀏覽器優化，省略資源等伺服器端概念。 WebMCP 帶來三大優勢。速度與可靠性方面，由於使用瀏覽器內部系統，客戶端與工具通訊幾乎瞬間完成，無需等待遠端伺服器往返。耐久性方面，WebMCP 工具連接應用邏輯而非設計，網站重設計不會破壞 Agent 的互動能力。控制權方面，開發者明確定義 Agent 與網站互動的首選方式，而非依賴 Agent 自行發現按鈕。 關鍵區別在於「誰擁有使用者介面」。MCP 應用在 Agent 的使用者介面內呈現應用，需要建立獨立新應用；WebMCP 則幫助 Agent 與現有網站實時互動，可存取活動工作階段資料、cookie 與現場瀏覽器分頁才有的 DOM 元素。應用不再是 Agent 生態內的客人，反而 Agent 成為網站上的客人。WebMCP 工具具有臨時性，僅在頁面開啟時存在，使用者離開或關閉分頁後 Agent 無法再存取。 最有效的 AI Agent 應用應同時使用兩項技術。MCP 伺服器作為基礎服務層處理核心商業邏輯、資料檢索與背景任務，確保服務平台無關且隨時可用；WebMCP 則是最後一步，直接連接 Agent 與網站，為瀏覽器內 Agent 提供高保真度互動，讓 Agent 在使用者訪問網站時能快速可靠地代表使用者行動。應將 MCP 與 WebMCP 視為夥伴而非對手，WebMCP 為瀏覽器 AI Agent 提供與使用者在分頁中看到的世界的高保真互動方式。