WebMCP深度调研报告

WebMCP（Web Model Context Protocol）深度调研报告

调研日期：2026年3月20日状态：WebMCP 目前为 W3C 社区草案（Draft Community Group Report），Chrome 146 Canary 提供早期预览

0. 面向服务端开发者的快速理解

如果你是 Java/服务端开发者，对浏览器前端不太熟悉，本节用后端概念帮你快速建立理解。

0.1 一句话理解 WebMCP

WebMCP 解决的问题，类比到后端世界：

css 复制代码

传统方式：AI 访问网页 ≈ 爬虫 + OCR 猜页面结构（没有API文档，看截图猜接口）
WebMCP 方式：AI 访问网页 ≈ 网站直接暴露了 REST API（有完整Swagger文档）

0.2 三方参与模型

WebMCP 有三方参与，和 Dubbo/Spring Cloud 的服务治理非常像：

WebMCP 角色	做什么	Java 类比
网站开发者（Provider）	在网页 JS 里注册"工具"，声明对外暴露的能力	`@DubboService` 注解发布 RPC 接口
浏览器内核（Registry + Gateway）	管理工具注册表、安全检查、执行调度	Zookeeper/Nacos（注册中心）+ Spring Gateway（网关）
AI Agent（Consumer）	发现可用工具 → 选择工具 → 构造参数 → 调用	`@DubboReference` 注入远程服务并调用

0.3 核心流程（后端语言版）

第一步：服务注册（网站开发者做的）

javascript 复制代码

// 前端 JS 代码
navigator.modelContext.registerTool({
    name: "searchFlights",                    // ≈ 方法签名
    description: "搜索航班",                   // ≈ Swagger 接口说明
    inputSchema: { origin: "string", ... },   // ≈ Request DTO
    execute: async (input) => { ... }         // ≈ ServiceImpl 实现
})

Java 等价理解：

java 复制代码

@PostMapping("/searchFlights")
public FlightResponse searchFlights(@RequestBody FlightRequest req) {
    return flightService.search(req);
}

第二步：服务发现（AI Agent 做的）

AI Agent 问浏览器："这个网页有哪些工具？"→ 浏览器返回工具清单（≈ 从 Nacos 拉取服务列表 / 读取 Swagger 文档）

第三步：服务调用

Agent 选择工具、构造参数、发起调用 → 浏览器转发给 execute 函数 → 返回 JSON 结果（≈ dubboService.searchFlights(request)）

0.4 关键前端概念速查表

前端概念	含义	Java/后端类比
`navigator`	浏览器提供给网页的全局 SDK 对象	`System` 类 / Spring ApplicationContext
`navigator.modelContext`	WebMCP 的注册中心入口	`DiscoveryClient` / Nacos 客户端
`registerTool()`	注册一个工具供 AI 调用	`@DubboService` / `@PostMapping` 发布接口
`execute` 回调	工具被调用时执行的业务逻辑	`ServiceImpl` 中的方法实现
`inputSchema`	JSON Schema 格式的入参定义	Request DTO / Swagger 参数定义
`SecureContext`	仅 HTTPS 环境可用	Spring Security 的 `@Secured` 注解
`requestUserInteraction`	敏感操作弹窗让用户确认	类似二次确认/审批流（需要人工确认）
`readOnlyHint`	标记工具为只读	`@GetMapping`（只读）vs `@PostMapping`（写）
声明式 API（HTML属性）	在 HTML 标签上加属性即可暴露工具	类似注解驱动（`@RestController`零配置发布）
命令式 API（JS代码）	写 JS 代码动态注册工具	类似编程式注册 Bean（`registerBean()`）
Tool Map	浏览器内部的工具注册表	Nacos 的服务注册表
浏览器会话继承	工具自动拥有用户的登录态	类似 ThreadLocal 传递用户上下文

0.5 浏览器内核 vs 应用层的分工

复制代码

