向量空间 JBoltAI 推出的 TokUI，是面向 AI 应用场景打造的流式 UI 描述与渲染框架，核心围绕大模型的文本输出特性，重构 UI 的描述、传输与渲染全链路。以下从产品定位与设计背景两个维度，对 TokUI 进行具体说明。
一、TokUI 是什么
向量空间 JBoltAI 打造的 TokUI，本质是一套零运行时依赖的流式 UI 描述与渲染框架。它通过极简的领域特定语言（DSL）描述界面组件，由后端生成 DSL 字符串后，经由 SSE 或 WebSocket 以流式方式推送到前端；前端基于状态机对输入进行增量解析，在首个有效标签到达时即开始绘制真实 DOM 元素，无需等待完整结构全部输出。
TokUI 的数据流分为三层贯穿前后端：服务端通过构建工具以链式 API 将结构化数据编译为 DSL 字符串；传输层通过流式协议将字符流持续推向前端；前端解析器逐字符处理输入流，同步由渲染器将解析出的节点转化为真实页面元素。整套体系共享同一套组件语义，保证 UI 描述与最终渲染效果的一致性。
从技术定位来看，TokUI 并非 HTML 的替代方案，也不是 Markdown 的功能升级，而是专门针对 AI 流式输出场景设计的第三种 UI 表达介质。与传统方案相比，它的 Token 消耗更低，对流式传输的适配度更高，同时原生支持交互能力，语义聚焦于组件层面，更贴合 AI 生成的场景特性。其核心应用场景为 AI 对话中的流式 UI 生成，同时协议设计天然兼容低代码平台、远程 UI 配置、跨端 UI 协议等通用场景。
二、为什么要设计 TokUI
向量空间 JBoltAI 设计 TokUI 的核心动因，是当前 AI 产品中普遍存在的能力与表达错配。现有 UI 方案大多诞生于传统互联网时代，并未针对大模型的输出特性优化，无法很好地适配 AI 场景的需求，具体体现在四个方面。
模型能力持续提升，但 UI 表达形式停滞
其一，模型能力持续提升，但 UI 表达形式停滞。大模型已经具备生成代码、处理表格、生成可视化内容、调用工具的能力，但最终呈现给用户的，往往还是逐行铺开的纯文本或 Markdown 内容，形成密集的文字墙。Markdown 仅能解决基础的文档可读性，无法承载可交互的表格、实时更新的图表、可提交的表单，也无法直观展示智能体的工具调用进度与推理过程，信息表达效率和交互体验都存在明显局限。
HTML 方案冗余度高，不符合 Token 经济特性
其二，HTML 方案冗余度高，不符合 Token 经济特性。理论上 AI 可以直接输出 HTML 实现富 UI，但 HTML 原本面向人工编写与浏览器解析设计，并未考虑按 Token 计费的使用场景。大量开闭标签、冗余属性会带来较高的 Token 消耗，在规模化调用场景下会提升生成成本，同时 HTML 原生也难以实现边生成边渲染的流式体验。
结构化输出方案无法支持流式渲染
其三，结构化输出方案无法支持流式渲染。通过结构化 JSON 驱动 UI 是常见的实现思路，但 JSON 的语法特性决定了它必须完整接收后才能正确解析，一旦结构不闭合就会解析失败。这就导致 AI 生成 UI 时，用户需要等待全部内容输出完成才能看到完整界面，失去了流式输出带来的即时反馈感，与 AI 对话的交互特质相悖。
传统前端方案依赖沉重，与轻量嵌入需求不符
其四，传统前端方案依赖沉重，与轻量嵌入需求不符。如果要在对话场景中实现富 UI 渲染，常规方案需要引入前端框架、组件库、图表库、解析器等一整套技术栈，对于仅需补充基础交互能力的场景来说体量过重，也提升了集成与维护的成本。
针对这些行业共性问题，向量空间 JBoltAI 给出的解决方案，是打造一套专为流式输出而生、适配 Token 经济模式、原生支持交互、零运行时依赖的 UI 描述语言。并非让 AI 去适配传统 UI 表达方式，而是为 AI 的输出特性重新设计 UI 的表达介质，从底层对齐大模型逐 Token 生成的节奏。
TokUI 的全部技术设计与能力建设，都围绕 AI 原生场景的核心需求展开，为 AI 时代的 UI 交互提供了新的实现路径。
