OpenTiny NEXT 深度解析：用 SDK 和 GenUI 让 Web 应用接入 AI 能力

1. 从 HC 2026 现场说起OpenTiny NEXT 到底想解决什么问题今年 HC 大会的展区里OpenTiny 的展台前一直围着人。我挤进去看了两轮演示又拉着他们的工程师聊了将近四十分钟回来之后最大的感受是OpenTiny NEXT 这次不是在做“给组件库加个 AI 按钮”这种表面功夫而是在重新定义 Web 应用和 AI 之间的那层接口。先把话说清楚OpenTiny 本身是华为开源的一套企业级前端组件库和低代码引擎包含 TinyVue、TinyNG、TinyPro 等一整套东西主要面向中后台管理系统、数据看板、表单密集型业务这类场景。而OpenTiny NEXT 是它在智能化方向上的一次整体升级核心关键词就是标题里那几个Web、AI、SDK、GenUI。那它到底解决什么问题我举个实际场景你就懂了。以前我们做一个 CRM 系统客户说“帮我查一下上个月华东区销售额超过 50 万的订单”你得先点筛选、选时间、选区域、填金额、点查询五步操作。现在如果这个系统接了 OpenTiny NEXT 的能力用户直接在对话框里说这句话AI 理解意图之后通过 SDK 调用页面上的查询接口自动把筛选条件填好、把结果渲染出来。用户不需要学你的界面AI 帮你操作界面。这就是所谓的GenUIGenerative UI生成式界面思路界面不再是死的而是根据用户意图动态生成或动态调整的。OpenTiny NEXT 提供的 SDK就是让开发者能把这套能力接进自己已有的 Web 项目里而不是推倒重来。适合谁看这篇三类人一是正在做中后台系统、想加智能化能力但不想重构的前端负责人二是对 GenUI、AI Agent 落地感兴趣的技术选型同学三是单纯想搞清楚“Web 应用智能化”这条路现在走到哪一步了的开发者。下面我按现场看到的东西加上自己的理解把这件事拆开讲。2. 核心设计思路拆解为什么是 SDK 而不是新框架2.1 不推翻现有技术栈是这次最聪明的选择我见过太多“智能化升级”的方案上来就让你换框架、换渲染引擎、换状态管理最后项目组怨声载道。OpenTiny NEXT 走的是另一条路它把自己做成一个 SDK挂在你现有的 Web 应用上。这个决策背后的逻辑很实在。中后台系统动辄几十上百个页面历史包袱重你不可能让一个已经跑了三年的系统为了接 AI 全部重写。SDK 模式的好处是侵入性低——你在入口处初始化一下在需要智能化的页面注册一下能力剩下的老代码基本不用动。从工程角度看这相当于在应用和 AI 之间加了一层适配层。这层适配层干三件事把页面上的可操作能力接口、组件、数据暴露给 AI把 AI 的意图翻译成具体的页面操作把操作结果回传给 AI 做下一步推理。你可以把它理解成一个“翻译官”左边是人类的自然语言右边是前端的具体函数调用。2.2 GenUI 的本质是“能力注册 意图路由”很多人对 GenUI 有误解以为就是让 AI 直接生成 HTML 或者生成一个页面。真做过就知道让大模型直接吐 UI 代码稳定性和安全性都没法保证生成出来的东西样式不统一、交互有漏洞企业级场景根本不敢用。OpenTiny NEXT 的 GenUI 走的是更务实的路线开发者预先注册“能力”AI 负责在合适的时机调用合适的能力。这里的“能力”可以是一个查询接口、一个表单填充动作、一个图表渲染函数。AI 不直接画界面而是决定“现在该调用哪个能力、传什么参数”。打个比方这就像餐厅点菜。AI 不是那个冲进厨房自己炒菜的客人而是那个听懂客人需求、然后把订单准确报给厨房的服务员。厨房也就是你写好的业务逻辑还是原来的厨房菜还是那些菜只是点菜的方式从看菜单变成了说话。这种设计的好处非常明显可控。AI 能调用的能力是你注册进去的它调不了你没注册的东西可测。每个能力都是独立的函数可以单独写测试可回退。AI 判断错了用户还能手动操作界面本身没被破坏。2.3 为什么强调 SDK 这个词热词里 SDK 出现频率极高这不是偶然。SDK 意味着标准化和可集成。OpenTiny NEXT 把自己定位成 SDK实际上是在说我不绑定你的框架Vue 能用React 能用甚至你是个老 jQuery 项目只要按我的规范注册能力也能接。我在现场特意问了兼容性问题得到的答复是核心 SDK 是框架无关的针对 TinyVue 这种自家组件库会有更顺滑的封装但底层能力不依赖特定框架。这对存量项目来说是个好消息——你不需要为了用它的 AI 能力先把整个项目迁移到某个特定技术栈。从行业趋势看SDK 化也是 AI 能力落地的主流路径。大模型能力再强也得有个东西把它和具体业务接起来SDK 就是这个“接”的载体。OpenTiny NEXT 选择这条路说明它是奔着真实项目落地去的不是做个 demo 秀肌肉。3. 核心能力细节解析与实操要点3.1 能力注册把页面变成 AI 可操作的“工具箱”整个体系里最关键的一步就是能力注册。你得告诉 SDK我这个页面上有哪些东西是 AI 可以操作的。从现场演示和我自己的理解来看注册一个能力大概需要描述这几样东西能力名称AI 靠这个识别、能力描述自然语言帮 AI 理解这个能力是干嘛的、参数定义需要传什么、执行函数真正干活的代码。这里有个坑我必须提醒能力描述写得越清楚AI 调用越准。很多人注册能力的时候描述写得含糊比如就写个“查询数据”结果 AI 根本不知道什么时候该用它。正确的写法应该像给新同事写文档一样把使用场景、参数含义、返回结果都写明白。// 能力注册的示意结构基于常见实践补全 registerCapability({ name: queryOrderList, description: 根据时间范围、区域、金额下限查询订单列表返回订单数组, parameters: { startDate: { type: string, description: 开始日期格式 YYYY-MM-DD }, endDate: { type: string, description: 结束日期格式 YYYY-MM-DD }, region: { type: string, description: 区域名称如华东 }, minAmount: { type: number, description: 最小金额单位元 } }, handler: async (params) { // 调用你原有的业务接口 return await orderApi.query(params); } });注意能力粒度要适中。太粗一个能力干十件事AI 容易传错参数太细每个字段一个能力AI 要调很多次效率低。我的经验是按“用户一次意图能完成的事”来划分粒度。3.2 意图理解与参数映射AI 最容易出错的地方用户说“上个月华东区的大单”AI 要把它翻译成startDate: 2026-05-01, endDate: 2026-05-31, region: 华东, minAmount: 500000。这一步是整个链路里最容易出问题的。为什么因为自然语言是模糊的。“上个月”是相对时间得结合当前日期算“大单”是业务黑话得有个映射规则“华东区”可能你系统里存的是“华东大区”得做名称对齐。OpenTiny NEXT 在这块的思路是给 AI 提供上下文和约束。你在注册能力时定义的参数类型和描述就是给 AI 的约束。同时 SDK 会把你应用里的一些基础信息比如当前用户、当前时间、字典数据作为上下文喂给模型帮它做更准确的判断。实操建议把业务黑话整理成映射表作为上下文注入。比如“大单金额50万”“活跃用户近30天登录5次”这些规则写进去AI 的准确率会明显提升。别指望模型自己猜出你公司的业务定义它猜不出来。3.3 结果渲染GenUI 的“生成”体现在哪能力执行完拿到数据接下来就是渲染。这里的“生成式”体现在AI 可以根据数据特点和用户意图决定用什么方式展示。比如同样是订单数据用户问“有多少单”AI 可能返回一个数字卡片用户问“趋势怎么样”AI 可能渲染一个折线图用户问“哪些客户”AI 可能返回一个表格。这些展示形式对应的组件是你预先准备好的AI 做的是选择和填数据。这就回到了前面说的AI 不直接画 UI它在你的组件库里挑合适的组件来用。这样既保证了样式统一又保证了交互可靠。我在现场看到演示里同一个查询请求换个问法返回的展示形式确实不一样这个体验挺惊艳的。3.4 安全边界企业场景绕不开的一环企业级应用接 AI安全是头等大事。OpenTiny NEXT 在这方面做了几层防护我觉得值得单独说。第一层是能力白名单。只有注册过的能力 AI 才能调没注册的它碰不到。第二层是参数校验。AI 传过来的参数要过一遍校验类型不对、范围超限的直接拒绝。第三层是权限继承。AI 调用能力时用的是当前登录用户的权限用户没权限查的数据AI 也查不到。提示千万别为了图省事把管理员的超级权限直接给 AI 用。一定要让 AI 的操作走用户权限体系否则出了数据泄露就是大事故。4. 实操过程与核心环节实现4.1 环境准备与 SDK 接入假设你手上有个 Vue 3 Vite 的中后台项目想接入 OpenTiny NEXT 的能力。第一步是装依赖、初始化 SDK。# 安装核心 SDK包名以官方发布为准此处为示意 npm install opentiny/next-sdk初始化一般在应用入口做把一些全局配置传进去比如模型服务的地址、认证信息、全局上下文提供函数等。import { createNextAgent } from opentiny/next-sdk; const agent createNextAgent({ // 模型服务配置 model: { endpoint: /api/ai/chat, // 其他认证参数按官方文档来 }, // 全局上下文帮 AI 理解当前环境 contextProvider: () ({ currentTime: new Date().toISOString(), currentUser: store.state.user.name, // 业务字典帮 AI 做名称对齐 dictionaries: { regions: [华东, 华北, 华南, 西南], orderStatus: [待付款, 已付款, 已发货, 已完成] } }) }); // 挂到全局方便各页面注册能力 app.config.globalProperties.$agent agent;这一步的关键点是 contextProvider。它返回的内容会作为上下文喂给模型直接影响意图理解的准确率。我的建议是把当前时间、当前用户、常用字典都放进去成本很低但效果提升明显。4.2 在业务页面注册能力接下来到具体页面比如订单列表页把查询能力注册进去。// 在订单列表页的 setup 里 import { onMounted, onUnmounted } from vue; import { useNextAgent } from opentiny/next-sdk; export default { setup() { const agent useNextAgent(); let capabilityId null; onMounted(() { capabilityId agent.registerCapability({ name: queryOrderList, description: 查询订单列表支持按时间范围、区域、金额下限筛选, parameters: { startDate: { type: string, description: 开始日期 YYYY-MM-DD }, endDate: { type: string, description: 结束日期 YYYY-MM-DD }, region: { type: string, description: 区域名称 }, minAmount: { type: number, description: 最小金额元 } }, handler: async (params) { // 复用页面原有的查询逻辑 const res await fetchOrderList(params); // 同时更新页面状态让界面和 AI 操作同步 updateTableData(res.list); return res; } }); }); // 页面卸载时注销能力避免污染其他页面 onUnmounted(() { if (capabilityId) agent.unregisterCapability(capabilityId); }); } };这里有个实操心得handler 里除了返回数据最好同步更新页面状态。这样用户能看到 AI 操作界面的过程而不是数据悄悄变了但界面没反应。这种“可见性”对建立用户信任很重要。4.3 参数计算与映射的落地前面提到“上个月”“大单”这类模糊表达需要映射。具体怎么落地我一般会在 contextProvider 里注入一个业务规则表或者单独提供一个解析函数。// 业务规则映射示意 const businessRules { // 时间相对词 timeMapping: { 今天: () [today(), today()], 上个月: () [lastMonthStart(), lastMonthEnd()], 近一周: () [daysAgo(7), today()] }, // 业务黑话 slangMapping: { 大单: { minAmount: 500000 }, 小单: { maxAmount: 10000 }, 活跃客户: { minOrderCount: 5 } } };把这些规则作为上下文的一部分提供给模型它在解析用户输入时就有了依据。实测下来加了业务规则之后参数映射的准确率能从“经常出错”提升到“基本可用”。4.4 完整链路的联调单个能力跑通之后要做的是多能力协同的联调。真实场景里用户一句话可能触发多个能力比如“帮我看看上个月华东的大单然后给这些客户发个提醒”。这句话里有两个意图查询 发提醒。SDK 需要能识别出这是两步操作先调查询能力拿到结果后再调发提醒能力而且第二步的参数依赖第一步的结果。这种链式调用是 Agent 能力的核心也是联调时最花时间的部分。我的建议是先把单能力调稳再上多能力。单能力都没调准就急着做链式出了问题根本不知道是哪一环的锅。联调时打开 SDK 的日志把每次意图识别、参数解析、能力调用的过程都打出来排查起来快很多。5. 常见问题与排查技巧实录5.1 AI 识别不出该调用哪个能力这是最高频的问题。表现是用户说了需求AI 回复“我不太理解”或者调了个完全不相关的能力。排查思路按这个顺序来先看能力描述是不是太模糊把描述改得更具体、更贴近用户可能的说法再看能力数量是不是太多如果注册了几十个能力模型选择困难考虑按页面或场景分组注册最后看上下文里有没有提供足够的业务信息。我踩过的一个坑能力名称用了英文驼峰queryOrderList但用户说的是中文“查订单”模型有时候对不上。后来在描述里补了“查询订单列表”这样的中文说明问题就解决了。别假设模型能自动做中英文对齐该写的说明要写。5.2 参数传错或漏传用户说“查上个月的订单”结果 AI 只传了 startDate 没传 endDate或者把“上个月”算成了“30天前”。这类问题的根源通常是参数描述不够明确。把endDate的描述从“结束日期”改成“结束日期查询上个月时应为上月最后一天”模型的表现会好很多。另外在 handler 里加一层参数兜底也很重要——如果 endDate 没传默认补上当前日期别让请求直接失败。还有一种情况是相对时间计算错误。模型对“上个月”“下季度”这种相对时间的计算经常出错。我的做法是在 contextProvider 里直接把常用相对时间的计算结果算好传进去比如lastMonth: { start: 2026-05-01, end: 2026-05-31 }让模型直接用别让它自己算。5.3 能力调用成功但界面没反应数据查回来了但表格还是空的。这通常是状态同步没做好。前面强调过handler 里除了返回数据还要更新页面状态。如果你用的是 Vuex 或 Pinia记得在 handler 里 commit 或 dispatch 对应的 action。还有一种可能是组件没监听数据变化。有些老代码里表格数据是初始化时赋值的后续变化不响应。这种情况要么改成响应式要么在 handler 里手动触发刷新。5.4 多轮对话上下文丢失用户先问“查上个月华东的订单”接着问“那华北的呢”。第二句里的“那”指代的是上一句的查询条件但 AI 如果记不住上下文就会懵。SDK 一般会维护对话历史但历史太长会拖慢响应、增加成本。我的经验是保留最近 5 到 10 轮更早的做摘要压缩。另外对于关键的业务上下文比如用户当前在哪个页面、选了什么筛选条件单独维护一份别混在对话历史里。5.5 常见问题速查表问题现象可能原因排查方向解决建议AI 不调用任何能力能力描述模糊/能力过多检查描述文案、能力数量描述具体化、按场景分组参数传错参数描述不清/相对时间算错看日志里的参数解析结果补描述、预计算相对时间界面无反应状态未同步检查 handler 是否更新状态handler 内同步更新页面数据多轮对话丢失上下文未维护/历史过长检查对话历史配置保留近几轮、关键上下文单独存调用越权权限未继承检查能力调用的权限来源走用户权限体系不用超管权限响应慢能力粒度过细/历史过长看调用链长度合并能力、压缩历史提示排查这类问题日志是第一生产力。把意图识别结果、参数解析结果、能力调用入参出参都打出来大部分问题看一眼日志就定位了。别靠猜。6. 我对 Web 应用智能化这条路的一些实际体会聊了这么多技术细节最后说点我自己的感受。Web 应用智能化这件事这两年喊的人多真正落地的少。原因不复杂大部分方案要么太重要么太虚。重的让你重构整个应用虚的做个 demo 好看但上不了生产。OpenTiny NEXT 这次给我的感觉是找到了一个相对务实的中间点。SDK 化让它能接进存量项目能力注册机制让 AI 的操作可控可测GenUI 的思路避开了直接生成 UI 代码的坑。这些选择背后能看出来是做企业级项目的人才会有的考量。当然它也不是银弹。能力注册的工作量是实打实的你得把页面上每个想开放给 AI 的操作都梳理一遍、注册一遍。业务规则的整理也是个细活黑话映射、相对时间计算这些都得一个个抠。但我觉得这个投入是值得的——你梳理能力的过程其实也是在梳理自己系统的接口边界这件事本身就有价值。如果你手上正好有个中后台系统想试试智能化我的建议是别一上来就铺开。挑一个高频、边界清晰的场景比如“订单查询”或者“报表生成”先把这一个场景调通把能力注册、参数映射、结果渲染这条链路跑顺再考虑扩展。一个场景跑通了后面的复制成本会低很多。另外提醒一句别把 AI 当成替代用户操作的唯一入口。它应该是增强不是替代。用户想手动操作的时候界面还得是完整可用的。AI 挂了、模型服务不稳定的时候系统不能瘫。这个底线思维在企业场景里比什么都重要。