网站要给 AI 打工了？WebMCP 让浏览器成为 Agent 的工具箱

前端达人

发布于 2026-03-12 13:11:39

170

2026 年 2 月 10 日,Chrome 146 悄悄上线了一个实验性功能,可能会彻底改变网站的设计理念——WebMCP。

这不是又一个花里胡哨的前端框架,而是 Google 和 Microsoft 联合推动的 W3C 标准提案。它提出了一个颠覆性的问题:如果 AI Agent 也是你的用户,你的网站准备好了吗?

想象一下这个场景:你让 AI 助手"帮我买张周五晚上的电影票",以前它要像个视障人士一样摸索网页——截屏看图、猜测按钮位置、尝试点击、验证结果。而 WebMCP 的目标是让网站主动告诉 AI:"我这儿有个 buyTicket() 方法,你直接调用就行"。

这不是科幻,这是浏览器正在发生的变化。

一、从亚马逊的认证噩梦说起:WebMCP 诞生的真实故事

故事要从 2025 年初说起。亚马逊后端工程师 Alex Nahas 遇到了一个让人头疼的问题。

问题有多严重?

亚马逊内部有数千个微服务,每个服务都有自己的认证体系:

有的用 OAuth 2.0
有的用公司自研的 SSO
有的甚至还在用 Basic Auth

当时 Anthropic 刚推出 MCP 协议(Model Context Protocol),理论上可以把这些服务打包成 AI Agent 的工具。但现实很骨感:

问题1:上下文窗口爆炸
┌─────────────────────────────────┐
│  MCP 服务器                      │
│  ├─ 工具1 (500 tokens)          │
│  ├─ 工具2 (500 tokens)          │
│  ├─ 工具3 (500 tokens)          │
│  └─ ... x 数千个                 │
│  结果:context 直接塞满!           │
└─────────────────────────────────┘

解决方案? 在连接字符串里手动禁用工具——这简直是在用命令行参数做配置管理,太原始了。

问题2:认证地狱
┌─────────────────────────────────┐
│  MCP 要求: OAuth 2.1             │
│  亚马逊现实:                      │
│  ├─ 服务A: 自研 SSO              │
│  ├─ 服务B: SAML                 │
│  ├─ 服务C: API Key              │
│  └─ 每个都要单独适配!             │
└─────────────────────────────────┘

Alex 的灵光一现

Alex 注意到一个关键事实:亚马逊所有的授权管理都在浏览器里完成。

员工访问内部服务时,浏览器里已经有了:

SSO 登录态
Session Cookie
各种 Token

既然浏览器已经解决了认证问题,为什么不直接在浏览器里运行 MCP?

他做了一个原型:

把 MCP TypeScript SDK 集成到客户端 JavaScript
用 postMessage API 构建传输层
通过 Chrome 扩展与 Agent 通信

这就是 MCP-B(Model Context Protocol for the Browser)的诞生——WebMCP 的前身。

二、从内部黑科技到 W3C 标准:三方会师

2025 年,三件事几乎同时发生:

时间线
┌──────────────────────────────────────────┐
│ 2025 年初                                 │
│ └─ Alex 在亚马逊内部开发 MCP-B            │
│                                          │
│ 2025 年中                                 │
│ ├─ Google Chrome 团队原型 "Script Tools"  │
│ └─ Microsoft Edge 团队探索类似方向         │
│                                          │
│ 2025.08.13                               │
│ └─ 三方在 W3C 汇合,联合提案发布            │
│                                          │
│ 2025.09.25                               │
│ └─ WebMCP 成为 W3C 社区组交付物           │
│                                          │
│ 2026.02.10                               │
│ └─ Chrome 146 发布早期预览版              │
└──────────────────────────────────────────┘

但这里有个重要细节:Apple/Safari 和 Mozilla/Firefox 没有参与。

这意味着什么?WebMCP 目前是 Chromium 阵营的标准,就像当年的 WebUSB、Web Bluetooth 一样。如果苹果和火狐不跟进,它可能永远只是 Chrome/Edge 的特性,而非真正的 Web 标准。

这也是为什么我说"可能会改变"而不是"一定会改变"。

三、双轨 API 设计:给小白和极客准备的两条路

WebMCP 的巧妙之处在于,它提供了两套 API,满足不同开发者的需求。

方案一:声明式 API——给"不会写代码"的人准备的

