当浏览器里多了一种“用户”：WebMCP 时代，前端该怎么重新设计界面

过去我们做前端，只需要面对一种用户：坐在屏幕前、用眼睛看、用手点的人。2026 年下半年，这个前提开始松动——浏览器里的 AI 智能体会替用户读页面、填表单、比价、下单。它们一开始的做法很笨：截图、猜按钮、模拟点击，一次改版就可能全盘失效。

最近我认真跟进了 WebMCP 这个提案，以及围绕它长出来的第一批工具链（GrapesJS WebMCP 插件、Vercel Labs 的 wterm、AI SDK 7 的周下载量已达 4400 万）。我的判断是：这不是又一轮“AI 生成页面”的热闹，而是前端第一次需要为“非人类调用者”设计一套正式接口。这篇文章聊聊它是什么、代码长什么样，以及我认为前端工程师现在真正该做的事。

一、从“猜界面”到“给契约”

WebMCP 是 W3C Web Machine Learning Community Group 里、由微软和谷歌工程师编辑的一份草案：网页可以把自己的 JavaScript 函数或 HTML 表单，注册成带自然语言描述和 JSON Schema 的“工具”（tool），供浏览器内的智能体直接调用。

区别用一句话就能说清。用户说“帮我订周五四位的桌”，只有视觉能力的智能体得：找到日期输入框 → 打开日历组件 → 选时段 → 猜哪个按钮是“确认” → 再截图确认结果，中途一个弹窗就能让它迷路。而有了 WebMCP，页面直接提供一个 book_table(date, time, guests)，智能体传参调用、拿到结构化结果。

关键在于工具运行在用户当前打开的页面、复用用户已登录的会话和页面状态。这跟后端常驻的 MCP Server 是互补关系：Server 服务终端、编辑器、聊天客户端里的智能体；WebMCP 服务此刻正停在你页面上的那个智能体。Chrome 的说法很形象——MCP 是持久的，WebMCP 是跟着标签页走的。

二、两套 API：命令式与声明式

命令式入口是 document.modelContext.registerTool()。一个只读工具大致长这样：

const mc = document.modelContext || navigator.modelContext;
if (mc && typeof mc.registerTool === 'function') {
  await mc.registerTool({
    name: 'search_faq',
    description: '按关键词检索本页常见问题，返回最多 3 条匹配结果。只读，不修改任何数据。',
    inputSchema: {
      type: 'object',
      properties: { question: { type: 'string', description: '用户的问题原文' } },
      required: ['question']
    },
    annotations: { readOnlyHint: true },
    async execute({ question }) {
      return faqIndex.search(question).slice(0, 3); // 复用页面已有的数据
    }
  });
}

注意第一行：2026 年间入口从 navigator.modelContext 迁到了 document.modelContext，所以要双读兼容；不支持的浏览器要安静降级，不能报错影响正常用户。

更有意思的是声明式 API——不写一行 JS，给普通表单加两个属性就能变成工具：

<form toolname="request_quote" tooldescription="提交询价申请，需填写姓名与需求">
  <label>姓名</label>
  <input name="name" toolparamdescription="联系人的真实姓名">
  <label>问题类型</label>
  <select name="type"><option>账单问题</option><option>技术问题</option></select>
  <button type="submit">送出</button>
</form>

浏览器会自动把 <select> 的选项转成 anyOf + enum，把 label 文本变成字段说明，生成完整 JSON Schema。配套的 SubmitEvent.agentInvoked 能告诉你“这次提交是智能体发起的”，:tool-form-active / :tool-submit-active 两个伪类则让你能在界面上实时显示“AI 正在帮我填这一栏”。这是很前端的细节：能力开放出去的同时，也要把正在发生的事可视化给人看。

三、我总结的六条工具设计原则

把工具当成一个对外 API 来设计，而不是把内部函数随便挂出去。下面这几条是我在看完几份真实落地案例后整理的原则，也踩中了草案自己的安全建议：

