HENGSHI SENSE 6.2 架构全景解析：Data Agent、指标引擎与Headless语义层的工程实现

导语：2026年4月16日，衡石科技正式发布HENGSHI SENSE 6.2版本。这不是一次常规的功能堆叠迭代，而是一次围绕"Agentic BI"核心理念的架构级升级。本文将从工程实现的角度，深度拆解6.2版本的六大核心模块------特别是全栈Data Agent的技术实现、指标管理系统的架构设计、以及支撑这一切的Headless语义层底座。无论你是BI平台开发者、数据架构师，还是关注AI+数据方向的技术管理者，都能从中获得有价值的参考。

一、6.2版本的技术定位：从"功能迭代"到"架构升级"

1.1 版本演进脉络

在深入6.2的具体功能之前，有必要先理解衡石科技在HENGSHI SENSE的版本演进中遵循的技术脉络：

|-----------|------------|----------------|---------------------------|
| 版本线 | 时间 | 核心主题 | 技术关键词 |
| v4.x-v5.x | 2020-2023 | Headless架构确立 | API化、多租户、嵌入式SDK、语义层 |
| v6.0 | 2023-2025 | AI能力初探 | LLM集成、Text-to-SQL、智能推荐 |
| v6.1 | 2025-2026初 | Agent概念验证 | 自然语言建模、对话式创作、CLI工具 |
| v6.2 | 2026.4 | Agentic BI完整实现 | 全栈Data Agent、全域上下文覆盖、自愈能力 |

可以看出，6.2版本是一个量变到质变的节点------此前几个版本中逐步引入的AI能力（自然语言查询、智能推荐、Agent概念验证）在6.2中完成了系统性整合，形成了完整的Agentic BI技术栈。

1.2 6.2的技术主题

6.2版本的工程实现围绕三个核心技术主题展开：

1. Agent化：将AI能力从"辅助查询"扩展到"全栈操作"，Agent可以执行从数据建模到仪表盘创作的完整BI工作流

2. 资产化：将指标从"报表附属品"提升为"一等公民数据资产"，提供收藏、搜索、同步等资产管理能力

3. 工程化：在数据导出、权限管理、水印安全等企业级能力上补齐工程短板，支撑大规模生产环境部署

---

二、Data Agent：全栈BI智能体的架构设计与实现

2.1 从"问数助手"到"全栈BI智能体"的技术跃迁

Data Agent是6.2版本的核心亮点。但理解它的技术价值，需要先理解此前的局限和6.2的突破。

在传统BI平台中，"问数助手"（通常基于Text-to-SQL实现）的技术实现相对简单：

用户自然语言输入 → LLM意图识别 → SQL生成 → 数据库查询 → 结果展示

这条链路的问题在于：它只能处理"查询"这一个环节。用户问"上个月华东区的销售额是多少"，系统可以回答。但用户说"帮我建一个华东区销售趋势的仪表盘，包含同比环比、按产品分类的柱状图，再加上KPI卡片"，传统的问数助手就完全无能为力了。

6.2版本的Data Agent本质上是一个多模态、多任务、全栈的BI智能体，它的技术架构是这样的：

关键的技术突破在于：

• Task Planner（任务规划器）：能够理解复杂的多步骤请求，自动拆解为子任务序列，并支持进度跟踪

• 多Agent协作：建模助手、创作助手、问数助手可以协同工作，例如"先建一个数据集，然后基于这个数据集创建仪表盘"

• 平台API直调：Agent不再通过模拟UI操作来实现功能，而是直接调用Headless API，确保操作的精确性和可靠性

2.2 四大Agent能力的技术实现

2.2.1 建模助手（Modeling Agent）

建模助手是最具技术含量的Agent能力，因为它需要理解数据工程的复杂逻辑。

核心能力：

• 在建模画布中自由拖拽数据集

• 灵活配置LEFT/INNER/RIGHT JOIN等关联关系

• 快速从数据连接中创建新数据集

• 智能推荐最优关联类型与维度归属

工程实现要点：

建模助手的底层调用的是衡石的语义建模API。当用户说"把订单表和客户表关联起来，用客户ID做左连接"时，Agent需要完成以下步骤：

1. 意图解析：识别出操作类型（JOIN）、涉及的表（订单表、客户表）、关联字段（客户ID）、关联类型（LEFT JOIN）

2. 数据发现：在语义层中搜索匹配的数据集（可能涉及模糊匹配和同义词处理）

