你的企业数据，Agent 真的读懂并用对了吗？

对很多业务人员来说，这样的场景并不陌生：例会上，领导突然问“帮我看下华东区域本财年的收入达成率是多少？”

业务人员把问题交给 Agent，几秒后便得到一个答案。但这个答案真的能直接用于汇报吗？对熟悉公司业务的人来说，这句查询并不难理解，但如果要让 Agent 从企业数据库中返回一个真正符合业务要求的答案，它首先需要理解一连串隐藏在问题背后的业务语义，然后才能基于上下文进行查询。

图1 Agent 准确查询企业数据所需的业务语义映射

Agent 能否准确回答企业数据问题，关键在于用户的业务语言能否准确映射到企业内部真正的数据对象、指标口径和业务规则。当这层映射不准确时，即使 SQL 能成功执行，得到的也未必是业务真正想要的答案。

但在实际企业业务中，这层映射远比想象中复杂

在企业场景下建立这层映射，并不是简单地给字段补几句说明。企业的数据结构、业务知识和业务规则等往往分散在不同位置，并且随业务持续变化。要让Agent 长期准确理解企业数据，至少要解决三个难题。

难题1：数据零散，且缺少完整的业务含义

经过多年的业务系统开发，企业业务数据往往较为零散，存储在多种数据库中。同时，如果将这些零散的数据一股脑地“塞给”Agent，也只能告诉Agent一张表有哪些字段、字段是什么类型，以及表之间有哪些显式的外键关系。

图2 数据库结构无法完整表达业务含义

但这些结构信息不足以让 Agent 理解：一张表对应什么业务过程，一个字段在公司内部具体代表什么，以及一项指标应该基于哪些数据计算。例如，数据库中可能同时存在多个与“收入”相关的字段。仅凭字段名称，Agent 很难判断业务人员所说的“收入”究竟应该对应哪一个。简单来说，数据对象虽然存在，但并不天然带有足够完整、可供Agent使用的业务解释。

第一道难题，是让企业的零散的数据对象真正“有业务含义”。

难题2：业务知识存在，却散落在数据库之外

决定一次查询是否符合企业实际业务的关键知识，往往并不存储在数据库中。指标口径可能记录在指标文档中，区域与组织的映射维护在业务规则中，内部术语存在于各类说明文件里，而一些成熟的查询方法甚至只存在于专家经验中。

如果这些知识没有与具体的数据对象建立稳定联系，Agent 即使找到相关表和字段，也可能用错口径或遗漏企业内部特有的规则。

第二道难题，是让散落在不同载体中的业务知识，与对应的数据对象真正连接起来。

难题3：业务持续变化，已有映射易过时

企业业务并不是静止的。组织架构会调整，指标定义会变化，新的字段和业务编码不断出现，旧规则也会被新规则替代。

即使今天建立了一套正确的语义映射，如果无法跟随业务持续更新，这套映射仍会逐渐失真，Agent 基于过时解释得到的查询结果同样难以保证可靠。

第三道难题，是让这套映射关系不是一次性配置，而是能够随着业务持续校正和更新。

企业真正缺少的，是 Agent 与数据之间的一层语义基础

如果问题的本质，是业务语言无法稳定映射到企业数据，那么单纯提高模型能力，并不能从根本上解决问题。因为Agent 仍然需要准确的业务上下文。

因此，企业真正需要的是一套长期存在于 Agent 与企业数据之间的语义体系：一端连接数据结构，解释表、字段、指标代表什么；另一端连接企业自己的业务语言、规则和知识，明确业务概念应该如何落到数据之上。

图3 企业语义层实现业务知识与数据库结构映射

这套连接业务概念、数据对象和业务规则的体系，就是企业语义层。它在 Agent 与企业数据之间建立一套可被统一理解、持续维护和反复复用的“业务翻译体系”。

Nexa Knowledge：先让企业自己的语义被建立起来

Nexa Knowledge 是为解决企业语义的构建、维护与持续演进而生的企业级智能服务。针对前面的三个问题，Nexa Knowledge 分别从数据本身、企业知识和语义更新三个方向，让这层语义逐步建立起来。

图4 Nexa Knowledge 企业语义层的构建与持续进化

第一步：从数据出发，让散落的数据对象先“有业务含义”

Nexa Knowledge的第一步，是将企业原本分散的数据结构、业务知识和使用经验组织起来，构建一套能够被 Agent 理解、检索、调用并持续维护的企业语义层。

Nexa Knowledge 可以结合 TDSQL Nexa 的多模数据管理能力，将企业散落在各处的多模数据汇聚于同一平面。例如原有业务使用了 TDSQL 系列云数据库产品，如 TDSQL-B、TDSQL-C、云PostgreSQL 等产品，可以将已有实例平滑接入 TDSQL Nexa 作为数据源。

