WebMCP 综合指南

AI编程/Vibe Coding 遇到问题需要帮助的，联系微信 ezpoda，免费咨询。

机器人现在占网络流量的 51%。WebMCP 是网络对假装成人类的代理的回答

现在，在网络的某个地方，一个 AI 代理正盯着航班预订页面的屏幕截图。

它眯着眼睛看着像素，试图弄清楚哪个蓝色矩形是"搜索"按钮。

它找到了，点击它，等待页面重新加载，拍下另一个屏幕截图，然后开始整个荒谬的过程。

这是 2026 年初代理浏览的艺术状态。数十亿参数的模型假装成人类， 逐个像素， 逐个点。

就像看着有人通过向书法家描述每个字母的形状来口述一封信，当他们可以直接递交文本时。

2026 年 2 月 10 日，一个安静的早期预览登陆了 Chrome 145，开始改变这一点。它被称为 WebMCP，它为网站提供了一种直接与 AI 代理交谈的方式：没有屏幕截图，没有 DOM 抓取，没有猜测哪个元素做什么。

Oli 的视频没有超过一百万次观看这一事实告诉了我们很多。

WebMCP 公开在 JavaScript 或 HTML 中声明的结构化工具，代理可以像发现和调用 API 一样发现和调用它们。

规范还很年轻。 它是 W3C 社区组草案，不是标准。但在它后面坐拥来自微软和谷歌的编辑、一个拥有 530+ 星星且不断增长的 GitHub 存储库以及 Chrome 仍然占据统治地位的 66% 浏览器市场份额的分量。

这是一个关于 WebMCP 如何融入至少五个不同浏览器正在以非常不同的方式解决同一问题的格局的故事。

1、我们已经正常化的荒谬

让我们诚实地谈谈今天的"代理浏览"意味着什么。

一个 AI 代理想为你买一双跑鞋。实际上会发生什么：代理启动一个无头浏览器，导航到购物网站，渲染页面，拍下屏幕截图，将该屏幕截图发送到视觉模型，接收屏幕内容的描述，决定点击什么，发送点击命令，等待页面更新，并重复。

每一个交互。

我们构建了历史上最复杂的语言模型，我们却让它们像从移动车辆上的人一样阅读网站。

数字说明了故事。根据 Imperva 的 2025 年不良机器人报告，机器人流量现在占所有网络流量的 51%。Cloudflare 衡量的 AI 机器人流量增长 757% 同比。

你网站超过一半的访问者 不是人类。

你不会想知道在我们开启 Cloudflare AI 爬取控制之前我们的每月 WebFlow 账单是多少。

AI 访问者正在做一些极其浪费的事情：从视觉表示中重建结构化信息，一次一个像素。

并不是当前的方法不起作用。

它起作用，某种程度上。

OpenAI 的 Operator 可以预订餐厅。Perplexity 的 Comet 可以比较购物。开源的 browser-use 库，拥有 78K+ GitHub 星星，可以自动化令人印象深刻的复杂工作流程。

但它们都共享相同的核心限制：它们导航到为人类眼睛和人类手设计的界面。

脆弱性是真正的问题。更改按钮的颜色，移动表单字段，更新你的 CSS 框架——每个抓取你网站的代理都会崩溃。这是困扰网络抓取二十年的相同脆弱性，除了现在抓取工具得到风险投资支持并称自己为"代理。"

2、五个浏览器，五种哲学

在我们深入研究 WebMCP 的技术细节之前，了解它正在进入的格局会有所帮助。至少五个主要努力正在试图解决代理-浏览器问题，而且它们得出了完全不同的答案。

Perplexity Comet 于 2025 年 7 月作为完整的 AI 原生浏览器推出。它不是 Chrome 扩展或包装器；它是一个将代理功能内置到渲染引擎中的独立浏览器。Comet 的代理以人类的方式导航页面，使用视觉模型和 DOM 解析，但具有比附加解决方案更紧密的集成。

Dia，来自 The Browser Company（Arc 背后的人），采取了不同的道路。2024 年底预览并通过 2025 年进入测试版，Dia 将 AI 视为浏览体验的一等公民。它较少关于自主代理，更多关于 AI 增强的浏览。浏览器预测你需要什么并帮助你获得它。