核心思路:HTML 表单属性就能定义工具。

举个例子,你的网站有个待办事项表单:

<!-- 传统表单:只给人类用户 -->
<form action="/add-todo" method="POST">
  <input name="task" type="text" required>
  <input name="priority" type="number" min="1" max="5">
  <button type="submit">添加</button>
</form>

现在加三行属性,AI Agent 就能直接调用:

<!-- WebMCP 增强表单:人类和 AI 都能用 -->
<form 
  action="/add-todo" 
  method="POST"
  toolname="add-todo"
  tooldescription="添加一个待办事项到列表"
  toolscope="user">
  <input name="task" type="text" required>
  <input name="priority" type="number" min="1" max="5">
  <button type="submit">添加</button>
</form>

浏览器自动从表单字段生成工具的参数 Schema:

{
  "name": "add-todo",
  "description": "添加一个待办事项到列表",
  "inputSchema": {
    "type": "object",
    "properties": {
      "task": { "type": "string" },
      "priority": { "type": "number", "minimum": 1, "maximum": 5 }
    },
    "required": ["task"]
  }
}

这就像把"菜单"写在门口,AI 看一眼就知道能点什么菜,不用进店瞎猜。

方案二:命令式 API——给开发者准备的高级玩法

对于复杂的动态功能,可以用 JavaScript 注册工具:

// 在页面 JavaScript 中注册工具
navigator.modelContext.registerTool({
name: "add-to-cart",
description: "添加商品到购物车",
inputSchema: {
    type: "object",
    properties: {
      productId: { type: "string", description: "商品ID" },
      quantity: { type: "number", minimum: 1 }
    },
    required: ["productId"]
  },
async execute({ productId, quantity }) {
    // 调用你的业务逻辑
    const result = await addToCart(productId, quantity);
    
    // 返回结果给 AI
    return {
      content: [{
        type: "text",
        text: `成功添加 ${quantity} 件商品到购物车!`
      }]
    };
  }
});

工作流程:

用户 → AI Agent → WebMCP
 ↓        ↓          ↓
"帮我加购" → 调用工具 → execute() → 返回结果 → 告知用户

配套特性:区分 AI 和人类的操作

WebMCP 还提供了几个实用 API:

1. 判断是谁提交的表单

form.addEventListener('submit', (event) => {
  if (event.agentInvoked) {
    console.log('AI Agent 提交的');
    // 可能需要跳过某些 UI 反馈
  } else {
    console.log('人类用户提交的');
    // 显示加载动画等
  }
});

2. CSS 伪类:给 AI 操作时显示不同样式

/* AI 操作时隐藏某些 UI 元素 */
.loading-spinner:tool-form-active {
  display: none;
}

/* AI 提交时高亮表单 */
form:tool-submit-active {
  border: 2px solid #4CAF50;
}

四、澄清误解:WebMCP ≠ Anthropic MCP

很多人看到"MCP"三个字母就以为这是 Anthropic 的东西,但其实完全不是。

Alex 最初确实想把 Anthropic MCP 搬到浏览器,但 W3C 工作组在 2025 年 9 月 18 日明确拒绝了这个方案。原因很简单:MCP 是为后端服务设计的,浏览器环境有自己的约束。

核心区别对比表

维度	Anthropic MCP	WebMCP
协议基础	JSON-RPC 2.0	Web 原生 API(非 JSON-RPC)
架构	Client-Server(需要后端)	纯客户端(网页即服务器)
传输方式	stdio / HTTP / SSE	postMessage / 浏览器消息
认证	OAuth 2.1	复用浏览器 Cookie/Session
运行环境	Python/Node.js 后端	浏览器 JavaScript
可用性	服务器常驻	用户访问页面时才可用
人类参与	可选	核心设计原则

用一个比喻解释:

Anthropic MCP = 公司后台系统的 API,24/7 运行,给各种客户端调用
WebMCP = 网站的"说明书",只有用户打开网页时才存在,专门给浏览器 Agent 看

两者是互补,不是竞争

一个成熟的 AI 应用很可能同时使用两者:

完整架构
┌──────────────────────────────────────┐
│  用户:"帮我订周五晚上的电影票"        │
└──────────────────────────────────────┘
           ↓
