Google WebMCP是什么？AI Agent直接调用网页功能的新标准详解

AI Agent正在改变我们使用网页的方式

过去几十年，我们一直在为人类的眼睛和操作习惯构建网页。但如今，使用网页的不再只是人类——AI Agent正在代替用户浏览网页、完成操作。问题在于，当前的Agent需要付出巨大的代价才能完成一个简单的网页操作：解析整个DOM树、分析无障碍树、截取屏幕截图、计算点击坐标……这个过程不仅缓慢、脆弱，还消耗大量Token。

DOM（Document Object Model）树是浏览器将HTML文档解析后生成的树状数据结构，每个HTML标签都是树中的一个节点。一个中等复杂度的网页可能包含数千甚至上万个DOM节点。无障碍树（Accessibility Tree）则是浏览器基于DOM树生成的另一棵精简树，原本是为屏幕阅读器等辅助技术服务的，它保留了页面元素的语义角色、名称和状态信息。当前主流的AI Agent（如Anthropic的Computer Use、OpenAI的Operator）在操作网页时，通常需要同时解析这两棵树来理解页面结构，再结合屏幕截图进行视觉定位。这个过程每一步都需要将大量信息序列化为文本送入大语言模型，单次页面理解就可能消耗数千到上万个Token，而一个完整的多步骤操作流程累计消耗的Token量更是惊人。

更糟糕的是，即便经过这些复杂步骤，一个突然加载的广告就可能把页面内容推移（这种现象在Web性能领域被称为"布局偏移"，是Core Web Vitals中CLS指标衡量的核心问题），导致Agent点错位置。Google Chrome团队提出的WebMCP（Web Model Context Protocol）正是为了解决这一痛点而生。

什么是WebMCP？核心概念解析

WebMCP是一个提议中的Web标准，它允许网站开发者将自己站点的功能定义为结构化的工具（Tools），供AI Agent直接调用。如果说MCP是"AI的USB-C接口"，那么WebMCP就是专门为浏览器端AI交互设计的实现方案。

MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议，旨在为AI模型与外部数据源、工具之间建立标准化的通信接口。MCP采用客户端-服务器架构：MCP Server暴露工具（Tools）、资源（Resources）和提示模板（Prompts），MCP Client（通常嵌入在AI应用中）通过JSON-RPC 2.0协议与Server通信。该协议迅速获得了行业广泛采纳，包括OpenAI、Google、Microsoft等主要AI厂商都宣布支持。MCP的核心价值在于解决了"M×N集成问题"——没有统一协议时，M个AI应用要对接N个外部服务需要M×N个定制集成，而有了MCP，每个应用只需实现一次MCP Client，每个服务只需实现一次MCP Server。

WebMCP与MCP的关键区别

两者是互补关系而非替代关系：

• MCP：让AI Agent连接服务器端应用，需要搭建独立服务器，Agent可以随时随地访问
• WebMCP：专注于客户端浏览器内的AI交互，工具运行在浏览器中，需要浏览器窗口处于打开状态

简单来说，WebMCP是MCP中"Tools"部分在浏览器端的实现，它让工程师能够为浏览器内的AI Agent提供可调用的工具接口。这种设计选择意味着WebMCP天然具备一些独特优势：工具可以直接操作DOM、访问浏览器API、与页面状态实时同步，而这些是传统服务器端MCP难以实现的。同时，由于工具运行在用户的浏览器中，用户对AI Agent的操作拥有完全的可见性和控制权。

实际演示：AI Agent玩迷宫游戏

Google Chrome DevRel团队构建了一个迷宫逃脱游戏来展示WebMCP的能力。这个游戏的独特之处在于——你无法通过点击UI来操作，只能通过AI工具来玩。

通过Chrome侧边栏的Model Context Tool Inspector扩展，可以看到页面上注册的所有工具。在迷宫首页只有一个"Start Maze Game"工具，而进入迷宫后，会出现移动（north/south/east/west）、查看、拾取物品、使用物品等多个工具。

