原文：Everyone’s Missing the Point of WebMCP，作者 Alice Moore

AI 助手在帮用户处理浏览器内的任务时越来越得心应手，但它们仍然需要人频繁地从旁引导。

它们会点错东西，会跑偏思路。它们能完成令人印象深刻的工作，但前提是有人一步一步地在界面上推着它走。问题的根源不在于网页缺少某种暴露数据的新方式，而在于这些助手仍然要在一个专为人类设计的软件里靠猜来完成操作。

WebMCP 有意思，就在这里。

不是因为它要取代 API，也不是因为每个网站突然都变成了 AI 的接入端点，而是因为它让一个正在运行的页面有了一种途径：向已经在浏览器里协助用户的助手暴露结构化的操作。少了盲目点击，少了 UI 瞎猜，用户、助手和应用之间的协作有了更清晰的路径。

如果这一切能实现，其含义比表面看起来实在得多：浏览器内的 AI 辅助，或许真的可以从”好看的 demo”走向日常可用的东西。

WebMCP 是什么？

WebMCP 是一项拟议中的浏览器端标准，用于从正在运行的网页中暴露结构化工具。Chrome 将其描述为：让网站向 AI 智能体暴露结构化工具，从而让它们以更快的速度、更高的可靠性和更精准的方式执行操作。该提案将这些工具定义为：携带自然语言描述和结构化 schema 的 JavaScript 函数，直接由页面本身对外暴露。

这就是 WebMCP 不一样的地方。

对于后端 MCP 或传统 API 而言，AI 是直接与后端服务通信的 — 不需要任何活跃的页面。当智能体需要对数据和系统进行结构化的、面向智能体的访问时，这依然是最佳方案。

对于浏览器自动化而言，智能体会尝试像人一样操作界面：点击、滚动、输入、从错误中恢复，并理解屏幕上显示的内容。Playwright 本是为 Web 应用端到端测试而生的，而 Playwright MCP 则将这套模型通过结构化的 accessibility 快照延伸到了 LLM 的使用场景。OpenAI 的”computer use”也是类似的思路：像人类一样使用图形界面。

WebMCP 介于两者之间。它赋予页面一种表达能力：”这是我支持的操作，这是它们的含义，这是助手在与用户共享同一个活跃上下文时调用它们的方式。”

WebMCP vs MCP vs 浏览器自动化

最简明的区分方式如下：

• 使用 API 或后端 MCP：当智能体需要直接、结构化地访问系统和数据，且无需依赖活跃页面时。
• 使用浏览器自动化：当它需要像人类一样操作 UI 时，无论是用于测试、任务执行，还是完整的 computer use 场景。
• 使用 WebMCP：当用户已经在浏览器中，且希望助手能以比盲目点击和 DOM 猜测更可靠的方式配合页面工作时。该提案将其定位于有用户参与的本地浏览器工作流，而非服务器间通信或无监督的自主执行场景。

三层各司其职，职责分明。

WebMCP 真正适用的场景

WebMCP 并非 API 或后端访问的替代品。

如果智能体需要批量结构化数据、程序化的条件分支，或者根本不依赖活跃页面的工作，后端集成仍然是更合适的选择。WebMCP 面向的是那些希望在活跃的用户体验中与助手协同配合的网站。

这意味着更少的 UI 摸索，以及用户、页面与助手之间更充分的上下文共享。Chrome 把速度、可靠性和精准度放在首位，原因也在于此。

这也解释了为什么 WebMCP 对 AI 浏览器和浏览器内助手的意义，远大于对传统页面抓取讨论的意义。

WebMCP 为何对 AI 浏览器和助手意义重大

这里真正发生的变化不是某款具体产品，而是一个方向：人们想要在浏览器里、在自己正在做的事情当中得到帮助，而不仅仅是在一个独立的聊天窗口里。AI 浏览器、智能 IDE 以及浏览器内助手，都在朝这个方向发力。

这个诉求很好理解，但实际体验参差不齐。这些系统在演示中往往表现亮眼，一旦落地使用便开始露出破绽，尤其是当它们不得不从混乱的界面和残缺的上下文中推断意图时。如果你曾亲眼目睹一个 AI 浏览器走错一步，然后自信满满地在错误的基础上越走越远，你就明白问题所在了。

这正是 WebMCP 的价值所在。它提供了一条比让助手只通过 UI 逆向工程每个网站更清晰的路径。如果一个网站能够直接暴露结构化的操作和上下文，助手就少了很多猜测的必要。这并不能消除所有失败场景，但确实能让交互从”computer use 杂技”的范畴，向人们真正可以信赖、用于重复性任务的方向迈进。

这一点之所以重要，是因为浏览器本身就已经掌握着助手通常费力重建的那些上下文信息：当前页面、当前会话、用户所处的状态，以及他们恰好需要帮助的那个时刻。WebMCP 无法像变魔术一样解决信任或权限问题，但它确实为网站提供了一种更清晰的参与方式，而不是逼着助手从像素和标记语言中推断一切。

为何部分产品副驾驶可能沦为多余

这是更有意思的一面。

