一、ChatBI 的天花板在哪里？

ChatBI 无疑是近两年 BI 行业最火的概念。用自然语言问数据、查指标，听起来太美好了——不再需要学 SQL，不再需要拖拽图表，开口就能得到答案。但如果你在实际工作中用过 ChatBI，大概率会遇到这样的场景：

你问"上个月华东区的销售额是多少"，ChatBI 给出了正确答案。然后你追问"和上上个月比呢"，ChatBI 说"抱歉，我无法理解您的问题"。或者你问"华东区销售额下降的原因是什么"，ChatBI 给出了一段车轱辘话，毫无可操作性。

问题出在哪里？大多数 ChatBI 产品只解决了"Ask"这一个环节——把自然语言翻译成 SQL，执行查询，返回结果。但数据分析的真实流程远不止于此。一个完整的数据分析工作流至少包含三个阶段：

1. Ask（提问）：理解业务问题，匹配正确的数据口径，生成准确的查询

2. Model（建模）：数据准备、清洗、关联、指标建模、维度设计

3. Deliver（交付）：可视化呈现、报表制作、报告生成、洞察提炼

只做 Ask 的 ChatBI，充其量是一个"数据搜索引擎"。而衡石提出的 Agentic BI，目标是让 AI Agent 覆盖整个 Ask → Model → Deliver 链路，成为真正的"数据工作助手"。

---

二、什么是 Agentic BI？和传统 BI、ChatBI 有什么区别？

Agentic BI 的"Agentic"来自 AI Agent（智能体）的概念。和传统的 LLM 对话不同，AI Agent 具备三个核心特征：感知上下文、使用工具、执行动作。

在 BI 场景下，这三个特征意味着：

• 感知上下文：Agent 不只是理解你当前的问题，还能理解你的业务背景、数据结构、历史分析习惯

• 使用工具：Agent 可以调用数据连接、SQL 生成、图表渲染、报告排版等各种工具

• 执行动作：Agent 不只是"告诉你答案"，还能"帮你做完"——创建仪表盘、更新报表、发送报告

对比三种范式：

维度	传统 BI	ChatBI	Agentic BI
交互方式	拖拽式 / 编码式	自然语言问答	自然语言 + 自动执行
覆盖范围	可视化 + 报表	数据查询	Ask + Model + Deliver 全流程
执行主体	人	人 + AI 生成 SQL	AI Agent 为主体，人审核
产出物	仪表盘 / 报表	查询结果	仪表盘 / 报表 / 分析报告
技术依赖	BI 引擎	LLM + NL2SQL	LLM + Agent 执行层 + BI 引擎

三、衡石 Data Agent Family：三个专业化 Agent 各司其职

衡石的 AI 分析智能体不是一个泛化的"万能 Agent"，而是拆分成了三个专业化 Agent，形成 Data Agent Family：

Agent 01：数据问答 Agent

定位是"面向 DBA 和数据科学家的编码处理工作台"。它不只是简单的问答，而是一个数据工程助手。比如你让它"帮我创建一个数据集，包含过去 12 个月的订单数据，按月汇总，关联客户信息"，它会自动完成数据集的创建和 SQL 逻辑。生成的数据集结果可以直接展开建模分析和可视化创作。

技术上的核心挑战在于NL2Metrics——不是简单地把自然语言翻译成 SQL，而是翻译成基于指标语义层的查询。这意味着 Agent 需要先理解"销售额"对应的指标定义（是含税还是不含税？是下单金额还是实收金额？），然后再生成正确的查询。

Agent 02：可视化创作 Agent

这个 Agent 负责仪表盘和大屏的创作。你告诉它"帮我做一个华东区域销售驾驶舱，包含月度销售趋势、客户分布地图、TOP10 产品排行、同比增长率"，它会自动规划页面布局、选择合适的图表类型、创建图表并组装成仪表盘。

它覆盖的能力包括：数据源连接、数据集配置、仪表板创建、图表生成，全部通过拖拽和配置实现，也支持数据科学家和高级程序员通过编码方式处理更复杂的场景。预置函数和模型开盒即用，降低了创作门槛。

Agent 03：建模 Agent

面向业务人员的零代码建模助手。业务人员不需要懂 SQL，通过自然语言描述就能完成数据建模——"把订单表和客户表按客户 ID 关联，创建一个'客户购买力'指标，定义为过去 12 个月的累计订单金额"。Agent 会自动完成表关联、字段选择、指标计算等建模操作。

