浏览器开始原生支持 AI 操作页面：WebMCP 如何补齐智能体“最后一公里

一、问题的起点：AI 操作浏览器为什么一直很难

在智能体技术快速演进的这几年，写代码、读代码、生成测试用例等任务的能力提升非常明显，但一旦涉及“操作浏览器完成真实流程”，难度会立刻上升一个量级。原因并不在于模型不理解页面，而在于页面并没有为模型提供可稳定调用的入口。

传统做法通常依赖几条路径：

1. 读取 HTML 源码，让模型自行推断页面结构；
2. 结合截图、坐标定位和元素树进行视觉理解；
3. 通过脚本注入方式尝试点击、输入、滚动等操作。

这些方式都有明显缺陷。HTML 是给浏览器渲染和人类阅读准备的，不是为了被智能体调用而设计的。现代前端页面大量依赖脚本动态生成内容，DOM 结构复杂、状态变化频繁，截图识别又受分辨率、主题、弹窗、动画和网络延迟影响。模型常常需要多轮尝试才能完成一次简单操作，不仅速度慢，而且 token 消耗极大。

换句话说，过去智能体操作浏览器，是在“观察并猜测”，而不是在“调用接口”。

二、WebMCP 要解决的问题

WebMCP 的核心思路非常直接：让网页在运行过程中，主动向浏览器注册一组可供智能体调用的工具接口。

这里的“工具”不是面向人类用户的按钮，而是面向 AI 的结构化能力描述。页面通过脚本声明：

• 工具名称；
• 工具用途；
• 参数结构；
• 执行逻辑；
• 返回结果。

这样，智能体就不再需要理解某个按钮在哪、某个表单如何填写、某个操作需要点击几次。只要页面提供了对应工具，智能体就可以像调用函数一样完成任务。

可以把这个过程理解为：网页从“被观察的对象”变成了“可协作的执行体”。

三、机制拆解：页面如何把能力交给 AI

从技术实现角度看，WebMCP 的交互链条大致如下：

1. 页面加载后，脚本向浏览器注册工具；
2. 浏览器维护当前页面的可用工具列表；
3. 智能体通过浏览器获取工具描述；
4. 智能体根据任务选择合适工具；
5. 页面执行工具逻辑；
6. 页面返回结构化结果。

这里的关键变化在于，智能体拿到的不再是模糊的页面信息，而是一份清晰的能力清单。清单中包含参数类型、必填项、返回结构等约束，模型可以直接生成有效调用。

例如，一个待办事项页面可以主动注册添加任务的能力：

await document.modelContext.registerTool({
  name: "add_todo",
  description: "在当前页面的待办事项列表中添加一个新项目。",
  inputSchema: {
    type: "object",
    properties: {
      text: {
        type: "string",
        description: "待办事项的条目是什么"
      }
    },
    required: ["text"]
  },
  execute: async ({ text }) => {
    addTodoToPage(text);
    return {
      success: true,
      message: `已经添加待办事项：${text}`
    };
  }
});

在这个例子中，页面不仅告诉了 AI“可以添加待办事项”，还明确说明了需要什么参数、执行后返回什么。模型不需要知道按钮位置，也不需要理解页面布局。

四、为什么这对智能体意义重大

过去，很多智能体操作浏览器的失败，并不是因为模型能力不够，而是因为信息损失和高不确定性叠加在一起。

WebMCP 改变了这种局面。它把页面交互从“感知问题”变成了“接口调用问题”。这不是小的优化，而是交互模式的转变。

具体收益包括：

1. 调用确定性大幅提升

智能体知道当前页面支持哪些操作，也知道每个操作需要什么参数。这消除了大量猜测过程，使执行结果更可预期。

2. 执行链路更短

不再需要截图、分析图片、定位元素、试错点击。模型可以直接生成工具调用请求，节省多轮推理时间。

3. 资源消耗下降

相比反复读取 DOM 和图像信息，结构化工具调用的 token 开销更低，响应速度更快。

4. 更容易与业务系统对齐

页面开发者可以直接把内部业务能力转化为 AI 可调用工具，确保智能体的行为符合业务规则，而不是自由发挥。

五、前端开发的新增量

WebMCP 的普及会给前端开发带来一类新的工作内容：为页面设计 AI 可用的能力接口。

这并不意味着每个页面都要暴露所有功能。相反，合理的做法是根据页面定位和用户场景，选择最适合智能体调用的高频操作。

前端开发者需要关注几个方面：

1. 明确哪些能力适合开放；
2. 设计清晰的工具名称和描述；
3. 定义严谨的参数结构和返回格式；
4. 控制权限边界，避免危险操作被误触发。

这类工作与设计开放 API 有相似之处，但服务对象从“外部系统”变成了“智能体”。

六、尚不成熟的现实

需要明确的是，目前这一能力仍处于早期阶段。许多实现还依赖实验性开关，接口规范也未完全稳定。要在生产环境中大规模使用，还需要解决一系列问题：

• 权限模型如何设计；
• 跨页面、跨站点调用如何管理；
• 版本兼容如何保障；
• 工具发现机制如何标准化；
• 安全审计如何落地。

因此，说“AI 已经可以完全接管所有编程工作”仍然不够准确。更准确的说法是：浏览器正在为智能体提供一种更可靠的页面操作路径，这补上了过去自动化流程中非常薄弱的一环。

七、对开发者的实际建议

如果是前端开发者，现在可以关注但不急于全面改造现有项目。更合理的方式是：

• 跟踪相关规范草案的演进；
• 在内部工具或测试页面中做小范围验证；
• 总结哪些页面能力最适合以工具形式暴露；
• 关注权限控制与安全边界的设计实践。

如果是后端或全栈开发者，也需要理解这一趋势对自动化测试、数据采集、流程机器人等场景的潜在影响。未来，大量原本需要人工操作浏览器的流程，可能转由智能体通过页面能力接口直接完成。

八、从“观察页面”到“调用页面”

WebMCP 的出现并不意味着所有问题都解决了，它更像是一个重要信号：网页不再只是给人看的内容载体，也在逐步成为可被智能体程序化使用的服务端点。

对于智能编程和自动化领域而言，这补上了相当关键的一环。过去，代码生成可以完成，但执行层始终受制于环境交互能力。现在，浏览器开始原生支持面向 AI 的能力暴露，整个链条变得更加完整。

这也许不能立刻让智能体接管所有编程工作，但它确实让“AI 操作真实系统”的距离，缩短了一大步。