阅读视图

发现新文章,点击刷新页面。

WebMCP 实战指南:让你的网站瞬间变成 AI 的“大脑外挂”

一、 AI 终于不用“瞎猜”你的网页了

我们可以把 WebMCP 想象成一种**“翻译官协议”**:

  • 以前的 AI(视觉模拟派) :就像一个老外在看一份全中文的报纸,他得先拍照,再识别文字,最后猜哪里是按钮。一旦你把按钮从左边挪到右边,他就找不到了。
  • WebMCP(接口直连派) :你的网站现在给 AI 提供了一个**“操作说明书”**。AI 进门后不用看页面长什么样,直接问:“那个‘查询余额’的功能在哪?” 你的网站直接通过 WebMCP 告诉它:“在这里,发个 JSON 给我,我就告诉你结果。”

一句话总结:WebMCP 让网页从“给人看的界面”变成了“给 AI 调用的函数”。


二、 核心能力:WebMCP 的“两把斧”

在实际开发中,WebMCP 提供了两种接入方式:

  1. 宣告式(适合简单动作) :在 HTML 里加个属性,就像给按钮贴个“AI 可读”的标签。
  2. 命令式(适合高级逻辑) :用 JavaScript 编写具体的执行函数,适合处理复杂计算。

三、 实战:WebMCP 的具体使用方法

目前,你可以在 Chrome Canary (v145+) 中通过以下步骤实现一个“AI 自动分析监控日志”的功能。

1. 开启实验室开关

在浏览器地址栏输入:chrome://flags/#enable-webmcp,将其设置为 Enabled 并重启。

2. 定义“说明书” (mcp-config.json)

在你的网站根目录放置一个配置文件,告诉 AI 你有哪些能力。

JSON

{
  "tools": [
    {
      "name": "get_frontend_error_logs",
      "description": "获取当前页面的前端错误日志详情",
      "parameters": {
        "type": "object",
        "properties": {
          "limit": { "type": "number", "description": "返回的日志数量" }
        }
      }
    }
  ]
}

3. JavaScript 具体实现逻辑

在你的网页脚本中,注册这个工具的具体执行逻辑。

JavaScript

// 检查浏览器是否支持 WebMCP
if ('modelContext' in navigator) {
  // 注册工具
  navigator.modelContext.registerTool('get_frontend_error_logs', async (args) => {
    // 1. 从你的监控系统中提取数据
    const logs = window.__MY_MONITOR_LOGS__.slice(0, args.limit || 5);
    
    // 2. 返回给 AI
    return {
      content: [
        { 
          type: "text", 
          text: JSON.stringify(logs, null, 2) 
        }
      ]
    };
  });
  
  console.log("WebMCP 工具已就绪,AI 现在可以直接读取你的日志了!");
}

四、 极致的 Token 优化:从“读图”到“读字典”

web系统经常有成千上万行的表格数据,让 AI 截图识别简直是灾难。

1. 结构化数据的降维打击

  • 视觉识别:1 张 1080P 的截图可能消耗 1000+ Tokens,且 AI 经常看错行。
  • WebMCP:你返回一个 JSON.stringify(summary) 仅需几十个 Tokens。
  • 工程技巧:在 registerTool 的返回结果中,你可以预先对数据进行特征提取(比如只返回异常波动点),将原本需要 AI 自己总结的过程,在本地通过高性能 JS 预处理完成,进一步压榨 Token 成本。

五、 交互新范式:从“被动响应”到“双向协同”

在你的实战代码中,展示了 AI 如何“主动”调数据,但 WebMCP 的真正威力在于它构建了一个双向总线

1. 订阅模式:让 AI 实时盯盘

在金融监控或 K 线分析场景,AI 不应该总在问“现在价格是多少”,而应该是当价格波动超过阈值时,网站主动推送到 AI 上下文。

  • 扩展用法:利用 WebMCP 的资源订阅(Resources Subscription)机制。
  • 代码逻辑:通过 navigator.modelContext.updateResource(),当监控系统发现异常流量或金融数据触发对冲点时,自动将上下文注入 AI 的实时缓存,实现“无感预警”。

六、 安全深度防御:权限隔离

你一定关心:万一 AI 乱发指令怎么办?WebMCP 引入了显式授权与沙箱隔离

