引】如果 LLM 是大脑语义层就是 Agentic AI 的心脏——为Agent 构建缺失的上下文层。本文是“本体与AI”的系列文字之一也是《本体驱动的AI大模型方法与实现》一书的解释与补充。走进任何一家大公司你会看到同一份购物清单前沿 LLMClaude、GPT、Gemini等、企业数据平台、堆满非结构化文档的数据湖、向量数据库、一堆 Agent、编排框架LangGraph、CrewAI、一堆工具以及某种形式的记忆。架构图看起来很壮观Demo 也能跑通。然后 Agent 上到生产环境奇怪的事情发生了。两个 Agent 回答同一个营收问题给出两个不同的数字。一个关于上季度的简单问题生成了查错表的 SQL。成本飙升信任蒸发。那个号称要变革自助式分析的项目被悄悄搁置。这里缺失的不是更好的模型而是几乎没人画在架构图上的那一层——语义层。如果 LLM 是 Agent 系统的大脑语义层就是心脏。大脑可以很聪明但如果没有东西把干净、受治理、一致的含义泵给它它仍然一无是处。一、真正的问题LLM 本质上是一个训练于公共互联网数据的概率推理引擎。它从未见过你的ORDERS表。它可能不知道你们公司把净营收定义为总营收减去折扣和退货不知道上季度指的是最近完成的一个财季也不知道那个实际叫amt_ttl_pre_dsc的列就是财务部口中的顶线。把原始 schema 交给一个聪明的模型问它业务问题它会自信地编造缺失的业务逻辑。这不是模型的 Bug而是模型在上下文不足时精确地做了它被设计来做的事。指标漂移。问三个 Agent或三个仪表盘的总销售额你会得到三个数字。因为总销售额对 A 团队意味着仅零售对 B 团队意味着零售加批发对财务意味着零售加批发减退货。没有一个统一的受治理定义每个 Agent 都在临时重新推导业务逻辑。把它乘以几千个 Agent你得到的不是分析结果而是一场争论。RAG 的问题形状不对。RAG设计的初衷是从一堆非结构化文本中找到相关段落。但大多数企业问题不是检索型的——它们是计算型的。上季度各区域净营收不是躺在某个段落里等着被检索的它需要使用一个定义跨结构化系统正确地计算出来。RAG 原生地处理不了这些。MCP 是管道不是含义。Model Context Protocol 理所当然地成为了AI 的 USB-C 接口——连接 Agent 与工具和数据的标准线。但线只传递上下文不创造上下文。没有语义层兜底的 MCP只是打开了通往你数据仓库的每个阀门没有地图也没有过滤器。共同主线在于你技术栈里的所有组件都是必要的但没有一个提供受治理的业务含义这就是缺口。市场正在觉醒于一个简单的事实没有受治理语义的 AI 无法扩展。二、语义层和上下文层到底是什么语义层是业务中的受治理词汇表。这是净营收活跃客户流失率区域各被精确定义一次的地方——作为指标、维度和关系映射到你的物理表上——让每个消费者人或机器得到相同答案。经典 BI 语义层如 Power BI 的表格模型或 Looker 的 LookML是为仪表盘构建的被动、只读、为人点击而设计。上下文层比语义层更大。人们说的上下文其实有两个层面。第一层是运行时上下文——每次调用模型时喂给它的东西当前对话、本次会话的记忆、长期记忆、可用工具这个过程称为上下文工程。第二层是企业上下文层在运行时之上每个 Agent 都从中汲取的永久、共享的基础包括受治理定义、谁被允许看什么、每个数字从哪来跨越所有系统不只是一个数据仓库。简单说运行时上下文是一个 Agent 此刻看到的东西企业上下文层是每个 Agent 到处都在汲取的唯一事实源。MCP两者都不是它是传输层让 Agent 触达语义/上下文层的协议。MCP是连接不是智能。那么语义层和上下文层的实际区别是什么简短回答语义层是上下文层的一部分。语义层回答一个狭窄而精确的问题我们的业务术语是什么意思如何计算它是指标、维度和关系的字典——净营收 总营收减折扣和退货只定义一次。它是心脏的心脏但主要关于数字和定义。上下文层回答一个大得多的问题Agent 需要知道的一切才能正确安全地使用我们的数据。这包括语义层的定义加上周围的织物——哪些数据可信且经过认证、数据从哪来血缘、谁有权看权限、数据长什么样schema 和数据类型、表之间如何关联以及 Agent 应遵循的不成文家规那些活在 nobodys schema 里的注意事项和关联路径。上下文比指标更丰富被描述为一个由六类元数据组成的多层组装技术元数据schema、数据类型、安全标签IAM直接来自源系统语义元数据业务本体、术语表、分类运营元数据血缘、数据画像、使用统计、质量评分关系物理资产与业务概念之间的连接信任元数据 标识数据是否来自认证权威源的信号Agent 指引非结构化的Agent 说明书聚合前要应用的过滤器、要遵循的关联路径、schema 中看不见的注意事项业界日益收敛的新定义是上下文语义层 受治理指标 本体 知识图谱 记忆 LLM 编排三、为什么值得投入可部署的准确性。研究表明LLM 通过语义层查询而非直接查原始表时数据问题的准确率可提升多达3 倍。Databricks 报告其 Genie Ontology 上下文引擎将回答准确率从约 50% 提升至84.5%。Bloomberg Media 内部的知识差距 Agent仅通过将缺失的制度性知识捕获为受治理上下文就将其数据访问 Agent 的 SQL 准确率提升了63%。模型不再猜测业务逻辑因为业务逻辑被直接交给了它。一致性——终结指标漂移。净营收只定义一次每个 Agent、仪表盘和笔记本都继承它。财务签字的数字就是你面向客户的 Agent 引用的数字。不再需要调和三个真相。治理、安全和血缘——与生俱来。好的语义层在查询时执行 RBAC并在每个结果中携带血缘。Snowflake 的 Cortex Analyst 遵循基于角色的访问Microsoft 的 Fabric Data Agents 遵守 Purview 策略和行/列级安全AWS Context 通过 IAM 和 Lake Formation 让每个 Agent 查询具备身份感知。Agent 不会意外泄露用户无权查看的列每个答案都附带这是从哪来的链路。这是有趣 Demo 与合规允许上线的东西之间的区别。成本控制。当定义集中在一个受治理的地方你不再在每个提示词中重复它们更多问题留在受治理业务逻辑内而不是退化为昂贵且不可预测的原始表行为。Databricks 现在通过 Unity AI Gateway 加上硬性支出上限来包装这一切。更好的语义覆盖直接意味着更低更稳定的账单。可解释性与信任。因为指标、关系和已验证查询是显式的系统可以展示其推理过程。这正是把自信的 Agent 变成可信的 Agent 的关键——尤其当 Agent 从回答问题走向执行动作调整定价、下订单、分拣工单时。互操作性与面向未来。定义一个指标一次同时服务 Claude、ChatGPT、你的内部 Agent 和 Power BI——无需为每个定制胶水代码。四、如何构建各大平台操作参考没有叫语义层的单一产品需要自己组装。Google Cloud — Knowledge Catalog通用上下文引擎最完整的上下文层即产品方案。Knowledge Catalog 是一个 Gemini 驱动、常驻运行的上下文引擎构建动态上下文图谱来锚定 Agent 并减少幻觉。三大支柱聚合统一 BigQuery、AlloyDB、Spanner、Looker 及 Atlan/Collibra 等第三方目录的技术元数据为一个受治理真相源、富集Gemini 自动生成描述、业务术语表、关系和已验证黄金SQL 模式、搜索/检索语义搜索加 Context Retrieval API 和lookupContext等 MCP 工具。Looker/LookML 提供指标语义Gemini Enterprise 中的 Deep Research Agent 消费它。Microsoft / Azure — Power BI 语义模型 Fabric IQ Purview微软的优势在于数百万企业已在用 Power BI 语义模型而它把这些变成了 Fabric IQ 下 AI 的锚定层——配上本体和 Purview 治理让 Fabric Data Agents 用纯英语回答问题同时尊重每个用户的权限。AWS — AWS Context SageMaker Catalog BedrockAWS Context自动将你的数据映射为知识图谱通过 Agent 搜索 API 和 MCP 工具在运行时向 Agent 提供受治理的关系、业务规则和领域知识。每个查询都具备身份感知继承 IAM 和 Lake Formation 权限且可审计元数据以开放 Apache Iceberg 格式发布在 S3 上。它由 Glue Data Catalog 技能资产关联路径、查询模式、使用规则——即Agent 指引层、S3 Annotations 和 SageMaker Catalog基于 DataZone语义搜索、GenAI 生成元数据、数据产品、血缘、Amazon Q供给。Bedrock AgentCore 运行 Agent含记忆、网关和身份。如果你已运行 S3/Glue/Lake Formation卖点是零数据移动。Databricks — Unity Catalog Semantics Genie OntologyUnity Catalog 是数据、AI 资产、Agent 和 MCP 的统一治理平面。其上是Unity Catalog Business Semantics / Metric Views——用 SQL/YAML 一次性定义营收、流失率、利润率等 KPI含同义词、格式、关系受治理且开源/OSI 兼容可从 SQL、API、BI 和 Agent通过 MCP查询。为 Agent 供血的是Genie Ontology一个自改进的上下文引擎通过ontorank排名权威定义。Genie OneAgent 同事和 Agent Bricks 消费它。Snowflake — Cortex Analyst Semantic Views仓库原生、严格治理。Semantic Views 是 schema 级对象编码逻辑表、维度、事实、指标、关系、同义词、已验证查询和自定义指令——具备完整 RBAC 和共享能力。Cortex Analyst 是 LLM 驱动的 Text-to-SQL 引擎读取语义视图并生成在你的仓库中运行的受治理 SQLCortex Agents 将它与 Cortex Search用于非结构化数据协同编排。Snowflake 较新的 Horizon Context / Cortex Sense 将此扩展为跨系统上下文方案。因为语义视图受限于仓库当含义跨越 Snowflake 边界时需配合跨系统上下文层使用。OpenAI — 消费层的大脑值得对架构师说清楚OpenAI 是模型提供商不是语义层厂商。ChatGPT Enterprise 提供连接器和工具OpenAI 也采用了 MCP——所以 GPT Agent 消费的是你构建的受治理语义层在上面某个平台上而非自己提供。像 Anthropic 和 Google 一样OpenAI 游离于 OSI 标准之外。计划在你的数据平台上构建上下文层让模型通过 MCP 触达它。两个把一切串联起来的标准是OSI 和 MCP。OSIOpen Semantic Interchangev1.0 于 2026 年 1 月在 GitHub 发布基于 MetricFlow——让你用厂商中立的 YAML 定义一次指标任何兼容工具都能消费。Snowflake、Databricks、dbt、Cube、AtScale、Salesforce、Tableau、BlackRock 等 40 合作伙伴已加入明显缺席的是 Microsoft、SAP、IBM、Oracle 以及头部大模型厂商OpenAI、Anthropic、Google。MCP是将其传输给 Agent 的管道语义层仍然是企业所拥有的那一块。五、一个具体示例受治理语义模型下面是一个精简的 Snowflake 风格语义视图针对零售营收领域——回答架构图中那个确切问题。注意混乱的物理列amt_ttl_pre_dsc永远不会到达 Agentnet_revenue只被定义一次折扣和退货的逻辑被明确。将语义文件YAML存储到 Snowflake Semantic View 或 Google Catalog 等中 → Agent 通过 MCP 从那里读取。name: retail_revenue description: Governed revenue model for the retail analytics domain. tables: -name: orders base_table:{database: SALES,schema: PUBLIC,table: FCT_ORDERS } primary_key:{columns:[order_id]} dimensions: -name: region expr: region synonyms:[area,geo,territory] description: Sales region the order was booked in. -name: channel expr: sales_channel synonyms:[retail vs wholesale] time_dimensions: -name: order_date expr: order_date data_type: date facts: -name: gross_revenue expr: amt_ttl_pre_dsc # physical column no human can read description: Order revenue before discounts. -name: discount_pct expr: discount_pct access_modifier: private_access # used in math, never exposed alone metrics: -name: net_revenue description: Gross revenue after discounts and returns. THE company definition. expr: SUM(gross_revenue * (1 - discount_pct)) synonyms:[revenue,net sales,topline] -name: customers base_table:{database: SALES,schema: PUBLIC,table: DIM_CUSTOMER } primary_key:{columns:[customer_id]} relationships: -name: orders_to_customers left_table: orders right_table: customers expr: orders.customer_id customers.customer_id # Few-shot patterns the model trusts and reuses (Google calls these golden queries) verified_queries: -name: net_revenue_by_region_last_quarter question:What was net revenue by region last quarter? sql: SELECT region, SUM(amt_ttl_pre_dsc * (1 - discount_pct)) AS net_revenue FROM SALES.PUBLIC.FCT_ORDERS WHERE order_date DATE_TRUNC(quarter, DATEADD(quarter, -1, CURRENT_DATE())) AND order_date DATE_TRUNC(quarter, CURRENT_DATE()) GROUP BY region ORDER BY net_revenue DESC custom_instructions: Last quarter always means the most recently completed calendar quarter. Never aggregate gross_revenue directly; revenue always resolves to net_revenue.这个文件就是这个领域的核心同义词让topline和geo正确解析、唯一的指标真定义、关联路径模型不用猜、已验证查询高信任的 Few-shot 示例、自定义指令默认值和护栏。把它放在 Git 里像代码一样 review通过 CI/CD 发布追踪使用情况。现代语义层像产品一样被拥有和发布而不是像维基一样被维护。六、接入 Agent作为通往数据的唯一途径真正带来安全性的操作是Agent 不获得原始仓库访问权。它获得一个受治理工具通过 MCP 暴露并放入编排图。模型仍然推理它只是无法绕过心脏触及数据。# Illustrative LangGraph wiring. The agents ONLY data tool is the semantic layer. from langgraph.prebuilt import create_react_agent defquery_semantic_layer(question: str)- dict: Answer a business question against the governed semantic model. Returns rows the exact SQL lineage. Metric definitions (e.g. net_revenue) are fixed in the model — the LLM does not invent them. return cortex_analyst.ask(semantic_viewretail_revenue, questionquestion) agent create_react_agent( modelclaude-...,# the brain: reasoning planning tools[query_semantic_layer],# the heart: the single, governed door to data )七、小结问自己一个问题我们的受治理业务含义住在哪里每个 Agent 如何触达它如果答案是在提示词里或模型自己会搞清楚那就是你最高杠杆的工作。你不需要从零开始任何模型都可通过 MCP 触达。大模型会持续变得更便宜更聪明。但企业持久的优势是语义层——建好它它之上的一切都会同时变得更聪明、更安全、更便宜。【关联阅读】万字长文缺算力还是语义企业Agent的真正瓶颈《本体驱动的AI大模型》作者序让知识图谱成为大模型的伴侣面向知识图谱的大模型应用解读知识图谱的自动构建从语义网到知识图谱知识图谱与向量数据库的相遇在大模型RAG系统中应用知识图谱知识图谱的5G追溯行业规模的知识图谱——经验和挑战IOT语义互操作性之本体论IOT语义互操作性之语义IOT语义互操作性之标准与开源IOT语义互操作性之API接口IOT语义交互性之交叉老码农眼中的Agent SkillMCP过时了么你可能面对的MCP 反模式大模型应用系列两万字解读MCPMCP规范完整中译稿2025-3-26版全网首发MCP 的10种架构模式全网首发安全性问题使MCP成为AI应用的双刃剑如何化险为夷呢智能体间协作的巴别塔困境如何破解解读Agent通信4大协议MCP/ACP/A2A/ANP
