10 上下文层：元数据、语义与契约

本章产出： Context Layer 的概念模型、核心实体关系，以及一份从“数据目录”演进为“Agent 上下文基础设施”的建设清单。

企业部署大模型时，一个根本矛盾很快显现：模型拥有广泛的公共知识，却不了解这家企业此刻的真实世界。它不知道“客户”在销售和财务系统里为何不是同一个粒度，不知道某项指标已经更换口径，不知道一张表由谁负责，也不知道一份制度只适用于特定区域。把更多表和文档交给模型，并不会自动消除这种无知；没有语义和边界的数据越多，模型越可能在相互冲突的证据中组织出流畅但错误的答案。

上下文层的作用，是把分散在系统、文档和人的头脑中的“关于数据的数据”组织起来：它是什么、来自哪里、如何变化、是否健康、由谁负责、与什么相关、谁可以在什么目的下使用。Agent 不仅需要取到数据，还要在行动前理解这些条件。Context Layer 因此不是单一数据库，也不只是一个数据目录，而是一组贯穿发现、理解、信任和使用的数据能力。

OpenMetadata 将自己描述为面向 AI 的开放上下文层，把技术元数据、质量、血缘、所有权、用量、策略、对话、记忆、术语、分类、指标、领域、数据契约和数据产品连接起来，并通过搜索、API 与 MCP 等方式激活这些上下文(OpenMetadata Contributors, 不详)。本章借鉴的是这种开放模型和连接思想，而不是要求所有企业采用同一种产品。

10.1 数据值与上下文的区别

假设 Agent 读到字段 available_qty = 12。只有数值，它无法判断：

这是账面量、可销售量还是可承诺量；
单位是件、箱还是托盘；
数据在何时更新，最大允许延迟是多少；
是否包含已锁定、质检或在途库存；
哪个系统和团队对它负责；
当前用户能否查看对应仓库；
这个字段最近是否发生过口径变更；
数据质量检查是否刚刚失败。

上下文不是附加说明，而是正确使用数值的条件。传统分析中，人可能通过经验补齐这些信息；Agent 缺少组织经验，更容易把名字相似的字段拼接起来。机器可读的上下文必须成为数据产品的一部分。

10.2 上下文层的六类内容

10.2.1 技术上下文

包括数据库、表、字段、文件、主题、API、任务、模式、类型、分区、连接和运行状态。它回答数据在技术上位于何处、如何到达、怎样访问。技术元数据通常由连接器自动采集，但自动采集只能说明结构，不能替代业务解释。

10.2.2 业务语义

包括业务术语、定义、同义词、实体、关系、指标、维度、规则、适用范围和示例。它回答一个概念对企业意味着什么。业务术语不应只是百科全书条目，而要连接到实际字段、数据产品、报表、API 和责任人。

例如“首次修复率”必须说明分子分母、工单粒度、观察窗口、何谓重复上门、取消工单是否纳入。Agent 若只检索到术语解释却找不到可执行指标定义，仍可能自行编造计算方式。

10.2.3 来源与血缘

血缘描述数据从哪里来、经过何种转换、被哪些消费者使用。字段级血缘帮助解释一个指标的输入，产品和 Agent 级血缘则帮助判断某次变更会影响哪些检索索引、工具和业务流程。血缘应同时包含自动采集和人工补充，因为文档发布、规则审核和人工标注未必存在于 SQL 任务中。

10.2.4 质量与运行状态

包括完整性、唯一性、准确性、新鲜度、分布异常、契约检查、管道延迟、服务可用性和事件。关键是把检查结果连接到具体资产、时间与消费者。Agent 在使用数据时可以获取当前健康状态：当库存链路延迟超标时，只提供“待确认”而非确定数字。

10.2.5 所有权与治理

包括领域、业务所有者、技术维护者、分类标签、访问策略、保留、驻留、使用目的和审批。所有权不能只是联系人姓名；要说明谁有权定义语义、谁负责修复质量、谁批准访问、谁接受服务等级。策略必须能在实际查询和工具调用时执行，而不只展示在目录页面。

10.2.6 使用、反馈与记忆

包括资产被谁使用、热门查询、常见失败、讨论、认证状态、用户反馈和已确认经验。使用信号可以帮助排序和退役，但不能把“常用”误作“正确”。Agent 的长期记忆也应区分个人偏好、会话状态、团队知识和企业事实，并有来源、期限与删除机制。

10.3 核心实体关系

Context Layer 可以围绕下列实体建立关系：

