构建可信数据智能体的上下文层 ｜ 技术趋势

2026 年，智能体将在企业级应用中取得哪些实质性突破？点击下载《2026 年 AI 与数据发展预测》白皮书，获悉专家一手前瞻，抢先拥抱新的工作方式！

为什么“与数据对话”只是入门基础——以及为什么赢家将构建上下文，而不仅仅是模型？

对于我们这些在数据领域深耕数十年的人来说，近期业界对“上下文层”日益增长的兴趣，既令人欣慰，也引人深思。这些并非新概念，而是计算机科学的基本原则。语义层之所以重新浮出水面，是因为大多数企业都发现了一个同样令人不安的现实：模型听起来很聪明，但仍然会生成那些“确信的错误答案”。

这种失败模式，与其说是模型推理能力的问题——因为模型实际上已经变得非常聪明，且仍在持续进步——不如说，瓶颈在于能否获取正确的上下文。

在受控演示中，智能体可能表现出色。但在企业内部，它被迫在混乱的环境中运作：业务概念支离破碎、规则隐含不显、历史记录缺失，并且“真相”在不同系统之间往往存在争议。

分析人员的实际工作是多步骤、跨领域且涉及办公室政治的。业务负责人所提出的“为什么”和“是什么”，远不止是 SQL 查询：

• “找出变化所在，解释变化原因，并建议应对措施。”

• “比较两种定义，调和冲突，并生成一份能够提交董事会的汇报性叙述。”

• “调查异常情况，并将其与导致该异常的业务事件关联起来。”

正是在这里，企业的现实问题开始浮现：

• 语义孤岛：“客户”一词在不同系统中含义迥异；

• 因果缺失：数据仓库捕获的是状态，而非导致该状态成立的决策过程与相关讨论；

• 隐性规则：财年日历、资格标准、审批策略以及禁用指标，通常零散分布，仅存于口口相传的经验之中；

• 真相冲突：财务系统和 CRM 系统的数据可能都被视为“可信”，但彼此之间仍然存在分歧。

因此，核心问题已经从“模型能否生成 SQL？”转变为：“智能体能否在你企业的语义、策略和历史约束范围内运作——并且能够证明其确实如此？”

定义：可信智能体的最小词汇表

首先，确立如下若干核心概念：

• 分析语义模型：一种面向分析的接口，用于定义度量、维度及实体，并将其映射至物理数据层，使用户无需了解底层架构或掌握 SQL 即可操作数据；

• 关系与身份层（在企业环境中常被称为“本体”）：对跨领域概念、关系及规则的机器可读表征。它涵盖身份解析、同义词处理与约束机制，以确保跨域集成的安全性与显式化。其表现形式可为 OWL/RDF、经过治理的连接图谱，或与受管控数据产品的概念绑定；

• 业务规程：经版本控制的运营操作手册，明确定义工作的执行方式，包括路由流转、审批流程、异常处置及策略实施规则；

• 证据与溯源：针对答案的追溯链路，包含所用数据来源、施加的转换逻辑、数据源的沿袭关系，以及为何采纳或拒绝竞争性来源的说明；

• 策略与权限：可由机器强制执行的规则集，用于界定用户（或代表用户行事的智能体）在检索、计算及披露数据方面的授权范围。 

语义与智能体上下文：旧理念迎来新紧迫性

语义模型与本体论并非新概念。数十年来，企业一直在通过商业智能语义层、主数据管理、数据目录和知识图谱等手段，追求数据含义的一致性。本体论在生命科学与医疗保健等领域也已相当成熟——在这些领域中，复杂的生物医学概念与标准化的临床术语天然构成了图状的知识结构。与此同时，业界对语义层和本体论的关注度正显著上升。

图 1：谷歌趋势显示“语义视图”与“本体论”的搜索热度呈上升趋势

这一趋势的出现并非偶然。语义模型和本体论在以下几个方面对大语言模型驱动的智能体构成了重要补充：

• 大语言模型能够理解意图并处理歧义，但通常缺乏企业级上下文。语义模型与本体论则以可复用的形式编码了该上下文；

• 大语言模型的输出具有概率性；而语义产物则是基于事实且可验证的；

• 语义产物的构建历来成本高昂且容易与实际需求脱节；自然语言界面与智能体工具的引入，使得生成、管理并保持语义产物时效性变得更加可行。

同时需要强调的是，本体论本身并非最终目标。真正的目标是构建高质量的数据智能体。自然语言作为实用的前端入口，改变了系统必须提供的底层支撑能力。仅将问题转化为 SQL 查询已远远不够。智能体需要一层包含语义、身份标识、约束条件、策略规则与数据血缘的上下文层。

这便是当前的关键转折点：

• 大语言模型使得从“文本到数据”的转化变得切实可行；

• 智能体上下文则为智能体分析提供了可信赖的基础。

