2026 年 10 月的 WebMCP：让网站能被 AI 智能体使用，以及源试用究竟意味着什么

WebMCP 让网页向 AI 智能体提供一份简短的清单，列出智能体可以做的事，每一项都有名称、描述和输入模式（input schema），而不是让智能体靠截图和 DOM 去琢磨这个页面。智能体发现 check_order_status 工具后，传入订单号就能调用它。没有这个工具，智能体就得自己找到正确的字段，再点中正确的按钮。

这是它的承诺。但截至 2026 年 10 月 22 日，实际情况比大多数文章讲的要窄。WebMCP 是 W3C 社区组的一份提案，还不是标准。Chrome 以源试用（origin trial）的形式运行它，尚未决定正式发布。调用这些工具的消费级智能体只有一个（ChatGPT 桌面应用内置的浏览器），而且它不支持声明式的表单版本，这一版本已于 10 月 8 日从规范中移除。Safari 的引擎团队反对该提案，Mozilla 持中立态度。

本文写给正在判断现在是否要加入 WebMCP 的开发者和产品负责人。内容包括：这套 API 是什么、谁来调用、如何为真实访客启用、如何编写不会递给智能体一把上了膛的枪的工具，以及如果您希望智能体能用上您的网站，应当先修什么。

WebMCP 是什么

规范在 document.modelContext 上定义了一套 JavaScript API，页面通过它注册工具：“WebMCP API 使 Web 应用能够向 AI 智能体提供基于 JavaScript 的工具。”一个工具有 name、description 和 execute 回调，还可以有 title、inputSchema（JSON Schema）和 annotations。智能体调用工具时，运行的是页面自己的代码，使用的是用户的会话。

关于它，有三点很容易搞错：

• 它不是标准。这份文件是 Web Machine Learning 社区组的社区组报告草案，并且自己写明：“它不是 W3C 标准，也不在 W3C 标准轨道上。”Chrome 自己的文档称它是“一项拟议中的 Web 标准”。这份报告的日期在 10 月里每隔几天就更新一次，编辑来自 Microsoft 和 Google。
• 里面没有 MCP。规范称，使用它的页面“可以被看作在客户端脚本中实现工具的 Model Context Protocol 服务器”，随后又说它“没有规定工具向浏览器智能体暴露的格式”。Mozilla 的评审说得很直白：“这个名字有误导性……这里没有 MCP。”WebMCP 工具不会连接您后端的 MCP 服务器，也不能取代它。
• 它不会让您被发现。Chrome 的文档自己列出了这一限制：“客户端和浏览器必须直接访问某个网站，才能知道它有没有可调用的工具。”WebMCP 帮助的是已经在您页面上的智能体，对如何被找到则毫无作用。

这套 API 仅限安全上下文，并受 tools 权限策略（Permissions Policy）控制，其默认允许列表是 'self'，因此跨源 iframe 无法注册工具，除非嵌入它的页面允许。

截至 2026 年 10 月 22 日的现状

Chrome 156 是原定试用期的最后一个版本，已于 2026 年 10 月 20 日进入稳定渠道。申请延长的终点 Chrome 162，计划于 2027 年 2 月 2 日进入稳定渠道。延期是否已经生效，无法从试用控制台确认，所以请按“很可能生效但并不确定”来规划。

延期申请解释了 Chrome 为什么想要更多时间：“源试用的反馈提出了对 API 的改进建议，我们正在实施。”在同一个讨论串里，Google 的 Dominic Farolino 写道，团队“希望在延期窗口内进入 I2S”，也就是申请正式发布，并且“命令式 API 比声明式 API 受欢迎得多，所以我们会根据用户需求加大对它的投入。”他还提到，正在做原型的有延续 API（continuation API）、工具稳定性 API（tool stability API），以及对工具大小的限制。您今天依据的 API 将会改变。

到底是谁在调用这些工具

注册工具什么都不需要。使用工具则需要智能体，而智能体的名单很短。

Chrome 自带的测试扩展。Chrome 的文档提供了两个扩展（包括 Model Context Tool Inspector），用于在演示和您自己的页面上试用工具。它们需要您自己的模型 API 密钥，Chrome 还特别说明：“这些扩展与 Chrome 中的 Gemini 无关。”它们是开发者工具，不是客户。

