谷歌在 Chrome 146 版本中迈出了关键一步：原生支持 WebMCP (Web Model Context Protocol)。这一更新标志着 AI Agent 与浏览器交互的方式发生了范式转移——从依赖底层调试协议转向基于 Web 标准的原生集成。
然而，这项看似强大的功能目前正面临典型的 “鸡生蛋”困境：浏览器准备好了，但网站还没准备好。
技术飞跃：从 CDP 到 WebMCP
在 Chrome 144 及更早版本中，Agent 操作浏览器主要依赖 CDP (Chrome DevTools Protocol)。这种方式虽然强大，但存在明显短板：
- 重后端依赖：需要运行额外的 Python 或 Node.js 后端服务来桥接 CDP 和 Agent。
- 高 Token 消耗：为了理解页面结构，往往需要传输大量 DOM 信息，导致 Token 成本高昂。
- 复杂性高：配置繁琐，且容易因浏览器版本更新而断裂。
Chrome 146 引入的 WebMCP 彻底改变了这一格局：
- 前端即服务端：网页本身直接成为 MCP Server。通过嵌入特定的前端 JavaScript，网站直接向 Agent 暴露能力接口。
- 零后端部署：无需额外的中间件或后端服务，Agent 可直接通过浏览器原生能力与网页对话。
- 降本增效：
- 更省 Token：网站可以按需暴露精简的结构化数据，而非整个 DOM 树。
- 更高准确率：网站开发者最了解自己的数据结构，主动提供的接口比 AI 猜测的 DOM 解析更精准可靠。
现实困境：严重的“鸡生蛋”问题
尽管技术架构完美，但 WebMCP 目前的实用性几乎为 零，原因在于其核心机制：需要网站主动声明能力。
- 机制限制：WebMCP 不是像 CDP 那样强行读取页面，而是依赖网站在代码中显式声明：“我支持登录”、“我支持搜索”、“我支持下单”，并定义好对应的接口。
- 现状尴尬：
- 国外：谷歌正在推动各大头部网站（如 Google Search, YouTube, Gmail 等）逐步适配，但这需要时间。
- 国内：由于生态封闭及技术跟进速度差异，国内主流网站（微信、淘宝、抖音等）短期内主动适配 WebMCP 的可能性极低。
- 结论：在没有网站主动提供 MCP 描述文件（Manifest）的情况下，Agent 面对普通网页依然“两眼一抹黑”，无法发挥 WebMCP 的优势。
如何体验？
如果你是开发者或极客，想提前尝鲜或测试自己的网站：
- 打开 Chrome 146+ 浏览器。
- 在地址栏输入：
chrome://flags/#enable-webmcp-testing - 启用该选项并重启浏览器。
- 访问已适配 WebMCP 的网站（目前极少），即可观察 Agent 如何通过原生接口与之交互。
标准之战与生态博弈
WebMCP 是 W3C 推动的 Web 标准的一部分，谷歌此举意在确立浏览器作为 AI Agent 首选运行时 的地位。
- 长期利好：一旦形成标准，未来所有网站都将像今天支持 SEO 一样支持“Agent 优化”（AEO），互联网将从“人读”全面转向“人机共读”。
- 短期阵痛：在生态成熟前，基于 CDP 或 计算机视觉（CV） 的通用操作方案（如 ChromeClaw、OpenClaw 的浏览器自动化模块）仍是主流，因为它们不依赖网站配合，具有更强的通用性。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
