Auto Ontology（NVIDIA/auto-ontology）：把业务口径编译成智能体能查的语义本体，让 text-to-SQL 先问「能不能答」

一、导读

一个智能体可以检索文档、也能查数据库，但真正卡住企业级分析的从来不是速度，而是可靠性——一个「营收」指标答得再快，只要数字是错的就一文不值。NVIDIA 在 2026 年 10 月 21 日的 GTC Berlin 上把 Auto Ontology 作为 Agent Knowledge Foundation 的核心开源库推出：它从企业元数据构建一层语义本体，把「客户」「订单」「营收」这些业务概念映射到真实数据列与可复用的 SQL 表达式，再通过 MCP、CLI 与 REST 暴露给任意智能体框架。本文拆解它的三段式编译流水线、LangGraph 查询图、七个重建上限与「宁可不答」的可解性判定，并给出四类可复现场景。

二、项目速览

项目	信息
仓库	NVIDIA/auto-ontology
作者	NVIDIA Corporation
主语言	Python（前端 TypeScript / Next.js 16）
Star 总数	8,896（2026-11-06 抓取）
当日涨星	2,005（GitHub Trending daily 第三名）
License	Apache-2.0
首次发布	2026-04-27
定位	面向智能体的语义层 / 本体库，text-to-SQL + MCP + REST

三、为什么是它：问题背景与定位

它的 README 第一段没有讲自己多好，而是讲了一件事有多没用：「Agents can retrieve documents and query databases, but reliability gates agentic analytics: a revenue metric answered faster is worth nothing if the number is wrong.」这句话几乎是 2026 年企业级智能体的一记耳光——过去两年所有人都在比谁跑得快、工具调用更花哨，而真正让企业不敢把报表交给智能体的原因，是那句没人敢问出口的话：你这个「营收」，和我财务系统里的「营收」，是同一个东西吗？

Auto Ontology 要回答六个问题：数据在哪、它是什么意思、该不该用它、怎么用它、它从哪来、和什么相似。这六个问题恰好覆盖了智能体在企业数据上翻车的全部方式——不知道数据在哪就猜表名；不知道什么意思就把「客户数」和「活跃客户数」混用；不知道能不能用就把三年前的快照当今天口径；不知道怎么用就写出语法正确但逻辑荒谬的 SQL；不知道从哪来，数字就没法审计；不知道和什么相似，每次都要从零开始找。人在公司里靠什么解决这六件事？靠一个干了八年的数据工程师、一份没人读完的数据字典、和开会时有人喊一句「等等，这个指标是财务口径还是业务口径」。Auto Ontology 的野心，是把这套口口相传的默契变成一份能被机器读、能被校验、能被继承的东西。

涨星动因有三层。一是时机：NVIDIA 在 GTC Berlin 把 Auto Ontology 放进 Agent Knowledge Foundation，与 Nemotron Retriever、Kumo 系列模型、CUDA-X 库、OpenShell 安全运行时打包发布，Palantir、Databricks、Snowflake、AWS、IBM、Oracle 等一长串企业被列为采用方。二是收购整合：NVIDIA 在 2026 年 2 月以约 7,500 万美元收购以色列初创公司 Illumex（专注自动化构建企业数据语义层与本体），又在 6 月以据报超过 4 亿美元收购 Kumo（为关系型数据构建基础模型），Auto Ontology 正是这两笔收购在工程上的合流。三是叙事转向：在「RAG 够不够用」的行业争论里，NVIDIA 明确站到「知识图谱比基于相似度的文本片段检索更能准确表达概念及其关系」这一边。

值得注意的是它的自我定位——「It complements the semantic models customers already own.」企业里的语义层通常已经存在：dbt 的模型、LookML、某个 BI 工具里的指标定义。新工具若要求你先把这些扔掉，第一天就通不过。因此它选择做增量，并主动兼容 Apache Ossie（语义模型交换的开放标准），通过 Ossie YAML 导入导出模型定义。

四、【重点】架构原理

4.1 整体架构：五个进程，五个端口

