TokUI：为AI时代而生的真流式UI引擎

引言

当大模型已经能写论文、画图表、调起工具，用户在对话框里看到的，却依然是一堵缓慢铺开的文字墙。

TokUI想回答一个问题：如果AI的输出本身就是一串Token，那么从「Token」到「可交互的富UI」之间，能不能不存在那道鸿沟？

一、TokUI是什么

TokUI是一个零依赖的流式UI描述与渲染框架。它用极简的DSL（领域特定语言）描述组件，经SSE或WebSocket流式推送，前端基于状态机增量解析——首个Token到达即开始渲染为真实DOM。

它的核心场景是AI对话中的流式UI生成，同时其协议设计天然兼容低代码平台、远程UI配置、跨端UI协议等通用场景。

三层数据流

text

后端TokUIBuilder生成DSL → SSE/WebSocket推送 → 前端TokUIParser增量解析 → TokUIRenderer渲染DOM

同一套组件语义贯穿前后端：Builder在服务端把结构化数据编译成DSL字符串，Parser在前端用状态机把字符流增量解析成节点树，Renderer把每个节点翻成真实DOM，并接管交互、主题、容错。

与技术版图中的其他方案对比

 

 

维度	HTML	Markdown	JSON Schema	TokUI DSL
Token成本	高（标签冗长）	低	高（嵌套引号多）	极低
流式友好	否（必须闭合）	部分（逐行）	否（需完整JSON）	是（逐字符）
可交互	是	否	依赖运行时	是（原生）
AI生成成本	高	低	中	低

TokUI不是HTML的替代品，也不是Markdown的升级版——它是为「AI流式输出」这一全新场景专门设计的第三种UI表达介质。

二、为什么要设计TokUI

TokUI的诞生，源于当前AI产品中四个被普遍忽视的「错配」。

错配一：模型能力在飞跃，UI表达却停滞

大模型已经能写代码、做表格、画图表、调工具，但所有这些能力，最终都要坍缩成一段Markdown或纯文本，挤在聊天框里慢慢铺开。Markdown解决了「文档的可读性」，却没解决「交互」——它不能渲染可勾选的表格行，不能流式画折线图，不能展示Agent正在调用哪个工具、进度如何。

错配二：HTML太重，Token时代扛不住

HTML是为「人手写+浏览器解析」设计的，不是为「按Token计费」设计的。同样一张带斑马纹的表格，HTML需要大量冗余标签，而TokUI只需要极简的几行描述。相同UI的Token消耗，TokUI远低于HTML或JSON Schema——在百万级Token的生产成本面前，这不是优化，是刚需。

错配三：结构化输出（JSON）不能流式

