开放语义、Ontology 与元数据：Agent Context 的三重支柱

“上季度按产品类别统计的收入是多少？”同一个问题，BI 看板、Notebook 和财务模型可能算出不同结果。Agent 即使能访问这些系统，也需要知道该使用哪份收入定义、按哪个日期统计、如何关联数据。等到它进一步调用业务 API、触发工作流，还要确认当前用户有没有权限、操作是否符合规则。数据连接解决了访问入口，业务答案的准确性和后续动作的边界仍需要另外一套上下文来保证。

Agent 能查到数据，为什么仍可能算错收入

Agent 从回答问题（Answer）走向推理决策（Reason）和执行操作（Act），对上下文的要求也在增加。回答问题时，通常先找到相关文档、表和字段；要做决策，就得理解这些数据的业务定义、实体关系与适用条件；执行查询或业务动作之前，还需要检查权限、规则和操作前提。对应到数据系统中，是三个相互关联的问题：Data access 决定能否访问，Business meaning 决定如何理解，Operational constraints 决定当前条件下允许执行什么。

以收入统计为例，BI Dashboard 可能直接计算 SUM(order_total)，包含税费与运费；Notebook 使用 SUM(qty × unit_price)，但没有扣除折扣和退货；财务模型按 ship date 确认收入，并单独处理退款。缺少业务定义的 AI Agent 则可能选择最先找到的表，再自行推断 Join 关系。表面上都在回答收入问题，实际采用了不同的指标和计算路径。

差异落在四个地方：收入的定义、净额处理、时间口径，以及表之间的关联方式。底层数据相同，也不能保证最终数字一致。若没有可查证的定义和资产映射，业务人员很难判断哪一个结果适用于当前决策，更难要求 Agent 下次按相同口径重算。

资产、业务定义与实体关系，如何组成 Agent Context

支撑这类任务的上下文可以分为三部分。Unified Metadata（统一元数据）描述资产身份、结构、来源与访问接口，回答“数据在哪里”；Open Semantics（开放语义层）保存指标、维度、口径和业务术语，回答“这些数据在业务上是什么意思”；Ontology（业务本体）表达实体、概念、关系与约束，帮助 Agent 从抽象概念找到具体对象，并理解它们之间的联系。三者各有职责，实际查询和操作仍由查询引擎、业务 API 或工作流系统完成。身份权限、版本、校验、审计和反馈贯穿其中。

企业已有的数据分散在 Lakehouse、数据库、流系统以及文件和模型资产中。建设 Agent 不会改变这些系统的分布，统一元数据要做的是为异构资产提供相对稳定的标识、结构与血缘信息和访问入口。Apache Gravitino 就用于连接 Iceberg、Hive、MySQL、PostgreSQL、Kafka 等不同类型的资产；它统一的是资产的描述与访问方式，并不要求把数据全部搬到一处。

例如，一个收入语义模型需要引用 orders、items、products 等资产，就必须准确定位对应的表和字段；底层结构发生变化，才能进一步分析受影响的模型。检索范围也需要控制。面对成千上万张表，可以用 Domain 按业务组织资产，将 Agent 的搜索限制在相关领域，而非每次扫描整个企业目录。

资产找到之后，还要确认计算口径。以 Ossie Semantic Model 中的 net_revenue 为例，指标表达式为 SUM(order_items.net_amount)，时间字段使用 orders.order_date，分析维度为 products.category，并记录相关关联。BI、业务应用和 Agent 共用这份已确认的语义定义，收入计算便有了可以共同引用的依据，不必每个工具都重新推断字段和关联。

共享定义要跨工具使用，还需要解决两个环节：交换格式让模型在 BI、应用和 Agent 之间流通；运行服务将模型绑定到真实资产，检查调用者权限，再编译到相应的执行引擎。格式统一解决了定义如何传递，运行时检查则决定这份定义能否在当前系统和调用者身份下执行。

收入查询主要围绕指标计算；“哪些表包含客户个人数据，这些数据是否受到保护？”则涉及概念和关系。可以将 PersonalData 定义为上位概念，EmailAddress 和 PhoneNumber 作为其子类，再把这些概念分别绑定到 lake.crm.customers.email、mysql.loyalty.member_email、kafka.events.contact_phone 等实际字段。一个业务概念由此能够关联多个系统中的数据资产。