AI Agent能够理解自然语言指令（如"R"代表"right"），自动映射到对应的工具调用，甚至可以接收"complete the maze"这样的高级指令，自主重复调用工具直到完成目标。这种能力展示了AI Agent的"Agentic Loop"（智能体循环）模式——Agent不是简单地执行单次工具调用，而是在一个循环中持续观察环境状态、制定计划、执行动作、评估结果，直到达成最终目标。这与ReAct（Reasoning + Acting）等主流Agent架构的设计理念一致。

WebMCP的四大核心应用场景

WebMCP解锁了一种全新的网页使用模式：用户可以先正常浏览网站，然后将控制权交给AI Agent完成复杂操作，随时可以收回控制权。这种"人机协作"模式被称为Human-in-the-Loop，它在保持AI高效执行能力的同时，确保了用户对关键决策（如支付确认）的最终控制权。

典型应用场景包括：

• 复杂表单填写：医疗表单、金融表单等多步骤流程。这类表单往往包含条件逻辑（如选择某个选项后才显示后续字段）、数据验证、跨页面状态保持等复杂交互，传统的屏幕抓取方式极易出错
• 机票预订：多条件筛选、多步骤操作
• 电商购物：商品筛选、规格选择（比如找一个能装手机的黑色仿皮手拿包）
• 票务购买：选座、选票型、填写信息一气呵成

技术实现：声明式与命令式两种API方案

WebMCP提供了声明式和命令式两种实现方式，开发者可以根据实际需求选择。这种双轨设计借鉴了Web平台的一贯传统——HTML本身是声明式的，而JavaScript提供命令式能力，两者互补覆盖从简单到复杂的全部场景。

声明式API（Declarative API）

适用于标准HTML表单场景。只需在表单元素上添加几个属性（如tool-name和tool-description），浏览器就会自动生成JSON Schema供Agent读取，表单字段作为工具的参数。

JSON Schema是一种用于描述JSON数据结构的声明式语言，它定义了数据的类型、格式、约束条件和嵌套关系。在WebMCP和MCP生态中，JSON Schema扮演着关键角色：它精确描述了每个工具接受的参数结构，包括参数名称、数据类型、是否必填、取值范围、默认值等信息。大语言模型通过读取JSON Schema就能理解工具的输入要求，从而正确构造调用参数。这种机制与OpenAI的Function Calling、Anthropic的Tool Use等技术一脉相承——它们都依赖JSON Schema来实现AI模型与外部函数之间的结构化交互。

此外还有agent-invoked布尔属性，可以区分表单是由Agent还是人类填写的。这个属性在实际应用中非常重要——网站可以据此决定是否跳过某些仅面向人类的交互步骤（如CAPTCHA验证），或者在后端日志中标记该操作来源于AI Agent，便于审计和分析。

命令式API（Imperative API）

适用于更复杂的多步骤UI流程，也是目前使用最广泛的方式。开发者通过registerTool函数注册自定义工具：

registerTool({
  name: "addToDoItem",
  description: "添加一个待办事项到列表中",
  schema: { /* JSON Schema */ },
  execute: async (params) => {
    // 验证输入、创建DOM节点、更新页面
    return { success: true, message: "待办事项已添加" };
  }
});

关键要点：描述信息要足够详细，让AI Agent知道何时该调用这个工具——这与Prompt Engineering的原则一致，清晰的工具描述本质上就是给AI模型的指令。execute块中可以调用已有的业务逻辑，这意味着开发者不需要为WebMCP重写功能代码，而是可以复用现有的前端函数和组件方法。返回值要包含足够信息供Agent决定下一步操作，例如返回操作结果、当前状态、可用的后续操作等上下文信息。

音乐票务网站演示：多步骤购票全流程