Auto Ontology 是一组容器化服务，职责边界划得很干脆：

   智能体客户端 (MCP/REST)
        │
        ▼
  Frontend (Next.js 16) :3000 公开   ← Web UI · Better Auth · /api 网关
        │ x-auto-ontology-user-id
        ├──────────────► MCP Server (FastMCP) :3003 公开（只读工具）
        ▼
  Backend (FastAPI + LangChain) :3001 仅内网  ← text-to-SQL 查询图
        ▼
  Ingestion (FastAPI) :3002 仅内网，无自身鉴权  ← 抽取 + 编译语义层
        ▼
  Postgres 17 + pgvector :5432 仅内网  ← 目录 · 本体 · 应用数据 · 向量

组件	技术	职责	端口
Frontend	Next.js 16、Better Auth、Prisma	Web UI、认证、公开 API 网关	3000
Backend	FastAPI（Python 3.12+）、LangChain	text-to-SQL 智能体、目录与本体 API	3001
Ingestion	FastAPI	数据抽取与语义层编译	3002
MCP Server	FastMCP	基于公开 API 的只读智能体工具	3003
Postgres + pgvector	PostgreSQL 17	目录、本体、应用数据、向量库	5432

这套端口设计里藏着一条关键信任边界：Backend 信任由 Frontend 转发的 x-auto-ontology-user-id 头，而 Ingestion 的接口（ingest、delete、reset、compile）自身没有任何鉴权。因此官方要求把 3001、3002 留在私有网络，只暴露 3000（Web/API 网关）与 3003（MCP）。安全模型是「网关集中鉴权 + 内网信任」——配错就等于把无鉴权的数据编译接口挂到公网。

4.2 三段式生命周期：生成 → 认证 → 回答

本体承载三类定义：术语（Terms），如 Customer 或 Invoice Line，带描述与同义词并映射到列；SQL 属性（SQL attributes），挂在术语下、经审核的 SQL 表达式（如毛利率、滚动合计），智能体复用它们以保证同一度量每次算法一致；关系（Relationships），表如何连接，包括桥表，从键和数据推断。

生成由 ingestion 服务从源库构建初稿，分四步：读源（抽取 schema、profile 列、采样值入目录）→ 命名实体（逐表抽术语并映射到列）→ 解析关系（推断 join 与桥表、从查询历史建议 SQL 属性）→ 写入本体（存 Postgres，向量入 pgvector）。官方示例中一次 Wide World Importers 编译产出 31 个术语。

认证是最容易被低估的一环：人在 Chat 里用真实问题测试，或通过 MCP 的 check_answerable 与 ask_question 测试；在 UI/API 里精修术语、描述与 SQL 属性；确认无误后认证。这里的「认证」是硬约束——只有人签过字的修正才被信任。README 一句话点破设计哲学：「一个会遗忘的系统不可怕，一个会乱学的系统才可怕。」

回答是五步流水线：分类意图并抽取实体 → 嵌入检索召回候选术语/列/SQL 属性 → 从候选写 SQL → 校验过滤值与查询（对照数据库），失败则修复 → 执行并返回答案、SQL 与所经历的步骤。候选无法支撑查询时，智能体明确报告「此问题无法从这份数据回答」，而不是硬编一个 SQL。

4.3 编译流水线：从元数据到语义图

入口是 run_semantic_compilation()，先施加全局并发闸门 SEMANTIC_LLM_MAX_INFLIGHT（默认 6）。这个数字有讲究——编译按表并行、每张表内部又扇出，请求速率是乘积而非求和，容易超过端点上限，历史上曾表现为 HTTP 503 ResourceExhausted。把限流放在编译期间而非共享 invoke 调用点，是为了不误伤已经自己限流的调用方。

四个阶段依次是：术语编译 → 语义外键解析 → SQL 属性建议 → 桥表处理。代码注释很能说明工程判断：「下面三个阶段是长尾——光 FK 解析在一个数据库上就跑过 300 秒——而且它们都不是刚写入的术语可用的前提。一次被取消的编译会直接跳到总结，而不是花几分钟做没人等的工作。」这是典型的「先交付可用部分，再做长尾增强」。

语义外键解析（semantic_fk.py） 是本体质量的关键。它先找出所有「既没有 SEMANTIC_FK 边、也没有 HAS_ATTRIBUTE 边」的列（被术语提取跳过的外键列），再对每列走两条路：声明外键快车道——若已有 FOREIGN_KEY 边，直接找到目标列上的 ColumnAttribute 建立 SEMANTIC_FK，并拒绝指向同表自身列的自引用；LLM/VDB 回退——无声明外键时，把列上下文向量化，在语义库搜 top-5 最相似的 ColumnAttribute 让 LLM 挑一个；LLM 弃权时回落到「去活库探查样本值是否匹配」。这种「确定性优先、LLM 兜底、探查收尾」的三级策略，是它比纯 LLM 推断更可靠的原因。