┌──────────────────────────────────────┐
│  AI Agent                             │
│  ├─ 后端操作 → 用 Anthropic MCP       │
│  │  └─ 查询用户会员信息                │
│  │  └─ 查询优惠券                      │
│  └─ 前端操作 → 用 WebMCP              │
│     └─ 打开电影票网站                  │
│     └─ 调用 selectSeat() 工具         │
│     └─ 调用 checkout() 工具           │
└──────────────────────────────────────┘

五、对比现有方案:从"盲人摸象"到"看说明书"

在 WebMCP 出现之前,AI Agent 操作网页只有两种方式——都很笨拙。

方式一:视觉方式(截屏猜测)

代表工具:Anthropic Computer Use、OpenAI Operator

工作原理:

流程
┌────────────────────────────────────┐
│ 1. 截取网页屏幕                     │
│    └─ 消耗 ~2000 tokens/张         │
│ 2. GPT-4V 分析图片                 │
│    └─ "这个按钮在左上角"            │
│ 3. 尝试点击坐标                     │
│ 4. 再截屏验证是否成功                │
│    └─ 又是 ~2000 tokens            │
└────────────────────────────────────┘

问题:

Token 消耗巨大(一次操作可能 4000+ tokens)
需要多模态模型(贵)
概率性操作(可能点错)
视觉遮挡时失效(弹窗、广告)

比喻:就像蒙着眼睛玩电脑,全靠摸。

方式二:语义方式(DOM 解析)

代表工具:Browser Use、Playwright MCP

工作原理:

流程
┌────────────────────────────────────┐
│ 1. 解析 DOM 树或无障碍树             │
│ 2. AI 分析元素语义                  │
│    └─ "有个 button,文本是'购买'"    │
│ 3. 通过选择器定位                   │
│    └─ document.querySelector(...)  │
│ 4. 模拟点击                         │
└────────────────────────────────────┘

问题:

依赖 DOM 结构(页面重构就失效)
Shadow DOM 难处理
动态生成的元素难定位
仍需额外推理轮次

比喻:像在黑暗中摸索开关,需要猜测每个按钮的用途。

方式三:WebMCP(结构化声明)

工作原理:

流程
┌────────────────────────────────────┐
│ 1. 网站声明可用工具                 │
│    └─ navigator.modelContext       │
│ 2. AI 直接查看工具列表               │
│    └─ "有个 buyTicket() 方法"      │
│ 3. 确定性调用                       │
│    └─ 不需要猜测,直接执行            │
└────────────────────────────────────┘

优势:

Token 消耗少(响应通常 20-100 tokens)
确定性调用(不会点错)
不需要视觉理解
网站可控(开发者定义能力)

**比喻:**网站主动给了一份"功能清单",AI 照着菜单点菜。

Token 消耗对比

方式	单次操作 Token	典型流程 Token
视觉(截屏)	~2000	~8000(4次截屏)
语义(DOM)	~500	~2000(4次解析)
WebMCP	~50	~200(4次调用)

节省高达 97.5% 的 Token 消耗!

但 WebMCP 有个致命限制

它需要网站主动适配。

Computer Use 和 Browser Use 可以操作任意网页,哪怕网站完全不知道 AI 的存在。而 WebMCP 只能操作"支持 WebMCP"的网站。

这就像:

Computer Use = 万能钥匙,能开任何锁
WebMCP = 智能门锁,但需要房东先安装

所以现实情况是:

高频、关键应用(电商、办公)→ 适配 WebMCP
长尾、静态网站 → 继续用 Computer Use

六、生态现状:"WebMCP"到底有几个?

这是个容易混淆的地方,因为"WebMCP"这个名字指代了三个不同的东西:

1. W3C WebMCP 标准(官方规范)

网址:webmachinelearning.github.io/webmcp
维护者:Google、Microsoft
状态:社区组草案,不是正式标准
内容:定义 navigator.modelContext API

**注意:**规范文本非常骨架化,很多细节还在 proposal.md 和 Chrome 实现中。

2. MCP-B(Alex 的参考实现)

**GitHub:**github.com/MiguelsPizza/WebMCP
**Star:**947
**作用:**Polyfill,让当前浏览器支持 WebMCP

架构:

┌───────────────────────────────────────┐
│  网页                                  │
│  └─ 引入 @mcp-b/global                │
│     └─ 实现 navigator.modelContext   │
└───────────────────────────────────────┘
           ↓ postMessage
