这两年企业里"看数"的习惯在变。过去经营会上摆的是提前做好的 BI 大屏和周报，管理层对着固定图表找问题。如今不少公司想在对话框里直接抛一句"上月华东退货率为什么涨了"。这个迁移看着轻巧，它有助于将数据消费从静态报表查看，逐步转向对话式探查。
持续智能问数是智能问数的一种发展方向。它支持在结果上连续追问、逐层下钻，还能把问数能力固化成定时自动生成的经营简报，让问数从"被动响应一问"走向"主动持续洞察"。管理者可考虑配置一个便于随时调用、能记录上下文的数据参谋。
什么是持续智能问数
单次问数解决的是临时一问，你问一句它答一句，答完这段就结束。持续智能问数把"问"当成连续会话来管。前一轮的约束条件会被系统留着，下一轮你只丢一句"再看城市维度"或者"下钻到品类"，系统明白你指的还是同一张表和同一批数据。这种连续性，是它区别于固定报表的重要特征之一。
它和普通对话式 BI 的差别也在这。后者通常为单轮问答，问完即止，下一句可能不保留前文。持续智能问数可保留上下文，为连续追问提供参考，并有助于减少重复说明带来的理解偏差。
多轮对话靠什么记住上下文
背后是一套状态管理机制。系统把每一轮产生的筛选条件、选中的维度、时间范围，全写进一个持久化的记忆区。下一轮对话进来，这些存量状态可接入新请求，通常无需反复说明"上季度、只看华东"。
工程上这个记忆区通常靠工作流引擎的 Memory 持久化落地，用检查点（checkpointer）把状态落库，在检查点已成功保存且任务支持恢复的情况下，可尝试从断点续接，减少因超时导致上下文丢失的情况。再配合状态传递，上一个节点的输出可自动传递至下一个节点，后面引用时可直接获取，减少人工搬运。
持久化什么也得设计。时间范围、选中维度、目标指标和筛选条件要留，中间推理过程可以丢。留太多可能干扰模型，使关键约束不易被识别。
状态压缩。对话拉太长，开头那几条关键约束容易被后面的闲聊冲淡，模型到后边记不清你最初盯的是哪张表。所以长会话要做约束摘要，把核心条件压成几句话常驻上下文。这对 token 成本也有好处，只留骨架，不养闲话。
下钻钻取
经营数据需要分层。拿时间来说，能从年一直切到某一天；地区维度则是全国、省、市、门店逐层收口；品类也一样，大类下面挂中类，中类下面才是单品。下钻，就是顺着层级往下走一层看更细的数，反过来叫上卷。
难的不是下钻这个动作，是系统得知道维度之间的层级。维度建模里，事实表存度量，维度表存层级，下钻快不快取决于维度表的层级有没有建清楚。底层若只有一张扁平明细表，下钻通常需要更换筛选条件重新聚合。较为顺畅的下钻，是把层级关系先显式建好，你点一下"下钻到品类"，系统可从父节点切换至对应子节点，通常无需编写查询语句。
把问数固化成经营驾驶舱
会问还不够，不少管理者希望每天能及时看到一份数。经营驾驶舱就是把一条问数链路配成定时工作流，按天或按周自动跑，跑完渲染成报告。
做法是在工作流里挂一个定时节点，到点触发，自动取数、生成摘要和图表，再推到指定位置。管理层进例会前，报告可提前生成。想追问，直接在结果上接着问。
话说回来，这些能力能不能跑顺，一半看模型，另一半看你家数据底子干不干净。表都没接进来，系统能力可能难以充分发挥。
工程意义
单次取数救的是临时一问，持续洞察管的是每天看数。从被动响应到主动推送，有助于缩短常规取数与制表环节，为管理判断提供更及时的参考。它把数据参谋的成本摊薄了。原先配一个专职经营分析，大半时间在重复取数和做表，现在系统可承担这些重复性工作。有助于将人的角色从重复操作转向更高层次的判断。
小艾智能体的 Agent 工作流引擎用 LangGraph 做状态流转，它的Memory持久化可支持多轮追问和断点续跑。你前边问的约束，后边接着问系统可识别。
定时这一块，工作流里配一个定时节点，按日或周可自动执行问数链路，生成经营驾驶舱报告。报告用HTML渲染，兼容性以部署环境为准，可用于管理例会投屏。文档处理引擎"支持对常见PDF、Excel、Word文件进行解析与切分，实际处理效果取决于文件类型和内容质量，再用BGE-M3向量化存入Milvus，问数时从这片知识取片段，有助于提升回答的可靠性。知识图谱那层可将"华东区""退货率""某品类"这类实体和关系构建为网络，下钻时可沿关系路径查询，减少迂回。
智能问数的发展方向之一，是让更多管理者能使用一个便于随时调用、能记录上下文的数据参谋。它未必替人做判断，但有助于提升判断的效率和准确性。