桥表处理（bridge_tables.py） 针对「所有列都是外键」的纯连接表：不新建术语，而用 LLM 生成结构性 JOIN 的 SQL 表达式，再用 rerank 在两侧术语里挑更匹配的一个挂上去，让多跳关系在检索时表现为可复用的 SQL 片段。这就是它能在没有显式 join 路径时，依然拼出「invoice line → invoice → customer → city → state province」五跳链路的原因。

4.4 查询图：LangGraph 上的确定性状态机

回答阶段不是一次 LLM 调用，而是一张 LangGraph 状态图，节点包括 QuestionIntentAgent（意图分类）、QuestionExtractionAgent（实体抽取）、CandidateRetrievalAgent（候选召回）、CandidatePreparationAgent（候选准备）、SQLFromCandidatesAgent（生成 SQL）、SQLValidationAgent（解析/静态/意图校验）、SQLReconstructionAgent（重建）、SQLValueValidationAgent（值校验）、SQLExecutionAgent（执行）、ResponseAgent（响应），以及若干软检查节点（join_path_check、jsonb_path_check、proactive_value_check、empty_like_result_check、empty_result_value_repair）。

七个重建上限是这张图最重要的护栏。MAX_RECONSTRUCTION_ATTEMPTS = 7：SQL 重建最多七次，超过就路由到 unconstructable，明确告诉用户「当前数据无法构造查询」。代码注释解释了为什么这条路径要单独处理：「它被直接传递而不是折进下面的 else 分支，那个分支假设凡是不是 invalid_sql 的都是可用 SQL，会把一个已经放弃的运行继续送往执行。」这个「宁可不答」的设计，是它与多数 text-to-SQL demo 的分水岭——demo 的目标是「总能给你一个 SQL」，而生产系统的目标是「绝不给错的 SQL」。

图上还有一类软检查路由（_make_soft_check_router）：jsonb 路径、join 路径、值预检、空 LIKE、值修复。这些检查失败会把 SQL 送回 reconstruct_sql，但不经过强制重建上限的路由。代码注释点明风险：「一个持续失败的检查可能会一直循环，直到图的全局递归限制中止整个运行。」因此设了第二道闸门——累计失败次数超过 INTENT_VALIDATION_SKIPPED_AFTER 就停止阻塞，让 SQL 原样通过。这是「硬上限 + 软旁路」的双层防死循环设计。

进度事件走自定义流通道（announce_node_start）是个实用细节。app.stream() 只在节点结束后才 yield 更新，若只靠更新驱动 UI，一次 20 秒的重建会一直显示上一个节点标签（比如卡在「Validating intent」）。因此代码在节点真正开始时通过 LangGraph 自定义流通道写一条 step_start 事件。注释标注「best-effort」：没有流式上下文时没有 writer，缺失的进度事件不能把整个运行拖垮。

4.5 模型角色与关键设计取舍

LLM 用量拆成四个角色，每个由一组三元组环境变量配置（<PREFIX>_ENDPOINT/_API_KEY/_MODEL），未设置字段回落到 DEFAULT_MODELS_*：

角色	默认模型	做什么
`REASONING`	`nvidia/nemotron-3.5-lightning-30b-a3b`	构建本体、写答案的 SQL 与解释、给可解性打分
`NON_REASONING`	`nvidia/nemotron-3.5-lightning-30b-a3b`	快步骤：意图、实体抽取、候选选择、SQL 检查与修复
`EMBED`	`nvidia/nemotron-3.5-embed-1b`	索引表/列/术语/SQL 属性，匹配问题到它们
`RERANK`	`nvidia/nemotron-3.5-rerank-8b`	编译桥表 SQL 属性时对候选表排序

