瀏覽器即 Agent 平台：Chrome 原生 MCP + WebMCP 如何改變前端開發（entries: webmcp-nexus, chrome-native-mcp）💡

今年年初 Google 喺 Chrome 入面直接嵌入 MCP（Model Context Protocol）支援，同期 WebMCP 標準亦開始成形。呢兩個看似獨立嘅趨勢，其實指向同一個結論：瀏覽器唔再只係「睇網頁嘅工具」，而係 AI Agent 嘅主要運行平台。對於前端開發者嚟講，呢個轉變唔單止影響我哋寫 Code 嘅方式，更會重構整個 Web 生態嘅權力結構。

MCP + WebMCP：瀏覽器成為 Agent 嘅「作業系統」

傳統上，瀏覽器係人類閱讀網頁嘅介面。我哋用眼睛睇、用滑鼠㩒、用鍵盤打字。但當 AI Agent 要操作網頁時，佢哋面對嘅係一個充滿視覺佈局同動態 DOM 嘅複雜環境——呢個正好係瀏覽器本身最擅長處理嘅嘢。

Chrome 原生 MCP 嘅做法係將瀏覽器嘅內部能力（DOM 操作、Network 攔截、Console 執行、Tab 管理）以標準化嘅 Tool Interface 暴露俾 AI Agent。換句話講，Agent 可以直接通過 MCP Protocol 同瀏覽器溝通，唔再需要依賴 Selenium 或 Puppeteer 呢類半鹹淡嘅自動化 Layer。呢個唔係增量改善，而係根本性嘅 Architecture Shift——瀏覽器由「被動嘅渲染引擎」變成「主動嘅 Agent Runtime」。

WebMCP 更進一步。佢定義咗一個標準，讓網站開發者可以宣告式咁描述自己網站嘅「Agent Entry Point」——即係 AI 可以點樣同呢個網站互動、有咩 Tools 可以 Call、有咩權限要申請。呢個概念類似於 REST API 嘅 OpenAPI Spec，但針對嘅係 AI Agent 嘅 Interaction Design。想像一個 EC 網站可以透過 WebMCP 公開 Product Search、Cart Management、Order Tracking 呢啲 Tool，Agent 就可以直接用自然語言幫用戶完成購物流程，而唔係靠 Screen Scraping 去估個 Button 喺邊。

對前端開發嘅三層衝擊

第一層衝擊係 UI 嘅可程式化程度會被重新定義。今日我哋寫 Frontend 嘅時候，預設嘅 User 係「人」。但如果知道你個網站嘅使用者可能係 AI Agent，你會點樣設計個 Interface？你會唔會為 Agent 提供一個專門嘅 JSON Endpoint，定係索性用 WebMCP 定義一個 Agent-First 嘅 Interaction Layer？呢個問題會改變我哋對「User Experience」嘅定義——UX 唔再只係 Human Experience，仲包括 Machine Experience。

第二層係 測試同監控嘅 Paradigm Shift。傳統嘅 E2E Testing（Cypress、Playwright）模擬人類操作——Click Button、Fill Form、Wait for Navigation。但當 Agent 變成主要使用者，我哋需要測試嘅係 MCP Tool Call 嘅 Correctness、Token Consumption、Agent Decision Path。呢個唔係 Enhancement，而係全新嘅 Testing Category。你會需要一套工具嚟 Assert「Agent 喺呢個狀態下應該 Call 咩 Tool」，而唔係「個 Button Click 咗之後 URL 係咩」。

第三層係 前端架構嘅 Agent-Native 重構。當 Agent 可以直接操作 DOM 同 Network，我哋嘅 Component 設計要考慮 Machine Readability。Semantic HTML 突然變得好重要——唔係為咗 SEO，而係為咗俾 Agent 理解你個 UI 嘅結構。ARIA Labels 唔再係 Accessibility 嘅 Bonus，而係 Agent Compatibility 嘅必需品。 States（Loading、Empty、Error、Edge Case）需要有清晰對應嘅 DOM Structure，因為 Agent 係透過 DOM 嚟判斷而家發生緊咩事，唔係靠肉眼睇 Screenshot。

開發者嘅實際行動建議

如果你係 Frontend Engineer，而家就應該開始做三件事。

第一，深入理解 MCP Protocol。去 modelcontextprotocol.io 睇 Spec，搞清楚 Tool、Resource、Prompt 呢三個核心概念。然後用 Chrome 嘅 MCP Inspector 去睇下你日常用開嘅網站有咩 MCP Tool 可以 Call——你會發現好多大型網站已經開始部署 Agent Entry Point，只係你未留意。

第二，為你嘅 Project 加入 WebMCP 或 Chrome Extension MCP。唔需要一開始就做好完整嘅 Agent Interface，可以由 Documentation 同 README 做起——等 Agent 可以透過 MCP 直接讀你個 Project 嘅文件，而唔係靠 RAG 或者 Web Crawler。呢個簡單嘅 Step 已經可以大幅提升你個 Project 喺 Agent Ecosystem 入面嘅 Discoverability。

第三，重新審視你嘅 Component Design System。每個 Component 係咪都有清晰嘅 Semantic Role？States（Loading、Empty、Error）係咪都有對應嘅 DOM Structure？Agent 嚟到嘅時候，佢可唔可以一眼就睇得出你個 UI 而家處於咩狀態？如果你嘅 Component 淨係靠 CSS Class 嚟切換狀態，而 DOM Structure 冇任何變化，Agent 係 Detect 唔到嘅。

結語

我成日覺得 Chrome 原生 MCP 之於 Agent 生態，就好似 AWS Lambda 之於 Serverless——佢提供咗一個標準化嘅 Execution Environment，令開發者可以專注寫 Logic，而唔使煩 Infrastructure。WebMCP 就係呢個生態嘅 API Gateway，定義咗 Agent 同 Web 之間嘅 Contract。對於我哋香港嘅開發者嚟講，呢個係一個難得嘅機會可以喺 Infrastructure Layer 仲未被大廠完全 Lock-in 嘅時候，Early Adopt 一個新標準。而家 Learn，半年後你就係嗰個「早就話咗俾你聽」嘅人。瀏覽器即 Agent 平台呢個趨勢，唔係「會唔會發生」嘅問題，而係「發生咗之後你準備好未」嘅問題。