当 AI Agent 直接对着数据仓库写 SQL，最大的风险不是语法错误，而是它"写对了但理解错了"——把营收算成 GMV、把活跃用户定义成登录用户。NVIDIA 的 Auto Ontology 试图在 Agent 和数据库之间插一层可审计的语义护栏。
发生了什么
NVIDIA 发布了 Auto Ontology，一个以 Apache 2.0 许可开源的库。它的核心能力是从企业已有的元数据中生成语义层（semantic layer），把指标、维度、表关系等业务定义结构化下来，再让 AI Agent 生成的 SQL 锚定在这些"受认证的定义"之上，而不是靠模型对表名字段的自由猜测。
在交付形态上，Auto Ontology 不只提供一个 Python 库：它通过 MCP（Model Context Protocol）向 Agent 暴露上下文，同时提供 CLI 和 API 两种接入方式。这意味着它既可以嵌进现有的 Agent 框架，也能被命令行工具或自建服务调用。
为什么重要
Text-to-SQL 这几年反复卡在同一个地方：模型能写出跑得通的查询，却难以保证业务口径一致。企业数据团队真正在维护的资产，往往不是表结构本身，而是"什么算新客""退款怎么扣"这类散落在文档、BI 报表和口口相传里的定义。语义层（如 dbt Semantic Layer、Cube 等）正是为收敛这些定义而生，但长期以来它是给人用的，Agent 拿不到。
Auto Ontology 的切入点在于"自动生成"和"Agent 原生"。传统语义层需要人工建模，成本高、更新慢；从元数据自动推导则试图降低这层基础设施的搭建门槛。而 MCP 的支持尤其关键——它把语义层变成 Agent 可直接检索的上下文源，而不是又一个需要专门适配的孤岛系统。NVIDIA 以 Apache 2.0 开源，也降低了厂商锁定的顾虑。
影响与看点
对数据平台团队而言，这类工具的价值取决于元数据质量：如果企业连字段注释和指标定义都不完整，自动生成的语义层很可能只是把混乱结构化了一遍。因此实际落地时，它更像是"元数据治理的放大器"，而非替代品。
对 Agent 开发者来说，MCP + CLI + API 的三重接口意味着可以按场景选择集成深度：轻量场景直接让 Agent 通过 MCP 拉取上下文，重场景则走 API 做校验和拦截。值得关注的是它如何与现有 BI 语义层共存——是替代、补充，还是仅作为 Agent 侧的只读视图。
一个独立判断：语义层正在从"人看报表的中间件"变成"Agent 调数据的准入层"，谁掌握了受认证的定义，谁就掌握了 Agent 分析结果的可信度。NVIDIA 此举未必是要做数据治理生意，更像是为 Agent 生态补齐一块它自己也需要的地基。