3. 可行性校验：验证关联字段的数据类型是否兼容、关联关系是否已存在、是否会产生笛卡尔积等问题

4. API调用：通过语义建模API创建或修改数据集的JOIN配置

5. 结果反馈：向用户展示操作结果，包括关联后的数据预览和潜在问题提示

智能推荐机制：

除了执行明确的用户指令，建模助手还能"主动建议"。例如，当用户加载一个数据集时，Agent可以分析数据集的元数据（字段名、数据类型、数据分布），自动推荐可能的关联关系和维度归属。这种"建议"不是基于规则的简单匹配，而是结合了数据特征的智能推断。

2.2.2 创作助手（Creative Agent）

创作助手负责仪表盘和数据报告的可视化创作。

核心能力：

• 一句话指令即可新建仪表盘并自动生成对应图表

• 灵活修改图表类型、配色、标签、坐标轴等样式

• 支持从数据集自动推荐最佳可视化方案

工程实现要点：

创作助手的技术挑战在于：如何将自然语言的"模糊描述"映射为精确的"可视化配置"。

当用户说"帮我做一个华东区各省份的销售额排名，用柱状图"时，Agent需要：

1. 从语义层中定位"华东区"维度的精确数据字段

2. 识别"销售额"对应的指标定义（可能是多个字段的计算结果）

3. 确定聚合方式（SUM、AVG等）

4. 配置排序规则（按销售额降序）

5. 选择合适的图表类型（水平柱状图更适合排名展示）

6. 生成可视化配置并通过API创建图表

当用户说"换成饼图，颜色用蓝色系"时，Agent需要：

1. 识别上下文中的"上一个操作"（修改哪个图表）

2. 修改图表类型配置

3. 应用蓝色系配色方案

4. 保持数据绑定不变

2.2.3 问数助手（Query Agent）

问数助手是6.2中"升级"而非"全新"的模块，但升级幅度巨大。

核心升级：

• 具备更智能的分析流程规划能力

• 支持从查询错误中自我学习优化

• 精准记忆用户分析习惯与常用维度

• 智能搜索关联数据集

自我学习机制：

这是问数助手最值得关注的技术特性。传统的Text-to-SQL系统是"无状态"的------同样的查询每次生成同样的SQL。但6.2的问数助手引入了上下文记忆和错误学习机制：

• 当生成的SQL执行失败时，Agent会分析报错信息（语法错误、字段不存在、权限不足等），自动修正并重试

• 当用户手动修正了Agent的结果后，Agent会"记住"这次修正，在后续类似的查询中避免重复犯错

• 用户常用的维度、度量、过滤条件会被记录到个人偏好中，影响后续的查询推荐

2.2.4 页面操作助手（Navigation Agent）

页面操作助手是一个相对轻量但极具实用价值的Agent。

核心能力：

• 根据指令快速导航至任意功能页面

• 修改图表标题、样式等配置项

• 边操作边讲解功能流程

工程实现要点：

页面操作助手本质上是一个"RPA（机器人流程自动化）+ NLG（自然语言生成）"的组合。它通过调用页面导航API和配置修改API，实现了对整个产品界面的"程序化操作"。同时，它还能生成自然语言的"操作说明"，告诉用户它做了什么、为什么这么做。

2.3 AI能力增强的技术实现

除了四大Agent能力，6.2还在底层AI能力上做了多项工程优化：

流式输出：用户可以实时看到Agent的操作过程和中间结果，而不必等待所有操作完成后才看到最终输出。这在长流程操作（如复杂的建模+创作组合任务）中极大地提升了用户体验。

多语言适配： Agent能够自动检测用户的语言偏好，并使用对应语言进行交互。这对于国际化SaaS伙伴（如Synagie）和跨国企业客户（如WPP、宝马）尤为重要。

任务拆解与进度跟踪： 复杂请求（如"基于过去一年的销售数据，创建一份包含趋势分析、区域对比、产品排名的综合分析仪表盘"）会被自动拆解为多个子任务，每个子任务的执行进度实时展示。用户可以随时中断、修改或优先执行某个子任务。

Agent偏好设置： 6.2在用户中心新增了「Agent偏好」设置，支持用户通过Markdown格式自定义个性化指令。例如，用户可以设置"默认使用柱状图而不是折线图"、"日期格式统一使用YYYY-MM-DD"、"度量单位默认显示万元"等偏好。

从对话中自动学习： Agent能够从用户的操作和反馈中自动学习习惯。这不是简单的"记住上次查询"，而是对用户分析模式、常用维度、偏好图表类型的持续学习和适应。

