最近在調(diào)試一個(gè)自動(dòng)處理后臺(tái)工單的 Agent我發(fā)現(xiàn)自己真正花時(shí)間的不是提示詞也不是模型能力而是“讓 Agent 和網(wǎng)頁(yè)真正打交道”這一層。很多 Agent 看起來(lái)智能一旦要登錄系統(tǒng)、點(diǎn)按鈕、翻表格立刻變得笨拙——要么給網(wǎng)站單獨(dú)寫接口要么靠截圖做視覺(jué)猜測(cè)要么用一套脆弱的 CSS 選擇器硬撐。直到我把瀏覽器這一層按 WebMCP 的思路重新整理了一遍才體會(huì)到什么叫“瀏覽器原生”的交互方式。這篇文章不是某個(gè)官方文檔的翻譯而是我在實(shí)際項(xiàng)目里圍繞 WebMCP、AI Agent、瀏覽器原生交互做的一次系統(tǒng)踩點(diǎn)和總結(jié)。適合正在做 Agent 產(chǎn)品、內(nèi)網(wǎng)辦公自動(dòng)化、網(wǎng)頁(yè)數(shù)據(jù)運(yùn)營(yíng)的人讀讀完能少走很多彎路。1. Agent 卡在“瀏覽器之外”WebMCP 要填的坑到底是什么1.1 現(xiàn)在主流的網(wǎng)頁(yè)交互方案各有什么死穴先說(shuō)清楚 WebMCP 為什么值得聊。過(guò)去一年我見(jiàn)過(guò)太多 Agent 項(xiàng)目架構(gòu)圖上畫得很漂亮大模型做規(guī)劃、向量庫(kù)做記憶、工具層接了一堆 API看起來(lái)無(wú)所不能。但只要落到真實(shí)業(yè)務(wù)第一個(gè)卡住的地方永遠(yuǎn)是網(wǎng)頁(yè)操作。目前主流做法基本是四條路線各自的痛點(diǎn)都很明顯。第一條路線是 API 優(yōu)先。讓網(wǎng)站方提供官方接口Agent 直接調(diào)用。這條路線最干凈但現(xiàn)實(shí)很骨感內(nèi)部老系統(tǒng)沒(méi)有 API第三方后臺(tái)不開(kāi)放 API就算有 API字段含義和權(quán)限模型也未必跟頁(yè)面操作對(duì)得上。我接過(guò)一個(gè)項(xiàng)目客戶堅(jiān)持說(shuō)“我們有 API”結(jié)果一查API 只能查數(shù)據(jù)不能提交表單最終還是要回到頁(yè)面操作。第二條路線是爬蟲加選擇器解析。寫一堆 XPath、CSS 選擇器去抓取頁(yè)面數(shù)據(jù)。缺點(diǎn)是極其脆弱頁(yè)面結(jié)構(gòu)只要微調(diào)選擇器就崩而且很多站點(diǎn)有反爬策略維護(hù)成本不亞于寫一個(gè)獨(dú)立應(yīng)用。關(guān)鍵在于爬蟲抓到的是靜態(tài) HTML對(duì)頁(yè)面交互點(diǎn)擊、拖拽、彈窗幾乎無(wú)能為力。第三條路線是視覺(jué)方案。截屏把圖片丟給多模態(tài)大模型讓模型看圖識(shí)別按鈕并給出坐標(biāo)。優(yōu)點(diǎn)是適應(yīng)性強(qiáng)缺點(diǎn)也同樣明顯截圖有延遲、Token 成本高、坐標(biāo)精度不穩(wěn)定遇到動(dòng)態(tài)加載的內(nèi)容經(jīng)常翻車。實(shí)測(cè)下來(lái)視覺(jué)方案適合做兜底和校驗(yàn)不適合做主力操作路徑。第四條路線是瀏覽器自動(dòng)化腳本比如 Selenium、Playwright 這一派。腳本本身很成熟穩(wěn)定性也不錯(cuò)。但問(wèn)題在于這些工具強(qiáng)調(diào)的是“腳本執(zhí)行命令”不是“讓 Agent 理解頁(yè)面”。你需要為每一次操作編寫?yīng)毩⑦壿嫛却硞€(gè)元素、判斷是否存在、處理彈窗——等于每個(gè)站點(diǎn)都要定制開(kāi)發(fā)一套驅(qū)動(dòng)程序。代碼量巨大且不可通用。你把這四條路線擺在一起看會(huì)發(fā)現(xiàn)一個(gè)共同死穴沒(méi)有任何一個(gè)標(biāo)準(zhǔn)協(xié)議讓瀏覽器主動(dòng)向 Agent 聲明“我能干什么、現(xiàn)在是什么狀態(tài)”。所有方案都是 Agent 在外部猜而不是瀏覽器在內(nèi)部提供能力。WebMCP 想解決的正是這個(gè)問(wèn)題。1.2 “瀏覽器原生”到底意味著什么WebMCP可以拆成 Web 加 MCP。MCP 是 Model Context Protocol 的縮寫核心思路是把“模型需要的外部能力”標(biāo)準(zhǔn)化成一套協(xié)議。好比電腦上的 USB-C 接口不管接的是顯示器、硬盤還是充電器接口形態(tài)統(tǒng)一了設(shè)備之間就能即插即用。WebMCP 就是把這套協(xié)議搬進(jìn)瀏覽器環(huán)境。更直白一點(diǎn)瀏覽器不再只是一個(gè)被操作的對(duì)象而成為 MCP 的宿主運(yùn)行時(shí)。網(wǎng)頁(yè)本身可以作為一個(gè)“能力端點(diǎn)”存在主動(dòng)暴露自己的表單字段、按鈕、列表狀態(tài)、加載狀態(tài)Agent 通過(guò)標(biāo)準(zhǔn)化的協(xié)議去發(fā)現(xiàn)這些能力并調(diào)用它們。我用一個(gè)生活化的類比。傳統(tǒng)做法是你想讓一個(gè)人幫你操作一臺(tái)老舊儀器你得先寫一份極其詳細(xì)的操作手冊(cè)告訴他哪個(gè)旋鈕在哪兒、怎么擰、擰到什么位置。WebMCP 的做法是這臺(tái)儀器自己貼了一張標(biāo)簽上面寫著“我有三個(gè)旋鈕、兩個(gè)按鈕、一個(gè)顯示屏支持以下操作”操作員看一眼標(biāo)簽就能開(kāi)工而且換一臺(tái)儀器只要標(biāo)簽寫得規(guī)范操作員幾乎不用重新學(xué)習(xí)。所以所謂“瀏覽器原生”交互核心就三點(diǎn)能力可發(fā)現(xiàn)、操作可標(biāo)準(zhǔn)化、狀態(tài)可感知。頁(yè)面自己把底牌亮出來(lái)Agent 按統(tǒng)一規(guī)則來(lái)打這就是與之前所有方案的分水嶺。1.3 誰(shuí)最需要它結(jié)合我接觸到的需求方下面這幾類人最應(yīng)該關(guān)注 WebMCP。做內(nèi)部辦公自動(dòng)化 Agent 的團(tuán)隊(duì)。ERP、CRM、工單系統(tǒng)這類老后臺(tái)普遍沒(méi)有開(kāi)放接口但業(yè)務(wù)流程又必須走頁(yè)面。WebMCP 能把這些頁(yè)面變成可以被 Agent 調(diào)度的“虛擬 API”自動(dòng)化程度直接上一個(gè)臺(tái)階。做垂直場(chǎng)景助手的開(kāi)發(fā)者。比如讓 Agent 幫用戶查物流、比價(jià)、填表單、管理后臺(tái)內(nèi)容。有了標(biāo)準(zhǔn)化協(xié)議你不用為每個(gè)網(wǎng)站單獨(dú)寫適配器開(kāi)發(fā)效率提升是數(shù)量級(jí)的。做瀏覽器插件產(chǎn)品的團(tuán)隊(duì)。很多插件本質(zhì)上就是在替用戶操作網(wǎng)頁(yè)之前只能靠?jī)?nèi)容腳本硬編碼邏輯現(xiàn)在可以讓插件成為一個(gè) MCP 網(wǎng)關(guān)把頁(yè)面能力開(kāi)放給上層 Agent。另外還有一類做 RPA 改造的公司。傳統(tǒng) RPA 靠錄屏和選擇器綁定遇到頁(yè)面改版就廢。WebMCP 這種語(yǔ)義化、意圖化的思路恰好補(bǔ)上了 RPA 在“頁(yè)面理解”上的短板。2. 從 MCP 到 WebMCP三個(gè)關(guān)鍵設(shè)計(jì)讓瀏覽器變成 Agent 的“原生環(huán)境”2.1 先回顧 MCP 的三件套約定在深入 WebMCP 之前得先把 MCP 的基礎(chǔ)約定說(shuō)清楚否則后面全是空中樓閣。MCP 的設(shè)計(jì)很簡(jiǎn)潔它定義了三種核心原語(yǔ)。第一是 Tools代表動(dòng)作能力。比如“查詢天氣”“創(chuàng)建訂單”“提交表單”每個(gè) Tool 有自己的輸入?yún)?shù)和輸出格式。Agent 通過(guò)調(diào)用 Tool 完成具體操作類似函數(shù)調(diào)用。第二是 Resources代表數(shù)據(jù)資源。比如“用戶信息”“商品詳情”“頁(yè)面上的表單字段列表”。Resources 是只讀的Agent 先從 Resources 里獲取上下文再?zèng)Q定調(diào)用哪些 Tools。第三是 Prompts代表可復(fù)用的提示模板。用于把常見(jiàn)任務(wù)固化成模板減少 Agent 的規(guī)劃負(fù)擔(dān)。MCP 的設(shè)計(jì)哲學(xué)很像給 AI 界的各種模型和工具之間做了一套通用的“插線板”。你不需要針對(duì)每個(gè)模型寫一套工具適配代碼只要工具側(cè)實(shí)現(xiàn)了 MCP 協(xié)議任何兼容的模型都能直接調(diào)用。WebMCP 沿用了這套三件套但把實(shí)現(xiàn)環(huán)境放在了瀏覽器里。這帶來(lái)一個(gè)關(guān)鍵轉(zhuǎn)變傳統(tǒng)的 MCP 工具通常是外掛在應(yīng)用之外的比如一個(gè) Python 服務(wù)去調(diào)數(shù)據(jù)庫(kù)而 WebMCP 的工具和資源是網(wǎng)頁(yè)元素本身。按鈕、輸入框、下拉菜單、列表、分頁(yè)器在 WebMCP 的視角下都是可以被聲明和暴露的“原生資源”。2.2 關(guān)鍵設(shè)計(jì)一頁(yè)面即端點(diǎn)Page as Endpoint這是我認(rèn)為 WebMCP 最核心的設(shè)計(jì)理念。傳統(tǒng)的瀏覽器自動(dòng)化里頁(yè)面只是一個(gè)被遙控的目標(biāo)腳本在外面操作它。而 WebMCP 把每個(gè)頁(yè)面看作一個(gè) MCP 端點(diǎn)Endpoint頁(yè)面自己負(fù)責(zé)向 Agent 描述自身的能力。具體怎么做以 Chromium 系瀏覽器為例通過(guò)擴(kuò)展或者注入腳本在頁(yè)面加載完成后做一次“能力盤點(diǎn)”。盤點(diǎn)內(nèi)容包括表單字段有哪些、可見(jiàn)按鈕有哪些、當(dāng)前處于什么加載狀態(tài)、有無(wú)彈窗或錯(cuò)誤提示。然后生成一份結(jié)構(gòu)化的描述文檔相當(dāng)于頁(yè)面的“能力名片”。這份描述文檔不是隨便生成的它要遵循統(tǒng)一的 schema。比如一個(gè)表單字段會(huì)記錄它的語(yǔ)義 ID、類型文本、日期、下拉、當(dāng)前值、是否必填、關(guān)聯(lián)的校驗(yàn)規(guī)則。Agent 拿到這份文檔不需要自己猜測(cè)頁(yè)面上有什么直接按圖索驥即可。我把這個(gè)設(shè)計(jì)叫“頁(yè)面即端點(diǎn)”是因?yàn)樗鼜氐赘淖兞四芰Φ臍w屬關(guān)系。之前是“Agent 想辦法去夠頁(yè)面”現(xiàn)在是“頁(yè)面主動(dòng)把手伸給 Agent”。別小看這個(gè)反轉(zhuǎn)它帶來(lái)的直接好處是通用性。只要每個(gè)頁(yè)面都實(shí)現(xiàn)了這套端點(diǎn)化描述Agent 面對(duì)任何一個(gè)站點(diǎn)都不再是“盲人摸象”而是先看名片再辦事。2.3 關(guān)鍵設(shè)計(jì)二從“坐標(biāo)點(diǎn)擊”到“意圖操作”傳統(tǒng)瀏覽器自動(dòng)化最常見(jiàn)的毀譽(yù)參半的點(diǎn)就是依賴坐標(biāo)或選擇器。比如“點(diǎn)擊頁(yè)面坐標(biāo) (x, y)”或“點(diǎn)擊 #submit-btn”。坐標(biāo)的問(wèn)題很明顯頁(yè)面窗口大小一變、布局一變坐標(biāo)就廢了。選擇器的問(wèn)題也很明顯前端重構(gòu)一下 class 名腳本直接崩潰。WebMCP 的思路是切換到“意圖操作”。Agent 告訴瀏覽器“我要提交這個(gè)表單”“我要把發(fā)貨狀態(tài)切換到已完成”而不是“我要點(diǎn)坐標(biāo)為 (320, 480) 的地方”。瀏覽器側(cè)收到意圖后自己去找對(duì)應(yīng)的元素、判斷是否可交互、執(zhí)行操作并返回結(jié)果。這就好比你和人打交道你不會(huì)說(shuō)“請(qǐng)把你的右手食指抬高 5 厘米指向那個(gè)紅色按鈕”你會(huì)說(shuō)“請(qǐng)按一下左邊的紅色按鈕”。意圖操作的價(jià)值在于它把“如何定位元素”這件事留給了瀏覽器側(cè)而 Agent 只關(guān)心“我想達(dá)成什么效果”。頁(yè)面前端再怎么改版只要功能語(yǔ)義不變Agent 的任務(wù)定義就不用變。在我自己的測(cè)試?yán)镞@個(gè)設(shè)計(jì)的實(shí)際收益非常明顯。之前用 Playwright 寫一套后臺(tái)自動(dòng)化頁(yè)面改版后往往要改幾個(gè)小時(shí)的選擇器。改用意圖化描述后大多數(shù)情況下只需要重新生成一次能力文檔Agent 側(cè)的任務(wù)定義幾乎不動(dòng)。2.4 關(guān)鍵設(shè)計(jì)三會(huì)話綁定與上下文黏性還有一個(gè)容易被忽略、但實(shí)際使用中極其重要的設(shè)計(jì)會(huì)話綁定。Agent 操作網(wǎng)頁(yè)天然涉及多輪交互。你要先登錄然后跳到某個(gè)菜單再填寫查詢條件最后點(diǎn)擊搜索并讀取結(jié)果。這個(gè)過(guò)程里狀態(tài)是連續(xù)的。如果每次操作都當(dāng)作獨(dú)立的無(wú)狀態(tài)請(qǐng)求就完了。WebMCP 借用瀏覽器的天然能力來(lái)解決這個(gè)問(wèn)題。Cookie、IndexedDB、LocalStorage 這些瀏覽器本地狀態(tài)天然就是會(huì)話的載體。WebMCP 會(huì)為每個(gè)任務(wù)創(chuàng)建綁定到特定標(biāo)簽頁(yè)的會(huì)話上下文Agent 的操作始終在這個(gè)上下文里執(zhí)行。更近一步跨標(biāo)簽頁(yè)的時(shí)候也能保持住“會(huì)話黏性”。比如任務(wù)需要同時(shí)參考兩個(gè)頁(yè)面的數(shù)據(jù)WebMCP 可以給兩個(gè)標(biāo)簽頁(yè)的會(huì)話掛上同一個(gè)任務(wù) ID。這樣即使 Agent 在頁(yè)面 A 登錄了切換到頁(yè)面 B 時(shí)登錄態(tài)依然能通過(guò)共享的瀏覽器上下文被感知不需要重復(fù)認(rèn)證。這個(gè)設(shè)計(jì)也帶來(lái)了一個(gè)嚴(yán)肅的問(wèn)題會(huì)話安全。一個(gè) Agent 可能同時(shí)處理多個(gè)任務(wù)如果會(huì)話上下文串了任務(wù) A 的操作跑到任務(wù) B 的頁(yè)面里后果不堪設(shè)想。所以 WebMCP 的會(huì)話綁定通常會(huì)做嚴(yán)格隔離每個(gè)任務(wù)一個(gè)獨(dú)立會(huì)話空間并且配合用戶授權(quán)機(jī)制。3. WebMCP 落地的模塊拆分?jǐn)U展層、橋接層與 DOM 能力層怎么協(xié)同3.1 建議的四層架構(gòu)參考聊完理念來(lái)點(diǎn)實(shí)際的。如果你要在自己項(xiàng)目里落地 WebMCP建議按下面這個(gè)四層架構(gòu)來(lái)拆。這個(gè)架構(gòu)不是嚴(yán)格標(biāo)準(zhǔn)而是我結(jié)合幾個(gè)實(shí)踐項(xiàng)目總結(jié)的相對(duì)省力的組織方式。第一層瀏覽器擴(kuò)展層。它負(fù)責(zé)三件事識(shí)別需要注入的頁(yè)面、管理用戶授權(quán)、維護(hù) WebMCP 端點(diǎn)生命周期。沒(méi)有這一層后面的能力層根本沒(méi)有入口。擴(kuò)展層要在頁(yè)面加載前就準(zhǔn)備好運(yùn)行時(shí)并且要處理用戶對(duì)哪些站點(diǎn)授權(quán)、哪些站點(diǎn)拒絕的決策邏輯。第二層協(xié)議橋接層。這是最容易被低估的一層。它負(fù)責(zé)把瀏覽器側(cè)發(fā)生的“原生事件”比如表單值變化、點(diǎn)擊、頁(yè)面跳轉(zhuǎn)、請(qǐng)求失敗翻譯成 MCP 協(xié)議格式的消息同時(shí)把 Agent 發(fā)來(lái)的 MCP 請(qǐng)求翻譯回瀏覽器側(cè)的 DOM 操作。相當(dāng)于一個(gè)翻譯官。第三層DOM 能力層。這一層負(fù)責(zé)生成“能力文檔”并執(zhí)行指令。具體來(lái)說(shuō)就是遍歷 DOM 樹抽取可交互元素和相關(guān)狀態(tài)生成結(jié)構(gòu)化的資源描述同時(shí)實(shí)現(xiàn)“意圖操作”的執(zhí)行——Agent 說(shuō)要提交表單這層去定位、校驗(yàn)、點(diǎn)擊、等待回執(zhí)。第四層調(diào)度與會(huì)話層。它管多任務(wù)并發(fā)、標(biāo)簽頁(yè)歸屬、會(huì)話隔離、超時(shí)重試。如果一個(gè) Agent 同時(shí)處理兩個(gè)任務(wù)分別操作兩個(gè)標(biāo)簽頁(yè)調(diào)度層必須保證兩邊互不干擾。四層之間可以理解為這樣的協(xié)作關(guān)系會(huì)話層接到任務(wù)詢問(wèn)擴(kuò)展層哪個(gè)頁(yè)面被授權(quán)了然后通過(guò)橋接層與 DOM 能力層溝通DOM 能力層再返回操作結(jié)果橋接層把結(jié)果格式化最終會(huì)話層把結(jié)果交給 Agent 決策。層級(jí)主要職責(zé)典型實(shí)現(xiàn)要點(diǎn)瀏覽器擴(kuò)展層注入、授權(quán)、生命周期manifest 配置、站點(diǎn)白名單、運(yùn)行時(shí)清理協(xié)議橋接層事件雙向翻譯、協(xié)議格式化MCP 消息編解碼、錯(cuò)誤映射、重試邏輯DOM 能力層能力盤點(diǎn)、意圖執(zhí)行語(yǔ)義 ID 抽取、元素定位、狀態(tài)檢測(cè)調(diào)度與會(huì)話層并發(fā)控制、會(huì)話隔離任務(wù) ID 綁定、標(biāo)簽頁(yè)映射、超時(shí)熔斷3.2 一次完整任務(wù)交互的時(shí)序展開(kāi)紙上談兵沒(méi)有用我把一次真實(shí)任務(wù)的完整時(shí)序拆出來(lái)。假設(shè)用戶對(duì) Agent 說(shuō)“把后臺(tái)里上個(gè)月的異常訂單導(dǎo)出來(lái)按金額倒序生成一個(gè)表格”。第一步Agent 的任務(wù)規(guī)劃層拆分出多個(gè)子任務(wù)打開(kāi)后臺(tái)、登錄如果未登錄、進(jìn)入訂單列表、篩選日期、導(dǎo)出數(shù)據(jù)。第二步調(diào)度層檢查現(xiàn)有的會(huì)話發(fā)現(xiàn)沒(méi)有對(duì)應(yīng)后臺(tái)的授權(quán)于是提示用戶授權(quán)。用戶同意后擴(kuò)展層在目標(biāo)站點(diǎn)頁(yè)面注入 WebMCP 運(yùn)行時(shí)。第三步擴(kuò)展層通知 DOM 能力層做一次能力盤點(diǎn)生成該頁(yè)面的能力文檔。文檔里記錄了當(dāng)前頁(yè)面有登錄表單、登錄按鈕、輸入框等。第四步Agent 下發(fā)意圖操作“填充登錄表單并提交”。橋接層翻譯請(qǐng)求DOM 能力層執(zhí)行返回登錄成功或失敗的狀態(tài)。第五步登錄成功后DOM 能力層重新盤點(diǎn)頁(yè)面能力因?yàn)榈卿浐蟮捻?yè)面和登錄前的頁(yè)面完全是兩個(gè)狀態(tài)。Agent 根據(jù)新的能力文檔繼續(xù)規(guī)劃點(diǎn)擊“訂單管理”、輸入篩選條件、點(diǎn)擊導(dǎo)出。第六步所有操作完成后結(jié)果數(shù)據(jù)回傳會(huì)話層把任務(wù)標(biāo)記為完成并清理不再需要的臨時(shí)狀態(tài)。這個(gè)時(shí)序里最值得注意的一點(diǎn)是每次頁(yè)面狀態(tài)變化后都必須重新做能力盤點(diǎn)。很多初次實(shí)現(xiàn) WebMCP 的人習(xí)慣在頁(yè)面加載時(shí)只盤點(diǎn)一次后面就一直用舊文檔。結(jié)果就是 Agent 以為頁(yè)面上還有登錄按鈕實(shí)際上已經(jīng)在訂單列表頁(yè)了直接原地出錯(cuò)。我反復(fù)強(qiáng)調(diào)能力文檔是快照不是永久檔案頁(yè)面一變快照就必須刷新。3.3 狀態(tài)持久化的細(xì)節(jié)處理狀態(tài)持久化是個(gè)不顯眼但繞不開(kāi)的問(wèn)題。Agent 在頁(yè)面上操作產(chǎn)生的狀態(tài)散落在各處登錄態(tài)在 Cookie 里、篩選條件在頁(yè)面內(nèi)存里、表格排序在 UI 狀態(tài)里、臨時(shí)數(shù)據(jù)在 JS 變量里。WebMCP 的實(shí)踐經(jīng)驗(yàn)是按層級(jí)分層持久化。第一層是瀏覽器原生狀態(tài)比如 Cookie 和 IndexedDB托管給瀏覽器本身Agent 不用管。第二層是頁(yè)面交互產(chǎn)生的臨時(shí)狀態(tài)比如一個(gè)沒(méi)提交的表單內(nèi)容DOM 能力層需要維護(hù)一份內(nèi)存映射并且在頁(yè)面刷新后能恢復(fù)能恢復(fù)則恢復(fù)不能恢復(fù)就明確告訴 Agent 需要重新操作。第三層是 Agent 側(cè)的會(huì)話記錄也就是每一輪操作的歷史、操作前后的頁(yè)面快照這部分要持久化到后端形成審計(jì)鏈路。我在項(xiàng)目里踩過(guò)一個(gè)大坑Agent 填了一半表單網(wǎng)絡(luò)閃斷頁(yè)面刷新填的內(nèi)容全沒(méi)了。之前沒(méi)有“恢復(fù)草稿”機(jī)制Agent 完全意識(shí)不到自己丟了多少狀態(tài)直接進(jìn)入下一步操作結(jié)果把空表單提交了。后來(lái)我在 DOM 能力層加了一個(gè)“表單草稿快照”每填一個(gè)字段就同步一份到會(huì)話存儲(chǔ)?；謴?fù)后Agent 先比對(duì)快照發(fā)現(xiàn)缺失字段就重新填才算解決了這個(gè)問(wèn)題。4. 跑通一個(gè)最小 WebMCP 項(xiàng)目讓 Agent 真正操作一個(gè)網(wǎng)頁(yè)表單4.1 建立環(huán)境和目標(biāo)理論說(shuō)太多容易飄還是動(dòng)手跑個(gè)最小項(xiàng)目。這里的目標(biāo)是用本地服務(wù)起兩個(gè)頁(yè)面一個(gè)表單頁(yè)一個(gè)結(jié)果頁(yè)讓 Agent 通過(guò) WebMCP 的簡(jiǎn)化實(shí)現(xiàn)來(lái)自動(dòng)填寫表單并提交驗(yàn)證核心鏈路能通。這個(gè)項(xiàng)目不需要完整實(shí)現(xiàn)標(biāo)準(zhǔn) MCP 協(xié)議重點(diǎn)是跑通“能力盤點(diǎn) 意圖操作 會(huì)話綁定”的主鏈路我已經(jīng)用這種方式在一個(gè)內(nèi)部項(xiàng)目里驗(yàn)證過(guò)整個(gè)思路的可行性。環(huán)境準(zhǔn)備如下。一臺(tái)裝有 Chromium 系瀏覽器的電腦Chrome 或 Edge 均可打開(kāi)開(kāi)發(fā)者模式準(zhǔn)備一個(gè)臨時(shí)擴(kuò)展。本地起一個(gè)簡(jiǎn)單的靜態(tài)服務(wù)比如 npx serve 或者任意靜態(tài)服務(wù)器。表單頁(yè)用 demo-form.html結(jié)果頁(yè)用 demo-result.html。Agent 側(cè)的調(diào)用用簡(jiǎn)單的 Node 腳本加 fetch 請(qǐng)求模擬不走完整實(shí)現(xiàn)但保留協(xié)議結(jié)構(gòu)。你不需要任何云服務(wù)全部本地跑通。整個(gè)過(guò)程大概半小時(shí)能完成。4.2 擴(kuò)展側(cè)的核心代碼第一步是創(chuàng)建一個(gè)最小 Chrome 擴(kuò)展。目錄結(jié)構(gòu)簡(jiǎn)單點(diǎn)manifest.json 加 content.js 就夠。manifest 需要聲明 content script 匹配本地頁(yè)面并允許訪問(wèn)頁(yè)面 DOM。{ manifest_version: 3, name: Local MCP Bridge, version: 0.1.0, content_scripts: [ { matches: [http://127.0.0.1/*], js: [content.js], run_at: document_idle } ], permissions: [storage] }content.js 里做一個(gè)極簡(jiǎn)的 WebMCP 運(yùn)行時(shí)。頁(yè)面加載完成后盤點(diǎn)當(dāng)前表單字段生成能力文檔并暴露一個(gè)本地接口供 Agent 側(cè)調(diào)用。// content.js —— 簡(jiǎn)化版把當(dāng)前頁(yè)面當(dāng)作 MCP 端點(diǎn) (function registerEndpoint() { // 1. 能力盤點(diǎn)掃描表單字段和按鈕 function scanCapabilities() { const fields Array.from(document.querySelectorAll(input, select, textarea)).map((el) { return { id: el.id || el.name || field- Math.random().toString(36).slice(2, 8), type: el.type || el.tagName.toLowerCase(), currentValue: el.value || , required: el.hasAttribute(required), label: document.querySelector(label[for${el.id}])?.textContent?.trim() || }; }); const buttons Array.from(document.querySelectorAll(button, input[typesubmit])).map((el) { return { id: el.id || el.name || btn- Math.random().toString(36).slice(2, 8), text: el.textContent?.trim() || el.value || }; }); return { fields, buttons, url: location.href, title: document.title }; } // 2. 意圖操作按字段名填值 function fillField(fieldId, value) { const el document.getElementById(fieldId); if (!el) return { ok: false, error: field not found }; el.value value; el.dispatchEvent(new Event(input, { bubbles: true })); return { ok: true, fieldId, value }; } function submitForm() { const form document.querySelector(form); if (!form) return { ok: false, error: form not found }; form.dispatchEvent(new Event(submit, { bubbles: true, cancelable: true })); return { ok: true }; } // 3. 暴露給外部通過(guò) window 上掛一個(gè)全局對(duì)象方便 Agent 側(cè)調(diào)用 window.__localMCPBridge__ { scanCapabilities, fillField, submitForm, sessionId: demo-session-local }; console.log([WebMCP] endpoint registered for:, location.href); })();這個(gè)示例里的 dispatchEvent 很重要很多前端框架比如 React監(jiān)聽(tīng)的是合成事件直接賦值 el.value 不會(huì)觸發(fā)框架的 onChange必須補(bǔ)一個(gè) input 事件否則表單數(shù)據(jù)不會(huì)被框架捕獲。4.3 Agent 側(cè)調(diào)用鏈路擴(kuò)展準(zhǔn)備好后表單頁(yè)加載時(shí)會(huì)自動(dòng)注入運(yùn)行時(shí)。現(xiàn)在寫 Agent 側(cè)的調(diào)用腳本。這里用 Node 的 fetch 來(lái)模擬 Agent 發(fā)送 MCP 風(fēng)格請(qǐng)求。// agent-simulator.js —— 用 fetch 模擬 Agent 的 MCP 調(diào)用 const endpoint http://127.0.0.1:9222/mcp; // 實(shí)際生產(chǎn)環(huán)境會(huì)通過(guò)調(diào)試協(xié)議或擴(kuò)展橋接 const headers { Content-Type: application/json }; async function scan(targetUrl) { const res await fetch(${endpoint}/resource, { method: POST, headers, body: JSON.stringify({ target: targetUrl, resource: dom://capabilities, sessionId: demo-session-local }) }); return res.json(); } async function runTask() { // 1. 盤點(diǎn)頁(yè)面能力 const caps await scan(http://127.0.0.1:3000/demo-form.html); console.log(頁(yè)面能力清單:, caps); // 2. 填充字段 const fillRes await fetch(${endpoint}/tool, { method: POST, headers, body: JSON.stringify({ tool: form.fill, input: { fieldId: name, value: 測(cè)試訂單-202401 }, sessionId: demo-session-local }) }); console.log(填充結(jié)果:, await fillRes.json()); // 3. 提交表單 const submitRes await fetch(${endpoint}/tool, { method: POST, headers, body: JSON.stringify({ tool: form.submit, input: {}, sessionId: demo-session-local }) }); console.log(提交結(jié)果:, await submitRes.json()); } runTask().catch(console.error);這個(gè)腳本里的 URL 和接口路徑是我為了演示定義的真正生產(chǎn)環(huán)境會(huì)統(tǒng)一走遠(yuǎn)程 MCP 端點(diǎn)或者通過(guò)擴(kuò)展的消息通道。但結(jié)構(gòu)不需要變先盤點(diǎn)能力再調(diào)用工具再拿結(jié)果。如果你把目標(biāo) URL 換成任意一個(gè)授權(quán)過(guò)的頁(yè)面只要頁(yè)面里實(shí)現(xiàn)了 WebMCP 運(yùn)行時(shí)鏈路就是一樣的。4.4 驗(yàn)證結(jié)果和最先遇到的坑啟動(dòng)本地服務(wù)、加載擴(kuò)展、運(yùn)行 agent-simulator.js正常情況會(huì)看到控制臺(tái)依次輸出能力清單、填充結(jié)果、提交結(jié)果。提交成功后瀏覽器自動(dòng)跳到 demo-result.html頁(yè)面顯示“收到訂單測(cè)試訂單-202401”。跑通之后有四個(gè)高頻坑你幾乎一定會(huì)遇到。第一個(gè)坑content script 注入時(shí)機(jī)。如果 run_at 是 document_idle頁(yè)面主框架還在加載時(shí)可能拿不到完整 DOM。解決辦法是加上run_at: document_start并在 DOMContentLoaded 后再盤點(diǎn)或者用 MutationObserver 監(jiān)聽(tīng)頁(yè)面變化。第二個(gè)坑input 事件沒(méi)觸發(fā)。前面提過(guò)React 和 Vue 這類框架對(duì)原生事件有封裝填充 value 后必須手動(dòng)派發(fā)事件否則組件內(nèi)部狀態(tài)沒(méi)更新。第三個(gè)坑表單校驗(yàn)攔截。很多表單有前端校驗(yàn)如果 Agent 填的值不滿足校驗(yàn)規(guī)則表單根本提交不出去。DOM 能力層必須在提交前調(diào)用 form.checkValidity()把校驗(yàn)失敗信息返回給 Agent讓它重新填。第四個(gè)坑頁(yè)面跳轉(zhuǎn)導(dǎo)致腳本失效。表單提交后頁(yè)面跳轉(zhuǎn)content script 在新頁(yè)面會(huì)重新注入但 Agent 可能還抱著舊會(huì)話 ID。所以會(huì)話層要監(jiān)聽(tīng)頁(yè)面跳轉(zhuǎn)事件自動(dòng)切換新的能力文檔而不是硬闖。以我的經(jīng)驗(yàn)這四個(gè)坑里最傷的是第二個(gè)因?yàn)樗粫?huì)直接報(bào)錯(cuò)而是表現(xiàn)為“填了值但提交后數(shù)據(jù)是空的”排查起來(lái)非常迷惑。建議從現(xiàn)在開(kāi)始凡是實(shí)現(xiàn)瀏覽器側(cè)填充邏輯一律補(bǔ) input 事件。5. 實(shí)測(cè)里最折磨人的五個(gè)問(wèn)題會(huì)話漂移、DOM 漂移與誤觸攔截5.1 DOM 漂移SPA 和懶加載的頻繁偷襲我在第 3 章提過(guò)能力文檔要及時(shí)刷新實(shí)際操作中DOM 漂移是最大頻率翻車點(diǎn)。尤其是單頁(yè)應(yīng)用SPA它不會(huì)整頁(yè)刷新而是通過(guò) JS 重寫局部 DOM比如點(diǎn)擊 Tab 切換面板。如果 Agent 用的是舊能力文檔它看到的字段可能已經(jīng)全部移除了。更隱蔽的是懶加載。很多列表頁(yè)在滾動(dòng)到底部時(shí)才加載更多數(shù)據(jù)項(xiàng)加載前頁(yè)面上根本沒(méi)有這些元素。Agent 想采集全部數(shù)據(jù)結(jié)果只讀到第一屏。對(duì)策分兩層。DOM 能力層要做“溫和重掃”每次意圖操作執(zhí)行前都檢查當(dāng)前 DOM 與能力文檔的差異如果關(guān)鍵元素列表變化超過(guò)閾值就重新生成文檔并警告 Agent。調(diào)度層要做“時(shí)機(jī)感知”對(duì)于懶加載場(chǎng)景Agent 下發(fā)滾動(dòng)操作后要等待一段時(shí)間讓數(shù)據(jù)加載完成而不是立刻采集。我看過(guò)很多團(tuán)隊(duì)在 DOM 漂移上死磕選擇器方向就偏了。這問(wèn)題的本質(zhì)是頁(yè)面是動(dòng)態(tài)的所以方案也必須是動(dòng)態(tài)的——能力文檔不是一次生成永久使用而是伴隨頁(yè)面狀態(tài)變化的增量化快照。5.2 多標(biāo)簽頁(yè)的會(huì)話歸屬錯(cuò)亂當(dāng) Agent 同時(shí)處理多個(gè)任務(wù)時(shí)最容易出現(xiàn)的詭異問(wèn)題是任務(wù) A 的 Agent 調(diào)了一個(gè) form.fill結(jié)果表單出現(xiàn)在任務(wù) B 的標(biāo)簽頁(yè)里。根因是會(huì)話 ID 沒(méi)有和具體標(biāo)簽頁(yè)的頂層執(zhí)行上下文綁定。我的解決方案是給會(huì)話 ID 增加層級(jí)任務(wù)ID:標(biāo)簽頁(yè)ID:執(zhí)行上下文ID。任務(wù) ID 標(biāo)識(shí)一次用戶請(qǐng)求標(biāo)簽頁(yè) ID 標(biāo)識(shí)具體瀏覽器 Tab執(zhí)行上下文 ID 標(biāo)識(shí)頁(yè)面里的一個(gè) iframe 或 Shadow DOM 分區(qū)。每層獨(dú)立層層校驗(yàn)。還有一個(gè)很現(xiàn)實(shí)的坑標(biāo)簽頁(yè)可能被用戶手動(dòng)關(guān)閉。Agent 還在往這個(gè)會(huì)話發(fā)請(qǐng)求結(jié)果發(fā)現(xiàn)目標(biāo)頁(yè)面沒(méi)了。調(diào)度層必須監(jiān)聽(tīng)標(biāo)簽頁(yè)關(guān)閉事件發(fā)現(xiàn)會(huì)話綁定的標(biāo)簽頁(yè)不存在時(shí)立即標(biāo)記會(huì)話異常讓 Agent 決定是重新打開(kāi)頁(yè)面還是轉(zhuǎn)人工。5.3 權(quán)限確認(rèn)的誤觸用戶被問(wèn)太多次就點(diǎn)到“一律允許”WebMCP 涉及瀏覽器操作必然要引入權(quán)限確認(rèn)機(jī)制。但這里存在一個(gè)產(chǎn)品層面的兩難每次操作都彈窗確認(rèn)用戶嫌煩Agent 效率也低完全不確認(rèn)風(fēng)險(xiǎn)大得沒(méi)法接受。我在實(shí)踐中的折中方案是分級(jí)授權(quán)。按操作類型分三級(jí)第一級(jí)是只讀操作比如讀取頁(yè)面數(shù)據(jù)配置好站點(diǎn)白名單后不再?gòu)棿暗诙?jí)是寫入操作比如填表單、點(diǎn)擊提交彈窗確認(rèn)但記住站點(diǎn)級(jí)偏好第三級(jí)是高敏感操作比如轉(zhuǎn)賬、刪除、發(fā)送消息必須每次單獨(dú)確認(rèn)并且確認(rèn)按鈕要有冷卻時(shí)間。這個(gè)分級(jí)的實(shí)現(xiàn)并不復(fù)雜但在體驗(yàn)和安全的平衡上很有價(jià)值。用戶會(huì)逐漸形成信任只讀和常規(guī)寫入不用管高敏感操作始終被保護(hù)。如果你不做分級(jí)一股腦全彈窗用戶很快就會(huì)不耐煩地點(diǎn)“一律允許”權(quán)限防線等于崩潰。5.4 iframe 與 Shadow DOM 的“黑盒”問(wèn)題真實(shí)的后臺(tái)系統(tǒng)里iframe 嵌套是常態(tài)特別是老企業(yè)內(nèi)部系統(tǒng)。而 Shadow DOM 則是現(xiàn)代前端組件庫(kù)比如 Web Components的常見(jiàn)產(chǎn)物。這兩個(gè)東西對(duì) WebMCP 的直接威脅是主文檔 DOM 能力層巡視不到它們。iframe 的問(wèn)題在于跨源限制。如果 iframe 和主頁(yè)面同源可以直接遞歸遍歷如果跨源就不能直接操作其內(nèi)部 DOM必須通過(guò)瀏覽器擴(kuò)展的跨上下文機(jī)制或者 postMessage 橋接。Shadow DOM 的問(wèn)題在于事件穿透和選擇。普通 querySelector 無(wú)法穿透 Shadow DOM 邊界必須使用選擇器對(duì) shadowRoot 進(jìn)行遞歸匹配。對(duì)策就是一條DOM 能力層必須同時(shí)處理三種容器頂層 document、iframe document、Shadow root。并且在能力文檔里顯式標(biāo)注每個(gè)元素的容器歸屬和來(lái)源 origin。Agent 看到的是統(tǒng)一抽象但真正執(zhí)行時(shí)由能力層按歸屬路由到對(duì)應(yīng)容器。5.5 并發(fā)任務(wù)時(shí)的瀏覽器資源爭(zhēng)搶最后一個(gè)高頻問(wèn)題是并發(fā)。Agent 不是單線程思考它可能在等待頁(yè)面 A 的接口響應(yīng)時(shí)同時(shí)去操作頁(yè)面 B。如果用的是同一個(gè)瀏覽器實(shí)例兩個(gè)并發(fā)任務(wù)會(huì)爭(zhēng)搶標(biāo)簽頁(yè)、爭(zhēng)搶 CPU 計(jì)算、爭(zhēng)搶網(wǎng)絡(luò)帶寬嚴(yán)重時(shí)直接導(dǎo)致操作互相踩踏。我建議的架構(gòu)是瀏覽器實(shí)例池。把每個(gè) Agent 任務(wù)綁定到獨(dú)立的瀏覽器上下文可以理解為隱身會(huì)話空間任務(wù)之間物理隔離。如果機(jī)器資源不允許開(kāi)太多瀏覽器實(shí)例那就回到調(diào)度層的串行隊(duì)列——同一時(shí)刻只允許一個(gè)任務(wù)持有某個(gè)頁(yè)面組的操作權(quán)。注意瀏覽器實(shí)例池不是簡(jiǎn)單的多開(kāi)窗口。它需要和 WebMCP 的會(huì)話綁定配合實(shí)例 A 里的頁(yè)面授權(quán)、Cookie、IndexedDB 完全隔離于實(shí)例 B。這樣不僅減少爭(zhēng)搶還順便解決了敏感數(shù)據(jù)串號(hào)的問(wèn)題。缺點(diǎn)是多實(shí)例占用內(nèi)存所以在低配機(jī)器上我通常建議并發(fā)任務(wù)數(shù)小于 4 用實(shí)例池大于 4 上隊(duì)列不要讓 Agent 插件模式把所有任務(wù)硬塞進(jìn)一個(gè)瀏覽器。6. 真要上生產(chǎn)我建議你先盯緊這幾條底線6.1 最小權(quán)限不是口號(hào)是落地的配置項(xiàng)WebMCP 把瀏覽器能力開(kāi)放給 Agent本質(zhì)上等于把用戶的操作權(quán)交給了程序。如果你不做權(quán)限約束Agent 能訪問(wèn)任何授權(quán)站點(diǎn)的任何數(shù)據(jù)、執(zhí)行任何操作那隱患比人工操作還大——因?yàn)槌绦蚩梢詿o(wú)限次、極快地執(zhí)行。所以最小權(quán)限原則必須作為系統(tǒng)配置項(xiàng)存在而不是寫進(jìn)需求文檔的一句話。具體落地參考如下按站點(diǎn)分策略每個(gè)域名的默認(rèn)權(quán)限是“禁止”。按動(dòng)作分級(jí)別讀、寫、高敏感三層分別配置。按用戶分范圍普通用戶只能讓 Agent 操作其自身可訪問(wèn)的頁(yè)面。按時(shí)間窗口限制比如下班后只允許只讀操作不允許寫入。這套配置看起來(lái)很繁瑣但我可以說(shuō)一個(gè)真實(shí)案例。我見(jiàn)過(guò)一個(gè)團(tuán)隊(duì)把 Agent 接到客戶管理系統(tǒng)沒(méi)有做分級(jí)Agent 拿到授權(quán)后一口氣給 500 個(gè)客戶群發(fā)了營(yíng)銷消息其中一半是催款內(nèi)容。這種事故一旦發(fā)生負(fù)責(zé)人很難向客戶交代。所以別嫌權(quán)限管理系統(tǒng)麻煩它本質(zhì)上是你避免事故的最后閘門。6.2 審計(jì)日志比 Agent 的推理過(guò)程更重要很多 Agent 項(xiàng)目一上來(lái)就關(guān)注大模型的推理鏈路恨不得把每一次思考都記錄下來(lái)。但 WebMCP 場(chǎng)景不一樣你更需要的是操作事實(shí)的審計(jì)。我強(qiáng)烈建議在會(huì)話層記錄以下四類信息。第一是意圖快照Agent 每次下發(fā)的意圖操作原樣記錄下來(lái)。第二是執(zhí)行結(jié)果DOM 能力層的返回值成功還是失敗、返回了什么數(shù)據(jù)。第三是頁(yè)面前后快照關(guān)鍵操作前后的 DOM 狀態(tài)摘要或者截圖用于事后比對(duì)。第四是權(quán)限決策記錄為什么這次操作被允許走的是哪個(gè)授權(quán)規(guī)則。我一般會(huì)定期把審計(jì)日志拿去做回放分析。角色切換成“老刑警”模式先把日志按任務(wù) ID 分組再按操作時(shí)間排序看看不同任務(wù)執(zhí)行的路徑差異。這個(gè)方法在定位“某次自動(dòng)化事故到底是 Agent 規(guī)劃錯(cuò)了還是頁(yè)面狀態(tài)異?！睍r(shí)非常有用。沒(méi)有這套日志排查這類問(wèn)題就是大海撈針。6.3 操作回滾與熔斷機(jī)制讓 Agent 操作網(wǎng)頁(yè)必須接受一個(gè)現(xiàn)實(shí)任何自動(dòng)化都會(huì)出錯(cuò)。所以設(shè)計(jì)階段就要考慮“錯(cuò)了之后怎么收?qǐng)觥?。寫入類操作盡量做可逆或部分可逆。比如填表單在操作前快照表單所有字段的舊值提交前如果 Agent 發(fā)現(xiàn)某個(gè)環(huán)節(jié)異?？梢韵劝驯韱位謴?fù)原狀。這不難實(shí)現(xiàn)在能力文檔里加入snapshot和restore兩個(gè)工具即可。更底層的保障是熔斷。如果連續(xù)出現(xiàn)操作失敗比如連續(xù) 3 次 DOM 能力盤點(diǎn)失敗、連續(xù) 2 次表單校驗(yàn)失敗調(diào)度層必須停止繼續(xù)下發(fā)新操作并把控制權(quán)交回給 Agent 或人工。不要指望 Agent 自己發(fā)現(xiàn)問(wèn)題它的長(zhǎng)鏈路推理里很容易把異常當(dāng)作新任務(wù)處理一路走偏。熔斷機(jī)制是系統(tǒng)層面的“剎車”。高敏感操作的回滾比較復(fù)雜。比如“刪除一條記錄”基本不可逆。這種操作在核心流程里建議不要給 Agent 完全自動(dòng)執(zhí)行的權(quán)限一定要加人工審批節(jié)點(diǎn)。寧可操作慢一步也比事后補(bǔ)救強(qiáng)十倍。6.4 灰度上線讓 Agent 先在仿真環(huán)境跑最后一個(gè)底線是灰度驗(yàn)證。不要讓 Agent 直接連接生產(chǎn)站點(diǎn)尤其是剛接入 WebMCP 的初期。在內(nèi)部項(xiàng)目里我會(huì)先搭一套仿真環(huán)境把生產(chǎn)頁(yè)面完整復(fù)制一份連后端接口都 Mock 掉。Agent 先在仿真環(huán)境跑通全流程確認(rèn)無(wú)誤后再切換到生產(chǎn)并且一開(kāi)始只開(kāi)放低頻、低風(fēng)險(xiǎn)的操作范圍。這個(gè)做法的好處有兩個(gè)。第一是排錯(cuò)安全Agent 在仿真環(huán)境里怎么折騰都不影響真實(shí)業(yè)務(wù)。第二是可用真實(shí)數(shù)據(jù)驗(yàn)證能力文檔的完整性仿真環(huán)境會(huì)有很多生產(chǎn)環(huán)境才有的極端頁(yè)面狀態(tài)比如某字段超長(zhǎng)、某元素重復(fù) IDAgent 在仿真環(huán)境暴露的問(wèn)題越多上線后的坑越少。灰度上線的節(jié)奏我一般這樣安排仿真環(huán)境全量測(cè)試通過(guò)后切到生產(chǎn)環(huán)境的一個(gè)測(cè)試賬號(hào)跑 3 到 5 天重點(diǎn)觀察審計(jì)日志里的異常比例。異常比例降到閾值以下才逐步開(kāi)放到部分真實(shí)用戶。這個(gè)過(guò)程不復(fù)雜但特別考驗(yàn)?zāi)托暮芏鄨F(tuán)隊(duì)在仿真環(huán)境剛跑通就急著全面放量結(jié)果第二天就被頁(yè)面改版打回原形。結(jié)尾我的實(shí)際體會(huì)和一個(gè)小建議最后聊點(diǎn)個(gè)人的體會(huì)。WebMCP 的價(jià)值不在于又多了一個(gè)新協(xié)議名詞而在于它把“網(wǎng)頁(yè)能力如何暴露給 Agent”這件事從每個(gè)團(tuán)隊(duì)各自為政變成了一套可復(fù)用、可審計(jì)、可組合的標(biāo)準(zhǔn)化思路。我實(shí)際跑下來(lái)最明顯的感受是當(dāng)網(wǎng)頁(yè)自己會(huì)“說(shuō)話”之后Agent 的開(kāi)發(fā)重心可以重新回到任務(wù)規(guī)劃和異常處理上而不是花費(fèi)大量的時(shí)間與某個(gè)按鈕的選擇器纏斗。你不再需要為一個(gè)頁(yè)面的改版而焦慮因?yàn)?WebMCP 層會(huì)重新盤點(diǎn)能力Agent 只不過(guò)換了一張新的能力清單。當(dāng)然它目前還遠(yuǎn)談不上完美權(quán)限模型、會(huì)話隔離、跨源 iframe 這些都是需要繼續(xù)打磨的地方也不適合所有場(chǎng)景。如果你準(zhǔn)備入局我建議從小站點(diǎn)、低頻的寫入類任務(wù)開(kāi)始驗(yàn)證這套思路先把安全性、審計(jì)、回滾這些底線工程做扎實(shí)再談大規(guī)模自動(dòng)化。這比急著做一個(gè)全自動(dòng)的“瀏覽器機(jī)器人”要靠譜得多。