WebMCP 让网页自己交出工具：Amazon 在挡 AI，Shopify 已经在请 AI 结账

先说一个反差很大的事。Amazon 和 Adidas 正在把 AI 代理挡在结账流程外面，据 TechCrunch 的报道口径，这两家选的是不让它进来。Shopify 反着做：2026 年 9 月 28 日，Shopify 开发者 changelog 宣布结账支持 WebMCP，包含 Shop Pay，向所有 eligible merchants 开放。

一边关门，一边把钥匙递出去。

一、AI 操作网页，一直都很别扭

过去两年，AI 操作网页这件事始终有点滑稽。代理要读你的页面代码，猜哪个元素是按钮，再模拟一次点击。你改个 class，它就瞎了。换个布局，它就开始乱点。

WebMCP 换了个思路：不让代理猜，让网页自己把能力交出来，交成一个个有名字、有输入 schema 的函数。

如果你是做前端的，这事的重量大概接近当年 AJAX 出来的时候。如果你只是用 AI 工具的人，它意味着以后 AI 在你登录着的网页里干活，可能真的不用再装作在乱点了。

二、它到底动了哪一刀：不是 MCP 的浏览器版

结论先放这：它不是 MCP 的浏览器版，别这么理解。

名字里带 MCP，是因为 tool 的形状跟 MCP 协议一致。但传输层完全是另一回事。服务端 MCP 走 HTTP 加 JSON-RPC，WebMCP 走的是 JavaScript 堆，网页和代理在同一个浏览器里，直接函数调用，中间没有网络那一跳。

这一刀砍在三个地方。

第一，它跑在用户的登录态里。cookie、IndexedDB、per-tab 状态，全都在。代理不用再为了登录这件事跟你掰扯。

第二，你不用新起传输，不用托管，不用扩容。加一段注册代码，工具就活了。

第三，工具可以跟已有 MCP 工具同名同 schema，一起发给模型。你之前攒的服务端 MCP 工具不白攒。

对比一下传统路子：以前代理靠读页面代码加模拟点击，现在直接调结构化接口。有社区整理的口径说 token 消耗能降一个数量级，但这个数字没有官方背书，你当趋势看，别当承诺。

顺带说一句，腾讯 BrowserSkill 这类浏览器代理方案，走的还是看页面再点页面的路子。WebMCP 想做的是让这一层直接消失。

三、现在到底能用到什么程度

分三条线看，别混在一起。

标准化这条线：提案在 W3C Web Machine Learning 社区组孵化，当前状态是 Draft Community Group Report。官方原话是 “It is not a W3C Standard nor is it on the W3C Standards Track”。翻过来就是：还不是标准，也不在标准轨道上。

浏览器这条线：Chrome 149 有 origin trial 在跑，Edge 150 也有。Chrome 文档还明确写了，这个 API 主要面向 local browser workflows with a human in the loop，也就是有人工参与的本地浏览器工作流。这句话很重要，后面讲结账的时候你还会再见到它。

落地这条线：Shopify 走得最快。8 月开始，storefront 和 cart 的 WebMCP 工具已经在每个 Liquid 店面和 Hydrogen developer preview 上可用；9 月 28 日结账也开了。

所以如果你问现在能不能上，答案分叉：想在自己页面上试，Chrome 原试用里能跑；想真接电商结账，Shopify 那条路已经全量。

网页把工具注册给浏览器里的代理，而不是让代理去猜页面元素

四、动手：给你的页面注册第一个工具

核心就一个方法，registerTool。

async function addTodo({ text }) {
  return { ok: true, text };
}
await document.modelContext.registerTool({
  name: "add_todo",
  description: "Add a task to the list",
  inputSchema: {
    type: "object",
    properties: { text: { type: "string" } }
  },
  execute: addTodo
});

几个要点。API 面是 document.modelContext，早期草稿和部分实现暴露成 navigator.modelContext，两种写法你都会看到，别慌。execute 是 async 函数，接一个参数对象，返回结果。

想给模型更多提示，加 annotations；想随组件卸载，用 AbortSignal。

annotations: { readOnlyHint: false, untrustedContentHint: true }

const controller = new AbortController();
await document.modelContext.registerTool(tool, { signal: controller.signal });
controller.abort();

abort 之后，同名工具可以再注册。这个对组件生命周期很有用。React 那边有实验性的 useWebMCP，Angular 也有实验性支持，都是实验性，别当稳定依赖。

五、代理怎么发现和执行

发现用 getTools，返回当前文档有权访问的工具列表，按字母序，默认只给同源。要拿跨源工具就传 fromOrigins，而且只支持安全来源。执行用 executeTool，工具列表变了监听 toolchange。

const tools = await document.modelContext.getTools();
await document.modelContext.getTools({ fromOrigins: ["https://partner.org"] });
await document.modelContext.executeTool(tool, '{"text":"Buy milk"}');
document.modelContext.addEventListener("toolchange", (e) => {});