1. 只读优先。第一批工具只做查询、检索、状态读取。风险最低、见效最快，还能顺手验证 schema 写得对不对。
2. 一切不可逆动作留给人。花钱、发消息、改购物车、提交申请：工具最多做到“预填 + 滚动到表单 + 把焦点交还用户”，绝不自动提交。有团队用自定义事件做预填，由人按下最后那个按钮——这个模式值得抄。
3. 描述写给智能体看，不是写给 PM 看。description 要说清能做什么、不能做什么、返回什么；Schema 里的 description 要说清字段的取值语义。模糊描述等于让模型猜，又退回到“猜界面”的老路。
4. 永远不要暴露管理功能或他人数据。工具跑在用户的登录会话里，权限边界必须由服务端照常校验，不能因为“是工具调用的”就放松。
5. 复用页面已有逻辑。工具只是把页面本来就会做的事换个入口，别另起一套状态机，否则两边迟早不一致。
6. 给视觉反馈。智能体操作时用 CSS 伪类标出正在填写的字段，让人始终知道发生了什么、随时能接管。

四、别把 WebMCP 当流量玩法，也别拿它替代后端

这里要泼一盆冷水。截至目前，WebMCP 仍是 Community Group 草案，不是 W3C 正式推荐标准：Chrome 149 / Edge 150 处于 origin trial，ChatGPT Desktop 支持、Brave Leo 实验性支持，Firefox 和 Safari 只提交了 standards position、尚未承诺。API 还可能改，草案里连声明式表单都还没完全定稿。也没有任何证据表明它影响搜索排名。

所以正确的定位是“准备，而不是重建”。一个站点可以有三条通道，各管各的：

• llms.txt / 公开端点：给压根不会打开页面的智能体（邮件、语音、定时任务）一个受控入口；
• 后端 MCP Server：给终端、IDE、聊天客户端里的智能体，跑在你自己的基础设施上；
• WebMCP：给此刻停在页面里的浏览器智能体，复用当前会话和 UI 状态。

三条互补，不要互相替代。当前阶段花一个下午注册一个只读工具做实验就够了，别把整个前端架构押在一份还在改的草案上。

五、真正会长期值钱的东西：语义层

我觉得这波变化里最值得前端人高兴的一点是：那些“老派基本功”重新变成了核心竞争力。要让智能体可靠地操作页面，你需要真实的 <form> 和 <button> 而不是可点击的图片、每个字段有可见 label、错误信息用文字说明、价格和库存写在 HTML 里而不是塞进图片、危险操作前有明确确认步骤。这些东西同时服务于无障碍读屏、搜索引擎爬虫和 AI 智能体——一套语义，三类读者。

另一头，工具链也在往“设计意图”上补：GrapesJS 的 @grapesjs/webmcp 把可视化编辑器的组件、样式、区块直接暴露成工具，让智能体别再靠截图绕路；Vercel Labs 的 wterm 让页面内终端支持 WebMCP；开源的 Open Design Agent Kit 则把设计 Playbook 接进 Claude Code、Cursor 这类编程助手，专门解决“AI 写的功能能跑但长得丑”。生成式 UI 的下一个瓶颈，显然已经不是“能不能生成”，而是生成出来的东西是否遵守你的设计系统。

写在最后

过去二十年，前端的接口对象是 DOM 和设计稿；现在多了一类调用者，它不关心像素，只关心“这个页面能做什么、参数是什么、结果长什么样”。这不意味着要重写一切，恰恰相反——它把语义化 HTML、清晰的组件边界、可描述的状态、明确的确认流程这些基本功，重新推到了台前。

先给站点加一个只读工具，安静降级，观察它被调用了多少次。等标准稳定、浏览器铺开时，你会比别人早一步知道自己的界面在机器眼里到底是什么样子。

参考与延伸阅读（均为 2026 年 10—11 月公开资料）：W3C WebML CG 的 WebMCP 草案与 Chrome 官方 origin trial 说明；GrapesJS《Introducing GrapesJS WebMCP》；dev.to UnlockLive 的 WebMCP 实战记录；Chrome WebMCP 工具安全指南；Vercel AI SDK 发布记录。本文观点与代码为作者整理，草案 API 仍可能变动，落地前请以官方最新规范为准。