devgo.cn如果你的团队正在用编码 Agent（能理解自然语言并写代码的 AI 助手）做数据分析，大概率会遇到两个头疼的问题：一是 Agent 写出来的 SQL 经常算错指标，同一个“营收”在不同报表里口径不一；二是它生成的图表样式五花八门，像几个实习生各写各的。Graphene 这个新开源项目，就是冲着这两个痛点来的。它的核心思路是“一切皆代码”：把数据模型、指标定义、可视化页面全部写成项目里的普通文件，让 Agent 像改代码一样改报表。
Graphene 提供了两块关键能力。第一块是语义层，名叫 Graphene SQL。传统 BI 工具的语义层（负责把业务指标翻译成数据库查询的中间层）通常很封闭，只暴露一套小众的查询 API，Agent 根本不熟悉。Graphene SQL 的做法是：它看起来就是普通 SQL，支持 CTE（公用表表达式，一种把复杂查询拆成临时结果集的写法）、子查询、窗口函数、集合操作等标准能力，但额外引入了“度量”（measure，比如 revenue 定义为 sum(amount)）和“建模关联”（modeled join，比如订单表和用户表的一对多关系）这两个概念。你在模型文件里定义好这些业务逻辑，查询时直接引用，Agent 就不需要每次重复写聚合逻辑，也不容易算错。这个设计灵感来自 Malloy（LookML 作者做的查询语言），但 Graphene 把它实现成了 Agent 更熟悉的普通 SQL 语法。
第二块是仪表盘文件类型。Graphene 的页面用 Markdown 编写，里面可以嵌入 SQL 代码块和可视化组件标签，比如 `<BarChart data="top_customers" x="name" y="revenue" />`。这种声明式写法比直接用 Python 的 matplotlib 或 JavaScript 的 ECharts 写图表代码要简洁得多，而且样式统一。Graphene 页面还支持输入组件（比如下拉筛选框）和多种布局模式，既能做监控大屏，也能做叙事型报告。
Graphene 的设计目标很明确：token 效率（语言尽量简短，减少 Agent 的 token 消耗）、Agent 友好（完全通过 CLI 控制，文档以 agent skill 的形式随 npm 包分发，Agent 可以直接读取）、高天花板（SQL 支持 170+ 函数，页面支持任意 HTML/CSS/JS/ECharts 表达式）。它目前支持 Snowflake、BigQuery、ClickHouse、Postgres、MotherDuck 和本地 DuckDB 作为数据源。
为什么作者认为“编码 Agent + 一切皆代码”能打败传统 BI？核心是上下文。如果 BI 栈就放在公司代码仓库里，和业务代码、数据管道放在一起，Agent 就能理解它该分析什么、为什么重要。反过来，当 Agent 在开发新功能时，也能直接引用历史分析结果来支撑决策。另一个关键点是避免锁定：所有文件都在你的仓库里，你可以用任何 Agent 或 LLM，数据不会被关在某个 SaaS 工具的私有格式里。
最让我意外的是 Graphene 对“数据团队会不会失业”这个问题的回答。作者认为数据专家的角色会从“手动建报表”变成“塑造技能、模型和工具”，去指导 Agent 如何处理公司里最棘手、最模糊的数据问题——那些仍然需要数据专家品味才能得到好答案的问题。这其实是对“AI 取代工作”的一种更务实的看法：不是取代，而是把工作重心从执行层上移到定义层。
如果你正在用编码 Agent 做数据工作，或者想给团队搭一套“AI 原生”的分析基础设施，Graphene 的思路可以直接借鉴：把指标定义成代码里的确定性对象，让 Agent 在查询时直接调用，而不是每次重新写聚合逻辑；把可视化页面也变成代码，用声明式组件保证一致性。需要注意的坑是：Graphene 目前要求你使用 git 和编码 Agent 才能发挥全部价值，纯业务人员上手门槛不低；另外它用的是 Elastic License 2.0，内部使用免费，但想基于它做商业应用需要联系作者。总的来说，这是一个值得关注的方向——它把 BI 从“工具”变成了“代码库的一部分”，让数据分析真正融入开发流程。
内容与图片版权归原作者所有 · 原文: https://github.com/graphene-data/graphene