┌──────────────────────────────────────────────────┐
│  应用层（网站开发者写的 JS 代码）                     │
│  ≈ 你写的 ServiceImpl + Controller                │
│  职责：注册工具、实现业务逻辑、决定哪些需要用户确认      │
├──────────────────────────────────────────────────┤
│  浏览器内核（Chrome/Edge 提供）                      │
│  ≈ Tomcat + Spring容器 + 安全框架                  │
│  职责：提供API、管理注册表、安全检查、路由调用           │
├──────────────────────────────────────────────────┤
│  AI Agent（外部消费者）                              │
│  ≈ 调用你 API 的客户端                              │
│  职责：发现工具、理解意图、构造参数、调用工具            │
└──────────────────────────────────────────────────┘

0.6 Token 效率提升 89% 的直觉理解

复制代码

传统方式：你没有API文档，只能看着前端页面截图猜接口 → 效率极低
WebMCP方式：你有完整的Swagger文档，直接看接口定义调用 → 效率极高

1. 行业全景图

1.1 WebMCP 出现的背景

问题：AI Agent 与 Web 之间的"语言鸿沟"

当前 AI Agent（如 ChatGPT、Claude、Gemini 等）在浏览网页时，本质上是一个"不懂当地语言的游客"。它们通过以下方式与网页交互：

截屏 + 视觉识别：对页面截图，用视觉模型猜测 UI 元素的含义
DOM 解析：爬取原始 HTML，通过 CSS 选择器定位元素
模拟点击：合成鼠标/键盘事件，模拟人类操作

这些方法存在严重缺陷：

脆弱性极高：页面布局一改，自动化脚本立即失效
Token 消耗巨大：一次截图需要消耗数千 Token
准确率低：Agent 需要"猜"按钮功能，经常猜错
缺乏语义理解：Agent 看到的是像素而不是业务逻辑

催化因素：Agentic Web 的兴起

2025-2026年，主要 AI 厂商纷纷推出浏览器 Agent 产品：

产品	公司	发布时间	核心能力
Chrome Auto Browse	Google	2026年1月	Gemini 驱动的自主浏览
Atlas (Agent Mode)	OpenAI	2025年10月	多步骤任务执行
Comet	Perplexity	2025年7月	搜索优先的 Agent 浏览
Disco	Google Labs	2025年12月	从标签页生成自定义应用

这些产品使得"网站需要对 AI Agent 友好"从理论变成了迫切的实际需求。

WebMCP 的诞生

WebMCP 由 Google Chrome 团队 和 Microsoft Edge 团队 联合开发，于 2025年8月13日首次发布提案，2026年2月10日随 Chrome 146 Canary 发布早期预览。它通过 W3C Web Machine Learning Community Group 孵化，核心作者包括：

Brandon Walderman（Microsoft）
Leo Lee（Microsoft）
Andrew Nolan（Microsoft）
David Bokan（Google）
Khushal Sagar（Google）
Hannah Van Opstal（Google）

1.2 Agent 协议生态全景

