WebMCP：代理使用的第二条通道，就在浏览器里

AI 代理够到你店铺的路有两条，而讨论通常只覆盖其中一条。

服务端那条是 UCP：代理连上 MCP 端点、检索目录、建购物车。另一条完全在浏览器里跑，就在买家正在看的那一页上。它叫 WebMCP，而在 Shopify 上它默认开启。

核心要点

• WebMCP 是一项 Web 标准，让页面向浏览器内的代理注册结构化工具。接口是 document.modelContext，配 getTools() 与 executeTool()。
• Shopify 在每一个 Liquid 店面，以及渲染了 ShopifyScripts 的 Hydrogen 2026-10 店面上自动注册这些工具。
• 约 19 个工具，分五组：目录、购物车、结算、导航、店铺信息。
• 官方说法：代理拿到的是数据，而不是去解析截图。
• search_shop_policies_and_faqs 是你的知识库目前唯一已生效的出口。

工具清单

用函数调用替掉截图，为什么重要

过去两年，浏览器代理操作电商网站靠的是视觉：截图、识别按钮、算坐标、点击、再截图确认。这个循环慢、贵、脆。改版会打断它。Cookie 横幅会打断它。懒加载的价格会打断它。

WebMCP 把这个循环换成了函数调用，对商家有三点变化。

稳定性。 代理依赖的是工具契约，不是像素位置。你改版商品页，购买路径照常工作。对发版频繁的团队，这悄悄消掉了一整类看不见的损坏。

成本。 一次 add_to_cart 调用替代十几次截图与点击。对代理来说更便宜更快，意味着更多购买被完成而不是中途放弃。

可观测性。 工具调用原则上是可测量的，而模拟点击从来不是。商家第一次有路径知道「有多少代理在我店里做了什么」——不过正如归因断裂里写的，报表那一侧还很不成熟。

让它真正重要的那条条款

你自己店铺的 /agents.md 里有一行很容易扫过去："Do not fall back to scripted form fills or page controls."

工具不可用时，代理被要求不要退回去点击，而是把买家交回浏览器。把这条和「一个店面注册了零个 WebMCP 工具」放在一起，结果很具体：代理不会降级回旧的视觉方式，它会离开。

这就把 grep 的结果变成了一个真实的数字。curl -s --compressed https://yourstore.com/ | grep -ci 'modelContext\|webmcp' 返回 0 不是少了个增强功能，而是一扇关上的门。在我们探测的那家 Headless 店上这个计数是 0，而同类 Liquid 店返回五个匹配——完整对比在这里。

和知识库的连接

search_shop_policies_and_faqs 值得单独注意，因为它消费的东西：你在 Sales channels → Agentic → Knowledge base 里发布的事实。

协议侧的 Ask 能力 ask_business 仍是 UCP draft，在一家真实店铺返回给我们的 15 个工具里并不存在。但这个浏览器侧的工具已经在读同一批事实。用浏览器内代理逛你店的买家，今天就能拿到你批准过的答案。

这正是现在就建知识库而不是等协议稳定的实际理由：这份资产已经在被使用了。

实际要做什么

1. 验证注册。 跑 grep。大于 0，否则本文对你不适用。
2. 如果你在 Hydrogen 上，确认版本是 2026-10 并且渲染了 ShopifyScripts，或调用了 initializeShopifyScripts。这是计数为 0 最常见的原因。
3. 测试重要的工具。 用浏览器内代理逛自己的店，试三件事：找一个商品、加入购物车、问一个退货问题。三分钟，比任何审计报告都说明问题。
4. 发布知识库事实，因为 search_shop_policies_and_faqs 已经在读它们。
5. 不要把「默认」当成「正常工作」。 重度定制的主题、改过的结账页、第三方购物车 App 都可能干扰。

常见问题

WebMCP 是 Shopify 发明的吗？ 不是。它是一项正在推进的 Web 标准，让页面向浏览器内代理暴露结构化工具。Shopify 的贡献是在自家店面上默认铺开一套实现——而这正是把一个标准变成一条渠道的东西。

WebMCP 会取代 UCP 吗？ 不会，两者并行。UCP 是服务端对服务端的，支撑跨店发现与代理侧结算。WebMCP 工作在买家已经打开的那一页上。完整图景需要两者——见六层栈。

我能注册自定义工具吗？ Shopify 的默认注册提供的是一套固定工具，不支持。把标准工具当成契约，把投入放在让它们返回好数据上。