ChatGPT 的内置浏览器。OpenAI 员工于 2026 年 8 月 25 日在其开发者论坛上发帖说，“站点工具是 ChatGPT 对拟议中的 WebMCP 标准的实现。”它的文档设定了条件：特定的模型、最新的桌面应用、企业版工作区需由管理员允许、不支持教育版工作区，并且“是否可用还取决于推送进度”。文档还列出了不支持的内容：“声明式 API：通过 HTML 表单属性定义的工具不能作为站点工具使用”，以及在 iframe 内注册的工具，同源的也不行。OpenAI 的说明很明确：“请使用 JavaScript 在顶层页面中注册工具”。文档没有说明页面是否需要 Chrome 源试用令牌，ChatGPT 才能看到它的工具。

Chrome 中的 Gemini。Google 在 5 月表示它“将很快支持 WebMCP API”。此后我们没有找到任何一手来源说它已经支持。暂时不要围绕它制定计划。

其他所有智能体退回旧办法。各个浏览器中的所有智能体，仍然按老办法读取页面。Chrome 在自己的风险评估里也这么说：“Chrome 中的浏览器智能体可以像以前一样，通过模拟用户行为来操作网站。”OpenAI 则说：“如果没有合适的工具，智能体仍然可以使用其常规的浏览器能力。”没有 WebMCP 的网站，对智能体并不是隐形的。按钮失灵、字段没有标签的网站，对所有智能体来说都很难用。

命令式 API

这是规范所定义的版本，是 ChatGPT 支持的版本，也是 Chrome 说开发者更喜欢的版本。工具封装的是页面已有的逻辑。下面是一个针对已登录客户的只读查询，写法参照 Chrome 的文档和 OpenAI 的特性检测：

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

其中要注意的几点：

• 名称、描述和模式，是模型读到的内容。Chrome 建议每个工具描述不超过 500 个字符，每个参数描述不超过 150 个，工具名和参数名各不超过 30 个，每次工具输出不超过 1.5K 个字符，并说明“这些建议可能会调整”。规范的说明文档（explainer）警告：“暴露过多工具（例如几十个甚至几百个）会严重拖累智能体的表现”，所以只注册当前页面状态需要的工具，其余的用 AbortController 的信号移除。
• execute 的第二个参数带有 AbortSignal，因此被取消的调用可以中止正在进行的请求。
• 注解只是提示。readOnlyHint 标明这是查询。consequentialHint 标明任何会预订、购买、发送、删除或转账的操作，Chrome 的文档说它“允许智能体和浏览器强制要求用户确认”。untrustedContentHint 标明输出中带有评论、用户内容或第三方数据。从 Chrome 156 起还有一个 debugging 注解。
• 页面代码也可以列出并运行工具，用的是 document.modelContext.getTools() 和 executeTool()，工具列表变化时会触发 toolchange 事件。从 Chrome 155 起，向 executeTool() 传入 JSON 字符串化的参数已被弃用。

React、Angular 和 Vue 各有实验性的辅助库，npm 包 webmcp-types 提供 TypeScript 类型定义。较旧的教程里调用 navigator.modelContext 的写法已经过时：规范在 2026 年 5 月 27 日把这套 API 移到了 document 上。

声明式 API：在 Chrome 的试用中，却不在规范里

声明式版本用两个属性，就把现有的 HTML 表单变成一个工具。对老旧、以表单为主的网站很有吸引力，因为其他部分都不用改：

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

在 Chrome 的试用中，“智能体调用 toolname 时，浏览器会让表单获得焦点并填入字段。表单对用户保持可见。”浏览器根据控件来构建参数：控件的名称、<label>、required 以及 <select> 的选项。除非表单带有 toolautosubmit，否则“用户必须手动点击提交才能完成任务”，对于任何会下单或发送销售线索的表单，这正是您想要的。SubmitEvent.agentInvoked 告诉您的处理程序，这是智能体填写的表单；在 preventDefault() 之后调用 respondWith()，就能把结果返回给智能体。请用 addEventListener 在 document.modelContext 上监听 toolactivated 和 toolcancel 事件：从 Chrome 156 起不再支持 window.ontoolactivated 和 window.ontoolcancel。

麻烦在于它的地位。说明文档最近一次变更是在 2026 年 10 月 8 日，标题为“Remove declarative API from the spec for now”，现在写的是，声明式的对应版本“正在单独探索……但目前不属于规范的一部分。”ChatGPT 不支持它。Chrome 仍在试用中记录着它，Google 的 Farolino 也在 Mozilla 的讨论串里主张：“我们认为声明式提案有价值，哪怕只是为了遗留网站，尤其是以表单为主的网站”。请把它看作实验之中的 Chrome 实验：值得一试，但只靠它不明智。

为真实访客启用

一个标志（chrome://flags/#enable-webmcp-testing）可以在您自己的浏览器里启用 WebMCP 以供测试，对访客则不起作用。要让访客用上，页面需要源试用令牌。

