一、 前言：为什么医疗系统急需Web Agent？

💊 医生：医疗信息化的“效率困境”

• “点击疲劳”：医生每天在HIS（医院信息系统）上的点击操作平均超过400次，开一张检查单需要填写大量字段。

• “信息孤岛”：患者信息分散在EMR、LIS、PACS等多个系统，医生需登录不同系统拼凑完整病史。

• “认知负担重”：繁忙的门诊中，医生一边问诊一边操作复杂UI，容易遗漏关键信息或开错项目。

💉 护士：被忽视的庞大用户，操作权限与重复劳动

作为医院信息系统最大的用户群体，护士的需求往往被忽视，其困境主要体现在系统权限与工作流程的错配。

• 权限设置不合理：护士拥有过多或过少的功能权限都会降低满意度，且高达42%的护士甚至不清楚自己应拥有哪些权限。

• 无效的文书工作：护理文书记录任务繁重且重复度高，消耗了大量直接护理时间。据统计，35%的护士每周需花费3小时以上用于处理此类工作。

🧑🤝🧑 患者：在繁琐与低效中孤独前行

患者在整个就医流程中，也常常感到迷茫、沟通不畅和负担沉重。

• 操作复杂与流程繁琐：预约、挂号、缴费等环节界面不友好，流程冗长。例如，部分医院要求患者反复刷新挂号页面查询排队顺序，就医范围选项不明确，加剧了就医焦虑。

• 沟通不畅与等待焦虑：线上问诊常遇回复延迟、沟通断裂，患者难以获得及时的病情反馈和用药指导。

🤖 Web Agent带来的变革

普通的模型调用是一问一答：

你发消息，模型回消息，结束。

Agent 则不同，它进入一个思考-行动-观察循环：

展望

• 自然语言驱动：医生直接说“给这位患者开一个血常规+CRP”，系统自动完成开单、打印指引、扣费。

• 跨系统编排：Agent可以串联HIS、EMR、LIS，一站式完成“查病史→开检查→看报告”。

• 解放生产力：让医生回归诊疗本身，把软件操作交给AI。

• 智能流程跟进：自动跟进检查结果、配药进度等，并主动推送通知，打破信息盲区。

二、听完这场分享，你会学到什么？

由于概念介绍比较多，可能比较枯燥，我先说下都有哪些点，大家可以选择感兴趣的听哈

• 了解AI圈术语概念与协同

• 掌握 Web Agent 的核心技术

• Web Agent(WebMCP)与当下智能体的优劣对比

• OpenTiny NEXT-SDKs前端智能应用开发企业级解决方案

三、AI圈术语概念

• RAG（检索增强生成） AI 在回答问题前，先去你的知识库（或数据库、网页）里搜索相关内容，再结合搜索到的信息生成答案。这解决了 LLM 的两个核心痛点：知识截止日期（模型不知道训练后发生的事）和幻觉问题（模型在不确定时会编造答案）

  • 传统数据库（SQL）：基于精确匹配。比如WHERE name = ‘张三’。它找不出“苹果好吃”和“这种水果口感酸甜”之间的语义关联，因为文字完全不同。

  • 向量数据库：基于语义搜索。它能把“如何消解忧愁”和“让人快乐的10种食物”匹配上，因为两者的向量在空间上距离很近，都指向“缓解负面情绪”。

• A2A（Agent-to-Agent 协议） 未来一个任务可能需要多个 Agent 协作完成（如一个 Agent 负责查床位状态，另一个 Agent 负责预约挂号，还有一个 Agent 负责生成流程单）。A2A 能让它们互相发现、通信、协作。

• ATTP / ATP（Agent 信任传输协议） HTTPS 的“范式重构”版。HTTPS 只加密传输，ATTP 还能确保“说话的是真 Agent”、“它没有被篡改指令”、“每一步都有不可抵赖的日志”。当 Agent 能执行“转账”“开药”等敏感操作时能提供身份验证、授权限定、防篡改审计。

• MCP（为LLM构建的通用连接器） 被称为AI 世界的“万能 USB-C 接口”，2024 年由 Anthropic 推出的一种AI模型上下文协议。以前 AI 想用飞书、Gmail、云盘，每个都要单独对接；MCP 统一了接口标准，AI 只要支持 MCP，就能像插 USB 一样一次性连接所有支持 MCP 的工具。AI 通过 MCP 发现并调度各种 Skills。

  MCP 的关键特性

  1. 标准化接口：定义统一的接口和协议，确保 LLM 与外部资源的兼容性。

  2. 动态集成：支持 LLM 动态访问和集成外部数据源和工具。

  3. 上下文感知：支持动态管理对话上下文，提升多轮对话的连贯性。

  4. 开放性和可扩展性：支持第三方开发者为 LLM 应用扩展功能和资源。