在演示的音乐票务网站中，用户只需说"买两张Summer Vibes Festival的VIP票"，AI Agent就会自动完成以下步骤：

1. 调用searchConcerts工具找到对应演唱会及其ID
2. 调用openConcertPage工具打开演唱会详情页
3. 在新页面调用purchaseTicket工具，传入数量和票型

整个过程中UI同步更新，用户可以看到VIP被选中、数量被设置。值得注意的是，这里的工具调用是跨页面的——Agent在导航到新页面后，能够发现并使用新页面上注册的工具，这说明WebMCP的工具注册机制是与页面生命周期绑定的，每个页面可以独立声明自己提供的工具集。

而在真实场景中，最终的支付环节应该交回给用户手动确认。这不仅是用户体验的考量，更涉及法律合规问题——在许多司法管辖区，金融交易需要明确的用户授权，AI Agent的自动操作可能不满足"知情同意"的法律要求。

如何开始使用WebMCP

目前WebMCP仍处于早期预览阶段，API仍在快速迭代中。

Chrome Canary是Google Chrome的每日构建版本，包含最新的实验性功能，主要面向开发者和早期测试者。一个新的Web功能从提案到正式标准通常要经历多个阶段：首先在W3C或WHATWG等标准组织提出提案（Intent to Prototype），然后在浏览器的实验性版本中实现并通过Feature Flag开启测试，接着经过Origin Trial（允许特定网站在生产环境中试用）收集反馈，最终在获得多个浏览器厂商共识后纳入正式标准。WebMCP目前处于非常早期的阶段，这意味着API可能随时发生重大变更，距离成为正式Web标准还有相当长的路要走。

入门步骤如下：

1. 安装Chrome 146+版本（推荐使用Chrome Canary）
2. 启用WebMCP测试标志（在chrome://flags中搜索相关选项）
3. 安装Model Context Tool Inspector扩展
4. 参考官方博客和GitHub仓库中的示例Demo

Google还提供了eval CLI工具，帮助开发者测试自己网站上的WebMCP工具效果。这个工具可以模拟AI Agent的行为，自动发现页面上注册的工具并尝试调用，帮助开发者在没有完整AI Agent集成的情况下验证工具定义的正确性和可用性。

总结：WebMCP代表了Web与AI交互的未来

在使用WebMCP之前，有一个重要的前提不能忽略：良好的Web基础建设。语义化HTML、无障碍标准、页面性能优化、清晰的用户体验流程——这些做好了，你的网站就已经对AI Agent友好了一半。

语义化HTML是指使用具有明确含义的HTML标签（如<nav>、<article>、<header>、<main>、<form>等）来构建页面，而非滥用<div>和<span>等无语义标签。这一实践最初是为了提升网页的可访问性（Accessibility）和搜索引擎优化（SEO），但在AI Agent时代获得了新的重要性。当AI Agent需要理解页面结构时，语义化标签提供了天然的结构线索。WCAG（Web Content Accessibility Guidelines）无障碍标准同样如此，ARIA属性（如aria-label、aria-role）为页面元素提供了机器可读的语义描述，这些信息对AI Agent的页面理解同样至关重要。换言之，过去十年间Web社区推动的可访问性最佳实践，如今正在成为AI时代的基础设施。

WebMCP是在此基础上的进一步增强。AI Agent已经在使用Web了，我们不必继续忍受那些消耗大量Token、脆弱易碎的屏幕抓取方式。WebMCP让每个网站都能变成AI Agent的高性能API，同时为用户构建更好的体验。

从更宏观的视角来看，WebMCP的出现标志着Web平台正在经历一次根本性的范式转变——从"人类可读的文档平台"向"人机双重可用的应用平台"演进。正如Web从静态文档发展到动态应用（Web 2.0），再到移动优先的响应式设计，如今"AI Agent优先"正在成为下一个重要的设计维度。这个标准虽然还在早期，但它代表了Web与AI交互的未来方向。

核心要点