这里有个特别容易写错的地方：executeTool 的第二个参数是 JSON 字符串，不是对象。写成对象会静默失败，README 里通常不提醒。

跨源 iframe 默认不给注册工具，必须用 Permissions Policy 委派。

<iframe src="https://example.com" allow="tools"></iframe>

注册侧对应写 exposedTo: [“https://example.com”]。两边都要配，少一边就没工具。

结账的四个工具，最后一步之前必须有人点头

六、Shopify 那四个结账工具

四个工具，名字都很直白。

get_checkout

读当前结账状态。买家下单后在 Thank you 页调用，返回订单收据。金额是货币最小单位的整数，拿到 1299 就是 12.99。

update_checkout

替换买家的联系方式、配送方式、折扣码、声明字段和支付信息。两个硬性语义：它是 PUT 语义，你必须先拿一次最新的 get_checkout 响应，再构造完整目标状态，不能只传增量；它忽略 line items，改商品这件事留给买家在页面上做。

complete_checkout 与 navigate_to_storefront

前者是买家确认之后下单。后者是离开结账回店面，只有店铺有线上店面时才注册。

它实现的是 UCP（Universal Commerce Protocol）的 dev.ucp.shopping.checkout capability，只不过用浏览器注册的工具，而不是服务端 JSON-RPC。跟 Shopify 服务端那个 Checkout MCP 共享同一套 checkout 对象、状态和消息。

人必须留在环里，这是文档原话级别的硬要求：Before you call complete_checkout, show the buyer the current order and total, and get their permission to place it。Web Bot Auth、Shop Pay approval、ready_for_complete 状态，都不等于许可。总额变了，要再问一次。3D Secure 认证或者 blocking UI extensions 出现时，工具把控制权交回买家。

支付只接受买家已保存的 Shop Pay 卡，payment.instruments 不收新卡。

代理自己要做 Web Bot Auth：用 Ed25519 签名密钥，公钥托管在 key directory，并向 Shopify 发布该目录。不做的话，可能被 Shopify 的 bot detection 降级或拦截。

不是所有结账都会注册工具。标准三页结账（除非买家走 Shop Pay）、B2B 结账、嵌入式结账和移动端 SDK 结账、含其他店铺商品的结账，这几种都不注册。另外没有 cancel_checkout 的等价工具，checkout 状态永远不会变成 canceled。

如果你是做电商的，用 Codex 做电商那套思路现在可以往前推一步：从让 AI 帮你写店铺代码，到让网页把结账能力直接交给 AI。

Shopify 的 staff PM Gil Greenberg 在 X 上说得很直接：如果代理跑在买家浏览器里，就用 storefront 和 checkout 上的 WebMCP 工具，别去导航给人类写的 HTML。

七、别踩这几个坑

坑 1：把商家返回的文本当成了指令

现象：页面里一段促销文案、一条商品评论、一个卖家自定义的字段，被模型当成了下一步该做什么。

根因：WebMCP 交出的是结构化工具，但工具的返回值里照样能塞自由文本。

解法：返回值当数据，不当指令。annotations 里该标 untrustedContentHint: true 就标。

坑 2：把 origin trial 当成标准

现象：团队按浏览器已经支持了来排期。

根因：W3C 那边还是 Draft Community Group Report，官方明确说不是标准也不在标准轨道上；Chrome 和 Edge 那边是原试用，会变，也会到期。

解法：先在能承受改动的页面上试，API 面从一开始就做成可替换的薄封装。

坑 3：默认所有结账都能用

现象：接完发现一部分订单没工具可调。

根因：B2B、嵌入式、移动端 SDK、跨店商品这几类结账不注册，update_checkout 还忽略 line items。

解法：把 get_checkout 当成唯一事实来源，每次改之前重新拉一次。

坑 4：以为已经拿到了许可

现象：Shop Pay 过了，ready_for_complete 亮了，就直接下单。

根因：文档把这些明确排除在许可之外，它们只代表技术条件满足。

解法：下单前把订单和总额摆给买家看，拿到明确确认。总额变了，重新问一次。

坑 5：钱和责任没分清

现象：只看了技术文档，没看责任条款。

根因：OpenAI 那份 Delegated Payment Spec，跟 Stripe 一起做的 Agentic Commerce Protocol 的一部分，写得很明白。OpenAI 不是 merchant of record，结算、退款、拒付（chargeback）和合规责任留在商家和它的 PSP 身上。同一份 spec 还警告，直接对接它可能要直接处理持卡人数据（CHD），会影响你的 PCI scope。

解法：接之前先让支付和法务过一遍，别让工程先做决定。

卡组织这边按一家电商咨询博客的二手整理：Mastercard 在网络层标记 agent-initiated 交易，持卡人可设单笔与月度上限、允许商户类别和有效期窗口；Visa Core Rules 在 2026 年 4 月加了 agentic transaction 条款，要求身份验证。Amex 推出了 Agent Purchase Protection，保 AI 代理出错导致的扣款，但要求代理注册并发送经认证的购买意图，覆盖范围窄。这些不是一手通稿，看口径就好。