#21 Syntax: WebMCP 来了

原文播客：Syntax – Tasty Web Development Treats #979

节目信息

Syntax | 整理时间：2026年02月23日

主持人: Wes Bos, Scott Tolinski

时长: 约15分钟

节目简介

本期节目深入探讨了 WebMCP（Web Model Context Protocol）这一全新的 Web 标准。WebMCP 允许网站直接向 AI 暴露结构化的工具接口，无需额外部署 MCP 服务器。主持人 Wes 和 Scott 通过一个购物清单应用的实际演示，展示了 WebMCP 如何让 AI 以结构化方式与网站交互，相比传统的 Playwright 爬虫方案速度提升数十倍。节目还讨论了声明式 API（HTML 表单）vs 命令式 API（JavaScript）的设计选择，以及这项技术对 Web 生态的深远影响。

核心话题讨论

话题 1: WebMCP 是什么？

Wes: “WebMCP 本质上是通过网站本身来呈现工具，并提供与网站交互的方式。这与 MCP 服务器不同，也与 MCP UI 及 MCP 应用程序不同。这是通过网站直接呈现功能的新方式，无需额外部署服务器。”

💡 要点: WebMCP 让网站原生支持 AI 交互，无需额外基础设施

Scott: “我对这个很感兴趣，因为我听说了 Web MCP，我首先关注的是 Chrome DevTools MCP 或 Agent 浏览器，以及这类工具。”

Wes: “完全不是这样。”

核心区别:

MCP 服务器: 需要单独部署和维护的后端服务
MCP UI/应用: 在聊天界面中嵌入组件
WebMCP: 网站直接暴露工具，AI 访问网站即可使用

话题 2: 实际演示 – 购物清单应用

Wes: “我开发了一款名为购物清单的应用。这是一个非常简单的应用，你可以在其中列出想要前往的每家超市，然后在每家超市下方添加、删除或勾选你想要购买的食品项目。”

演示场景:

添加单个商品

用户: “请将香蕉添加到好市多购物清单”
AI: 调用 addItem 工具，参数 {item: “香蕉”, store: “好市多”}
结果: 香蕉成功添加

跨商店移动

用户: “能把香蕉从好市多移至全食物吗”
AI: 调用 moveItem 工具
结果: 香蕉从好市多转移到全食超市

智能批量添加

用户: “请将鸡肉面条汤的所有食材添加到全食超市”
AI: 自动识别食材（鸡高汤、鸡胸肉、蛋面条、胡萝卜、芹菜、洋葱）
结果: 6 个食材全部添加

模糊匹配

用户: “标记所有含有鸡肉的项目”（拼写错误：chicke）
AI: 容错处理，正确识别并标记鸡肉相关商品

💡 要点: AI 能理解自然语言，自动推理，容错拼写错误

Wes: “AI 的一个优势在于，我可以拼写错误，它根本不在乎，完全不介意。它能理解你的意思，这实际上非常棒。”

话题 3: 两种实现方式

Wes: “我认为这简直是天才之举，因为如果您的网站已有表单，或者您只是希望以声明式方式简单地公开某项功能的用途，只需添加几个不同的属性即可。”

💡 要点: 声明式 API 让现有表单零成本升级为 AI 工具

技术优势:

自动推断: 从 HTML 表单自动推断数据结构
零学习成本: 开发者无需学习新 API
渐进增强: 现有表单可直接使用

话题 4: WebMCP 的核心优势

优势 1: 混合用户界面

Wes: “我不认为每件事都希望仅仅变成一个用户界面组件，尤其是像预订航班这类事情。那些售卖机票的人并不只是希望被简化为一种工具，他们希望为您提供良好的体验，同时也希望向您推荐更多增值服务。”

核心观点:

用户可以选择使用原始 UI 或自然语言交互
商家保留品牌体验和增值服务推荐能力
AI 作为辅助工具，而非替代品

Scott: “如果拥有历史购物清单，你就能更进一步实现这一操作。你可以这样说，把上周的所有蔬菜添加到本周，这种操作在实际的用户界面中实现起来会更困难。”

💡 要点: 自然语言交互解锁了传统 UI 难以实现的复杂操作

优势 2: 速度提升

Wes: “相比我之前使用过的多个与浏览器交互的 AI 工具，它的速度要快得多。之前使用那个叫 Chat GPT 浏览器的工具时，体验极其痛苦，它非常缓慢。”

性能对比:

传统方案（Playwright）: 需要解析 HTML、分析可访问性树、截图识别按钮
WebMCP: 直接调用结构化工具，5 秒内完成操作

实测数据:

创建新药店 + 添加润唇膏: 5 秒
传统爬虫方案: 30-60 秒

💡 要点: 结构化交互比视觉识别快 6-12 倍

优势 3: Token 效率

