项目里有这样一条链路用 LLM 按指定的 schema 抽取领域数据structured output拿到结构化数据后前端写代码把它渲染出来type SalesRow { region: string; revenue: number; quarter: string } function RevenueByRegion({ data }: { data: SalesRow[] }) { return BarChart data{data} xregion yrevenue / // 图型、维度全硬编码 }需求固定时系统很稳定。但随着业务可视化需求越来越多——换图表类型、加下钻、切维度——每次都要改代码、发版本前端成了扩展的瓶颈。本文是我在做技术调研时的总结。本质上我们把“怎么画”这件事 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 渲染器从此不再为每张图改代码。const spec { mark: bar, encoding: { x: { field: region }, y: { field: revenue } } } VegaLite spec{spec} data{data} / // 通用渲染器几乎不用再改新需求 改 prompt不改代码。Vega-Lite 这类交互图形的高层语法天生适合做 LLM 输出的中立中间表示JSON 紧凑、可校验、可移植。对已经有 schema 化数据的项目这是改动最小、收益最直接的一步。适用图表类需求为主想最快解耦“图型”与“代码”。代价表达力受限于图表语法做不了任意布局/交互。新动态MCP 生态已有图表类 Servermcp-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 AppsSEP-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-UIMCP 负责 agent ↔ 工具与数据MCP Apps 让工具直接回传可在沙箱 iframe 渲染的 UI 资源A2UIGoogle 的 agent ↔ UI 原生组件蓝图协议强调“宿主本地渲染”而非沙箱隔离A2Aagent↔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通用渲染器★★★★★★★★★★★改 promptB 组件树UI 组件树 JSON白名单 registry★★★★★★★★★★改 prompt扩白名单C 代码产物前端代码沙箱 iframe★★★★★★★★★改 promptD 协议化标准事件流/蓝图协议渲染层★★★★★★★★★★★★改 prompt五、可信度与安全把渲染权交给 LLM引入了两个范式0没有的新风险可信度生成的图“对不对”学术界已经有成熟评测可借鉴微软 VisEval 把 “自然语言→可视化”的质量拆成三维——validity有效性/ legality合法性/ readability可读性用自动化 checker 评估nvBench 2.0 还聚焦于歧义性一个查询可能对应多个合理图。落到工程上至少要做spec 的 schema 校验 字段/聚合口径的校验。若数据涉及指标语义层semantic layer——把「指标口径、字段含义」沉淀为可治理的一层——是让生成结果可信、一致、可复用的关键。新工具VegaChat 框架提出了 Spec Score Vision Score 的双维度评估直接在声明式 spec 层面做正确性判断不需要等渲染成图再用多模态模型看——这对工程化流水线非常友好。安全渲染权让渡到哪边界就建到哪范式边界Aspec schema 白名单限定 mark/encodingB组件 allowlist props 校验C沙箱 iframe MCP Apps 预定义组件 schemaD协议级校验AG-UI 事件过滤、A2UI 蓝图 schema“让模型描述、宿主在 allowlist/schema/sandbox 下渲染”这是 Generative UI 区别于“让模型随便写代码执行”的本质。六、为什么可视化是“结构化生成”的最佳试金石将这个系列的文章连起来看篇目核心问题解决思路别让 LLM 写文件写文件丢数据、并发冲突状态住进程LLM 只提意图本文可视化场景里Harness 长什么样五种范式 五种让渡渲染权的粒度可视化是校验链最完整、收益最直观的场景。跑通了它报告生成、配置下发、UI 编排都是同一条思路的平移。七、后续预告