WebMCP：彻底改变 AI 与网站交互方式的新规范 |

Translate: 🇫🇷 French 🇸🇦 Arabic 🇨🇳 Chinese 🇪🇸 Spanish

今天我们来探讨一个全新的规范：WebMCP。

我们将解释它是什么，展示一个演示，并分享一些独到的见解。

本质上，WebMCP 是一种通过网站本身来暴露工具和交互方式的机制。

这与 MCP 服务器、MCP UI 或 MCP 应用都不同。

虽然它们相关，工作方式相似，但 WebMCP 提供了一种全新的方式。

它让你的网站能够直接提供功能，而无需部署额外的服务器。

当前 AI 与网站交互的挑战

让我们以一个我构建的“购物清单”应用为例。

这是一个简单的看板应用，你可以为常去的杂货店创建列表。

在每个商店列表下，你可以添加、移除和勾选商品。

构建这样的应用，你通常需要实现以下功能：

添加商店
添加商品
重新排序商品
重命名
删除商品
勾选商品

现在，如果你想让 AI 能够使用你应用的功能，你有几个选择。

现有方案及其局限性

内置 AI：你可以直接在应用中集成 AI 功能，但需要自己承担其运营成本。
MCP 服务器：你可以创建一个 MCP 服务器来暴露所有工具，然后让 AI 聊天通过它进行交互。
MCP UI / MCP 应用：你可以返回和生成嵌入式的组件或风格化的结构，直接在聊天界面中展示。
浏览器自动化：你可以使用像 Playwright 这样的工具，它会转储 HTML、分析无障碍树或截取 UI 屏幕。然后，它会像人类一样点击按钮来使用网站。根据我的经验，这种方法虽然可行，但极其缓慢，因为它需要解析所有内容并找出要按下的按钮。

WebMCP：一种更直接的解决方案

WebMCP 的解决方案是让你的网站明确地发布它能做什么。

在我的购物清单应用中，我有几个不同的工具：

addItem
getItems
deleteItem
deleteStore
createStore
getItemsByStore
moveItem

这与你通常为 MCP 服务器发布的工具没什么不同。

你需要发布这些工具，并定义它们的输入和输出模式（schemas）。

这意味着你告诉 AI：

“嘿，AI，这里有一个叫做 addItem 的工具。这是它的功能描述。这是它的输入和输出模式。如果你想调用我的工具，你必须提供商品名称和要添加到的商店。然后，我会返回给你相应的信息。”

这是一种与 AI 进行结构化对话的绝佳方式。

graph TD
    subgraph "传统方法 (Traditional Methods)"
        A[AI 代理] --> B{抓取 HTML/无障碍树};
        B --> C[AI 模型解析 UI];
        C --> D[模拟点击/输入];
        D --> E((网站 UI));
    end

    subgraph "WebMCP 方法 (WebMCP Method)"
        X[AI 代理] --> Y{读取网站发布的工具};
        Y --> Z[直接调用工具函数];
        Z --> F((网站功能));
    end

    style E fill:#f9f,stroke:#333,stroke-width:2px
    style F fill:#ccf,stroke:#333,stroke-width:2px

[!NOTE] 这种方法绕过了脆弱且缓慢的 UI 解析，直接与应用程序的逻辑进行对话，从而实现了速度和可靠性的飞跃。

实战演示：AI 管理购物清单

Chrome 发布了一个浏览器扩展作为交互示例。

我加载页面，它立即找到了所有可用的工具。

我将其连接到 Gemini 2.5 Flash，然后发出指令：

“请将香蕉添加到 Costco 购物清单。完成后，显示我购物清单上的所有东西。哦，然后把香蕉从 Costco 移到 Whole Foods。”

AI 解析了我的需求，查看了可用的工具。

几秒钟后，它成功地将香蕉添加到了 Costco，然后又将其移动到了 Whole Foods。

我还可以尝试更复杂的指令：

“请将制作鸡汤所需的所有食材添加到 Whole Foods。”

AI 再次解析了指令，并迅速添加了鸡汤、鸡胸肉、鸡蛋面、胡萝卜、芹菜和洋葱。

我甚至可以进行后续操作：

“把所有带‘鸡’的东西都划掉，我已经有了。”

AI 理解了我的意思（即使我有拼写错误），并划掉了鸡汤和鸡胸肉。

AI 的一个巨大好处就是它能理解拼写错误，这真是太棒了。

如何实现 WebMCP：两种主要方式

那么，浏览器是如何知道这些工具的呢？

你有两种方式来声明它们。

1. 使用 JavaScript 命令式声明

你可以使用 JavaScript 命令式地声明工具。

只需调用 window.navigator.mmodelcontext.registerTool。

你可以提供工具的描述、输入和输出数据模式。