Function Calling让模型能输出结构化JSON，但JSON有一个致命缺陷：它必须完整到达才能解析。一个{没闭合，整个结构就解析失败。于是AI生成UI的体验变成了：用户盯着转圈，等几十秒，然后「啪」地一次性渲染出整个界面——这完全违背了AI对话最迷人的特质——逐字流式、即时反馈。

错配四：前端依赖沉重，与「轻量AI嵌入」相悖

想在对话里渲染富UI，常见做法是塞一个React/Vue + 组件库 + 图表库 + Markdown解析器。这套技术栈对于一个「只想给AI回复加一点交互」的场景来说，过重了。

一个设计回应四个错配

给AI一种为流式而生、为Token经济而设计、原生可交互、零依赖的UI描述语言。

它不是让AI学会写HTML，而是发明一种新的、与AI输出节奏天然对齐的UI介质。

三、设计哲学：From Token to UI

TokUI围绕三条不可妥协的设计原则展开。

原则一：流式优先（Stream-First）

这是TokUI区别于一切「UI框架」的根本。传统UI框架假设数据是完整的、一次性的。但AI的输出是逐Token的、不完整的、随时可能中断的。TokUI的解析器从第一行代码起，就为「输入随时在任意位置被切断」而设计——它的状态机在三个状态间切换，任何一个字符到达都能推进状态，不需要等待完整结构。

这意味着[card tt:到达时，卡片容器就已经被创建并插入DOM；后续子节点陆续填充。首屏即现，无需等待闭合。 这是「真流式」，不是「分块批量渲染」伪装的流式。

原则二：Token经济（Token Economy）

TokUI的DSL是为按Token计费的时代逆向优化的：

• 属性简写：tt（title）、tx（text）、clk（onclick）、ph（placeholder）

• 布尔属性只写key：stripe、dis、req，不需要="true"

• 逗号多值：v:"primary,sm"一行表达多个变体

• 内容即正文：[h1 这是一个标题]，没有冗余标签对

结果是：相同UI的Token消耗，TokUI远低于HTML或JSON Schema。

原则三：语言无关的UI协议

TokUI不是「前端框架」，它是一套贯穿前后端的UI协议。服务端Builder、前端Parser、Renderer共享同一份组件类型清单和属性语义。DSL字符串就是这条协议的序列化形式——人类可读、网络可传、AI可生成。

无论后端是Node.js、Python、Rust、Java还是Go，只要输出符合同一套DSL，就能驱动同一个前端。 TokUI不强行绑定任何编程语言，它天然适用于任何大模型业务开发的技术栈。

四、核心技术特点

零依赖

前后端均为原生API，运行时不引入任何npm包。图表用纯SVG手绘，代码高亮用自写tokenizer覆盖11种语言，Markdown解析、主题系统、事件总线全部自研。零依赖意味着TokUI可以被塞进任何已有项目、任何CDN <script>、任何无构建环境，不污染依赖树、不引发版本冲突。

真流式增量解析与渲染

状态机（TEXT / TAG_OPEN / TAG_CLOSE）逐字符推进；feed(chunk)增量喂入，立即解析并渲染；容器开标签到达即创建DOM并入栈，子节点陆续填充；单块增量解析<1ms，首Token即开始绘制。

150+开箱即用组件

覆盖基础布局、表格、表单、图表、对话气泡、工具调用、代码差异等七大类，开箱即能覆盖主流AI产品的全部交互形态。

事件安全模型——零注入风险

DSL不含任何可执行代码，事件处理器全部是命名引用，需预先registerHandler注册。DOM创建时过滤所有on*属性和formaction，全库仅两处使用innerHTML且均做了净化处理。AI输出什么，都不会变成宿主页面的可执行代码——这是可以被放进生产AI产品的安全底线。

容错降级

未注册组件渲染为div.tokui-unknown，渲染抛错生成降级显示。单点错误不炸整页，流式过程始终稳健。

五、关键技术突破

1. 字符级真流式状态机

市面上很多号称「流式渲染」的方案，本质是把完整JSON切成块分批发送——一旦块边界劈开标签或引号就崩了。TokUI的解析器是字符级真流式：状态可中途暂停，无论输入在哪个字符被切断，下一次feed到来时都能从断点继续。

2. 代码块/终端的真流式逐字渲染

代码块内的[不应该被解析成标签。TokUI解决了半截闭标签的回持、转义序列被chunk劈开、增量emit避免重复等棘手问题——代码块是真正的逐字流式高亮，而不是等到[/code]才一次性吐出。

3. 嵌套容器的隐式闭合——容错AI的「坏习惯」

AI写DSL时常带HTML肌肉记忆——写<li>不闭合、容器标签跨行漏写]。TokUI用隐式闭合机制对齐HTML的容错语义：兄弟item隐式闭合、p自动闭合对标HTML<p>、容器跨行漏写]的引号感知补全。这套机制的本质是把「严格语法」降级为「宽容解析」，吃下真实AI输出的所有毛刺。

4. 图表的流式预览

图表数据量大、闭合晚，如果等整个标签闭合才渲染，图表区域会长时间空白。TokUI实现了半成品的流式预览：柱状图逐根长出、甘特图任务条逐条增长、饼图逐块填充——图表和文字一样是流式的。

5. 流式渲染的插槽栈

流式渲染下DOM是「边收边长」的。TokUI用slotStack管理嵌套容器的挂载位置：新元素始终挂到栈顶容器的_slot。流式关闭钩子解决延迟初始化问题——像picker、transfer这类组件，在所有子元素就绪后才绑定交互。

六、应用场景

AI对话产品的富UI回复（核心场景）

一个真实的AI回复不再是纯文本，而是一组流式渲染的对话组件——思考过程可折叠展开、工具调用卡片展示状态、图表逐根长出、表格逐行刷入、来源引用可点击跳转。

AI Agent与工具调用的可视化

Agent执行多步任务时，每一步都在流式演进。TokUI的agent/tool-call/plan/think-chain组件支持流式状态更新，让用户实时看到「正在调用→调用成功」的状态流转。

数据分析与BI报告的流式生成

让AI直接「画出」一份报告——指标卡先到、图表逐根长出、表格逐行刷入、结论最后弹出。

低代码平台与远程UI配置

同一套DSL既可以由AI生成，也可以由可视化编辑器生成、由配置中心下发、由多端运行时消费。

跨语言后端统一UI协议

无论后端是什么技术栈，只要输出符合TokUI DSL规范，就能驱动同一个前端。 TokUI正在成为一层语言无关的UI中间件。

七、写在最后

互联网的UI，过去三十年是「人写、机器渲染」。AI时代，UI正在变成「机器生成、人交互」。而生成的方式，应该是流式的、经济的、安全的、可交互的。

TokUI想做的，就是这四件事的底层介质。

From Token to UI.
让AI用极少的Token，流式生成富UI。

---

TokUI采用MIT协议开源，零依赖，克隆即用。项目由向量空间JBoltAI团队开发并开源