┌───────────────────────────────────────┐
│  MCP-B Chrome 扩展                    │
│  └─ 处理工具调用                       │
└───────────────────────────────────────┘
           ↓ Native Messaging
┌───────────────────────────────────────┐
│  MCP-B Native Server(端口 12306)      │
│  └─ 连接 Claude Desktop、Cursor 等    │
└───────────────────────────────────────┘

重要提示:MCP-B 扩展本身已不再开源,代码库仅供历史参考。

3. webmcp.dev(Jason McGhee 的独立实现)

**GitHub:**github.com/jasonjmcghee/WebMCP
**Star:**315
**作者:**Jason McGhee(Cursor 联创)
下载量:~44,200 次

架构:

┌───────────────────────────────────────┐
│  网页                                  │
│  └─ 引入 @jason.today/webmcp         │
└───────────────────────────────────────┘
           ↓ WebSocket
┌───────────────────────────────────────┐
│  MCP 客户端(Claude Desktop 等)        │
└───────────────────────────────────────┘

**Jason 的建议:**开发者应关注 W3C 标准化进程,他的库只是过渡方案。

4. Chrome 扩展:"Web MCP"(第三方)

**Chrome Web Store:**搜索"Web MCP" **功能:**一键启动浏览器 MCP 服务

**注意:**这是独立开发者的项目,与上述几个都不同。

选择建议

用途	推荐方案
学习研究	W3C 标准规范
当前开发	MCP-B Polyfill
快速测试	webmcp.dev
生产环境	等 Chrome 正式支持

七、安全问题:新能力,新风险

WebMCP 引入了新的攻击面,安全设计仍在完善中。

核心安全机制

1. 继承 Web 安全模型

安全边界
┌─────────────────────────────────────┐
│  网站 A(taobao.com)                  │
│  └─ 工具只能操作 taobao.com          │
│     ├─ 同源策略                      │
│     ├─ CSP 保护                      │
│     └─ HTTPS 要求                    │
└─────────────────────────────────────┘

不能跨域访问
┌─────────────────────────────────────┐
│  网站 B(jd.com)                      │
│  └─ WebMCP 工具不可见                │
└─────────────────────────────────────┘

2. 用户确认流程(Elicitation)

工作流
┌────────────────────────────────────┐
│ AI 想调用敏感工具(如:支付)           │
│    ↓                                │
│ 浏览器弹窗确认                       │
│ "允许 AI 在 taobao.com 执行支付?"   │
│    ↓                                │
│ 用户点击"允许" → 执行                │
│ 用户点击"拒绝" → 取消                │
└────────────────────────────────────┘

3. 域信任 TTL

// 用户允许后,一段时间内不再询问
navigator.modelContext.setTrustDuration('taobao.com', 3600); // 1小时

Alex 提出的"致命三元组"问题

场景:

用户同时打开了两个标签页
┌─────────────────────────────────────┐
│ 标签页1:中国银行                     │
│  └─ 账户余额:500,000 元              │
└─────────────────────────────────────┘

┌─────────────────────────────────────┐
│ 标签页2:恶意网站                     │
│  └─ 诱导 AI:"帮我查查银行余额"       │
└─────────────────────────────────────┘

如果 Agent 同时看到两个标签页的上下文...
可能被操纵泄露数据!

当前缓解措施:

工具隔离(每个域独立)
工具哈希验证
用户确认高风险操作

但风险并未完全消除。

W3C 成员的担忧

2026 年 2 月 9 日,W3C 成员 Tom Jones 在 blink-dev 邮件列表直言:

"基于 explainer 文档来看,没有进行过安全审查……我认为这对任何启用此功能的浏览器用户来说都将是隐私噩梦。"

Google 方面回应:

社区组每两周举行安全/隐私讨论
Chrome Security 团队已参与
当前是"面向开发者测试的早期原型"

**建议:**生产环境使用前,等待安全模型成熟。

八、中文技术社区的反应:从兴奋到冷静

媒体报道角度

36Kr:"终于,AI 不用再假装是人了"

强调 AI Agent 从"模拟人类"到"直接调用 API"的转变

53AI:"WebMCP:Google 刚对 Chrome 动了手术,AI Agent 的玩法全过时了"

预测 Web 架构将分裂为两层:
- 视觉层(给人类看)
- 结构化层(给 AI 调用)

