近十万电商域名通过WebMCP接入智能体

AI 能写代码，却未必能顺利在网上买双鞋。问题不全在模型：购物网站主要给人使用，智能体只能读 HTML、猜按钮、模拟点击，换个主题都可能让流程失效。

Commerce.com 和 Cloudflare 的方案，是通过 WebMCP 把商品搜索、加购等能力变成浏览器里的结构化工具，再由边缘节点统一接入近 100,000 个域名。真正值得看的是：怎样复用用户会话、保留商家控制权，以及大规模开启后如何允许单店退出。

购物智能体需要的是工具入口

靠页面操作购物，智能体要处理 Cookie 弹窗、商品规格下拉框，还可能撞上机器人验证。每次判断都消耗时间和 token，界面变化还会增加失败机会。

WebMCP 的思路是让页面直接提供工具。原文将它描述为 Google 提出的实验性浏览器标准，目前仍处于早期预览，可通过 Chrome 实验开关 chrome://flags/#enable-webmcp-testing、Chrome Origin Trials、部分智能体浏览器，以及 Cloudflare Kitesurf 等开发环境使用。

例如，用户要求寻找价格低于 140 美元、尺码为 10 的防水越野跑鞋，并加入购物车。支持 WebMCP 的智能体可以从 document.modelContext 发现工具，调用 search_products({ query: "trail running shoe", max_price: 140, size: 10 })，随后调用 add_to_cart({ product_id: "shoe_123" })。

这里也有一个不能略过的缺口：示例参数没有表达「防水」，加购参数也没展示具体规格如何绑定。两次调用说明了交互方式，但不能证明整个选品过程已经满足要求。

结构化工具能减少猜按钮，却不能替智能体保证选品正确。

浏览器里的购物会话为什么重要

Commerce.com 同时提供服务端 MCP 和 WebMCP。前者服务于直接连接商店的智能体，例如跨多个网站购物的助手；后者服务于在消费者浏览器里工作的智能体。按作者的描述，两边使用同一套购物工具，商家不用分别维护两套业务能力。

WebMCP 工具在商店域名下、用户当前的浏览器会话中执行，因此智能体看到的是该会话里的价格和购物车，加购结果也会实时反映到页面上。原文强调，凭据不会交给第三方，访问仍发生在商家网站。

Cloudflare 则承担边缘交付层的角色，把 Commerce.com 后端 MCP server 的工具定义和动作请求原样代理过去。商品查询、购物车和结账流程的逻辑，仍由商家的后端决定。

最后购买也保留了人工步骤：用户准备好后，自己点击 checkout。对商家而言，这套设计的吸引力是既能接住智能体带来的购物需求，又能继续掌握站内体验和结账流程。

不过，「凭据不交给第三方」并不等于整套系统已经得到安全验证。原文没有展开工具授权、敏感操作确认或提示注入防护，无法据此判断全部安全边界。

近十万个域名，怎样统一开启又允许单店退出

Cloudflare 在 8 月推出了 WebMCP 边缘实现的 beta。开启后，边缘节点注入一个小脚本，站点所有者不必自行编写接入代码。

Commerce.com 已经通过 Cloudflare 承载近 100,000 个域名，但这些商家自定义域名共享 zone，而最初的 WebMCP 配置只有整个 zone 的开关。平台需要批量接入，单个商家又必须能够退出。

他们复用了 Configuration Rules 和自定义主机名元数据，没有另外建设复杂的允许名单。下面的规则根据商家元数据关闭对应店铺的 WebMCP：

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

要看清 expression 这一行：它比较的是字符串 "true"。商家在 Commerce.com 后台退出后，对应元数据就能让边缘规则生效。

按作者的说明，规则在页面交付前执行，退出店铺不会触发远程查询，也不会注入脚本，因而没有额外延迟。这个结论针对退出路径，不能扩展成开启功能后也没有性能成本。

另一个实际问题是路径。mcp-server-client toolpack 原先默认 MCP server 位于 /mcp，而 Commerce.com 使用 /api/mcp。为此，Cloudflare 增加了 zone 级 MCP URL 配置，并把它传给注入脚本：

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

关键是 data-mcp-url="/api/mcp"：接入层适应业务端点，商家不必迁移现有路径。如果 MCP server 离线，或浏览器不支持 WebMCP，脚本会退出，店铺继续正常加载。

我的判断

这次合作最有参考价值的是接入方式：购物能力留在后端，浏览器复用现有会话，边缘层负责分发和配置。对于已有多租户平台，这比要求每个商家修改主题更容易推广，也能让退出机制跟着现有租户配置走。

它的前提同样明确。Commerce.com 已有后端 MCP server，也已使用 Cloudflare for SaaS 承载大量商家域名。普通团队若还没有工具接口、租户元数据和统一流量入口，「不用写一行代码」只适用于最终商家，平台侧仍有建设成本。

与模拟点击相比，显式工具接口更少依赖页面布局，这个判断有充分的工程直觉支持。但作者没有提供成功率、token 消耗、响应时间或成本的对照数据，「更快、更便宜、更可靠」目前仍是定性判断。

近 100,000 个域名也代表平台规模，不能当成已经完成同等规模效果验证的证据。加上 WebMCP 仍是实验性提案，更合适的态度是验证接入价值，同时保留兼容和回退能力。

能拿来做什么

• 如果正在给电商站接入浏览器智能体，可以先把搜索、规格查询和加购做成明确的工具接口，并检查用户条件是否完整进入参数，尤其是尺码、颜色和防水这类约束。
• 如果负责多租户 SaaS，可以借鉴「平台开启、租户退出」的配置方式，把开关放进已有租户元数据，并在交付页面前决定是否注入脚本。
• 如果负责前端接入，应把浏览器不支持、MCP 服务离线作为明确的回退场景，验证脚本退出后页面和人工购物流程是否仍正常。
• 如果要向团队证明改造收益，应对同一批购物任务比较页面操作与工具调用的完成率、耗时和 token 消耗，再决定扩大范围。