2.4 全域上下文覆盖

6.2版本的Data Agent已经实现了全产品模块上下文覆盖，这是其区别于其他"AI+BI"产品的关键技术指标。

具体覆盖的核心场景包括：

|-------|--------------|---------------------|
| 场景 | 覆盖能力 | 典型操作 |
| 应用创作 | 仪表盘创建、页面管理 | "创建一个新的销售分析仪表盘" |
| 数据集市 | 数据包浏览、资源查找 | "找到华东区的销售数据集" |
| 仪表盘 | 图表操作、交互配置 | "把这个柱状图换成折线图" |
| 数据集 | 字段管理、关联配置 | "给这个数据集加上客户维度" |
| 数据连接 | 数据源管理、连接测试 | "检查一下MySQL连接是否正常" |
| 数据管道 | ETL流程配置 | "设置一个每日同步的数据管道" |
| 权限管理 | 角色配置、数据授权 | "给销售部门开放华东区数据的只读权限" |
| API管理 | API密钥管理、调用统计 | "查看上周的API调用次数" |
| 用户管理 | 账号管理、组织架构 | "创建一个数据分析团队" |

---

三、指标管理系统：企业级指标资产的工程化治理

3.1 指标管理的工程挑战

在企业级BI场景中，指标管理是一个被严重低估的工程难题。一个中大型企业可能有数百甚至数千个业务指标，分布在不同的部门、系统和报表中。

典型的指标管理痛点：

• 定义不一致：财务部的"收入"和销售部的"收入"可能计算口径完全不同

• 查找困难：想用某个指标，但不知道它定义在哪里、谁维护的、数据源是什么

• 重复建设：多个分析师各自定义了相同或相似的指标，导致"同义词"泛滥

• 变更风险：修改一个指标定义，可能影响数十个依赖它的报表

3.2 指标收藏功能的实现

6.2推出的指标收藏功能，看似简单，但在工程实现上需要解决几个关键问题：

收藏列表的高效查询： 个人收藏上限为1000个指标。如何在1000+指标的列表中实现快速搜索和分类展示？衡石的实现方案是：为每个用户的收藏列表建立倒排索引，支持按指标名称、归属主题路径、指标描述等多维度快速检索。

归属主题路径展示： 收藏列表不仅显示指标名称，还显示该指标所属的主题路径（如"销售管理 > 区域分析 > 华东区销售额"），帮助用户快速定位指标的来源和上下文。

一键直达： 点击收藏的指标可以直接跳转到该指标的详情页面或使用该指标的仪表盘，实现"收藏即调用"的无缝体验。

3.3 全场景指标搜索的实现

全场景指标搜索是6.2中工程复杂度较高的功能，因为它需要在多个不同的产品上下文中提供一致的搜索体验。

技术实现要点：

1. 统一搜索索引：所有指标（无论是在管理指标页面、指标市集、还是仪表盘添加指标的上下文中）都使用同一套搜索索引，确保搜索结果的一致性。

2. 场景感知：系统会根据当前上下文智能调整搜索行为。例如，在"管理指标"页面搜索时，结果偏向指标定义和管理操作；在"仪表盘添加指标"时，结果偏向可用的、有权限的指标。

3. 搜索关键词保留：在搜索结果列表中保留用户的搜索关键词，方便用户确认搜索意图是否被正确理解。

4. 性能优化：搜索结果最多返回1000条，通过分页加载和懒加载确保在大结果集场景下的响应速度。

---

四、仪表盘模块：企业级可视化体验的工程化升级

4.1 图表引擎增强

6.2在图表引擎层面做了多项增强，每一项都涉及底层渲染引擎的改造：

KPI条件格式： 新增规则配置方式，支持自定义规则，实现副指标和对比度量的独立配置。这意味着用户可以为同一个KPI组件中的不同指标设置不同的颜色规则和格式化逻辑，大幅提升了KPI展示的灵活性和信息密度。

虚线设置： 折线图、折线柱状图、组合图支持设置指定字段线条为虚线。这个看似简单的功能，在渲染引擎层面需要支持对系列级别的线型配置，并确保虚线与实线在图例中的正确区分。

图例增强： 环形图、饼图、南丁格尔图图例支持展示度量值和占比信息。这要求图例渲染组件从纯"标签展示"升级为"标签+数值+百分比"的复合展示模式。

4.2 交互体验升级

