Article body
正文
摘要： 企业引入 Agentic BI，真正要验收的不是“能不能答出一个数”，而是能否把业务问题转成口径明确、证据可查、责任清楚的交付物，并在授权的接口与流程中推进下一步。衡石的指标管理、Data Agent、HENGSHI CLI、HENGSHI BOX 与 JARVIS 分别对应语义治理、分析创作、工程执行、私域部署与 Agent 运营。本文给出一条从问题、指标、分析到交付、行动和复盘的可操作闭环，也说明哪些环节仍应由企业的发布、审批与系统集成共同完成。
先定义“闭环”的边界。 Data Agent 已支持基于业务数据做对话式分析，并可辅助指标创建、仪表盘生成与编辑；“创建工单、调整预算、发起采购、更新 CRM”等外部业务动作，则需要企业按接口能力、身份授权与审批规则进行集成设计。把两者区分开，才能既把价值做实，也不把风险交给一句自然语言。
一、问题不在“有没有答案”，而在答案能否被业务验收
一次自然语言问数，通常只能完成发现线索的第一步。比如“华东销售为什么下降”，如果输出没有说明它使用的指标、统计时间、筛选条件、数据快照与可继续核查的维度，业务负责人就很难判断该不该据此调整动作。更常见的情况是：分析结束后没有形成责任人、截止时间和复核口径，洞察停留在对话窗口里。
因此，Agentic BI 的交付对象应从“回答”改成“可验收的业务结论包”：它至少要说明问题、指标版本、分析范围、证据、建议动作、风险与复核方式。这样，业务人员仍然掌握判断权，智能体则把取数、拆解、对比、整理和表达这些高频工作推进到可交付状态。
1. 同一指标不等于任何场景都得到同一个数
指标口径一致是可信分析的基础，但“同一指标永远同结果”并不准确。计算结果还取决于统计周期、数据快照或数据更新时点、筛选条件、维度粒度，以及用户身份所对应的数据权限。复核时，必须把这些条件一并保存，而不是只保存指标名称。对于生成式 AI，同一输入也不应被预设为必然产生完全相同的回答；模型版本、检索到的上下文、数据状态和追问过程都可能影响表达与分析路径。
衡石指标管理强调“一处定义，多方使用”，以 HQL 将数据存算与指标逻辑解耦，并支持围绕业务指标体系、KPI 和指标探查开展消费。对复杂口径，应优先沉淀为可复用指标：把统计时间、是否扣除退款、是否包含运费等规则写进定义和描述；对“复购率”“ROI”等易混概念，在数据知识管理中维护业务术语到字段或指标的映射。口径发生变更后，也应按企业的发布、版本与刷新策略逐项核对仪表盘、报表、嵌入页面和缓存结果，不能假定所有引用会自动即时生效。
二、从问题到行动：一条可验收的六步链路
衡石 Data Agent 的产品能力可以承接前半段的分析工作：它会结合用户输入判断意图、按需要拆分问题，并在用户有权限的数据范围内，从数据集市、应用集市和应用创作内容中混合检索；复杂问题可进行一次或多次数据查询。它还能读取登录账号与当前页面信息，从而理解“我的部门”等上下文，并辅助指标、仪表盘与可视化创作。产品能力的价值，在于把业务探索接回已有的数据和 BI 资产，而不是将自然语言当作绕开治理的捷径。
图1：Agentic BI 的验收维度；每个维度都应留下可检查的证据
| 阶段 | 交付物与衡石能力 | 验收问题 |
|---|---|---|
| 1. 定义问题 | 明确业务目标、责任人、决策时点；在当前页面或对话中发起探索。 | 问题是否能被限定为可验证的业务假设？ |
| 2. 固化指标 | 用指标承载复杂口径，补齐字段/指标描述、同义词、过滤规则和版本记录。 | 口径、时间范围、权限范围与数据快照是否齐全？ |
| 3. 多步分析 | Data Agent 按问题复杂度进行查询、汇总、异常识别、分解与下钻，输出基于已有数据的解读。 | 每个关键结论能否回到图表、指标或明细复查？ |
| 4. 形成交付 | 生成仪表盘、图表、说明或结构化结论；业务方确认采用的结论版本。 | 谁认可结论？下一步由谁在何时完成？ |
| 5. 授权后行动 | 通过现有业务系统的接口、审批和权限机制，执行通知、建单或其他约定动作。 | 动作是否在明确授权内，且可回看请求、审批和结果？ |
| 6. 效果复盘 | 以同一指标与新数据快照检查结果，补充数据知识和人审反馈。 | 行动是否改善了目标，还是需要修正假设或口径？ |
2. 数据准备决定分析能否落到业务语境
Data Agent 的准确性并不只依赖模型。衡石 6.2 手册建议，在数据集知识管理中用自然语言描述数据集用途、隐含过滤规则、同义词及业务词与字段、指标之间的对应关系；还可通过向量化提升对行业术语与上下文的检索。对于“智能学习”产出的内容，手册明确建议人工检查后再增删改。这里的原则是：让 AI 参与学习和整理，但把业务语义的最终确认留给懂业务的人。
这也解释了为什么应先从一个业务域的少量核心指标开始。先把命名、数据类型、字段说明、隐藏的无关字段和指标描述整理清楚，再引入对话分析；等到业务团队能稳定复核后，再扩展到更多数据包和更多问题。智能解读可基于预先配置的思路进行实时查询、异常识别、分解、下钻和报告输出，但它描述的是已有或历史数据，不应被当作未来预测或自动决策。
三、一个可复用的验收案例：区域销售下滑处置
以下为示例，不代表任何客户事实。某零售团队在经营看板中发现“华东净销售额”低于目标，负责人希望在周会上决定是否调整渠道资源。团队不应直接把“下降原因”作为唯一交付，而应先约定验收条件，再让 Data Agent 和 BI 能力完成可复核的分析材料。
业务问题：华东净销售额低于本周目标，是否需要调整渠道资源？
指标：净销售额（已发布版本 v2026.10）
分析范围：自然周；华东；自营与经销渠道分别查看
复核条件：数据快照时间、筛选条件、用户权限上下文、指标定义链接
分析交付：趋势、渠道/城市拆分、退款影响、异常说明、可追溯图表
业务决定：负责人确认后，由渠道负责人在既有流程中提交资源调整申请
复盘日期：下一个自然周，以相同口径和新的数据快照检查结果在分析阶段，Data Agent 可依据当前仪表盘与用户上下文开展查询、拆分维度并生成解读材料；团队应要求它把结论对应到已使用的图表、指标和筛选，而不是只接受一段自然语言解释。如果发现退款口径或渠道归属存在争议，正确动作是回到指标定义和数据知识中修正、发布，再重新验证，而不是让模型在对话中临时“猜一个算法”。
在行动阶段，系统可以将已确认的结论带到已有的工单、审批或 CRM 流程中；是否自动创建、谁能批准、失败如何处理，取决于集成接口和企业治理设计。衡石 HENGSHI CLI 的对外命令为 hbi，可将数据接入、HQL 查询、仪表盘生成和权限等 BI 工程操作组织为 Agent 可调用的命令面，并为支持预演的操作提供 --dry-run，并配合结果回显，适合在工程变更前让人审查。这里 HQL 是分析表达与指标逻辑的一部分，并不是把业务动作写成“任务 DSL”。
效果复盘还应记录促销、季节性、客群结构与其他同步变化。必要时设置对照条件，区分行动后的指标变化与行动本身的贡献，避免只凭前后对比就认定因果关系。
四、分阶段落地：先可复核，再可扩展
1. 第一阶段：建立一条可解释的分析链
选择一个高频、低争议的问题，例如区域销售、库存周转或服务响应。完成指标与数据知识准备，约定一张验收卡，要求每次交付保留范围、图表、指标版本和人工结论。验收标准是业务人员能用同一组条件复查关键结论。
2. 第二阶段：把分析结果沉淀为可消费资产
当复核稳定后，将高频分析沉淀为指标看板、解读思路、仪表盘和报告模板。HENGSHI SENSE 支持 Data Agent 从零创建或编辑仪表盘，包括图表、过滤器、富文本报告、布局与控件批量操作；业务团队仍需建立发布检查，确认不同消费入口看到的是目标版本。
3. 第三阶段：在授权的边界内连接业务流程
优先接入通知、待办生成、材料预填等低风险动作，再试点需要人工审批的外部操作。HENGSHI BOX 提供软硬一体的私域部署选择，将 BI 平台、本地模型与 Agent 工具环境结合起来。采用本地方案时，需要在验收中明确模型运行位置、对外网络访问和数据传递范围；如接入外部模型或服务，也应逐项核对其数据路径。JARVIS 提供企业 Agent 运营方法论与咨询赋能，帮助团队建设结构化知识、工作流、质量门禁与持续改进机制。企业可以按需要组合这些能力，并分别约定部署安全与工作流质量的验收项。
五、结语：把“智能”交付为可检查的业务改变
Agentic BI 的价值不在于让系统替人作决定，而在于让组织以更短路径完成“提出问题—使用统一口径—获得可复查分析—形成可验收交付—在授权下行动—用新数据复盘”的循环。衡石的指标管理、Data Agent、BI 工程命令面和部署、运营方法论，为这条链路提供了可组合的能力。真正可持续的落地，仍需要企业把指标版本、数据质量、发布策略、审批接口和责任机制一起纳入设计。