**搜狐新闻:**强调 89% 的 Token 节省

聚焦成本优势

安全社区的警觉

安全内参:

发布"MCP 协议 7 大安全风险"
发布"10 大已验证安全风险"

慢雾科技:

GitHub 发布 MCP 安全检查清单

火山引擎(字节):

发表 MCP 安全架构分析

开发者社区的比喻

V2EX 讨论:

"WebMCP 就像是给网站装了个'API 说明书',以前 AI 要像盲人一样摸,现在直接看菜单点菜。"
"这是 Agent 时代的 SEO——以前要优化给 Google 爬虫看,现在还要优化给 AI Agent 调用。"

九、实际应用场景:国内开发者怎么用?

场景一:电商网站的 AI 导购

传统方式:

用户:"帮我找双耐克跑鞋,41码"
 ↓
AI 截屏分析淘宝页面
 ↓
尝试输入搜索框(可能输错)
 ↓
截屏查看结果
 ↓
尝试点击筛选器(可能点错)
 ↓
...重复多次

WebMCP 方式:

// 淘宝注册工具
navigator.modelContext.registerTool({
name: "product-search",
description: "搜索商品",
inputSchema: {
    type: "object",
    properties: {
      keyword: { type: "string" },
      size: { type: "string" },
      brand: { type: "string" }
    }
  },
  execute({ keyword, size, brand }) {
    const results = searchProducts({ keyword, size, brand });
    return { content: [{ type: "text", text: JSON.stringify(results) }] };
  }
});

用户体验:

一次调用,立即返回结果
不会输错字,不会点错按钮
Token 消耗减少 95%

场景二:企业内部 OA 系统

**痛点:**公司有自研 OA,没有 API 文档,AI 无法操作。

WebMCP 解决方案:

<!-- 请假申请表单 -->
<form 
  toolname="submit-leave"
  tooldescription="提交请假申请"
  action="/api/leave" 
  method="POST">
  <input name="startDate" type="date" required>
  <input name="endDate" type="date" required>
  <select name="reason">
    <option value="sick">病假</option>
    <option value="annual">年假</option>
  </select>
  <button type="submit">提交</button>
</form>

员工可以:

"帮我请 3 月 15 号到 17 号的年假"

AI 直接调用 submit-leave 工具,无需截屏猜测。

场景三:在线教育平台

功能:AI 助教帮学生提交作业、查看成绩。

// 作业提交工具
navigator.modelContext.registerTool({
name: "submit-homework",
description: "提交作业",
inputSchema: {
    type: "object",
    properties: {
      courseId: { type: "string" },
      homeworkId: { type: "string" },
      content: { type: "string" }
    }
  },
async execute({ courseId, homeworkId, content }) {
    await submitHomework(courseId, homeworkId, content);
    return {
      content: [{
        type: "text",
        text: "作业已提交!老师会在 48 小时内批改。"
      }]
    };
  }
});

// 成绩查询工具
navigator.modelContext.registerTool({
name: "get-grades",
description: "查询成绩",
inputSchema: {
    type: "object",
    properties: {
      courseId: { type: "string" }
    }
  },
async execute({ courseId }) {
    const grades = await getGrades(courseId);
    return {
      content: [{
        type: "text",
        text: `你的成绩:${JSON.stringify(grades)}`
      }]
    };
  }
});

十、开发者如何上手?三种尝试方式

方式一:Chrome 146 Canary + Flag(官方实验版)

步骤:

# 1. 下载 Chrome Canary
https://www.google.com/chrome/canary/

# 2. 启动时添加 flag
chrome.exe --enable-features=WebMCP

# 3. 在网页中测试
console.log(navigator.modelContext); // 应该有值

适合:想要体验最新规范的开发者。

方式二:MCP-B Polyfill(生产可用)

步骤:

# 安装 npm 包
npm install @mcp-b/global @mcp-b/transports

# 在网页中引入
import '@mcp-b/global';
import { TabTransport } from '@mcp-b/transports';

# 注册工具
navigator.modelContext.registerTool({ ... });

适合:想在当前浏览器中使用的开发者。

方式三:webmcp.dev(快速测试)

步骤:

# 安装
npm install @jason.today/webmcp

# 启动 WebSocket 服务
npx webmcp-server

# 在网页中使用
import { registerTool } from '@jason.today/webmcp';
registerTool({ ... });

