最近在调试一个自动处理后台工单的 Agent我发现自己真正花时间的不是提示词也不是模型能力而是“让 Agent 和网页真正打交道”这一层。很多 Agent 看起来智能一旦要登录系统、点按钮、翻表格立刻变得笨拙——要么给网站单独写接口要么靠截图做视觉猜测要么用一套脆弱的 CSS 选择器硬撑。直到我把浏览器这一层按 WebMCP 的思路重新整理了一遍才体会到什么叫“浏览器原生”的交互方式。这篇文章不是某个官方文档的翻译而是我在实际项目里围绕 WebMCP、AI Agent、浏览器原生交互做的一次系统踩点和总结。适合正在做 Agent 产品、内网办公自动化、网页数据运营的人读读完能少走很多弯路。1. Agent 卡在“浏览器之外”WebMCP 要填的坑到底是什么1.1 现在主流的网页交互方案各有什么死穴先说清楚 WebMCP 为什么值得聊。过去一年我见过太多 Agent 项目架构图上画得很漂亮大模型做规划、向量库做记忆、工具层接了一堆 API看起来无所不能。但只要落到真实业务第一个卡住的地方永远是网页操作。目前主流做法基本是四条路线各自的痛点都很明显。第一条路线是 API 优先。让网站方提供官方接口Agent 直接调用。这条路线最干净但现实很骨感内部老系统没有 API第三方后台不开放 API就算有 API字段含义和权限模型也未必跟页面操作对得上。我接过一个项目客户坚持说“我们有 API”结果一查API 只能查数据不能提交表单最终还是要回到页面操作。第二条路线是爬虫加选择器解析。写一堆 XPath、CSS 选择器去抓取页面数据。缺点是极其脆弱页面结构只要微调选择器就崩而且很多站点有反爬策略维护成本不亚于写一个独立应用。关键在于爬虫抓到的是静态 HTML对页面交互点击、拖拽、弹窗几乎无能为力。第三条路线是视觉方案。截屏把图片丢给多模态大模型让模型看图识别按钮并给出坐标。优点是适应性强缺点也同样明显截图有延迟、Token 成本高、坐标精度不稳定遇到动态加载的内容经常翻车。实测下来视觉方案适合做兜底和校验不适合做主力操作路径。第四条路线是浏览器自动化脚本比如 Selenium、Playwright 这一派。脚本本身很成熟稳定性也不错。但问题在于这些工具强调的是“脚本执行命令”不是“让 Agent 理解页面”。你需要为每一次操作编写独立逻辑——等待某个元素、判断是否存在、处理弹窗——等于每个站点都要定制开发一套驱动程序。代码量巨大且不可通用。你把这四条路线摆在一起看会发现一个共同死穴没有任何一个标准协议让浏览器主动向 Agent 声明“我能干什么、现在是什么状态”。所有方案都是 Agent 在外部猜而不是浏览器在内部提供能力。WebMCP 想解决的正是这个问题。1.2 “浏览器原生”到底意味着什么WebMCP可以拆成 Web 加 MCP。MCP 是 Model Context Protocol 的缩写核心思路是把“模型需要的外部能力”标准化成一套协议。好比电脑上的 USB-C 接口不管接的是显示器、硬盘还是充电器接口形态统一了设备之间就能即插即用。WebMCP 就是把这套协议搬进浏览器环境。更直白一点浏览器不再只是一个被操作的对象而成为 MCP 的宿主运行时。网页本身可以作为一个“能力端点”存在主动暴露自己的表单字段、按钮、列表状态、加载状态Agent 通过标准化的协议去发现这些能力并调用它们。我用一个生活化的类比。传统做法是你想让一个人帮你操作一台老旧仪器你得先写一份极其详细的操作手册告诉他哪个旋钮在哪儿、怎么拧、拧到什么位置。WebMCP 的做法是这台仪器自己贴了一张标签上面写着“我有三个旋钮、两个按钮、一个显示屏支持以下操作”操作员看一眼标签就能开工而且换一台仪器只要标签写得规范操作员几乎不用重新学习。所以所谓“浏览器原生”交互核心就三点能力可发现、操作可标准化、状态可感知。页面自己把底牌亮出来Agent 按统一规则来打这就是与之前所有方案的分水岭。1.3 谁最需要它结合我接触到的需求方下面这几类人最应该关注 WebMCP。做内部办公自动化 Agent 的团队。ERP、CRM、工单系统这类老后台普遍没有开放接口但业务流程又必须走页面。WebMCP 能把这些页面变成可以被 Agent 调度的“虚拟 API”自动化程度直接上一个台阶。做垂直场景助手的开发者。比如让 Agent 帮用户查物流、比价、填表单、管理后台内容。有了标准化协议你不用为每个网站单独写适配器开发效率提升是数量级的。做浏览器插件产品的团队。很多插件本质上就是在替用户操作网页之前只能靠内容脚本硬编码逻辑现在可以让插件成为一个 MCP 网关把页面能力开放给上层 Agent。另外还有一类做 RPA 改造的公司。传统 RPA 靠录屏和选择器绑定遇到页面改版就废。WebMCP 这种语义化、意图化的思路恰好补上了 RPA 在“页面理解”上的短板。2. 从 MCP 到 WebMCP三个关键设计让浏览器变成 Agent 的“原生环境”2.1 先回顾 MCP 的三件套约定在深入 WebMCP 之前得先把 MCP 的基础约定说清楚否则后面全是空中楼阁。MCP 的设计很简洁它定义了三种核心原语。第一是 Tools代表动作能力。比如“查询天气”“创建订单”“提交表单”每个 Tool 有自己的输入参数和输出格式。Agent 通过调用 Tool 完成具体操作类似函数调用。第二是 Resources代表数据资源。比如“用户信息”“商品详情”“页面上的表单字段列表”。Resources 是只读的Agent 先从 Resources 里获取上下文再决定调用哪些 Tools。第三是 Prompts代表可复用的提示模板。用于把常见任务固化成模板减少 Agent 的规划负担。MCP 的设计哲学很像给 AI 界的各种模型和工具之间做了一套通用的“插线板”。你不需要针对每个模型写一套工具适配代码只要工具侧实现了 MCP 协议任何兼容的模型都能直接调用。WebMCP 沿用了这套三件套但把实现环境放在了浏览器里。这带来一个关键转变传统的 MCP 工具通常是外挂在应用之外的比如一个 Python 服务去调数据库而 WebMCP 的工具和资源是网页元素本身。按钮、输入框、下拉菜单、列表、分页器在 WebMCP 的视角下都是可以被声明和暴露的“原生资源”。2.2 关键设计一页面即端点Page as Endpoint这是我认为 WebMCP 最核心的设计理念。传统的浏览器自动化里页面只是一个被遥控的目标脚本在外面操作它。而 WebMCP 把每个页面看作一个 MCP 端点Endpoint页面自己负责向 Agent 描述自身的能力。具体怎么做以 Chromium 系浏览器为例通过扩展或者注入脚本在页面加载完成后做一次“能力盘点”。盘点内容包括表单字段有哪些、可见按钮有哪些、当前处于什么加载状态、有无弹窗或错误提示。然后生成一份结构化的描述文档相当于页面的“能力名片”。这份描述文档不是随便生成的它要遵循统一的 schema。比如一个表单字段会记录它的语义 ID、类型文本、日期、下拉、当前值、是否必填、关联的校验规则。Agent 拿到这份文档不需要自己猜测页面上有什么直接按图索骥即可。我把这个设计叫“页面即端点”是因为它彻底改变了能力的归属关系。之前是“Agent 想办法去够页面”现在是“页面主动把手伸给 Agent”。别小看这个反转它带来的直接好处是通用性。只要每个页面都实现了这套端点化描述Agent 面对任何一个站点都不再是“盲人摸象”而是先看名片再办事。2.3 关键设计二从“坐标点击”到“意图操作”传统浏览器自动化最常见的毁誉参半的点就是依赖坐标或选择器。比如“点击页面坐标 (x, y)”或“点击 #submit-btn”。坐标的问题很明显页面窗口大小一变、布局一变坐标就废了。选择器的问题也很明显前端重构一下 class 名脚本直接崩溃。WebMCP 的思路是切换到“意图操作”。Agent 告诉浏览器“我要提交这个表单”“我要把发货状态切换到已完成”而不是“我要点坐标为 (320, 480) 的地方”。浏览器侧收到意图后自己去找对应的元素、判断是否可交互、执行操作并返回结果。这就好比你和人打交道你不会说“请把你的右手食指抬高 5 厘米指向那个红色按钮”你会说“请按一下左边的红色按钮”。意图操作的价值在于它把“如何定位元素”这件事留给了浏览器侧而 Agent 只关心“我想达成什么效果”。页面前端再怎么改版只要功能语义不变Agent 的任务定义就不用变。在我自己的测试里这个设计的实际收益非常明显。之前用 Playwright 写一套后台自动化页面改版后往往要改几个小时的选择器。改用意图化描述后大多数情况下只需要重新生成一次能力文档Agent 侧的任务定义几乎不动。2.4 关键设计三会话绑定与上下文黏性还有一个容易被忽略、但实际使用中极其重要的设计会话绑定。Agent 操作网页天然涉及多轮交互。你要先登录然后跳到某个菜单再填写查询条件最后点击搜索并读取结果。这个过程里状态是连续的。如果每次操作都当作独立的无状态请求就完了。WebMCP 借用浏览器的天然能力来解决这个问题。Cookie、IndexedDB、LocalStorage 这些浏览器本地状态天然就是会话的载体。WebMCP 会为每个任务创建绑定到特定标签页的会话上下文Agent 的操作始终在这个上下文里执行。更近一步跨标签页的时候也能保持住“会话黏性”。比如任务需要同时参考两个页面的数据WebMCP 可以给两个标签页的会话挂上同一个任务 ID。这样即使 Agent 在页面 A 登录了切换到页面 B 时登录态依然能通过共享的浏览器上下文被感知不需要重复认证。这个设计也带来了一个严肃的问题会话安全。一个 Agent 可能同时处理多个任务如果会话上下文串了任务 A 的操作跑到任务 B 的页面里后果不堪设想。所以 WebMCP 的会话绑定通常会做严格隔离每个任务一个独立会话空间并且配合用户授权机制。3. WebMCP 落地的模块拆分扩展层、桥接层与 DOM 能力层怎么协同3.1 建议的四层架构参考聊完理念来点实际的。如果你要在自己项目里落地 WebMCP建议按下面这个四层架构来拆。这个架构不是严格标准而是我结合几个实践项目总结的相对省力的组织方式。第一层浏览器扩展层。它负责三件事识别需要注入的页面、管理用户授权、维护 WebMCP 端点生命周期。没有这一层后面的能力层根本没有入口。扩展层要在页面加载前就准备好运行时并且要处理用户对哪些站点授权、哪些站点拒绝的决策逻辑。第二层协议桥接层。这是最容易被低估的一层。它负责把浏览器侧发生的“原生事件”比如表单值变化、点击、页面跳转、请求失败翻译成 MCP 协议格式的消息同时把 Agent 发来的 MCP 请求翻译回浏览器侧的 DOM 操作。相当于一个翻译官。第三层DOM 能力层。这一层负责生成“能力文档”并执行指令。具体来说就是遍历 DOM 树抽取可交互元素和相关状态生成结构化的资源描述同时实现“意图操作”的执行——Agent 说要提交表单这层去定位、校验、点击、等待回执。第四层调度与会话层。它管多任务并发、标签页归属、会话隔离、超时重试。如果一个 Agent 同时处理两个任务分别操作两个标签页调度层必须保证两边互不干扰。四层之间可以理解为这样的协作关系会话层接到任务询问扩展层哪个页面被授权了然后通过桥接层与 DOM 能力层沟通DOM 能力层再返回操作结果桥接层把结果格式化最终会话层把结果交给 Agent 决策。层级主要职责典型实现要点浏览器扩展层注入、授权、生命周期manifest 配置、站点白名单、运行时清理协议桥接层事件双向翻译、协议格式化MCP 消息编解码、错误映射、重试逻辑DOM 能力层能力盘点、意图执行语义 ID 抽取、元素定位、状态检测调度与会话层并发控制、会话隔离任务 ID 绑定、标签页映射、超时熔断3.2 一次完整任务交互的时序展开纸上谈兵没有用我把一次真实任务的完整时序拆出来。假设用户对 Agent 说“把后台里上个月的异常订单导出来按金额倒序生成一个表格”。第一步Agent 的任务规划层拆分出多个子任务打开后台、登录如果未登录、进入订单列表、筛选日期、导出数据。第二步调度层检查现有的会话发现没有对应后台的授权于是提示用户授权。用户同意后扩展层在目标站点页面注入 WebMCP 运行时。第三步扩展层通知 DOM 能力层做一次能力盘点生成该页面的能力文档。文档里记录了当前页面有登录表单、登录按钮、输入框等。第四步Agent 下发意图操作“填充登录表单并提交”。桥接层翻译请求DOM 能力层执行返回登录成功或失败的状态。第五步登录成功后DOM 能力层重新盘点页面能力因为登录后的页面和登录前的页面完全是两个状态。Agent 根据新的能力文档继续规划点击“订单管理”、输入筛选条件、点击导出。第六步所有操作完成后结果数据回传会话层把任务标记为完成并清理不再需要的临时状态。这个时序里最值得注意的一点是每次页面状态变化后都必须重新做能力盘点。很多初次实现 WebMCP 的人习惯在页面加载时只盘点一次后面就一直用旧文档。结果就是 Agent 以为页面上还有登录按钮实际上已经在订单列表页了直接原地出错。我反复强调能力文档是快照不是永久档案页面一变快照就必须刷新。3.3 状态持久化的细节处理状态持久化是个不显眼但绕不开的问题。Agent 在页面上操作产生的状态散落在各处登录态在 Cookie 里、筛选条件在页面内存里、表格排序在 UI 状态里、临时数据在 JS 变量里。WebMCP 的实践经验是按层级分层持久化。第一层是浏览器原生状态比如 Cookie 和 IndexedDB托管给浏览器本身Agent 不用管。第二层是页面交互产生的临时状态比如一个没提交的表单内容DOM 能力层需要维护一份内存映射并且在页面刷新后能恢复能恢复则恢复不能恢复就明确告诉 Agent 需要重新操作。第三层是 Agent 侧的会话记录也就是每一轮操作的历史、操作前后的页面快照这部分要持久化到后端形成审计链路。我在项目里踩过一个大坑Agent 填了一半表单网络闪断页面刷新填的内容全没了。之前没有“恢复草稿”机制Agent 完全意识不到自己丢了多少状态直接进入下一步操作结果把空表单提交了。后来我在 DOM 能力层加了一个“表单草稿快照”每填一个字段就同步一份到会话存储。恢复后Agent 先比对快照发现缺失字段就重新填才算解决了这个问题。4. 跑通一个最小 WebMCP 项目让 Agent 真正操作一个网页表单4.1 建立环境和目标理论说太多容易飘还是动手跑个最小项目。这里的目标是用本地服务起两个页面一个表单页一个结果页让 Agent 通过 WebMCP 的简化实现来自动填写表单并提交验证核心链路能通。这个项目不需要完整实现标准 MCP 协议重点是跑通“能力盘点 意图操作 会话绑定”的主链路我已经用这种方式在一个内部项目里验证过整个思路的可行性。环境准备如下。一台装有 Chromium 系浏览器的电脑Chrome 或 Edge 均可打开开发者模式准备一个临时扩展。本地起一个简单的静态服务比如 npx serve 或者任意静态服务器。表单页用 demo-form.html结果页用 demo-result.html。Agent 侧的调用用简单的 Node 脚本加 fetch 请求模拟不走完整实现但保留协议结构。你不需要任何云服务全部本地跑通。整个过程大概半小时能完成。4.2 扩展侧的核心代码第一步是创建一个最小 Chrome 扩展。目录结构简单点manifest.json 加 content.js 就够。manifest 需要声明 content script 匹配本地页面并允许访问页面 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 里做一个极简的 WebMCP 运行时。页面加载完成后盘点当前表单字段生成能力文档并暴露一个本地接口供 Agent 侧调用。// content.js —— 简化版把当前页面当作 MCP 端点 (function registerEndpoint() { // 1. 能力盘点扫描表单字段和按钮 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. 暴露给外部通过 window 上挂一个全局对象方便 Agent 侧调用 window.__localMCPBridge__ { scanCapabilities, fillField, submitForm, sessionId: demo-session-local }; console.log([WebMCP] endpoint registered for:, location.href); })();这个示例里的 dispatchEvent 很重要很多前端框架比如 React监听的是合成事件直接赋值 el.value 不会触发框架的 onChange必须补一个 input 事件否则表单数据不会被框架捕获。4.3 Agent 侧调用链路扩展准备好后表单页加载时会自动注入运行时。现在写 Agent 侧的调用脚本。这里用 Node 的 fetch 来模拟 Agent 发送 MCP 风格请求。// agent-simulator.js —— 用 fetch 模拟 Agent 的 MCP 调用 const endpoint http://127.0.0.1:9222/mcp; // 实际生产环境会通过调试协议或扩展桥接 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. 盘点页面能力 const caps await scan(http://127.0.0.1:3000/demo-form.html); console.log(页面能力清单:, caps); // 2. 填充字段 const fillRes await fetch(${endpoint}/tool, { method: POST, headers, body: JSON.stringify({ tool: form.fill, input: { fieldId: name, value: 测试订单-202401 }, sessionId: demo-session-local }) }); console.log(填充结果:, 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(提交结果:, await submitRes.json()); } runTask().catch(console.error);这个脚本里的 URL 和接口路径是我为了演示定义的真正生产环境会统一走远程 MCP 端点或者通过扩展的消息通道。但结构不需要变先盘点能力再调用工具再拿结果。如果你把目标 URL 换成任意一个授权过的页面只要页面里实现了 WebMCP 运行时链路就是一样的。4.4 验证结果和最先遇到的坑启动本地服务、加载扩展、运行 agent-simulator.js正常情况会看到控制台依次输出能力清单、填充结果、提交结果。提交成功后浏览器自动跳到 demo-result.html页面显示“收到订单测试订单-202401”。跑通之后有四个高频坑你几乎一定会遇到。第一个坑content script 注入时机。如果 run_at 是 document_idle页面主框架还在加载时可能拿不到完整 DOM。解决办法是加上run_at: document_start并在 DOMContentLoaded 后再盘点或者用 MutationObserver 监听页面变化。第二个坑input 事件没触发。前面提过React 和 Vue 这类框架对原生事件有封装填充 value 后必须手动派发事件否则组件内部状态没更新。第三个坑表单校验拦截。很多表单有前端校验如果 Agent 填的值不满足校验规则表单根本提交不出去。DOM 能力层必须在提交前调用 form.checkValidity()把校验失败信息返回给 Agent让它重新填。第四个坑页面跳转导致脚本失效。表单提交后页面跳转content script 在新页面会重新注入但 Agent 可能还抱着旧会话 ID。所以会话层要监听页面跳转事件自动切换新的能力文档而不是硬闯。以我的经验这四个坑里最伤的是第二个因为它不会直接报错而是表现为“填了值但提交后数据是空的”排查起来非常迷惑。建议从现在开始凡是实现浏览器侧填充逻辑一律补 input 事件。5. 实测里最折磨人的五个问题会话漂移、DOM 漂移与误触拦截5.1 DOM 漂移SPA 和懒加载的频繁偷袭我在第 3 章提过能力文档要及时刷新实际操作中DOM 漂移是最大频率翻车点。尤其是单页应用SPA它不会整页刷新而是通过 JS 重写局部 DOM比如点击 Tab 切换面板。如果 Agent 用的是旧能力文档它看到的字段可能已经全部移除了。更隐蔽的是懒加载。很多列表页在滚动到底部时才加载更多数据项加载前页面上根本没有这些元素。Agent 想采集全部数据结果只读到第一屏。对策分两层。DOM 能力层要做“温和重扫”每次意图操作执行前都检查当前 DOM 与能力文档的差异如果关键元素列表变化超过阈值就重新生成文档并警告 Agent。调度层要做“时机感知”对于懒加载场景Agent 下发滚动操作后要等待一段时间让数据加载完成而不是立刻采集。我看过很多团队在 DOM 漂移上死磕选择器方向就偏了。这问题的本质是页面是动态的所以方案也必须是动态的——能力文档不是一次生成永久使用而是伴随页面状态变化的增量化快照。5.2 多标签页的会话归属错乱当 Agent 同时处理多个任务时最容易出现的诡异问题是任务 A 的 Agent 调了一个 form.fill结果表单出现在任务 B 的标签页里。根因是会话 ID 没有和具体标签页的顶层执行上下文绑定。我的解决方案是给会话 ID 增加层级任务ID:标签页ID:执行上下文ID。任务 ID 标识一次用户请求标签页 ID 标识具体浏览器 Tab执行上下文 ID 标识页面里的一个 iframe 或 Shadow DOM 分区。每层独立层层校验。还有一个很现实的坑标签页可能被用户手动关闭。Agent 还在往这个会话发请求结果发现目标页面没了。调度层必须监听标签页关闭事件发现会话绑定的标签页不存在时立即标记会话异常让 Agent 决定是重新打开页面还是转人工。5.3 权限确认的误触用户被问太多次就点到“一律允许”WebMCP 涉及浏览器操作必然要引入权限确认机制。但这里存在一个产品层面的两难每次操作都弹窗确认用户嫌烦Agent 效率也低完全不确认风险大得没法接受。我在实践中的折中方案是分级授权。按操作类型分三级第一级是只读操作比如读取页面数据配置好站点白名单后不再弹窗第二级是写入操作比如填表单、点击提交弹窗确认但记住站点级偏好第三级是高敏感操作比如转账、删除、发送消息必须每次单独确认并且确认按钮要有冷却时间。这个分级的实现并不复杂但在体验和安全的平衡上很有价值。用户会逐渐形成信任只读和常规写入不用管高敏感操作始终被保护。如果你不做分级一股脑全弹窗用户很快就会不耐烦地点“一律允许”权限防线等于崩溃。5.4 iframe 与 Shadow DOM 的“黑盒”问题真实的后台系统里iframe 嵌套是常态特别是老企业内部系统。而 Shadow DOM 则是现代前端组件库比如 Web Components的常见产物。这两个东西对 WebMCP 的直接威胁是主文档 DOM 能力层巡视不到它们。iframe 的问题在于跨源限制。如果 iframe 和主页面同源可以直接递归遍历如果跨源就不能直接操作其内部 DOM必须通过浏览器扩展的跨上下文机制或者 postMessage 桥接。Shadow DOM 的问题在于事件穿透和选择。普通 querySelector 无法穿透 Shadow DOM 边界必须使用选择器对 shadowRoot 进行递归匹配。对策就是一条DOM 能力层必须同时处理三种容器顶层 document、iframe document、Shadow root。并且在能力文档里显式标注每个元素的容器归属和来源 origin。Agent 看到的是统一抽象但真正执行时由能力层按归属路由到对应容器。5.5 并发任务时的浏览器资源争抢最后一个高频问题是并发。Agent 不是单线程思考它可能在等待页面 A 的接口响应时同时去操作页面 B。如果用的是同一个浏览器实例两个并发任务会争抢标签页、争抢 CPU 计算、争抢网络带宽严重时直接导致操作互相踩踏。我建议的架构是浏览器实例池。把每个 Agent 任务绑定到独立的浏览器上下文可以理解为隐身会话空间任务之间物理隔离。如果机器资源不允许开太多浏览器实例那就回到调度层的串行队列——同一时刻只允许一个任务持有某个页面组的操作权。注意浏览器实例池不是简单的多开窗口。它需要和 WebMCP 的会话绑定配合实例 A 里的页面授权、Cookie、IndexedDB 完全隔离于实例 B。这样不仅减少争抢还顺便解决了敏感数据串号的问题。缺点是多实例占用内存所以在低配机器上我通常建议并发任务数小于 4 用实例池大于 4 上队列不要让 Agent 插件模式把所有任务硬塞进一个浏览器。6. 真要上生产我建议你先盯紧这几条底线6.1 最小权限不是口号是落地的配置项WebMCP 把浏览器能力开放给 Agent本质上等于把用户的操作权交给了程序。如果你不做权限约束Agent 能访问任何授权站点的任何数据、执行任何操作那隐患比人工操作还大——因为程序可以无限次、极快地执行。所以最小权限原则必须作为系统配置项存在而不是写进需求文档的一句话。具体落地参考如下按站点分策略每个域名的默认权限是“禁止”。按动作分级别读、写、高敏感三层分别配置。按用户分范围普通用户只能让 Agent 操作其自身可访问的页面。按时间窗口限制比如下班后只允许只读操作不允许写入。这套配置看起来很繁琐但我可以说一个真实案例。我见过一个团队把 Agent 接到客户管理系统没有做分级Agent 拿到授权后一口气给 500 个客户群发了营销消息其中一半是催款内容。这种事故一旦发生负责人很难向客户交代。所以别嫌权限管理系统麻烦它本质上是你避免事故的最后闸门。6.2 审计日志比 Agent 的推理过程更重要很多 Agent 项目一上来就关注大模型的推理链路恨不得把每一次思考都记录下来。但 WebMCP 场景不一样你更需要的是操作事实的审计。我强烈建议在会话层记录以下四类信息。第一是意图快照Agent 每次下发的意图操作原样记录下来。第二是执行结果DOM 能力层的返回值成功还是失败、返回了什么数据。第三是页面前后快照关键操作前后的 DOM 状态摘要或者截图用于事后比对。第四是权限决策记录为什么这次操作被允许走的是哪个授权规则。我一般会定期把审计日志拿去做回放分析。角色切换成“老刑警”模式先把日志按任务 ID 分组再按操作时间排序看看不同任务执行的路径差异。这个方法在定位“某次自动化事故到底是 Agent 规划错了还是页面状态异常”时非常有用。没有这套日志排查这类问题就是大海捞针。6.3 操作回滚与熔断机制让 Agent 操作网页必须接受一个现实任何自动化都会出错。所以设计阶段就要考虑“错了之后怎么收场”。写入类操作尽量做可逆或部分可逆。比如填表单在操作前快照表单所有字段的旧值提交前如果 Agent 发现某个环节异常可以先把表单恢复原状。这不难实现在能力文档里加入snapshot和restore两个工具即可。更底层的保障是熔断。如果连续出现操作失败比如连续 3 次 DOM 能力盘点失败、连续 2 次表单校验失败调度层必须停止继续下发新操作并把控制权交回给 Agent 或人工。不要指望 Agent 自己发现问题它的长链路推理里很容易把异常当作新任务处理一路走偏。熔断机制是系统层面的“刹车”。高敏感操作的回滚比较复杂。比如“删除一条记录”基本不可逆。这种操作在核心流程里建议不要给 Agent 完全自动执行的权限一定要加人工审批节点。宁可操作慢一步也比事后补救强十倍。6.4 灰度上线让 Agent 先在仿真环境跑最后一个底线是灰度验证。不要让 Agent 直接连接生产站点尤其是刚接入 WebMCP 的初期。在内部项目里我会先搭一套仿真环境把生产页面完整复制一份连后端接口都 Mock 掉。Agent 先在仿真环境跑通全流程确认无误后再切换到生产并且一开始只开放低频、低风险的操作范围。这个做法的好处有两个。第一是排错安全Agent 在仿真环境里怎么折腾都不影响真实业务。第二是可用真实数据验证能力文档的完整性仿真环境会有很多生产环境才有的极端页面状态比如某字段超长、某元素重复 IDAgent 在仿真环境暴露的问题越多上线后的坑越少。灰度上线的节奏我一般这样安排仿真环境全量测试通过后切到生产环境的一个测试账号跑 3 到 5 天重点观察审计日志里的异常比例。异常比例降到阈值以下才逐步开放到部分真实用户。这个过程不复杂但特别考验耐心很多团队在仿真环境刚跑通就急着全面放量结果第二天就被页面改版打回原形。结尾我的实际体会和一个小建议最后聊点个人的体会。WebMCP 的价值不在于又多了一个新协议名词而在于它把“网页能力如何暴露给 Agent”这件事从每个团队各自为政变成了一套可复用、可审计、可组合的标准化思路。我实际跑下来最明显的感受是当网页自己会“说话”之后Agent 的开发重心可以重新回到任务规划和异常处理上而不是花费大量的时间与某个按钮的选择器缠斗。你不再需要为一个页面的改版而焦虑因为 WebMCP 层会重新盘点能力Agent 只不过换了一张新的能力清单。当然它目前还远谈不上完美权限模型、会话隔离、跨源 iframe 这些都是需要继续打磨的地方也不适合所有场景。如果你准备入局我建议从小站点、低频的写入类任务开始验证这套思路先把安全性、审计、回滚这些底线工程做扎实再谈大规模自动化。这比急着做一个全自动的“浏览器机器人”要靠谱得多。