---

四、NL2Metrics：ChatBI 准确度的技术基石

ChatBI 最大的痛点是准确度。用户问"上个月的 GMV"，如果 AI 翻译的 SQL 用错了字段（比如用了含退款的数据），结果就会误导业务决策。

衡石的解决方案是 NL2Metrics——不是把自然语言直接翻译成 SQL，而是先翻译成指标查询。中间经过一层指标语义层（Metrics Semantic Layer），这层语义层用 HQL（Hengshi Query Language）定义了每个指标的确切计算逻辑。

流程是这样的：

1. 用户问"上个月华东区的 GMV 是多少"

2. NL2Metrics 引擎将问题拆解为：时间范围=上月，区域=华东，指标=GMV

3. 在指标语义层中查找"GMV"的定义：SUM(order_amount) WHERE order_status != 'cancelled'

4. 基于指标定义生成最终的查询，加入时间和区域的过滤条件

5. 执行查询并返回结果

这个过程中，指标语义层起到了"护栏"的作用——不管用户怎么问，最终计算的口径都是由指标定义决定的，AI 不会"自由发挥"。

---

五、HENGSHI CLI：Agent 的"手和脚"

光有"大脑"（NL2Metrics + LLM）还不够，Agent 还需要"手和脚"来执行具体的 BI 工程操作。这就是 HENGSHI CLI 的定位——面向 AI Agent 的 BI 命令行执行层。

CLI 提供了一套标准化的命令体系（以 hbi 为入口），覆盖数据连接管理、数据集创建、HQL 查询、仪表盘生成、权限管理等 BI 工程全链路。AI Agent 通过调用这些命令来完成实际的 BI 操作，而不是通过临场猜 API 接口来操作。

更重要的是，CLI 内置了 --dry-run 预演机制和 SSE 实时回显。Agent 执行的每个操作在真正生效前可以先"预演"一遍，运维人员确认无误后才正式执行。执行过程中，前端的 Web UI 可以实时看到 Agent 的操作进度和结果——这就是衡石定义的"machine executes, humans verify"人机协同模式。

---

六、从"人找数据"到"数据找人"：Agentic BI 的终极形态

Agentic BI 的真正价值，不只是让数据查询更方便，而是改变数据消费的模式。

传统 BI 的模式是"人找数据"：业务人员需要主动打开报表、拖拽筛选器、阅读数据，才能获取洞察。即使有了 ChatBI，也是人主动提问、AI 被动回答。

而 Agentic BI 的终极形态是"数据找人"。常驻型 Agent 会持续监控业务指标，当发现异常时主动预警并推送分析报告。比如每天早上自动生成"昨日经营简报"并推送到钉钉群，当华东区销售额同比下滑超过 15% 时自动触发归因分析并通知区域负责人。

衡石的 HENGSHI BOX 已经在实现这个场景——内置的常驻型 Agent 可以完成定时报告推送、异常监测预警等自动化任务，让数据洞察从"被查询"变为"被推送"。

---

七、给数据团队的建议：如何落地 Agentic BI？

如果你正在考虑在组织中落地 Agentic BI，以下是一些实践建议：

• 先建指标语义层：Agentic BI 的准确度依赖指标定义的完整性。先把核心业务指标梳理清楚，统一口径，再让 Agent 基于这些指标提供服务。

• 从小场景切入：不要一开始就试图让 Agent 自动完成所有 BI 工作。从最简单的数据问答开始，逐步扩展到建模辅助、报表生成，最后才是全流程自动化。

• 保留人工审核：dry-run 机制和人机协同模式是必要的。Agent 的产出需要人审核确认，尤其是涉及数据口径和业务逻辑的操作。

• 关注安全边界：明确 Agent 可以执行哪些操作、不能执行哪些操作。权限控制、数据脱敏、审计追踪一样都不能少。

Agentic BI 不是对传统 BI 的替代，而是在 BI 之上叠加了一层 AI 能力，让数据分析从"人驱动的工具操作"进化为"AI 辅助的智能流程"。衡石在这条路上已经走得比较远了——从 NL2Metrics 到 Data Agent Family，从 HENGSHI CLI 到 HENGSHI BOX，形成了一套完整的技术栈。对于数据团队来说，现在是认真评估 Agentic BI 的时候了。