过去三十年,Web 是为人设计的:页面被假设另一头坐着一个会读字、会点按钮、会填表单的人。搜索引擎爬虫一定程度上改变了这一假设,但它们走的是「抓内容回服务器」这条单向链路,被访问的站点既拿不到对应流量,也几乎拿不到对应署名。2024 年 11 月 Anthropic 开源 Model Context Protocol 之后,Agent 这一类新型访客被逐步推到台前——它们能调用工具、能跨页面保持上
过去三十年,Web 是为人设计的:页面被假设另一头坐着一个会读字、会点按钮、会填表单的人。搜索引擎爬虫一定程度上改变了这一假设,但它们走的是「抓内容回服务器」这条单向链路,被访问的站点既拿不到对应流量,也几乎拿不到对应署名。2024 年 11 月 Anthropic 开源 Model Context Protocol 之后,Agent 这一类新型访客被逐步推到台前——它们能调用工具、能跨页面保持上下文、能完成跨站点任务;但仍然在用「人类浏览器」的方式工作:解析 DOM、模拟点击、在弹出的 CAPTCHA 前卡住。这种「Agent 借人眼上网」的尴尬,正是 WebMCP 想要解决的问题。
Cloudflare 在 2026-08-06 发布的开发者博客《Give any website a WebMCP interface》中,给出了当前 WebMCP 工程化最具体的描述:WebMCP is a new browser standard, shipping experimentally in Chrome 146, that shows up in the page as document.modelContext. A site can choose to expose a set of tools for agents running in the browser, meaning agents no longer have to guess their way through a page built for humans. 这句话信息密度很高——它一次性回答了 WebMCP 的形态(Web 标准)、部署位置(Chrome 146 实验性)、接入入口(JS 全局对象 document.modelContext)、使用方式(站点主动注册工具)以及它要替代的东西(让 Agent 不再靠「猜页面」的方式工作)。这是迄今为止关于 WebMCP 协议定位的最清晰表述。
把 WebMCP 放回 Anthropic 2024-11 那篇 MCP 协议的原始定义里看:「The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools.」MCP 解决的是「AI 客户端如何接入数据源」,而 WebMCP 把这一原则前推到了浏览器侧——前端页面本身就是一个数据源,站点作为 MCP 服务器,浏览器里的 Agent 作为 MCP 客户端,中间通过 document.modelContext 这一原生对象握手。从协议层看,WebMCP 不是另起炉灶,而是 MCP 在 Web 平台的横向扩展;从工程层看,它是第一次给「站点主动对 Agent 说话」这件事提供了一份被浏览器默认接受的规范接口。
Cloudflare 同一篇博客里还提到一件非常务实的事:「Today we are launching a developer preview of WebMCP on Cloudflare. Switch it on and browser agents can start working with your site, with no code and nothing changed at your origin. Cloudflare adds a small bridge to your pages, which registers a set of tools for a visitor's agent to use.」——也就是说,Cloudflare 在自己的边缘网络上挂了一个「WebMCP 桥」,站点不需要改任何代码,只要打开开关,Cloudflare 就会在回源页面里自动注入一份工具清单,把页面里常见的可交互元素(按钮、表单、链接)翻译成 Agent 可调用的 Tools。这件事的工程意义是:WebMCP 的落地不必等每一个站点重写自己的前端,网络层可以先把这件事做掉,站点再按需接管。
浏览器侧,WebMCP 的另一半工程由 Chrome 146 的 document.modelContext 与 Cloudflare 自家的 BrowserRun 共同撑起。Cloudflare 写道:「BrowserRun, our remote browser, already added WebMCP support, so an agent can discover and call the tools a site exposes.」BrowserRun 是 Cloudflare 提供的可远程调用的浏览器,它的存在意义在于:很多 Agent 并不直接控制用户本机的 Chrome,而是通过远程浏览器去访问站点——这正是 Cloudflare 自己最擅长的「在网络边缘托管计算」场景。WebMCP 在 BrowserRun 里先一步跑通,意味着任何接入了 BrowserRun 的 Agent 都能立刻用上新协议;同时 Cloudflare Radar 也会很快提供 WebMCP 工具,让运营侧的 Agent 可以直接读雷达数据——这是协议落到真实产品的第一次批量演示。
理解 WebMCP 给整个 Agent 工程带来的变化,关键在于把过去那种「爬虫—>解析—>模拟」的三段式链路换掉。过去一个 Agent 想在一个电商网站里完成下单,要先抓 HTML、再用启发式规则从 DOM 里找出「加入购物车」按钮的位置、再模拟点击、再等页面跳转、再继续解析——任何一处前端改版,这一套脚本就可能失效。WebMCP 让站点把「加入购物车」「查询库存」「发起支付」这些动作直接以 Tool 的形式暴露出来,Agent 拿到的是结构化的工具描述(JSON Schema)和确定性的调用结果,而不是要解析的 HTML 字符串。这种从「解析 DOM」到「调用 Tool」的根本性切换,是 WebMCP 给 Agent 工程带来的最大一次性收益。
当然,WebMCP 不是没有代价。Cloudflare 那篇博客反复提到一个关键词:the site has to implement it. 协议标准是一回事,每一个站点愿不愿意暴露自己的业务 Tool 是另一回事。出于商业考量,有些站点会主动选择不暴露(例如电商不希望竞品 Agent 直接比价),有些站点会按场景选择性暴露(对登录用户暴露高级 Tool,对匿名 Agent 只暴露只读 Tool),还有些站点会反向把 WebMCP 当作新一代 SEO——把 Tool 描述当成给 Agent 看的「页面摘要」来运营。这意味着未来 1-2 年,WebMCP 生态里会很快分化出两类产品:一类是「主动暴露型」站点,自己写好 Tool 文档、把核心业务能力开放给 Agent;另一类是「网关代理型」服务,例如 Cloudflare 这种网络边缘方案,替不主动改造的站点自动从页面结构里反推 Tool 清单。
把视线从协议层再拉回到浏览器绑定这条工程基线。WebMCP 在 Chrome 146 里以 document.modelContext 这一原生对象形式存在,这件事意味着几件事:第一,任何 AI Agent 只要拿到一个普通 Chrome 实例(本地或远程),就能直接调用 navigator.modelContext 而不用额外装插件;第二,浏览器厂商对 document.modelContext 的实现进度会直接决定 WebMCP 的可用面——Chrome 146 之后,Firefox、Safari 是否跟进、跟进到哪个版本,是接下来 6-12 个月最值得跟踪的浏览器侧信号;第三,因为对象挂在 document 上,前端的反爬、限流、AB 测试、行为分析这些基础设施都可以照常工作,WebMCP 不会绕开它们,这给站点在「让 Agent 进来」和「把 Agent 拦在外面」之间留出了相当精细的可控空间。
对企业级 Agent 项目而言,WebMCP 落地最直接的红利在三类场景。第一类是「跨站点任务」:Agent 不再需要为每一个站点单独维护一套适配代码,只要目标站点支持 WebMCP,Agent 就能用统一的 Tool 调用协议完成下单、查询、修改、取消等操作,适配成本从「为每个站点写一遍爬虫」降到「检查每个站点有没有暴露 WebMCP 工具」。第二类是「企业内部系统集成」:那些不面向公网但仍然有浏览器入口的老系统(OA、ERP、CRM),可以在不重写的前提下,由浏览器扩展或网关把内部业务操作包装成 WebMCP Tool,供 Agent 调用。第三类是「运营监控与自动化」:Cloudflare Radar 即将提供的 WebMCP 工具就是一个例子,运营侧 Agent 可以直接拉取雷达数据,而不必再写爬虫或对接专门的 API。
回到工程基线这件事本身。WebMCP 目前的工程新基线可以浓缩成四句话:协议层基于 MCP、浏览器层挂在 document.modelContext、接入层由网络边缘代理(Cloudflare 这类)和站点主动实现两条路径并存、能力暴露粒度受站点主导。这条基线在 2026-08 已经由 Cloudflare 与 Chrome 共同搭起了骨架,接下来 1-2 年的关键问题会集中在三处:一是更多浏览器跟进 document.modelContext 的速度;二是 Tool 描述(JSON Schema、命名、参数语义)的标准化,让 Agent 在不同站点之间可以无缝迁移调用范式;三是 Tool 调用结果的审计与计费机制——站点暴露工具之后,谁来计量、谁来付费、谁来承担异常调用的责任,这些工程治理层面的问题会被迅速推上台面。
最后回到开发者视角。如果今天要为一个站点开启 WebMCP 支持,有两条现实可行的路径。路径一是 Cloudflare 这类网络边缘方案:把站点接入 Cloudflare,在面板里打开 WebMCP 开关,无需改任何业务代码,Agent 就能拿到一份由 Cloudflare 自动反推出的 Tool 清单,适合「想先看看效果、但短期内没人力改前端」的站点。路径二是站点主动实现:在前端代码里显式调用 document.modelContext,把自己愿意暴露的业务能力(查询订单、发起退款、订阅推送)一条一条注册成 Tool,适合「已经把 WebMCP 当作新一代 API 来规划」的团队。两条路径并不互斥,反而可以组合——边缘代理先兜底,站点再逐步把核心 Tool 从代理方案迁回自有实现,这是当前最务实的工程演进节奏。
