WebMCP 工程化:网站侧 MCP 化教学,Agent 与网页交互的协议层新基线 · 重庆智能体开发 · 行业资讯

2026 年 2 月底,Google Chrome 团队把 WebMCP 推到 Origin Trial,从 Chrome 149 开始可以本地通过 chrome://flags/#enable-webmcp-testing 启用。3 月,WebMCP 提案进入 W3C Web Machine Learning Community Group。8 月初,Angular 给出实验性支持。提案的核心命题一句话就能讲清楚:Web 页面可以把自己注册成一个 MCP server,把页面里的功能以带自然语言描述和结构化 schema 的"工具"形式暴露给 AI Agent,Agent 直接调用这些工具,而不是去 DOM 里猜哪个 div 是日期选择器、哪个绿色按钮是"确认"。这意味着 Agent 与网站交互的方式,从"屏幕截图式屏幕抓取"升级到"声明式 API 调用",Agent 的可靠性第一次有了协议层的支撑。

这件事的产业意义在于:过去两年 Agent 与网站交互的所有方案都是"让 Agent 更聪明地去理解 HTML"——但 HTML 是为人类视觉设计的,不是为机器调用设计的;无论模型多强,只要布局改一下、CSS 类名变一下、cookie banner 加一下,Agent 就会点错。WebMCP 换了思路:让网站自己声明能做什么,Agent 调用声明的接口;网站重设计只影响视觉,不影响接口。这件事改写的不是单点技术,而是 Agent 与开放互联网交互的协议基线。下面是它能给企业 Agent 落地带来的 10 个具体启示。

1. 从"屏幕抓取"到"声明式接口":稳定性的来源换了

今天大多数 Agent 操作网站的方式,等价于"通过电话描述截图来操作电脑"——Agent 加载页面,读原始 HTML,猜 40 个 div 里哪个是日期选择器,猜测绿色按钮可能是"确认",点它,等响应,重新读整屏确认是否生效。下周按钮位置变了 Agent 就坏,改个 CSS 类名 Agent 也坏,加个 cookie banner Agent 就点错地方。这是一切 Agent 屏幕抓取方案的固有脆弱性,因为 Agent 在每一次执行时都在反向工程 UI。

WebMCP 提议的解法是:网站自己声明能做什么。页面注册一个 book_table 工具,接受 date、time、party size 三个字段,Agent 调用它;页面重设计不影响工具名和 schema,只要接口契约稳定,Agent 就不会坏。这个稳定性来源的切换是根本性的——从"Agent 必须聪明地猜"变成"网站必须清晰地声明"。对网站运营方来说,这把 Agent 友好的责任从 Agent 一侧推到了网站一侧。

2. 它是 MCP 在浏览器里的延伸,不是替代

理解 WebMCP 的最好锚点是 MCP。MCP 给 AI 提供了一种调用 server 端工具的标准方式;WebMCP 把同一个思路搬到浏览器:网页本身成为提供工具的地方,工具跑在你已经打开的 tab 里、用你已经在登录的会话。WebMCP 的提案首页明确说,使用 WebMCP 的网页可以被视作在客户端脚本里实现工具的 MCP server。这个定位决定了 WebMCP 不是要替代 MCP,而是要把 MCP 拓展到浏览器场景。

这意味着企业已有的 MCP server 投资(给 Notion、Linear、内部数据库暴露工具的 MCP)可以平滑延伸到 Web 端——同一个 Agent 同时通过 MCP 访问后台服务、通过 WebMCP 访问网页,工具集合与调用方式是一致的。这种一致性对 Agent 框架的设计者来说,意味着同一套 tool discovery、tool calling、tool validation 逻辑可以复用,不必为浏览器单独写一套。

3. 协议成熟度:Community Group Draft,不是 W3C 标准

在热情拥抱之前必须诚实标注 WebMCP 的成熟度。它当前是 W3C Web Machine Learning Community Group 草案,不是完成态的 W3C 标准,也尚未走上正式的 standards track。Google Chrome 团队的明确表述是"under active discussion and subject to change"。Angular 已经给出实验性支持,但整体仍处于"现在尝试并塑造它"的阶段,不是"上生产"的阶段。

