AI 现在用网页，全靠爬内容和截图猜按钮

网页这东西，从第一天起就是按「屏幕对面坐着一个人」设计的。有人会读文字、会点按钮、会填表单。

现在越来越多的访客是 AI Agent。它们怎么用这些为人做的页面？眼下就两条路，都不太好。

第一条是爬取。 Agent 把整个页面抄回自己的服务器去解析。这条路网站主最难受，内容被拿走了，流量一点没留下，署名也没有。

惯常的做法是爬虫，把内容复制回一台服务器，而且往往一点流量都不给原站，署名也少得可怜。有更好的办法，而且它不需要抓取。

Cloudflare 博客 · Give any website a WebMCP interface

第二条是截图-分析-点击。 Agent 像人一样看屏幕：截个图，让模型分析这是什么界面、搜索框在哪，点进去，再截图，再分析。慢、脆，而且烧掉的 token 大半花在「认路」上，不是花在办事上。页面改个版，整套流程就废了。

WebMCP 想给出第三条路：网站主动告诉 Agent「我这儿有哪几个工具你可以直接调」，比如「搜航班」「订机票」，每个参数是什么类型写得清清楚楚。Agent 不用猜了，直接调。

WebMCP 让网站把能干的事列成工具，AI 照着调

先说清楚它的身份：WebMCP 是一个浏览器标准提案，正在 W3C 的一个社区组里孵化，还没成为正式标准。Chrome 那边给它的状态标注到今天仍是「Proposed」（提议中）。

它在网页里长成一个接口，叫 document.modelContext。网站往这个接口上挂工具，浏览器里的 Agent 就能看见并调用。

挂工具有两种写法，门槛差得挺远：

一种是写 JavaScript，调 registerTool()，把工具的名字、说明、参数结构和执行逻辑都写清楚。复杂的交互只能这么来。

另一种更省事，就在你已经有的 HTML 表单上加几个属性。 一个订餐表单，加上 toolname（这个工具叫什么）、tooldescription（它是干嘛的），再给每个输入框加一句 toolparamdescription（这一格填什么），浏览器就自动把它变成一个 Agent 能调的工具，连参数说明书都替你生成好。

工具会随页面变化，付款前停下等人确认

光看接口定义，还感觉不到它实际用起来什么样。Cloudflare 自己的远程浏览器文档里带了一份实操记录，走的是 Google 官方那个酒店预订 demo，两个细节挺出乎意料。

一是工具不是固定几个。 刚打开页面时只有三个：看酒店详情、按地点搜、查设施政策。等你调完「按地点搜巴黎」，页面跳到搜索结果，这时候才多出来一个新工具「筛选搜索结果」。工具跟着页面状态走。

二是敏感操作会把 Agent 卡住。 「完成预订」这个工具调下去不会直接成交，它停在那儿，等你在浏览器里点「确认预订」那个按钮。这是标准内建的人工确认机制。

Cloudflare 的做法：网页送出去的路上塞进一行脚本

标准讲完了，回到 Cloudflare 这次的活。它的实现分两块，两块都在你的源站前面，你的代码一个字不用动。静态站还是单页应用，效果一样。

第一块：在边缘塞一行脚本

你在后台把开关打开之后，你的每一个 HTML 页面从 Cloudflare 的服务器发给访客之前，会被加上这么一行：

<script type="module"
        src="/.webmcp/bridge.js"
        data-packs="c2pa,mcp-server-client"
        data-mcp-url="/mcp"></script>

干这件事的工具叫 HTMLRewriter，Cloudflare 在网页送出去的路上改写 HTML 的东西。你的源站服务器完全不知情，也不用配合。

第二块：bridge.js 这个桥

它在页面里跑，第一件事是找浏览器有没有 WebMCP 接口。没有就直接返回，什么也不做，页面跟以前一模一样。有的话，它把 data-packs 里列的包合成一份工具清单，逐个注册上去。

自带两个功能包：查图片来历、调你自己的 MCP 服务

工具是按「包」给的，一组相关的工具打包在一起，一起开关。预览版给了两个包，都完全在访客的浏览器里跑，不绕道 Cloudflare 的服务器。以后加了新包，站点只要在后台勾一下就能用上，不用重新部署。

包一：查页面上的图片是谁做的

这个包读的是图片里的 C2PA 信息，一套给图片记「出身证明」的行业标准：这张图是谁生成的、是不是 AI 做的、后来谁改过，都写在图片文件开头的元数据里。

包里给两个工具。scan_images_c2pa 把整页图片扫一遍，返回一份摘要。Cloudflare 给的示例输出是：整页 12 张图，全扫完了，其中 8 张带 C2PA 信息；每张列出来源，比如某张 hero.jpg 的生成器写着 Adobe Firefly、签名方是 Adobe Inc.。另一个 inspect_image_c2pa 单张挖深，解出完整档案，编辑历史、声称的作者、签名证书。

技术上它就是一个纯 TypeScript 的读取器，只碰图片开头那几 KB 的元数据，不下载整张图。

包二：把你自己的 MCP 服务器搬进页面

如果你的站本来就有一个 MCP 服务器（这一两年不少公司已经建好了），这个包会先去 /mcp 问一句「你有哪些工具」，拿到清单之后，把你已有的每个工具原样代理一份到页面上：名字照抄、说明照抄、参数说明书也直接照抄。