1. 权限最小化原则

WebMCP 不会默认给 AI 权限去读你的整个 LocalStorage 或 Cookie。

  • 层级控制:每一个 registerTool 注册的功能,都会在 Chrome 侧边栏显示详细的权限说明。
  • 人类确认 (HITL) :对于涉及敏感操作(如:执行转账、删除线上日志)的 Tool,WebMCP 支持声明 userApproval: "required"。当 AI 尝试调用时,浏览器会跳出原生确认框,这种系统级的阻断是任何第三方插件无法模拟的安全保障。

七、 架构解耦:一套标准,适配所有 AI 终端

你目前在研究 AI Prompt ManagerTrae/Cursor。WebMCP 的出现解决了前端工程中的“适配地狱”。

1. “一次开发,到处运行”的 AI 能力

  • 旧模式:你得写一个 Chrome 插件给 Gemini 用,再写一个 MCP Server 给 Claude Desktop 用,再给 Cursor 写特定的插件。
  • WebMCP 模式:你只需要在网页里 registerTool。由于 Chrome 是宿主,只要你在 Chrome 里打开这个网页,无论是侧边栏的 Gemini,还是通过 DevTools 接入的 AI Agent,都能识别并使用这套能力。这极大降低了你维护 AI 基础设施 的成本。

八、为什么非用它不可?

  1. 性能屠宰场:不再需要给 AI 发送几万个 DOM 节点的 HTML 文本,只传核心 JSON,Token 消耗节省 90%。
  2. 安全围栏:数据处理在本地浏览器完成。大模型只发指令,不直接接触你的敏感数据库明细。
  3. 开发效率:你不再需要为不同的 AI 插件写不同的适配层,只要符合 WebMCP 标准,所有支持该协议的 AI 助手都能秒懂你的业务。

WebMCP 时代:在浏览器中释放 AI 的工作能力

随着 AI Agent 的广泛应用,传统的 Web 自动化与 Web 交互模式正在迎来根本性变化。WebMCP 是一个未来派的技术提案,它不仅改变了 AI 访问 Web 的方式,还为 AI 与前端应用之间建立起了 协议级的交互通道。本文从WebMCP架构分层解析这项技术及其工程意义。

面对 GEO 与 Agent 应用逐步弱化浏览器入口价值的趋势,浏览器厂商必须主动跟进,通过技术升级与生态重构来守住自身核心阵地。


一、WebMCP 是什么?

WebMCP(Web Model Context Protocol)是一种 客户端 JavaScript 接口规范,允许 Web 应用以结构化、可调用的形式向 AI Agent 暴露其功能(tools)。WebMCP 的核心目标是:

让 Web 应用拥有一组可被 AI Agents 调用的工具函数,避免 AI 通过截图 + DOM 模拟点击这样的低效方式去理解和操作页面。

WebMCP 允许开发者将 Web 应用的功能“以工具形式”公开,供 Agents、浏览器辅助技术等访问。页面将现有的 JavaScript 逻辑包装成与自然语言输入对应的“tools”,AI Agents 可以直接调用它们,而不是模拟用户行为。

换句话说:

WebMCP 是前端版的 MCP 工具协议:它让 Web 应用自己变成一个能被 AI 调用的、语义明确的接口服务器。


二、核心理念:让 Web App 成为 AI 可调用的工具集

WebMCP 的核心机制由三部分构成:

1. 工具注册与调用

页面通过 navigator.modelContext.registerTool() 或类似 API 把自己内部的 JS 功能(如搜索、筛选、提交、获取数据)注册为可调用的工具(tools)。这些 tools 带有:

  • 名称
  • 自然语言描述
  • 输入/输出结构定义(JSON schema)

Agents 识别到这些 tools 后,就可以直接调用,而不需要重新解析 DOM。


2. 语义描述与结构化调用

WebMCP 的工具接口是结构化的,而不是 UI 操作序列:

filterTemplates(description: string) → UI 更新
getDresses(size, color) → 返回商品列表
orderPrints(copies, page_size, page_finish) → 下单

这比视觉模拟更可靠、更高效。


3. 人机协作而非全自动