参数控件增强： 日期范围参数控件支持自定义默认值配置项。在工程实现上，这要求参数控件的配置模型支持"动态默认值"的概念------默认值不再是一个固定的日期，而可以是一个表达式（如"本月第一天"、"上个月最后一天"等）。

快捷时间段过滤器： 新增自定义日期快捷选项功能。传统的快捷选项是固定的（"最近7天"、"最近30天"等），而6.2允许管理员自定义快捷选项（如"本季度"、"上个工作周"等），这需要过滤器组件支持"自定义快捷项"的配置模型。

复杂报表页眉页脚： 支持页眉页脚自定义，自动插入标题、页码、打印时间等内容。这个功能看似是"打印增强"，但在工程实现上需要构建一个完整的"报表模板引擎"------支持占位符替换、动态内容插入、分页控制等能力。

4.3 数据导出突破

6.2将图表明细数据导出条数从固定10万行优化为最大支持1000万行。这个100倍的提升，背后涉及多个工程层面的改造：

1. 流式导出：不再将所有数据加载到内存后再生成文件，而是采用流式处理，边查询边写入，内存占用与数据量解耦。

2. 异步导出：对于大数据量导出，采用异步任务模式，用户提交导出请求后可以继续使用系统，导出完成后通知用户下载。

3. 格式优化：对Excel文件的生成进行了性能优化，避免大文件生成过程中的内存溢出和性能衰减。

---

五、数据源与基础管理：企业级治理能力的工程化

5.1 数据集市管理的工程实现

文件夹/数据包置顶： 高频使用的数据包或重要文件夹可固定在列表顶部。这个功能在数据模型层面需要为每个数据包/文件夹增加一个"置顶权重"字段，并在列表查询时加入排序逻辑。

数据包锁定： 锁定后的数据包进入保护状态，所有内部资源变为只读。工程实现上需要：

• 在数据包元数据中增加"锁定状态"和"锁定者"字段

• 在所有涉及数据包修改的API端点中加入锁定状态校验

• 遵循"谁锁定谁解锁"原则，只有锁定者本人才能解除锁定

跨应用复制指标同步： 复制数据集时自动识别并同步其内部定义的非模型创建的原子指标。这需要在数据集复制逻辑中加入"依赖分析"步骤------扫描数据集中引用的所有指标，识别哪些是原子指标、哪些是模型指标，然后对原子指标执行同步操作。

5.2 基础管理的精细化

水印设置优化是6.2中值得关注的工程增强。新版支持：

1. 应用级别的水印开关：管理员可以为每个应用单独配置是否显示水印，而不是全局统一。这需要在权限模型中加入"应用级水印配置"的权限项。

2. 高度自定义水印内容：支持用户名、邮箱、手机号、系统时间等参数的组合。这需要构建一个"水印模板引擎"------解析模板中的占位符，在渲染时动态替换为实际值。

默认排序全局设置： 系统管理员可对多模块列表展示规则进行一键式定义。这需要构建一个"全局排序配置中心"，将各模块的排序规则集中管理，确保一致性。

---

六、总结：6.2版本的技术意义

HENGSHI SENSE 6.2不是一个"功能堆叠"版本，而是一次围绕"Agentic BI"核心理念的架构级升级。

从技术角度看，6.2的核心贡献在于：

1. 定义了全栈BI智能体的工程范式：Data Agent不是简单的"对话式查询"，而是一个能够执行完整BI工作流（建模→创作→查询→管理）的多Agent系统

2. 完善了企业级指标资产的治理能力：指标收藏、全局搜索、跨应用同步等功能，让企业级指标管理从"口号"变为"可落地的工程方案"

3. 补齐了大规模生产环境的工程短板：1000万行数据导出、精细化水印管理、数据包锁定等功能，确保平台可以支撑大型集团企业的生产部署

4. 验证了Headless架构的AI时代价值：Agent通过API直调平台能力（而非模拟UI操作），验证了Headless架构在AI Agent时代的不可替代性

对于BI平台开发者和数据架构师而言，HENGSHI SENSE 6.2提供了一个有价值的参考案例：如何在保持企业级工程严谨性的同时，将AI Agent能力深度整合到平台架构中。 这不是简单的"在BI上加个ChatGPT"，而是从底层架构开始的系统性重新设计。

---

本文从工程实现视角深度解析HENGSHI SENSE 6.2，适合BI平台开发者、数据架构师、AI工程化方向的技术从业者阅读。技术细节基于衡石科技官方发布资料的分析与推理，具体实现以官方技术文档为准。