WebMCP抢先预览：浏览器成AI执行层，网站正式API化

WebMCP 是 Chrome 新推的浏览器 API，让网站通过 JavaScript 或 HTML 直接向 AI 代理暴露结构化工具，无需截图或后端 MCP 服务器，大幅降低 token 消耗、提升准确率，谷歌微软联合推动，现已可在 Chrome Canary 试用。

现在的AI智能体想要操作网页，基本上就两条路可以走，但这两条路都坑坑洼洼让人头疼。第一条路叫截图点击流，也就是所谓的视觉代理方案。AI先截个图，然后用视觉模型分析这图里都有啥，再模拟鼠标点击和键盘输入。这方案能跑通，但跑起来像个重度近视的老大爷在摸黑找门把手。每截一次图就要消耗几千个token，简单操作还好，复杂流程直接让算力账单爆表。更惨的是网页UI稍微改个按钮位置，AI立马变成无头苍蝇，之前的训练数据全白费。

第二条路是后端MCP服务器，网站自己搭个独立的服务器，用Model Context Protocol把功能暴露给AI。这方案稳是稳，但门槛高得吓人。小公司根本玩不起，需要单独维护一套API接口，相当于为了给AI用专门盖了栋副楼。大多数网站连人类用户的体验都还没打磨好，哪有余力给AI开VIP通道。结果就是AI智能体在网页世界里像个没地图的外地游客，要么靠猜要么靠钱，体验极差成本极高。

WebMCP的出现直接开辟了第三条路，而且这条路走起来特别顺。网站本身主动告诉AI自己能做什么，而不是让AI去猜。AI不再需要盯着像素琢磨这个红色按钮是不是"加入购物车"，网站直接注册一个结构化的工具，名字叫add_to_cart，描述写得清清楚楚，输入参数规定得明明白白。AI调用这个工具就像调用本地函数一样自然，网站收到调用后执行原有的前端JavaScript逻辑，完事儿把结构化数据返回给AI。没有截图开销，没有DOM解析的麻烦，不需要单独的服务器，现有的前端代码直接变身AI接口。这种转变让网页从被动展示变成了主动服务，AI从猜测者变成了调用者，整个交互逻辑彻底翻新。

WebMCP给浏览器加了个全新的API接口，名字叫navigator.modelContext。这名字听起来挺技术，但功能直白得很。网站通过这个接口注册工具，AI通过这个接口发现和调用工具，中间不需要任何翻译官。注册工具有两种玩法，一种是JavaScript的命令式API，适合需要精细控制的场景；另一种是HTML的声明式API，适合简单的表单操作，连JavaScript都不用写。

JavaScript方式的控制力拉满。开发者写一个函数，用JSON Schema描述输入参数的类型和含义，然后注册到navigator.modelContext里。举个实际的例子，一个电商网站想要让AI能帮忙加购物车，代码长这样：

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'add_to_cart',
    description: 'Add a product to the shopping cart',
    inputSchema: {
      type: 'object',
      properties: {
        productId: {
          type: 'string',
          description: 'The product ID to add'
        },
        quantity: {
          type: 'number',
          description: 'How many to add'
        }
      },
      required: ['productId', 'quantity']
    },
    async execute({ productId, quantity }) {
      const result = await addToCart(productId, quantity);
      return {
        content: [{
          type: 'text',
          text: JSON.stringify(result)
        }]
      };
    }
  });
}

就这么几行代码，AI智能体现在可以在完全不触碰UI的情况下把商品加入购物车。它不需要知道购物车按钮在哪里，不需要识别商品图片，直接调用add_to_cart函数，传入正确的productId和quantity参数，网站原有的addToCart()函数正常执行，AI拿到结构化的返回结果。整个过程没有视觉识别的不确定性，没有模拟点击的延迟，没有DOM结构变化带来的脆弱性。现有的业务逻辑一点不用改，只是多了一层AI调用的入口。

HTML方式更适合快速上手。现有的表单只要加几个属性就能变身AI工具，连JavaScript都不用碰。比如一个航班搜索表单：

<form toolname="search_flights"
      tooldescription="Search for available flights"
      action="/api/search">
  <input name="origin"
         toolparamdescription="Departure airport code (e.g. SFO)" />
  <input name="destination"
         toolparamdescription="Arrival airport code (e.g. JFK)" />
  <input name="date" type="date"
         toolparamdescription="Travel date in YYYY-MM-DD" />
  <button type="submit">Search</button>
</form>