flowchart TD
    D[领域 Domain] --> P[数据产品 Data Product]
    P --> A[数据资产 Asset]
    A --> S[模式与字段 Schema]
    T[业务术语 Term] --> S
    M[指标 Metric] --> A
    C[数据契约 Contract] --> P
    C --> A
    Q[质量与 SLO] --> C
    L[血缘 Lineage] --> A
    O[所有者 Owner] --> D
    O --> P
    R[策略 Policy] --> A
    U[消费与反馈 Usage] --> P
    G[Agent / 应用] --> P

领域提供责任边界，数据产品提供面向任务的消费边界，资产承载技术对象，术语和指标提供语义，契约声明承诺，质量与血缘提供可信度，策略规定可用范围，使用与反馈证明价值。企业不必一次实现所有实体，但应保持模型可扩展，避免把目录设计成只有表和字段的静态清单。

10.4 数据目录为何不等于上下文层

目录解决“有什么”和“在哪里”，上下文层还要解决“是否适用于当前任务”和“此刻能否安全使用”。一个静态目录常存在三类断裂：

第一，目录与运行系统断裂。页面上标注了敏感等级，但查询层没有执行；质量显示良好，但结果来自上周；所有者变更后没有同步到告警流程。

第二，目录与消费端断裂。用户可以浏览资产，Agent 却无法通过稳定接口获得相同语义和策略；或 Agent 只能检索描述，不能得到结构化关系和状态。

第三，目录与反馈断裂。消费失败、语义争议和业务结果没有回流，上下文随着业务变化逐渐过期。

因此建设重点应从“登记更多资产”转向“激活关键上下文”：让语义进入查询，让策略进入执行，让质量进入决策，让血缘进入变更，让反馈进入运营。

10.5 语义必须可执行

业务术语表常见的失败方式是写了大量定义，却没有连接数据。可执行语义至少具备四个层次：

词汇层：术语、同义词、缩写、定义和示例；
模型层：实体、属性、关系、层级和有效时间；
计算层：指标公式、过滤条件、粒度、窗口和版本；
服务层：可查询接口、权限、响应模式和 SLO。

以“有效保修”为例，词汇层说明概念，模型层连接设备、客户、合同和零件，计算层表达日期与例外规则，服务层让 Agent 用设备标识查询并获得结论、依据和规则版本。若只把保修制度切成文本，模型必须自己解释复杂条件；若只提供一个布尔字段，又无法说明为什么。结构化结果与规则证据结合，可靠性更高。

语义冲突不应通过强制统一所有系统来解决。不同领域可能合法使用不同粒度。上下文层应保存差异、映射和适用范围。例如“客户”在销售域代表集团与商机主体，在售后域代表安装地点，在财务域代表开票主体。统一企业标识可以连接它们，但不应抹去各自业务含义。

10.6 数据契约把说明变成承诺

元数据说明“当前是什么”，契约声明“生产者承诺什么，消费者可以依赖什么”。契约可包含模式、语义、质量规则、新鲜度、可用性、访问策略、使用条款、版本和通知机制。OpenMetadata 的数据契约模型也覆盖模式与质量保证、状态与版本、访问政策，以及刷新频率、最大延迟、可用性、时区和保留等服务要求(OpenMetadata Contributors, 不详)。

契约首先是组织协议，其次才是机器文件。生产者、数据产品团队和消费者需要共同确认：哪些字段是稳定接口，什么变化属于破坏性变化，质量未达标如何通知，谁承担修复，消费者应如何降级。

契约应尽可能自动执行。模式变更在部署前检查，新鲜度和质量在运行时监测，访问策略在请求时判定，弃用通过依赖关系通知。无法自动验证的语义变化仍需人工评审。不要把契约变成阻止任何变化的官僚流程；它的目的，是让变化可见、可协商、可迁移。

10.7 为 Agent 提供上下文，而非倾倒元数据

企业元数据可能非常庞大，不能把整个目录放进提示。上下文服务应根据任务、身份和当前对象选择最小必要信息。例如 Agent 查询某设备的故障时，可以获得：

设备实体定义与唯一标识；
当前配置及其来源、有效时间和质量状态；
可用的手册与案例产品端口；
“可用库存”等相关术语和指标定义；
当前用户的可见范围和工具权限；
关键契约是否达标、是否存在已知事件；
回答中必须携带的引用和限制。

