WebMCP 是什么
基本定义
WebMCP（Web Model Context Protocol）是 Google 与 Microsoft 在 W3C 框架下联合推动的浏览器原生 Web API。Chrome 146 已推出早期预览版本，核心目标是让网页主动将自身能力封装为结构化工具，供 AI Agent 直接调用，解决当前 Agent 操作网页的稳定性与效率问题。
核心思想
把交互从 UI 层搬到语义层。不再依赖按钮点击、坐标定位或 DOM 解析，而是让网页直接暴露'提交请假''搜索航班''加入购物车'等业务动作，形成结构化工具契约，Agent 按契约调用而非'猜 UI'。
关键特性
- 双轨 API 设计：声明式 API（HTML 表单属性）+ 命令式 API（JavaScript 注册），兼顾易用性与灵活性
- 浏览器内运行：纯客户端实现，网页本身就是'工具服务器'，天然继承用户登录态与权限上下文
- 结构化上下文：支持网页提供 JSON 格式的业务状态（如购物车、表单草稿），大幅降低模型理解成本
- 工具契约化：每个工具包含名称、描述、输入输出 Schema、执行逻辑，变更可控
解决的核心痛点
当前 Agent 操作网页的两大路线均存在缺陷：
| 交互路线 | 核心问题 | WebMCP 解决方案 |
|---|---|---|
| 视觉路线（截图识别） | 慢、贵（约 2000 token/次）、易出错 | 语义化工具调用，Token 消耗减少约 89% |
| DOM/选择器路线 | 脆弱（改版即失效）、复杂场景难处理 | 工具契约不变则不受 UI 变更影响 |
WebMCP 让 Agent 从'呈现层倒推业务动作'转变为'直接调用业务动作'，稳定性与效率显著提升。
与 Anthropic MCP 的区别
WebMCP 与 Anthropic MCP（Model Context Protocol）虽同名，但架构完全不同，聚焦领域互补，成熟应用可同时部署。
| 对比维度 | Anthropic MCP | WebMCP |
|---|---|---|
| 协议基础 | JSON-RPC 2.0 | 非 JSON-RPC，纯 Web 原生 API |
| 架构模式 | Client-Server（需后端服务器） | 纯客户端（网页即'服务器'） |
| 运行位置 | 后端独立服务 | 浏览器前端环境 |
| 认证机制 | OAuth 2.1 | 浏览器原有认证（Cookie、Session） |
| 可用性 | 服务器常驻运行 | 用户导航到页面时才可用 |
| 聚焦场景 | 后端服务集成、跨系统数据访问 | 前端浏览器交互、网页功能调用 |
| 核心优势 | 统一后端集成标准 | 天然复用浏览器上下文、低接入成本 |
关键结论：Anthropic MCP 解决'AI 如何连接后端服务'，WebMCP 解决'AI 如何操作前端网页'，二者相辅相成，非竞争关系。
项目中如何接入 WebMCP
接入准备
- 环境要求：Chrome 146+（开启
chrome://flags/#enable-web-model-context）或使用 MCP-B Polyfill 兼容其他浏览器 - 适用场景：优先内部系统（OA/ERP/管理后台）、高频标准化流程、可控制的站点
- 人员要求：前端开发（熟悉 HTML/JS），无需后端改动即可实现基础接入
两种接入方式（从易到难）
方式一：声明式 API（零 JS 代码）
适用于简单表单场景，直接在 HTML 标签添加属性，浏览器自动生成工具 Schema。比如一个请假申请表单，只需这样写：
<!-- 示例：请假申请表单 -->
<form toolname="submitLeaveRequest" tooldescription="Submit a leave request with date and reason">
<input name="date" type="date" required toolhint="Leave date in YYYY-MM-DD format">
<input name="reason" type="text" minlength="2" maxlength="200" required>
<button type="submit">提交申请</button>
</form>
方式二：命令式 API（JavaScript 注册）
适用于复杂交互场景，通过 navigator.modelContext.registerTool() 注册动态工具。这里要注意异步处理，因为业务逻辑往往涉及网络请求：
// 示例：注册'提交请假'工具
navigator.modelContext.registerTool({
name: "submitLeaveRequest",
description: "Submit a leave request in the current OA session",
inputSchema: {
type: "object",
properties: {
date: { type: "string", pattern: "^\\d{4}-\\d{2}-\\d{2}$" },
reason: { type: "string", minLength: 2, maxLength: 200 }
},
required: ["date", "reason"]
},
outputSchema: { type: "string", description: "Result message" },
annotations: { readOnlyHint: "false" }, // 非只读，需用户确认
async execute({ date, reason }) {
// 复用现有业务逻辑
const result = await window.oa.leave.submit({ date, reason });
return {
content: [{ type: "text", text: result.message }]
};
}
});
方式三：上下文提供（增强 Agent 理解）
为了让 Agent 更懂当前状态，可以主动推送快照数据：
// 示例：提供购物车上下文
navigator.modelContext.provideContext({
name: "cart",
description: "Current shopping cart snapshot",
data: {
items: [
{ sku: "SKU-001", qty: 2, name: "无线鼠标" }
],
total: 199.0,
currency: "CNY"
}
});
生产级接入最佳实践
3.1 工具设计原则
- 动作化而非元素化：暴露
createOrder()而非clickSubmitBtn()，避免 UI 耦合 - 强约束输入：使用 JSON Schema 定义参数格式、范围、必填项，减少无效调用
- 标签化工具：通过
annotations区分只读、需确认、破坏性动作，强化安全控制 - 粒度适中：一个表单/流程对应一组工具，避免过细导致调用繁琐
- 可恢复设计：失败场景分类（可重试/需确认/权限不足），提供补救路径
3.2 落地步骤（低风险到高风险）
- 只读工具先行：查询、导出、对账等无副作用功能，零风险验证链路
- 可回滚写入：草稿保存、批量填充、预校验，加入幂等键与状态对齐
- 不可逆操作：提交、支付、删除等，必须添加用户确认、审计日志、权限收敛
3.3 配套设施
- 调试工具：Chrome 扩展'Model Context Tool Inspector'，用于查看注册工具与调用记录
- 可观测性：记录工具调用日志，关联用户、时间、参数、结果，支持审计与问题排查
- 兼容性处理：使用 MCP-B Polyfill（
@mcp-b/webmcp-ts-sdk）支持非 Chrome 浏览器 - 前端框架集成：React（
useWebMCP钩子）、Vue 3（组合式 API）等已有成熟适配方案
WebMCP 的风险与安全防护
核心风险点
1.1 安全风险
- '致命三元组'问题：用户同时打开银行与恶意标签页时，Agent 可能被操纵泄露敏感数据
- 权限放大：Agent 获得网页操作权限后，可能执行超出用户预期的操作
- 工具滥用：恶意网页可能注册伪装工具，诱导 Agent 执行有害操作
- 隐私泄露：网页可通过工具调用记录构建用户画像，引发静默追踪风险
1.2 工程风险
- 标准不稳定：当前为早期草案，API 形态、最佳实践可能变更，Apple/Safari、Mozilla/Firefox 暂未参与
- 兼容性局限：短期依赖 Chromium 生态，跨浏览器支持需时间
- 适用范围受限：仅可控站点可用，不可控外部站点仍需传统自动化兜底
- 维护成本：工具契约需随业务变更同步更新，增加前端维护负担
安全防护建议
2.1 基础安全措施
- 最小权限原则：只暴露愿意被自动化的能力，隐藏内部功能与敏感操作
- 默认不信任：写入、支付、删除等动作默认要求用户确认，提供可视化操作记录
- 隔离上下文：避免 Agent 同时获取多个敏感站点的工具与数据访问权限
- 安全上下文：仅在 HTTPS 与顶级浏览上下文中启用 WebMCP，遵循同源策略与 CSP
2.2 企业级安全治理
- 权限体系：建立工具级权限控制，明确谁能用、能用哪些工具、操作范围
- 审计机制：所有工具调用可追溯、可回放、可撤销，满足合规要求
- 安全审查：工具注册前需安全评估，避免暴露敏感操作或引入注入风险
- 域信任控制：设置域信任 TTL，限制 Agent 跨域操作的时效性
风险权衡与使用边界
适合使用 WebMCP 的场景：
- 高频、重复、标准化流程（报销、请假、采购、对账）
- 可控站点（自研系统、内部系统、SaaS 管理台）
- 出错代价可控，且愿意实施权限、确认、审计机制
- 希望服务更容易被 AI Agent 使用，获取 Agent 流量红利
不适合使用 WebMCP 的场景：
- 不可控且频繁变更的外部站点
- 强依赖人类主观判断的流程（需读附件、看图、主观审批）
- 失败会造成不可逆损失，且不愿投入安全控制成本
- 禁止自动化的场景（票务、风控、身份验证页面）
总结与未来展望
WebMCP 标志着浏览器开始将 AI Agent 视为'一等公民'，推动 Web 生态向'双用户群'（人类+Agent）演进。短期落地将是'WebMCP 工具化站点 + 传统自动化兜底'的混合路线，长期有望成为 AI 与 Web 交互的标准范式。
核心建议：将 WebMCP 视为工程化能力而非银弹，优先在可控内部系统试点，从只读工具入手，强化安全与可观测性，逐步扩展至核心业务流程，为 Agent 时代的 Web 交互提前布局。
参考资料
- WebMCP W3C 社区组草案：https://webmachinelearning.github.io/webmcp/
- MCP-B 参考实现：https://github.com/MiguelsPizza/WebMCP
- Chrome 官方博客：https://developer.chrome.com/blog/webmcp-epp
- WebMCP 安全隐私考虑：https://github.com/webmachinelearning/webmcp/blob/main/docs/security-privacy-considerations.md