对企业来说,这条信息的意义是:WebMCP 的协议接口细节在 2026 年下半年还可能变化。一个具体的例子是入口 API 的迁移——早期草案用 navigator.modelContext,最新版本改成 document.modelContext,因为工具应该属于一个 document,不是整个浏览器。如果跟着老教程写,会写错入口。优雅的写法是 const mc = document.modelContext || navigator.modelContext 兼容两边。这条教训会在 1 到 2 年的协议成长期里反复出现,任何今天投入 WebMCP 的团队都要为此预留适配层。

4. 注册一个工具,只需要 10 分钟

把协议讲得再玄,真正决定 WebMCP 能不能落地的,是它对一个普通开发者有多轻。Chrome 官方文档给出的最小示例:用一个 registerTool() 调用,声明工具名、描述、输入 schema,以及一个调用既有 JS 函数的 execute。整个调用链的长度大约 10 行 JavaScript。函数执行时跑在页面已有 JS 里、用页面已有状态、用用户已经在登录的会话。Agent 通过 getTools() 发现工具,通过 AbortController 撤回不再相关的工具。

这意味着企业把现有 Web 应用改造成 WebMCP 兼容的成本,是"用现有 JS 函数包一层声明式接口",而不是重写任何后端逻辑。10 分钟的入门门槛决定了 WebMCP 不只是给 AI-first 公司用的工具,而是任何已经有 Web 应用的传统企业都能用得上——这是它能成为协议基线的关键前提。

5. 声明式与命令式两套 API,适配不同人群

WebMCP 同时提供两套 API。命令式 API(registerTool)让开发者用 JavaScript 显式声明工具,适合复杂逻辑、需要调用现有 JS 的场景。声明式 API 则让开发者直接在 HTML 表单上加注解,框架自动把表单字段转成工具 schema,并把"填写这个表单"翻译成 Agent 可调用的工具。这种设计把"前端工程师"和"无 JS 背景的产品/运营"分成两个入口:前者写命令式 API 解决复杂业务逻辑,后者写声明式注解快速暴露简单表单。

对企业 Agent 治理来说,这两套 API 都进入治理范围——Agent 调用的工具,无论是命令式还是声明式,都要进入审计、权限、配额管理。命令式 API 给企业治理者更明确的代码入口,声明式 API 则要求框架层提供集中扫描机制,确保没有一个团队悄悄用表单注解暴露了不该暴露的工具。

6. 在用户已经登录的会话里执行,可观察可信任

WebMCP 的 execute 函数跑在页面已经加载的 JS 里,用页面已经有的状态,用用户已经在登录的会话——这意味着 Agent 不是某个隐形 headless 浏览器在用偷来的凭证操作,而是在用户打开的、被认证的 tab 里调用用户已经登录的网站功能。这一点对 Agent 可信度是颠覆性的:用户能看见 Agent 在做什么,因为它就在自己面前那个 tab 里运行;用户能随时打断,因为一切都在自己的浏览器会话里;网站保持对暴露什么的控制,因为声明式接口由网站自己定义。

这条信任链对企业 Agent 落地的意义在于:合规、审计、用户体验三个维度都被同时优化了。合规方面,Agent 操作的是用户已经在登录的会话,没有"绕过认证"的法律灰色地带;审计方面,所有工具调用在浏览器层面可观察、可记录;用户体验方面,用户看着 Agent 操作自己的 tab,信任成本降到最低。这是 WebMCP 相比 headless 浏览器 + cookie 注入方案最大的优势。

7. 与服务端 MCP 的真实分歧:不是替代,是分层

HN 上对 WebMCP 出现了清晰的反对声音:有评论者认为,想给 Agent 提供能力的网站应该直接暴露服务端 MCP——服务端拥有工具,Agent 不必经浏览器——这正是现在很多网站已经做的事。WebMCP 把同样的事情路由到浏览器里,创造一个"会跟真实 UI 漂移的副本",长期来看是过度设计。同一批评论者指出,长尾网站不会为 Agent 写任何接口,这些网站只能靠浏览器"更聪明地读现状"来接入,WebMCP 对它们毫无帮助。

这个分歧的真实答案不是"谁对谁错",而是分层:核心业务能力(下单、查库存、改订单)走服务端 MCP,确保强一致性、强权限、强审计;长尾交互(填表、看文档、订餐厅)走 WebMCP,让已有页面直接暴露交互而不必为每个长尾场景都写后端。两层都用,关键业务严谨,长尾业务灵活。对企业来说,WebMCP 不是替代服务端 MCP,而是补齐了"已有 Web 资产快速 Agent 化"这条以前空白的能力线。