WebMCP 不是为了让 AI 完全替代用户,而是为了让用户和 AI 协同完成任务。它强调:

  • 共享上下文
  • AI 与用户同时可见的执行状态
  • 用户有权审查/接受 AI 的动作

不像纯后台机器人,WebMCP 是“在 UI 里协作”的模型。


三、基于 Browser + WebMCP 的 Agent 驱动架构

image.png

这张图展示了 WebMCP 在浏览器场景下的设计思路:


1)AI Platform(大模型)

  • 负责理解用户意图
  • 识别需要调用的 WebMCP 工具
  • 并发送工具调用指令

2)Browser-integrated Agent(浏览器 Agent)

这个组件负责:

  • 将 LLM 指令转为工具调用
  • 与 WebMCP JS 进行交互
  • 在当前网页上下文执行注册的 JavaScript 工具代码

它类似一个“中间控制层”,连接了一端的 AI 推理和另一端的前端工具。


3)WebMCP JS

运行在页面内部的代理代码:

  • 负责注册和执行 tools
  • 与 Agent 进行通信
  • 在正常 Web 环境中执行定义好的工具函数

这意味着:

页面本身是一个 MCP Server ,但运行在客户端。


4)Third-Party HTTP 服务

仍然是页面自身依赖的服务端业务逻辑:

  • 通常的业务 API
  • 页面使用这些 API 完成任务
  • 也可以在工具内部直接调用

核心意义总结

这张图的核心思想是:

在浏览器里增强 Web 应用,让 AI Agent 能调用前端定义好的交互能力,而不是模拟用户行为。

它是一个 “前端即服务的 MCP Server” 模式。


四、为什么这是一种范式级的变革?

1)结构良好的能力暴露

传统 Agents 访问网站靠:截图 +Vision 识别 + DOM 模拟

这是低效、易错且不稳定的。

WebMCP 直接告诉 AI:

你的工具是 filterTemplates(criteria)
不要再猜测页面结构

这意味着 AI 不再“模拟人”,而是“直接调用真实功能”。

2)前端逻辑复用

WebMCP 允许:

  • 复用现有前端逻辑
  • 业务功能无需写额外后端 API
  • 使用现有组件构建工具

3)提升安全和用户控制

WebMCP 需要用户授权,且工具执行会明显提示用户,这符合“人机协作”设计,还能避免:

  • 未授权数据泄露
  • 无感知的全自动操作

这比无 UI 后端自动化更可控。

五、典型使用场景

使用WebMCP订奶茶

你说:
帮我找一家评分高、离我近一点的奶茶店,最好 20 元以内。

当前页面注册了一个 WebMCP 工具:

/**
 * 根据自然语言描述搜索奶茶店
 *
 * description - 用户对店铺的需求描述(自然语言)
 * max_price - 人均价格上限(单位:人民币)
 */
searchMilkTeaShops(description, max_price)

浏览器Agent判断这个工具最符合用户意图,于是调用:

searchMilkTeaShops(
  "评分高,距离近,出餐快",
  20
)

页面内部会把自然语言转为已有筛选条件,例如:

  • 评分 ≥ 4.5
  • 距离 ≤ 2km
  • 人均 ≤ 20 元

然后刷新页面,只展示符合条件的店铺。

浏览器Agent回复:
我帮你筛选了几家评分高、距离近、价格合适的奶茶店,要不要限定品牌?

你说:
优先考虑喜茶或者蜜雪冰城,少糖。

页面还注册了一个工具:

/**
 * 在当前结果中按品牌和口味偏好筛选
 *
 * brands - 品牌数组,例如 ["喜茶", "蜜雪冰城"]
 * sweetness - 甜度偏好,例如 ["正常糖", "少糖", "无糖"]
 */
refineShops(brands, sweetness)

浏览器Agent调用:

refineShops(
  ["喜茶", "蜜雪冰城"],
  ["少糖"]
)

页面更新,只展示符合条件的店铺和推荐饮品。

你点进一家店铺页面。页面加载后注册了新的工具:

/**
 * 根据口味偏好推荐饮品
 *
 * description - 对饮品口味的自然语言描述
 * max_price - 单杯价格上限
 */
recommendDrinks(description, max_price)

你说:
给我推荐一杯清爽一点的水果茶,不要太甜,20 元以内。

调用:

recommendDrinks(
  "清爽水果茶,少糖,不腻",
  20
)

页面自动高亮并展示 2–3 款符合条件的饮品。

你选中其中一杯。

页面注册了下单相关工具:

/**
 * 将指定饮品加入购物车
 *
 * product_id - 饮品 ID
 * options - 规格选项,例如甜度、冰量
 */
addDrinkToCart(product_id, options)

/**
 * 提交订单
 */
checkout()

浏览器Agent调用:

addDrinkToCart(
  5567890,
  {
    sweetness: "少糖",
    ice: "少冰"
  }
)

页面提示“已加入购物车”。

浏览器Agent在界面上显示一个提示按钮:
<去结算>

你点击。

浏览器Agent调用:

checkout()

页面跳转到确认订单页,你确认地址并完成支付。

整个过程中,浏览器Agent并没有去“点击筛选按钮”或“模拟输入搜索框”,而是直接调用页面注册的结构化工具函数。页面把原有的搜索、筛选、推荐、加购、下单逻辑封装成 WebMCP 工具,让 AI 可以用更稳定、更语义化的方式操作。

这就是 WebMCP 的核心理念:
不是让 AI 像人一样操作页面,而是让页面主动把能力暴露出来,供 AI 调用。

六、demo

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8" />
  <title>WebMCP Article Demo</title>
  <style>
    body { max-width: 800px; margin: auto; font-family: sans-serif; }
    article { line-height: 1.6; }
  </style>
</head>
<body>

  <h1>WebMCP Article Demo</h1>

  <article id="main-article">
    <h2>示例文章标题</h2>
    <p>这是第一段正文内容。</p>
    <p>这是第二段正文内容。</p>
    <p>这是第三段正文内容。</p>
  </article>

  <script>
    function extractArticleText() {
      // 优先找 article 标签
      let article = document.querySelector("article");

      // 如果没有 article,就尝试主内容容器
      if (!article) {
        article = document.querySelector("main") ||
                  document.querySelector("#content") ||
                  document.body;
      }

      // 清除 script/style
      const clone = article.cloneNode(true);
      clone.querySelectorAll("script, style, nav, footer").forEach(el => el.remove());

      const text = clone.innerText.trim();

      return {
        title: document.title,
        url: location.href,
        content: text,
        length: text.length
      };
    }

    if (navigator.modelContext?.registerTool) {
      console.log("[WebMCP] registering getArticleContent");

      navigator.modelContext.registerTool({
        name: "getArticleContent",
        description: "获取当前页面的文章正文内容",
        inputSchema: {
          type: "object",
          properties: {}
        },
        async execute() {
          const data = extractArticleText();

          return {
            content: [
              {
                type: "text",
                text: JSON.stringify(data, null, 2)
              }
            ]
          };
        }
      });

      console.log("[WebMCP] tool registered");
    } else {
      console.warn("WebMCP not supported in this browser.");
    }
  </script>

</body>
</html>

从一个想法到可发布:我把博客接进 MCP 的完整实践

同步至个人站点:从一个想法到可发布:我把博客接进 MCP 的完整实践

最近看 MUI 文档时,我注意到它已经有 MCP 了。然后我就顺手把本地的 Codex、Claude 这类 code agent 都接进了它的 MCP。

体验非常直接:开发里遇到 MUI 用法问题,Agent 不用我手动贴链接,自己调 mui mcp 就能拿到官方答案。用过一次之后,很容易上瘾。

我这边正好也在做 memo code ,最近在补 MCP client / pool / CLI(比如 memo mcp add/remove/list)。越做越觉得,MCP 不只是“大厂工具的生态接口”,它对小工具开发者、库作者、内容站作者也很有价值。

我这次的起点其实很朴素:

我想让别人本地 npx 一下,就能把 CellStack 接进 Agent 的 MCP 生态。

最理想的画面是,用户问一句“mcell 如何解决xxx问题的”,Agent 直接调工具返回结果,而不是我手动甩链接。

所以这篇想表达的重点,不只是“我实现了一个 MCP server”,而是这套做法本身:

如果你手里有工具、库、内容站,想让 Agent 像调工具一样调用你的内容,这是一条几乎零服务器成本的落地路线。