• WebMCP(浏览器原生的“能力开放协议”)

  它是由Google和Microsoft在2026年2月联合发起的一项名为“WebMCP”的浏览器原生新标准。它直接回应了旧时代“视觉模拟”和“DOM解析”方案的脆弱、高成本和低稳定性等问题。WebMCP通过提供声明式API和命令式API两种模式，让AI能够直接理解网页功能，实现逻辑层面的直连，而非像素级模拟。

• Skills（AI Agent核心）

  Skills 本质上就是教 AI 按固定流程做事的操作说明书，一旦写好，就能像函数一样反复调用。

  Skills 与 MCP 在实际应用中往往是协同工作的。在整个调用链路中，MCP 执行的是单一、精确的操作；而 Skills 则负责跨上下文感知的组合式流程编排。

• 生成式 UI（GenUI） 当模型输出结构化 JSON 数据，前端渲染器将其动态转换为可交互的 UI 组件（卡片、表单、图表）。AI 不再是只会发文字，还能“画”出表格、按钮、趋势图，让你直接操作。
  
  

在AIAgent领域，前端工程师不再是“画个病历表格、做几个图表、做个查询的对话框”，而是智能体环境的架构师链路闭环，自动校准修复问题

kills 合集平台：Agent Skills Marketplace | Codex & Claude Skills | SkillsMPFind awesome Agent Skills

四、Web Agent 核心技术：DOM 感知、原子动作封装、任务规划

要让 AI 成为一个真正能操作网页的 Agent，必须解决三个核心问题：如何“看见”界面、如何“拆解”能力、如何“规划”步骤。

4.1 DOM 感知：让 AI 看懂界面

Web Agent 要是想像人一样理解当前页面有什么元素、每个元素的状态和含义。

常见的感知方式有三种：

• DOM 树解析：直接读取页面的 DOM 结构，提取元素类型（按钮、输入框、表格等）、属性（class、data-、aria-）、文本内容、位置信息。优点是快速、准确，缺点是对动态生成的内容和复杂 CSS 布局不敏感。

• 可访问性树（Accessibility Tree）：利用浏览器为辅助技术提供的语义化结构，包含 role、name、value、状态等。许多 AI Agent 使用可访问性树作为感知基础，因为它更聚焦于“可交互”元素，噪声更少。

• 多模态视觉模型：将页面截图输入视觉大模型（如 GPT-4V），由模型直接识别界面元素和布局。优点是无需依赖 DOM 结构，能理解复杂的视觉样式；缺点是成本高、延迟大、容易产生幻觉。

在实际的 Web Agent 设计中，通常采用混合策略：先通过 DOM 树和可访问性树快速获取结构化信息，遇到复杂组件或动态内容时再调用视觉模型作为补充。

4.2 原子动作封装：把前端能力变成可调用的“函数”

无论 AI 如何感知界面，最终都需要执行具体操作——点击、输入、滚动、提交等。但如果让 AI 直接操作 DOM（例如document.getElementById('btn').click()），会带来两个问题：

• 脆性：DOM 结构稍有变化，选择器就会失效

• 不可控：AI 可能执行任意 JavaScript，带来安全风险

原子动作封装的思路是：

由开发者预先定义一组稳定的、有语义的、带参数和校验的动作，然后将这些动作暴露给 AI。每个动作对应一个明确的前端功能单元。

例如，一个筛选组件可以封装出这些原子动作：

封装后，AI 只需要调用setFilter并传入正确的参数，无需关心筛选框是 input 还是 select，也无需关心 DOM 结构。