谷歌 Disco 是一个外卡。2025 年 12 月从谷歌实验室出现在有限候补名单上，Disco 引入了"GenTabs"，AI 生成的迷你应用程序，作为浏览器选项卡出现。而不是导航到网站，AI 为你的任务生成一个专用界面。这是一个真正不同的赌注：如果代理根本不需要访问网站怎么办？

OpenAI Operator，2025 年 1 月 23 日推出，采用了云原生。它是在 OpenAI 基础设施中运行的浏览器代理，而不是在你的机器上。你描述你想要什么，Operator 在远程浏览器会话中代表你导航网络。它完全避免了本地浏览器问题，但引入了自己的关于隐私和控制的权衡。

然后还有 Atlas。

Chrome + WebMCP 是最新的进入者，并且在结构上最不同。它不构建一个更智能的代理来导航现有网站，而是提议更改网站本身。给页面一种声明其能力的方式，代理可以完全跳过导航。

前四种方法问："我们如何让代理更好地使用网站？"WebMCP 问："我们如何让网站更好地被代理使用？"

这是一个完全不同的问题，这就是为什么 WebMCP 很重要，即使它的采用还需要数年时间。

3、WebMCP 实际上是什么

让我们从技术角度探讨。

WebMCP 是一个浏览器 API，允许网页注册工具。想想结构化的、类型化的函数，AI 代理可以发现并直接调用。

如果你与 Anthropic 于 2024 年 11 月宣布并后来捐赠给 Linux 基金会的模型上下文协议（MCP）合作过，WebMCP 会感觉很熟悉。

规范自己的 README 说得很清楚：

"使用 WebMCP 的网页可以被视为在客户端脚本中实现工具而不是在后端实现的模型上下文协议（MCP）服务器。"

核心 API 位于 navigator.modelContext 上。这是命令式 JavaScript 方法：

navigator.modelContext.registerTool({
  name: "search_products",
  description: "搜索产品目录以查找项目",
  inputSchema: {
    type: "object",
    properties: {
      query: { type: "string", description: "产品名称或类别" }
    },
    required: ["query"]
  },
  execute: async ({ query }) => {
    const results = await fetch(`/api/search?q=${encodeURIComponent(query)}`);
    return await results.json();
  }
});

基本上就是这样。一个名称、一个描述、一个用于输入的 JSON Schema，以及一个执行函数。当 AI 代理访问你的页面时，它可以发现这个工具，理解它做什么，并使用结构化参数调用它。

没有屏幕截图。

没有像素解析。

没有猜测。

3.1 声明式方法

并不是每次交互都需要 JavaScript。WebMCP 还使用新属性扩展 HTML 表单：

<form toolname="search_products"
      tooldescription="搜索产品目录"
      toolautosubmit>
  <input name="query" type="text" placeholder="搜索产品..." />
  <button type="submit">搜索</button>
</form>

toolname 和 tooldescription 属性将普通 HTML 表单转换为可发现的工具。toolautosubmit 属性告诉浏览器，代理可以在不先询问用户的情况下提交此表单。如果没有该属性，浏览器会提示用户许可。（我们会回到为什么这很重要。）

3.2 知道谁在敲门

更聪明的设计决策之一是 SubmitEvent.agentInvoked。当表单提交来自 AI 代理而不是人类点击时，此属性为 true。你的服务器端代码可以区分两者：