浏览器自动读取这些属性，把这个表单暴露为AI可调用的工具。AI填写字段并提交，服务器端收到的请求和人类提交的一模一样。甚至还有个CSS伪类:tool-form-active，可以让表单在被AI使用时显示不同的样式，还有个SubmitEvent.agentInvoked布尔值，让服务器知道这次提交是人类还是AI发起的。这种设计既照顾了AI的需求，又没有破坏人类的用户体验，两边各取所需互不干扰。

Chrome团队和MCP-B项目的早期基准测试给出了实打实的数字，这些数字说明WebMCP不是那种"感觉更快"的玄学优化，而是真金白银的成本削减。看这张对比表就明白了：简单任务每个动作的token消耗从3801个暴跌到433个，降幅89%；复杂任务从8000+个降到1800个左右，降幅77%；计算开销直接砍掉67%。

这些数字意味着什么？意味着以前浏览网页的AI智能体在经济上根本跑不通，现在突然变得有利可图了。一个简单的计数器任务，用截图方案要烧掉3801个token，用WebMCP只要433个token。这不是百分之几的边际改进，这是数量级的飞跃。从"成本太高放弃治疗"到"成本可控可以商用"，中间就隔着一个WebMCP的距离。对于需要频繁操作网页的AI应用，比如自动化测试、数据抓取、智能助手，这种成本结构的变化直接决定了商业模式是否成立。

任务准确率的数据同样亮眼，达到了约98%。截图方案受限于视觉识别的准确率，按钮识别错误、文字理解偏差、坐标计算失误都是家常便饭。WebMCP用结构化调用替代像素猜测，从根本上消除了这些不确定性。AI调用的是明确定义的函数，传入的是类型校验过的参数，执行的是网站原有的业务逻辑，返回的是格式规范的数据。整个链条都是确定性的，没有猜测环节，准确率自然飙升。

计算开销降低67%也是个关键指标。截图方案需要运行视觉模型，无论是本地部署还是云端调用，都是吃资源的大户。WebMCP只需要处理JSON数据的序列化和函数调用，计算量小了一个数量级。这意味着同样的硬件资源可以支撑更多的并发任务，同样的任务可以用更便宜的硬件完成。对于需要大规模部署AI智能体的企业，这种效率提升直接转化为竞争优势。

WebMCP的幕后推手阵容堪称豪华，Google和Microsoft的工程师通过W3C Web Machine Learning Community Group联合开发。规格编辑有三位大神：Brandon Waldman来自Microsoft，Khushal Sagar和Dominic Farolino来自Google。当两个最大的浏览器厂商坐下来一起写规范， adoption基本就是时间问题。这不是某个公司的私货，而是行业共识的技术方向。

规范在2026年2月10日作为W3C社区组草案正式发布。这还不是最终标准，但已经进入了标准化流程。Chrome 146 Canary版本已经可以通过实验标志开启这个功能，Chrome 146稳定版预计在2026年3月10日左右发布。从草案到浏览器实现只有一个月，这个速度在Web标准历史上都算快的。Firefox和Safari还没官宣支持，但有了W3C的框架和两大厂商的示范，跟进只是时间问题。

这种厂商级别的合作传递了一个明确信号：WebMCP不是昙花一现的实验，而是Web平台演进的主线剧情。开发者可以放心投入，不用担心今天写的代码明天就被废弃。标准化进程保证了技术的开放性和互操作性，任何遵循规范的实现都能互相兼容。对于需要长期技术规划的企业，这种背书至关重要。

对于前端开发者，WebMCP意味着全新的接口层面。网站不仅需要声明能做什么，还需要考虑如何被AI理解和调用。好消息是技术栈没有变化，还是熟悉的JavaScript，registerTool() API直观易懂。坏消息是设计思维需要升级，现在要考虑工具可发现性、Schema设计质量、AI如何解读描述文本。

"Add to cart"对人类来说就是看按钮文字，但对语言模型来说需要更精确的语义理解。是添加到购物车还是立即购买？是添加单个商品还是批量操作？支持哪些支付方式？这些细节在Schema和描述中必须明确。前端开发者需要学会用AI的思维方式设计接口，这类似于从设计GUI转向设计API，但受众是自主决策的智能体而非人类程序员。

SEO和增长团队面临同样深刻的变革。Dan Petrovic的"Agentic CRO"概念不是夸张，当AI智能体能调用网站的结构化工具，那些提供最佳工具实现的网站将获得更多流量。工具描述成为新的meta description，Schema设计成为新的结构化数据。这是真实的竞争维度，而且刚刚开启。

