mylogs.cn

不用写一行代码，给网站装上 AI 代理专用接口

发布于

互联网最初是按「屏幕对面坐着一个人」来设计的：有人阅读页面、点击按钮、填写表单。但如今，越来越多的访问来自 AI 代理，而它们面对的仍是一个为人类打造的网络。

不用写一行代码，给网站装上 AI 代理专用接口
图片来源：Cloudflare

Cloudflare 在 8 月 6 日推出了 WebMCP 的开发者预览版，试图改变这一局面：网站只需在控制台里打开一个开关，无需编写任何代码，也不改动源站，浏览器中的 AI 代理就能直接调用这个网站提供的工具。Cloudflare 会向页面注入一个轻量桥接层，为访客的代理注册一套可用工具集。

从「爬」到「调用」

过去，AI 获取网站内容的通行做法是爬虫抓取：把内容复制回自己的服务器，往往既不给原网站带去流量，也不留下多少署名。Cloudflare 认为存在一条更好的路径，而且这条路径不需要爬取。

WebMCP 是一项新的浏览器标准，目前已在 Chrome 146 中实验性上线，在页面里以 document.modelContext 的形式呈现。网站可以主动向浏览器内运行的代理暴露一组工具，代理就不必再对着为人类设计的页面元素反复猜测。这样一来，代理的浏览体验可以与人类用户完全不同，token 花在真正要完成的任务上，而不是消耗在无谓的页面导航中。唯一的门槛在于：网站必须自己去实现它。

Cloudflare 一直在这条链路的两端同时布局。其远程浏览器 BrowserRun 已支持 WebMCP，代理可以发现并调用网站暴露的工具；Cloudflare Radar 也即将提供自己的 WebMCP 工具。这次的预览版针对的是另一端——让任何托管在 Cloudflare 上的网站，通过一个开关、零代码就获得这些能力。

技术实现：边缘注入加浏览器桥接

手动实现 WebMCP 本身就是一个不小的工程：需要设计要暴露哪些工具、把它们接入现有界面，还要随着标准演进持续维护。Cloudflare 的目标是把这件事简化成拨动一个设置开关。

这些工具以「工具包」（pack）的形式组织，相关工具可以整体启用。工具包的设计考虑了扩展性：随着 Cloudflare 陆续增加新包，网站只需打开开关即可接入更多能力，无需重新部署。当前开发者预览版包含两个工具包，两者都完全在浏览器中运行。

整套实现由两部分组成，均位于源站之前，不触碰网站自身代码，且对静态站点和单页应用一视同仁。

第一部分是边缘注入。当网站在 Cloudflare 控制台中开启 WebMCP 后，Cloudflare 使用 HTMLRewriter 在每个 HTML 响应中添加一行内容——一个指向桥接脚本的引用。标签和它加载的脚本都来自边缘节点、同源提供，页面的其他部分保持原样：

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

其中 data-packs 属性列出要激活的工具包。如果网站已有自建的 MCP（Model Context Protocol，模型上下文协议）服务器，data-mcp-url 就指向该服务器，默认为同源的 /mcp 路径。

第二部分是桥接层。它在页面中运行，负责寻找 WebMCP 接口。如果浏览器不支持该接口，脚本直接返回、什么也不做，页面行为与之前完全一致。

找到接口后，桥接层会把 data-packs 中列出的工具包合成一份工具清单，逐个通过 .registerTool 注册。一个工具包就是一组 MCP 工具描述符及其处理函数。像内容凭证包这样的静态包会预先声明自己的工具；而像站点 MCP 服务器包这样的动态包，则在启动时先发现工具，再进行注册。

在当前预览版中，每个工具都完全在访客的浏览器内运行，不存在向 Cloudflare 服务器的往返请求。内容凭证包在本地抓取图片并解析其前几 KB 的内容溯源元数据；站点 MCP 服务器包则从页面直接与网站的 MCP 服务器端点通信，使用访客所在的源和其已有的会话。

桥接层代码由运行在边缘的 Worker 提供。Cloudflare 表示这为后续扩展留出了空间——未来的工具包将能够调用这个 Worker，去完成页面自身无法独立完成的任务，比如用 Workers AI 总结站点地图，或查询 AI 搜索索引。

对代理而言，这些都只是普通的 MCP 工具。Cloudflare 直接沿用了 Model Context Protocol 自身的 Tool 和 CallToolResult 类型，因此一个已经能与 MCP 服务器对话的代理，不需要任何额外改造就能驱动页面。用 Cloudflare 的说法：浏览器只是 MCP 运行的又一个场所。

两个预览工具包

内容凭证包用于读取图片的溯源元数据，服务于 C2PA 内容凭证计划的参与方。其中 scan_images_c2pa 会扫描页面上的每一张图片，返回一份简短摘要，包含图片总数、已扫描数量、带有 C2PA 信息的数量，以及每张图的格式、声明生成方（例如 Adobe Firefly）、标题和签名者等字段。若需要更细致的信息，inspect_image_c2pa 可以解码单张图片的完整清单，包括编辑历史、声明的作者以及签名证书。

另一个是站点 MCP 服务器包。它会读取网站自有 MCP 服务器通过 tools/list 公布的每一个工具，为其注册一个代理封装。当代理调用该工具时，封装函数会以同源方式向 /mcp 发起 POST 请求，携带访客现有的会话凭据，并将返回的 CallToolResult 原样传回。

对站点运营者来说，这一变化的实际意义在于 AI 流量的处理方式：代理不必再从原始 HTML 中反推网站意图，而是可以调用结构化工具、拿到准确且符合预期的结果，同时保留会话上下文，网站方也能完整看到代理的交互行为。

WebMCP 采用 MCP 2026-07-28 版本规范，该版本将协议从有状态的会话管理转向基于 Streamable HTTP 的无状态模型，代理通过标准 POST 请求调用工具，用 Mcp-Method 和 Mcp-Name 请求头路由指令，从而更适合在边缘基础设施上横向扩展。

需要注意的是，这仍是开发者预览版，WebMCP 标准本身在 Chrome 中也处于实验阶段。站点运营者可以将 BrowserRun 指向自己的域名，查看代理究竟会发现哪些工具、又会如何调用它们，然后再决定是否放行生产流量。

来源：Cloudflare 官方博客、Cloudflare Browser Run 开发者文档

相关文章

TAG：