Chrome 146 + Cloudflare 一拍即合——网站零代码接 Agent 的新时代来了

<!-- 配图：Cloudflare 边缘注入 → 浏览器 registerTool → Agent 调用工具的流程图 -->

先说结论：WebMCP 这个标准从 0 到 1 走了半年，真正让它从"纸面标准"变成"可以上的东西"的，是这个月两件事同时落地。

8 月 6 日，Cloudflare 上线 WebMCP 开发者预览版，你在后台拨一个开关，HTMLRewriter 就在边缘给每个 HTML 响应注入一行 <script>。访客的浏览器里多了一套把你的网站动作注册为 Agent 工具的能力。你的源站代码，一个字都不用改。

8 月 15 日，Chrome 在 2026 中国开发者大会 Day 2 公布 Chrome 146 的实验性 WebMCP 支持挤进稳定版，同时预告 Chrome 150 的 Lighthouse 会直接把"智能体就绪度"塞进审计项。

这两件事单独看，就是大厂发布了新功能。放在一起看，事情就变了：浏览器愿意给标准，边缘网络愿意替你跑，开发者需要做的事降到了负一层——你甚至不用知道 WebMCP 是什么。

---

对讲机装上了，不用拆房子了

先搞清楚 WebMCP 解决的是什么鬼问题。

现在网站的结构，默认对面坐着的是个人。人是会读页面的，会点按钮的，会填表单的。但 Agent 越来越多——它不会"读"，它只会调工具。

传统方案是爬虫：把页面内容扒回服务器，再让模型用 token 去啃 HTML。结果就是原始网站没流量、没归因，Agent 在猜按钮的位置而不是真的在"用"你的网站。

WebMCP 的逻辑简单粗暴：给网站装一个对讲机。 过去它只对人说话，现在它还能对 Agent 喊："我能加购、能查单、能退票，你调我就行。"

实现方式是 document.modelContext。网站用 registerTool 把"加购物车"这个动作注册成一个 MCP 工具，Agent 在浏览器里直接调用，不用逐个按钮去点。同一个页面，人看到按钮，Agent 看到工具列表，两种访客各玩各的。

问题在于：标准再好，没人写代码就是死标准。 这是 WebMCP 从 Chrome 146 实验性支持以来最大的尴尬。英文圈有个 2026 年 5 月的博客标题叫 "0% Adoption Standard"，一点不夸张。标准躺在文档里，开发者没动力去动。

Cloudflare 干的事，就是把这个"没动力"给抹了。

它用 HTMLRewriter 在边缘塞一行有 data-packs 属性的标签。桥接脚本是 Cloudflare 自己 Worker 从边缘发的，跟源站同源。页面加载后桥接脚本去找 document.modelContext，找到就把工具注册进去，找不到就静默退出，页面行为和以前一模一样。

老房子装电梯。不拆墙，不重装修，一个开关的事。

---

工具包是什么东西

Cloudflare 这次的预览版带了两套工具包：Content Credentials 和 Site MCP Server。

Content Credentials 负责读 C2PA 内容凭证。扫一遍页面上的图，返回每张图的元数据摘要，或者深入单张图解析完整的编辑链、署名、签名证书。有意思的是它只读图片头部几个 KB 的元数据，不下整张图。而且现在所有结果都带着 signatureVerified: false——它只解码，不做密码学验证，防止 Agent 把"读到的声明"误当成"验证过的真话"。

Site MCP Server 更直接：你已经有 MCP 服务端的话，在注入标签里指一个 data-mcp-url，桥接脚本就在访客的浏览器里、用访客自己的 session 直接跟你的 MCP 端点通信。

所有工具都在访客浏览器本地执行，没有 Cloudflare 服务器的往返。 这是让我觉得这个方案真正聪明的地方。工具逻辑再多，Cloudflare 不碰你的数据，不碰你用户的 session。合规、隐私、延迟，三个坑都绕开了。

对 Agent 来说，这些就是普通的 MCP 工具。用 MCP 协议自己的 Tool 和 CallToolResult 类型。一个能跟 MCP 服务器通信的 Agent，拿过来就能驱动页面，不需要额外适配。

浏览器变成了 MCP 的又一个运行环境，而不是需要特殊调教的野外环境。

---

Chrome 那边在干嘛

Cloudflare 解决了"怎么上"，Chrome 干的事是"怎么知道好不好"。

Chrome 150 的 Lighthouse 新增"智能体就绪度"审计，从四个维度打分：

维度	检查什么
WebMCP 工具	注册了没有、能不能发现、能不能正常调用
视觉表现	对 Agent 的视觉上下文是否有干扰
无障碍能力	语义结构、ARIA 标签是否完备
内容偏移	页面加载后布局是否稳定

这四个维度选得有讲究。WebMCP 工具只占一个，剩下三个全是传统网页质量指标的侧写。Google 的意思很明白：Agent 友好的网站，本质上不是"为 Agent 重写网站"，而是"把人用的网站质量提高"。你无障碍做得烂、内容跳来跳去，Agent 来了也一样死。

<!-- 配图：智能体调浏览器 debug 的时序图：启动 → 填表 → 抓错 → 定位 → 改代码 → 验证 -->

Chrome DevTools Connect 也上了 WebStorm。智能体可以直接接入真实的 Chrome 调试实例，不再是模拟环境。合作伙伴 P2ER 用这套 Chrome DevTools + Skills 改造开发流程后，发布频率从每周一次做到每天多次，开发速度提升 10 倍。这个是 Chrome 官方原话，不是我编的。

---

卡在哪

该泼的冷水还是要泼。

WebMCP 现在还是实验性支持。 Chrome 146 刚进稳定版，Cloudflare 的预览版也明确贴着 developer preview 标签。从 0% 到主流之间隔着多少年，我不太确定。但如果让我押注，我会说这个标准比之前的 Web Monetization 和 Web Bluetooth 有戏得多。

理由很简单：那两个标准是"开发者为用户做事"，WebMCP 是"开发者为自己做事"。Agent 流量占比每涨一个点，网站的决策压力就涨一截。谁的网站先能被 Agent 正确调用，谁就先把这批访客的钱赚了。当 Agent 开始买东西的时候，不知道自己家按钮长什么样，就是商业事故。

国内的实际情况更凉一点。英文圈从 2026 年 5 月就开始吵 WebMCP，到 8 月 Cloudflare 和 Chrome 双双加码，讨论量从"什么是"直接过渡到"怎么接"。但中文技术文章大部分还停在 2026 年 3 月的概念扫盲——半年前的东西了。出海开发者其实已经被 Agent 流量逼到墙角，工具链还缺这最后一块。

---

Cloudflare 那边的循环已经跑通了：BrowserRun 给 Agent 一个能跑的浏览器，WebMCP 注入给你的网站装上工具，Agent 用 MCP 协议发现并调用。人也好，Agent 也好，终于开始用同一套基础设施了。

如果你现在有一条 Cloudflare 上的站，去 Dashboard 的 Agent Readiness → Labs 里打开那个开关，下一份 HTML 就会带上桥接标签。不需要部署任何东西，不需要改源站。然后拿 BrowserRun 指一下你的 URL，亲眼看看 Agent 能发现哪些工具。

这一波的门槛已经被拉到地平线以下。剩下的，就是你的网站准备对这波非人类访客说什么。 不说，它们就继续去猜。猜错了，按钮还是按钮，用户还是你的用户吗？