DevRel团队需要更新文档策略。如果平台有Web界面，WebMCP成为必须覆盖的集成点。开发者会问"如何让我的应用功能暴露给AI智能体"，答案需要包括WebMCP alongside REST/GraphQL APIs。编写优秀的工具描述，清晰无歧义，类型定义完善，这是DevRel的核心能力领域。

产品团队的问题从"人类如何使用我们的产品"变成"人类和智能体如何协作使用我们的产品"。声明式API让实验成本极低，给现有表单添加toolname和tooldescription属性不需要后端改动，就能观察智能体如何与之交互。这种低门槛的实验方式适合快速验证AI协作场景。

WebMCP并不取代后端MCP服务器，它们解决不同的问题。WebMCP运行在浏览器标签页中，需要用户在场共享上下文，继承会话cookie进行身份认证，适合协作式工作流，设置成本低只需添加JavaScript到现有页面，但无法脱离浏览器运行。后端MCP服务器运行在服务器上，智能体独立行动，使用OAuth或API密钥认证，适合自动化流水线，需要构建和部署服务器，但支持无头环境。

关键区别在于用户 presence。WebMCP用于人类在场观看、智能体在其会话内操作的协作场景。后端MCP用于智能体独立运行的自主流水线。一个旅行网站可能用WebMCP让智能体在用户观看和批准时搜索航班，同时用后端MCP服务器让智能体夜间检查价格并在票价下降时发送通知。两种方案各司其职，共同构成完整的AI集成策略。

最快的从零到工作WebMCP集成路径有四种选择。第一种是原生API，需要Chrome 146 Canary并开启chrome://flags/#enable-webmcp-testing标志：

navigator.modelContext.registerTool({
  name: 'get_product',
  description: 'Get product details by ID',
  inputSchema: {
    type: 'object',
    properties: {
      id: { type: 'string', description: 'Product ID' }
    },
    required: ['id']
  },
  async execute({ id }) {
    const product = await fetch(<code>/api/products/${id}</code>).then(r => r.json());
    return {
      content: [{ type: 'text', text: JSON.stringify(product) }]
    };
  }
});

第二种是MCP-B Polyfill，支持任何浏览器，先npm install @mcp-b/global，然后在应用入口导入import '@mcp-b/global'，之后navigator.modelContext API完全可用。

第三种是React Hook方式，import { useWebMCP } from '@mcp-b/react-webmcp'，配合Zod进行类型定义：

import { useWebMCP } from '@mcp-b/react-webmcp';
import { z } from 'zod';

function TodoApp() {
  const [todos, setTodos] = useState([]);

  useWebMCP('add_todo', {
    description: 'Add a new todo item',
    schema: z.object({
      title: z.string().describe('The todo title'),
      priority: z.enum(['low', 'medium', 'high'])
    }),
    handler: async ({ title, priority }) => {
      const newTodo = { id: Date.now(), title, priority, done: false };
      setTodos(prev => [...prev, newTodo]);
      return { content: [{ type: 'text', text: <code>Added: ${title}</code> }] };
    }
  });

  return <div>{/* your UI */}</div>;
}

第四种是零构建HTML方式，给现有表单加属性即可：

<form toolname="subscribe"
      tooldescription="Subscribe a user to the newsletter"
      action="/api/subscribe"
      method="POST">
  <input name="email" type="email"
         toolparamdescription="User email address" required />
  <button type="submit">Subscribe</button>
</form>

关键日期一目了然：2026年2月10日W3C社区组草案发布；2月11日Chrome团队宣布早期预览；2月12日Chrome 146 Canary可用；预计3月10日Chrome 146稳定版发布；2026年中期待更广泛的浏览器支持。这个节奏在Web标准领域算快的，说明厂商推动力度很大。

WebMCP不是孤立存在，它是 growing stack的一部分。MCP（Anthropic）是后端协议，智能体在服务器上调用工具，这是WebMCP扩展的原始标准。WebMCP（W3C）是前端协议，网站在浏览器中暴露工具。MCP-B（WebMCP-org）是桥梁，Chrome扩展连接浏览器端WebMCP工具到桌面MCP客户端，添加跨站工具协作能力。MCP Apps（Anthropic）是交互式UI扩展，把智能体工具变成人类可用的界面。

这些组件形成闭环：网站暴露工具给智能体（WebMCP），智能体暴露UI给用户（MCP Apps），一切通过同一协议层（MCP）连接。这个生态正在快速成熟，从协议到实现到工具链都在2026年初集中爆发。

