一份为你定制的 WebMCP 技术访谈解读

在 WebMCP 出现之前，AI 助手（比如你通过 ChatGPT 控制的浏览器插件）想操作一个网站，只有两种方法，都很“笨”：

1. 视觉模式（看截图）：AI 看一眼网页的截图，猜猜哪里是按钮、哪里是输入框，然后模拟鼠标去点击。这就像一个眼神不太好的人在识别一个完全陌生的 App 界面，很容易点错，而且效率极低。
2. 代码模式（读源码）：AI 直接去读网页背后那堆密密麻麻的 HTML 代码，从代码里分析结构，找到能操作的地方。这就像一个人不看软件界面，反而去读软件的源代码来搞懂怎么用，信息量巨大，而且非常耗费“脑力”（计算资源）。

这两种方法都又慢又贵，还容易出错。WebMCP 就是要提供第三种选择。

WebMCP 的核心思想非常简单：

让网站自己主动告诉 AI 助手：“你好，我是个购物网站，我这里有这几个功能：‘搜索商品’、‘加入购物车’、‘结账’。你要是用的话，就按这个格式来调用我。”

它就像是给每个网站都配上了一份标准化的“API接口”或“官方使用说明书”。AI 助手一上来，不用再猜了，直接阅读这份说明书，就能准确、高效地使用网站的功能。

这让网站从一个只能“看”的界面，变成了一个可以被程序直接调用的“工具”。

故事的主人公 Alex Nahas 当时在亚马逊当后端工程师。亚马逊内部有成千上万个系统和服务，每个都有自己的操作方式和权限验证方法。当 AI 助手（MCP）出现后，想把这些工具都接进去，简直是一场噩梦。

最大的问题是**权限**。AI 助手并不知道自己有没有权限去操作某个内部工具。而亚马逊所有员工的权限，都是通过浏览器登录来统一管理的。

Alex 灵机一动：为什么不干脆让 MCP 直接在浏览器里运行呢？这样一来，它自然就拥有了和当前登录用户完全相同的权限，所有权限问题都迎刃而解了！

这就是 MCP-B 的由来（B 代表 Browser，浏览器）。Alex 把 MCP 的核心功能用前端技术（TypeScript）在浏览器里实现了一遍。这样，AI 助手就能在浏览器这个“安全沙盒”里，名正言顺地操作它有权访问的一切。

这个想法非常巧妙，因为它解决了 AI 助手在企业内部应用最头疼的权限问题。

巧的是，Google Chrome 和微软 Edge 团队当时也在研究类似的问题：“怎么才能让 AI 助手安全、高效地与网页互动？”

当 Alex 带着他的 MCP-B 出现时，大家一拍即合。于是，他们联合 W3C（万维网联盟，制定所有网页标准的组织），把 MCP-B 的思想进一步发扬光大，并正式命名为 WebMCP，致力于把它变成一个所有浏览器都支持的国际标准。

这是一个非常现实的安全噩梦：

1. 你在浏览器里开了两个标签页。
2. 标签页 A 是你的**网上银行**。
3. 标签页 B 是一个你无意中点开的**恶意网站**。

如果这时有一个能力很强的 AI 助手在后台运行，它可以同时看到这两个页面的内容。那么，恶意网站 B 就可以通过“提示词注入”的方式，欺骗 AI 助手去你的网银页面 A 窃取信息，甚至转账！

这就是所谓的“致命三联招”：**敏感页面 + 恶意页面 + 一个能看到一切的 AI 助手 = 灾难**。

WebMCP 不能完全根除这个问题，但大大降低了风险。

因为 AI 助手不再是“看到所有东西”（比如网页截图和全部代码），它只能接触到网站主动“暴露”给它的那几个标准工具。网站可以精确控制哪些功能可以被 AI 调用，哪些敏感信息绝对不能暴露。

这就像是从“把家里所有房间的钥匙都给了管家”，变成了“只给了管家一个工具箱，告诉他只能用这些工具干活”。虽然管家还是可能被骗，但他能造成的破坏被大大限制了。