这也是两个包的差别所在，查图片那个包的工具是预先写死声明好的，这个包的工具得先问才知道。

document.modelContext.registerTool({
  name: tool.name,                 // 比如 "search_products"
  description: tool.description,
  inputSchema: tool.inputSchema,   // 直接照抄你的参数说明书
  execute: async (args) => {
    const res = await fetch(mcpUrl, {   // 同域名的 /mcp
      method: "POST",
      credentials: "same-origin",       // ← 带着访客当前的登录状态
      headers: { "content-type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0", id: 1, method: "tools/call",
        params: { name: tool.name, arguments: args },
      }),
    });
    const { result } = await res.json();
    return result;   // 结果原样传回去
  },
});

对 Agent 来说，这些全都是普普通通的 MCP 工具，Cloudflare 用的是 MCP 协议自己的数据类型，一个本来就会跟 MCP 服务器打交道的 Agent，不用加任何东西就能操作网页。

还有一句话透露了后面的路：bridge 的代码是 Cloudflare 边缘的一个 Worker 发的，这是给以后留的余地，将来的功能包可以让这个 Worker 干页面自己干不了的活，比如用 Workers AI 总结整个站点地图，或者查 AI Search 索引。

这个开关在哪打开，怎么确认生效

后台路径：Cloudflare Dashboard → Agent Readiness → Labs（还挂着 Beta 标）。这个 Labs 页面的自我介绍是「实验性的、要自己开的功能，让你的站跟 AI Agent 配合得更好」。

后台实际长这样：上面一个总开关，下面两个功能包的勾选框，两个默认都勾上。一个都不勾等于用默认集。图片来自 Cloudflare 博客。

确认真的生效了，就一条命令，去你的站要任意一个网页，看有没有那行注入：

curl -s https://your-site.example | grep webmcp

想看工具真的能被调起来，不用自己造一个 Agent，拿 Browser Run（Cloudflare 那台跑在云上的远程浏览器）指向你的网址就行，它会像访客的 Agent 一样，把工具发现出来、调一遍。不过有个前提：WebMCP 目前只在 Chrome 测试版里，所以得开一个专门的实验会话。

实测：今天最新版 Chrome 还不支持 WebMCP

开是开了，但访客那一端现在到底认不认？这件事的说法需要更新一下。

Cloudflare 博客写的是 WebMCP「正在 Chrome 146 里实验性发布」。这个口径已经滞后了：Chrome 官方文档的说法是，WebMCP 的公开试用期（origin trial）从 Chrome 149 开始，网站去 Google 那儿登记一下，就能对自己的真实用户打开这个功能，不再只能在自己电脑上开开关试。而今天，Chrome 稳定版已经是 151 了。

所以到底能不能用？我在本机测了一遍。测试页面带了 Chrome 要求的那个隔离响应头，满足接口可用的前提条件：

这不是说这东西没用，「开发者预览」本来就是这个意思。它现在的价值在于「你可以零成本先把站备好」，而不是「今天开了明天就有 Agent 来用」。Chrome 那边给这个特性登记的目标发布版本是 157，状态仍然是「提议中」。

顺带一提，我也查了 Cloudflare 自己：它的博客、官网、Radar 三个站现在都没打开这个功能。Radar 那套自己的 WebMCP 工具也还没上线，发布时给的时间是「很快」。

Chrome 官方列出的三个限制：网页不开着就调不了

标准本身还有几条硬边界，写在 Chrome 官方文档的「限制」一节里。这是做这套标准的人自己列的，比任何第三方点评都硬：

另外两条是安全上的约束：WebMCP 只在做了源隔离的页面里可用（站点如果关掉这个隔离，接口直接失效）；工具注册还受一条权限策略管，默认只允许顶层页面和同域名的页面注册，跨域名的内嵌框架默认禁止，想让它也能注册工具，得单独放行。

回到最开始那个问题：这个开关值不值得现在打开。开的成本是零，点一下，源站不动，浏览器不支持就静默跳过。所以要想的其实是另一个问题：开了之后，除了那两个通用包，你有没有自己的 MCP 服务器可以接上去。让 Agent 真能替用户在你站上办事的，是那个包。图片凭证扫描器是搭头。

WebMCP 本身是个还在孵化中的浏览器标准，网站要支持它，得自己写代码。Cloudflare 这次把这一步接管了：后台点开开关，源站代码一行不用改，也不用重新部署。

它把脚本塞进网页发出去的路上，网页从 Cloudflare 边缘节点送到访客手上之前，被加上一行 script，这行脚本和你的网站同域名。脚本先探测浏览器里有没有 WebMCP 这个接口：没有就直接退出，页面照旧；有就把选中的功能包拼成一份工具清单交给 AI。

预览版自带两个功能包，都在访客的浏览器里跑，不绕道 Cloudflare 的服务器。

另一个包更实在：如果你已经有自己的 MCP 服务器，这个包把里面的工具原样代理进页面，名字、说明、参数照抄。

我在 2026-08-07 用本机最新版 Chrome 测了一遍。

今天把这个开关打开，脚本确实会塞进页面，但多数访客的浏览器里根本没有这个接口，脚本探测不到，直接退出，页面照旧。能吃到工具的，是自己开了实验开关的浏览器，以及跑测试版 Chrome 的云端远程浏览器。