webmcp：35 个首页里只有一个能接智能体调用，还是 Cloudflare 自己
webmcp 是一套浏览器标准，让站点把一组工具直接交给来访的 AI 智能体。2026-09-30 读到的 35 个首页里，只有一个挂了这个东西，而且就是 Cloudflare 自己的站。
规则变动 · 2026-08-06 · Cloudflare WebMCP
webmcp 是一套浏览器标准，让页面把一组工具直接交给来访的 AI 智能体（agent，能自己操作页面的程序），而不是逼它在一个给人做的页面上摸索。2026-09-30 我们能读到的 35 个首页里，只有一个挂了这个东西，就是 Cloudflare 自己的站。标准是真的，普及是假的，这是我们今天关于它最有用的一句话。
这条变动到底是什么
Cloudflare 在 2026-08-06 放出了 WebMCP 的开发者预览。它自己的说法是：「WebMCP is a new browser standard, shipping experimentally in Chrome 146, that shows up in the page as document.modelContext.」页面因此可以把工具注册给来访的智能体去调用。公告把动机说得很直白：以前那条路是爬虫把内容拷回服务器，「too often, give the original site none of the traffic and little of the credit.」
Cloudflare 这个预览没让你自己写这套代码。在后台 Agent Readiness 里打开一个开关，边缘就往下发的每份 HTML 里注入一行：
<script type="module"
src="/.webmcp/bridge.js"
data-packs="c2pa,mcp-server-client"
data-mcp-url="/mcp"></script>标签和它加载的脚本都从边缘发、同源，所以对浏览器没有这套能力的访客来说，页面什么都没变。桥接脚本再把指定的几个包拼成一张工具清单，逐个用 registerTool 注册。预览里带了两个包：一个从图片里读内容凭证，另一个转发到你自己那台 Model Context Protocol 服务器。Cloudflare 讲得很清楚这是开发者预览，而且预览里每个工具都在访客浏览器里跑，不经过它自己的服务器。
我们怎么查的，以及一次抓取能看到什么
2026-09-30 我们对 35 个可用首页各抓一次，桌面 Chrome UA、跟随跳转、不执行 JavaScript，在返回的 HTML 里找三个串：webmcp、桥接路径 /.webmcp/bridge、以及 modelContext。39 个站里有四个（nytimes.com、medium.com、stackoverflow.com、canva.com）返回 403，剔除。我们自己的 6 个站也跑了同一套。
命中一个，而这一条值得细看。Cloudflare 首页里有一段 inline 脚本，读 document.modelContext，拿不到就直接返回，拿到就对一组工具逐个调 registerTool，旁边还有一句控制台警告写着「WebMCP tool registration failed」。这个页面上我们没找到 /.webmcp/bridge.js 标签，所以它自家首页更像是手写接入，而不是它正在卖的那个后台注入。
| 信号 | 面板首页 | 自有 6 站 |
|---|---|---|
| 抓取可用 | 39 个里 35 个 | 6 个里 6 个 |
| 挂了 WebMCP | 1 | 0 |
| 用 Cloudflare 桥接标签 | 0 | 0 |
| 出现 modelContext | 1 | 0 |
这唯一的一处也正好标出了方法的边界。只读 HTML，能知道的只是响应里有没有这段代码，它没法告诉你智能体能不能真的够到这些工具、工具能不能用、有没有哪个智能体真的试过。
webmcp 对内容站意味着什么
如果你是发文章的站，诚实的回答是：这件事现在对你没有任何改变，而知道这一点本身有价值。WebMCP 冲的是任务，不是阅读 —— 订票、筛选、配置，这些靠点击完成的事。一个内容页几乎没有这种形状的东西。它改变的是方向。一个能调用站点的智能体，拿到的是干净、结构化的答案，而不是从 HTML 里重新拼一遍，而这正是这个博客其余部分一直在做的、面向读者那半边工作的同一个目标。
今天就真能做的五件事：
- 查自己的页面。一条请求一条 grep 就知道有没有东西：
curl -s https://your-site.example | grep -i webmcp。 - 除非你卖的是任务，否则什么都别做。站点以只读内容为主，就还没有工具可暴露。
- 盯标准，别盯厂商。Chrome 146 还是实验性的，稳定之前这套接口还会动。
- 留住那条回退路。给不渲染的客户端供干净 HTML 与 markdown，是今天就能用的那一半，这套东西替代不了它。
- 别把它当排名手段。没有任何文档说哪个搜索或答案引擎按「页面讲不讲 WebMCP」来排名。
没人采用的标准不是最佳实践，只是一个检查点。
我们没法告诉你的，是那次调用之后发生了什么。我们手上没有会讲 WebMCP 的智能体，一次工具调用都没跑，也不知道 Cloudflare 那两个包返回的东西对一个智能体有没有用。这就是我们只报那个字符串、不给你一个可用示例的全部原因。
常见问题
webmcp 是什么
它是 Chrome 146 里实验性的一套浏览器标准，通过 document.modelContext 把页面的工具暴露给 AI 智能体。它和爬虫怎么拷你的内容无关，讲的是智能体在页面上做事，而不是读页面。
要不要开 Cloudflare 那个开关
只有当你的站有一个智能体能完成的任务时才值得。博客或官网这种站，答案是不开，而它还是个预览，这个决定更容易往后放。
对收录或被引用有没有用
没有哪家引擎把它写成一项输入，我们也不会把它说成一项。它和这个博客的关系是方向，不是已测出的效果。
你们是怎么测的
2026-09-30 每个首页一次请求，桌面 Chrome UA、跟随跳转、不执行 JS，在返回的 HTML 里搜三个串。四个站返回 403 被剔除，剩下 35 个。我们没调任何工具，也没开浏览器。
这里的形状和这个站其余部分一样：平台上一个能力，宣传里写「any site」，拿真实首页数一遍，答案是 1。同一件事更安静的那半边，是站点今天已经在怎么给不渲染的客户端供内容，见把 markdown 供给 AI 爬虫；大多数站会踩到的那个 Cloudflare 开关在哪些 AI 爬虫进来了；决定你的内容要不要去训练模型的设置，在挡训练但别挡掉搜索。把这些落到一个你能控制的页面上，正是 QueryWin 在做的事。