查询时，先通过 Glossary 和类定义解释 PersonalData 的范围，再沿概念关系进行 SPARQL 路径查询，跨目录定位对应资产，随后检查相关的 Mask / deny 策略。Ontology 负责表达概念及其关联范围；资产位置仍由元数据确定，脱敏和访问限制还要通过策略系统落实。仅凭某张表的字段名，很难完整回答个人数据分布及保护情况。

同样是 Agent 请求，所需上下文可以走不同路径。按产品类别查询收入时，先从 Glossary 确认 revenue 的业务含义，选用语义模型中的 net_revenue，再通过 Metadata 定位数据，由 Engine 编译和执行。检查个人数据保护时，则可先通过 Domain 限定业务范围，利用 Ontology 查找相关概念与资产，再由 Policy 检查脱敏和访问权限。

两条路径共用业务域、术语、受治理资产与调用者身份，但任务不必固定经过所有组件。收入统计更依赖语义模型，个人数据检查更依赖概念关系和策略。运行时按照问题组织所需的上下文，才能减少无关信息，也避免让 Agent 自行猜测业务定义。

上下文给出了正确的指标和关系，还要解决“谁可以用”的问题。治理需要覆盖四个环节：Model access 检查是否可以查看、使用模型；Asset access 检查是否有权访问模型引用的表和字段；Business rule 判断任务是否符合业务条件；Execute & audit 则要求相关系统落实限制并留下执行记录。模型权限和底层资产权限是两套独立的检查。

假设调用者能够使用收入语义模型，却没有 products 表的访问权限，编译阶段就应拒绝查询，并明确指出缺失的资产权限。对于允许执行的查询，引擎还要应用 row filter、column mask 等限制。答案与所使用的定义、模型版本及负责人信息一同保留，后续才能追查结果的计算依据和执行条件。

应用能跑通，业务知识怎样留下来

把这套上下文用于企业，通常会遇到四类困难。BI、应用和 Agent 独立建模，同一指标容易出现多个版本；技术元数据能自动采集，收入确认等业务口径仍需要业务人员判断；资产跨系统分布，标识、结构和访问方式不一致；字段、权限和业务规则持续变化，已发布的定义也可能过期。建设时既要尽快验证一个真实任务，又不能让每个 Agent 都留下另一套无法复用的定义。

风险在后续复用。如果 revenue、customer、order 的定义一直留在单个 Agent 中，另一个团队建设客户分析应用时，就可能重新定义同一批概念。任务虽然跑通，已验证的知识却没有进入组织内可以共同使用的模型，语义孤岛仍然存在。

另一种做法是 Bottom-up，先建设共享资产目录与治理基础，统一身份、权限、标签、审计和跨引擎访问，再为不同业务系统和 Agent 提供入口。它适合承接跨系统的资产管理、影响分析和权限控制，但起步范围较广，验证业务价值可能需要更长时间。

目录能够展示 order_date、ship_date 等字段，也能发现关联关系，却不能仅凭结构判断收入应该按哪个日期确认。业务含义来自指标定义和使用场景，需要财务或相关业务负责人参与。否则，资产目录覆盖得很全，Agent 在关键口径上仍然无法作出可靠选择。

Top-down 能较快形成可用应用，却容易重复建模；Bottom-up 建立公共底座，却可能缺少经过任务检验的业务定义。两者的结合点，是把场景中验证过的指标、实体和规则，与真实资产映射一起发布为共享模型。后续任务直接引用这些模型，运行中暴露的歧义和错误再进入修订流程，避免每个应用长期维护自己的版本。

混合建设可以从一个高价值场景开始，由业务和工程团队共同确认定义，利用统一元数据绑定真实资产，再通过参考问题、参考答案以及不同角色验证模型。验证通过后，将模型发布为共享对象；后续使用反馈继续用于修订。这里的关键是把应用中形成的定义交给公共治理流程，不能只停留在 Agent 的提示词或私有配置里。

