近10万个电商域名接入 WebMCP：让 AI 智能体直接调用购物工具

AI 智能体能写代码，却未必能顺利在网上买一双鞋。问题之一在于，传统网站主要面向人类设计：智能体需要解析页面、判断按钮用途、模拟点击，页面主题或商品规格控件的变化都可能让流程失效。

Commerce.com 与 Cloudflare 的合作尝试换一种方式：为近10万个电商域名提供 WebMCP 支持，让智能体直接调用结构化购物工具，而不是反复猜测页面操作。

WebMCP 改变了什么？

WebMCP 是 Google 提出的实验性浏览器标准提案，可让网页向 AI 智能体暴露 search_products 等结构化工具。

它目前仍处于早期预览阶段，可在启用实验开关的 Chrome、Chrome Origin Trials、部分智能体浏览器及开发环境中使用，尚不能视为所有浏览器都已支持的通用能力。

Cloudflare 的边缘实现通过向页面注入脚本提供这些工具，减少站点逐一修改前端代码的工作。在此次集成中，Cloudflare 充当边缘交付与代理层，将 Commerce.com 后端 MCP 服务的工具定义和调用传递给浏览器，不改变商家后端的工具逻辑。

从模拟点击转向调用购物工具

假设用户提出需求：“找一双140美元以下、10码的防水越野跑鞋，并加入购物车。”

传统页面操作方式下，智能体可能被 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 通过 Cloudflare for SaaS，在共享区域中托管大量商家的自定义域名。而 WebMCP 最初采用区域级的整体开关，无法直接满足“平台统一开启、单个商家自行退出”的需求。

双方将 WebMCP 接入 Cloudflare 的配置规则与自定义主机名元数据机制：平台先在主区域开启功能，再根据商家的退出标记，在边缘关闭特定店铺的 WebMCP。

{
  "action": "set_config",
  "expression": "cf.hostname.metadata.webmcp_opt_out eq \"true\"",
  "action_parameters": {
    "webmcp_enabled": false
  }
}

商家在管理后台选择退出后，规则会在页面交付前生效，对应店铺不再注入 WebMCP 脚本，也不需要为此进行远程查询。

部署还需要处理路径差异与故障回退

支持自定义 MCP 地址

Cloudflare 的 mcp-server-client 工具包最初假定 MCP 服务位于 /mcp，但 Commerce.com 使用的是 /api/mcp。

为此，方案增加了区域级 MCP URL 配置，并通过注入脚本的属性传入自定义地址：

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

不支持时保持普通店铺可用

如果商家的 MCP 服务离线，或消费者的浏览器不支持 WebMCP，脚本会退出，店铺继续按普通网页加载，不影响人工浏览购物。

浏览器端 WebMCP 与服务端 MCP 如何分工？

Commerce.com 同时提供服务端 MCP 和浏览器端 WebMCP，两者面向不同使用场景：

服务端 MCP：支持智能体直接连接商店，例如协助用户跨多个站点购物。
浏览器端 WebMCP：支持在消费者当前浏览器会话中工作的智能体。

两种方式使用同一套购物工具，商家无需为不同入口分别维护两套业务逻辑。

这次部署展示了一种面向大型电商平台的接入方式：以现有后端工具为基础，通过边缘层分发浏览器能力，同时保留商家退出机制、用户结账控制和故障回退。至于购物速度、调用成本与成功率能改善多少，目前提供的信息中没有量化测试结果，仍需实际验证。