近十万网店接入 WebMCP 工具调用

Commerce.com 联合 Cloudflare，为接近 10 万个店铺域名启用了 WebMCP：让 AI 购物助手直接调用搜索、加购工具，减少读页面、猜按钮、反复点击的过程。

这件事值得程序员关注，因为它展示了现有网站如何增加面向 Agent 的操作入口。不过，接入规模不等于使用规模：原文没有披露实际调用量，也没有给出速度和 token 消耗的对照数据。

AI 购物为什么要从点按钮改成调工具

按原文描述，如今多数购物 Agent 依赖网站 HTML 理解页面，判断控件用途，再点击、失败、重试。Cloudflare 认为，这种方式慢、消耗 token，而且脆弱，连主题样式变化都可能让流程失效。

WebMCP 是 Google 支持的一项浏览器标准提案，让页面提供结构化工具。Agent 不必从页面上推测「这个按钮能做什么」，而是发现工具后直接调用。

原文给出的例子是：寻找价格低于 140 美元、尺码为 10 的防水越野跑鞋，随后加入购物车。启用 WebMCP 后，这个过程可以表达为两次调用：

1. 用 search_products 搜索商品。
2. 用 add_to_cart 加入购物车。

这里展示的是调用流程，原文没有提供参数结构、返回值，也没有说明商品条件如何编码，不能直接当成完整开发示例。

工具运行在消费者自己的浏览器会话里，使用店铺域名下的上下文。因此，按原文所述，Agent 看到的价格和购物车与消费者一致，凭据也不需要交给第三方。最后的结账操作由消费者亲自点击，支付信息仍由消费者掌握。

这次接入把商品搜索和加购交给 Agent，把结账留给用户。

接近 10 万个域名，难点在平台适配

Cloudflare 在 8 月推出了 edge WebMCP beta，原文没有说明年份。启用后，Cloudflare 在边缘注入一段小脚本，站点所有者无需编写代码。

但「无需写代码」有前提：Commerce.com 已经有后端 MCP server，工具逻辑放在那里。Cloudflare 负责原样代理工具定义和操作，并不替店铺凭空生成搜索、加购能力。

Commerce.com 还保留了服务端 MCP，供直接连接店铺的 Agent 使用。浏览器内的 WebMCP 与它并行工作，承担不同的访问入口。

为了让这套机制适应大量商家，双方补了两个能力。

首先是逐商家退出。WebMCP 原先按整个 zone，也就是 Cloudflare 管理的站点区域，统一开关。Commerce.com 在主 zone 开启后，通过 Configuration Rule 检查自定义主机名元数据，识别哪些商家选择退出。商家在后台关闭功能，边缘就跳过该店铺。Cloudflare 声称，退出的店铺没有额外延迟、没有远程查询，也不会注入脚本。

其次是自定义 MCP 路径。桥接层原先假定服务端位于 /mcp，Commerce.com 实际使用 /api/mcp。Cloudflare 为此增加了 zone 级 URL 设置。

故障处理也很直接：MCP server 离线，或者访问者的浏览器不支持 WebMCP，脚本就退出，店铺照常加载。

我的判断

我认同把明确的业务动作暴露成工具。对于搜索和加购这类操作，结构化入口能减少 Agent 对页面布局的依赖，也让前端改版与自动化操作之间少一层耦合。

不过，速度更快、token 更省，目前在这篇原文里只是 Cloudflare 给出的判断，没有对照测试。接近 10 万个域名证明了平台能够批量开启功能，不能据此推断用户采用率或购物成功率。

「站点所有者无需写代码」也不能直接推广到一般团队。Commerce.com 已有后端 MCP 能力，普通站点若缺少这层工具逻辑，仍然要自己建设。

WebMCP 目前还是处于早期预览阶段的实验性标准提案，可通过 Chrome flag、Chrome Origin Trials、部分 Agent 浏览器，以及 Cloudflare Kitesurf 等开发环境使用。原文没有给出具体 flag 名称。现阶段更适合把它作为增量入口来评估；已有服务端 MCP 和页面操作方式仍各有适用环境。

此外，工具在用户会话内运行，解释了价格、购物车和凭据上下文如何保持一致，却没有完整回答 Agent 可以执行哪些动作、如何限制调用。原文对此没有展开。

能拿来做什么

• 如果你维护电商前端，可以先梳理商品搜索、加购等稳定业务动作，判断哪些值得提供结构化工具，并明确哪些步骤必须由用户确认。
• 如果你已有 Node 或其他后端实现的 MCP server，可以重点核对工具定义、部署路径和浏览器会话之间的衔接，别默认桥接层一定接受 /api/mcp 这样的现有路径。
• 如果你负责多商家平台，可以参考按商家配置、边缘判断是否启用的做法，同时验证退出后是否确实没有脚本注入和额外请求。
• 如果你准备试用 WebMCP，应记录调用成功率、耗时和 token 消耗，并测试浏览器不支持、MCP server 离线时的正常购物流程，用自己的数据决定是否扩大接入。