Wes: “如果按令牌计费，这类操作只需发送工具调用及可能的选项，无需传输整个 DOM 树或完整截图，从而显著提升效率。”

成本对比:

传统方案: 发送完整 DOM（数万 tokens）或截图（数千 tokens）
WebMCP: 仅发送工具调用（数十 tokens）

成本降低: 约 100-1000 倍

话题 5: 框架集成的天然优势

Wes: “这种情况似乎非常适合框架来实现。你已经将所有这些数据作为应用的一部分，已经拥有你的数据结构，已经具备验证逻辑，也已经有了用于构建表单原型的用户界面。”

框架可以做什么:

自动生成工具定义: 从组件 props 自动生成 schema
类型安全: TypeScript 类型自动映射到工具参数
验证复用: 表单验证逻辑直接用于工具参数验证
零配置: 开发者无需手动编写工具定义

Wes: “只需再往前一步进行发布，通过你的 HTML 网站实现这些功能非常简单。而且这不需要其他人再启动第二个 MCP 服务器，你无需托管任何额外内容，仅需维护你的网站即可。”

💡 要点: WebMCP 是框架的天然延伸，而非额外负担

话题 6: 关键问题与挑战

问题 1: 跨应用操作

Wes: “我有个问题，跨应用操作是否可行？因为肯特在我们讨论 MCP UI 时提到，人们并不只是想访问一个网站完成所有操作。就像你想要说，比如购物清单，就去查看一下我的日历，当晚餐时间是什么时候，如果我这周有任何晚餐安排，就添加到我的群组中。”

Wes 的推测:

浏览器侧边栏只是测试工具，不是最终形态
未来会有类似 MCP 的聊天应用
可以同时访问多个网站，在它们之间传输数据
可能采用无头浏览器模式

💡 要点: WebMCP 的真正潜力在于跨应用编排

问题 2: 隐私与安全

Wes: “我不认为每家网站都希望公开这类信息。我们看到了 API 早期的发展情况，当时每一个网站都提供了 API…”

潜在风险:

工具暴露可能泄露业务逻辑
需要身份验证和权限控制
防止滥用和爬虫

话题 7: Wes 的终极观点

Wes: “我认为这是网络适应人工智能的一个绝佳方式。因为不可能让天下所有人全都发布一个 MCP 服务器，让它与 ChatGPT 配合运行并实现功能。”

类比 iPhone 应用生态:

早期: 没人有 iPhone 应用
现在: 每个人都有 iPhone 应用
WebMCP: 让网站”AI-ready”的最低成本路径

Wes: “这类似于响应式设计，只需稍作调整即可。现在我的网站已适配移动设备。”

💡 要点: WebMCP 是 Web 的”响应式设计时刻”

📚 技术术语

WebMCP (Web Model Context Protocol): 让网站直接向 AI 暴露工具的 Web 标准
MCP 服务器: 独立部署的后端服务，通过 MCP 协议与 AI 通信
MCP UI/应用: 在聊天界面中嵌入的交互组件
声明式 API: 通过 HTML 属性定义工具（如表单）
命令式 API: 通过 JavaScript 代码注册工具
Token 效率: AI 模型按输入输出的 token 数量计费
无头浏览器: 没有图形界面的浏览器，用于自动化

💬 金句摘录

“WebMCP 本质上是通过网站本身来呈现工具，并提供与网站交互的方式。这与 MCP 服务器不同，这是通过网站直接呈现功能的新方式，无需额外部署服务器。” —— Wes Bos
“AI 的一个优势在于，我可以拼写错误，它根本不在乎，完全不介意。它能理解你的意思，这实际上非常棒。” —— Wes Bos
“如果拥有历史购物清单，你可以这样说，把上周的所有蔬菜添加到本周，这种操作在实际的用户界面中实现起来会更困难。” —— Scott Tolinski
“我认为这简直是天才之举，因为如果您的网站已有表单，只需添加几个不同的属性即可。” —— Wes Bos
“相比我之前使用过的多个与浏览器交互的 AI 工具，它的速度要快得多。” —— Wes Bos
“这类似于响应式设计，只需稍作调整即可。现在我的网站已适配移动设备。” —— Wes Bos

🤔 思考与启发

本期节目展现了 Web 技术对 AI 时代的深度思考：

标准化的力量: WebMCP 通过标准化让 AI 交互成为 Web 的原生能力，而非第三方补丁
渐进增强哲学: 声明式 API 让现有网站零成本升级，体现了 Web 的渐进增强传统
用户体验优先: 混合 UI 方案保留了传统界面的优势，AI 作为增强而非替代
开发者友好: 框架可以自动生成工具定义，降低了采用门槛
生态系统效应: 类比 iPhone 应用生态，WebMCP 可能引发 Web 的”AI-ready”浪潮

延伸思考: 在你的项目中，哪些功能适合通过 WebMCP 暴露给 AI？如何平衡开放性和安全性？