让网站自己声明：
我能做什么
当一个 Agent 想帮你在 Booking.com 订机票时，它的做法通常是：截图 → 识别按钮 → 模拟点击 → 再截图 → 再识别……这套流程慢、容易出错，还极度依赖页面 DOM 结构不变。换句话说，现在的 AI Agent 其实是在用「看图说话」的方式操作一个本来应该是「结构化数据」的网页。OpenAI、Anthropic、Google 都在做 Computer Use 类能力，但每家的 Agent 成功率都不让人满意——Anthropic 自己公开的 OSWorld 基准上，最好成绩也只在 60% 左右。很多时候不是模型的错，是网页压根没为「机器读取」做过设计。
WebMCP（Web Model Context Protocol）是 Google Chrome 团队联合微软，在 W3C Web Machine Learning Community Group 下推进的开放网页标准提案。核心思路极其简单：让网站开发者主动声明「我能提供哪些操作」，浏览器将这张操作清单暴露给 AI Agent，Agent 直接调用，跳过所有视觉解析环节。
Agent 到达页面后，浏览器把已注册的工具列表暴露出来，Agent 直接调用 searchFlights()，拿到结构化结果，完全不需要截图、不需要猜 DOM。开发者有两条实现路径：声明式 API（适合简单场景，通过 HTML 表单标注即可）和命令式 API（完整 JavaScript 注册，支持复杂动态交互与完整 JSON Schema 校验），两种方式可以混用。
WebMCP ≠ Anthropic MCP，
但它们是兄弟
很多人看到「MCP」两个字会困惑：这和 Anthropic 的 MCP 是一回事吗？不是，但关系密切。
| 维度 | Anthropic MCP | Google WebMCP |
|---|---|---|
| 运行位置 | 服务器端 / 本地客户端 | 浏览器原生，客户端 |
| 协议 | JSON-RPC 2.0 over stdio/HTTP/SSE | 浏览器原生 API（navigator.modelContext） |
| 标准组织 | Anthropic 主导的开放规范 | W3C 社区组（Google + Microsoft） |
| 面向对象 | AI 平台与后端服务集成 | 网页与浏览器内 Agent 集成 |
| 用户会话 | 无 | 天然携带用户登录态和 Cookie |
一句话区分：Anthropic MCP 让 Agent 和你的服务器说话，WebMCP 让 Agent 和你的网站说话。两者是互补关系而非竞争——一个航旅公司完全可以同时部署后端 MCP Server 供 Claude/ChatGPT 直接集成，WebMCP 供用户浏览器内的 Agent（比如 Gemini in Chrome）操作订票流程。
发布时间线：2026 年 2 月 11 日 Google 发布早期预览；5 月 19 日 Google I/O 2026 开发者主题演讲正式宣布，WebMCP 进入 Chrome 149 Origin Trial（公开测试阶段）；现状仍是 Draft Community Group Report，尚未进入正式 W3C 标准流程，Chrome Canary 支持需开启 flag 或参与 Origin Trial。已表达兴趣或正在测试的品牌：Booking.com、Expedia、Instacart、Intuit、Shopify、Redfin——都是「高频操作型」网站，订酒店、买东西、报税、找房，正是 Agent 最需要精确操作、最怕截图失误的场景。
为什么这件事可能
比 Gemini 3.5 更重要
Google I/O 2026 发布了一堆东西：Gemini 3.5 Flash、Project Astra 更新、Veo 3……但有分析文章直接把标题写成「WebMCP 是 Google 在 I/O 2026 发布的最重要的东西（但几乎没人在谈论它）」。理由是：模型每半年就会迭代一次，但基础设施的变革才是决定未来 5-10 年格局的事。WebMCP 的潜在意义在三个层面：
- 重新定义 SEO 和流量——如果 AI Agent 成为用户访问网站的主要方式，「被 Agent 调用」将取代「被搜索引擎收录」成为网站的核心分发诉求。没有 WebMCP 工具的网站，对 Agent 而言等于不存在
- 改写 Web 开发范式——前端开发者未来需要面向三类用户设计：人类桌面用户、人类移动用户，以及 AI Agent。WebMCP 是第三类用户的接口规范
- Chrome 的战略护城河——WebMCP 绑定在 Chrome 的
navigator.modelContext上，目前 Firefox 和 Safari 都没有跟进。如果 AI Agent 时代真的到来，Chrome 将从「最大浏览器」变成「唯一 Agent 原生浏览器」——这对 Google 的战略价值不亚于当年 V8 引擎对 JavaScript 生态的统治
WebMCP 的深层逻辑，是 Google 在「AI Agent 成为网页主要访客」的未来下，提前卡位「Agent 与网页交互的协议层」。如果这个标准成为事实标准：Gemini in Chrome 将是原生 Agent，天然比其他 Agent 有优先访问权；Chrome 成为 Agent 经济的基础设施，而非只是人类的浏览工具；搜索广告之后，Google 可能在「Agent 调用网站工具」的链路上找到新的商业模式。WebMCP 不是一个独立的技术决策，而是「让 Chrome 成为 Agentic Web 操作系统」这个更大战略的一块砖。
风险与隐患：
不能只看亮面
继承 MCP 生态的既有漏洞——MCP 生态已暴露过真实攻击案例：针对 GitHub MCP Server 的 Prompt Injection 导致私有仓库内容外泄；恶意 npm 包通过 MCP 注入邮件到攻击者控制的服务器；WhatsApp MCP Server 被攻破后用户完整聊天记录被窃取。WebMCP 将这些风险带入浏览器——更糟的是，浏览器内工具执行天然携带用户登录态和 Cookie，一旦 handler 被劫持，攻击者获得的是「完整授权的用户会话」。
工具覆盖攻击（Tool Hijacking）——规范中存在开放 Issue：第三方脚本（广告 SDK、分析脚本）能否覆盖已注册的工具？如果可以，一个被植入恶意代码的第三方脚本就能把 submitPayment() 的 handler 替换成攻击者的版本。WebMCP 的信任模型目前尚未定稿。
结构化数据暴露风险——向 AI Agent 暴露结构化的产品列表、库存水位、定价策略，本质上是在给竞争对手提供一个结构化数据抓取接口，这和人类用户浏览网页的风险截然不同。
跨浏览器标准化难题——目前只有 Chrome（Canary）支持，Safari 和 Firefox 均未跟进。历史上 Google 单方面推进的浏览器标准，最终夭折的不在少数（还记得 FLoC 吗）。
开发者现在
要做什么
如果你是前端/全栈开发者，现在不需要急着在生产环境部署 WebMCP，但有几件事值得提前做：
立刻可做：阅读 W3C WebMCP 规范草案，理解 navigator.modelContext API 的设计哲学；参与 Chrome 149 Origin Trial，在测试环境跑通基本的工具注册和调用流程；梳理核心产品功能，思考如果 Agent 要操作这些功能，需要暴露哪些工具。
中期规划：和 SEO 策略一起考虑「Agent 可见性策略」——哪些工具要暴露、暴露到什么粒度；在安全审查中增加「WebMCP 工具注册」的权限管控机制；关注 Booking.com、Shopify 等先行者的实施案例。
持续观察：Mozilla 和 Apple 是否跟进是关键信号——如果 Firefox 和 Safari 在 2026 年底前仍不跟进，WebMCP 可能沦为 Chrome 专属功能，战略价值大打折扣。
综合判断
WebMCP 不是一个独立的技术决策，而是「让 Chrome 成为 Agentic Web 操作系统」这个更大战略的一块砖。观察 Google 过去几年的每一步——Chrome + V8 + Web Standards 的组合——会发现他们在浏览器标准上的耐心和战略一致性超过绝大多数公司。这未必会按计划进行，但值得持续盯着看。