form.addEventListener("submit", (event) => {
  if (event.agentInvoked {
    // 为代理返回结构化 JSON
    event.respondWith(
      fetch("/api/search?q=" + new FormData(form).get("query"))
        .then((res) => res.json())
    );
  }
  // 否则，为人类进行正常的表单提交
});

如果你与 Service Workers 合作过，event.respondWith(Promise) 模式看起来会很熟悉。它让你拦截提交并直接向模型返回结构化数据，而无需页面导航。

3.3 用于代理状态的 CSS

WebMCP 甚至引入了 CSS 伪类，:tool-form-active 和 :tool-submit-active，因此你可以在代理与之交互时对表单进行不同的样式。这是一个小细节，但它表明规范作者多么认真地考虑开发者体验。

WebMCP 不会替换你现有的网站。它注释它。你的表单仍然对人类有效。它们现在也对机器有效。

4、已经上演的屏幕抓取平行

如果这种从"代理抓取接口"到"代理调用结构化 API"的转变听起来很熟悉，它应该如此。我们以前见过这种完全相同的模式。

在金融科技。

在开放银行法规席卷英国和欧洲之前，像早期的 Mint 这样的个人金融应用程序通过屏幕抓取银行网站工作。你会移交你的银行凭据，应用程序会像你一样登录，导航页面，并从 HTML 中解析你的余额。它是脆弱的、不安全的，并且起作用。直到银行更改它们的布局、添加验证码，或者（理所当然地）阻止抓取工具。

开放银行要求银行公开结构化 API。而不是从网页抓取以找到你的余额，应用程序可以调用 GET /accounts/{id}/balance 并获得 JSON 响应。结果是相同的信息，可靠地、安全地传递，并经过账户持有人的明确同意。

WebMCP 正在为更广泛的网络提出相同的结构性转变。代理不再抓取你的购物网站，而是调用你注册的工具。代理不再从屏幕截图解析你的预订表单，而是使用类型化参数调用它。

从屏幕抓取到结构化 API 的转变并不新鲜。金融科技已经证明了这种模式。WebMCP 正在将其应用于整个网络。

但有一个关键区别。开放银行是由法规驱动的；政府迫使银行开放。WebMCP 是自愿的。没有人强迫网站所有者在其表单上添加 toolname 属性。这给我们带来了最困难的问题。

5、每个浏览器实际上在内部如何工作

这五种方法之间的哲学差异不仅仅是营销。它们反映了关于智能应该存在于哪里以及谁应该承担适应成本的真正不同的架构赌注。

结构化简化了代理 + 浏览器交互过程

5.1 基于视觉的导航（Comet、Operator、browser-use）

这些系统将网络视为视觉环境。代理看到人类看到的内容——渲染的像素——并使用视觉模型和 DOM 分析的组合来理解页面。

优势是普遍性。 基于视觉的代理可以在任何网站上工作，今天，无需网站做任何特殊的事情。缺点是其他一切：它很慢（每次交互有多个模型调用）、脆弱（布局更改会破坏它）、昂贵（视觉模型推断并不便宜），并且受限于屏幕上可见的内容。

Operator 通过在云端运行增加了一个有趣的转折。你的代理不需要本地计算，但你的浏览会话存在于 OpenAI 的服务器上。对于预订餐厅，这没问题。对于访问你公司的内部工具？对于大多数安全团队来说，这是一个非启动器。

5.2 AI 增强的浏览（Dia）

Dia 属于不同的类别。它较少关于自主代理完成任务，更多关于 AI 理解你的浏览上下文并提供帮助。将其视为自动驾驶汽车和非常好的 GPS 之间的区别。Dia 导航 与 你一起，而不是 为你。

可以说，这是近期采用的最务实方法，因为它不需要网站更改，也不需要用户信任完全自主的代理。但这同时也意味着 Dia 没有像其他人那样解决相同的问题。

5.3 生成式界面（Disco）

Disco 的 GenTabs 概念是最激进的偏离。如果 AI 可以为你的任务生成专用界面，为什么要导航到网站？需要比较航班？AI 生成一个作为浏览器选项卡的比较工具，从多个来源拉取数据。

理论上很吸引人，但它提出了关于数据新鲜度、准确性以及生成的界面与其代表的实际服务之间关系的难题。如果 AI 生成一个"航班预订"选项卡，当价格错误时谁负责？

5.4 结构化工具声明（WebMCP）

WebMCP 翻转了责任。

它不使代理更聪明，而是使网站更易读。

代理不需要理解你的页面布局。它只需要读取你的工具声明。

权衡很明显：它要求网站所有者做工作。但工作量是最小的：在现有表单上添加几个属性，或一个 JavaScript 调用来注册工具，突然它就变得渐进式了。

带有 WebMCP 注释的站点仍然对人类访问者完美工作。注释对任何不寻找它们的人都是不可见的。

6、鸡和蛋的问题

这就是乐观与现实相遇的地方。

WebMCP 只有在网站采用它时才有效。网站只有在代理使用它时才会采用它。代理只有在足够多的网站支持它时才会使用它。经典的鸡和蛋问题，而且它已经扼杀了比这个更好的规范。

但 WebMCP 作者对此并不天真。 该规范专为渐进式增强而设计：你可以将 WebMCP 注释添加到现有站点，而无需更改任何关于它如何为人类访问者工作的内容。没有迁移，没有重写，没有破坏性更改。你正在添加一个层，而不是替换一个。

而且我们已经看到网络平台在以前解决了这个完全相同的采用问题。

6.1 ARIA 平行

当 WAI-ARIA（Accessible Rich Internet Applications）被引入时，它面临着相同的挑战。为什么开发人员会在他们的 HTML 中添加 role="button" 和 aria-label 属性？大多数用户分辨不出区别。元素没有它们也能正常工作。

答案来自法律要求（无障碍诉讼）、工具支持（屏幕阅读器变得更擅长使用 ARIA）和文化转变（开发人员开始关心无障碍）的组合。它花费了数年，但 ARIA 现在是专业网络开发的标准组成部分。

很难错过这个平行：

"就像 ARIA 标签帮助屏幕阅读器理解页面一样，WebMCP 帮助 AI 代理理解能力。"

这是一个深思熟虑的框架，而且它在战略上是聪明的。ARIA 成功不是因为每个网站在一夜之间采用了它，而是因为价值主张随着时间的推移变得不可否认。

6.2 Service Worker 平行

Service Workers 面临着类似的采用曲线。当它们推出时，立即出现的问题是：当大多数用户在线时，为什么开发人员会添加离线支持？答案逐渐出现：推送通知、后台同步、渐进式 Web 应用程序。初始用例扩展成了一个生态系统。

WebMCP 可以遵循相同的轨迹。初始用例是"让代理与你的站点交互。"但底层能力——网站声明结构化工具——可能启用我们尚未想象的事情。理解你的页面能力的开发工具。可以在没有 UI 自动化的情况下练习你的站点功能的测试框架。可以通过其声明的工具而不是合成点击来检查你的站点健康状况的监控系统。

每个成功的网络标准都开始于一个鸡和蛋问题。那些幸存下来的标准提供了渐进式增强和随着时间的推移增长的价值主张。WebMCP 赌它可以两者都做到。

7、安全性和信任：谁控制代理？

如果你是一名正在阅读本文的网络开发人员，你的安全本能应该开始刺痛。一个允许 AI 代理调用你页面上的函数的浏览器 API？这听起来像是一个跨站脚本梦想。

规范作者已经考虑了这一点，对于这个早期的草案，安全模型是彻底的。

7.1 内容安全策略集成

WebMCP 引入了一个新的 CSP 指令：model-context-src。它的作用类似于现有的 CSP 指令；你声明哪些来源被允许注册工具，并且浏览器强制执行它。

Content-Security-Policy: model-context-src 'self' https://trusted-cdn.example.com

如果来自不受信任来源的脚本尝试调用 navigator.modelContext.registerTool()，浏览器会阻止它。这与今天防止恶意脚本注入的相同模式，扩展到覆盖工具注册。

7.2 权限提示

还记得表单上的 toolautosubmit 属性吗？如果没有它，浏览器会在代理提交表单之前提示用户。这会影响具有现实后果的操作；你不希望代理在没有你明确批准的情况下一键购买某些东西。

权限模型镜像我们对于地理位置、摄像头访问和通知已经拥有的东西。浏览器在代理和页面之间调解，用户保持控制。

7.3 同源策略

页面注册的工具限定为该页面的来源。在 shopping.example.com 上注册的工具不能由与 evil.example.com 交互的代理调用。这是保护网络数十年的同源策略，应用于新的表面。

7.4 真正的威胁格局

更困难的安全问题不是关于 API 本身；它们是关于代理使用它做什么。如果购物网站注册了一个 purchase_item 工具，并且代理代表你调用它，如果代理购买了错误的东西谁负责？如果银行网站公开了一个 transfer_funds 工具，当提示注入攻击欺骗代理调用它时会发生什么？

这些不是 WebMCP 特有的问题；它们是无论代理如何与站点交互都存在的代理信任问题。但 WebMCP 使它们更加可见，这可以说是一件好事。审计结构化工具调用比审计一系列像素级点击更容易。

8、开发人员需要适应

如果你今天正在为网络构建，这是一个实际问题：你应该关心 WebMCP 吗？

诚实的答案是：不紧急，但 很快。

该规范是一个社区组草案。它不在 W3C 标准跟踪上。Chrome 145 预览恰恰是：一个预览。事情会改变。API 会转变。但方向已经明确，而且有些事情现在值得做。

8.1 从你的表单开始

最低成本的 WebMCP 采用路径是声明式方法。如果你的站点上有表单，即搜索、筛选、联系、预订，只需添加 toolname 和 tooldescription 属性是微不足道的：

<!-- 之前：一个正常的搜索表单 -->
<form action="/search" method="GET">
  <input name="q" type="text" />
  <button type="submit">搜索</button>
</form>
​
<!-- 之后：相同的表单，现在代理可发现 -->
<form action="/search" method="GET"
      toolname="site_search"
      tooldescription="搜索此网站以查找文章、产品或帮助主题">
  <input name="q" type="text" />
  <button type="submit">搜索</button>
</form>

该表单仍然完全相同地为人类访问者工作。不支持 WebMCP 的浏览器会忽略这些属性。纯粹的渐进式增强。

8.2 考虑你的 API 表面

如果你已经在你的网站后面有一个 REST 或 GraphQL API，WebMCP 工具注册本质上是对该 API 的客户端绑定。registerTool 中的 execute 函数只是对你现有端点的 fetch 调用。你不是在构建新的后端基础设施；你是通过浏览器原生通道暴露你已经拥有的东西。

8.3 考虑 agentInvoked 信号

检测提交是否来自代理的能力开启了有趣的可能性。你可能会向代理返回更丰富的结构化数据，同时保持人类体验不变。你可能会单独记录代理交互以进行分析。你可能会对代理请求进行与人类请求不同的速率限制。

form.addEventListener("submit", (event) => {
  if (event.agentInvoked {
    // 为代理提供结构化响应
    event.respondWith(
      getStructuredResults(new FormData(form))
    );
    return;
  }
  // 为人类提供正常的 HTML 响应
});

8.4 什么不要做

不要现在围绕 WebMCP 构建你的整个代理策略。该规范会改变。不要删除你现有的无障碍工作来专注于代理可访问性。ARIA 和 WebMCP 服务于不同的受众并相互补充。

并且不要假设 WebMCP 采用会很快。当涉及到新标准时，网络移动缓慢，这通常是一个功能，而不是一个错误。

9、结束语

网络是为人类构建的，现在它需要为两者工作。

网络被设计为一个超文本文档系统，供人们阅读文档和跟随链接。三十年来，我们将它扩展成了一个应用程序平台、一个商业引擎、一个通信媒介、一个社交网络。每一个这些过渡都需要新标准：用于演示的 CSS、用于交互的 JavaScript、用于安全的 HTTPS、用于离线功能的 Service Workers。

每次，网络都不是通过替换之前的内容来适应的，而是通过添加与旧内容共存的新层。1995 年的网站仍然在 Chrome 145 中渲染。它只是不使用自那时以来添加的任何能力。

WebMCP 正在提出下一层。它不是 HTML 的替代品，不是新的渲染引擎，不是竞争协议。而是，一种让页面清晰地（更重要的是）结构化地，"这是我所能做的，以及这是如何要求我这样做"的方式。

网络总是通过添加层而不是替换它们来发展。WebMCP 是使网站以 HTML 使文档对浏览器可读的方式对机器可读的层。

它是否成功取决于与之前每个网络标准命运相同的因素：浏览器支持、开发人员采用，以及证明工作值得的价值主张。Chrome 的支持给了它浏览器支持。渐进式增强模型降低了采用障碍。价值主张，即"你的网站在 AI 代理不抓取你的 UI 的情况下与它们一起工作"，只会随着代理流量的增加而增长。

但让我们保持清醒的眼光。MCP 生态系统仍然年轻。今天存在的 15K+ MCP 服务器大多是后端集成，而不是网页工具。

W3C 社区组在撰写时有 39 个开放问题和 12 个贡献者。按任何衡量标准，这仍然是早期阶段。

这五个正在解决代理问题的浏览器可能会多年共存。基于视觉的代理将继续抓取。云托管的代理将继续导航。AI 增强的浏览器将继续建议。并且逐渐地，一个表单一个表单，网站将开始以机器可以阅读的语言声明其能力。

它不会在一夜之间发生。 网络从不在一夜之间改变。但方向已经设定，第一批代码已经推出。

问题不是网站是否会学会代理语言。这需要多长时间，以及谁最先到达那里。

网络通过添加而发展。

原文链接: Chrome's WebMCP makes AI agents stop pretending

汇智网翻译整理，转载请标明出处