LLM 数据可视化：从“硬编码”到“Generative UI”的五种范式

声明：本文在写作过程中使用了AI辅助工具进行资料整理、结构优化与语言润色。核心观点、技术判断与工程经验均为作者原创。

一、问题：卡在渲染层

项目里有这样一条链路：用 LLM 按指定的 schema 抽取领域数据（structured output），拿到结构化数据后，前端写代码把它渲染出来：

ts 复制代码

type SalesRow = { region: string; revenue: number; quarter: string }

function RevenueByRegion({ data }: { data: SalesRow[] }) {
  return <BarChart data={data} x="region" y="revenue" />  // 图型、维度全硬编码
}

需求固定时，系统很稳定。但随着业务可视化需求越来越多------换图表类型、加下钻、切维度------每次都要改代码、发版本，前端成了扩展的瓶颈。本文是我在做技术调研时的总结。

本质上，我们把"怎么画"这件事 100% 硬编码在业务代码里，而 LLM 只负责输出数据。

二、核心原则：声明式 > 命令式

调研下来，整个"LLM 可视化"领域可以收敛成一条主线：

模型产出受约束的结构化描述 → 中立中间表示 → 宿主在安全边界内渲染。

差别只在于："渲染"这件事，把它放在链路的哪一层、交给谁决定。我们现在的做法是把渲染权 100% 攥在业务代码手里；而往后每一种"更灵活"的方案，都是在把一部分"画什么"的决定权，从代码移交给 LLM------代价是，要建立新的"安全边界"来接住它。

这里有一条贯穿全篇的工程原理，对选型极其关键：

声明式 > 命令式

让模型产出"数据↔图元的映射"（如 Vega-Lite 的 mark + encoding），坐标轴、图例自动补全；而不是让模型写"怎么算坐标、怎么操作 DOM"的命令式代码。

原因有三：

模型只需表达"画什么"；
受限语法能做 schema 校验，幻觉少、省token；
输出是 JSON，能 diff、能版本控制。

基于此，五种范式的取舍就清楚了。

三、五种范式演进图

把"渲染决定权"从左到右逐步交给 LLM，正好是一条从我们现状出发的演进路径：

范式 0：硬编码渲染

LLM 只产领域数据，前端用固定组件渲染。控制力最强，也最死板。AG-UI 管这种叫 Static Generative UI。这种做法并没有错，只是不为"需求频繁扩展"而生。

范式 A：声明式图表 spec

让 LLM 在产出领域数据的同时，额外产出一份 Vega-Lite / ECharts 的图表 spec；前端写一个通用的 spec 渲染器，从此不再为每张图改代码。

ts 复制代码

const spec = {
  mark: "bar",
  encoding: { x: { field: "region" }, y: { field: "revenue" } }
}
<VegaLite spec={spec} data={data} />   // 通用渲染器，几乎不用再改

新需求 = 改 prompt ，不改代码。

Vega-Lite 这类交互图形的高层语法天生适合做 LLM 输出的中立中间表示：JSON 紧凑、可校验、可移植。对已经有 schema 化数据的项目，这是改动最小、收益最直接的一步。

适用：图表类需求为主，想最快解耦"图型"与"代码"。

代价：表达力受限于图表语法，做不了任意布局/交互。

新动态 ：MCP 生态已有图表类 Server（mcp-echarts、mcp-server-chart），整条链路封装成标准工具，落地成本在下降。

范式 B：组件树 Generative UI

比"一张图"更进一步：让 LLM 产出一棵 UI 组件树（{$type, props, children} 的 JSON），前端维护一个组件白名单（allowlist / registry），校验通过后再挂载。这样模型能自由组合"卡片 + 表格 + 图表 + 布局"，但能渲染什么由白名单决定------这就是安全边界。

这正是assistant-ui、AG-UI 的 Declarative Generative UI 范式：agent 提议组件树与约束，由应用校验后挂载。相比范式 A，它从画一张图 升级到拼一个界面。

适用：组合式仪表盘、动态布局。

代价：要设计组件协议、建白名单、做校验，工程量上一个台阶。

新动态 ：Google 的 A2UI 协议走的正是这条路------Agent 发组件蓝图，宿主本地 1:1 渲染。与 AG-UI 互补：AG-UI 管事件流，A2UI 管组件协议。

范式 C：代码产物 + 沙箱渲染（Claude Artifacts 范式）

直接让 LLM 产出 HTML/JS/React 代码，前端在沙箱 iframe 里渲染。灵活性拉满------任意交互、任意图库都行；但安全/可控性最差，必须靠沙箱隔离。Claude Artifacts、ChatGPT 的代码执行、AI编程工具的 Canvas/Preview 走的都是这条路。

适用：探索型、一次性、高自由度产物。

代价：安全边界全压在沙箱上；产物难纳入既有设计系统。

新动态 ：Anthropic 2026 年 1 月发布的 MCP Apps （SEP-1865）把这范式协议化了------MCP Server 返回交互式 UI 定义，宿主 iframe 渲染，但用预定义组件 schema 而非任意 HTML，安全性高一档。Claude、ChatGPT、Copilot、Cursor 已支持。

