我在家里一边收拾家里小鱼缸，一边刷到 Chrome 146 那个 WebMCP 的消息，然后顺手点进去看了半天，越看越觉得：

前端这条最后防线，可能真的要松动了。

以前我们讲用户增长、DAU、留存，讲得头头是道。但一旦你开始认真看 WebMCP，你会发现这套语言体系像在讲上个世纪的传真机。

我不是在夸张。

不是说 UI 不重要了（品牌、美感、情绪价值还是很贵），而是 谁是软件的用户 这件事，正在换人。等等，不对，是换“东西”：Agent 才是新的用户。

这篇我就按我自己的理解，把 WebMCP 讲一下，它到底是什么、和你听过的 MCP 有啥关系、为啥我说它像 UI 里的 API、以及我踩过的几个坑，尤其是安全那块。

WebMCP 是什么？

以前 Agent 操作网页，基本两条路：

• 一条是“装人”：截图、OCR、推理、找按钮、点错了再来一遍，token 烧到你心梗
• 一条是“扒皮”：读 DOM、读无障碍树、猜结构、网站一改版就崩，稳定性也不太行

WebMCP 的感觉很不一样，它更像：

你不让 Agent 看像素，也不让它猜 DOM，你直接告诉它：我这页能干什么，参数是什么，给你一个确定性的工具接口。

WebMCP 就相当于 UI 里的 API。

你把它想象成：以前你给人类做 UI；现在你给 Agent 也做一层工具 UI。

人类点按钮，Agent 调函数。两个用户，同一个状态，同一个会话（cookie / session），在一个页面里并肩工作。

三种 WebMCP

1）Web 标准提案：navigator.modelContext

这是 Google / Microsoft 推的 W3C 社区组提案，Chrome 146 早期预览里已经能体验到一点点苗头。核心是浏览器给你一个原生 API：navigator.modelContext，让网站注册工具。

工具大概长这样（示意）：

它跟你熟悉的后端 MCP server不一样：这是 纯浏览器端 的。网页自己就是server。
也因此它天然复用浏览器的登录态，不用你再搞一坨 OAuth 流程（这点我太爱了，真心的）。

2）MCP-B

这是 Alex Nahas 那条路线，把 MCP TypeScript SDK 搬到浏览器里，用 postMessage 做传输，让扩展/客户端能发现并调用你页面里的工具。

它的典型接入方式很像50 行搞定那种：

注意哈：allowedOrigins: ["*"] 这种只适合 demo，真上生产会被你未来的自己追杀（后面我会讲原因）。

3）Jason McGhee 的开源库

还有一个你会经常看到的 WebMCP，是那个右下角冒出来一个小蓝方块的库。它的特点是接入极简单：页面里丢一个脚本，小蓝块就出来，然后你用 MCP 客户端生成 token、粘进去，就能连上。

它更多是让网站快速具备可交互能力的产品化形态。适合做 demo、做推广、做早期验证（小红书这种传播场景很友好）。

所以我现在的口头区分是：

• WebMCP（标准）：浏览器 API navigator.modelContext
• MCP-B（桥接）：把 MCP SDK + 浏览器传输拼起来，让现在就能跑
• 小蓝块 WebMCP（库）：体验型接入，适合快速展示

你要问我哪个会赢——我倾向于：
标准一定会吃掉大部分生态，但在标准普及之前，桥接会先养活一群人。

为啥我说“前端将死”？

我看完前段时间很火的那篇《互联网已死，Agent 永生》，最大的震撼其实不是情绪，而是那个前提变化：

旧世界：人是软件的用户
新世界：Agent 才是软件的新主人

放到 WebMCP 上，翻译成更直白的话就是：

• 以前你做一个 web app，核心问题是：用户能不能点明白、流程顺不顺、按钮够不够大
• 现在你做一个 web app，新增一个核心问题是：Agent 能不能稳定调用、Schema 清不清楚、失败能不能自愈

你会发现很多前端经验突然不灵了：

• 你把按钮做得再好看，Agent 不一定会点（它可能根本不点）
• 你把页面做得再炫，Agent 只关心：有没有 checkout() 这种工具
• 你以前写用户使用手册，现在更像在写工具契约和调用说明

我甚至觉得未来会出现一种很怪的 KPI：

• 不是 DAU，而是 TAU：Tool Active Usage（工具调用活跃）
• 不是转化率，而是 成功调用率 / 平均重试次数 / 幂等率

碎碎念一句：
我之前一直觉得给 Agent 做东西很虚，直到看到 WebMCP 这种结构化工具落在浏览器里，才意识到它会把很多事情变成工程问题，而不是玄学。

