📝

Google I/O Connect China 主旨演讲演示了 WebMCP：自然语言操作 3D 房间指哪打哪。对比阿里 PageAgent——两条让 AI 操作网页的路线：WebMCP 把能力变成 Tools 主动提供，PageAgent 读懂 DOM 像人一样操作。核心业务动作走 WebMCP，长尾 UI 走 PageAgent，结合才是完整的 Agent-native Web。

WebMCP vs PageAgent：AI操作网页的两条路线

来源：小红书 RayJason，写于 Google I/O Connect China 主旨演讲之后。

背景

今天在 Google I/O Connect China 主旨演讲看到了 WebMCP 的演示：通过 WebMCP 使用自然语言操作一个 3D 房间，指哪打哪。作者正好之前关注过阿里的 PageAgent，两者都在解决「让 AI/Agent 操作网页」，但思路完全不同。

两条路线（一句话版）

WebMCP：网页主动把能力变成 Tools，Agent 直接调用。开发者主动开发对外提供。
PageAgent：Agent 读懂 DOM，再像人一样点击、输入、滚动。

一个更像 Agent 时代的 Web API，一个更像嵌进网页里的 GUI Agent。

核心区别表（图 3）

维度	WebMCP	PageAgent
本质	Web 标准 / Browser API	JS Agent 框架
谁定义能力	开发者显式定义 Tool	Agent 自动理解 DOM
Agent 怎么操作	调用结构化 Tool	click / scroll 等 DOM 操作
是否需要 LLM 理解页面	很少	需要
Token 消耗	很低	相对高
操作可靠性	高，接近 API 调用	取决于 DOM / 页面设计 / 模型
老系统改造成本	需要注册 Tools	很低，直接嵌入 JS
UI 改版影响	较小	可能影响 Agent

工作原理对比（图 2）

PageAgent（DOM 操作）：

1. 读取 DOM
2. 找到目标元素
3. 点击 / 输入 / 滚动
4. 继续下一步操作

→ LLM 理解页面 → 操作 UI

WebMCP（结构化调用）：

1. LLM 选择合适的 Tool
2. 例：add_suspect_phone({ suspectId: "xx", phone: "138xxxx" })
3. 直接执行业务逻辑

→ LLM 调用 Tool → 执行业务

一个先理解页面，一个直接调用能力。

选型建议（图 3 右侧）

1. 核心业务动作 → 选 WebMCP：更稳定、更可控
2. 长尾 UI 操作 → 选 PageAgent：接入更快、改造更少
3. 两者结合，效果更佳

总结：WebMCP 擅长「做对的事」，PageAgent 擅长「把事做成」

我的理解（作者）

• 核心业务动作 → WebMCP
• 旧系统 / 长尾 UI → PageAgent
• 两者结合，可能才是更完整的 Agent-native Web

点评

这两条路线本质上是**「接口优先」vs「模拟人类」**之争：

• WebMCP 把网页变成可编程的 API 集合，稳定高效但需要开发者配合（有改造门槛）
• PageAgent 把 Agent 变成”会看页面的用户”，普适性强但费 Token、可靠性依赖页面质量

类似的分歧在 GUI Agent 领域反复出现（比如用 Accessibility Tree 还是视觉识别、用 API 还是 RPA），最终大概率是混合方案——核心走接口，边角走模拟。