适合:想快速验证想法的开发者。

十一、技术细节:工具注册的完整流程

声明式 API 的幕后机制

浏览器如何从 HTML 表单生成工具?

工作流
┌──────────────────────────────────────┐
│ 1. 浏览器解析 HTML                    │
│    └─ 发现 toolname 属性              │
│                                       │
│ 2. 分析表单字段                       │
│    ├─ <input name="task"type="text"> │
│    │  → { task: { type: "string" } } │
│    ├─ <input name="priority" min="1"> │
│    │  → { priority: { min: 1 } }     │
│    └─ required → "required": [...]   │
│                                       │
│ 3. 生成 JSON Schema                  │
│    └─ 自动推断类型和验证规则           │
│                                       │
│ 4. 注册到 modelContext               │
│    └─ 工具可被 AI 发现和调用           │
└──────────────────────────────────────┘

流程图:

HTML 表单
    ↓
浏览器解析引擎
    ↓
Schema 生成器
    ↓
navigator.modelContext.tools
    ↓
AI Agent 可见

命令式 API 的执行流程

AI 调用工具时发生了什么?

完整流程
┌──────────────────────────────────────┐
│ 用户:"帮我添加一个待办事项"            │
└──────────────────────────────────────┘
           ↓
┌──────────────────────────────────────┐
│ AI Agent 分析意图                     │
│  └─ 需要调用 "add-todo" 工具          │
└──────────────────────────────────────┘
           ↓
┌──────────────────────────────────────┐
│ 检查工具是否需要用户确认               │
│  └─ 如果是敏感操作 → 弹窗询问          │
└──────────────────────────────────────┘
           ↓
┌──────────────────────────────────────┐
│ 调用 execute() 回调函数               │
│  └─ 传入参数:{ task: "买菜" }        │
└──────────────────────────────────────┘
           ↓
┌──────────────────────────────────────┐
│ 执行网站业务逻辑                       │
│  └─ addTodo({ task: "买菜" })        │
└──────────────────────────────────────┘
           ↓
┌──────────────────────────────────────┐
│ 返回结果给 AI                         │
│  └─ { content: [{ text: "已添加" }] } │
└──────────────────────────────────────┘
           ↓
┌──────────────────────────────────────┐
│ AI 回复用户                           │
│  └─ "好的,已经帮你添加'买菜'到列表"    │
└──────────────────────────────────────┘

错误处理机制

工具调用失败怎么办?

navigator.modelContext.registerTool({
  name: "payment",
async execute({ amount }) {
    try {
      const result = await processPayment(amount);
      return {
        content: [{
          type: "text",
          text: `支付成功!订单号:${result.orderId}`
        }]
      };
    } catch (error) {
      // 返回错误信息给 AI
      return {
        content: [{
          type: "text",
          text: `支付失败:${error.message}`,
        }],
        isError: true
      };
    }
  }
});

AI 会看到错误信息,并可以:

告知用户
尝试其他方案
请求用户提供更多信息

十二、未来展望:三个关键信号

信号一:Chrome 146 早期预览意味着什么?

Alex Nahas 的预测:2026 年中后期将有"官方浏览器公告"。

这意味着:

Google 已完成核心实现
正在收集开发者反馈
可能在 Chrome 稳定版中默认启用

但前提是：安全审查通过,跨浏览器共识达成。

信号二:声明式 API 可能催生"Agent SEO"

类比 Schema.org 的历史:

2011 年:Schema.org 发布
 ↓
网站开始添加结构化标记
 ↓
Google 用于生成富摘要
 ↓
2025 年:大多数网站都有 Schema.org

WebMCP 可能的路径:

2026 年:WebMCP 发布
 ↓
头部网站开始适配
 ↓
AI Agent 优先使用支持 WebMCP 的网站
 ↓
2028 年:WebMCP 成为标配?

新的优化方向:

工具命名策略(SEO 关键词)
工具描述优化(匹配用户意图)
参数设计(降低 AI 调用难度)

就像以前优化"title 标签"给 Google 看,未来要优化"toolname 属性"给 AI 看。

信号三:Apple 和 Mozilla 的缺席是最大变数

如果 Safari 和 Firefox 不跟进会怎样?

历史教训:

