九九交易行
34.70M · 2026-03-25
WebMCP 解决的问题，类比到后端世界：
传统方式：AI 访问网页 ≈ 爬虫 + OCR 猜页面结构（没有API文档，看截图猜接口）
WebMCP 方式：AI 访问网页 ≈ 网站直接暴露了 REST API（有完整Swagger文档）
WebMCP 有三方参与，和 Dubbo/Spring Cloud 的服务治理非常像：
| WebMCP 角色 | 做什么 | Java 类比 |
|---|---|---|
| 网站开发者（Provider） | 在网页 JS 里注册"工具"，声明对外暴露的能力 | @DubboService 注解发布 RPC 接口 |
| 浏览器内核（Registry + Gateway） | 管理工具注册表、安全检查、执行调度 | Zookeeper/Nacos（注册中心）+ Spring Gateway（网关） |
| AI Agent（Consumer） | 发现可用工具 → 选择工具 → 构造参数 → 调用 | @DubboReference 注入远程服务并调用 |
第一步：服务注册（网站开发者做的）
// 前端 JS 代码
navigator.modelContext.registerTool({
name: "searchFlights", // ≈ 方法签名
description: "搜索航班", // ≈ Swagger 接口说明
inputSchema: { origin: "string", ... }, // ≈ Request DTO
execute: async (input) => { ... } // ≈ ServiceImpl 实现
})
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)）
| 前端概念 | 含义 | 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 传递用户上下文 |
┌──────────────────────────────────────────────────┐
│ 应用层（网站开发者写的 JS 代码） │
│ ≈ 你写的 ServiceImpl + Controller │
│ 职责：注册工具、实现业务逻辑、决定哪些需要用户确认 │
├──────────────────────────────────────────────────┤
│ 浏览器内核（Chrome/Edge 提供） │
│ ≈ Tomcat + Spring容器 + 安全框架 │
│ 职责：提供API、管理注册表、安全检查、路由调用 │
├──────────────────────────────────────────────────┤
│ AI Agent（外部消费者） │
│ ≈ 调用你 API 的客户端 │
│ 职责：发现工具、理解意图、构造参数、调用工具 │
└──────────────────────────────────────────────────┘
传统方式：你没有API文档，只能看着前端页面截图猜接口 → 效率极低
WebMCP方式：你有完整的Swagger文档，直接看接口定义调用 → 效率极高
问题：AI Agent 与 Web 之间的"语言鸿沟"
当前 AI Agent（如 ChatGPT、Claude、Gemini 等）在浏览网页时，本质上是一个"不懂当地语言的游客"。它们通过以下方式与网页交互：
这些方法存在严重缺陷：
催化因素：Agentic Web 的兴起
2025-2026年，主要 AI 厂商纷纷推出浏览器 Agent 产品：
| 产品 | 公司 | 发布时间 | 核心能力 |
|---|---|---|---|
| Chrome Auto Browse | 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 孵化，核心作者包括：
graph TB
subgraph "AI Agent 协议生态全景（2026年3月）"
direction TB
subgraph "Agent-to-Tool 层"
MCP["MCP<br/>Anthropic<br/>Agent ↔ 后端工具/数据"]
WebMCP["WebMCP<br/>Google + Microsoft<br/>Agent ↔ 浏览器前端"]
end
subgraph "Agent-to-Agent 层"
A2A["A2A<br/>Google<br/>Agent ↔ Agent 协作"]
ACP["ACP<br/>IBM<br/>Agent 通信协议"]
ANP["ANP<br/>蚂蚁集团<br/>Agent 网络协议"]
end
subgraph "基础设施层"
AGP["AGP<br/>Agent Gateway Protocol<br/>Agent 网关"]
AGNTCY["AGNTCY<br/>Cisco<br/>Agent 基础设施"]
end
MCP -->|"后端补充"| WebMCP
A2A -->|"Agent 间协调"| MCP
ACP -.->|"竞争/互补"| A2A
end
| 协议 | 主导方 | 核心定位 | 运行环境 | 解决的问题 |
|---|---|---|---|---|
| MCP | Anthropic | Agent ↔ 后端工具/数据源 | 服务器端（JSON-RPC） | AI 如何调用后端 API、数据库、文件系统 |
| WebMCP | Google + Microsoft | Agent ↔ 浏览器前端 | 浏览器内（客户端 JS） | AI 如何与网页 UI 交互 |
| A2A | Agent ↔ Agent 协作 | 网络层 | 多个 AI Agent 之间如何协调分工 | |
| ACP | IBM | Agent 通信协议 | 网络层 | Agent 间的可靠消息传递 |
| ANP | 蚂蚁集团 | Agent 网络协议 | 网络层 | 大规模 Agent 网络的发现与通信 |
关键关系：MCP 与 WebMCP 是互补的，不是竞争的。
graph LR
subgraph "MCP 的领域"
A[AI Agent] -->|JSON-RPC| B[MCP Server]
B --> C[数据库]
B --> D[API 服务]
B --> E[文件系统]
end
subgraph "WebMCP 的领域"
F[AI Agent] -->|navigator.modelContext| G[浏览器标签页]
G --> H[Web 应用 UI]
G --> I[用户认证上下文]
G --> J[前端业务逻辑]
end
A -.->|"同一个 Agent<br/>可同时使用两者"| F
一句话总结：MCP 解决后端集成，WebMCP 解决前端交互。
核心支持方（事实）：
生态参与者（事实）：
当前状态（事实）：
graph TB
subgraph "AI Agent 侧"
Agent["AI Agent<br/>（ChatGPT / Gemini / Claude 等）"]
AgentRuntime["Agent 运行时"]
end
subgraph "浏览器层（核心）"
BrowserAgent["浏览器内置 Agent<br/>或扩展 Agent"]
NavAPI["navigator.modelContext API"]
ToolRegistry["工具注册表<br/>（Tool Map）"]
SecurityLayer["安全层<br/>（SecureContext / 用户同意）"]
end
subgraph "Web 应用层"
DeclarativeAPI["声明式 API<br/>（HTML 属性）"]
ImperativeAPI["命令式 API<br/>（JavaScript）"]
AppLogic["现有应用逻辑<br/>（前端代码）"]
AuthContext["认证上下文<br/>（Cookies / SSO）"]
end
Agent -->|"外部 Agent 通过<br/>浏览器扩展/API 接入"| BrowserAgent
BrowserAgent --> NavAPI
NavAPI --> ToolRegistry
ToolRegistry --> SecurityLayer
SecurityLayer -->|"发现工具"| DeclarativeAPI
SecurityLayer -->|"发现工具"| ImperativeAPI
DeclarativeAPI --> AppLogic
ImperativeAPI --> AppLogic
AppLogic --> AuthContext
navigator.modelContext API这是 WebMCP 的核心接口，挂载在浏览器的 Navigator 对象上。根据 W3C 规范（2026年3月9日版本）：
// IDL 定义
partial interface Navigator {
[SecureContext, SameObject] readonly attribute ModelContext modelContext;
};
interface ModelContext {
undefined registerTool(ModelContextTool tool);
undefined unregisterTool(DOMString name);
};
关键约束：
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 // 客户端接口（用于请求用户交互）
);
interface ModelContextClient {
Promise<any> requestUserInteraction(UserInteractionCallback callback);
};
这个接口允许工具在执行过程中请求用户介入，例如弹出确认对话框。这是 WebMCP "人在回路"（Human-in-the-loop） 设计理念的核心体现。
除了 JavaScript 命令式 API，WebMCP 还支持通过 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 可直接调用该工具。
graph LR
subgraph "声明式 API（低门槛）"
HTML["HTML 表单<br/>+ toolname 属性"] --> Browser1["浏览器自动<br/>合成 JSON Schema"]
Browser1 --> Tool1["注册为工具"]
end
subgraph "命令式 API（高灵活性）"
JS["JavaScript 调用<br/>navigator.modelContext<br/>.registerTool()"] --> Tool2["注册为工具"]
end
Tool1 --> Agent1["Agent 调用"]
Tool2 --> Agent1
| 维度 | 声明式 API | 命令式 API |
|---|---|---|
| 实现方式 | HTML 属性（toolname / tooldescription） | JavaScript（navigator.modelContext.registerTool） |
| 适用场景 | 已有标准 HTML 表单的网站 | 复杂动态交互、SPA 应用 |
| 改造成本 | 极低（加两个属性） | 中等（需编写 JS 代码） |
| 灵活度 | 较低（依赖表单结构） | 极高（可动态注册/注销工具） |
| 上下文感知 | 不支持 | 支持（可根据页面状态动态调整可用工具） |
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 | 不需要，浏览器原生 |
根据多个来源报道，WebMCP 相比截屏方式 Token 效率提升约 89%。其原理如下：
传统截屏方式的 Token 消耗：
WebMCP 方式的 Token 消耗：
graph LR
subgraph "传统方式 Token 流"
S1["截图编码<br/>~3000 tokens"] --> S2["视觉推理<br/>~500 tokens"]
S2 --> S3["动作推理<br/>~200 tokens"]
S3 --> S4["下一步截图<br/>~3000 tokens"]
S4 --> S5["...重复N次"]
end
subgraph "WebMCP Token 流"
W1["工具列表<br/>~200 tokens"] --> W2["选择工具<br/>~50 tokens"]
W2 --> W3["构造参数<br/>~100 tokens"]
W3 --> W4["结构化结果<br/>~100 tokens"]
end
估算：完成一个典型任务（如搜索航班），传统方式可能消耗 ~10,000+ tokens，WebMCP 方式约 ~1,000 tokens，因此节省约 89%。
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: "找到以下航班：..."
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: 显示确认对话框<br/>"确认预订 CA1234 航班，2位乘客？"
User->>Browser: 点击"确认"
Browser->>NavMC: 用户已确认
NavMC->>WebApp: 继续执行 callback
WebApp->>WebApp: 执行预订逻辑
WebApp-->>NavMC: 返回预订结果
NavMC-->>Browser: Promise resolve
Browser-->>Agent: 预订成功 + 订单号
Agent->>User: "预订成功！订单号 ORD-12345"
graph TB
subgraph "参与角色"
U["用户<br/>发起需求、确认敏感操作"]
A["AI Agent<br/>理解意图、选择工具、构造参数"]
BA["浏览器 Agent<br/>（内置或扩展）<br/>桥接外部 Agent 与页面"]
B["浏览器引擎<br/>提供 navigator.modelContext<br/>管理安全策略"]
W["Web 应用<br/>注册工具、执行业务逻辑"]
end
U -->|"自然语言指令"| A
A -->|"工具调用"| BA
BA -->|"API 调用"| B
B -->|"执行回调"| W
W -->|"请求用户交互"| B
B -->|"确认对话"| U
WebMCP 的安全模型与传统 MCP 有本质区别：
1. 认证：继承浏览器会话
WebMCP 运行在浏览器标签页内，天然继承：
这意味着 不需要单独配置认证——如果用户已经登录了某个网站，Agent 通过 WebMCP 调用该网站的工具时，自动拥有该用户的权限。
2. 安全约束
根据 W3C 规范：
3. 当前安全问题（事实：仍在讨论中）
根据 GitHub Issue #121（2026年3月），社区正在讨论以下安全提案：
graph TB
subgraph "WebMCP 安全模型"
A["SecureContext<br/>仅 HTTPS"] --> B["浏览器会话继承<br/>Cookies / SSO"]
B --> C["同源策略<br/>工具限于注册页面"]
C --> D["readOnlyHint<br/>只读工具标记"]
D --> E["requestUserInteraction<br/>敏感操作需用户确认"]
E --> F["（讨论中）Agent 白名单<br/>输入验证 / 安全策略"]
end
事实来源：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 - 获取俱乐部信息设计原则：
事实来源：VentureBeat（2026年2月12日）、Chrome 官方博客
如何启用：
chrome://flags/#enable-webmcp-testing可以做什么：
navigator.modelContext.registerTool() 注册工具当前限制：
// 注册一个搜索航班的工具
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: "chy"
}))
};
}
});
<!-- 直接在 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>
// 安装：npm install @anthropic/mcp-b
import { polyfillWebMCP } from '@mcp-b/global';
// 为不支持 WebMCP 的浏览器提供兼容
polyfillWebMCP();
// 之后正常使用 navigator.modelContext API
navigator.modelContext.registerTool({
// ... 与原生 API 相同的代码
});
Model Context Tool Inspector 扩展：
这是 Google 提供的官方调试工具，可以从 Chrome Web Store 安装。功能包括：
graph TB
subgraph "WebMCP 解决的核心问题"
P1["网站 = API<br/>无需额外维护后端 API"] --> V["WebMCP"]
P2["Agent 理解语义<br/>而非猜测像素"] --> V
P3["复用前端代码<br/>零后端改造"] --> V
P4["继承用户认证<br/>零认证配置"] --> V
P5["人在回路<br/>敏感操作需确认"] --> V
end
根据 Patrick Brosset（Microsoft，WebMCP 提案参与者）的澄清文章（2026年2月23日）：
MCP 协议由三层组成：
WebMCP 只关心第一层——它的工具定义（name, description, inputSchema, execute）与 MCP 工具几乎完全一致。但浏览器自己处理了第二层和第三层，使用浏览器内部机制（而非 JSON-RPC）来传递消息。
| 风险 | 说明 |
|---|---|
| 规范尚未稳定 | 仍为 W3C 社区草案，API 可能变化 |
| 声明式 API 未完成 | 规范中标记为 TODO |
| 安全模型待完善 | 正在讨论中（GitHub Issue #121） |
| 浏览器兼容性 | 目前仅 Chrome Canary 支持 |
| 采纳率未知 | 需要网站开发者主动集成 |
| 与现有自动化冲突 | 如何与 Playwright/Puppeteer 等工具共存需明确 |
timeline
title WebMCP 发展时间线
2025年8月 : 首次发布提案（GitHub）
2026年2月 : Chrome 146 Canary Early Preview
: W3C 社区草案发布
2026年Q2（推测） : Chrome Stable 支持
: 声明式 API 完善
2026年下半年（推测） : Edge 原生支持
: 更多浏览器跟进
: 首批生产级集成
2027年（推测） : 可能进入 W3C 正式标准化流程
WebMCP 是一个具有重要战略意义的 Web 标准提案。它解决了一个真实且迫切的问题——让 AI Agent 能够以结构化、可靠、高效的方式与 Web 应用交互，而不是像"盲人摸象"一样猜测 UI。
核心判断：
