微软研究院联合中国人民大学IDEAS Lab，开源了一个叫Flint的项目，定位是"面向AI Agent的可视化语言"。它不直接生成图表，而是先生成一份十几行的中间规格，再由编译器把规格翻译成Vega-Lite、ECharts、Chart.js三种后端能直接渲染的完整配置。项目已经开源，可通过npm安装，也提供MCP server，方便接入AI Agent的工作流。
这件事的分量不在于又多了一个画图工具，图表库市面上从不缺。它想解决的是一个更窄但更实际的问题：现在让大模型自己写Vega-Lite或ECharts的底层配置，本质上是在赌——scale、axes、配色这些参数写错一处，图就变形，调试成本经常比手写还高。对做BI嵌入、自动报表的团队来说，这决定了以后敢不敢把图表生成这一环完全交给Agent。
发生了什么：规格只有三块，编译器补全底层参数
Flint的规格拆成三部分：data（数据）、semantic_types（语义类型）、chart_spec（图表定义与编码）。
语义类型是关键。把某一列标成YearMonth、Category、Profit或Temperature，编译器就据此推导坐标轴解析方式、配色方案，判断正负值要不要用发散色。
官方给的例子里，一份不到20行的Flint规格，编译展开后是几十行带精确domain、scale、颜色中点的Vega-Lite配置。
换图表类型也更轻。官方演示把一张按性别、年龄分面的柱状图，改成人口金字塔图，只改了chartType和编码绑定，其余参数由编译器重新推导。这和直接手写配置比，省的是重写一整套低层参数的力气。
为什么重要：省的是调试成本，不是画图能力
传统路径下，大模型直接写Vega-Lite或ECharts配置，写错一处轴或配色，往往要靠人工回头调试，短则改几行，长则推倒重写。
Flint把这段试错挪到编译器里做，前提是语义类型标注正确。这不等于AI"理解"了业务含义，只是编译器按标注好的类型套用了成熟的可视化规则。
对做数据产品、BI嵌入的团队，这意味着可以先小范围试——挑一两类高频报表场景接入Flint的MCP server，看语义标注能不能覆盖自己的数据模型，再决定要不要把更多图表生成逻辑迁过去。
限制在哪：后端能力不对等，标注错了照样白搭
三个后端渲染能力并不一样。官方举的例子是，Vega-Lite没有原生旭日图（sunburst），想用就得切到ECharts——"统一接口"不等于三个后端画得出同样的图。
| 维度 | Vega-Lite | ECharts | Chart.js |
|---|---|---|---|
| 旭日图（sunburst） | 无原生支持 | 支持 | 官方示例未提及 |
| 风格定位 | 声明式统计图表 | 复杂交互、大屏仪表盘 | 轻量前端嵌入 |
更根本的限制是数据本身。如果一列时间字段没标成YearMonth，或者该体现涨跌的数字没标成Profit，编译器照样推不出对的坐标轴和配色。企业级权限、数据治理、复杂交互，都不在Flint的能力范围内，它不是一整套BI工作流的替代品。
对负责BI嵌入和自动化报表的团队，接下来最该盯的不是Flint支持多少种图表，而是自己的数据模型能不能干净标出语义类型——这决定了接入之后，图表生成到底能省多少适配成本，还是又多了一层要维护的标注体系。