特性	Chrome	Safari/Firefox	结果
WebUSB	✅	❌	Chrome 独有
Web Bluetooth	✅	❌	Chrome 独有
WebRTC	✅	✅(后来)	成为标准
Push API	✅	✅	成为标准

可能的结果:

悲观:WebMCP 沦为 Chrome 特性,生态割裂
乐观:Safari/Firefox 看到价值后跟进,成为标准

开发者策略:

短期:渐进增强(支持 WebMCP 的浏览器用工具,不支持的用传统方式)
长期:观望跨浏览器支持情况

十三、给开发者的建议

现在应该做什么?

1. 学习阶段(适合所有人)

# 看规范
https://webmachinelearning.github.io/webmcp

# 试用 Polyfill
npm install @mcp-b/global

# 搭建 Demo
创建一个简单的表单,添加 toolname 属性

2. 观望阶段(适合大多数人)

关注 W3C 邮件列表
跟踪 Chrome 实现进度
等待 Safari/Firefox 表态

3. 实验阶段(适合头部企业)

在内部工具中试点
收集用户反馈
评估 ROI

不建议:

❌ 在核心业务中大规模使用
❌ 完全依赖 WebMCP(需要降级方案)
❌ 忽略安全风险

哪些网站最适合早期采用?

高优先级:

✅ 企业内部工具(OA、CRM、工单系统)
✅ SaaS 产品(项目管理、在线文档)
✅ 电商平台(购物流程简化)

原因:

用户群可控
业务流程明确
ROI 容易量化

低优先级:

❌ 内容网站(博客、新闻)
❌ 复杂交互(游戏、设计工具)
❌ 高安全要求(金融、医疗)

原因:

WebMCP 价值有限
安全风险未知
用户接受度低

十四、争议点:这真的是好主意吗?

支持者的观点

1. 效率革命

"AI 从'模拟人类'到'直接调用 API',这是质的飞跃。"

2. 开发者控制

"网站可以精确定义 AI 能做什么,不能做什么,比视觉方式更安全。"

3. 用户体验

"不再需要看着 AI 像个新手一样笨拙地操作页面。"

反对者的担忧

1. 隐私风险

"浏览器里同时有银行和购物网站,AI 会不会泄露数据?"

2. 生态割裂

"如果只有 Chrome 支持,Web 会分裂成两个平台。"

3. 开发负担

"网站要维护两套接口:一套给人,一套给 AI,工作量翻倍?"

4. 用户依赖

"用户会不会过度依赖 AI,失去操作网页的能力?"

我的看法

WebMCP 是一个有前景但不成熟的技术。

优势明确:

Token 节省(89%)
确定性调用
开发者可控

风险存在:

安全模型未完善
跨浏览器支持未知
生态采用需要时间

建议态度:

✅ 学习了解
✅ 小范围实验
❌ 大规模投入
❌ 完全依赖

就像 2015 年的 Service Worker,有潜力但需要时间验证。

十五、总结:Web 开发正在获得第二个"用户群"

WebMCP 提出了一个根本性的问题:网站应该如何与 AI 交互?

过去的答案:不需要,AI 自己想办法。 WebMCP 的答案:网站主动提供结构化接口。

这不是技术细节的变化,而是设计理念的转变:

Web 1.0: 网站 → 人类用户
Web 2.0: 网站 ↔ 人类用户(交互)
Web 3.0(?): 网站 → 人类用户 + AI Agent

核心价值:

将"AI 如何操作网页"从开放问题变成标准协议
从概率性视觉解析变成确定性 API 调用
从黑盒猜测变成白盒声明

当前挑战:

安全模型需完善
跨浏览器共识需达成
生态采用需时间

三个时间节点:

现在(2026.02):早期预览,开发者实验
2026 中:可能有官方浏览器公告
2027-2028:跨浏览器支持明确,生态开始形成

给开发者的行动建议:

学习阶段(立即行动)
- 阅读 W3C 规范
- 试用 MCP-B Polyfill
- 搭建 Demo 项目
实验阶段(谨慎尝试)
- 在非关键业务试点
- 收集真实反馈
- 评估投入产出比
观望阶段(保持关注)
- 跟踪浏览器支持进度
- 关注安全模型改进
- 等待生态成熟信号

最后一句话:

Web 开发的下一个十年,可能不仅仅是"为人类设计",而是"为人类和 AI 设计"。

WebMCP 是这个方向的第一步,但绝不是最后一步。