一、 前言为什么医疗系统急需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种食物”匹配上因为两者的向量在空间上距离很近都指向“缓解负面情绪”。A2AAgent-to-Agent 协议 未来一个任务可能需要多个 Agent 协作完成如一个 Agent 负责查床位状态另一个 Agent 负责预约挂号还有一个 Agent 负责生成流程单。A2A 能让它们互相发现、通信、协作。ATTP / ATPAgent 信任传输协议 HTTPS 的“范式重构”版。HTTPS 只加密传输ATTP 还能确保“说话的是真 Agent”、“它没有被篡改指令”、“每一步都有不可抵赖的日志”。当 Agent 能执行“转账”“开药”等敏感操作时能提供身份验证、授权限定、防篡改审计。特性HTTPHTTPSATTP应用开始时间1991年HTTP/0.9。2017 年起主流浏览器标记 HTTP 为“不安全”‌1995年网景公司发布SSL 2.0HTTPS诞生。普及于15-20年预计2026-2027年技术草案/初期试点阶段身份模型无不关心客户端身份服务端身份认证通过证书不提供智能体/客户端原生身份强制绑定智能体身份Agent Passport实现端到端的身份认证与授权安全机制无加密明文传输极易被窃听和篡改传输层加密防窃听/篡改、服务器身份认证防钓鱼、提升 SEO 排名但中间人可假冒客户端端到端的消息级安全• 强制性消息签名请求和响应• 防篡改审计追踪• 无“不安全模式”访问控制无依赖第三方应用逻辑原生内置的信任等级Trust Levels L0-L4适用场景传统网页浏览传输非敏感信息通用Web应用在线交易登录表单等AI智能体间通信、智能体与服务端交互、自动化任务执行MCP为LLM构建的通用连接器 被称为AI 世界的“万能 USB-C 接口”2024 年由 Anthropic 推出的一种AI模型上下文协议。以前 AI 想用飞书、Gmail、云盘每个都要单独对接MCP 统一了接口标准AI 只要支持 MCP就能像插 USB 一样一次性连接所有支持 MCP 的工具。AI 通过 MCP 发现并调度各种 Skills。MCP 的关键特性标准化接口定义统一的接口和协议确保 LLM 与外部资源的兼容性。动态集成支持 LLM 动态访问和集成外部数据源和工具。上下文感知支持动态管理对话上下文提升多轮对话的连贯性。开放性和可扩展性支持第三方开发者为 LLM 应用扩展功能和资源。WebMCP(浏览器原生的“能力开放协议”)它是由Google和Microsoft在2026年2月联合发起的一项名为“WebMCP”的浏览器原生新标准。它直接回应了旧时代“视觉模拟”和“DOM解析”方案的脆弱、高成本和低稳定性等问题。WebMCP通过提供声明式API和命令式API两种模式让AI能够直接理解网页功能实现逻辑层面的直连而非像素级模拟。SkillsAI Agent核心Skills 本质上就是教 AI 按固定流程做事的操作说明书一旦写好就能像函数一样反复调用。Skills 与 MCP 在实际应用中往往是协同工作的。在整个调用链路中MCP 执行的是单一、精确的操作而 Skills 则负责跨上下文感知的组合式流程编排。生成式 UIGenUI 当模型输出结构化 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。每个动作对应一个明确的前端功能单元。例如一个筛选组件可以封装出这些原子动作动作名参数返回值说明setFilter{ orderId?: string, customerName?: string, status?: any }boolean设置筛选条件clearFilters无void清空所有筛选getFilterState无object获取当前筛选状态sort{ data: array, key?: string, reverse?: boolean}array | object对列表或按某属性进行升降序排序exportExcelparams: { orderIds?: string[]; format?: xlsx | csv }void导出为 Excel封装后AI 只需要调用setFilter并传入正确的参数无需关心筛选框是 input 还是 select也无需关心 DOM 结构。// ... script setup langts 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): PromiseBlob { // 模拟异步生成 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): Promisestring { return new Promise((resolve, reject) { const reader new FileReader() reader.onloadend () resolve(reader.result as string) reader.onerror reject reader.readAsDataURL(blob) }) } onUnmounted(() cleanupPageTool?.()) /script4.3 任务规划让 AI 组织多步操作用户的一句话往往对应多个操作步骤。例如“筛选出最近一周的危急值记录按等级降序排序然后把前十条导出为 Excel”。这需要 AI 能够理解意图从自然语言中抽取出三个子任务筛选、排序、导出确定依赖关系必须先筛选再排序最后导出排序依赖筛选的结果调用原子动作依次调用setFilter→sort→exportExcel处理异常如果筛选结果为空则跳过后续步骤并提示用户任务规划通常由 Agent 框架中的规划器Planner 完成常见算法有ReActReason Act交替进行“思考”和“行动”每一步都观察结果并调整下一步计划。Plan-and-Solve首先生成完整的步骤序列计划然后按顺序执行适用于确定性较强的任务。自我反思Self-Reflection执行过程中如果发现错误Agent 会暂停、分析错误原因、修正计划并继续。在 Web Agent 中任务规划器会结合原子动作的描述每个动作能做什么、需要什么参数以及当前界面状态通过 DOM 感知获取生成可执行的动作序列。整个过程完全在确定性 API 之上进行不会出现“试图点击一个不存在的按钮”之类的幻觉。五、案例与优势对比让 AI 操作现有的 Web 界面还需要解决几个问题Agent 会不会乱来会不会编造会不会跑偏能不能稳定输出因为在实际落地中准确性、可控性和确定性往往比“聪明”更重要。带着这个视角我们来看两条主流的解决方案。5.1 方案一视觉/黑盒方式以 OpenClaw 为例OpenClaw 代表一类工具它们去模拟像人一样“看”网页——解析 DOM 树、利用可访问性树、甚至借助多模态模型理解截图。然后 AI 自行决定点哪里、填什么。(图片为引用)问题不准确DOM 结构复杂、动态内容多AI 容易定位错元素幻觉AI 可能“认为”某个按钮存在实际并不存在不可控AI 的操作路径无法被开发者预先约束tip1v2026.3.22引入了“统一工具描述协议”使Agent能更准确地识别和调用可用工具减少“幻觉调用” tip2OpenClaw 2.0引入了多模态目标识别系统融合计算机视觉与NLP技术即使面对完全动态渲染的页面也能保持98%以上的识别准确率简言之OpenClaw 试图让 AI 猜界面怎么用即使开发者已经定义了清晰的组件 API。未来将是鸿蒙的状态驱动动系统不是页面驱动系统5.2 方案二Web Agent 白盒/能力暴露方式Web Agent 的思路完全不同开发者显式告诉 AI 哪些能力可用、参数是什么、顺序怎么组合。前端将组件动作、数据接口、页面跳转协议封装成原子动作AI 基于这些原子动作进行任务规划而不是去猜测 DOM结果是准确、无幻觉、可观测、可干预六、实战讲解Vue3 OpenTiny NEXT-SDKs 前端智能应用解决方案那么如何在实际的 Vue 项目中落地 Web Agent6.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 内置了一个抽象层可以抹平不同 LLMOpenAI、Anthropic、国产大模型等在 Function Calling / Tool Use 上的差异。同时它支持文字、语音、图像等多模态输入使得 AI 对话框连接的 LLM 能够调用受控端的 MCP 工具。例如用户语音输入“把xx金额大于1000的行标红”语音转文字 → LLM 理解意图 → 调用表格组件的highlightRows工具6.1.6 动态生成二维码让 MCP 服务成为可调用的工具提供动态生成二维码的功能。这意味着企业应用里的 MCP 服务可以生成一个二维码手机扫码后可以在移动端打开一个 AI 对话框该对话框能够直接调用 Web 应用里暴露的所有 MCP 工具实现了跨端能力调用从移动端自然语言操控 PC 端 Web 应用这一特性在企业内部工具、远程协助、大屏控制等场景中极具价值。6.3 对比其他方案的优势方案原理准确性开发成本适用场景OpenClawDOM/视觉解析低有幻觉低无需改造前端演示、简单页面LangChain Puppeteer脚本式操作中依赖选择器高需写大量选择器自动化测试OpenTiny NEXT-SDKs显式能力暴露 MCP 协议 框架适配高无幻觉中一次声明到处调用企业级复杂应用OpenTiny 方案的核心价值将 AI 的不可靠性封装在确定性 API 之后。开发者控制能力边界AI 只负责编排。