基于实例已有的表、字段、关系等元数据信息，为数据对象生成基础的业务描述，并结合表间关系进一步组织业务域。

这一步先建立基础语义骨架。对于Agent 来说，它看到的不再只是彼此孤立的表名和字段名，而是开始知道：哪些数据属于同一个业务领域，一张表承载什么业务信息，以及字段可能对应什么业务概念。

第二步：把企业已有知识补进来，让语义真正符合企业

仅有基础的数据解释，还不足以还原一家企业真正的业务。不同企业对同一个词的定义可能完全不同。即使都是“华东区域”，背后采用的范围也可能存在明显差异。

因此，Nexa Knowledge 进一步支持将数据库之外的业务知识纳入企业语义体系，包括业务文档、指标定义、术语说明、实体映射、业务规则，以及验证过的查询经验和分析方法。

企业可以直接上传各类业务文档和经验材料。Nexa Knowledge 会自动识别原料类型、解析内容结构并判断知识类别，将其中有价值的内容沉淀为 Skill、术语、澄清规则、已验证问答和世界事实五类知识资产，并建立可供后续检索和调用的索引。其中，Skill 和已验证问答不仅记录“业务概念是什么意思”，还可以沉淀业务人员和数据库专家在实际使用中形成的经验，例如应该查询哪些数据、遵循什么指标口径、采用怎样的查询步骤和数据处理规则。当 Agent 生成 SQL 时，系统会检索与当前问题相关的知识和经验作为依据，减少仅凭表名、字段名猜测查询逻辑的情况，让生成的 SQL 更符合真实业务要求，也更具备直接执行的可信度。

企业业务知识可以与具体的数据对象建立联系，并在后续查询过程中被 Agent 统一检索和使用。由此，Agent 不仅知道“这个字段是什么”，还进一步知道“在这家企业里，它应该如何被理解和使用”。

第三步：把真实使用反馈重新沉淀，让语义持续接近真实业务

在真实使用过程中，用户可能发现某个字段描述不准确，业务专家可能确认新的指标口径，一次成功查询也可能验证新的查询路径。

Nexa Knowledge 可以将这些交互中的确认和修正重新沉淀回对应的语义资产，让语义层持续被补充、校正和更新，而不是停留在起初的一次性配置。

随着越来越多业务问题被提出、越来越多规则被确认，企业获得的是一层越来越贴近真实业务、并能够持续复用的企业语义。

有了语义层，Agent 才能真正按照企业语境查询数据

再回到文章最开始的问题：“帮我看下华东区域本财年的收入达成率是多少？”

在 Nexa Knowledge中，Agent 不再是只能从字段名和已有上下文推测查询方式，而是先通过企业语义层理解“用户真正想查什么”，再据此定位数据对象、判断业务口径并生成数据查询。当一个问题存在多种合理解释时，例如同一个指标存在多套口径，系统可以进一步让用户确认所需定义，或在探索场景下明确当前采用的假设。

Nexa Knowledge改变了Agent 查询数据时的起点，从根据字段名称猜测用户意图，变成先理解企业自己的业务语义，再去使用数据。

而这次使用过程中被确认的新规则、新解释和新映射，也可以继续回到语义层中，为后续查询复用。由此形成一个持续循环：构建语义，使用语义，在使用中校正语义，再用更准确的语义服务下一次查询。

从“猜数据”，到按企业语义“使用数据”

过去，Agent 面对新的业务问题，需要重新判断该用哪些表、字段和指标口径，本质上是在一次次“猜”企业的数据。

图5 结合 Nexa Knowledge 的Agent后端架构

在多家企业客户的真实生产环境中，我们验证了 Agent 基于 Nexa Knowledge 语义层构建数据应用的实际效果，并取得了一组具备较强说服力的量化结果。

在中等规模的应用构建场景下（数据表规模在数十至上百张、业务逻辑相对清晰），SQL 生成准确率基本可以达到“零人工介入”水平——即 Agent 生成的 SQL 无需人工审核与修改，即可直接投入生产使用。

结语

有了可持续维护的企业语义层后，被确认的数据含义、业务规则和专家知识可以不断沉淀并复用。Agent 不再从零理解企业，而是基于统一的语义基础进行查询和分析。

Nexa Knowledge 带来的变化，不只是让一次问数更准确，而是帮助企业在现有的数据库架构上进行智能化升级，建立一层可被 Agent 持续理解、调用和进化的语义基础，让 Agent 真正理解并驾驭企业数据，将企业数据转化为可持续的智能生产力。

TencentDB