WebMCP 真要跑起来，很多 AI Agent 的“看网页点按钮”都会变成过渡方案

导语

我一直觉得，现在很多 AI agent 看起来热闹，真正难受的地方其实很基础：它不是在“调用能力”，而是在“模仿人类操作网页”。

这件事从一开始就有点别扭。让模型盯着截图找按钮、猜输入框格式、猜页面状态、等刷新、再从一堆页面元素里捞结果，本质上是在拿高成本系统去适配一个根本不是为它设计的交互层。能跑，不代表这条路对。

所以我看到 WebMCP 这个方向时，第一反应不是“又来一个新概念”，而是：这东西如果真的推起来，很多今天被包装成 agent 能力的网页操作，可能很快就会显得像过渡方案。

核心事实

小互这条帖子讲得很直接：现在 AI agent 操作网页，最大的问题不是不会点，而是点这件事本身太低效。

以前 agent 要在一个机票网站搜航班，路径是典型的 UI 自动化逻辑：找到搜索框，猜日期格式，点提交，等页面刷新，再去解析结果。这条链路的问题不是“偶尔出错”，而是它天然就慢、脆，而且每一步都在消耗额外 token 和工程补丁。

WebMCP 提出来的思路正好反过来。不是让 agent 去理解网页长什么样，而是让网站直接把自己的能力暴露成工具接口。比如不再让 agent 找航班搜索按钮，而是直接给它一个 searchFlights(出发地, 目的地, 日期)，调用一次就拿到结构化结果。

按帖子里的说法，这条线是 Google 和微软在推的 W3C 标准草案，目前还在实验阶段。接入方式大致有两类：一类比较轻，给现有 HTML 表单加属性；另一类更重一点，用 JavaScript 注册更复杂的工具接口。细节当然还要继续核，但这个方向已经足够明确了：网页不再只是页面，也可能变成 agent 的可调用能力层。

影响解读

我觉得这件事真正值得盯的，不是“浏览器又多了一个新标准”，而是它可能在重写 agent 的基础设施叙事。

今天很多 agent 产品，本质上还是在用模型去补传统 RPA 和网页自动化的坑。说得好听一点，是让 AI 学会用网页；说得难听一点，是在用最贵的脑子，干最别扭的体力活。页面一改、按钮一挪、表单一变，整条链路就开始抖。

如果 WebMCP 这种思路成立，agent 交互的重点就会从“理解页面”转向“调用能力”。这两个听起来接近，实际差得很远。前者是在跟 UI 斗智斗勇，后者是在进入接口时代。

这背后最重要的变化，不是 demo 会更顺，而是成本结构会变。延迟会降，失败率会降，维护复杂度也可能降。对浏览器厂商、SaaS 平台、交易平台、信息网站，甚至所有未来想承接 agent 流量的产品来说，这都不是装饰性升级，而是入口层可能在换轨。

我甚至觉得，这件事有点像当年从 PC Web 走向移动互联网。不是说类比会一模一样，而是底层逻辑很像：一旦流量入口变了，没跟上那层交互协议的人，后面会越来越被动。以前网站只要对人友好，未来可能还得对 agent 友好。

说白了，网页这套东西本来就是给人点的。可如果 AI 真的开始大量“使用互联网”，那网站继续只提供给人类看的界面，本身就会变成一种效率损失。

风险与不确定性

当然，这件事现在还远没到可以喊“网页交互范式已经改写”的程度。

第一，当前公开信息还是比较早期，很多关键细节——包括标准成熟度、浏览器支持范围、网站接入门槛、权限设计——都还需要更正式的技术材料来验证。只看一条帖子，最多只能先确认方向，不适合下太满的结论。

第二，就算技术路径成立，生态 adoption 也不会自动发生。网站愿不愿意把哪些能力开放给 agent，开放到什么程度，怎么做认证、授权、审计和风控，这些都是硬问题。接口不是注册出来就算完事，特别是涉及交易、支付、隐私和不可逆操作的时候。

第三，也别高估“结构化工具接口”对所有 agent 场景的即时作用。很多问题卡住，不只是网页太难点，还包括账号体系、业务权限、流程确认和平台策略。WebMCP 可能会让 agent 更像真正的软件调用者，但它解决不了所有平台博弈问题。

所以我现在更倾向于把它看成一个很强的信号：它未必马上改写一切，但它很可能代表着一个正确方向。真正该关注的，不是这个词会不会火，而是谁会最早按这个方向把网站能力重新组织一遍。

参考链接

• 来源：X / 小互
• 链接：https://x.com/xiaohu/status/2033360499509969165?s=46