几个取舍值得展开。其一，本体不放在图数据库里：语义目录、术语、关系、SQL 属性与向量全部存在与被描述的那份 catalog 同一个 Postgres 里，运维面收敛但图查询靠 SQL 递归、规模受单库限制——用工程简单性换理论最优性，对几千张表的企业元数据完全够用。其二，MCP 服务不持有任何凭据：它是纯 HTTP 客户端，请求转给网关，认证与权限判定都在网关层，消除了「给智能体一个万能数据库账号」这一最常见的安全反模式。其三，嵌入模型必须在摄取与查询两侧一致：一旦不一致，检索会静默返回错误候选，这类 bug 极难排查。其四，预测分支在启动时决定是否建图：_prediction_enabled() 只在图创建时评估一次，KUMO_RFM_API_URL 未设置时预测节点与边根本不会被加入——用启动期静态裁剪替代运行期动态判断，代价是改配置要重启，收益是运行时无分支开销。其五，预测意味着数据出域：KumoRFM 是托管服务，要回答预测问题需把连接的表上传给它，受 KUMO_MAX_TABLES（默认 20）与 KUMO_MAX_ROWS_PER_TABLE（默认不限）约束，README 用加粗提醒先完成组织的数据审查。

4.6 与其他架构路线的差异

它代表「先建本体，再生成 SQL」这条路线。纯 text-to-SQL（schema 直喂 LLM）零准备工作，但表一多就爆上下文，且每个度量每次可能算出不同口径、无法审计——Auto Ontology 用「术语 + 已认证 SQL 属性」把口径固化下来，正是冲着这个缺陷去的。纯 RAG 靠相似度拉文本片段；NVIDIA 智能体 AI 产品副总裁 Adel El Hallak 在采访中直言「RAG 很棒，但它够用吗？」，他认为知识图谱更能准确表达概念及其关系——「当你在看一个移动运营商的套餐时，『层级』和『计划』其实是同一个意思，但 LLM 经常把这些搞混。」商业语义层（dbt/LookML/BI 工具）口径治理成熟，但面向人而非智能体，通常不提供 MCP/API。Auto Ontology 的差异化在于「智能体优先」：从第一天就把 MCP、CLI、REST 作为一等公民，并主动兼容 Ossie 以承接已有语义模型。

五、【重点】应用场景

场景一：让 Cursor / Claude 安全地查公司数据（MCP 接入）

痛点：直接给智能体一个数据库连接，等于给它一个万能账号——能读薪资表、能执行 DELETE，且没人知道它查了什么。解法：MCP Server 提供一组只读工具，且每个调用都以登录用户自己的权限运行。工具分四组：就绪检查（check_readiness）、术语（search_terms、get_term、get_term_columns、get_term_sql_attributes、get_sql_attribute、describe_table）、可解性（check_answerable）、提问（ask_question，返回答案、SQL 与数据行）。集成：启动 MCP Server 后在 Cursor 的 ~/.cursor/mcp.json 登记 {"mcpServers":{"auto-ontology":{"url":"http://localhost:3003/mcp"}}}，Claude Desktop 用 mcp-remote 桥接，重启客户端后按提示登录。收益：权限等价性——「会话能做的事，正好等于它背后那个人能做的事」，无需为智能体单独发凭据；可解性工具能在生成 SQL 之前判断数据能否回答该问题（README 示例返回 coverage 0.5 并指出「no term covers 'ad spend'」），把「编一个 SQL」变成「告诉你答不了」。边界：只读，不适合批量 ETL 或写操作；未完成术语认证前不建议直接接入面向业务用户的产品。

场景二：自然语言分析多源数据（跨 10 种引擎）

痛点：数据分散在 Postgres、Snowflake、Databricks、MySQL、ClickHouse、Trino 等引擎，业务人员问一个问题往往得先知道数据在哪、找对应的人、等 SQL 排期。解法：内置十个连接器（PostgreSQL、MySQL、Databricks、Snowflake、ClickHouse、Trino、Apache Kyuubi、HeavyDB、DuckDB、SQLite），在 Settings → Connections 添加或通过 CONNECTION_STRINGS 列出（DuckDB/SQLite 仅连接串），凭据可选存 HashiCorp Vault。集成：用 REST API 提问，响应是 SSE 流：

curl -N http://localhost:3000/api/chat/completions \
  -H "x-api-key: $AUTO_ONTOLOGY_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"question": "How many orders shipped last week?"}'

result 事件带答案与 SQL，data: [DONE] 结束；API token 在用户菜单 → API Tokens 生成。收益：每个答案都附带 SQL 与所经历的步骤，可拿去跟源系统对账。官方示例中「What was revenue for the USB food flash drive - sushi roll in Pennsylvania in June 2015?」返回 $588.80, from 3 invoice lines，并附一条五表 JOIN 的 SQL 与「Resolved terms / Joined / Validated the filter values」的步骤说明。边界：它不做跨库联邦查询，只把不同源的本体统一到一套术语下；需要真正的跨库 join 应先把数据落到同一引擎。

