不过，

1️⃣ 网站不再只服务于人类

过去我们很少怀疑一件事：网页是给人用的。其实，页面是给人看的，按钮是给人点的，表单是给人填的。所有交互都围绕“人如何操作程序”来设计。

a) 开发者痛点：GUI 的局限性

• 难以让 Agent 理解页面结构：Agent 能“看见”DOM，却无法“理解”为什么某个按钮存在或其背后业务逻辑。
• 重复猜测导致效率低下：通过模拟点击和读取页面内容来推断接下来操作。需要反复尝试与失败，大大增加开发成本。
• 缺乏标准化接口：没有统一的描述方式，使得每个网站都需要单独编写适配器。

b) WebMCP 的突破：从隐式到显式接口

WebMCP 把这层猜测往前挪——让网站直接告诉 Agent：

• 能力？"
• "应该怎么触发？"
• "哪些交互是标准的？"

2️⃣ 交互边界移动：从 GUI 到 Agent Interface

a) 当前痛点：仅靠 GUI 无法满足机器需求

• Aggressive UI 驱动导致性能瓶颈：Crawling 和自动化脚本频繁操作 DOM 会显著降低浏览器性能。其实，
• Lack of deterministic behavior：AIGC 等模型需要可预期、可验证的返回结果。而 GUI 隐式接口往往不稳定。

b) WebMCP 带来的变化

A 明确动作 + 结构化参数 + 可预期返回 + 稳定边界 = 更适合 Agent 的交互模式。

⚙️ “显式接口” vs “隐式接口”

MCP 更像跨网站工具箱，而 WebMCP 则在网站内部提供更直观、可调用的描述层。说到正如官方比喻，“MCP 像公司的呼叫中心。WebMCP 更像店里的现场专家。”这代表着网站开始承认 GUI 并非唯一入口，并补上更适合机器理解与调用的一层抽象。 怎么说呢，

3️⃣ WebMCP 的主要价值：显性化 Agent 接口

虽然仍处于 Early Preview。但其关键性并不取决于成熟度，而在于把原本隐含的信息变为显式可用 API。

• 🤯 开发者困惑：传统自动化工具只能“让 Agent 去适应网页”，而 WebMCP 则让网页自己“适应 Agent”。
• 🚧 难题：需要重新定义网站功能模块。使其既能通过 GUI 服务使用者，又能通过 API 为机器提供服务。

➡️ 从“把程序变强”到“让程序自适应”——这是根本区别！

This shift means developers must now think not just about how humans interact with a site,but also how an autonomous agent will execute tasks reliably.

4️⃣ 网页从“容器”到“能力入口”的转型

原来网页只是一块显示内容、接收点击的容器。现在它也承担起向外暴露功能的职责——成为真正意义上的"能力入口".

• Migrating from pure UI to structured capabilities:
• - Human‑facing UI remains.
• - Machine‑friendly APIs surface alongside.
• - The system’s core logic becomes decoupled from presentation.

⚡️ 后果是？• GUI 不会消失，但其主要地位被削弱；• 程序真正能力层将更多地位于后台，可供调度与组合；• 软件从单纯“面向人的产品”转向完整“面向人的 & 面向机器”的程序。老实说，

5️⃣ 软件同时面对两类使用者：人类 & Agent

• 👨 对人类使用者仍需提供易懂界面与即时反馈；
• 💻 对 Agent 必须提供清晰能力描述、稳定动作边界和结构化调用方式。

软件设计将不再只关注 “人怎么操作”，还必须考虑 “Agent 怎么执行”。这直接推动了软件从实现细节转向以能力为中心的发展方法。

#6️⃣ 对 Web 开发者而言的新挑战与机遇 #7️⃣ 改变你对 Web 的认知 #8️⃣ 继续关注 WebMCP 与未来标准 🚀✨

ID 标题 作者信息 发布时间

synclist-1559d7afac54bb56ef77ae32b96aa92f

更多

作者信息

2024-08-01