// ... <script setup lang="ts"> import { onMounted, onUnmounted } from 'vue' import { registerPageTool } from '@opentiny/next-sdk' let cleanupPageTool: (() => void) | undefined onMounted(() => { cleanupPageTool = registerPageTool({ route: '/orders', handlers: { // 1. 查询预约列表（支持按预约号、患者姓名、状态筛选） order_query: async (params: { orderId?: string customerName?: string status?: string }) => { // 模拟查询逻辑（实际应调用 API） const { orderId, customerName, status } = params const result = mockQueryOrders({ orderId, customerName, status }) const text = `找到 ${result.length} 条预约` return { content: [{ type: 'text', text: text }] } }, // 2. 导出为 Excel export_excel: async (params: { orderIds?: string[]; format?: 'xlsx' | 'csv' }) => { const { orderIds, format = 'xlsx' } = params // 模拟导出：生成文件并返回下载链接或直接返回文件内容 try { // 实际业务：根据 orderIds 获取数据，调用后端导出接口 const blob = await generateExcelBlob(orderIds, format) // 方式一：返回一个可下载的链接（推荐，因为 Agent 环境通常不支持直接返回文件流） const downloadUrl = URL.createObjectURL(blob) const text = `导出成功！共 ${blob.size} 字节，格式：${format.toUpperCase()}。\n下载链接：${downloadUrl}` return { content: [{ type: 'text', text: text }] } // 方式二：直接返回 base64 编码的文件内容（适合小文件） // const base64 = await blobToBase64(blob) // return { content: [{ type: 'text', text: base64 }] } } catch (error) { return { content: [{ type: 'text', text: `导出失败：${error.message}` }] } } }, // 3. 排序功能（通用原子动作） sort_list: async (params: { data: any[] // 待排序的数组 key?: string // 若元素为对象，指定排序的属性名 reverse?: boolean // 是否降序，默认 false }) => { const { data, key, reverse = false } = params if (!Array.isArray(data)) { return { content: [{ type: 'text', text: '错误：data 必须是数组' }] } } if (data.length === 0) { return { content: [{ type: 'text', text: '排序结果：[]' }] } } // 深拷贝原数组，不修改原数据 const sorted = [...data] // 比较函数 const compare = (a: any, b: any) => { let valA = key ? getNestedValue(a, key) : a let valB = key ? getNestedValue(b, key) : b // 处理 null/undefined（视为最小） if (valA == null && valB == null) return 0 if (valA == null) return -1 if (valB == null) return 1 // 数字与字符串混合时的自然排序（字符串转数字对比） if (typeof valA === 'number' && typeof valB === 'number') { return valA - valB } // 统一转字符串比较 const strA = String(valA) const strB = String(valB) return strA.localeCompare(strB) } sorted.sort((a, b) => { const result = compare(a, b) return reverse ? -result : result }) const text = `排序完成，共 ${sorted.length} 条数据。\n结果预览：${JSON.stringify(sorted.slice(0, 5))}${sorted.length > 5 ? '...' : ''}` return { content: [{ type: 'text', text: text }] } } } }) }) // 辅助函数：获取对象深层属性（支持点路径，如 'user.age'） function getNestedValue(obj: any, path: string): any { return path.split('.').reduce((current, key) => current?.[key], obj) } // 模拟查询预约的函数（实际应替换为真实 API） function mockQueryOrders(filters: any) { // 仅为示例，返回模拟数据 return [ { orderId: '1001', customerName: '张三', status: 'pending' }, { orderId: '1002', customerName: '李四', status: 'completed' } ] } // 模拟生成 Excel Blob（实际应调用后端导出接口） async function generateExcelBlob(orderIds: string[] | undefined, format: string): Promise<Blob> { // 模拟异步生成 return new Promise((resolve) => { setTimeout(() => { const fakeData = 'OrderId,Name,Status\n1001,张三,pending\n1002,李四,completed' const mime = format === 'xlsx' ? 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' : 'text/csv' resolve(new Blob([fakeData], { type: mime })) }, 100) }) } // 工具：Blob 转 Base64（可选） async function blobToBase64(blob: Blob): Promise<string> { return new Promise((resolve, reject) => { const reader = new FileReader() reader.onloadend = () => resolve(reader.result as string) reader.onerror = reject reader.readAsDataURL(blob) }) } onUnmounted(() => cleanupPageTool?.()) </script>

4.3 任务规划：让 AI 组织多步操作

用户的一句话往往对应多个操作步骤。例如：“筛选出最近一周的危急值记录，按等级降序排序，然后把前十条导出为 Excel”。这需要 AI 能够：

1. 理解意图：从自然语言中抽取出三个子任务（筛选、排序、导出）

2. 确定依赖关系：必须先筛选，再排序，最后导出；排序依赖筛选的结果

3. 调用原子动作：依次调用setFilter→sort→exportExcel

4. 处理异常：如果筛选结果为空，则跳过后续步骤并提示用户

任务规划通常由 Agent 框架中的规划器（Planner） 完成

常见算法有：

• ReAct（Reason + Act）：交替进行“思考”和“行动”，每一步都观察结果并调整下一步计划。

• Plan-and-Solve：首先生成完整的步骤序列（计划），然后按顺序执行，适用于确定性较强的任务。

• 自我反思（Self-Reflection）：执行过程中如果发现错误，Agent 会暂停、分析错误原因、修正计划并继续。

在 Web Agent 中，任务规划器会结合原子动作的描述（每个动作能做什么、需要什么参数）以及当前界面状态（通过 DOM 感知获取），生成可执行的动作序列。

整个过程完全在确定性 API 之上进行，不会出现“试图点击一个不存在的按钮”之类的幻觉。

五、案例与优势对比

让 AI 操作现有的 Web 界面还需要解决几个问题，Agent 会不会乱来？会不会编造？会不会跑偏？能不能稳定输出？因为在实际落地中，准确性、可控性和确定性往往比“聪明”更重要。

带着这个视角，我们来看两条主流的解决方案。

5.1 方案一：视觉/黑盒方式（以 OpenClaw 为例）