通过标准化指标与定义，语义分析模型最擅长在特定领域内交付可信的分析结果。当智能体同时具备显式的关系空间、身份解析能力、可连接性及约束条件（无论这些是以形式化本体论、精选的连接图谱，还是从概念到分析对象的绑定方式实现）时，跨领域工作才能真正可靠地开展。

当前的实际重点应在于：借鉴本体论和语义层中有价值的部分，但围绕智能体在企业真实环境中良好运作所需的条件进行优化。

面向可信数据智能体的实用架构

迈向多步骤可靠智能体分析，需要基于受管控的语义、明确的关系以及可审计的决策进行推理。对于企业级智能体，必须协同以下各层才能构建有效上下文。

 图 2：为企业级智能体创建上下文所需的层次结构

分析层

分析层提供与物理数据映射的指标、维度和实体。指标定义（包括筛选条件、连接逻辑与计算公式）统一存放，可在不同智能体体验中复用。语义视图作为分析层的精选且受管控的接口，同时保障分析操作的安全性。

自然语言问题（例如“收入”或“NRR”）需映射到具体的指标定义，包括正确的筛选条件（如“仅包含已关闭并赢单”）、默认时间窗口及允许的粒度。

示例问题：

“过去两个季度的 NRR 是多少？按企业客户与商业客户拆分。”

语义视图的应用：

• 指标：NRR（定义包含客户群组与续约逻辑）；

• 维度：季度、客户细分；

• 默认筛选条件：排除内部/测试账户；

• 时间逻辑：最近两个财务季度。

结果输出：

• 按季度与客户细分呈现的 NRR；

• 指标定义参考（NRR vX）；

• 所用查询参数（时间窗口、客户细分映射关系）。

关系与身份层（本体）：概念与绑定

该层定义了规范化实体（例如客户、账户、工单）及其之间的类型化关系，同时提供与数据世界之间的绑定（ID、语义对象、表）。该层还涵盖同义词/别名处理以及跨系统的身份映射。对于跨领域问题，通常需要将同一真实世界实体在不同系统中的不同标识符进行关联（例如 CRM 中的账户 ID 与支持系统中的组织 ID）。本层提供上述映射能力以及连接各领域所需的关系结构。

在一项内部实验中，我们构建了一个需要多个语义视图才能回答的查询集，并从最终答案准确率、总延迟和工具调用次数三个维度进行性能评估。实验发现，与遵循最佳实践的基线相比，仅需向智能体补充一份纯文本的“数据本体”（包含连接键、表粒度及基数/扇出提示），即可实现以下提升：最终答案准确率提高 20%，平均工具调用次数减少约 39%，端到端延迟降低约 20%。

以下是查询集示例：

问题：

“显示我负责的客户名录中未关闭的升级工单，以及每项面临风险的年度经常性收入。”

关系/身份使用情况：

• 规范化实体：客户

• CRM 映射：客户↔ CRM.AccountId

• 支持系统映射：客户↔ Support.OrgId

关系：

客户拥有支持工单

客户拥有合同（含年度经常性收入）

执行计划：

1) 在 CRM 中查找负责区域内的账户

2) 映射 CRM.AccountId →客户

3) 映射客户→ Support.OrgId →未关闭的升级工单

4) 映射客户→合同/年度经常性收入（财务语义对象）

5) 在客户粒度上关联结果

操作手册（指令集）：流程与路由

这是一套受管控的指令集合，描述了智能体处理特定意图时应遵循的方式，具体包括：路由至权威数据源、必要的澄清步骤以及必需的检查项（例如，“定价必须使用认证表格”或“禁止披露赢单率”）。

某些问题需要一致的程序化处理。手册为不同用户与渠道（如智能体、商业智能助手、嵌入式应用）提供了标准化的执行路径：

问题示例：

“针对欧洲、中东及非洲（EMEA）地区的客户，产品 X 的价格是多少？”

手册编号：定价查询

操作步骤：

1) 确认上下文：客户细分、合同类型、生效日期。

2) 路由至权威的定价语义对象（已认证）。

3) 应用适用于欧洲、中东及非洲（EMEA）地区的区域/货币规则。

4) 返回结果：价格+生效日期+所使用的数据源。

溯源与可解释性：使用了什么以及如何使用

此层提供关于答案如何生成的可审查记录：包括所选用的语义对象、应用的过滤条件、执行的关联操作，以及确立的时间戳/数据新鲜度。对于冲突情况，可包含选定哪个数据源及其采用的规则。

用户常会提出诸如“这是怎么算出来的？”或“为什么这份数据与另一份报告不同？”的追问。溯源机制为回答此类问题提供了一致性依据：

问题示例：

“第四季度的流失率是多少？为什么与上周的报告不同？”

溯源返回：

• 指标：Churn_Rate（定义版本 v2.4）；