如果 WebMCP 真的普及，它大概不会威胁 SaaS 本身的存在。但它或许会削减部分产品内嵌副驾驶的必要性——尤其是那些功能较浅、本质上只是将用户本可通过更泛用型助手触发的操作重新打包的副驾驶。

很多软件公司都想要自己的专属助手，这逻辑乍看说得通——拥有这个应用，在上面做自己的 AI 层是合理的。

但用户不一定总想用你的助手作为主要界面。

他们或许更青睐自己的助手：那个已经熟悉他们的写作风格、习惯偏好、文档资料、打开的标签页，以及整个工作流的助手，一个可以随他们从一个应用跳到下一个应用的助手。

这正是 WebMCP 在产品策略上变得有意思的地方。如果产品在浏览器中向外部助手暴露干净、结构化的操作，那么一些”挂在角落里的 AI 小助理”功能，看起来就不再像坚实的护城河，而更像一层便利涂层。不是因为产品团队停止创造价值，而是因为跨应用助手在处理那些”浅层副驾驶”最初被设计来应对的任务时，变得愈发得心应手。

这个规律并非放之四海而皆准。产品依然掌握着深度的工作流知识、私有数据、权限体系和后端集成，这些都是实实在在的优势。但一个副驾驶越是依赖通用的摘要、起草、搜索或界面点击操作，就越会在一个能跨应用通用的用户专属助手面前感受到压力。

这更像是一次产品策略层面的迁移，而非一场产品大洗牌。留存下来的价值，是那些真正难以复制的东西：领域专属的判断力、特权访问、工作流设计，以及产品中外部助手难以廉价替代的部分。最先承压的，是那层薄薄的聊天界面。

所以，WebMCP 大概不意味着”一个协议取代所有 SaaS”。

它或许意味着：用户会减少对”每个产品里那个不同的助手”的依赖，转而更多地依赖一个能跨产品通用的助手。

这个转变比”SaaS 被取代”要窄得多，但也更可能发生——而且影响或许更为深远。

WebMCP 不等同于用 AI 测试人类界面

这个区别值得厘清，但不需要过度渲染。

有时你确实需要一个智能体像人一样使用界面，这在 QA、端到端测试和 computer use 工作流中依然重要。Playwright 和 Playwright MCP 适用于这种场景，OpenAI 的 computer use 工具也是如此。

WebMCP 面向的是另一项任务：在一个运行中的应用里暴露结构化操作，让用户和助手能够在同一个上下文中更可靠地协同工作。人类界面依然是主角，助手只是有了更清晰、更安全的方式在其中提供帮助。

所以浏览器自动化与 WebMCP 有交叉，但它们解决的是不同的问题。

WebMCP 与无障碍访问

这里还有一个比”AI 购物助手帮你找优惠券”更有实质意义的角度。

WebMCP 提案明确纳入了辅助技术，并将无障碍访问作为其核心目标之一：让辅助工具获得超越传统无障碍树所能暴露范围的 Web 应用功能访问能力。

这一点不容忽视。

如果浏览器端 AI 在理解活跃网站方面持续进步，同时网站也暴露出更清晰的可操作结构，那么对于那些面对密集界面、精细操作障碍或视觉复杂度挑战的用户来说，网络将变得更易使用。这不是泛泛而谈的未来愿景，而是对用户当下正在尝试完成的任务的切实帮助。

传统无障碍层可以帮助辅助工具理解页面上的内容，但对于如何在复杂应用中最优雅地完成一项任务，它并不总能给出清晰的路径。结构化操作有望弥合这一鸿沟。这并非要取代无障碍的基础规范，而是能让辅助帮助在那些技术上已符合无障碍标准、实际操作起来却仍令人头疼的软件中，变得更加实用。

开发者现在就该开始探索 WebMCP 吗？

我认为：是的。

实际部署仍然依赖于浏览器的支持以及某种客户端层（例如 MCP 服务器或浏览器扩展），没有一套所有助手都能统一消费的现成方案。这对基于它构建产品的人来说确实需要考量。权限、身份认证和信任机制，都需要在真实产品中落地解决，而不能靠协议名称来一笔带过。但这是谨慎原型化的理由，而不是彻底无视这个方向的借口。

如果你的产品有一个用户真正花时间停留的活跃界面——尤其是那些流程复杂或摩擦感强的 - WebMCP 就值得现在就开始原型验证。

AWS 或 Google Cloud 这样的产品很好地说明了这一点：强大的 API 并不能让产品内置的引导功能变得无关紧要。人们依然会在这些控制台上花费大量真实时间，他们依然需要即时的上下文帮助。一个受用户掌控、能在界面内主动操作的助手，和塞给用户一堆文档然后祈祷他们自己看明白，是截然不同的两件事。

WebMCP 值得密切关注，对于合适的产品，也值得尽早测试 - 因为它有可能让你的产品在用户已经身处其中的地方，与助手的配合变得更顺畅。

WebMCP 大概不是那种让人眼前一亮的技术。但如果浏览器里的 AI 辅助哪天真正好用了，背后很可能有它的一份功劳。