WebMCP：让每个网站自带MCP服务器，AI代理不再靠截图

传统AI代理在浏览器里操作网页，靠的是截图、坐标点击和DOM猜测。这种方式脆弱、低效，而且对动态页面几乎无能为力。WebMCP提出了另一条路径：让网站主动声明自己能做什么，把Web应用变成一个可直接调用的MCP服务器。

从截图猜测到工具声明：交互范式的转变

目前大多数浏览器代理的工作方式是"看"页面——截图后交给视觉模型判断按钮位置，再模拟点击。这条链路长、延迟高，且一旦页面改版就全部失效。

WebMCP的核心变化在于，网站可以显式暴露自己的工具集。你告诉代理"这里有一个搜索接口""这里可以创建订单"，代理就能像调用传统MCP服务器一样直接调用，而不必再去理解像素和布局。

据该视频介绍，这一能力通过一个名为 document.modelcontext 的API实现，代理可以列出并调用页面暴露的工具。这意味着前端开发者在设计界面之外，还需要像设计REST API一样思考"代理可以怎么用我的页面"。

MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放协议，用于让 AI 模型以统一方式发现和调用外部工具与数据源。其核心抽象是"服务器"：一个 MCP 服务器向客户端声明自己提供哪些工具（tools）、资源（resources）和提示模板（prompts），客户端据此发起结构化调用，而非依赖自然语言猜测。WebMCP 复用了这一语义模型，只是把"服务器"的宿主从后端进程换成了网页本身，因此理解传统 MCP 的工具注册与发现机制，是理解 WebMCP 调用体验为何"看起来非常像"的前提。

API形态：与MCP保持一致的调用体验

作者强调，WebMCP的调用方式"看起来非常像使用传统MCP"。这对已经熟悉MCP生态的开发者是个利好——不需要重新学习一套概念模型，工具注册、发现和调用的语义基本平移到了浏览器环境。

除了命令式地通过 document.modelcontext 暴露工具，WebMCP还提供了一种声明式写法。声明式路径的价值在于兼容性：即使访问者用的是传统代理（不支持WebMCP协议），网站仍可正常交互，不会因为做了额外适配而对旧代理产生排斥。

这种"渐进增强"的设计思路值得注意。它降低了网站接受WebMCP的门槛——你可以先加一层声明，再逐步演进到完整的工具暴露。

实战演示：Claude Code通过远程调试驱动网页

视频中展示了演示者用Claude Code操作自己网站的过程，并且"严格通过WebMCP API"完成。

关键机制在于控制通道：Claude通过Chrome的远程调试协议（Remote Debugging Protocol）接管浏览器。连接建立后，它可以请求任意标签页的MCP服务器，并以传统MCP服务器的方式与页面交互。

这里有一个容易被忽略的结构性变化。传统MCP服务器对接的是后端服务——数据库、内部API、第三方系统。WebMCP把MCP的落点前移到了前端应用本身。代理获得的不只是"自动化能力"，还包括对网站功能的理解：这个页面能做什么、有哪些约束、哪些操作是安全的。

对代理而言，这接近一种"自我描述的界面"；对开发者而言，这是把网页从"给人看的UI"扩展为"给代理用的接口"。

当前阶段：从Origin Trial走向浏览器设置开关

WebMCP尚未成熟。据视频中的说明，Chrome已经将这项能力从Origin Trial阶段推进到可以通过浏览器设置直接启用的阶段。

这个阶段定位很重要：Origin Trial通常意味着API还在变动，而进入设置开关说明实现已相对稳定，但标准仍在推进中。作者也明确提到，WebMCP"仍处于早期阶段"。

Chrome官方正在发布相关资料，可作为深入了解的起点。

另一个关键信息是跨浏览器意图。作者明确表示"这不只是Chrome的东西"，WebMCP设计上将在各类浏览器中可用。如果这一目标兑现，它有可能成为一种跨浏览器的代理交互标准，而非某一家浏览器的私有特性——这对生态意义重大。

Origin Trial 是 Chrome 针对尚在孵化的 Web 平台特性提供的限时试用机制：开发者需为自己的源（origin）注册令牌，才能在真实用户环境中小范围启用该 API 并收集反馈。它的存在通常意味着规范仍在演进、接口可能发生破坏性变更。相比之下，"浏览器设置开关"是面向普通用户的实验性功能入口（如 chrome://flags），说明底层实现已较为完整、可以稳定开启，但并不等同于标准化完成——距离进入 W3C 正式规范、被其他浏览器引擎实现仍有距离，这也解释了为何文中强调其"仍处于早期阶段"。

对开发者和代理生态意味着什么

短期看，WebMCP最直接的价值是自动化测试和RPA场景。工具声明比截图点击稳定得多，维护成本也更低。

中期看，它改变了网站与代理的协作边界。当网站主动提供结构化能力，代理就不再需要"逆向工程"UI，而是可以直接基于契约执行任务。这对电商、SaaS、企业内网应用都是实质性的变化。

长期看，作者给出了一个颇具信心的判断："我认为很多网站都会自带WebMCP"，并称这会让代理与网站之间的交互体验"非常丰富"。这不是单纯的技术升级，而是网页从"人类可读"向"代理可调用"的双重身份演进。

对开发者来说，值得做的动作是：先在自己的一个内部项目上，用 document.modelcontext 暴露一两个只读工具，观察代理调用时的行为与失败模式。声明式写法成本更低，适合作为第一步验证。

对产品团队来说，问题则变成：如果代理是新型用户，我的网站该暴露什么、隐藏什么、如何鉴权？这些问题在WebMCP普及之前想清楚，会比事后补课从容得多。

背景补充

Chrome 远程调试协议（Chrome DevTools Protocol，CDP）是浏览器对外暴露的底层控制接口，开发者工具、Puppeteer、Playwright 等工具均构建于其上。通过以 --remote-debugging-port 启动 Chrome，外部程序可以枚举标签页、注入脚本、读取网络与控制台信息。在 WebMCP 的演示中，CDP 充当的是"传输通道"角色：代理先借它接入浏览器上下文，再在页面内访问 document.modelcontext 暴露的工具集，从而把浏览器自动化的控制面与 MCP 的工具调用面拼接起来。