WebMCP（网页模型上下文协议）

现在的 AI Agent 在浏览器里干活，基本上是在模仿人的操作：解析渲染出来的 DOM，猜哪个按钮管什么用，填表、点击，然后祈祷页面布局别变。这种方式既脆弱又慢。WebMCP 想换一条路：网站自己的代码把一批具名工具——searchFlights、addToCart、applyCoupon——注册到一个标准的浏览器接口上，浏览器里的 Agent 用结构化参数直接调用这些工具。

这个名字点明了它的来历。WebMCP 借用了 mcp 的核心思路——由一方对外声明可供 AI 客户端调用的工具——但把这套东西搬进了浏览器。Anthropic 的 MCP 是服务端协议，走 JSON-RPC（stdio 或 HTTP），用来把模型连到后端系统；WebMCP 是客户端的 JavaScript API，完全在页面里运行，受浏览器现有安全模型的沙箱约束。两者是互补关系，不是竞争：网站可以用 MCP 服务器来支撑它的 WebMCP 工具，也可以不用。

WebMCP 目前在 W3C 的一个社区组里孵化，有包括 Google、微软在内的浏览器厂商参与，2026 年已经在 Chrome 的预发布版本里出现了早期实现。截至 2026 年，它还是一个在积极开发中的草案，而不是一个成型、已经广泛落地的标准——把它当作生态在探索的一个方向（让网站『对 Agent 可读』），而不是今天在所有浏览器里都能依赖的能力。

怎么运作

网页调用一个浏览器 API（提案中的形态是 navigator.modelContext）来注册一个或多个工具，每个工具带有名称、一段自然语言描述、一份带类型的参数 schema，以及一个 JavaScript 处理函数。浏览器侧的 Agent（内建在浏览器里，或者是扩展）读取这份工具清单，方式和 MCP 客户端通过 capability-discovery 读取服务器工具列表是一样的，然后判断哪个工具匹配用户目标，带上参数调用它。浏览器夹在中间：可以在工具执行前要求用户确认，可以限定工具能碰到的范围，还能让本页面的工具和其他来源相互隔离。因为处理函数是网站自己的代码，网站始终掌控实际会发生什么——Agent 拿到的是一份声明清楚的接口，而不是一个需要逆向的界面。

举个例子

一个订票网站加了三个 WebMCP 工具：searchFlights(origin, destination, date)、selectFlight(id)、startCheckout()。用户对浏览器 Agent 说『帮我订下周五飞柏林最便宜的直飞』。Agent 调用 searchFlights 拿到结构化结果，挑出最便宜的直飞航班，调用 selectFlight，再调用 startCheckout——到这一步，浏览器会先弹出确认框，用户点了才会真的下单。全程没有 DOM 抓取，也不用猜哪个 <div> 是价格。

和相关概念的区别

常见误解

常见问题