Article body
正文
**摘要：**业务人员在看板上看到逾期交货、销售下滑或库存异常时，下一步往往不是从空白对话框重新提问，而是沿用眼前的数据口径继续拆分、解释和调整呈现。HENGSHI SENSE 的 Data Agent 可以读取登录账号和正在浏览的页面信息，在数据包、数据集和仪表盘等页面内参与查询、可视化辅助创作、指标辅助创作与智能解读。要把这项能力用稳，团队需要先分清页面上下文、会话上下文和已保存资产各自保存什么，再为追问、失败恢复和权限复核留出明确操作。
从当前页面开始，先识别上下文的边界
Data Agent 的侧边栏服务于“我正在看的页面还可以怎样分析或创作”这个问题。公开文档说明，Agent 能读取登录账号信息，并在数据包、数据集、仪表盘页面依据当前页面信息处理查询等需求。它也能在仪表盘列表页从零创建仪表盘，或编辑已有仪表盘，包括图表、过滤器、富文本报告、布局、颜色和控件。仪表盘页面还可以配置智能解读，由预设思路驱动查询、异常识别、分解和下钻，输出基于已有及历史数据的描述性报告。
“读取当前页面”不等于页面里全部信息都能自动成为正确答案。实施时应把上下文拆成可检查的字段：登录用户及其数据权限；当前资源类型和资源标识；选定的数据包、数据集或仪表盘；当前图表的度量、维度、时间粒度、过滤条件和参数；正在编辑的控件或图表；尚未保存的草稿状态；本轮会话带入的提问和偏好。身份与资源范围决定允许访问什么，图表绑定和过滤条件决定查询口径，编辑状态与草稿决定后续操作是否可能改变页面资产。团队应在自己的页面、版本和权限模型中逐项验证这些字段的实际可用范围，而不应把“页面上下文”当作没有边界的记忆。
ChatBI 解决的是另一类起点。它适合独立的智能问数入口，可以围绕一次会话生成图表和看板；公开 FAQ 将“对话图表一键生成看板”列为 ChatBI 能力。Data Agent 侧边栏可做可视化、指标辅助创作和智能解读，却没有同一条“对话图表一键生成看板”路径。两个入口可以围绕同一套受权数据服务，却不能把各自的会话状态、页面状态和写入路径视为自动互通。
示意实施场景：采购逾期交货看板上的连续分析
**以下为示意实施场景，不代表客户案例或实际结果。**采购负责人打开“本月到货履约”仪表盘，页面已有本月范围、采购组织过滤器，以及“延迟交货单量”“延迟天数”“到货及时率”等已定义口径。页面上的明细还带有供应商、承诺到货日期、实际到货日期、订单状态和品类字段。负责人输入：“解释本月延迟交货，再按供应商拆分，只改图表样式保留口径。” 这是一条包含查询、追问和编辑意图的复合请求。
第一步应先确认“本月”承接的是看板的时间过滤器，还是提问时临时指定的自然月；“延迟交货”承接的是现有指标定义，还是要按承诺到货日与实际到货日临时计算。若看板已有受治理指标，优先沿用指标定义，并检查数据源、采购组织、时间窗口和排除状态。Data Agent 可以在权限范围内检索和查询，也可以把复杂问题拆成一次或多次数据查询。业务人员仍要查看返回的时间范围、过滤条件、度量名称和分组维度，确认它们与眼前看板一致后再解释原因。
第二步“按供应商拆分”应沿用已确认的本月范围、采购组织和延迟交货口径，把原来的趋势或品类等分析维度替换为供应商。若用户改成“只看华东仓”，系统需要新增或替换仓库过滤条件；若用户问“改成上季度”，时间过滤条件需要替换，本月上下文不能继续生效。把每一次追问拆成“继承哪些字段、替换哪些字段、增加哪些限制”三项检查，能让业务人员看见口径变化发生在哪里。
第三步“只改图表样式保留口径”属于页面创作。此时应保持度量、维度、过滤条件和数据绑定不变，只调整图表类型允许范围内的颜色、标签、布局或控件样式。用户若要求“把逾期率改成供应商风险分”，请求已经从样式编辑转为新的指标或计算定义，需要重新确认公式、聚合粒度、数据来源、命名、审核责任和保存位置。把这两类请求混在同一条指令中，最容易让看板外观变了，口径也在不知不觉中漂移。
查询、编辑、口径创作分别跨过哪些状态边界
| 用户意图 | 可继承的页面状态 | 需要明确确认的边界 |
|---|---|---|
| 解释本月延迟交货 | 当前数据源、时间范围、组织过滤器、已定义指标 | 延迟定义、排除状态、解释是否只基于已返回数据 |
| 按供应商拆分 | 已确认的度量、时间范围和过滤器 | 供应商替换哪个原有维度；是否保留品类、仓库等筛选 |
| 只改图表样式 | 数据绑定、图表数据、口径和页面位置 | 可修改的样式项、是否写入仪表盘、保存权限 |
| 创建 HQL 表达式或指标 | 相关数据集和业务术语 | 公式、聚合层级、指标名称、审核人和资产归属 |
| 后端或外部工作流调用 | 由集成方显式传入的请求参数 | API 支持面、调用身份、数据范围和写入动作 |
Data Agent 能基于对 HQL 的理解辅助编写复杂表达式和创建指标。这个能力适合把已经说清的业务规则转成可审阅的候选表达式。它不替代指标治理：同一个“逾期率”若按订单数、订单金额或行项目计算，会产生不同结果；分母是否排除取消单、日期取承诺日还是实际到货日，也必须由业务规则决定。重要口径应在数据侧沉淀为指标，补充分子、分母、时间窗口和同义词说明，避免把一次对话里的临时计算当作长期标准。
API 也不等同于把浏览器内的每项辅助创作能力原样开放给外部系统。公开 FAQ 将可视化辅助创作、指标辅助创作和智能解读列为 Agent 模式能力，未列为 Agent API 或 Workflow API 的同等能力；公开集成说明也把 API 定位为后端编排入口。项目组若要从自有系统调用，应按接口文档核对每一项查询、渲染或资产写入能力，并重新设计调用身份、传入上下文和权限校验。
把连续追问变成可复核的操作
对话连续性只能提升交互效率，不能代替验证。数据准备应排在提示词调优之前：清晰的数据集、字段和指标名称，完整的描述，隐藏无关字段，以及数据集知识管理中的术语、同义词和隐含规则，都会影响召回和理解。官方文档也明确提示，AI 行为具有不确定性，相同输入不保证得到完全相同的响应。团队可以用明确提问减少歧义，却不能把提示词当作替代数据治理的补丁。
每次完成关键追问后，操作者应核对执行日志中实际查询的数据源、指标、筛选条件与错误信息。若查询已经返回数据而图表编辑失败，应把“得到分析结果”和“未写入页面资产”分别记录；若保存失败，应保留原始看板和候选修改，排查页面权限、资源锁定或配置冲突后再重试。保存成功后，以相同身份重新加载仪表盘，确认图表、过滤器和指标绑定仍在；再按项目的角色设计，用具备较低编辑权限的账号或审阅流程复核读写边界。这样可以避免把临时会话结果、未保存草稿和已发布看板混成同一种状态。
用后续版本信息设计升级验证，而不把它当成结论
6.2.5 的变更记录提到 ChatBI 第二轮问数的数据源继承、会话范围，以及偏好已保存却未生效等修复。它们适合转换成升级后的回归样例：完成第一轮采购看板问数后，第二轮要求按供应商拆分，检查数据源是否保持；切换或返回会话后，检查请求是否仍处于预期范围；保存展示偏好后，重新进入页面检查偏好是否真正应用。发布记录说明这些问题曾进入修复范围，不足以证明任何现网环境都存在同一问题。
**衡石观点：**页面上下文让业务人员能从已有看板继续追问，受治理的指标让每次拆分仍有统一口径，清楚的保存与权限边界让创作结果可以被复核。把这三件事连起来，Data Agent 才能从一次方便的问答，进入可持续维护的分析工作。