场景三：把业务术语表变成可执行的共享资产

痛点：「活跃客户」在销售、财务、产品三个团队里有三种定义，每次开会都要重新对齐，且没人说得清当前报表用的是哪个口径。解法：用「术语 + 同义词 + 映射列 + 已认证 SQL 属性」把定义写成机器可读、可校验的资产。集成：编译完成后在 UI 里查看语义图（官方示例一次编译产出 31 个术语，选中 Order 能看到描述、相关术语、映射列与 SQL 属性）；在 Chat 或 MCP 里用真实问题测试；确认后在 UI/API 里认证；模型定义可通过 Settings → Import / Export 或 POST /api/model/import、/api/model/export 以 Ossie YAML 交换。收益：口径「一次定义、处处复用」——智能体复用已认证 SQL 属性而非每次重新推导，同一度量在不同问题里会算出相同结果；认证过的修正会被折回本体（第五个动词「Learn」）。边界：认证是人工的，术语多时需投入治理人力；schema 变更后需重新编译并人工复核认证状态。

场景四：用脚本和定时任务做「可编程问答」

痛点：数据团队想把「问数据」嵌进自动化流程（每日经营简报、异常巡检），但不想为每个问题写死一条 SQL。解法：通过 POST /api/chat/completions 配合 API token 让脚本与定时任务以自然语言提问。集成：见场景二的 curl/Python 示例；timeout 设足够大（示例 900 秒），因为首次问答在官方实测中约需 3 分钟；CI 回归可先用 check_answerable 判断问题是否落在本体覆盖范围内，避免把「数据不支持」误判为「系统故障」。收益：把问答从「人机对话」扩展到「机机调用」，且每次调用仍以具体用户权限运行，审计链路不断。边界：不建议放进对延迟敏感的同步接口；未评估数据出域前不建议启用预测能力。

六、快速上手

官方 Quickstart 用 Docker Compose 跑 Wide World Importers（微软示例销售库），前置条件是 Docker + Compose v2、uv、以及 build.nvidia.com 的 NVIDIA API key（nvapi-...）。核心步骤：克隆仓库并配置 .env（至少设 DEFAULT_MODELS_API_KEY、AUTH_SECRET、APP_URL 与三个密码）→ 起 Postgres 并灌入示例库 → docker compose up -d --build 构建并启动其余服务。打开 http://localhost:3000 登录后，进入 Settings → Semantic Compilation 打开编译开关，完成后显示 Semantic compilation is ready，随后在 Chat 里提问即可。

实测时延提示（待确认，来自第三方部署记录）：据 Railway 社区部署模板记录，首次启动时 Ingestion 摄取 Chinook 示例库、编译语义层约需 7 分钟，首次问答约需 3 分钟。这些数字来自第三方模板的实测描述，未经官方基准验证，仅作参考。若 UI 重启后左侧导航消失，是浏览器持有了过期会话 cookie，清除 localhost:3000 站点数据后重新登录即可。

七、横向对比

维度	Auto Ontology	纯 text-to-SQL	纯 RAG	商业语义层（dbt/LookML）
核心机制	本体（术语+SQL属性+关系）+ 嵌入检索 + LangGraph 状态机	LLM 直读 schema 写 SQL	向量相似度召回文本片段	人工维护的指标/模型定义
口径一致性	高（复用已认证 SQL 属性）	低（每次重新推导）	不适用	高
可审计性	高（返回 SQL + 步骤 + 出处）	中（有 SQL 无出处）	低	高（但面向人）
智能体接入	一等公民（MCP/CLI/REST）	需自行封装	需自行封装	通常无 MCP
数据源覆盖	10 种引擎	取决于实现	文档为主	以数仓为主
预测能力	可选（KumoRFM，需数据出域）	无	无	部分 BI 工具有
许可	Apache-2.0	视实现	视实现	多为商业许可
主要成本	LLM 调用 + 人工认证	LLM 调用	嵌入 + 存储	治理人力

需说明：「纯 text-to-SQL」与「纯 RAG」两列描述的是架构路线而非具体产品，实际产品往往是混合体；对比是为凸显 Auto Ontology 在「口径固化」与「可审计」两点上的取向差异。

