2026年2月，谷歌Chrome 146版预览版正式引入WebMCP协议，AI Agent无需模拟人类点击和视觉识别，便可直接通过API与网页内核对话。同一时期，BrowserUse发布了专为网页代理场景优化的自研大模型BU-30B-A3B-Preview，以1美元完成约200个浏览器任务的经济性，将Web Agent的规模化落地门槛降至前所未有的水平。而在国内前端社区，OpenTiny等方案已将WebMCP与WebSkills结合，给出了从概念到工程的完整落地路径。
这三股力量------WebMCP、WebSkills、WebAgent------正从不同维度重塑前端智能化的技术版图。然而，孤立地理解任何一个，都难以看清全貌。本文尝试用一套统一的三层架构，串联起这三个概念，探讨它们在真实前端工程中的协同方式与落地路径。
一、传统痛点：Agent为何在Web端"水土不服"
在WebMCP出现之前，AI Agent与网页交互的方式极为原始：截屏识别按钮位置、模拟鼠标点击、解析DOM树猜测元素含义。这种方法存在三个致命缺陷。
首先是成本问题。 一次简单的网页搜索，Agent可能需要消耗数千个Token来处理截图和解析HTML。传统浏览器自动化工具向AI传递信息时，会产生大量冗余上下文------一个普通网页的完整DOM信息，往往掺杂着大量布局脚手架、装饰性包装和重复的导航结构，这些噪声从机器推理的角度看几乎没有价值。
其次是稳定性问题。 当网站改版时，AI Agent可能因找不到特定按钮而彻底"瘫痪"。依赖视觉特征和XPath定位的方式，对页面结构的微小变化极为敏感。
更深层的则是表达力问题。 当前的Web应用是为人类视觉交互设计的，其HTML结构承载了大量隐式语义------开发者通过视觉排版传达信息层次，通过颜色和位置暗示元素的优先级。但这些对人类有效的设计，对AI来说几乎不可见。Agent无法区分一个<div class="btn">和一个<button>的语义差异，也无法通过<main>标签定位主内容区域。
这三重困境，指向同一个结论：要让AI真正理解并操作Web应用，我们需要为机器重新设计一套"界面语言"。
二、三层架构：WebMCP + WebSkills + WebAgent
从工程视角看，一套完整的Web前端智能化方案，可以抽象为三个层次：
-
协议层：定义AI与Web应用的通信规范，解决"怎么对话"的问题。
-
知识层：将领域经验、框架最佳实践和业务规则编码为机器可读的结构，解决"应该做什么"的问题。
-
执行层：将AI的决策转化为浏览器中的具体操作，解决"如何做到"的问题。
WebMCP、WebSkills和WebAgent恰好对应这三个层次。
2.1 协议层：WebMCP------从"视觉模拟"到"逻辑直连"
WebMCP是Model Context Protocol在Web端的延伸。传统MCP（由Anthropic于2024年11月发布）定义了AI模型与外部数据源、工具和服务之间的通信标准，通过JSON-RPC协议在安全的客户端-服务器架构中运行。
WebMCP的核心创新在于：让网页自身成为一个MCP服务器 。一个实现WebMCP的页面，会暴露一份能力清单（manifest），其中描述该页面支持哪些操作、可读取哪些数据、输入输出分别遵循什么结构。AI Agent在执行任务前先查询这份清单，然后通过navigator.modelContext API直接调用页面暴露的工具，无需解析HTML或识别视觉元素。
WebMCP提供了两种接入方式：
-
声明性API：直接在HTML表单中定义标准操作，适合表单提交、数据查询等常规交互。
-
命令式API ：通过JavaScript执行更复杂的动态交互，满足高级业务场景的需求-64。
可以这样理解WebMCP的价值：它相当于为网页的每个功能点都开了一个"API接口"。以往AI需要通过"看"和"猜"来操作网页，现在它可以直接"调用"网页的功能。这种转变，将Agent与网页的交互成本从Token密集型降至结构化的轻量级调用。
WebMCP的另一个关键特性是动态性。传统MCP工具运行在服务器端，是持久存在的；而WebMCP工具随页面的生命周期开启和关闭，一个页面只有在被加载后才能提供其工具能力。这种设计更符合Web应用的动态特性，但也带来了新的工程挑战------当AI调用的工具对应页面尚未加载时，系统需要自动完成路由跳转并等待页面就绪。
2.2 知识层：WebSkills------当"经验"变成"机器可读的结构"
如果说WebMCP解决的是AI与网页"如何通信"的问题，那么WebSkills解决的则是AI"应该按照什么原则来思考"的问题。
Skills并非传统意义上的代码库或npm包，而是一套专为AI编程代理设计的"结构化开发指南"。它将前端开发经验、框架最佳实践与任务分解逻辑进行标准化封装，使AI能够更精准地理解、推理并生成符合React或Vue生态规范的代码。
更具体地说，Skills将隐性的开发经验------比如"在Vue 3中如何正确实现双向绑定""在React中如何安全地管理异步状态"------转化为结构化的、机器可解析的元信息契约。每个Skill包含意图描述、输入约束、输出契约、框架版本适配标记以及典型反例警示。
Skills的核心设计思想与Web模块化异曲同工。传统Web开发中，我们将复杂系统拆解为用户认证、支付网关、日志服务等独立模块；在AI应用开发中，Skills将AI能力拆解为可复用、可组合的"专业工具"。如果开发者熟悉微服务架构或组件化开发，那么理解Skills只是认知平移。
在WebMCP+WebSkills的融合方案中，Skills扮演了"知识增强层"的角色：当AI通过WebMCP调用某个页面工具时，WebSkills为其提供该工具的使用规范、边界条件和错误处理模式，帮助AI更安全、更精准地完成任务。一个典型的实现方式是在前端工程中维护skills目录，存放Markdown格式的Skill定义文件，AI通过上下文检索获取相关知识-14。
2.3 执行层：WebAgent------浏览器中的"执行引擎"
协议的标准化（WebMCP）和知识的结构化（WebSkills），最终都需要一个执行载体来落地。这就是WebAgent层的作用。
WebAgent是一个运行在浏览器端的AI代理，它通过WebMCP协议与页面工具通信，同时利用WebSkills提供的知识库来指导行为决策。与传统后端Agent不同，WebAgent更擅长理解当前页面的真实状态、直接操作复杂UI组件、处理路由内的交互细节-61。
BrowserUse是目前最具代表性的WebAgent实现之一。它基于Playwright构建，通过大模型动态决策替代传统的固定脚本，让Agent能够自主完成登录、表单填写、流程执行等复杂任务-59。其核心执行循环包含三个步骤：观察当前页面状态、决策下一步动作、执行操作并进入下一轮循环-59。
2026年初，Vercel发布的Agent Browser则从另一个方向切入------它是一款专为AI代理设计的浏览器自动化CLI工具，无需安装驱动或配置复杂依赖，安装即可用。其数据结构经过深度优化，可减少高达93%的无关上下文，大幅提升AI的推理效率和操作准确性-68。
值得一提的是，WebAgent并不一定需要独立部署。OpenTiny的实践方案将WebMCP、WebSkills和WebAgent集成到同一个前端工程中：通过@opentiny/next-sdk提供WebMCP Server能力，通过@opentiny/next-remoter提供AI对话面板（集成LLM、MCP和Skills），最终形成完整的智能化闭环-14。
2.4 三层的协作关系
三层架构之间并非简单的依赖关系，而是相互赋能、互为增强。
从信息流向看：用户通过自然语言向WebAgent发出指令 → WebAgent参考WebSkills知识库理解任务约束 → 通过WebMCP协议调用页面工具 → 页面执行业务逻辑并返回结果。
从能力边界看：WebAgent负责"感知+决策"，WebMCP负责"通信+调用"，WebSkills负责"知识+规则"。三层各自独立演进，又通过标准化的接口相互衔接，这正是"关注点分离"原则在AI工程化中的体现。
从工程实践看，这三层可以按需组合。一个简单场景可能只需要WebMCP提供工具调用能力；复杂业务则需要WebSkills来沉淀领域知识；而要实现端到端的自动化闭环，则需要WebAgent作为执行大脑。
三、实践落地：从概念到工程
3.1 基础设施准备
实现WebMCP+WebSkills+WebAgent的融合方案，需要以下基础条件：
WebMCP能力 。目前Chrome 146及以上版本通过开启特定flag即可支持WebMCP预览版-12。开发者需要在应用中注册MCP Server，通过navigator.modelContext API暴露页面工具。
Skills知识库 。Skills通常以Markdown文件形式存放在项目的/skills目录下，每个Skill文件包含场景描述、输入输出契约和示例代码。AI在执行任务时，通过检索增强生成（RAG）的方式获取相关Skill知识。
Agent运行时 。可以选择BrowserUse、Vercel Agent Browser等开源方案，也可以使用OpenTiny提供的TinyRemoter组件快速集成对话面板和Agent能力-14。
3.2 典型应用场景
场景一：企业后台的智能助手
在企业级后台系统中，用户经常需要在多个页面间跳转执行复杂操作------例如查询某商品的价格保护政策，然后跳转到申请页面提交工单。传统方式下，用户需要手动切换页面、填写表单、提交申请。
基于WebMCP+WebSkills+WebAgent的方案，可以实现如下流程：用户通过对话面板输入自然语言指令 → WebAgent解析意图 → 调用WebMCP暴露的商品查询工具获取数据 → 参考WebSkills知识库中关于"价保申请"的业务规则 → 自动调用页面导航工具跳转到申请页面并完成工单提交-14。
Page Tool Bridge机制确保了跨页面调用的可靠性：当工具对应的页面未加载时，系统自动完成路由跳转，待页面就绪后发送工具调用消息-14。
场景二：AI驱动的UI自动化测试
传统的UI自动化测试依赖固定脚本，页面结构变化就会导致测试失败。BrowserUse的出现改变了这一局面：测试工程师只需用自然语言描述测试目标，AI Agent就能自主完成探索和验证-59。
配合WebMCP，Agent可以直接调用页面的结构化工具而非模拟点击，测试的稳定性和执行效率大幅提升。WebSkills则可用于沉淀测试用例的设计规范和断言规则，使AI生成的测试逻辑更符合业务预期。
场景三：前端开发中的智能代码生成
Skills的原始定义本身就是面向AI编程代理的。当AI需要生成符合Vue或React规范的组件代码时，通过检索相关的Skills知识库，它可以获得框架最佳实践的精准指引，而非依赖泛化的代码模板-22。
四、挑战与展望
尽管WebMCP+WebSkills+WebAgent的架构展现出广阔前景，但将其落地到生产环境仍面临诸多挑战。
WebMCP的生态成熟度。 目前WebMCP仍处于早期预览阶段，Chrome 146以上版本需要手动开启flag才能体验。更大规模的浏览器厂商支持、更完善的SDK生态，仍需时间培育。
Skills的标准化问题。 Skills目前主要依赖各社区的自主定义，缺乏统一规范。不同前端框架、不同业务领域的Skill定义方式差异较大，这给跨项目复用带来了挑战。
WebAgent的安全与合规。 当AI Agent能够直接调用网页API时，权限管理和操作审计变得尤为重要。需要建立细粒度的授权机制，确保AI只能在用户授权范围内执行操作。
从更长远的角度看，WebMCP+WebSkills+WebAgent的三层架构，揭示了一个更根本的趋势：Web应用正在从"为人类设计的界面"演变为"人机共用的交互平台"。WebMCP提供了机器可读的操作接口，WebSkills沉淀了领域知识，WebAgent则充当了人类与机器之间的智能桥梁。
正如WebMCP项目所言，其目标是成为AI应用领域的"USB-C接口"------一个标准化的连接协议，让不同AI模型、不同Web应用能够无缝协作-64。当这一愿景实现时，Web端的前端智能化将不再是少数先锋者的实验场，而成为每一个前端开发者的日常工具箱。
写在最后
WebMCP、WebSkills和WebAgent并非彼此替代的关系，而是从协议、知识、执行三个维度共同构成了一套完整的前端智能化解决方案。对于前端开发者而言，这既是一次技术挑战，更是一次思维升级------我们不再仅仅是"为人类写界面"的工程师，更是"为AI设计交互"的架构师。
未来的Web应用，既要有漂亮的人类界面，也要有清晰的机器接口。而WebMCP、WebSkills与WebAgent，正是帮助我们搭建这座"人机桥梁"的三根支柱。