WebMCP：给 Agent 结构化工具而非爬取 DOM

如果你看过一个助手尝试预约名额、填写表单或通过猜测按钮位置来点击完成结账，你就已经知道它的失败模式了。助手会抓取 DOM、遍历无障碍树，或读取截图。这种方式脆弱、缓慢，一次重新设计就能轻易破坏它，而且在将不可信页面文本当作指令时容易受到 prompt 注入攻击。Sarah Drasner 的 WebMCP 演示直接陈述了另一种方案：给助手提供工具，而不是抓取 DOM。

WebMCP 是一个浏览器端的提案（W3C Web Machine Learning Community Group 草案），它让页面可以注册结构化的工具，供助手直接调用。如果你见过服务端 Model Context Protocol 工具，它的形态会让你感到熟悉：一个名称、一个描述、一个输入的 JSON Schema，以及一条执行路径。区别在于它的运行环境。契约存在于页面中、用户的源和会话内，通过 document.modelContext.registerTool 注册，而不是在你连接到 ChatGPT 或 Claude 的远程 MCP 服务器上。这个区别对产品团队很重要。我们之前关于 SaaS 服务端 MCP 和 MCP 与 REST API 对比的相关文章涵盖了后端和助手集成方面；下面的章节将介绍页面层面的契约，以及它如何与 Core Web Vitals 和实验室监控产生交集。

当助手停止抓取 DOM 时，WebMCP 工具替代了什么

抓取是让助手去反向工程你的 UI。WebMCP 则是让你的站点声明它能做什么。在命令式路径中，JavaScript 通过 schema 和执行函数注册诸如 getAvailability 或 bookSlot 这样的工具。在声明式路径中，一个表单可以用 toolname 和 toolparamdescription 这样的属性来暴露同样的能力，让预订流程成为一个工具，而无需单独的注册脚本。浏览器（或如今的 WebMCP 感知扩展）收集这些工具，并在源作用域和权限仍在控制中的前提下，将它们呈现给用户的助手。

结构化的参数取代了"找到日期字段，然后找提交按钮，然后希望布局没有偏移"这种做法。助手根据契约提供日期、时间、姓名和电子邮件；你的代码来完成预订。你消耗更少的 token，看到更少的错误点击，并且比将整个 DOM 当作可读指令文本时保持更清晰的安全边界。这个提案仍处于早期阶段（Chrome 已运行了 origin-trial 风格的支持；API 名称已经从 navigator.modelContext 迁移到 document.modelContext 一次），所以对待生产级采用要视为谨慎的研究，而不是要求本季度重写每个表单的强制令。

为什么对于使用 WebMCP 的代理浏览来说 CLS 仍然很重要

即使工具存在， fallback 到 UI 定位的助手仍然关心几何形状。Lighthouse 的实验性 Agentic Browsing 工作已经因此点名了 Cumulative Layout Shift：如果广告、延迟加载的图片或注入的横幅在"识别控件"和"激活它"之间移动了布局，动作就会失败。WebMCP 减少了助手需要对声明式操作进行坐标猜测的频率，但它没有消除 CLS 作为产品风险的存在。人类仍然在看页面，fallback 路径和不完整的工具覆盖仍然在抓取，延迟的布局偏移在这两种情况下都会破坏信任。

发布更清晰的工具契约，在助手应该采取行动的地方。继续保持将 CLS 预算作为人类和任何仍使用视觉树的自动化的稳定性要求。不要认为绿色的 WebMCP 注册列表意味着你可以忽略转化 URL 上的字段 CLS。根据我们的经验，那些只演示工具注册而跳过布局稳定性的团队，在营销横幅延迟加载后的第一次就会重新发现抓取路径。

页面 WebMCP 与服务端 MCP 与单一 Lighthouse Agentic Browsing 运行

服务端 MCP（助手集成模式）是关于为 ChatGPT、Claude 或类似产品提供对你产品数据和动作的安全、有作用域的访问，通过你的后端拥有的协议。页面 WebMCP 是关于在用户访问该文档时声明这个文档能做什么。混淆两者会导致错误的路线图：你要么在助手需要认证 API 时在页面工具上花费 sprint 时间，要么跳过页面契约并让助手无限期地抓取预订小组件。

实验室审计是第三个关注点。Chrome 的 Lighthouse Agentic Browsing 类别可以观察 WebMCP 注册和相关就绪检查，使用分数比例而不是熟悉的 0-100 性能组合。这是有用的健康检查。它与对客户感知的回归进行持续 PageSpeed 监控不同。我们在 Lighthouse Agentic Browsing 上解包了评分、审计和优先排序：如何在 Chatbot 监控的 Watcher 博客上排名。用那个指南来获取审计列表和评分模型；当你要决定是否在页面上暴露工具时，用上面的分割来思考。

点查 Lighthouse 运行仍然遭受与任何手动 PageSpeed 检查相同的调度问题。周二绿色的 Agentic Browsing 通过并不能证明在营销标签上线后的周四，注册的时机、CLS 趋势或工具 schema 仍然有效。关于为什么一旦新奇感消退，预定监控比偶尔的实验室截图更好，请参阅 PageSpeed Insights 与自动化监控。

代理如何在 WebMCP 普及之前准备好客户站点

你不需要每个浏览器明天都发布 WebMCP 才能开始准备。从助手最可能破坏的流程开始：预订、账户查询、简单商务操作和支持分流表单。对于每个流程，先在纸上写下工具契约：名称、描述、必填字段、只读与状态变更。那个练习本身就会暴露出只对能看到周围文案的人类才有意义的表单。

在你能够实验的地方（Canary、扩展或特性检测的 document.modelContext），注册一个只读发现工具和一个在明确确认背后的写工具。优先使用特性检测，这样不支持的浏览器会保持安静。保持 schema 严格；模糊的自由文本字段会在 JSON 内部重新创建抓取的歧义。将实验与你已经计费的 CLS 和无障碍工作配对：语义标签和稳定布局帮助人类、辅助技术，以及在任何工具缺失时仍然遍历树的任何助手。

Apogee Watcher 保持在 webperf 工作的监控侧。我们在客户组合中安排实验室和现场导向的 PageSpeed 检查，这样回归会在下次演示之前出现。WebMCP 和 Agentic Browsing 审计是你可以在浏览器支持扩展时添加到该计划的输入。它们不会取代 LCP、INP 和 CLS 的预算，也不会取代向客户清楚地解释你在测量什么的责任。

如何在不放弃 CLS 监控的情况下测试一个客户 URL 上的 WebMCP

用 WebMCP 感知的检查器打开 WebMCP 演示一次：计算工具数量，调用一个，故意破坏一个 schema，然后将那条路径与通过预订 UI 点击进行比较。然后选择一个客户转化 URL，决定下一个 sprint 是否应该暴露一个工具、修复会破坏 fallback 抓取的 CLS，或者两者兼有。在标准稳定之前，在客户报告中将实验室 Agentic Browsing 检查标记为实验性的。继续对已经预测用户痛苦的 Core Web Vitals 进行持续监控。

关于 Lighthouse Agentic Browsing 的审计级细节，从我们在代理浏览评分上的 Watcher 指南开始。如果你的团队仍然依赖偶尔的 PageSpeed Insights 粘贴，请阅读手动检查何时不够用，并为重要的 URL 设置调度和预算。将两者分层：使用 Watcher 进行持续 PageSpeed 历史，并将 WebMCP 加上 Agentic Browsing 审计视为可选的实验室健康检查，直到浏览器支持变得寻常。