从数据字典到 Agent Context：企业数据上下文正在发生什么变化？

很多企业已经有数据字典。

数据字典通常记录表名、字段名、字段类型、字段说明和数据来源。

在传统 BI 时代，这些信息很重要。数据开发和分析师可以通过数据字典理解数据结构，减少重复沟通。

但到了 AI Agent 时代，只靠数据字典已经不够了。

Agent 需要的不只是字段解释，而是可以直接指导它回答业务问题的上下文。

数据字典回答“这是什么字段”

数据字典的核心问题是：这张表、这个字段是什么意思？

例如：

• •order_id 是订单编号；
• •pay_amount 是支付金额；
• •store_id 是门店编号；
• •member_level 是会员等级；
• •created_at 是订单创建时间。

这些信息能帮助人和 AI 初步理解表结构。

但业务问数通常不会停在字段层。

用户问的是：

• •本周销售额为什么下降？
• •哪些门店低于预期？
• •哪个渠道 ROI 变差？
• •新品在哪些用户群体里留存更好？

这些问题背后需要指标、维度、权限、业务规则和分析方法。

Agent Context 回答“这个问题该怎么分析”

Agent Context 比数据字典更宽。

它至少包括：

• •表和字段的业务说明；
• •指标定义、计算公式和适用范围；
• •维度层级，例如区域、城市、门店、渠道、商品；
• •字段值含义，例如“已核销”“退款中”“抖音本地生活”；
• •业务文档，例如活动规则、销售政策、渠道说明；
• •权限规则，例如谁能看哪些区域和敏感字段；
• •示例问题和标准分析路径；
• •查询边界，例如时间范围、超时、行数和资源限制。

微软 Fabric Data Agent 的说明中也提到，Data Agent 配置时可以加入数据源、instructions、example queries，并通过不同层级的 intent 管理组织策略、角色边界、开发者配置和用户提问。

这说明企业级 Agent 不是只靠模型“自由发挥”，而是需要明确的上下文和优先级。

为什么上下文比模型更容易成为瓶颈

模型能力越强，越容易让人误以为“把表结构给它就够了”。

实际情况相反。

如果企业的上下文缺失，模型只会更快地产生看似合理但口径不明的答案。

例如，“销售额”到底是支付金额、实收金额还是含税 GMV？

“华东区”到底包括哪些省市？

“高价值用户”按消费金额、购买频次还是会员等级判断？

“活动期”是按投放日期、下单日期还是核销日期？

这些都不是模型从字段名里必然能推出来的。

AskTable 如何把数据字典升级为 Agent Context

AskTable 的语义配置不是只为了写字段备注。

它要把企业内部的业务知识整理成 AI 可以使用的上下文层。

BuildTable 先把企业数据采集、存储、建模成 AI 友好的数据基础。

AskTable 在这个基础上补充表说明、字段说明、字段值索引、指标口径、业务文档、分析偏好和权限规则。

这样，AI 在回答问题时，不是面对一堆裸表，而是在企业定义过的上下文里选择数据、生成查询、解释结果。

这也是为什么 AskTable 更强调 AI Analytics，而不是简单 Text-to-SQL。

Text-to-SQL 解决“怎么写查询”。

Agent Context 解决“这个业务问题到底该按什么规则理解”。

企业应该从哪里开始

不需要一开始就建设庞大的知识体系。

更好的方式是从 10 个高频业务问题开始。

把每个问题背后的数据表、字段、指标口径、权限规则、业务文档和常见追问整理出来。

当这些上下文被持续沉淀，企业就会从“有数据字典”走向“有可被 AI 使用的数据智能上下文”。

参考来源

• •Microsoft Learn：Fabric data agent creation
• •Databricks：Open and Unified Business Semantics for BI and AI