上下文检索应支持关键词、语义、关系和结构化过滤。机器不仅要找到描述相似的资产，还要沿血缘、领域、术语和产品关系理解其位置。结果排序可以考虑语义相关性、认证、质量、时效和使用信号，但权重与理由应可解释。

面向 Agent 的接口可以是搜索 API、图查询、语义服务或 MCP 工具。接口返回应结构化、紧凑、带版本，并在访问前执行权限。开放协议有助于多个 Agent 复用，但协议不会自动解决语义和治理；工具背后的数据产品仍需负责。

10.8 权限与策略要随上下文传播

资产标签只有在下游持续有效才有意义。源字段被标记为个人信息后，派生表、搜索文档、向量块、缓存和评测样本都应继承或重新计算分类。访问决策还可能取决于用户、岗位、区域、客户关系、使用目的、设备和时间，不能只在表级做静态授权。

Agent 检索要先过滤再召回，工具调用要使用用户或受委托身份，输出还要防止多源组合产生新的敏感推断。策略判断本身也应有版本和审计：谁在什么时间以什么目的访问了什么，依据哪条策略允许或拒绝。

当删除请求或保留期限到达时，上下文层的关系图可以帮助定位派生索引、缓存和反馈副本。没有传播关系，企业很难证明删除完整。

10.9 新鲜度、可信度与冲突

上下文也会过期。术语定义、所有者、策略和文档适用范围都需要生命周期。每项关键上下文应有来源、最后确认时间、负责人和复审周期。自动采集的技术元数据可以频繁刷新，业务定义和规则则需要领域审核。

面对冲突，不应让模型随机选择。可建立基于权威等级、有效时间、认证状态、质量分数和适用范围的决策顺序。如果仍无法判断，返回冲突本身并要求人工确认。上下文层的价值不只是给出答案，也包括诚实暴露企业尚未统一的地方。

可信度不宜简化为一个神秘总分。更有用的是可解释信号：是否来自权威系统、是否经过认证、质量检查是否通过、是否在 SLO 内、是否存在争议、最近何时使用。Agent 可以按任务风险决定接受、澄清或拒答。

10.10 建设顺序：从关键链路开始

企业无需先建完整知识图谱再做场景。更务实的顺序是：

选择一个高价值任务，识别其关键实体、数据产品和规则；
自动采集相关技术元数据、模式、血缘与运行状态；
由领域专家补充术语、指标、所有权和适用范围；
为关键接口建立契约、质量检查与变更通知；
通过搜索、API 或工具向 Agent 激活上下文；
用真实查询与失败反馈持续补充关系和语义；
当第二个场景出现时，提炼可复用模型和平台能力。

山城精工可以从设备、型号、客户、工单、零件、手册六个实体开始，连接权威来源、所有者、有效时间、质量和权限。无需一开始登记企业全部数据资产。随着采购助手、质量分析等新场景加入，再扩展供应商、批次和检验等领域。

10.11 运营 Context Layer

上下文层不能作为一次性治理项目。需要明确运营指标：关键产品的所有者覆盖、业务定义覆盖、血缘完整、契约通过、新鲜度、搜索成功、无结果查询、争议解决时间、过期上下文和实际消费。指标应聚焦被使用的关键链路，而不是追求目录条目总数。

运营节奏可以包括每周处理质量和无结果查询，每月复审高影响术语与契约，每季度审查产品生命周期、权限和未使用资产。平台团队负责自动化与体验，领域团队负责语义和质量，治理团队负责标准与争议机制，安全团队负责策略，产品经理负责把反馈转成价值优先级。

10.12 本章交付物：上下文模型画布

为一个目标场景建立上下文模型时，应提交：

模块	必须说明的内容
领域与产品	责任边界、消费者、任务和生命周期
实体与语义	实体、属性、关系、术语、指标和有效时间
资产与血缘	技术对象、来源、转换、索引和消费依赖
契约与质量	模式、SLO、检查、版本、变更与降级
所有权	语义、质量、技术、权限和运营责任
策略	分类、身份、目的、范围、保留与审计
激活接口	搜索、API、语义查询、图关系或 MCP 工具
反馈运营	无结果、争议、故障、使用、价值和复审

如果数据层回答“企业拥有什么事实”，上下文层回答“这些事实在当前任务中意味着什么、是否可信、如何安全使用”。它把原本依赖老员工记忆的组织知识变成可连接、可执行和可演进的公共能力。Agent 的可靠性并非只来自更大的模型，而来自企业能够在正确时间为模型提供正确事实、正确语义和正确边界。