一、共识偏差：智能问数不是"连库 + 调模型"

智能问数（Intelligent Data Query）是当前企业数字化里非常热门的方向——用户用自然语言问数据，系统自动去数据库查，然后返回结果。听起来简单，以至于行业中普遍存在一种认知偏差：觉得这事只需要连个数据库、调个大模型就完了，技术门槛极低。

真实情况恰恰相反。数据调取是整条链路里最简单的一环。智能问数项目的真正核心难点，是让 AI 准确理解企业专属的业务规则，以及用户模糊的自然语言查询背后到底想要什么。

不同企业的"收入"口径可能差三个维度，不同部门的"转化率"算的是完全不同的东西。如果跳过业务理解，直接让大模型去写 SQL，结果就是字段名对了，数据错了，业务方不敢用。

二、核心执行链路：三步走，一步不能少

一个交付级的智能问数系统，必须按以下链路逐层推进，不能跳过或合并中间环节。

第一步：自然语言 → 结构化查询协议

用户说的是一句模糊的自然语言，比如"这个月利润怎么回事"。系统不能拿这句话直接去查数据库。首先要做的事，是把它拆解为一个结构化的查询协议，明确：

  • 查询主体：要分析什么业务对象？
  • 对比维度：和什么比——时间同比、品项对比、还是渠道对比？
  • 指标口径：用什么指标来衡量？利润是毛利润还是净利润？
  • 诉求类型：是要一个报表数值，还是要做归因分析，还是异常检测？

这一步把人的模糊意图翻译成结构化的中间表示，是整条链路的起点。不做这一步，后面的所有工作都是盲猜。

第二步：查询协议 → 企业业务本体映射

有了结构化协议，还不能直接查。因为企业的数据字段、指标定义、计算逻辑都是高度定制化的。同一个"用户数"，电商看的是"下单用户"，SaaS 看的是"活跃用户"，广告平台看的是"触达用户"。

「本体就是这家企业自己的业务语言和关系的地图。它告诉 AI 有哪些业务对象，有哪些查询指标，它们之间是什么关系。」

企业业务本体（Ontology）包含三个核心要素：

  • 业务对象：客户、订单、产品、渠道、活动等，以及它们之间的关联关系。
  • 指标定义：每个指标的精确计算口径、依赖的数据源、可用的修饰维度。
  • 业务规则：哪些数据需要权限校验，哪些指标有统计口径差异，哪些场景需要特殊处理。

本体映射的本质，是给大模型配一本企业专属的"翻译词典"。通过本体，系统把"利润"翻译成符合这家企业财务口径的具体查询语句。跳过本体直接写 SQL，数据对不上是必然的。

第三步：分析计划生成与动态执行

完成本体映射后，大模型生成一个分析计划。以"本月利润下降"为例，合理的初始计划是：先核实总收入是否下降 → 如下降则按渠道拆分明细 → 再核实总成本是否异常 → 如异常定位具体成本项。

这里最关键的设计是：Agent 不是生成计划后就机械执行到底，而是遵循"观察 → 判断 → 行动"的 ReAct 循环，每执行一步都要核验结果，根据反馈动态调整下一步分析方向。

三、Agent 设计约束：有限范围内的动态规划

智能问数 Agent 的设计，需要找准一个平衡点——既不是写死的固定 workflow，也不是毫无边界的自由探索。

「一个可用的智能问数的 agent，它不是完全固定的一个 workflow，它不是写死的，它也不是完全自由的探索，而是在一个有限的约束下，根据结果不断的修正自己的分析计划。」

实现这种平衡，需要在四个维度上对 Agent 施加约束：

  • 查询目标约束：Agent 必须始终围绕当前要回答的核心问题，不允许偏离。例如用户问的是利润下降，Agent 就不该自己跑去查库存周转率。
  • 可用指标约束：只允许访问业务本体中显式定义的指标。Agent 不能凭空创造指标，也不能访问未被授权的业务对象。
  • 工具调用权限：Agent 能调用的工具（读库、聚合计算、明细探查、报表生成等）是预定义的，不允许越权操作或生成全表扫描这样的危险查询。
  • 停止判定条件：当置信度达到阈值，或已穷尽所有可行的分析路径，Agent 必须停止并返回当前最佳结论，而不是无限制地继续分析下去。

这四个约束把 Agent 框在一个明确的"分析边界"内。边界内，Agent 可以灵活调整分析策略；边界外，一步都不能跨。这也是智能问数 Agent 走向生产环境的前提条件。

四、产品落地规范：给从业者的参考

基于以上分析，智能问数产品落地时需要遵循的核心规范非常明确：

  • 强制链路要求：不得采用"自然语言直接跳转数据查询"的实现逻辑。中间必须依次完成查询协议生成、本体映射、分析计划生成三个环节。少一个环节，系统的可靠性都会大幅下降。
  • 迭代优化要求：Agent 完成每个分析步骤后，必须根据返回结果做有效性验证。如果结果异常或不足以支撑结论，Agent 应重新规划分析路径，而不是硬着头皮输出一个低置信度的答案。

做好这两点，至少能避免 80% 的常见问题。剩下的 20%，取决于业务的复杂度、数据质量，以及本体的持续迭代能力。

智能问数的终点不是"让用户少点几次鼠标"，而是让企业能用自然语言与自己的数据资产进行可靠的对话。这背后 80% 的工作量不在模型调优上，而在业务理解、本体构建和系统架构设计上。理解了这一点，项目的交付路径就清晰了。