基于达梦 DM8 的智能问数方案设想：以 DSH 作为 Agent 底座

摘要

随着人工智能技术的发展，用户希望使用自然语言直接查询数据库，而不必掌握复杂的 SQL 语法。传统数据库查询通常依赖专业开发人员，不仅响应速度较慢，而且容易受到表结构复杂、字段含义不清和业务口径不统一等因素影响。

本文以达梦 DM8 为数据存储和查询核心，以 dmPython 作为数据库访问接口，并将 DSH 作为 Agent 运行底座，设计一套面向自然语言问数的技术方案。该方案重点关注数据库结构理解、SQL 生成、安全校验、只读执行和结果解释，为后续构建达梦数据库智能分析应用提供参考。

本文属于技术方案设想，不对未经实际测试的性能指标和成功率做结论。

一、方案背景

在实际业务系统中，数据库通常包含大量业务表、历史表和关联表。业务人员提出“某个时间段的销售情况”“不同区域的业务统计”等问题时，往往需要先找到对应的数据表和字段，再确定关联关系、筛选条件、统计口径，最后编写 SQL。

如果完全依赖人工处理，数据查询效率会受到限制。如果直接让人工智能访问数据库，又可能出现以下问题：

生成不存在的表名或字段名；
错误理解字段含义；
多表关联条件不正确；
聚合粒度与业务问题不一致；
执行修改数据的危险语句；
返回过多数据或敏感数据。

因此，数据库智能问数不能简单理解为“让模型自动写 SQL”，而应该建立一条包含结构理解、语义分析、安全检查和结果验证的完整链路。

二、总体技术架构

本方案以 DM8 作为核心数据库，使用 dmPython 负责应用层访问数据库，并通过 DSH 提供 Agent 的任务编排和工具调用能力。

【图1：达梦 DM8 智能问数总体架构图】

用户自然语言问题
        ↓
DSH Agent
        ↓
问题理解与查询规划
        ↓
Schema 与数据字典工具
        ↓
SQL 生成
        ↓
SQL 安全检查
        ↓
dmPython 数据库访问层
        ↓
达梦 DM8
        ↓
查询结果整理与自然语言解释

DM8 负责数据存储、数据关联和 SQL 执行；dmPython 是 Python 应用访问 DM 数据库的接口；DSH 则负责维护会话上下文、组织任务步骤和调用外部工具。达梦官方文档提供了 DM8 SQL、Python 接口和数据库开发相关资料，dmPython 也遵循 Python DB API 2.0 的接口规范。DM8 产品手册、dmPython 官方文档

三、DSH 作为 Agent 底座

DSH 是一个开源 Agent Runtime，提供会话管理、Agent Loop、工具注册、插件扩展和权限控制等基础能力。

在本方案中，DSH 不直接承担数据库存储工作，也不替代 DM8 的数据库能力，而是作为智能应用的运行底座，主要负责以下任务：

接收用户的自然语言问题；
维护多轮对话和任务上下文；
根据问题调用数据库相关工具；
处理 SQL 执行过程中的错误；
根据查询结果生成自然语言回答；
保存问题、SQL 和执行过程。

DSH 的插件化架构适合将数据库能力拆分成多个独立工具。例如，可以通过原生插件或 MCP 服务接入 Schema 查询、SQL 校验和数据库执行能力。

这样做的好处是，数据库访问逻辑不需要写入 Agent 核心流程，后续也可以替换数据库连接方式、权限策略或结果展示方式。

四、数据库结构理解

智能问数的第一步不是生成 SQL，而是理解数据库结构。

系统可以通过 Schema 工具读取以下信息：

数据表名称；
字段名称和字段类型；
主键和外键；
表之间的关联关系；
视图和索引；
字段注释；
业务数据字典。

例如，用户提出一个统计问题时，系统应先判断需要使用哪些表、哪个字段表示时间、哪个字段表示金额，以及统计结果应该按照什么维度进行分组。

除了数据库元数据，还可以增加业务数据字典，用于记录指标定义、字段别名和统计口径。这样可以避免人工智能只根据字段名称进行猜测。

在实际设计中，不建议将整个数据库结构一次性传递给 Agent，而是根据用户问题检索相关表和字段，减少上下文内容，也降低错误关联的可能性。