8. 安全模型的根本挑战:信任网站 vs. 信任 Agent

WebMCP 把安全模型翻转了。传统 MCP 模型里,Agent 信任服务端工具,因为是用户主动选择接入的,工具接口签名可见、调用历史可审计。WebMCP 模型里,网站定义工具,浏览器决定调用哪个——这意味着信任的对象从"用户选定的 server"变成"用户访问的任意网站"。一个恶意网站可以暴露"看起来有用"的工具,实际上把 Agent 会话里的上下文数据外泄出去。

这条安全模型的根本挑战,目前没有干净的解。WebMCP 的提案里提到了 origin scoping(工具只能在同源下被调用)和 exposure control(网站决定工具暴露给哪些 origin),但这些都是网站侧的能力,而不是 Agent 侧的能力。最终决定 WebMCP 安全性的,是浏览器对工具调用的统一拦截策略——浏览器需要像对待跨域请求一样,给 Agent 工具调用建立同源策略、用户授权、调用配额三层防御。这是 WebMCP 走向成熟必须解决的开放问题。

9. 可观察性革命:从"看不见的 DOM 抓取"到"可见的工具调用"

WebMCP 给 Agent 可观察性带来的提升是结构性的。在屏幕抓取时代,Agent 在网站里做了什么,对网站运营方来说几乎是不可见的——Agent 加载页面、读 HTML、模拟点击,这些操作对前端监控来说都是正常的浏览器行为,无法区分是人类操作还是 Agent 操作。WebMCP 把 Agent 的每一步操作变成显式的工具调用,调用名、参数、返回值都在浏览器 DevTools 和前端监控里可观察。

这意味着网站运营方从今天开始就能知道"哪些 Agent 在用我的网站、用得多频繁、调用了哪些工具、参数模式是什么、调用有没有失败"。这些数据以前只能通过昂贵的服务端日志部分重建,现在通过 WebMCP 直接在前端就有了。这是把"Agent 是我的网站的隐形用户"变成"Agent 是我的网站的可分析用户"的关键技术转折。

10. 企业落地的实操清单

把上面 9 个启示压成可执行清单,一家认真对待 WebMCP 的企业应该从今天开始做这些事。第一,把现有 Web 应用梳理成"哪部分适合走服务端 MCP、哪部分适合走 WebMCP",前者覆盖核心业务能力,后者覆盖长尾交互与表单填写。第二,在改造优先级上,先做"已经有清晰表单交互"的产品页面(WebMCP 适配成本最低),再做复杂业务逻辑页(用命令式 API 包现有 JS)。第三,把 WebMCP 工具注册纳入前端代码评审清单,任何 registerTool() 调用都要经过安全审计,确保工具描述和参数不暴露敏感操作。第四,在前端监控里增加"Agent 工具调用"维度,统计每个工具的调用频率、失败率、来源 Agent,作为未来 Agent 流量治理的基础。第五,在 Agent 框架里增加 WebMCP 工具的特殊处理——比如要求浏览器弹窗让用户确认敏感工具调用,而不是默默执行。第六,跟踪 W3C Web Machine Learning Community Group 的协议演进,在 document.modelContext 与 navigator.modelContext 这类入口迁移上保持代码兼容。第七,把 WebMCP 安全模型的不成熟性透明告知业务方,任何 Agent 走 WebMCP 完成的业务,都要假设其可能受恶意网站工具欺骗,关键操作必须有服务端二次校验兜底。

协议基线的真正含义

WebMCP 给出的最大启示不是某项具体技术,而是 Agent 与开放互联网交互的方式第一次有了协议层的支撑。在此之前,Agent 与网站的所有交互都是单点集成、屏幕抓取、脆弱的 UI 反向工程;在此之后,网站可以通过声明式接口主动暴露能力,Agent 通过调用这些接口完成工作,二者用同一个契约说话。这种契约的稳定性,直接决定了 Agent 能不能从"个人开发者的玩具"走到"企业生产的基础设施"。

对企业来说,WebMCP 是 2026 年下半年最值得提前布局的 Agent 协议之一——不是因为它的 API 已经稳定到可以生产使用,而是因为它的方向正确,提前理解、提前实验、提前参与标准演进,能让企业在协议成熟时第一时间拿到红利,同时避免被不成熟的协议细节绑架。这是从"屏幕抓取时代"走向"协议化时代"的过渡期,过渡期的投入回报曲线最陡。