AI 可以编写代码并通过律师资格考试，但它仍然难以在网上购买一双鞋。
这是因为网站是为人类构建的，而不是为代理构建的。如今大多数替人购物的代理都基于网站的 HTML 工作——它们查看页面，猜测哪个按钮起什么作用，点击，如果出错就再试一次。这个过程很慢，消耗大量 token，而且看似无害的主题更改也可能使其失效。
WebMCP 应运而生：这是来自 Google 的浏览器标准，为 AI 代理在页面上提供结构化工具，例如 search_products。代理无需寻找按钮，而是直接调用所需的确切工具，使购物更快、更便宜且可靠得多。由于 WebMCP 仍是一个处于早期预览阶段的实验性浏览器标准提案，它目前可通过实验性 Chrome 标志（chrome://flags/#enable-webmcp-testing）、Chrome Origin Trials、部分代理浏览器以及 Cloudflare Kitesurf 等开发者环境使用。
8 月，我们推出了 WebMCP 的边缘实现 测试版。启用后，Cloudflare 会在边缘注入一小段脚本，自动提供这些工具，网站所有者无需编写任何代码。
Commerce.com 是一个为 AI 时代构建的灵活商务平台，已经使用 Cloudflare 运行其近 100,000 个域名。因此当预览版发布时，他们问道：我们能否为所有商店一次性启用此功能？
以下是 Commerce.com 为何需要 WebMCP、我们如何构建边缘级退出机制以让每个商家拥有控制权，以及我们在过程中学到的东西。
Commerce.com 为何需要 WebMCP
Commerce.com 产品管理总监 Kristina Pototska 解释了这对店面为何重要：
“商家不断问我们如何跟上代理购物。当购物者要求代理寻找某物时，商家希望自己的商店出现在答案中。他们希望留住客户、保持对结账的控制，并且无需重建网站即可做到。WebMCP 有助于实现这三点。代理获得真正的工具来搜索产品、检查详情、构建购物车并获取结账链接，因此它不必在页面上猜测。人类购物者留在商家网站上，商家保持客户关系。
我们希望以安全的方式启用此功能，并且不要求商家编辑主题或手动做任何事情。这就是 Cloudflare 合作完美发挥作用的地方。
WebMCP 还与我们的服务器端 MCP 协同工作，两者共同覆盖人们使用代理购物的不同方式。服务器端 MCP 支持直接连接到商店的代理，例如帮助某人在多个网站购物的助手。WebMCP 支持在购物者浏览器中工作的代理。两种情况下都是同一套购物工具，因此商家不必在两者之间选择或分别管理。”
在底层，此集成依赖于两个关键原则。首先，WebMCP 工具直接在购物者于商店域名上的活动浏览器会话内执行，确保代理看到相同的价格和购物车。没有凭据发送给第三方，访问仍然发生在商家网站上。其次，Cloudflare 作为 Commerce.com 后端 MCP 服务器的边缘交付层，原样代理工具定义和操作，以便商家保持对其工具逻辑的完全控制。
购物者的代理看到什么
访问已启用的 Commerce.com 店面时，AI 助手不再需要猜测如何浏览网站。相反，它可以通过 WebMCP 即时发现工具。
假设你告诉你的代理：“帮我找一双 140 美元以下、10 码的防水越野跑鞋，并把它加入我的购物车。”
没有 WebMCP：代理尝试模拟人类点击，却被 cookie 横幅阻止、误解变体下拉菜单，或被试图区分自动化流量和真实客户的机器人挑战绊倒。
使用 WebMCP：代理在 document.modelContext 上检测到商店的工具，并进行两次干净的调用：
search_products({ query: "trail running shoe", max_price: 140, size: 10 })add_to_cart({ product_id: "shoe_123" })
因为代理在商店域名上你的活动浏览器会话内运行，你的购物车会实时更新。Commerce.com 的后端 MCP 服务器决定商务流程：当你准备完成购买时，你自己点击结账——保持你的支付详情安全，并让你完全控制最终购买。
我们一起构建了什么
当 Commerce.com 要求为近 100000 个店面启用 WebMCP 时，我们遇到了一个实际挑战：WebMCP 最初设计为整个域名区域的单一开关。
Commerce 希望启用我们的 mcp-server-client 工具包，它充当边缘桥梁——将工具定义和请求直接从 Commerce.com 的后端 MCP 服务器代理到访客的浏览器。由于 Commerce.com 使用 Cloudflare for SaaS 在共享区域上托管数千个商家个性化域名，我们需要一种方式来在平台范围内交付此功能，同时让各个店主轻松选择退出。
1. 为 Commerce.com 上的所有商店启用，每个商家可退出
我们没有构建复杂的自定义允许列表，而是将 WebMCP 接入现有的 Cloudflare 概念：配置规则 和 自定义主机名元数据。
Commerce.com 为其主区域启用 WebMCP，然后在边缘添加一条规则来检查商家元数据。如果商家在其 Commerce.com 仪表板中切换“退出”开关，Cloudflare 会自动为该特定店面绕过 WebMCP：
{
"action": "set_config",
"expression": "cf.hostname.metadata.webmcp_opt_out eq \"true\"",
"action_parameters": {
"webmcp_enabled": false
}
}
由于 Cloudflare 在提供页面之前在边缘评估这些规则，选择退出的商店获得零额外延迟、无远程查找，也不注入脚本。
2. 定制端点和安全回退
与任何预览版一样，在现实世界中与合作伙伴合作揭示了一些我们未曾考虑到的实际细节：
自定义 MCP 路径：启用 mcp-server-client 工具包时，我们的桥接程序最初预期在每个站点的 /mcp 路径找到其 MCP 服务器。Commerce.com 的服务器位于 /api/mcp。为处理这一点，我们在区域级别添加了可配置的 MCP URL 设置。设置后，我们将自定义路径传入注入的 script 标签：
<script type="module"
src="/.webmcp/bridge.js"
data-packs="c2pa,mcp-server-client"
data-mcp-url="/api/mcp"></script>
无缝回退：如果商店的 MCP 服务器离线，或客户的浏览器不支持 WebMCP，脚本会退出。店面正常加载，人类购物者不受影响。
下一步
随着标准演进，我们将继续投资 WebMCP，首先从帮助智能体更轻松地找到站点的工具开始。Cloudflare 和 Commerce.com 将继续合作，让智能体购物对商家和购物者都快速、可靠且安全。
如果你在 2026 年 10 月 21 日于旧金山参加 Cloudflare Connect，欢迎来参加我们的 Getting your storefront agent ready for peak season 小组讨论，嘉宾包括 Kristina Pototska（Commerce 产品管理总监）、Justis Blasco（Popmenu 首席技术官兼联合创始人）、Ross Harvey（Fruugo 基础设施负责人）和 Josh Mills（Gopuff 工程副总裁）。