Google正式加入Apache Ossie行业组织，致力于编写一种通用格式，使AI智能体能够像人类一样准确读取和理解业务数据。据媒体报道，此举紧随微软近期加入同一项目之后，Google发言人已证实这一消息。目前，Snowflake和Nvidia也已参与其中。
这一时机并非偶然。随着企业快速部署AI智能体，这些工具能够同时查询数据仓库、CRM系统和仪表板。然而，智能体缺乏资深分析师的“机构记忆”，例如无法自动识别本季度“净收入”中应排除哪些退货项。它们仅能读取眼前的定义，若不同工具持有不同版本的定义，生成的答案虽流畅却可能完全错误。
统一语义：打破数据孤岛
这正是Ossie旨在解决的核心痛点。该项目于2025年底以“开放语义交换”（Open Semantic Interchange）之名启动，由Snowflake牵头，dbt Labs、Salesforce和贝莱德等为早期合作伙伴。2026年7月，为避免与其他“OSI”缩写冲突，项目进入Apache孵化器并更名为Apache Ossie。尽管规范未变，但治理结构已调整为隶属于Apache软件基金会，实行公开邮件列表、变更投票机制，以及基于代码贡献而非公司头衔的提交者资格制度。
目前，已有超过50家组织加入，包括Databricks、Salesforce、dbt Labs、Cube、AtScale以及越来越多的目录和BI供应商。Google BigQuery此前已出现在部分参与者名单中，此次加入标志着更全面的企业合作承诺。
在传统场景中，市场部的“活跃客户数”常与财务部不一致，销售部门统计预订单而数据仓库统计发票。人类依靠经验弥补这种定义漂移，但智能体做不到。Ossie提供了一套用于指标、维度、数据集及其关系的YAML和JSON规范。只需定义一次“总收入”及其适用的连接和过滤条件，所有兼容的BI工具、笔记本和智能体都将使用相同逻辑。Apache Ossie网站明确指出：不要在每个仪表板中重新定义收入。
Looker通过LookML、Power BI通过语义模型、Snowflake和Databricks通过各自的视图，均在内部实现了类似概念。关键在于可移植性：定义通常局限于诞生之地，迁移意味着重建。微软曾一度捍卫这一壁垒，阻止Databricks将其语义层接入Power BI，理由是可靠性问题。但随后微软改变立场，工程师开发了用于Power BI和Fabric的双向转换器，并于9月16日合并到Ossie仓库中。这一转变被业内人士视为“AI数据战争”中的彻底反转。
微软Azure数据首席技术官Amir Netz将Fabric IQ上下文层描述为“几乎像是给智能体的虚拟现实”，这与Ossie的目标一致：智能体需要内置公司的独特逻辑，而非原始表数据的堆砌。微软仍希望Fabric处于中心地位，其开放定义的策略表明，托管真相比拥有每一份副本更重要。
Google则带着不同的遗产入场。Looker的建模语言在定义与仪表板之间建立了紧密循环，BigQuery支撑着大部分企业分析，Gemini正被集成到Workspace和Cloud中。理论上，能读取共享Ossie模型的智能体可以向Looker、BigQuery和第三方数据仓库提出相同问题并获得兼容答案。但这尚未完全建成。
目前，针对dbt MetricFlow、Salesforce、GoodData和Apache Polaris的参考转换器已存在。微软的Power BI路径已映射表和关系，但正如Prologika审查后指出，完整的DAX生成仍需额外的微软特定提示。互操作性尚不完整，原生导入和导出在发货产品中仍然罕见。
从连接到理解：智能体的下一步
Anthropic广泛采用的模型上下文协议（MCP）解决了智能体如何与工具通信的问题，而Ossie解决的是数据含义的问题。一个是插头，另一个是字典。Google在MCP方面非常积极，在云服务、Workspace、Merchant API甚至Google Home中推出了托管服务器。连接变得容易，但理解依然困难。
Dremio将Ossie定位为“拥有意义的层级”。Parquet、Arrow、Iceberg和Polaris告诉机器数据是什么，而Ossie告诉机器数据是用来做什么的。当智能体被允许行动而不仅仅是聊天时，这种区别至关重要。
压力正在上升。用于训练的高质量公共文本日益稀缺，关于抓取新闻的诉讼关乎过去的令牌。未来的智能体将取决于实时、受管且一致的数字。共享语义格式虽不能解决法律纠纷，但能让CFO确保Copilot、Cortex和Gemini都在查看相同的收入数字。
批评者指出，超大规模厂商在两头下注。微软打开了一扇它曾试图关闭的门；Google加入了一个可能削弱Looker建模优势专有性的组织；Snowflake召集了最初的努力，但仍出售不离开其环境的语义视图。参与不等于提供原生支持。
但替代方案更糟：在每个BI工具和智能体堆栈之间进行自定义的N对N映射，会导致指标漂移不断累积。幻觉与其说是模型故障，不如说是定义故障。将指标锁定在单一供应商格式内的公司将目睹智能体在生产环境中失败，而发布单一事实来源的公司将让智能体表现得如同属于那里一样。
Google的加入并未完成规范，但使得任何平台都难以置身事外。Snowflake、Databricks、微软和现在的Google都在桌边，Salesforce也是如此。转换器会变得更好，或者不会。关于指标语言、目录和本体论的工作组要么产生引擎实际可查询的内容，要么格式保持为表和连接的最低公分母转储。目前，墙壁正在倒塌，虽未完全消失，但足以让下一代智能体最终知道企业实际使用的是哪个版本的数字。