规范本身标记了几个未解决领域，这种坦诚态度反而增加了可信度。

工具大规模发现问题：如果每个网站暴露50个工具（推荐的最大值），智能体如何高效发现跨Web的相关工具？多智能体冲突问题：当两个智能体同时尝试使用同一网站的工具时会发生什么？

无头场景限制：WebMCP需要浏览器，服务器端渲染和无头环境没有navigator.modelContext。

原生支持缺失：目前只有Chrome 146 Canary支持，Firefox和Safari未官宣，虽然@mcp-b/global polyfill暂时填补空白。

规范不稳定：规范中有多个TODO占位符，API表面在标准化前会变化。

这些限制不是致命缺陷，而是发展中的正常状态。W3C流程就是为了在标准化前充分讨论这些问题，浏览器实现也会随着规范成熟而更新。对于早期采用者，风险是API可能变化需要重写代码；对于保守派，等待稳定版是更稳妥的选择。

1、 智能体网络的结构化互动
WebMCP 提出了两项新 API，允许浏览器代理代表用户执行操作：

• 声明性 API：执行可直接在 HTML 表单中定义的标准操作。
• 命令式 API：执行需要 JavaScript 执行的复杂、更动态的互动。

2、使用场景
设想一下，一个能够自信而快速地为用户处理复杂任务的智能体。

• 客户支持：通过使代理能够自动填写所有必要的技术细节，帮助用户创建详细的客户支持服务工单。
• 电子商务：如果代理可以轻松找到用户所需的产品、配置特定的购物选项并精确地完成结账流程，用户就能更好地选购您的产品。
• 旅游：用户可以更轻松地找到所需的航班，因为代理可以使用结构化数据进行搜索、过滤结果和处理预订，从而确保每次都能获得准确的结果。

今天如何尝试

1. 下载Chrome Canary（版本146+）
2. 转到chrome://flags/#enable-webmcp-testing
3. 启用“WebMCP for testing”标志
4. 重新启动Chrome

开发者社区在48小时内构建了什么

采用的速度确实令人惊讶。以下是公告发布后两天内出现的内容：

1、MCP-B-浏览器桥
Alex Nahas，以前在亚马逊工作，在W3C规范存在之前就构建了MCP-B（浏览器的“B”）。它最初是亚马逊的一个内部解决方案，后端MCP服务器无法访问经过身份验证的Web应用程序，因为它们缺乏会话cookie。

MCP-B是一个Chrome扩展程序，它可以从所有打开的选项卡中收集WebMCP工具，并将它们连接到桌面MCP客户端，如Claude Desktop或Cursor。它还包括内置的AI代理，可以帮助您在不离开浏览器的情况下创建WebMCP工具。

该项目现在提供了@mcp-b/global polyfill，它将navigator.modelContext添加到还没有原生支持的浏览器中，加上一个分叉的Chrome DevTools MCP服务器，它公开了list_webmcp_tools和call_webmcp_tool功能。

2、五个框架示例
WebMCP-org/examplesrepo在五个框架中提供了生产就绪的演示：

1. 纯 TypeScript 购物车 navigator.modelContext.registerTool()
2. React 任务管理器 useWebMCP() 钩子 + Zod 验证
3. Rails 7 书签管理器 Stimulus 控制器集成
4. Angular 19 笔记应用 Angular signals + 服务
5. Phoenix LiveView 计数器 + 项目列表 Elixir 服务端状态同步

社区成员在数小时内添加了Vue和Nuxt 3实现。

3、DoorDash-Style食品订购演示
Pietro Schirano为DoorDash-like食品订购应用程序构建了一个入门模板，其中AI代理将物品添加到购物车，配置选项并导航结账-所有这些都通过WebMCP工具调用，从不接触UI。

4、带代理控制的TODO应用程序
日本开发人员@azukiazusa9构建了一个干净的TODO应用程序演示，显示navigator.modelContext.provideContext注册添加，删除和列表工具。他们的视频展示了一个人工智能代理通过结构化工具调用创建和管理TODO项目。

5、旅行预订参考应用程序
Chrome团队在travel-demo.bandarra.me发布了一个实时旅行预订演示，演示了两种API-用于航班搜索的声明性HTML表单和用于复杂行程构建的命令式JavaScript。这是官方的参考实现。

6、Chrome DevTools快速入门
DevTools快速入门展示了一个开发循环，其中AI编写WebMCP工具，Vite热重载，AI测试自己的工具并迭代。包含的三个示例（get_page_title、get_counter、set_counter）演示了该模式。