前端将死，Agent 永生

我在家里一边收拾家里小鱼缸，一边刷到 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 永生》，最大的震撼其实不是情绪，而是那个前提变化：

放到 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 调的工具层。

我讲真，这种人会很贵！