// 示例：使用 JavaScript 注册工具
window.navigator.mmodelcontext.registerTool({
  toolName: 'addItem',
  description: '向指定的商店购物清单中添加一个商品。',
  inputSchema: {
    type: 'object',
    properties: {
      item: { type: 'string', description: '要添加的商品名称。' },
      store: { type: 'string', description: '商店的名称。' }
    },
    required: ['item', 'store']
  },
  // ... 定义 outputSchema
});

2. 使用 HTML 表单声明式声明

另一种方式是使用 HTML 表单元素，我认为这简直是天才之举。

如果你的网站已经有表单，或者你只是想以声明方式发布功能，只需添加几个属性即可。

tool-name
tool-description
tool-param-title
tool-param-description

浏览器会解析这些 HTML 元素并找出可用的操作。

<!-- 示例：使用 HTML 表单声明工具 -->
<form
  tool-name="createStore"
  tool-description="创建一个新的商店列表。">
  <label tool-param-title="商店名称">
    <input type="text" name="storeName" tool-param-description="新商店的唯一名称。">
  </label>
  <button type="submit">创建商店</button>
</form>

[!TIP] 在这种情况下，你甚至不需要发布模式（schema），因为它可以从你的表单中推断出来。这真是太棒了！

WebMCP 的核心优势

让我们来谈谈 WebMCP 带来的几个好处。

混合式 UI 体验

我非常喜欢这种混合式的 UI 方法。并非所有东西都适合成为一个聊天界面中的 UI 小部件。比如预订航班，商家希望提供完整的体验，而不仅仅是成为一个功能单一的工具。 WebMCP 允许用户继续使用他们熟悉的网站 UI，同时也能通过自然语言进行交互。

自然语言的强大功能

如果我要添加鸡汤的食材，我不需要手动添加五六个不同的项目。我只需输入：“嘿，帮我添加 X、Y 和 Z。” 这比拖放操作快得多。你甚至可以做更复杂的事情，比如：“把上周购物清单里所有的蔬菜都加到这周的清单里。” 用传统的 UI 实现这一点会非常困难，因为它涉及到复杂的标签系统和逻辑。

极致的速度

WebMCP 比那些 AI 浏览器交互工具快得多。那些工具在你让它们运行然后走开时还不错，但如果你坐等它完成，会感觉非常缓慢。看看 WebMCP 有多快：

“添加一个新商店：药店。添加润唇膏。” 发送后，一、二、三、四、五……五秒钟，它就添加了一个新商店和商品。这速度非常快。

更高的令牌效率

如果你是按令牌付费的，WebMCP 效率更高。它只向 AI 发送工具调用和可能的选项。而不是发送整个 DOM 树或屏幕截图，让 AI 去解析和点击。

易于框架集成

这似乎是为框架量身定做的。你的应用中已经有了所有这些数据：模式、验证逻辑、UI 层。只需多走一步，将这些功能发布到你的 HTML 网站中，就非常容易了。这不需要你再去启动一个单独的 MCP 服务器。

悬而未决的问题与未来展望

当然，这只是一个早期预览版，还有一些问题需要解决。

跨应用交互是否可能？ 用户希望应用能互相协作。例如：“查看我的日历，如果这周有晚宴计划，就把相关食材添加到我的购物清单里。” 我推测这是可能的。当前的 Chrome 侧边栏只是一个测试工具。未来，聊天应用可能会访问多个网站，发现它们的工具，并在它们之间移动数据。
无头（Headless）模式 我猜想它最终会支持无头模式运行。

最终思考：WebMCP 在 AI 时代的地位

我认为这是 Web 适应 AI 的一个绝佳方式。

你不可能让地球上每个人都去发布一个 MCP 服务器。

WebMCP 是一个很好的过渡桥梁。

开发者只需在 HTML 表单上添加几个属性，或在 JavaScript 中发布一些工具。

你的网站就为 AI 做好了准备。

这类似于响应式设计：“我只需要做一点小改动，我的网站就能在移动设备上完美运行了。”

API 的历史教训

然而，并非每个网站都愿意开放其功能。

我们从 API 的历史中看到了这一点。

早期，几乎每个网站都有免费的 API，催生了无数的客户端和“混搭”应用。

但慢慢地，这些公司开始关闭 API 访问权限。

Reddit API 几乎完全消失了。
Twitter API 变得极其昂贵。
Instagram API 几乎不可能进行交互。

大公司不希望你把它们当作一个简单的工具来使用。

他们希望你留在他们的平台上，使用他们的方式，这样他们才能向你销售东西并赚取最多的钱。

所以，我不确定 WebMCP 是否会成为所有应用的终极解决方案。

但我确信，对于那些希望 AI 与其应用交互的人来说，这是一个绝佳的前进方向。