八、局限、风险与社区观察

维护模式：不接受外部贡献。 README 明确写着「This project is currently not accepting external contributions.」以及团队不接收外部 PR。集成请求与 bug 报告以 issue 形式提交，安全漏洞走 SECURITY.md。这意味着它是厂商主导项目，社区无法直接改进代码——对依赖它的团队是需要评估的长期风险。

部署与安全边界。 如 4.1 所述，Backend（3001）与 Ingestion（3002）必须留在私有网络：Backend 信任前端转发的用户 ID 头，Ingestion 接口自身无鉴权。「配错就出事」，Helm chart 与 Docker Compose 都需仔细检查网络策略。

预测功能的数据外发。 启用 KumoRFM 意味着连接的表会被上传到托管服务，受 KUMO_MAX_TABLES（默认 20）与 KUMO_MAX_ROWS_PER_TABLE（默认不限）约束，README 要求先完成组织的数据审查——使用前必须明确告知合规团队。

外部依赖。 默认推理依赖 NVIDIA NIM（托管或自托管），需要 nvapi- key；虽支持任意 OpenAI 兼容端点，但 README 建议用支持结构化输出的模型。系统会自动检索外部材料，免责声明指出这些材料不随软件分发，使用者需自行确认其条款与安全。

生产可用性观察。 项目首发于 2026-04-27，到 2026-11-06 约半年、8,896 星，处于快速成长期。它提供 Helm chart、OpenAPI 规范、三类官方技能（setup/management/query）与较完整文档，工程完整度高于多数同期项目；但「不接受外部贡献」+「依赖专有模型服务」两点，决定了它更适合作为参考架构与内部工具，而非可完全自主掌控的基础设施。

待确认项。 官方 README 未给出 text-to-SQL 的公开基准数字，而是指向独立的 NVIDIA/auto-ontology-eval 仓库跑 BIRD 基准（该仓库 2026-11-06 抓取时 91 星）；本文未获取该仓库实测结果，故不引用具体准确率。NVIDIA 官方披露的「本体创建时间缩短 90%」为厂商自测数据，未公开测试规模与评价方法。官方也未公布 Wide World Importers 之外的编译耗时基准。

九、小结与行动建议

Auto Ontology 的价值不在于「让智能体写 SQL」——这件事 2024 年就有人做了——而在于它把「口径治理」从人肉流程变成可编译、可认证、可审计、可继承的工程资产。最值得借鉴的三个设计是：七个重建上限的「宁可不答」、软检查的双层防死循环、认证环节把「学习」限定在人签过字的修正上。行动建议：

想快速评估的技术负责人：用 Docker Compose + Wide World Importers 跑通 Quickstart（约 15 分钟，首次编译约 7 分钟），重点观察两个行为——正确答案是否附带 SQL 与步骤、答不了的问题是否被明确拒绝。
正在做企业级智能体的团队：把「术语 + 已认证 SQL 属性 + 关系」这套三层本体抽象抄进自己的设计，即使底层不用 Auto Ontology；它解决的是「同一指标在不同问题里算法不一致」这个最隐蔽也最致命的缺陷。
关注安全边界的架构师：研究它的网关信任模型（MCP 不持凭据、以用户身份运行）与端口划分（无鉴权服务强制内网），这两点可直接复用到任何智能体数据接入层。
评估生产落地的团队：先确认三件事——能否接受「不接受外部贡献」的维护模式、能否接受默认依赖 NVIDIA NIM、以及预测功能的数据出域是否通过合规审查。
对本体/知识图谱路线感兴趣的研究者：关注它与 Apache Ossie 的互操作，以及 ontology-sql-eval 后续是否公布 BIRD 基准结果——那将是判断「本体路线是否真的比纯 text-to-SQL 更准」的关键证据。

资料来源（数据获取日期 2026-11-06）：项目 README 与源码（github.com/NVIDIA/auto-ontology，Apache-2.0）、NVIDIA 官方博客《NVIDIA Agent Toolkit Expands, Grounding Enterprise Agents in Company Data》（2026-10-21）、MarkTechPost 与 7wData 对 Auto Ontology 的报道、Globes/Fortune 对 Illumex 与 Kumo 收购的报道、GitHub Trending daily 榜（2026-11-06 抓取）。