MCP 協議與瀏覽器 Agent：從 N×M 套適配到一次接入

Agent 要真正動手做事，最後通常都會落到瀏覽器上：登入、發文、抓資料、填表。技術上困難的不是能不能點，而是把瀏覽器交給 Agent 時的接入成本。

N×M 的適配泥淖

假設市場上有 N 個工具、M 個模型。工具提供方要為每個模型寫一套串接程式，模型側也要為每個工具寫一套適配層，雙方各自維護，總量就是 N×M。

麻煩在於這是乘法。多一個工具，不只是多一份工作，而是要在這個工具與每個模型之間各接一次；反過來，模型換一個版本，已經接好的工具也可能要重新驗證。一個能力寫得再好，只要沒有針對某個模型的適配，就無法使用——工具就這樣卡在流通環節。

早期只能各寫各的。同一件事，列出環境、啟動瀏覽器、讀取頁面，換一個呼叫方就得重寫一次，邏輯也常常不一致：有人把等待寫在 Client，有人寫在 Server。

協議把兩邊拆開

MCP（Model Context Protocol，模型上下文協議）在 2024 年底公開，做法是把工具發現與呼叫定義成標準格式：暴露什麼、參數如何描述、回傳什麼結構，都寫進協議。

結構因此變成 Agent 連一個 MCP Client，Client 依協議連多個 MCP Server，Server 背後才是實際能力。實作量從 N×M 降到 N+M：模型側只要實作一次 Client，工具側只要實作一次 Server。

角色只有三個。Host 是執行模型的應用程式，負責把 Client 啟動起來；Client 是協議客戶端的實作，一般一個 Server 對應一個；Server 由工具提供方撰寫，把能力包成標準工具暴露出去。

目前有兩種通訊方式。本機模式走標準輸入輸出，Client 與 Server 在同一台機器上，鏈路短、設定少，做自動化時最常見。遠端模式走 HTTP 或 WebSocket，適合分散式部署，代價是必須額外釐清驗證與網路邊界。

瀏覽器場景中，暴露出來的是三層能力

把瀏覽器環境接進協議後，暴露的能力大致落在三層。

最上層是環境：列出帳號下有哪些環境、依設定新建一個、啟動指定環境、為它綁定網路出口、用完後關閉。這些動作過去散落在各家的 API 中，現在成為模型可以發現與呼叫的工具。啟動之後通常會回傳一個除錯端點，例如連接埠或 WebSocket 位址，拿到後就能交給 Selenium、Puppeteer 之類的驅動程式。

中間層是頁面：開啟位址、讀取 DOM 或無障礙樹、切換分頁、截圖。

最下層是動作：點擊、輸入、捲動、等待某個條件成立，以及處理彈出視窗。

變化的關鍵不在動作有多少，而在環境從一段必須自己寫的程式碼，變成 Agent 可以自行挑選使用的資源。你只需要說清楚目標，由它決定要先建一個環境還是重用現有環境，以及按什麼順序呼叫。多環境平行執行時尤其明顯：排程寫在提示中，而不是硬編碼在腳本裡。

現階段仍未解決的部分

協議解決連接，不解決正確性。還有幾個容易被忽略的地方。

工具描述的品質會決定呼叫結果。參數寫錯、工具選錯，協議幫不上忙；工具一多，描述本身也會佔用上下文，因此必須在數量與粒度之間取捨。粒度太粗，模型不知道一個工具能做多少件事；太細，上下文會先被塞滿。

權限與稽核仍在早期階段。相當一部分 Server 是本機單機形態，一啟動就帶著不小的權限，但缺少細粒度授權與呼叫紀錄。遠端模式則要先回答誰能連、能看到什麼。

頁面穩定性也沒有被消除。元素定位不到、載入時序不穩、登入狀態過期、驗證碼，這些仍然需要寫等待、重試與備援處理，協議只統一了入口。

生態成熟度也不均衡。不同 Server 支援的資源類型、回傳結構、錯誤碼並不完全一致，跨多個 Server 組合一個任務時，編排邏輯往往仍得自己寫。協議本身也持續演進，因此需要留意版本之間的行為差異。

還有一條邊界必須分清楚：協議管的是模型如何呼叫工具，不管任務本身是否合規。資料採集是否取得授權、帳號的使用目的是否正當、是否違反平台規則，都是獨立判斷，和鏈路順不順沒有關係。

多環境場景下，環境之間是否隔離、網路出口與時區語言是否成套，往往比接入方式更影響結果。PurpleMark 在環境隔離這一層提供了可由 AI 工具呼叫的環境建立、啟動與網路設定介面，同一個 Client 就能進行調度。

僅作技術原理說明，請在合法合規的前提下使用相關協議與工具。