OpenTiny NEXT系列直播学习与实践全景解析
第一篇：理论基础篇——AI Agent与Web应用的连接困局
第一章：从大模型到智能体：理解AI Agent的本质
1.1 大模型的“能说不能做”困境
大语言模型的出现无疑是人类技术史上的里程碑。GPT系列、Claude、文心一言、通义千问等模型展现出了惊人的语言理解和生成能力。然而，当我们试图将这些模型应用于实际的Web应用开发时，一个根本性的矛盾浮出水面：
大模型是“大脑”，但缺少“手脚”。
传统的LLM只能进行文本输入和文本输出，它们被困在对话框的牢笼中。即使是最先进的模型，也无法直接操作DOM元素、无法读取用户的浏览器状态、无法与现有的前端组件库进行交互。这种“能说不能做”的困境，成为LLM从“玩具”走向“工具”的最大障碍。
在OpenTiny NEXT系列直播的第一讲中，主讲人用一个生动的比喻揭示了这一困境：
“现在的AI就像是一个被蒙住眼睛的专家，它拥有丰富的知识，却看不见你的界面，摸不到你的按钮。它只能通过文字与你交流，却无法真正帮你完成任何操作。”
这种困境在前端开发领域尤为明显。当我们希望AI能够辅助开发、自动生成界面、智能操作组件时，仅仅依靠文本对话是远远不够的。
1.2 AI Agent的概念与核心能力
AI Agent（智能体）概念的提出，正是为了解决“能说不能做”的困局。一个完整的AI Agent应当具备以下核心能力：
-
感知能力：能够理解当前环境的状态（用户的浏览器界面、页面结构、组件状态）
-
规划能力：能够将复杂任务分解为可执行的步骤序列
-
行动能力：能够实际执行操作（点击按钮、填写表单、导航页面）
-
记忆能力：能够记住历史交互和上下文信息
-
反思能力：能够评估行动结果并调整策略
在Web应用场景下，一个真正的AI Agent应该像一名人类用户一样，能够“看到”界面、“理解”功能、“操作”组件、“完成”任务。
1.3 智能体与Web应用之间的“鸿沟”
尽管AI Agent的概念令人兴奋，但当我们试图将其落地到Web应用时，却发现了一条难以逾越的鸿沟：
鸿沟一：感知鸿沟
Web应用的界面是动态的、可视化的，而AI只能处理文本。如何让AI“看见”界面？如何将DOM结构、样式信息、组件状态转化为AI可以理解的语言？
鸿沟二：行动鸿沟
AI无法直接操作浏览器。如何让AI能够“点击”按钮、“填写”输入框、“滚动”页面？这需要建立一套AI可以调用的操作接口。
鸿沟三：语义鸿沟
即使AI能够获取DOM树，它也无法理解每个组件的业务含义。一个<button>标签可能代表“提交”、“取消”、“删除”等完全不同的操作。如何让AI理解组件的语义？
鸿沟四：上下文鸿沟
Web应用的状态是瞬时的、有状态的。AI需要理解当前页面所处的状态、用户的操作历史、组件间的数据流动，才能做出正确的决策。
这四大鸿沟，构成了智能体与Web应用融合的核心挑战。
第二章：MCP的启示——模型上下文协议
2.1 什么是MCP
MCP（Model Context Protocol，模型上下文协议）是由Anthropic提出的一种标准化协议，旨在为AI模型提供统一的工具调用和数据访问接口。MCP的核心思想是：将AI的能力扩展从“模型内部”转移到“协议层面”，通过标准化的接口让模型能够与外部世界进行交互。
MCP定义了三个核心概念：
-
Resources（资源）：AI可以读取的数据源，如文件、数据库、API返回
-
Tools（工具）：AI可以调用的函数，如执行操作、发送请求
-
Prompts（提示模板）：预定义的提示词模板，用于引导模型行为
MCP的出现，为AI Agent与外部世界的连接提供了一套标准化的“插座”。任何遵循MCP协议的服务器，都可以被AI Agent发现、理解和使用。
2.2 MCP在Web场景下的局限性
然而，MCP最初的设计目标并非针对Web应用。它更适用于后端场景，如文件系统、数据库、API服务等。当我们将MCP应用于前端Web场景时，它的局限性暴露无遗：
-
缺乏对DOM的理解：MCP的Tool定义是函数式的，无法描述Web组件的结构、属性、事件
-
无状态性：MCP的每次调用都是独立的，难以维护会话上下文
-
忽略UI语义：MCP无法表达按钮、表单、列表等UI元素的语义信息
-
缺少可视化感知：MCP只能处理结构化数据，无法让AI“看到”界面
这意味着，我们需要在MCP的基础上，构建一层专门针对Web场景的连接范式——这就是WebMCP诞生的背景。
第三章：WebMCP的提出——专为Web定制的连接范式
3.1 WebMCP的核心思想
WebMCP（Web Model Context Protocol）是在MCP的基础上，针对Web应用场景进行扩展和优化的连接协议。它的核心思想是：
将Web应用的组件树、状态、事件、语义等信息，以AI可理解、可操作的方式暴露出来。
WebMCP不是要取代MCP，而是MCP在Web领域的“方言”——它继承MCP的核心理念，但针对Web的特殊性进行了专门设计。
3.2 WebMCP的三层架构
在OpenTiny NEXT系列直播中，讲师详细剖析了WebMCP的三层架构：
第一层：视图层感知（View Perception）
这一层负责将Web应用的DOM树、组件树、样式信息、可视区域等转化为AI可理解的结构化描述。主要包括：
-
DOM语义化：将DOM节点映射为具有业务含义的组件描述
-
组件树提取：对于使用组件库（如TinyVue）的应用，提取组件树结构
-
可访问性增强：利用ARIA属性等增强语义信息
-
可视区域描述：描述当前可见区域的布局、焦点元素等
第二层：能力暴露层（Capability Exposure）
这一层负责将Web应用的可交互元素（按钮、输入框、表单等）暴露为AI可调用的工具（Tools）。主要包括：
-
组件动作映射：将组件的操作（点击、输入、选择）映射为Tool函数
-
事件监听：监听组件事件，将结果反馈给AI
-
状态同步：将组件的状态（值、禁用、可见性）同步给AI
第三层：交互执行层（Interaction Execution）
这一层负责执行AI发起的操作指令，并将执行结果反馈给AI。主要包括：
-
动作执行器：实际执行DOM操作或组件方法调用
-
结果反馈：将操作结果（成功/失败、返回值、新状态）返回给AI
-
错误处理：处理操作异常，提供错误信息供AI调整策略
通过这三层架构，WebMCP成功地将一个静态的Web页面，转化为一个AI可以“感知”和“操作”的智能体环境。
3.3 WebMCP的数据格式设计
为了实现AI与Web应用的高效交互，WebMCP定义了一套专门的数据格式。以下是一个典型的WebMCP视图描述示例：
json
{
"type": "webpage",
"url": "https://example.com/form",
"title": "用户注册表单",
"components": [
{
"id": "name-input",
"type": "Input",
"label": "姓名",
"value": "",
"placeholder": "请输入姓名",
"required": true,
"actions": ["setValue", "clear", "focus"]
},
{
"id": "email-input",
"type": "Input",
"label": "邮箱",
"value": "",
"placeholder": "example@domain.com",
"required": true,
"validation": "email",
"actions": ["setValue", "clear", "focus"]
},
{
"id": "submit-btn",
"type": "Button",
"label": "提交注册",
"variant": "primary",
"disabled": false,
"actions": ["click"]
}
],
"layout": "vertical-form",
"focus": "name-input"
}
这种结构化的描述，让AI能够像人类一样“理解”页面的组成、每个组件的用途、可执行的操作，以及当前的状态。
第二篇：核心范式篇——WebMCP在OpenTiny中的实践
第四章：WebSkills——能力封装的最佳实践
4.1 从工具到技能：WebSkills的设计哲学
在WebMCP的架构中，每一个可交互的组件都被暴露为一个“工具”。然而，仅仅有工具是不够的——AI需要知道“何时”使用“哪个”工具，以及如何组合使用多个工具来完成复杂任务。
这就是WebSkills（网络技能）要解决的问题。WebSkills是对WebMCP Tools的进一步封装，它将一组相关的工具组合成一个“技能”，并附带使用说明、适用场景、限制条件等元信息。
在OpenTiny NEXT的实战分享中，讲师将WebSkills比作“给AI的说明书”：
“Tools是零件，Skills是组装好的模块。当AI需要完成一个任务时，它不是在零件箱里翻找，而是直接拿起一个技能模块，按照说明书来使用。”
4.2 设计一个典型的WebSkill：表单填写技能
以“表单填写”为例，我们可以设计一个WebSkill，它包含以下内容：
-
技能名称：FormFiller
-
适用场景：当页面包含表单，且用户意图是填写并提交表单时
-
依赖工具：
getFormFields、setFieldValue、validateField、submitForm -
使用流程：
-
调用
getFormFields获取所有表单字段及其要求 -
根据用户输入或上下文，为每个字段生成值
-
逐个调用
setFieldValue填充字段 -
调用
validateField检查每个字段的有效性 -
如果全部有效，调用
submitForm提交 -
返回提交结果
-
-
限制条件：不支持文件上传类型的表单
通过这样的技能封装，AI无需理解每个工具的底层实现，只需按照技能描述来执行即可。这大大降低了AI执行复杂任务的认知负担。
4.3 WebSkills的注册与发现机制
为了实现WebSkills的动态注册和发现，OpenTiny设计了一套基于Manifest（清单）的机制：
json
{
"skillName": "FormFiller",
"version": "1.0.0",
"description": "智能表单填写技能",
"triggers": ["填写表单", "提交表单", "注册", "登录"],
"requiredTools": ["getFormFields", "setFieldValue", ...],
"examples": [
{
"userInput": "帮我填写这个注册表单，姓名张三，邮箱zhang@example.com",
"executionSteps": [...]
}
]
}
AI在启动时，会加载当前页面支持的所有WebSkills，并根据用户的意图匹配合适的技能。这种机制让AI能够“因地制宜”地选择能力，而不是盲目地调用工具。
第五章：WebAgent——智能体的落地形态
5.1 WebAgent的架构设计
WebAgent是运行在浏览器中的AI智能体，它集成了WebMCP协议和WebSkills能力，能够理解用户的自然语言指令，并自动执行相应的操作。
WebAgent的典型架构包含以下模块：
-
意图理解模块：分析用户输入，识别任务类型和关键参数
-
技能匹配模块：根据意图匹配合适的WebSkill
-
执行规划模块：将任务分解为一系列步骤
-
工具调用模块：通过WebMCP调用具体的组件操作
-
状态感知模块：持续监控页面状态，为决策提供依据
-
反馈生成模块：将执行结果转化为自然语言反馈给用户
5.2 WebAgent的工作流程
以一个实际场景为例：用户打开一个电商网站，对WebAgent说：“帮我筛选出价格在100-200元之间的商品，并按销量排序。”
WebAgent的工作流程如下：
步骤1：意图理解
-
任务类型：商品筛选
-
关键参数：价格区间[100,200]、排序方式“销量”
步骤2：技能匹配
-
匹配到“ProductFilter”技能
步骤3：页面感知
-
通过WebMCP获取当前页面的组件结构，发现存在“价格滑块”、“排序下拉框”、“筛选按钮”等组件
步骤4：规划执行
-
规划序列：
-
将价格滑块的低值设为100，高值设为200
-
点击排序下拉框，选择“按销量排序”
-
点击“筛选”按钮
-
等待结果加载
-
步骤5：执行与反馈
-
依次调用对应的Tool执行操作
-
监控页面变化，确认筛选结果已更新
-
向用户反馈：“已为您筛选出12件商品，已按销量排序”
5.3 WebAgent的状态管理与记忆
在实际运行中，WebAgent需要维护会话状态和历史记忆。OpenTiny实现了一套轻量级的状态管理机制：
-
短期记忆：存储当前会话的交互历史、最近执行的操作、页面状态快照
-
长期记忆：存储用户的偏好、历史任务完成情况等（通过localStorage或云端）
-
任务记忆：对于多步骤任务，存储中间结果和已完成步骤
这种记忆机制让WebAgent能够处理复杂的多轮对话场景，而不是每次交互都从零开始。
第六章：WebMCP + WebSkills + WebAgent = 前端智能化三驾马车
通过前面的分析，我们可以看到，WebMCP、WebSkills、WebAgent三者构成了前端智能化的完整技术栈：
-
WebMCP：提供了AI与Web应用之间的“通信协议”和“数据格式”
-
WebSkills：提供了能力封装和“使用说明书”
-
WebAgent：提供了智能体的“大脑”和“执行器”
这三者相辅相成，缺一不可。没有WebMCP，AI无法感知和操作页面；没有WebSkills，AI不知道如何组合工具完成任务；没有WebAgent，整个体系缺少执行和决策的中心。
在OpenTiny NEXT系列直播中，讲师用一个形象的比喻总结了三者的关系：
“WebMCP是神经系统，WebSkills是肌肉记忆，WebAgent是大脑。神经系统传递信号，肌肉记忆提供动作模式，大脑做出决策。”
第三篇：交互革命篇——生成式UI重构对话交互
第七章：GenUI的概念与演进
7.1 从GUI到CUI再到GenUI
人机交互的演进，大致经历了三个阶段：
GUI（图形用户界面）：用户通过鼠标、键盘操作界面元素，界面是静态的、预定义的。
CUI（对话式用户界面）：用户通过自然语言与系统交互，系统以文本或语音回复。ChatGPT、Siri等都是CUI的典型代表。
GenUI（生成式用户界面）：在对话的基础上，系统能够动态生成UI组件，提供比纯文本更丰富、更直观的交互方式。
GenUI的核心思想是：让AI成为UI的生成器，根据对话上下文和用户意图，实时生成最适合当前任务的界面。
7.2 GenUI的三种生成模式
在OpenTiny的GenUI实践中，总结了三种主要的生成模式：
模式一：内联组件生成
在对话流中动态插入UI组件，如按钮、表单、卡片等。例如：
用户：“我想预订明天上午10点的会议室。”
AI：（生成一个会议室预订表单组件，内嵌在对话中）
用户：（填写并提交表单）
这种模式下，UI是对话的延伸，用户无需跳出对话即可完成操作。
模式二：全屏界面生成
当任务复杂度较高时，AI可以生成一个完整的界面（如仪表盘、编辑器、配置面板）。例如：
用户：“帮我创建一个数据分析仪表盘，展示销售数据。”
AI：（生成一个包含图表、筛选器、表格的完整界面）
用户：（在界面中进行深度操作）
这种模式下，AI承担了部分前端开发的工作，将用户的意图直接转化为可交互的应用。
模式三：混合模式
结合内联和全屏两种模式，根据任务的不同阶段动态切换。例如，先通过内联组件收集关键信息，然后生成全屏界面进行深度操作。
7.3 GenUI的技术实现
实现GenUI需要解决三个核心问题：
-
组件库的AI可理解性：AI需要知道有哪些组件可用、每个组件的属性和事件、组件的使用场景。这正是TinyVue Skill要解决的问题。
-
布局的智能生成：AI需要根据用户意图，决定如何布局组件。这需要结合设计系统（如TinyTheme）和布局算法。
-
状态的动态绑定：生成的UI需要与AI的后台逻辑进行状态同步。例如，用户点击按钮后，AI需要感知并响应。
第八章：GenUI实战案例——智能表单生成器
8.1 案例背景
假设用户说：“我需要一个员工信息收集表单，包含姓名、部门、入职日期、照片上传，部门要下拉选择。”
传统的做法是：开发人员手动编写表单代码，或者使用低代码平台拖拽生成。而在GenUI的场景下，AI可以自动生成这个表单。
8.2 AI的处理流程
第一步：意图解析
AI识别出：
-
任务类型：生成表单
-
字段列表：姓名（文本）、部门（选择）、入职日期（日期）、照片上传（文件）
-
特殊要求：部门字段需要下拉选择
第二步：组件选择
AI根据TinyVue组件库的知识，选择合适的组件：
-
姓名：
<Input>组件 -
部门：
<Select>组件，选项从用户上下文或API获取 -
入职日期：
<DatePicker>组件 -
照片上传：
<Upload>组件
第三步：布局生成
AI根据设计规范，生成合理的布局（通常是垂直表单布局），并添加提交按钮。
第四步：代码生成与渲染
AI生成Vue组件代码，并在对话中动态渲染。
生成的代码可能如下：
vue
<template>
<Form :model="formData" :rules="rules" ref="formRef">
<FormItem label="姓名" prop="name">
<Input v-model="formData.name" placeholder="请输入姓名" />
</FormItem>
<FormItem label="部门" prop="department">
<Select v-model="formData.department" :options="departmentOptions" />
</FormItem>
<FormItem label="入职日期" prop="hireDate">
<DatePicker v-model="formData.hireDate" />
</FormItem>
<FormItem label="照片" prop="photo">
<Upload action="/api/upload" v-model="formData.photo" />
</FormItem>
<Button type="primary" @click="submit">提交</Button>
</Form>
</template>
<script setup>
import { ref } from 'vue'
import { Form, FormItem, Input, Select, DatePicker, Upload, Button } from '@opentiny/vue'
const formData = ref({
name: '',
department: '',
hireDate: '',
photo: ''
})
const departmentOptions = ref([
{ label: '技术部', value: 'tech' },
{ label: '市场部', value: 'marketing' },
{ label: '销售部', value: 'sales' }
])
const rules = {
name: [{ required: true, message: '请输入姓名' }],
department: [{ required: true, message: '请选择部门' }]
}
const submit = () => {
// 提交逻辑
}
</script>
第五步：交互增强
AI还可以为表单添加智能提示、实时校验、自动填充等功能，进一步提升用户体验。
8.3 GenUI的优势与挑战
优势：
-
零代码：用户无需编程即可获得定制化界面
-
动态适配：根据对话上下文实时调整UI
-
一致性：生成的UI符合设计规范
挑战：
-
精确性：AI生成的UI能否完全符合用户预期？
-
可控性：用户如何修改AI生成的UI？
-
性能：动态生成UI对性能的影响如何？
第四篇：扩展能力篇——AI-Extension让AI真的“看得到、动得了”
第九章：浏览器扩展的智能化
9.1 AI-Extension的设计目标
AI-Extension是OpenTiny推出的浏览器扩展解决方案，它旨在将AI的能力注入到任意Web页面中，让AI能够“看到”任何网站的界面，“操作”任何网站的组件。
传统的AI对话工具（如ChatGPT）只能处理文本输入输出，无法与用户当前浏览的页面进行交互。而AI-Extension通过浏览器扩展的API，实现了与页面的深度集成。
9.2 AI-Extension的核心功能
功能一：页面感知
AI-Extension能够获取当前页面的DOM结构、截图、用户选中的文本等，并将这些信息传递给AI。这让AI能够“看到”用户正在浏览的内容。
功能二：操作执行
AI-Extension能够模拟用户操作，如点击、输入、滚动、导航等。这让AI能够“动得了”页面元素。
功能三：数据提取
AI-Extension能够从页面中提取结构化数据，如表格内容、商品信息、新闻列表等，并导出为JSON、CSV等格式。
功能四：自动化任务
AI-Extension支持用户创建自动化任务，如“每天早上8点登录公司系统，下载昨天的销售报表”，让AI成为用户的“数字助理”。
9.3 AI-Extension的架构
AI-Extension采用三层架构：
-
Content Script：注入到页面中，负责与DOM交互、监听页面事件
-
Background Script：运行在扩展的后台，负责管理状态、与AI服务通信
-
Popup UI：提供用户界面，展示AI的思考过程、执行记录等
这种架构保证了AI能力与页面的安全隔离，同时提供了高效的通信机制。
9.4 实战案例：智能表单填写助手
一个典型的AI-Extension应用场景是：当用户在网上填写表单时，AI自动识别表单字段，并根据用户的历史信息或上下文自动填充。
例如，用户在注册一个新网站时，AI-Extension会自动：
-
识别出“姓名”、“邮箱”、“手机号”等字段
-
从用户存储的档案中取出对应信息
-
自动填写到表单中
-
如果用户同意，还可自动提交
这种体验极大地提升了用户填写表单的效率。
第五篇：实战落地篇——TinyRobot与AI对话组件库
第十章：TinyRobot的设计与实现
10.1 TinyRobot是什么
TinyRobot是OpenTiny推出的一套AI对话组件库，它提供了一系列开箱即用的Vue组件，帮助开发者快速构建具有AI能力的对话界面。
TinyRobot的核心组件包括：
-
ChatContainer：对话容器，管理消息列表
-
MessageBubble：消息气泡，支持文本、Markdown、组件等多种内容类型
-
InputArea：输入区域，支持文本输入、语音输入、文件上传
-
ThinkingIndicator：思考指示器，展示AI的思考过程
-
ActionButton：操作按钮，支持快捷操作建议
10.2 TinyRobot与WebAgent的集成
TinyRobot不仅是一个UI组件库，它还内置了与WebAgent的集成能力。开发者只需简单配置，即可让TinyRobot的对话界面连接到WebAgent后端，实现真正的智能对话。
集成流程如下：
-
初始化：创建TinyRobot实例，配置WebAgent的API地址
-
用户输入：用户输入消息，TinyRobot调用WebAgent的接口
-
WebAgent处理：WebAgent理解意图、规划执行、调用WebMCP操作页面
-
结果返回：WebAgent将执行结果返回给TinyRobot
-
界面更新：TinyRobot将结果渲染为消息气泡，并展示给用户
10.3 TinyRobot的应用场景
场景一：智能客服
在电商网站中嵌入TinyRobot，用户可以通过自然语言咨询商品、下单、查询订单等。WebAgent可以自动操作页面完成用户请求。
场景二：开发辅助
在低代码平台或IDE中嵌入TinyRobot，开发者可以通过对话生成页面、修改配置、调试代码。WebAgent可以自动操作编辑器完成开发任务。
场景三：办公自动化
在OA系统中嵌入TinyRobot，员工可以通过对话发起审批、预订会议室、查询日程。WebAgent可以自动操作办公系统完成流程。
第十一章：TinyRobot实战案例——智能客服机器人
11.1 需求分析
假设我们需要为一个电商网站开发一个智能客服机器人，支持以下功能：
-
商品咨询：用户询问商品信息，机器人展示商品卡片
-
下单：用户表达购买意愿，机器人引导完成下单
-
订单查询：用户查询订单状态，机器人展示订单详情
-
退换货：用户申请退换货，机器人发起流程
11.2 技术选型
-
前端框架：Vue 3 + TinyRobot组件库
-
后端：WebAgent服务 + WebMCP桥接
-
页面操作：AI-Extension（在浏览器端）
11.3 实现步骤
步骤1：集成TinyRobot
在Vue项目中安装TinyRobot，并引入组件：
vue
<template>
<ChatContainer
:messages="messages"
:onSend="handleSend"
:thinking="thinking"
/>
</template>
<script setup>
import { ref } from 'vue'
import { ChatContainer } from '@opentiny/robot'
const messages = ref([])
const thinking = ref(false)
const handleSend = async (text) => {
thinking.value = true
const response = await fetch('/api/agent', {
method: 'POST',
body: JSON.stringify({ message: text })
})
const data = await response.json()
messages.value.push({ role: 'assistant', content: data.reply })
thinking.value = false
}
</script>
步骤2：实现WebAgent逻辑
WebAgent需要处理不同类型的用户意图：
javascript
// 意图识别
const intent = await classifyIntent(userMessage)
switch(intent.type) {
case 'product_inquiry':
// 搜索商品
const products = await searchProducts(intent.keywords)
// 生成商品卡片
return generateProductCards(products)
case 'place_order':
// 调用WebMCP操作购物车
await webMCP.click('#add-to-cart')
await webMCP.click('#checkout')
return '已将商品加入购物车，请确认订单信息。'
case 'order_query':
// 获取订单列表
const orders = await fetchOrders(intent.orderId)
return generateOrderDetails(orders)
// ... 其他意图
}
步骤3：集成AI-Extension（可选）
如果希望机器人能够直接操作页面，可以在浏览器中安装AI-Extension，并通过postMessage与页面通信。
步骤4：部署与测试
完成开发后，部署到生产环境，并进行充分的测试，确保机器人能够准确理解用户意图并正确执行操作。
11.4 优化与迭代
上线后，根据用户反馈持续优化：
-
收集未处理的意图，扩充意图分类模型
-
优化商品卡片的展示效果
-
增加更多快捷操作按钮，提升交互效率
第六篇：协议实践篇——深入MCP开发
第十二章：MCP协议详解
12.1 MCP的消息格式
MCP基于JSON-RPC 2.0，定义了客户端和服务器之间的消息格式。主要有三种消息类型：
-
请求（Request）：客户端向服务器发送请求，需要响应
-
响应（Response）：服务器对请求的响应
-
通知（Notification）：单向消息，无需响应
一个典型的工具调用请求：
json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search_products",
"arguments": {
"keyword": "laptop",
"limit": 10
}
}
}
对应的响应：
json
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "找到以下商品：..."
}
]
}
}
12.2 MCP服务器的开发
开发一个MCP服务器，需要实现以下核心能力：
-
工具列表：返回服务器提供的所有工具及其描述
-
工具调用：执行具体的工具逻辑
-
资源列表：返回可访问的资源
-
资源读取：返回资源内容
以下是一个简单的MCP服务器示例（Node.js）：
javascript
import { Server } from '@modelcontextprotocol/sdk/server/index.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
const server = new Server({
name: 'example-mcp-server',
version: '1.0.0'
}, {
capabilities: {
tools: {}
}
})
// 注册工具列表
server.setRequestHandler('tools/list', async () => ({
tools: [
{
name: 'greet',
description: '打招呼',
inputSchema: {
type: 'object',
properties: {
name: { type: 'string' }
},
required: ['name']
}
}
]
}))
// 处理工具调用
server.setRequestHandler('tools/call', async (request) => {
const { name, arguments: args } = request.params
if (name === 'greet') {
return {
content: [{ type: 'text', text: `Hello, ${args.name}!` }]
}
}
throw new Error(`Unknown tool: ${name}`)
})
// 启动服务器
const transport = new StdioServerTransport()
await server.connect(transport)
12.3 MCP在OpenTiny中的实践
OpenTiny将MCP协议应用于多个场景：
-
TinyVue组件库的MCP服务器：提供组件文档、示例代码、属性说明等资源
-
TinyEngine的MCP集成：允许AI通过MCP调用低代码平台的API，进行页面创建、组件拖拽、属性配置等操作
-
TinyRobot的MCP客户端：内置MCP客户端，可以与任何MCP服务器通信，扩展AI的能力
第七篇：组件智能化篇——TinyVue Skill让AI真正懂组件库
第十三章：组件库的AI可理解性
13.1 为什么需要组件库的AI理解
在前端智能化的大背景下，组件库不再只是给人类开发者使用的工具，它也需要被AI“理解”。当AI需要生成UI、操作页面、回答组件相关问题时，它必须知道：
-
有哪些组件可用？
-
每个组件的用途是什么？
-
组件的属性有哪些，分别有什么作用？
-
组件的事件如何触发？
-
组件的使用场景和最佳实践是什么？
传统的组件文档是为人类设计的，以自然语言和代码示例为主，AI难以直接利用。我们需要一种结构化的、机器可读的组件描述方式。
13.2 TinyVue Skill的设计
TinyVue Skill是一个专门为TinyVue组件库设计的MCP技能，它将整个组件库的知识转化为AI可以理解和使用的能力。
TinyVue Skill包含以下内容：
-
组件目录：所有组件的列表，包括名称、分类、简要描述
-
组件详情：每个组件的详细说明，包括属性、事件、插槽、方法、示例
-
设计规范：颜色、字体、间距、阴影等设计token
-
使用指南：常见使用场景、组合方式、注意事项
-
代码生成模板：用于AI生成代码的模板
所有这些信息以结构化的JSON格式存储，并暴露为MCP的资源和工具。
13.3 TinyVue Skill的实践效果
通过TinyVue Skill，AI能够：
-
智能推荐组件：根据用户需求，推荐最合适的组件
-
生成组件代码：根据用户描述，生成符合TinyVue规范的代码
-
解答组件问题：回答关于组件使用的各种问题
-
自动配置组件：根据设计稿或需求，自动设置组件的属性和样式
例如，当用户说“我想要一个带搜索功能的下拉选择框”时，AI可以通过TinyVue Skill了解到，TinyVue的Select组件支持filterable属性，从而生成正确的代码。
第十四章：TinyVue Skill的实现细节
14.1 组件元数据的提取
首先，需要从TinyVue的源码中提取组件的元数据。这可以通过静态分析实现：
javascript
// 提取组件的props const props = extractProps(componentFile) // 提取events const events = extractEvents(componentFile) // 提取slots const slots = extractSlots(componentFile) // 提取methods const methods = extractMethods(componentFile)
然后，将这些元数据转换为标准格式：
json
{
"name": "Button",
"category": "通用",
"description": "按钮用于开始一个即时操作",
"props": [
{
"name": "type",
"type": "string",
"default": "default",
"options": ["primary", "success", "warning", "danger", "info"],
"description": "按钮类型"
},
{
"name": "size",
"type": "string",
"default": "medium",
"options": ["large", "medium", "small", "mini"],
"description": "按钮尺寸"
}
],
"events": [
{
"name": "click",
"description": "点击按钮时触发",
"params": ["event"]
}
],
"slots": [
{
"name": "default",
"description": "按钮内容"
}
]
}
14.2 示例代码的生成
为了让AI更好地理解如何使用组件，还需要提供丰富的示例代码。这些示例可以来自组件库的文档、demo，也可以自动生成。
例如，对于Button组件，可以提供：
javascript
// 基础用法 <Button type="primary">主要按钮</Button> // 不同尺寸 <Button size="large">大按钮</Button> <Button size="medium">中按钮</Button> <Button size="small">小按钮</Button> // 禁用状态 <Button disabled>禁用按钮</Button> // 加载状态 <Button loading>加载中</Button>
14.3 AI的提示工程
为了让AI更好地利用TinyVue Skill，需要设计合适的提示词模板。例如，当AI需要生成组件代码时，可以使用以下提示：
text
你是一个前端开发专家，使用TinyVue组件库进行开发。
请根据用户需求，生成符合TinyVue规范的Vue代码。
可用的组件及其属性如下：
{{componentMetadata}}
用户需求：{{userRequirement}}
通过这种方式，AI能够准确地生成代码。
第八篇：平台融合篇——TinyEngine低代码与AI的深度融合
第十五章：低代码平台与AI的天然契合
15.1 低代码平台的现状与挑战
低代码平台通过可视化拖拽的方式，让开发者能够快速构建应用。然而，传统低代码平台存在一些痛点：
-
学习成本：用户需要学习平台的操作方式、组件使用等
-
灵活性不足：拖拽操作对于复杂的布局和逻辑往往力不从心
-
效率瓶颈：即使是简单的修改，也需要手动操作
AI的引入，为低代码平台带来了新的可能性。
15.2 TinyEngine的AI融合战略
TinyEngine是OpenTiny推出的低代码平台，它从设计之初就将AI作为核心能力进行融合。TinyEngine的AI融合体现在三个层面：
层面一：AI辅助开发
-
自然语言生成页面：用户通过自然语言描述页面需求，AI自动生成页面结构和组件配置
-
智能布局推荐：AI根据内容类型和设计规范，推荐最合适的布局
-
组件智能配置：AI根据业务语义，自动配置组件的属性和数据绑定
层面二：AI驱动交互
-
对话式构建：用户可以通过对话与TinyEngine交互，如“把标题改成红色”、“添加一个表格，显示用户数据”
-
智能问答：用户可以随时询问平台的使用方法、组件的属性含义等
-
实时预览与反馈：AI对用户的操作提供实时建议和反馈
层面三：AI赋能运行时
-
智能表单：根据数据模型自动生成表单，并支持智能校验
-
智能报表：根据用户意图动态生成图表和报表
-
智能工作流：根据业务规则自动推荐工作流节点
第十六章：TinyEngine的AI实战案例
16.1 案例一：自然语言生成页面
用户打开TinyEngine，输入：“创建一个员工信息管理页面，包含员工列表、搜索框、新增员工按钮。列表显示姓名、部门、职位、操作按钮。”
AI的处理流程：
-
意图解析：识别出页面包含员工列表、搜索框、新增按钮
-
数据模型推断：推断出员工信息的数据结构（姓名、部门、职位）
-
组件选择：选择Table组件作为列表，Input组件作为搜索框，Button作为新增按钮
-
布局生成：将搜索框放在顶部，表格居中，按钮放在表格上方或表格内
-
代码生成：生成页面配置（JSON Schema），TinyEngine渲染引擎将其转换为实际页面
最终，用户得到一个功能完整的管理页面，无需任何拖拽操作。
16.2 案例二：对话式修改页面
用户已经构建了一个页面，然后通过对话进行修改：
用户：“把表格的列宽调整一下，姓名列宽200，部门150，职位150。”
AI：解析后，修改表格列的宽度配置。
用户：“搜索框增加一个搜索按钮，放在输入框右边。”
AI：在搜索框旁边添加一个按钮，并绑定搜索事件。
这种对话式修改，让页面的调整变得更加直观和高效。
16.3 案例三：智能数据绑定
用户创建了一个图表组件，AI自动提示：“我检测到页面中有‘销售数据’表格，是否需要将图表绑定到该表格的数据源？”用户确认后，AI自动完成数据绑定。
这种智能感知能力，大大减少了用户的配置工作量。
第十七章：TinyEngine的AI架构
TinyEngine的AI架构主要包含以下模块：
-
意图理解引擎：基于大模型，理解用户的自然语言输入
-
页面生成器：根据意图生成页面配置（JSON Schema）
-
修改处理器：处理用户的修改请求，更新页面配置
-
智能推荐引擎：基于页面上下文，提供智能推荐
-
反馈学习模块：收集用户反馈，持续优化AI模型
所有AI能力都通过MCP协议暴露，使得TinyEngine的AI能力可以被其他应用复用。
第九篇：开源实践篇——从学习者到贡献者的蜕变
第十八章：OpenTiny开源社区介绍
OpenTiny是华为云开源的前端生态，包含TinyVue组件库、TinyEngine低代码平台、TinyPro后台模板、TinyCLI命令行工具等多个项目。OpenTiny的目标是打造一个“轻量、易用、高性能”的前端解决方案。
OpenTiny的开源社区非常活跃，有大量的开发者和企业用户参与贡献。我本人也是通过OpenTiny NEXT系列直播了解到这个社区，并逐步从学习者成长为贡献者。
第十九章：参与开源的心路历程
19.1 初识OpenTiny
最初接触OpenTiny，是因为在工作中需要选择一个企业级组件库。经过对比，TinyVue的轻量级和易用性吸引了我的注意。在使用的过程中，我发现了OpenTiny NEXT系列直播，便开始了系统的学习。
19.2 从学习到贡献
在学习的过程中，我逐渐发现了一些文档中的不足、示例中的bug，以及一些可以优化的地方。起初，我只是在GitHub上提issue，后来在社区成员的鼓励下，我开始尝试提交PR。
第一次提交PR的过程是紧张的，担心自己的代码不符合规范、担心被拒绝。但社区成员非常友好，他们耐心地review我的代码，指出问题，并指导我改进。最终，我的第一个PR被合并了，那种成就感是无与伦比的。
19.3 深度参与
随着时间的推移，我参与了越来越多的贡献：
-
修复了TinyVue的多个bug
-
为TinyEngine贡献了AI辅助开发的功能
-
编写了WebMCP相关的中文文档
-
在社区中帮助新手解答问题
这些经历让我对前端智能化的理解更加深入，也让我感受到了开源的魅力——一群人为了共同的目标，不计回报地付出，推动技术的进步。
第二十章：开源实践中的技术感悟
20.1 关于WebMCP的思考
在参与WebMCP的开发过程中，我深刻体会到“标准化”的重要性。如果没有一个统一的协议，每个AI应用都要重复造轮子，这不仅浪费资源，也不利于生态的发展。WebMCP的价值在于，它为前端智能化提供了一个共同的语言。
20.2 关于AI与前端融合的感悟
前端智能化的核心不是让AI替代前端开发者，而是让AI成为前端开发者的“超级助手”。AI可以处理重复性、机械性的工作，让开发者专注于创造性、业务性的工作。在TinyEngine的AI辅助开发实践中，我看到了这种“人机协作”的巨大潜力。
20.3 关于开源社区的感悟
开源社区是一个“赠人玫瑰，手有余香”的地方。你帮助别人解决问题，自己也会从中学习和成长。在OpenTiny社区，我不仅学到了技术，还结识了一群志同道合的朋友。这种社区氛围，是开源最宝贵的财富。
第十篇：未来展望篇——前端智能化的星辰大海
第二十一章：技术趋势预测
21.1 WebMCP将成为Web智能化的基础设施
随着AI应用的普及，WebMCP有望成为Web浏览器的标准能力。未来，浏览器可能会内置WebMCP的支持，让任何网站都可以被AI感知和操作。这将开启一个全新的“AI原生”Web时代。
21.2 组件库的AI标准化
未来，组件库不仅要提供UI组件，还要提供结构化的AI元数据。可能会诞生类似“AI组件描述语言”的标准，让AI能够统一理解不同组件库的组件。
21.3 低代码平台与AI的深度融合
低代码平台将不再是“拖拽工具”，而是“对话式应用构建平台”。用户通过自然语言即可构建复杂应用，低代码平台则负责将意图转化为实现。
21.4 AI Agent的普及
AI Agent将像浏览器一样成为每个用户的标配。用户可以雇佣多个AI Agent，分别处理不同领域的工作，Agent之间还可以相互协作。
第二十二章：挑战与应对
22.1 安全性挑战
当AI能够操作Web页面时，安全性成为首要问题。如何防止AI执行恶意操作？如何确保用户的隐私不被泄露？这需要从协议层面、权限管理层面、审计层面共同解决。
22.2 可靠性挑战
AI的操作并不总是正确的。当AI执行了错误的操作，如何快速恢复？如何让用户能够干预和纠正AI的行为？这需要设计良好的用户交互机制。
22.3 性能挑战
AI的推理和执行需要时间，如何在保证响应速度的同时提供智能体验？这需要优化AI模型、采用缓存策略、预加载等。
22.4 标准化挑战
目前，WebMCP、MCP等都处于早期阶段，标准尚未统一。如何推动这些标准的演进和普及，需要整个社区的努力。
结语：连接智能，创造未来
从AI Agent到WebMCP，从WebSkills到WebAgent，从GenUI到TinyVue Skill，从TinyEngine到AI-Extension——我们见证了前端智能化的蓬勃发展，也亲身参与了这场技术变革。
回望过去几个月的学习与实践，我深深感受到：技术的进步不仅仅是代码的堆砌，更是人类智慧的延伸。当我们让AI“看得到”界面、“动得了”组件，我们实际上是在创造一种全新的人机交互方式——一种更加自然、更加高效、更加智能的方式。
未来的Web，将不再是静态的文档，而是动态的、智能的、可交互的“数字生命体”。每一个页面都可以被AI理解，每一个组件都可以被AI操作，每一个用户都可以通过自然语言完成复杂的任务。
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
8
0- 0
已为社区贡献8条内容
所有评论(0)