OpenClaw 代表一类工具：它们去模拟像人一样“看”网页——解析 DOM 树、利用可访问性树、甚至借助多模态模型理解截图。然后 AI 自行决定点哪里、填什么。(图片为引用)

问题：

• 不准确：DOM 结构复杂、动态内容多，AI 容易定位错元素

• 幻觉：AI 可能“认为”某个按钮存在，实际并不存在

• 不可控：AI 的操作路径无法被开发者预先约束

tip1：v2026.3.22引入了“统一工具描述协议”，使Agent能更准确地识别和调用可用工具，减少“幻觉调用” tip2：OpenClaw 2.0引入了多模态目标识别系统，融合计算机视觉与NLP技术，即使面对完全动态渲染的页面也能保持98%以上的识别准确率

简言之，OpenClaw 试图让 AI 猜界面怎么用，即使开发者已经定义了清晰的组件 API。

未来将是鸿蒙的状态驱动动系统，不是页面驱动系统

5.2 方案二：Web Agent （白盒/能力暴露方式）

Web Agent 的思路完全不同：开发者显式告诉 AI 哪些能力可用、参数是什么、顺序怎么组合。

• 前端将组件动作、数据接口、页面跳转协议封装成原子动作

• AI 基于这些原子动作进行任务规划，而不是去猜测 DOM

• 结果是：准确、无幻觉、可观测、可干预
  

六、实战讲解：Vue3 + OpenTiny NEXT-SDKs 前端智能应用解决方案

那么，如何在实际的 Vue 项目中落地 Web Agent？

6.1 快速开始

OpenTiny NEXT-SDKs 是一套前端智能应用开发工具包，旨在简化 WebAgent 的集成与使用。它支持多种编程语言和前端框架，帮助开发者快速实现智能化功能。以下是它的核心能力：

6.1.1 多语言核心 SDK，降低接入门槛

提供 TypeScript、Python、Java 等多个版本的核心 SDK，封装了与 WebAgent 服务的连接、认证、会话管理等底层逻辑。开发者无需关心协议细节，只需调用简化的 API 即可让前端应用接入 Agent 能力。

6.1.2 将前端功能声明为 MCP Server

通过易用的 API，开发者可以将企业应用中的任何前端功能（组件动作、数据接口、业务逻辑）快速声明为 MCP Server。这意味着：

• 每个 Vue/React 组件都可以暴露自己的一组可调用“工具”

• AI Agent 通过标准 MCP 协议发现并调用这些工具

• 实现了前端能力与 AI 的解耦——更换 LLM 或 Agent 框架不影响前端声明

6.1.3 框架适配层：降低特定框架的使用难度

针对 Vue、React、Angular、Vanilla 等主流前端框架的特性，提供专门的适配层 API。例如：

• 在 Vue 中，利用 Composition API 和依赖注入机制，让组件动作自动注册到全局 Agent 注册表

• 在 React 中，通过 Hooks 和 Context 简化 Agent 状态管理 这样，开发者可以在自己熟悉的框架生态中，以最小改造成本使用 MCP Server 和连接 WebAgent。

6.1.4 对话框组件适配器：任意 AI 对话框快速接入

提供一个通用适配器层，可以将任意前端 AI 对话框组件（包括 OpenTiny 自带的 TinyRobot 组件，以及第三方的 ChatUI、自定义对话框）快速接入 WebAgent 服务。适配器负责：

• 将用户的自然语言输入转发给 Agent

• 将 Agent 的思考过程和执行结果渲染到对话框中

• 支持流式输出和中间步骤展示

6.1.5 抹平 LLM 差异，支持多模态输入

OpenTiny NEXT-SDKs 内置了一个抽象层，可以抹平不同 LLM（OpenAI、Anthropic、国产大模型等）在 Function Calling / Tool Use 上的差异。同时，它支持文字、语音、图像等多模态输入，使得 AI 对话框连接的 LLM 能够调用受控端的 MCP 工具。例如：

• 用户语音输入：“把xx金额大于1000的行标红”

• 语音转文字 → LLM 理解意图 → 调用表格组件的highlightRows工具

6.1.6 动态生成二维码：让 MCP 服务成为可调用的工具

提供动态生成二维码的功能。这意味着：

• 企业应用里的 MCP 服务可以生成一个二维码，手机扫码后可以在移动端打开一个 AI 对话框

• 该对话框能够直接调用 Web 应用里暴露的所有 MCP 工具

• 实现了跨端能力调用：从移动端自然语言操控 PC 端 Web 应用

这一特性在企业内部工具、远程协助、大屏控制等场景中极具价值。

6.3 对比其他方案的优势

OpenTiny 方案的核心价值：将 AI 的不可靠性封装在确定性 API 之后。开发者控制能力边界，AI 只负责编排。