为减少手工建模，可以导入已有指标和业务术语，结合元数据、历史查询及报表生成候选语义模型。工程团队通过 Git workflow 维护版本，业务负责人进行 Steward review，确认口径和适用条件后再发布。自动生成可以减少整理工作，但候选定义仍须经过审核，尤其是那些无法从技术元数据中直接确定的业务规则。

模型发布并不代表维护结束。字段删除或类型变化、资产迁移、权限调整属于 Technical change；指标口径、分类和适用范围调整属于 Business change；失败查询、歧义和人工纠正则构成 Usage feedback。任何一类变化都可能影响语义模型、Ontology 与底层资产之间的绑定关系。

这些变化进入 Review pipeline 后，需要经过 Impact analysis、Validate、Approve、Publish + history：先判断受影响的资产和模型，再校验修改、审核发布并保留历史。系统可以收集附有来源和置信信息的 Candidate context，但它仍是待确认的候选知识；维护者审核后，才能进入 Curated context。使用中积累的证据不能绕过审批，直接改写已发布的正式定义。

从共享模型到可执行的上下文服务

前面的资产、语义和治理机制可以组织为 AI 上下文平台（AI Context Platform）的四层参考架构。USE 层连接 Agent、BI 和业务应用；CONTEXT 层管理 Open Semantics、Ontology、Domain 与 Glossary；ASSET 层负责 Unified Metadata、Mapping 和 Access APIs；EXECUTE 层对接 Query Engine、Business API 和 Workflow。Identity、Policy、Version、Validation、Audit 与 Feedback 贯穿各层，保证模型引用和实际执行受到相同的治理约束。

这套架构按任务与调用者身份准备上下文。收入查询需要的是“term → metric → assets → SQL”，个人数据检查则沿“concept → assets → policies”处理。它们可以共享底层资产与权限体系，但在运行时选取不同的定义和关系，最终由对应的引擎或业务系统执行。

Datastrato 的产品方向也围绕这四个环节展开：DISCOVER 通过统一元数据连接异构资产，借助 Domain 和 Glossary 限定检索范围、解释业务术语；MODEL 表达指标、维度与关联，结合 Ontology sidecar 的实践方式；GOVERN 负责模型和资产授权、审核认证、版本及执行前策略检查；SERVE 通过 REST、MCP 等接口服务 Agent，并面向调用者使用的引擎提供编译及模型解释能力。

企业 Agent 要持续使用这些上下文，依赖的不只是一次建模。业务定义必须有人确认，模型要准确绑定底层资产，权限和业务规则要由实际执行系统落实；字段、口径和使用场景发生变化，还需要能够追溯影响、修订模型并保留版本。

数据目录向 AI Context Platform 延伸，困难也随之从“找到数据”进入“维护业务理解”的范围。一个收入指标由谁认定、适用于哪些业务条件、何时需要重新审核，以及 Agent 依据什么权限执行，都需要落实到明确的责任人与系统机制中。

企业 Agent 的落地，最终还是要回到一个具体问题：当它面对真实业务任务时，能否找到正确的数据、理解准确的业务含义，并在权限和规则允许的范围内完成操作。

统一元数据解决数据资产的定位与连接，开放语义层统一指标和业务口径，Ontology 则把分散的实体、关系与约束组织起来。但这些能力能否长期发挥作用，还取决于企业能否将业务场景中验证过的定义沉淀为共享知识，并随着数据结构、业务规则和使用反馈持续更新。

从数据目录走向 AI Context Platform，企业需要建设的不只是让 Agent 获取更多信息的入口，还包括一套能够持续维护业务定义、追踪数据来源、落实操作约束的基础设施。只有这些基础工作跟得上，Agent 才有条件从回答数据问题，进一步走向可靠的业务决策与执行。

作者介绍：堵俊平，Datastrato 创始人兼 CEO；原 LF AI & Data 基金会董事主席，Apache 软件基金会（ASF）成员，Apache Gravitino 联合创始人，Apache Hadoop、Submarine、Incubator PMC。曾任腾讯开源联盟主席兼大数据研发总监、Hortonworks（Cloudera）Hadoop YARN 团队负责人。

本文整理自堵俊平在 DACon 2026 北京站的主题演讲。

参考来源

Apache Gravitino 项目地址：https://github.com/apache/gravitino

点个在看你最好看

SPRING HAS ARRIVED