"请分析 2026 年 6 月 14 日至 6 月 16 日各设备的平均油温、最高油温和最低油位，并关联同期告警和故障数量。请按最高油温从高到低排列，优先关注油温较高且同时存在告警或故障的设备。"
看起来，这只是一次数据查询。但执行起来，远不只是生成一段 SQL。
系统首先要知道该查哪几张表，哪些字段分别代表"油温""油位""告警"和"故障"，时间字段是哪一个；还要找到正确的关联关系，完成统计、排序和结果组织。
如果用户接着说一句："再按油位也排一下。"
AI 还必须知道，这不是一个新问题，而是在修改刚才那次查询。
自然语言问数难的地方，从来不是把一句话翻译成 SQL，而是让 AI 理解数据结构、维护查询上下文，并在尽可能短的链路中快速生成正确的 SQL，最终确保查询能够在真实数据库中安全执行。
在推动工业场景 AI Agent 能力落地过程中，我们选择智能问数作为一个具体切入点，并基于 DolphinX 做了一个智能问数 Agent，尝试探索一套面向企业数据的智能问数链路应该如何构建。
不只是 Text-to-SQL
如果只是把自然语言翻译成 SQL，问题其实并不复杂。真正困难的是，用户的问题往往不是一次性的：他会继续追问、修改条件，甚至回到更早的一次查询重新调整。
因此，我们探索的并不只是"自然语言 → SQL"，而是一条完整的智能问数链路：问题理解、上下文构建、元数据检索、真实 Schema 探查、SQL 生成、安全检查、查询执行和执行结果检查。
目前，我们的智能问数 Agent 主要覆盖三类典型的场景：
- 查数据：数量、明细、筛选、排名、Top N、分组、趋势、占比等常见分析需求。
- 追问题：基于当前查询继续增加条件或分析维度。例如"同一时间范围""区域也加一下""只看华东"等自然语言追问，可以继承之前查询中仍然有效的条件和数据范围。
- 改问题：定位历史查询，并对其中的条件进行修改。例如，用户可以回到更早的一次查询："把前面那条检修计划查询改成只看上半年。"
这意味着，AI 在这里不只是一个 SQL 生成器，而是在尝试维护一个持续演进的查询上下文------它需要记住用户问过什么，也需要判断当前这句话究竟是在延续、修改，还是重新开始。
不再把元数据一次性丢给模型
企业数据环境里，一个常见做法是把数据库元数据全部交给大模型，然后让模型自己选表、选字段。
我们没有这么做。我们认为：模型可以判断用户想查什么、应该使用哪些字段、如何组织查询，但不能凭空创造数据库对象。
因此，我们选择让模型负责判断，让数据库负责提供事实。这样做的目的，是让 AI 的判断始终建立在真实的数据结构之上，而不是依赖模型自身的猜测。
在实际应用中，Agent 会首先根据用户问题召回少量候选表，再从 DolphinDB 探查真实字段、字段注释、类型以及必要的字段值样例。随着查询上下文逐步明确，系统可以动态扩展字段和表；如果当前候选范围仍无法满足需求时，再进一步扩大元数据搜索范围。
这种按需检索、逐步收敛的方式，不只是为了提高 SQL 的准确性，也是在控制 AI 处理的信息范围，减少无效的上下文和推理，让模型更快定位到真正需要的数据。
给 AI 划定安全边界
当 AI 开始直接面对企业数据，哪些操作可以执行，哪些操作必须被禁止？
我们希望 AI 不仅要在明确的边界内访问数据，整个查询过程也应该是可见、可验证、可干预的，而不是让用户只能等待一个最终答案。
在我们的实践方案中，问数并不是直接从自然语言生成 SQL，而是被拆解为问题理解、上下文构建、元数据检索、真实 Schema 探查、SQL 生成、安全检查、查询执行和结果检查等多个阶段。
首先是让 AI 的数据访问可控。所有查询请求在执行前都会经过服务端 Hard Stop（强制拦截）检查，拦截写操作、DDL、非法函数，以及超出最终 Schema 的表和字段引用。通过检查后，统一进入只读执行链路。即使 SQL 执行失败，Agent 根据错误信息进行局部修复后，修复后的 SQL 也必须重新经过安全检查才能再次执行，目前最多自动修复 5 次。
其次是让 AI 的查询过程可见。每个阶段的关键结果都会呈现给用户：AI 如何理解问题、构建了什么查询上下文、检索了哪些元数据、实际探查到了哪些字段和类型，以及最终生成了什么 SQL。用户不需要仅仅根据一个最终数字来判断答案是否可信，而是可以沿着整个查询过程检查 AI 的判断。
更重要的是，这个过程不是只能"看"，还可以随时"改"。如果用户发现 AI 在某个阶段理解错了，例如选错了数据表、字段含义理解有误，或者统计口径不符合预期，可以直接打断并纠正。AI 会基于修正后的上下文继续后续查询，而不是让错误一路传递到最终结果。
简单地说，我们想解决的并不只是"AI 能不能查到数据"，而是让 AI 在一个安全、透明且可控的执行链路中完成查询。用户既可以把分析任务交给 AI，也始终保留对数据访问和查询过程的控制权。
注：目前实现的智能问数 Agent 主要面向个人开发者，旨在重点验证 AI 与企业结构化数据交互的核心链路。未来如果进一步进入企业生产环境，还需要接入企业权限体系，整体链路还需要增加身份与权限校验，确保 AI 的每一次数据访问都建立在用户已有的数据权限之上。
下一步，我们还会做什么
这次实践并不试图一次性解决所有问题。
目前的实现主要关注的是结构化数据的查询和分析，暂不处理写入、更新、删除等数据库操作，也不把自己定位成完整的数据治理平台。后续，我们还会继续探索：
- 图表与报告生成：让查询结果进一步转化为可读的图表和分析报告。
- 跨会话长期记忆：让 Agent 能够理解更长期的业务分析上下文。
- 账号与权限体系：接入企业身份认证和数据权限控制。
- 向量化元数据检索：提升复杂数据环境下的表、字段和业务语义召回能力。
- 多轮分析任务：从单次查询进一步扩展到连续的数据分析任务。
这些能力的共同目标，并不是让 AI 生成更多 SQL，而是让它能够理解更多业务上下文，完成更复杂的数据分析任务。
从问数开始，但不止于问数
但比这些能力本身更值得关注的，是一个更大的问题：AI 能不能从"回答问题"走向"帮助分析问题"？
例如，在实际场景里，用户关心的可能是"这个指标为什么突然上涨"，而不是"给我查一下上涨了多少"。前一个问题已经不只是查询。AI 需要进一步关联数据、理解指标变化、识别异常，并寻找可能的原因。
从回答问题到解释问题、发现问题，变化的不只是 AI 能完成的任务数量，更是 AI 参与数据分析的方式。
智能问数只是一个具体的起点。从数据查询到数据分析，再到问题发现与决策支持，AI 正在逐步从一个"回答问题"的工具，走向真正参与分析的智能助手。