Commerce.com与Cloudflare如何为AI代理准备店面

AI代理购物卡在“最后一公里”，Cloudflare和Commerce.com想用浏览器标准解决它 AI能写代码、能通过律师资格考试，却仍然很难在网上买一双鞋。原因很简单：绝大多数电商网站是为人类设计的，不是为AI代理设计的。目前大多数购物代理只能靠读取网页HTML来“猜”页面结构——看页面、猜哪个按钮管什么、点击、出错再重试。这个过程既慢又消耗大量token（大模型处理文本的计量单位），而且一次看似无关紧要的主题模板更换就可能让它彻底失灵。为此，Google提出了一项名为WebMCP的浏览器标准，让AI代理在页面上直接调用结构化工具，比如search_products（搜索商品），而不必再满页面找按钮。代理直接调用所需工具，购物因此更快、更便宜、也更可靠。由于WebMCP目前仍处于早期预览的实验性阶段，它只在Chrome实验性开关、Chrome Origin Trials（谷歌面向开发者的新功能试用计划）、部分代理浏览器以及Cloudflare Kitesurf等开发环境中可用。今年8月，Cloudflare发布了WebMCP的边缘计算实现测试版：开启后，Cloudflare会在边缘注入一小段脚本，自动让这些工具可用，网站主一行代码都不用写。 Commerce.com是一家面向AI时代打造的灵活电商平台，其近10万个域名本就跑在Cloudflare上。预览版一出，他们便提出：能不能一次性为所有店铺开启这项能力？这背后的诉求很直接。Commerce.com产品管理总监Kristina Pototska解释，商家不断追问如何跟上代理购物趋势——当消费者让AI代理去找某件商品时，商家希望自己的店铺出现在答案里，希望留住客户、掌控结账环节，同时不必重建网站。WebMCP恰好同时满足这三点：代理获得搜索商品、查看详情、构建购物车、获取结账链接的真实工具，不用再在页面上瞎猜；消费者仍停留在商家站点上，商家保住了客户关系。而且整个开启过程是安全的，不需要商家改主题模板或做任何手工操作。WebMCP还与Commerce.com的服务端MCP并行工作，覆盖不同的代理购物方式：服务端MCP支持直接连接店铺的代理，比如帮用户跨多个网站比价购物的助手；WebMCP则支持在消费者浏览器内工作的代理。两种场景下提供的是同一套购物工具，商家无需二选一或分别管理。技术实现上依赖两个原则：其一，WebMCP工具直接在消费者浏览器会话中、于店铺域名下执行，确保代理看到的价格和购物车与用户一致，凭证不流向第三方，访问仍发生在商家站点上；其二，Cloudflare作为Commerce.com后端MCP服务器的边缘分发层，原样代理工具定义和操作，商家对工具逻辑保持完全控制。对消费者而言，变化很直观：访问已开启功能的店铺时，AI助手不再需要猜怎么逛网站，而是能通过WebMCP直接发现工具。比如你对代理说“帮我找一双140美元以下、10码的防水越野跑鞋并加入购物车”，没有WebMCP时，代理只能模拟人类点击，结果往往被Cookie弹窗拦住、误读商品规格下拉框，或被区分自动流量的机器人验证卡住；有了WebMCP，代理能在document.modelContext上检测到店铺工具，直接完成操作。