Cloudflare 在其仪表板中新增了一个开关，可以在任何网站的页面中注入 WebMCP 桥接器，从而让 AI 智能体能够发现并调用网站提供的工具，而无需改动源服务器的代码。此举消除了使网站实现“智能体就绪”（agent-ready）过程中最耗费人力的步骤，但开发者仍需定义实用的工具并监控其使用情况。

为什么边缘端开关至关重要

WebMCP 是一个用于注册工具的 API。在此之前，要让网站接入该协议，需要在每个页面上手动插入桥接脚本。Cloudflare 新推出的“Browser Run → Agent Readiness”开关实现了在边缘端的自动化注入——在 HTML 离开 Cloudflare 网络并到达访问者的浏览器时，自动添加该脚本。

其优势显而易见：任何托管在任何地方的静态网站，现在只需点击一下，即可向 AI 智能体开放其内容。无需更改源服务器，也无需重新构建前端。

该功能具体做了什么

启用该开关后，会发生两件事：

  • 边缘注入 (Edge injection) – Cloudflare 会在传出的 HTML 中追加一段小的 JavaScript 有效载荷。它既适用于传统的静态页面，也适用于依赖客户端路由的现代 SPA。
  • 浏览器桥接 (Browser bridge) – 该脚本在用户的浏览器中运行，并将网站向 WebMCP API 进行注册，宣告其可以提供的工具。

Cloudflare 在预览版中附带了两个预装的工具包：

  1. 内容凭证 (Content Credentials) – 暴露附加在媒体文件上的 C2PA（内容来源和真实性联盟）元数据，允许智能体验证来源。
  2. 网站 MCP 服务器 (Site MCP Server) – 充当代理，将工具调用转发到您已经在后台运行的 MCP 服务器。

这些工具包解决了分发问题：您不再需要为了让智能体能够访问网站，而在每个页面上散布桥接代码。

开发者仍需承担的工作

开启开关并不会神奇地将购物车或航班搜索表单变成 AI 可调用的工具。桥接器仅仅是宣告网站可以提供工具；网站本身仍必须定义这些工具。一个工具要投入使用，需要满足两个条件：

  • 必须在代理可以访问的地方运行着一个 MCP 服务器。
  • 开发者必须通过 document.modelContext API 注册每个工具，并指定工具的名称、输入模式（schema）和预期的输出格式。

如果暴露了搜索工具，开发者必须确保返回的数据是干净、结构化且对下游智能体有用的。否则，工具虽然会被调用，但几乎没有价值。

可观测性是另一个缺失的部分。当前的发布版本并未提供日志来显示哪些智能体调用了哪些工具，或者调用在哪里失败了。团队必须自行构建监测机制（instrumentation）——捕获请求 ID、响应时间和错误代码——以验证桥接器和底层 MCP 服务器是否按预期工作。

谁将受益，谁必须采取行动

  • 已经运行 MCP 服务器的网站所有者 可以直接开启 Cloudflare 开关，立即实现现有工具集的边缘级分发。边缘注入处理了底层架构工作，让他们能够专注于工具设计。
  • 希望 AI 智能体执行操作的企业（如搜索产品目录、预订预约等）仍然需要编写工具定义并进行彻底测试。该开关并不能取代这些工作。
  • 团队必须考虑将内部 API 暴露给任何发现该网站的智能体所带来的信任风险。

总结

Cloudflare 托管在边缘的 WebMCP 开关消除了在每个页面手动插入桥接脚本的步骤，为任何网站成为 AI 智能体可发现的对象打开了大门。真正的核心工作——设计有意义的工具、确保其安全性以及构建可观测性——仍然留在开发者这一侧。利用该开关来解决分发难题；然后，将注意力转向决定智能体是否能在您的网站上真正完成有用工作的能力与信任挑战。