1. 在 Chrome 的 WebMCP 试用页面注册您的源。源试用“对所有开发者公开开放”，令牌会“为您的源上的所有用户启用某项功能”。
2. 在每个需要暴露工具的页面上提供令牌，方式是在 <head> 中放 <meta http-equiv="origin-trial" content="...">，或者用 Origin-Trial: 响应头。令牌也可以通过脚本注入。一个令牌对应一个源；一个页面可以带多个令牌。
3. 记得续期。试用延期时，Chrome 会要求注册者“为试用中登记的每个源提供新令牌”，而且“Chrome 会忽略无效或已过期的令牌”。过期的令牌会悄无声息地失效：工具就是不再出现。
4. Edge 需要在 Edge 的试用页面单独注册。其条款要求“在可能的情况下，您同意采用特性检测或优雅降级”。

Lighthouse 的 WebMCP 审核同样需要试用注册，所以没有令牌就去测试的网站，会看到这些审核失败。

编写可以放心调用的工具

规范的安全章节是非规范性的，并且坦率地说明了责任落在谁身上：防止智能体被操纵，“主要是智能体自身安全模型的责任，而不是本规范能够以规范方式强制执行的事情。”不过，被操纵的智能体能造成多大的损害，仍由您的工具决定。

• 提示可以说谎，所以智能体不会轻信。规范写道：“恶意网站可以省略或歪曲这些提示。”OpenAI 则说：“工具的名称，或它声称自己只读取数据，并不能证明它实际做了什么”，其浏览器中的每次调用都要经过安全审查，购买及类似操作仍需确认。即便如此，也请如实标注。谨慎的智能体正是据此决定何时询问用户。
• 准确描述影响。规范自己举的反面例子，是一个描述为“结算当前购物车”的工具，却“实际触发了一次购买。用户并不想买任何东西。”如果某个工具会从银行卡扣款，描述里就要写明，并且把 consequentialHint 设为 true。
• 每一次都在服务器上授权。工具使用的是用户的会话：规范指出，“智能体能够继承浏览器中用户的身份和认证上下文。”工具调用就是该用户发出的一次请求，要接受同样的检查。说明文档里的建议依然成立：“在代码中严格校验，在模式中宽松定义”，因为严格的模式校验失败，可能让智能体卡住。
• 为提示注入做好准备。规范把它列在第一位，分为三种形式：隐藏在工具元数据中的指令、隐藏在工具输出中的指令，以及把工具当作攻击目标的攻击。输出中带有他人所写文本（评论、消息、商品问答）的，应归入 untrustedContentHint，并作为数据返回，而不是智能体可能当作指令的行文。
• 有意识地让某些页面退出。Permissions-Policy: tools=() 响应头会让该文档及其嵌入的所有内容都无法使用这套 API。账户设置、支付页面和管理界面都值得考虑。

关于 Chrome 的文档，有一点要提醒：它的安全页面说，草案中包含一个 requestUserInteraction() 方法，用于在工具运行中途询问用户。但 2026 年 10 月 20 日的规范草案里没有这个方法，说明文档也仍把用户确认列为悬而未决的问题。不要围绕它做设计。

Safari 和 Firefox 的工程师反对什么

即使您只为 Chrome 开发，这些反对意见也值得一读，因为它们描述了 WebMCP 在实践中可能出什么问题。

WebKit 的立场发布于 2026 年 6 月 3 日，主张难用的页面应当用 HTML 和 ARIA 来修复，“因为用户、辅助技术和智能体都能从中受益”，而用了工具，“脆弱性只是从 DOM 转移到了工具描述里”。它把智能体看作不该被单独区别对待的辅助技术：“WebMCP 恰恰相反，它让‘有智能体在操作’成了一个可观察的事实。”它还指出，该提案“对于有后果的操作，没有同意和可撤销的模型”。

Mozilla 在 8 月定为中立：WebMCP“引入了一个可能很有价值的抽象”，但“开辟了一个现实运行规律还有太多悬而未决的问题的层面，因而无法全心支持”。它警告说，网站可能“提供与页面上用户体验不符的工具”，例如“提供对普通用户不可见的提示注入”。Mozilla 的个别工程师对命令式的函数调用原语表示过兴趣，但这不代表 Mozilla 的认可。

Chrome 自己认为，其他引擎不采纳 WebMCP，对用户造成的风险较低。反过来说，就是今天在网站上添加工具，在 Safari 或 Firefox 里不会有任何收益。

对所有智能体今天都有效的做法