范式 D：协议化解耦（AG-UI / MCP Apps / A2UI）

前面几种绑定在"某一个前端"上。要跨平台复用，得把"输出 UI"标准化：

AG-UI：事件化的 agent ↔ 前端协议，把 generative UI 以标准事件流推给任意应用；
MCP Apps / MCP-UI：MCP 负责 agent ↔ 工具与数据，MCP Apps 让工具直接回传可在沙箱 iframe 渲染的 UI 资源；
A2UI：Google 的 agent ↔ UI 原生组件蓝图协议，强调"宿主本地渲染"而非沙箱隔离；
A2A：agent↔agent 分层。

它的价值不在"画得更好"，在**"画的能力"与"具体前端"解耦**。

生态现状：AG-UI 由 CopilotKit 发起并维护导，Google、Microsoft、Amazon、Oracle 等已采纳。A2UI 由 Google 推动。MCP Apps 由 Anthropic/Linux Foundation 背书。三者不是竞争关系，而是互补分层------AG-UI 管事件流，A2UI 管组件协议，MCP Apps 管工具侧 UI 交付。一个完整的系统可能同时用到其中两个或三个。

四、选型矩阵

范式	LLM 产出	渲染层	控制力	灵活性	跨平台	改需求成本
0 硬编码	领域数据	硬编码组件	★★★★★	★	★	改代码+发版
A 声明式 spec	数据+图表 spec	通用渲染器	★★★★	★★★	★★★★	改 prompt
B 组件树	UI 组件树 JSON	白名单 registry	★★★	★★★★	★★★	改 prompt+扩白名单
C 代码产物	前端代码	沙箱 iframe	★★	★★★★★	★★	改 prompt
D 协议化	标准事件流/蓝图	协议渲染层	★★★	★★★★	★★★★★	改 prompt

五、可信度与安全

把渲染权交给 LLM，引入了两个范式0没有的新风险：

可信度：生成的图"对不对"？

学术界已经有成熟评测可借鉴：微软 VisEval 把 "自然语言→可视化"的质量拆成三维------validity（有效性）/ legality（合法性）/ readability（可读性），用自动化 checker 评估；nvBench 2.0 还聚焦于歧义性（一个查询可能对应多个合理图）。落到工程上，至少要做：spec 的 schema 校验 + 字段/聚合口径的校验。若数据涉及指标，语义层（semantic layer）------把「指标口径、字段含义」沉淀为可治理的一层------是让生成结果可信、一致、可复用的关键。

新工具：VegaChat 框架提出了 Spec Score + Vision Score 的双维度评估，直接在声明式 spec 层面做正确性判断，不需要等渲染成图再用多模态模型看------这对工程化流水线非常友好。

安全：渲染权让渡到哪，边界就建到哪

范式	边界
A	spec schema 白名单（限定 mark/encoding）
B	组件 allowlist + props 校验
C	沙箱 iframe + MCP Apps 预定义组件 schema
D	协议级校验（AG-UI 事件过滤、A2UI 蓝图 schema）

"让模型描述、宿主在 allowlist/schema/sandbox 下渲染"，这是 Generative UI 区别于"让模型随便写代码执行"的本质。

六、为什么可视化是"结构化生成"的最佳试金石

将这个系列的文章连起来看：

篇目	核心问题	解决思路
别让 LLM 写文件）	写文件丢数据、并发冲突	状态住进程，LLM 只提意图
本文	可视化场景里，Harness 长什么样	五种范式 = 五种让渡渲染权的粒度

可视化是校验链最完整、收益最直观的场景。 跑通了它，报告生成、配置下发、UI 编排都是同一条思路的平移。

七、后续预告

这篇是地图。接下来我将按范式逐个动手：

声明式spec：LLM 产 Vega-Lite/ECharts spec，搭通用渲染器，含 schema 约束与 few-shot；
组件树GenUI：设计组件协议 + 白名单 registry，参考 AG-UI / A2UI；
代码产物沙箱：Artifacts 与 MCP Apps 的沙箱渲染；
协议化：AG-UI / MCP Apps / A2UI 跨平台解耦；
可信度与评测：VisEval + VegaChat Spec Score + 语义层。

如果你也卡在"LLM 输出数据、前端手写渲染"，欢迎一起往后走。

参考资料

AG-UI：https://docs.ag-ui.com/introduction
assistant-ui：https://www.assistant-ui.com/
Vega-Lite：https://vega.github.io/vega-lite/
Claude Artifacts：https://claude.com/blog/artifacts
MCP Apps（SEP-1865）：https://github.com/modelcontextprotocol/specification
A2UI：https://a2ui.dev/
MCP 图表 Server：mcp-echarts｜mcp-server-chart
VisEval：https://arxiv.org/abs/2407.00981
nvBench 2.0：https://arxiv.org/abs/2503.12880
LIDA：https://arxiv.org/abs/2303.02927
VegaChat：https://arxiv.org/abs/2601.15385