五、SQL 生成与安全校验

完成问题理解和结构匹配后，Agent 才生成查询 SQL。

生成 SQL 后不能直接执行，而应经过独立的 SQL 检查模块。检查内容包括：

是否为允许执行的查询语句；
是否包含插入、更新、删除或结构修改操作；
是否存在多条 SQL 拼接执行；
表名和字段名是否真实存在；
是否使用了允许访问的表；
是否设置了合理的数据量限制；
是否可能产生高成本笛卡尔积；
是否访问了敏感字段。

数据库账户应使用专门的只读账号，并通过数据库权限限制访问范围。应用层还可以增加查询超时、返回行数限制和敏感字段脱敏等策略。

通过这种方式，Agent 只负责提出查询意图和生成 SQL，真正的数据库执行仍然由受控的工具完成。

六、dmPython 执行 DM8 查询

通过校验的 SQL 可以交给 dmPython 执行。应用层不直接向用户暴露数据库连接，而是由查询服务统一管理连接、事务和异常。

查询服务可以按照以下流程工作：

接收 SQL
  ↓
检查访问权限
  ↓
创建或获取数据库连接
  ↓
执行查询
  ↓
读取字段信息和结果集
  ↓
转换为结构化数据
  ↓
返回给 Agent

如果 DM8 返回语法错误、字段不存在或权限不足等信息，Agent 可以根据错误信息重新检查 Schema 和查询逻辑。但重新生成 SQL 仍然需要经过安全校验，不能因为自动修正而绕过权限控制。

七、查询结果解释

数据库返回的通常是结构化结果，普通用户还需要进一步理解结果含义。

Agent 可以对结果进行以下处理：

将结果转换为表格；
对统计数据进行摘要；
说明查询使用的时间范围和数据口径；
提示结果为空的原因；
识别可能的重复关联；
根据需要生成图表或趋势说明。

为了增强可信度，最终回答中可以同时展示查询条件、使用的数据表和生成的 SQL。这样用户不仅能看到结果，也能了解结果是如何得到的。

【图2：自然语言问题到查询结果的处理流程图】

八、方案的安全边界

数据库智能问数的核心原则应该是“模型负责理解，工具负责执行，数据库负责授权”。

建议从以下方面建立安全边界：

为智能问数单独创建 DM8 只读账号；
仅开放指定模式和数据表；
默认只允许查询类 SQL；
设置最大返回行数和执行时间；
对敏感字段进行脱敏；
禁止执行多语句请求；
对高成本查询要求人工确认；
记录用户问题、生成 SQL 和执行结果；
不在源代码中保存数据库密码；
优先使用脱敏数据或分析库进行智能查询。

【图3：DM8 只读权限与 SQL 安全检查示意图】

九、应用前景

基于 DM8、dmPython 和 DSH 的智能问数方案，可以进一步应用于：

企业经营数据查询；
销售和库存分析；
管理驾驶舱；
自助报表生成；
数据库运维辅助；
SQL 生成与审核；
数据字典问答；
面向业务人员的数据分析门户。

后续还可以将查询结果与 DM8 的权限管理、审计能力和企业数据管理流程结合起来，使智能问数不仅能够“查到数据”，还能够满足企业对数据安全、过程追踪和责任审计的要求。

结语

达梦 DM8 为企业应用提供了稳定的数据存储和 SQL 查询能力，dmPython 为 Python 应用访问 DM8 提供了便捷接口，而 DSH 则可以作为智能 Agent 的运行底座，负责会话管理、工具编排和任务推进。

三者结合后，可以形成一条从自然语言问题到数据库查询结果的完整链路：

自然语言理解
  → 数据结构匹配
  → SQL 生成
  → 安全检查
  → DM8 查询
  → 结果解释

需要强调的是，数据库智能问数的关键不在于单纯生成 SQL，而在于建立可靠的 Schema 理解机制、严格的安全控制和可追踪的执行过程。以 DM8 为数据核心，以 dmPython 作为访问接口，再利用 DSH 提供 Agent 底座，可以为达梦数据库智能化应用提供一种具有扩展价值的技术实现思路。