graph TB subgraph "AI Agent 协议生态全景（2026年3月）" direction TB subgraph "Agent-to-Tool 层" MCP["MCP
Anthropic
Agent ↔ 后端工具/数据"] WebMCP["WebMCP
Google + Microsoft
Agent ↔ 浏览器前端"] end subgraph "Agent-to-Agent 层" A2A["A2A
Google
Agent ↔ Agent 协作"] ACP["ACP
IBM
Agent 通信协议"] ANP["ANP
蚂蚁集团
Agent 网络协议"] end subgraph "基础设施层" AGP["AGP
Agent Gateway Protocol
Agent 网关"] AGNTCY["AGNTCY
Cisco
Agent 基础设施"] end MCP -->|"后端补充"| WebMCP A2A -->|"Agent 间协调"| MCP ACP -.->|"竞争/互补"| A2A end

1.3 各协议的定位与互补关系

协议	主导方	核心定位	运行环境	解决的问题
MCP	Anthropic	Agent ↔ 后端工具/数据源	服务器端（JSON-RPC）	AI 如何调用后端 API、数据库、文件系统
WebMCP	Google + Microsoft	Agent ↔ 浏览器前端	浏览器内（客户端 JS）	AI 如何与网页 UI 交互
A2A	Google	Agent ↔ Agent 协作	网络层	多个 AI Agent 之间如何协调分工
ACP	IBM	Agent 通信协议	网络层	Agent 间的可靠消息传递
ANP	蚂蚁集团	Agent 网络协议	网络层	大规模 Agent 网络的发现与通信

关键关系：MCP 与 WebMCP 是互补的，不是竞争的。

一句话总结：MCP 解决后端集成，WebMCP 解决前端交互。

1.4 支持者与采纳情况

核心支持方（事实）：

Google：Chrome 146 Canary 已集成早期预览，Chrome 团队是核心开发者
Microsoft：Edge 团队联合开发，多名 Microsoft 工程师是规范作者
W3C：通过 Web Machine Learning Community Group 孵化

生态参与者（事实）：

MCP-B 项目：第三方 Chrome 扩展，为非原生支持的浏览器提供 polyfill
Who's In?：首个宣布 WebMCP 集成的活动平台（2026年3月）
多个开发者社区（Reddit r/webdev、Dev.to）有活跃的实验性实现讨论

当前状态（事实）：

规范状态：W3C 社区草案（非 W3C 标准）
Chrome 支持：Chrome 146 Canary，需手动开启 flag
生产就绪度：未就绪，仍在早期预览阶段
预计更广泛浏览器支持：2026年中后期（推测）

2. 技术架构全景图

2.1 完整技术架构

graph TB subgraph "AI Agent 侧" Agent["AI Agent
（ChatGPT / Gemini / Claude 等）"] AgentRuntime["Agent 运行时"] end subgraph "浏览器层（核心）" BrowserAgent["浏览器内置 Agent
或扩展 Agent"] NavAPI["navigator.modelContext API"] ToolRegistry["工具注册表
（Tool Map）"] SecurityLayer["安全层
（SecureContext / 用户同意）"] end subgraph "Web 应用层" DeclarativeAPI["声明式 API
（HTML 属性）"] ImperativeAPI["命令式 API
（JavaScript）"] AppLogic["现有应用逻辑
（前端代码）"] AuthContext["认证上下文
（Cookies / SSO）"] end Agent -->|"外部 Agent 通过
浏览器扩展/API 接入"| BrowserAgent BrowserAgent --> NavAPI NavAPI --> ToolRegistry ToolRegistry --> SecurityLayer SecurityLayer -->|"发现工具"| DeclarativeAPI SecurityLayer -->|"发现工具"| ImperativeAPI DeclarativeAPI --> AppLogic ImperativeAPI --> AppLogic AppLogic --> AuthContext

2.2 核心组件详解

组件一：`navigator.modelContext` API

这是 WebMCP 的核心接口，挂载在浏览器的 Navigator 对象上。根据 W3C 规范（2026年3月9日版本）：

javascript 复制代码

// IDL 定义
partial interface Navigator {
  [SecureContext, SameObject] readonly attribute ModelContext modelContext;
};

interface ModelContext {
  undefined registerTool(ModelContextTool tool);
  undefined unregisterTool(DOMString name);
};

Java类比 ：navigator 相当于 Spring ApplicationContext，modelContext 相当于从容器中获取的 DiscoveryClient Bean。registerTool() 相当于 @DubboService 将服务注册到 Nacos。

关键约束：

SecureContext：仅在 HTTPS 环境下可用
SameObject：每个 Navigator 实例对应唯一的 ModelContext

组件二：ModelContextTool（工具定义）

javascript 复制代码

dictionary ModelContextTool {
  required DOMString name;          // 工具唯一标识符
  required DOMString description;   // 自然语言描述（供 LLM 理解）
  object inputSchema;               // JSON Schema 输入参数定义
  required ToolExecuteCallback execute;  // 执行回调函数
  ToolAnnotations annotations;      // 可选注解（如 readOnlyHint）
};

dictionary ToolAnnotations {
  boolean readOnlyHint = false;     // 标记为只读工具
};

callback ToolExecuteCallback = Promise<any> (
  object input,                     // Agent 传入的参数
  ModelContextClient client         // 客户端接口（用于请求用户交互）
);

组件三：ModelContextClient（用户交互接口）

Java类比 ：ModelContextTool 相当于一个 RPC 接口定义。name = 方法签名，description = Swagger注释，inputSchema = Request DTO，execute = ServiceImpl 实现方法。

javascript 复制代码

interface ModelContextClient {
  Promise<any> requestUserInteraction(UserInteractionCallback callback);
};

这个接口允许工具在执行过程中请求用户介入，例如弹出确认对话框。这是 WebMCP "人在回路"（Human-in-the-loop） 设计理念的核心体现。

Java类比 ：requestUserInteraction 类似审批流中的"需要人工确认"节点。Agent 调用了一个敏感操作（如支付、删除），系统暂停执行，弹窗让用户确认后才继续。

组件四：声明式 API（HTML 属性方式）

除了 JavaScript 命令式 API，WebMCP 还支持通过 HTML 属性声明工具：

html 复制代码

<!-- 示例：餐厅预订表单 -->
<form toolname="makeReservation"
      tooldescription="预订餐厅座位">
  <label>
    日期
    <input type="date" name="date" required>
  </label>
  <label>
    人数
    <input type="number" name="partySize" min="1" max="20" required>
  </label>
  <label>
    姓名
    <input type="text" name="guestName" required>
  </label>
  <button type="submit">预订</button>
</form>

浏览器会自动将表单结构合成为 JSON Schema，Agent 可直接调用该工具。

2.3 两种 API 模式对比

graph LR subgraph "声明式 API（低门槛）" HTML["HTML 表单
+ toolname 属性"] --> Browser1["浏览器自动
合成 JSON Schema"] Browser1 --> Tool1["注册为工具"] end subgraph "命令式 API（高灵活性）" JS["JavaScript 调用
navigator.modelContext
.registerTool()"] --> Tool2["注册为工具"] end Tool1 --> Agent1["Agent 调用"] Tool2 --> Agent1

维度	声明式 API	命令式 API
实现方式	HTML 属性（toolname / tooldescription）	JavaScript（navigator.modelContext.registerTool）
适用场景	已有标准 HTML 表单的网站	复杂动态交互、SPA 应用
改造成本	极低（加两个属性）	中等（需编写 JS 代码）
灵活度	较低（依赖表单结构）	极高（可动态注册/注销工具）
上下文感知	不支持	支持（可根据页面状态动态调整可用工具）

2.4 与传统 Web 访问方式的对比

graph TB subgraph "传统方式：截屏 + DOM 解析" T1["1. 加载页面"] --> T2["2. 截取屏幕"] T2 --> T3["3. 视觉模型识别 UI 元素"] T3 --> T4["4. 猜测按钮/输入框功能"] T4 --> T5["5. 模拟鼠标点击"] T5 --> T6["6. 等待页面响应"] T6 --> T7["7. 再次截屏确认结果"] end subgraph "WebMCP 方式" W1["1. 加载页面"] --> W2["2. 发现注册的工具列表"] W2 --> W3["3. 读取工具的 Schema"] W3 --> W4["4. 直接调用工具函数"] W4 --> W5["5. 获取结构化返回值"] end

维度	截屏/DOM 方式	WebMCP 方式
Token 消耗	每次交互数千 Token	减少 89%
任务准确率	~60-70%（推测）	97.9%（据 digital-loop.com 报道）
对页面变化的鲁棒性	极差（CSS 选择器易失效）	极强（基于语义化工具定义）
执行速度	慢（多轮截屏+推理）	快（单次函数调用）
认证处理	需要单独处理	继承浏览器会话（Cookies/SSO）
需要额外基础设施	需要 headless browser	不需要，浏览器原生

2.5 Token 效率提升 89% 的原理

根据多个来源报道，WebMCP 相比截屏方式 Token 效率提升约 89%。其原理如下：

传统截屏方式的 Token 消耗：

一张网页截图编码后约 几千到上万 Token
视觉模型需要处理整个图像来理解 UI
每一步交互都需要重新截图
多步骤任务需要多次截图循环
还需要额外 Token 来推理"这个按钮是什么功能"

WebMCP 方式的 Token 消耗：

工具列表是结构化 JSON，极其紧凑
每个工具描述仅需 几十到几百 Token
调用参数是类型化的 JSON
返回结果也是结构化数据
不需要视觉推理

graph LR subgraph "传统方式 Token 流" S1["截图编码
~3000 tokens"] --> S2["视觉推理
~500 tokens"] S2 --> S3["动作推理
~200 tokens"] S3 --> S4["下一步截图
~3000 tokens"] S4 --> S5["...重复N次"] end subgraph "WebMCP Token 流" W1["工具列表
~200 tokens"] --> W2["选择工具
~50 tokens"] W2 --> W3["构造参数
~100 tokens"] W3 --> W4["结构化结果
~100 tokens"] end

估算：完成一个典型任务（如搜索航班），传统方式可能消耗 ~10,000+ tokens，WebMCP 方式约 ~1,000 tokens，因此节省约 89%。

注意：89% 这个数字来自 Google/Microsoft 的初步基准测试，具体数值可能因场景而异。多个独立报道（Zuplo、digital-loop、VentureBeat 等）均引用了这一数据，但尚未见到公开的详细基准测试方法论。

3. 核心时序图

3.1 完整请求时序

sequenceDiagram participant User as 用户 participant Agent as AI Agent participant Browser as 浏览器 participant NavMC as navigator.modelContext participant WebApp as Web 应用 Note over WebApp: 页面加载阶段 WebApp->>NavMC: registerTool({name, description, inputSchema, execute}) NavMC->>NavMC: 验证工具定义有效性 NavMC->>NavMC: 存入 Tool Map Note over User,Agent: 用户发起请求 User->>Agent: "帮我搜索3月25日北京到上海的航班" Note over Agent,Browser: 工具发现阶段 Agent->>Browser: 请求当前页面的可用工具列表 Browser->>NavMC: 读取 Tool Map NavMC-->>Browser: 返回工具列表（name + description + inputSchema） Browser-->>Agent: 工具清单 JSON Note over Agent: Agent 推理阶段 Agent->>Agent: LLM 分析目标，匹配工具 "searchFlights" Agent->>Agent: 根据 inputSchema 构造参数 Note over Agent,WebApp: 工具执行阶段 Agent->>Browser: 调用 searchFlights({origin:"PEK", dest:"SHA", date:"2026-03-25"}) Browser->>NavMC: 执行 Tool Map 中对应的 execute 回调 NavMC->>WebApp: 调用 execute(input, client) WebApp->>WebApp: 执行前端搜索逻辑（复用现有代码） WebApp-->>NavMC: 返回结构化结果 NavMC-->>Browser: Promise resolve Browser-->>Agent: 结构化航班数据 JSON Note over Agent,User: 结果呈现 Agent->>User: "找到以下航班：..."

3.2 带用户确认的时序（写操作场景）

sequenceDiagram participant User as 用户 participant Agent as AI Agent participant Browser as 浏览器 participant NavMC as navigator.modelContext participant WebApp as Web 应用 Agent->>Browser: 调用 bookFlight({flightId: "CA1234", passengers: 2}) Browser->>NavMC: 执行 execute 回调 NavMC->>WebApp: execute(input, client) Note over WebApp: 涉及写操作，需要用户确认 WebApp->>NavMC: client.requestUserInteraction(callback) Note over Browser: 浏览器将控制权交给用户 NavMC->>Browser: 暂停 Agent 操作 Browser->>User: 显示确认对话框
"确认预订 CA1234 航班，2位乘客？" User->>Browser: 点击"确认" Browser->>NavMC: 用户已确认 NavMC->>WebApp: 继续执行 callback WebApp->>WebApp: 执行预订逻辑 WebApp-->>NavMC: 返回预订结果 NavMC-->>Browser: Promise resolve Browser-->>Agent: 预订成功 + 订单号 Agent->>User: "预订成功！订单号 ORD-12345"

3.3 涉及的角色和组件

3.4 认证和权限处理

WebMCP 的安全模型与传统 MCP 有本质区别：

1. 认证：继承浏览器会话

WebMCP 运行在浏览器标签页内，天然继承：

浏览器的 Cookies
SSO 令牌
OAuth 会话
用户已登录的所有认证状态

这意味着 不需要单独配置认证------如果用户已经登录了某个网站，Agent 通过 WebMCP 调用该网站的工具时，自动拥有该用户的权限。

Java类比 ：传统 MCP 需要配置 OAuth 2.1，类似你的微服务需要 JWT Token 才能调用。WebMCP 自动继承浏览器会话，类似 ThreadLocal 自动传递用户上下文------因为用户已经登录了网站，工具调用自动带上了认证信息。

2. 安全约束

根据 W3C 规范：

SecureContext 要求：仅在 HTTPS 页面上可用
同源策略：工具只能在注册它的浏览上下文（Browsing Context）内使用
readOnlyHint 注解：工具可声明自己为只读，帮助 Agent 判断操作安全性
requestUserInteraction：敏感操作必须通过用户确认

3. 当前安全问题（事实：仍在讨论中）

根据 GitHub Issue #121（2026年3月），社区正在讨论以下安全提案：

输入验证机制
安全策略声明（工具作者声明风险等级）
Agent 允许列表（白名单）

graph TB subgraph "WebMCP 安全模型" A["SecureContext
仅 HTTPS"] --> B["浏览器会话继承
Cookies / SSO"] B --> C["同源策略
工具限于注册页面"] C --> D["readOnlyHint
只读工具标记"] D --> E["requestUserInteraction
敏感操作需用户确认"] E --> F["（讨论中）Agent 白名单
输入验证 / 安全策略"] end

关键区别：传统 MCP 需要通过 OAuth 2.1 等机制单独配置认证。WebMCP 由于运行在浏览器中，直接复用用户已有的登录状态，大幅降低了集成复杂度。

4. 具体案例

4.1 Who's In?------首个 WebMCP 集成的活动平台

事实来源：Medium 文章（Craig Pollard, 2026年3月2日）

概述：Who's In? 是一个活动平台，声称是首个实现 WebMCP 集成的活动平台（领先于 Eventbrite、Luma、Partiful 等）。

集成的 7 个只读工具：

search_events - 搜索活动
get_event_details - 获取活动详情
check_availability - 检查可用性
get_rsvp_link - 获取报名链接
get_popular_events - 获取热门活动
list_categories - 列出分类
get_club_info - 获取俱乐部信息

设计原则：

所有工具均为只读（readOnlyHint: true）
写操作（RSVP、创建活动）仍需用户手动点击链接确认
工具同时作为 REST API 提供给非浏览器 Agent

4.2 Chrome 146 Canary 的 Early Preview

事实来源：VentureBeat（2026年2月12日）、Chrome 官方博客

如何启用：

下载 Chrome 146 Canary（版本 146.0.7672.0 或更高）
访问 chrome://flags/#enable-webmcp-testing
将 "WebMCP for testing" flag 设为 "Enabled"
重启浏览器

可以做什么：

网站可以通过 navigator.modelContext.registerTool() 注册工具
安装 Model Context Tool Inspector Chrome 扩展可以：
- 查看任意页面上注册的工具
- 手动测试工具调用
- 用自定义参数执行工具
Google 提供了一个旅行演示页面，展示完整的工具发现→调用流程

当前限制：

仅 Chrome Canary 支持，且需手动开启 flag
不是生产就绪的
规范仍在快速迭代中
声明式 API（HTML 属性方式）尚未完全实现（规范中标记为 TODO）

4.3 开发者接入示例

方式一：命令式 API（JavaScript）

javascript 复制代码

// 注册一个搜索航班的工具
navigator.modelContext.registerTool({
  name: "searchFlights",
  description: "搜索指定出发地、目的地和日期的航班",
  inputSchema: {
    type: "object",
    properties: {
      origin: {
        type: "string",
        description: "出发城市 IATA 代码（如 PEK）"
      },
      destination: {
        type: "string",
        description: "到达城市 IATA 代码（如 SHA）"
      },
      date: {
        type: "string",
        format: "date",
        description: "出发日期（YYYY-MM-DD 格式）"
      },
      passengers: {
        type: "integer",
        minimum: 1,
        maximum: 9,
        description: "乘客人数"
      }
    },
    required: ["origin", "destination", "date"]
  },
  annotations: {
    readOnlyHint: true  // 标记为只读操作
  },
  execute: async (input, client) => {
    // 复用现有的前端搜索逻辑
    const results = await flightSearchAPI.search({
      from: input.origin,
      to: input.destination,
      departDate: input.date,
      pax: input.passengers || 1
    });

    return {
      flights: results.map(f => ({
        flightNo: f.number,
        departure: f.departTime,
        arrival: f.arriveTime,
        price: f.price,
        currency: "CNY"
      }))
    };
  }
});

方式二：声明式 API（HTML 属性）

html 复制代码

<!-- 直接在 HTML 表单上添加属性 -->
<form toolname="searchFlights"
      tooldescription="搜索指定出发地、目的地和日期的航班">
  <label>出发地 <input type="text" name="origin" required></label>
  <label>目的地 <input type="text" name="destination" required></label>
  <label>日期 <input type="date" name="date" required></label>
  <label>乘客 <input type="number" name="passengers" min="1" max="9" value="1"></label>
  <button type="submit">搜索</button>
</form>

方式三：使用 MCP-B Polyfill（非 Chrome 浏览器）

javascript 复制代码

// 安装：npm install @anthropic/mcp-b
import { polyfillWebMCP } from '@mcp-b/global';

// 为不支持 WebMCP 的浏览器提供兼容
polyfillWebMCP();

// 之后正常使用 navigator.modelContext API
navigator.modelContext.registerTool({
  // ... 与原生 API 相同的代码
});

4.4 调试与测试

Model Context Tool Inspector 扩展：

这是 Google 提供的官方调试工具，可以从 Chrome Web Store 安装。功能包括：

列出当前页面注册的所有 WebMCP 工具
显示每个工具的 name、description、inputSchema
允许手动输入参数并执行工具
可以配置 Gemini API Key 后，用 AI 直接测试工具调用

5. 总结与展望

5.1 WebMCP 的核心价值定位

graph TB subgraph "WebMCP 解决的核心问题" P1["网站 = API
无需额外维护后端 API"] --> V["WebMCP"] P2["Agent 理解语义
而非猜测像素"] --> V P3["复用前端代码
零后端改造"] --> V P4["继承用户认证
零认证配置"] --> V P5["人在回路
敏感操作需确认"] --> V end

5.2 与 MCP 层级关系的精确理解

根据 Patrick Brosset（Microsoft，WebMCP 提案参与者）的澄清文章（2026年2月23日）：

MCP 协议由三层组成：

原语层（Primitives）：工具（Tools）、资源（Resources）、提示（Prompts）等
数据层（Data Layer）：MCP 客户端与服务器如何通信
传输层（Transport Layer）：消息如何传递

WebMCP 只关心第一层------它的工具定义（name, description, inputSchema, execute）与 MCP 工具几乎完全一致。但浏览器自己处理了第二层和第三层，使用浏览器内部机制（而非 JSON-RPC）来传递消息。

当前 WebMCP 只支持 Tools，不支持 MCP 的 Resources 和 Prompts 概念。

5.3 关键风险与不确定性

风险	说明
规范尚未稳定	仍为 W3C 社区草案，API 可能变化
声明式 API 未完成	规范中标记为 TODO
安全模型待完善	正在讨论中（GitHub Issue #121）
浏览器兼容性	目前仅 Chrome Canary 支持
采纳率未知	需要网站开发者主动集成
与现有自动化冲突	如何与 Playwright/Puppeteer 等工具共存需明确

5.4 时间线展望

timeline title WebMCP 发展时间线 2025年8月 : 首次发布提案（GitHub） 2026年2月 : Chrome 146 Canary Early Preview : W3C 社区草案发布 2026年Q2（推测） : Chrome Stable 支持 : 声明式 API 完善 2026年下半年（推测） : Edge 原生支持 : 更多浏览器跟进 : 首批生产级集成 2027年（推测） : 可能进入 W3C 正式标准化流程

5.5 结论

WebMCP 是一个具有重要战略意义的 Web 标准提案。它解决了一个真实且迫切的问题------让 AI Agent 能够以结构化、可靠、高效的方式与 Web 应用交互，而不是像"盲人摸象"一样猜测 UI。

核心判断：

技术方向正确：将网页变为结构化 API 的思路比截屏/DOM 解析更优雅、更高效
行业支持强劲：Google + Microsoft + W3C 的组合提供了强有力的推动力
与 MCP 互补：后端用 MCP，前端用 WebMCP，形成完整的 Agent-Web 交互栈
需要耐心：作为 Web 标准，从提案到广泛采纳通常需要 1-3 年

参考来源

W3C 规范：webmachinelearning.github.io/webmcp（2026...
GitHub 仓库：github.com/webmachinel...
Patrick Brosset 更新：patrickbrosset.com/articles/20...
VentureBeat：venturebeat.com/infrastruct...
Forbes：www.forbes.com/sites/joeto...
Semrush 分析：www.semrush.com/blog/webmcp
Zuplo 技术分析：zuplo.com/blog/what-i...
DataCamp 教程：www.datacamp.com/tutorial/we...
Who's In? 案例：medium.com/@craigpolla...
The New Stack：thenewstack.io/webmcp-chro...
Search Engine Land：searchengineland.com/google-rele...
digital-loop.com：digital-loop.com/en/blog/web...

WebMCP深度调研报告

WebMCP（Web Model Context Protocol）深度调研报告

0. 面向服务端开发者的快速理解

0.1 一句话理解 WebMCP

0.2 三方参与模型

0.3 核心流程（后端语言版）

0.4 关键前端概念速查表

0.5 浏览器内核 vs 应用层的分工

0.6 Token 效率提升 89% 的直觉理解

目录

1. 行业全景图

1.1 WebMCP 出现的背景

1.2 Agent 协议生态全景

1.3 各协议的定位与互补关系

1.4 支持者与采纳情况

2. 技术架构全景图

2.1 完整技术架构

2.2 核心组件详解

组件一：navigator.modelContext API

组件二：ModelContextTool（工具定义）

组件三：ModelContextClient（用户交互接口）

组件四：声明式 API（HTML 属性方式）

2.3 两种 API 模式对比

2.4 与传统 Web 访问方式的对比

2.5 Token 效率提升 89% 的原理

3. 核心时序图

3.1 完整请求时序

3.2 带用户确认的时序（写操作场景）

3.3 涉及的角色和组件

3.4 认证和权限处理

4. 具体案例

4.1 Who's In?------首个 WebMCP 集成的活动平台

4.2 Chrome 146 Canary 的 Early Preview

4.3 开发者接入示例

方式一：命令式 API（JavaScript）

方式二：声明式 API（HTML 属性）

方式三：使用 MCP-B Polyfill（非 Chrome 浏览器）

4.4 调试与测试

5. 总结与展望

5.1 WebMCP 的核心价值定位

5.2 与 MCP 层级关系的精确理解

5.3 关键风险与不确定性

5.4 时间线展望

5.5 结论

参考来源

组件一：`navigator.modelContext` API