1. 先拆三层:把站点细节从 Agent 侧剥离

我一开始就刻意把方案拆开,避免 Agent 直接依赖站点内部结构:

  1. 构建期生成静态数据(先把站点内容变成标准 JSON)
  2. 用户本地起 MCP Server(@mcell/stack-mcpnpx 即用)
  3. Agent 侧 MCP Client 只管调工具,不关心站点怎么组织、页面怎么写

这三层拆完之后,server 的职责就很纯粹:把内容暴露成一组可查询工具,而且是用户本地跑,我不用额外养服务

第一版很快做出来,但当时模型太“文章中心”,主要只覆盖 blog / topic article。很快我就发现不够:CellStack 不只有文章,还有专题页、站点介绍、关于我这些信息。

如果 Agent 只能读文章,它就更像“文章检索器”,而不是“能回答整个站点内容”的助手。

2. 模型升级成多资源:把“站点”变成可查询资源集合

我把数据模型升级成了多资源结构:

  • blog
  • topic
  • topic_article
  • site_page
  • profile

构建产物也从单一索引,扩成下面这套:

  • index.json
  • latest.json
  • catalog.json
  • articles/*

同时把站点信息和“我”的信息抽成统一数据源,让页面渲染和 MCP 共用同一份内容,避免维护两套数据。

工具层也同步升级:

  • list_resources
  • read_resource
  • list_topics
  • read_site_info

并且我保留了旧工具名做兼容,避免早期接入方被强制迁移。

3. 真正的坑不在协议,在交付链路

中间踩了两个很真实的坑:

  1. MCP 握手失败。我一度怀疑是协议问题,最后发现根因是 npx 当时还拉不到包(404),stderr 里是 npm 报错。
  2. 手工发 npm 不稳定。token / 2FA 在“我电脑上能发”不等于“可重复的交付链路”。

这俩问题让我意识到,如果目标是“一句命令接入”,那真正要工程化的不只是 MCP,而是发布与分发。

4. 把发包也工程化:从“能用”到“可持续演进”

后面我把发布流程写进了 CI:

  • 构建流程生成 MCP 原数据
  • 单独加 publish-stack-mcp workflow,检测 packages/stack-mcp 改动后自动发包(版本已存在则跳过)

然后又做了一个很关键的小优化:默认静默启动日志,减少客户端把 stderr 噪音误判成异常;需要排查时再开 STACK_MCP_DEBUG

到这一步,这件事才算从“能不能做”变成了“可发布、可维护、可演进”。

5. 接入体验:一句命令 + 站点内直接给配置

现在接入基本一句命令:

codex mcp add cellstack -- npx -y @mcell/stack-mcp@0.2.1

此外我在站点右上角加了 MCP 图标和配置弹窗,直接给 Codex / Claude / Memo / 标准配置的可复制示例,尽量把接入门槛压到最低。

相关记录:

6. 为什么我现在更偏向 MCP(而不只是 skills)

很多人会说“skills 不就行了”。skills 当然有用,但它有个很现实的维护问题:你经常要为不同 Agent 分别写接入说明和配置。并且这类文档库等产品,更新比较及时,使用 SKILLS 就需要频繁的修改本地 SKILSS 文档,远不如使用 MCP。

Claude Code CLI、Cursor、Codex CLI、OpenCode……各家入口、目录约定、文档风格都不同。久而久之,一个仓库里会长出一堆 .xxx/ 配置目录,后续改接口、改 schema、加字段时,就得挨个同步、挨个测。

这套静态 JSON + npx 本地 MCP Server 的组合,本质上是把问题收敛成三件事:

  • 站点侧:维护一份可演进的标准化数据产物(JSON / catalog / latest / resources)
  • 工具侧:维护一个 MCP Server(npx 即用)
  • Agent 侧:谁支持 MCP 谁就能接,差异只剩“添加 server 的命令怎么写”

事实上,定义好mcp server tools、json docs 生成脚本逻辑之后不需要再管了,后面就快快乐乐的用吧。

这对长期维护“自己的专属知识库”非常友好。后续如果我打算做个人Agent知识库的话,觉得这种做法还是蛮好的。甚至扩展一下,MCP + SKILL的组合也不错,或许长期积累之后,AGENT 即我呢?

(完)

❌