所有浏览器智能体读取的都是截图、HTML 和无障碍树。Google 关于对智能体友好的网站的 web.dev 指南说，智能体“利用 DOM 和无障碍树得到一份干净、结构化的可交互元素列表，再与视觉渲染结果相互对照”。它给出的实用清单很短：

• 使用真正的 <button> 和 <a> 元素，而不是可点击的 <div> 和 <span>。
• 用 for 把每个 <label> 与其输入框关联起来。
• 可交互元素上不要有透明的遮罩层，也不要有小于 8 平方像素的可交互元素。
• 布局稳定，不会在智能体即将点击时发生位移。

它的结论是：“我们为让网站‘适合智能体’所提的每一条建议，也会让网站对人更友好。”这几乎一字不差，就是 WebKit 用来代替 WebMCP 的主张。如果您的结账页面通不过无障碍审核，请先修好它，再去写任何一个工具。

Lighthouse 自 13.2.0 版本（2026 年 5 月 1 日）起有了“智能体浏览”（Agentic Browsing）类别，Chrome 从 150 版本起可用，并在 Lighthouse 13.4.1（2026 年 7 月 20 日）中为 PageSpeed Insights API 启用。它检查的内容包括：对机器重要的那部分无障碍审核、布局稳定性、已注册的 WebMCP 工具和没有工具的表单、schema 的有效性，以及是否存在 llms.txt 文件。Chrome 称它“仅供参考，没有基准”：没有 0 到 100 的评分。关于 llms.txt，Google 搜索自己的指南是，它不使用这类文件：添加一个“既不会损害也不会帮助您的网站在 Google 搜索中的可见性或排名”。Lighthouse 检查这个文件，并不改变这一点。

现在该加入 WebMCP 吗

使用 Shopify 的 Liquid 主题：无需做任何事。Shopify 的店面、购物车和结账工具已经上线，“无需安装或配置任何东西”，Shopify 自己也提醒，“目前只有基于 Chromium 的浏览器通过源试用支持智能体”。无头店面仅在 Hydrogen 开发者预览版中得到覆盖。我们没有找到其他任何电商平台、支付服务商或 CDN 会为其客户开启 WebMCP。

使用自主开发、无头或遗留系统的网站：取决于您的用户是谁。

• 如果您的客户或员工使用 ChatGPT 桌面应用的浏览器，那么顶层页面中的命令式工具是唯一能触达他们的类型。先围绕您最常见的任务（订单状态、库存情况、报价）做两三个只读工具，放在特性检测之后，带上源试用令牌，然后看有没有人调用。
• 如果您想在 Chrome 里低成本地试验，在现有表单上加声明式属性只需几个小时。但不要止步于此：ChatGPT 看不到它们，规范里也已经没有它们了。
• 如果您没有证据表明智能体会来访问您，请先修好语义、标签和布局。这些工作对每个智能体和每位使用辅助技术的人都有帮助，API 变化时也不会有任何一点被白费。

无论哪种情况，都要保持常规界面完整。OpenAI 的建议是：“为不支持 WebMCP 的用户和浏览器保留常规界面。”

还可能发生什么变化

• Intent to Ship。Chrome 团队希望在延期窗口内提出申请，如果延期成立，窗口随 Chrome 162（2027 年 2 月 2 日）结束。正式发布后，Chrome 中将不再需要令牌。
• API 的形态。延续 API（导航之后落在下一个页面上的结果）、工具稳定性 API 和大小限制正在做原型。近期的版本已经移除了 window.ontoolactivated 和字符串化的参数。
• 声明式 API 的命运。“暂时”移出了规范，仍留在 Chrome 的试用中。
• 调用方。Chrome 中的 Gemini 支持已宣布但尚未推出。规范的实现状态页面列出：Meta Ray-Ban Display 眼镜上的网页应用对 WebMCP 的支持即将推出，Brave 的 Leo 助手则有实验性支持。

如果您现在就加入工具，请把它们放在同一个模块里，放在特性检测之后，这样下一次变更只需改一处。

从哪里获得帮助

我们开发网站及其后端中智能体会触及的部分：封装现有订单、预订和账户逻辑的工具，把智能体的调用与该用户的其他请求同等对待的授权，以及在任何工具出现之前就让网站可用的语义和无障碍修复。我们的 AI 智能体开发与 MCP 集成服务既涵盖 WebMCP 工具，也涵盖后端 MCP 服务器，尽管名字相似，二者是不同的东西。

如果您想了解，智能体今天在您的网站上看到了什么，以及工具是否会给您的客户带来改变，请写信到 office@c9group.dev。