• 过滤条件：排除非自愿流失；

• 时间窗口：FYQ4（财年日历）；

• 数据源：计费事件表（截至时间戳）、客户状态快照。

与上周差异对比：

• 定义由 v2.3 变更为 v2.4；

• 对计费事件表执行了回填操作。

事件与决策记忆：状态与原理

该层存储与业务实体关联的事件轨迹及决策产物，具体包括：审批记录、事件时间线、变更事件，以及相关的工单或沟通线程。此记忆层可集成至多种应用场景，例如：分析场景：构建正确的关联查询逻辑；业务概念定义：记录指标计算口径的变更；数据对账场景：在信息冲突时，判断应采信哪一方的数据依据。该层为“为何”类核心问题提供证据支撑。许多工作流所需的解释必须根植于操作历史记录，而非仅依赖当前状态快照。

问题示例：

“为何批准了 Acme 公司 20%的折扣？由谁批准？”

检索到的证据：

• 审批工作流记录（请求内容、审批人、时间戳）；

• 审批人填写的备注或理由字段；

• 关联的交易支持工单记录；

• 相关政策阈值参考依据（如适用）。

回答内容应包含：

•  审批人及对应时间戳；

•  已记录的审批理由；

•  支撑性产物的链接或唯一标识符。

为何这不属于提示工程范畴

人们易产生一种错觉，认为仅凭精巧的提示词设计即可替代智能体工程方法论。然而，在大规模实际应用中，纯依赖提示词的系统往往会迅速失效：其运作机制不透明、难以审计，且行为会随时间发生漂移。

采用智能体工程方法论则可提供持久且可治理的产物，具体体现在：

• 变更控制：支持可审计、带版本管理的发布上线流程；

• 可审计性：提供可解释的路由决策逻辑、关联查询规则及定义说明；

• 互操作性：以统一的语义基础层同时赋能商业智能工具与智能体运行；

• 治理能力：规则不再是建议性指导，而是转化为可强制执行的约束条件；

• 可复用性：支持业务概念经一次建模后，在不同上下文中被多次复用，避免重复定义。

智能体上下文的创建与维护：AI 如何改变其经济性

随着像 Cortex Code 这类强大智能体的兴起，构建与维护智能体上下文的任务已变得更加可行。大多数商业语义层难以成功落地的原因很简单：构建成本高昂、信息更新滞后，且其演进速度难以跟上业务发展的步伐。借助 AI 智能体，相关工作流程可被大幅简化——智能体能够阅读文档、知识图谱、本体、聊天记录及其他记录系统，从而创建上下文并保持其时效性。

以下是一个高度简化的 AI 智能体工作流程：

1. 从智能体与精选语义层入手（利用现有仪表板和查询历史记录）。

2. 从现有来源中逐层添加智能体上下文，包括：现有表的元数据、历史查询与使用模式、文档、运维手册、现有本体以及代码流水线。完成此步骤后，应已构建出一个功能较为强大的智能体。

3. 从真实使用模式中学习。

4. 提出改进建议，如同义词、映射关系及缺失的关联等。

5. 将人工审批纳入闭环流程。

6. 在持续扩大覆盖范围的同时，不断降低成本。

预测与结语

以下是我们对该领域未来演进方向的一些展望：

• 随着模型本身逐渐商品化，胜出的架构会将“智能体上下文”而非模型本身，视为产品的核心；

• 最成功的智能体会聚焦于需要解决的业务问题，而非将目光锁定在诸如本体这类单一产物上；

• 语义模型将继续作为受治理指标与可信领域分析的锚点。当智能体成为这一上下文的主要消费者时，保持这些语义层及时更新、对齐且机器可读的压力会不断增加，从而推动它们从静态的文档产物转变为动态的、被积极维护的资产；

• 由 Cortex Code 这类 AI 智能体驱动的智能体上下文层的生成与持续演进，将获得更多投入；

• 随着采用规模扩大，我们预计会出现促进跨平台互操作性的标准，让大语言模型（LLM）能够更轻松地解读这些上下文层，并在不同工具与生态中保持一致地执行操作。诸如 开放语义交换协议（OSI） 等举措，正是为了实现此类互操作性。

总体而言，我们相信元数据与数据目录建设将重获关注。这些语义层将越来越多地由人类与智能体协同维护。

最新进展

如果您是数据团队高管，正在构建需要复杂上下文处理与跨领域编排的智能体，我们诚邀您了解我们的最新进展：

语义视图： 了解如何构建跨领域编排的基础。

Snowflake Intelligence：了解我们如何将业务保障规则整合到统一智能层中。

原文地址：https://www.snowflake.com/en/blog/agent-context-layer-trustworthy-data-agents/

点击链接立即报名注册：Ascent - Snowflake Platform Training - China，更多 Snowflake 精彩活动请关注专区。