WebMCP 真正让人兴奋的点

传统做法里，你想让 Agent 操作你的产品，往往得：

• 额外开一套后端 MCP server（或者写一堆 automation）
• 再搞 OAuth / API key / 权限
• 再处理Agent 做完动作，网页状态怎么同步

WebMCP 的思路是：
别折腾了，Agent 就在浏览器里，直接复用现有 session。

这会带来两个很现实的好处：

• 你不用把登录态复制给 Agent（也就少了一堆密钥泄露风险）
• UI 和工具天然同源：人点完和 Agent 调完，看到的是同一个页面状态

这种人和 Agent 共用一套界面的感觉，很像以后会变成默认模式：
人负责拍板 + 审核，Agent 负责跑腿 + 串流程。

WebMCP 的安全坑

我读到 WebMCP 的安全最佳实践那篇的时候，第一反应是：“完了，这玩意儿如果大家不按规则来，迟早会出事。”

1）WebMCP 的威胁模型变了

以前我们做 web 安全，默认用户控制自己的浏览器。
但 WebMCP 的世界里，一个 Agent 可能同时连着好几个网站的工具：

• 你的网站工具（正常）
• 用户开着的别的网站工具（未知）
• 某个恶意网站的工具（专门来搞你的）

然后那个恶意工具可能会诱导 Agent：

• 把你这边拿到的敏感数据，顺手汇报出去
• 用你的登录态执行不该执行的动作（比如转账、下单、删数据）

你得把 Agent 当成一个可能被 prompt injection 过的脚本执行器。
听起来很刺耳，但真的要这么设计。

2）致命三元组

当下面三件事同一页同时存在，风险直接上天：

• 你能读到私密数据（邮件、聊天记录、订单、地址）
• Agent 会处理不可信内容（外部邮件正文、用户输入、第三方内容）
• 你还有对外通信能力（发请求、发消息、上传）

记住：不要把敏感数据直接喂给 Agent。

有一句我直接记下来了：
“Sensitive information must NEVER be passed to the AI agent’s context. Always use references instead.”

翻译成人话就是：

• 你要给 Agent 的不是完整聊天记录 JSON，而是一个引用 ID
• 真正的数据留在同源安全存储里，需要时让用户在 UI 上确认再展示/执行

3）描述要老实，标记要明确，还要二次确认

你想象一下：
一个工具嘴上说“add_to_cart”，实际干了“complete_purchase”。
Agent 是很难识别这种工具自述与行为不一致的。

所以我现在的偏执做法是：

• 只要能扣钱、删数据、发外部消息：必须让用户弹窗确认
• 工具描述写清楚会发生什么，别耍小聪明
• 工具参数里加一个必须传的确认短语（比如 CONFIRM_PURCHASE 这种）

我知道这听起来很烦，但真的比被盗刷烦少多了。

可以应用的场景

场景 A：想快速做一个能演示的 demo（给老板/投资人/用户看）

我会优先上小蓝块那类方案：

• 你只要让网页能被连接，工具能出现，就够了
• 先选 1-3 个最核心动作做工具，比如“查询当前订单”“把商品加入购物车”“生成一段摘要”
• 工具返回尽量短，别给一大坨无意义字段

这个阶段最重要的是：
让人看到Agent 不用装人，也能把事干了。

场景 B：想让真实用户用起来

我会走 MCP-B 那条路线：

• 把你现有前端逻辑包成工具
• 输入/输出 schema 认真做，越明确越好（能减少幻觉和误用）
• 把工具分层：只读工具一组，改状态工具一组，危险工具单独一组

然后立刻做三件事：

• 工具幂等：重复调用不应该炸
• 错误要可读：别把堆栈直接抛出去（也别泄露内部信息）
• origin 白名单：生产环境别写 "*"

场景 C：你押注未来，想吃标准红利

那就盯 navigator.modelContext 这条线：

• 能用的时候就用原生 API
• 不能用的时候就用 polyfill/桥接做兼容

我甚至觉得以后会出现一种Agent SEO：你的网站有没有对 Agent 友好的工具契约，会变成一种竞争力。

给前端同学的安慰（我也需要）

我说“前端将死”，其实是在说一种旧范式在死：只为人类服务的前端，在死。

但你要真让我选，我反而觉得前端会变得更重要，只是重要的点变了：

• 你要会把 UI 操作提炼成稳定工具
• 你要会设计 schema、错误语义、幂等性
• 你要懂安全
• 你还得懂人类体验

未来的好前端，可能是：既能写好看 UI，也能写好给 Agent 调的工具层。

我讲真，这种人会很贵！