一页摘要
三个判断。① Snowflake 没有"做一个本体"，它把本体拆成四个各自可售卖、各自成熟的层，而且每一层的产物都是仓里的对象（目录条目、语义视图、KG 节点边表、上下文基底），由同一套 RBAC 治理——这是"数据平台公司做本体"的范式 B。② OntoOS 走的本来就是范式 B（本体存在湖仓、SQL 主线、图在仓里），而且在"抽取"这一步比 Snowflake 深一个量级：它不只盘点表，还从容器镜像反解出端点 / ORM / MQ / 调用线索 / 配置真值这些行为语义边——这是研发本体独有的护城河。③ 但 OntoOS 的本体知识今天住在三个地方——技能仓 Markdown（952 KB）、控制台的 Python 注册表（43 实体 / 79 关系）、36 个派生视图——没有一处是湖仓里可被 Agent 一次性读取的"全局本体"，这正是 Snowflake 用 Semantic Views + KG + Cortex Sense 三层补上的东西。
五项决策（建议）
- 本体入仓：把注册表（实体 / 关系 / 同义词 / 度量）导出为版本化的
ontology.yaml契约包，并物化为dws.kg_node/dws.kg_edge两张表（随每日发布生成，不是视图）。 - 语义层成为一等公民：在"关系 + 命中率"之外补齐 Semantic View 的另外两件事——受控词汇（同义词 / 中文名词 / 拼音）与度量（measure），先接到
search与命名查询。 - 给 Agent 一份全局本体基底：生成 ≤32 KB 的 Ontology Manifest 作为 MCP
instructions/ Resource 下发；用 ops-agent-bench（85 题）做"有 / 无 manifest"对照，复刻 Cortex Sense 的 47→83 实验但可复现。 - 图在仓里、事实表不进图：2,800 万调用边、3,268 万方法节点留在事实表与物化线索；KG 只装"实体 ↔ 实体"的本体级边（量级百万以内，递归 CTE 跑得动——与 Snowflake 的判断一致）。
- 不做 Action 层，做它的只读半身：坚持只读与交接边界，但把"改表 / 改接口 / 改配置"的变更意图建模为可预检的操作类型（impact precheck），输出到发布流程与 Apollo。
三阶段节奏
A · 本体入仓（2026-10 → 12）：契约包 + kg_node / kg_edge + neighborhood 命名查询 + Manifest v0 + bench 对照 + 发布区明文凭据收口（P0 前置）。
B · 语义层一等公民（2027-01 → 06）：度量与同义词进 spec、推荐边（自动候选 + 人审）、控制台"本体页"（Studio 的穷人版）、发布区 Parquet / Iceberg 导出、研发本体 ↔ 业务湖仓的库表桥。
C · 从研发本体到企业上下文基底（2027-07 → 12）：1 条产品线的业务本体试点（发票 / 税号 / 客户 ↔ 表 ↔ 服务 ↔ 页面）、变更意图预检协议、跨引擎消费、评测常态化。
节奏与《OntoOS 查询服务架构设计 v2.0》（2026-09-20）的 P0–P3 并行：v2.0 解决"执行与事实上收服务端"，本文解决"本体本身成为一等对象"。两者不冲突，共用契约包。
Snowflake 的四层堆法：自下而上，每一层都是仓里的对象
文章的核心观察是一句话：Snowflake 走的是自下而上的路——先有目录（Catalog），再有语义层（Semantic），再有图（Knowledge Graph），最后是给智能体的统一接口（Cortex Sense）；与 Palantir"从业务对象出发、自顶向下"正好相反。把四层按时间排开，能看到它用了两年把"仓库里有什么"一步步推到"智能体知道仓库里有什么"。
L1 Horizon Catalog —— Polaris 之上的 AI 目录
2025-11-04 GA。三个组件：Collect（结构化 + 非结构化资产统一收集，带上下文）、Maintain（数据质量 + 自动化运维监控）、Extend（跨引擎读写——底层是 Apache Polaris / Iceberg REST，Spark / Trino / Dremio / Databricks 能直接读）。治理栈是 RBAC + FGAC + ABAC。
关键不是"又有一个 catalog"，而是把治理边界从 Snowflake 内部扩到跨引擎：Polaris 由 Dremio 与 Snowflake 共创、2024-08 捐赠、2026-02-18 升为 Apache 顶级项目（约 100 位贡献者、2,800+ PR、6 个版本，PMC 含 Google / Microsoft / Confluent / LanceDB）。这是对 Databricks Unity Catalog 的"开放标准之战"。
L2 Semantic Views + Semantic Studio —— 在 SQL 上盖一层受控词汇
Semantic View 是 schema 级的保存对象：定义哪些表构成一个业务实体、实体间的关系、哪些维度可分析、哪些度量可聚合，带同义词。DDL 2025-06 GA，派生度量 2025-09-30 GA，标准 SQL 查询 2026-03-02 GA，Autopilot（自动建议语义视图）2026-03 GA。
Semantic Studio 是编辑工具：选表 → 自动建议实体 / 维度 / 度量 / 关系 → 命名 + 同义词 → 提交 git 评审 → publish。2026-08-26 公开预览。它是 Cortex Analyst（NL→SQL，文章引述内部 benchmark 85–90%）、CoWork、CoCo、Cortex Sense 四个下游的共同输入。
L3 Knowledge Graph —— 节点边存进 warehouse，递归 CTE 遍历
2026-05-25 工程博客公开实现：图作为一组节点 / 边表存在仓内（KG_NODE、KG_EDGE、KG_NODE_PROPERTY、KG_EDGE_PROPERTY 等约 28 张元数据表），用递归 CTE 遍历；一组存储过程提供 CRUD；GraphRAG 接口把检索结果喂给 Cortex LLM 函数；Term Mappings 对齐不同 KG 的术语。Snowflake-Labs 有开源参考实现。
取舍：不要独立图数据库——"数据不用搬、治理边界统一"，代价是亿级边的遍历性能不如专用引擎。Snowflake 的判断是 80% 的企业图场景在百万边以下，warehouse 跑得动。
L4 Cortex Sense —— 自动构建"全局本体"给智能体
2026-06-02 Summit 进私有预览。三步：Scan（扫描所有表 / 视图 / 列 / 度量定义 / 语义视图，以及查询历史、BI 看板）→ Build（自动生成全局本体：节点是实体、边是关系）→ Share（作为"context substrate"暴露给 CoWork + CoCo，按用户角色与行为实时增强）。
Snowflake 自报：启用后 CoWork / CoCo 在复杂业务问题上的准确率从 47% 提到 83%。这是内部 benchmark，非第三方审计；但即便打折，量级也说明智能体的瓶颈不是模型而是 context。Catalog 是 Sense 的输入，Sense 是 Catalog 之上的智能体接口——两者是不同抽象层。
事实核验：文章的哪些说法是一手来源、哪些是厂商自报、哪些需要更正
| 说法 | 核验结果 | 来源 |
|---|---|---|
| Horizon Catalog 2025-11-04 BUILD GA，底层 Polaris | 一手确认 Snowflake 博客明确 Horizon Catalog 的互操作层建立在 Polaris 之上 | Snowflake 工程博客《Apache Polaris: The End of Data Vendor Lock-In》 |
| Apache Polaris 2026-02-18 升顶级项目 | 一手确认 polaris.apache.org 2026-02-19 公告；≈100 贡献者、2,800+ PR | polaris.apache.org / Dremio / Snowflake 博客 |
| Semantic Views 2026-03-02 GA | 需补充 03-02 GA 的是"标准 SQL 查询语义视图"；DDL 本身 2025-06 已 GA，派生度量 2025-09-30 GA，2026-06-26 "SQL 查询作为逻辑表" GA | Snowflake 发布说明 2026-06-26；Atlan 指南 |
| Semantic Studio 2026-06-02 私有预览 | 已过时 2026-08-26 发布说明：公开预览，所有账户可用；带 CoCo 对话式编辑、YAML 直编、Git 版本控制 | Snowflake 发布说明 2026-08-26 |
| Knowledge Graph：KG_NODE / KG_EDGE + 递归 CTE | 一手确认 工程博客《Ontology in Snowflake: Building Cortex Agents》与 Snowflake-Labs/knowledge-graph-snowflake | Snowflake 工程博客 / GitHub |
| Cortex Sense 47% → 83% | 厂商自报 Summit 2026-06-02 公布，私有预览；Sense 的输入还包括查询历史、对象元数据、BI 看板与语义视图（Horizon Context） | SiliconANGLE / Constellation / Atlan / typedef 的 Summit 报道 |
| CoWork / CoCo 改名；ontology-stack-builder skill（2026-03-30） | 文章所述，未独立核验 不影响本文结论 | 原文 |
两种范式，以及文章没说透的三件事
文章用 Palantir 的四件套（Object / Link / Action / Function）做了六维对标。把 OntoOS 放进同一张表当第三列，差异立刻清楚——OntoOS 在 Link 这一维比 Snowflake 多一样东西（实测命中率），在 Object / Function / 入口三维是"有但散落"，在 Action 一维与 Snowflake 一样空白。
| 维度 | Snowflake（范式 B） | Palantir（范式 A） | OntoOS 今天 |
|---|---|---|---|
| Object / 实体 | Semantic View 实体 + KG_NODE；维度、度量、关系随实体定义 | Ontology SDK Object Type，带 property | 43 个实体（42 表实体 + 1 合成实体"服务"），定义在 console/registry/entities.py（Python），不在湖仓；无度量、无同义词 |
| Link / 关系 | KG_EDGE 显式声明，GraphRAG 遍历 | Link Type，带 cardinality | 79 条登记关系（57 条 1:N / 10 条 N:1 / 7 条 N:M / 5 条 1:1），13 条跨域桥；每条带实测命中率与 confirmed / weak 置信度——这是两家都没有的一维 |
| Action / 写 | 无独立 Action 层；写走 SQL / ETL | Action Type：validate 前置条件 + 权限 + 副作用 | 无，且是刻意的：只读 + 交接（Apollo 控制台 / 发布流程 / 负责人线索） |
| Function / 逻辑 | Cortex 函数、存储过程、Sense 的智能体函数 | Function metadata，可声明可调用 | 7 条服务端命名查询（SQL 由服务端持有、启动期 lint）+ 36 个 DWD / DWS 派生视图 + 技能仓 48 张实测 SQL 模板 |
| 入口 | SQL + CoWork / CoCo 自然语言 + Semantic Studio（git） | Workshop 拖拽 + OSDK（TS / Python）+ AIP agents | 本体控制台（飞书登录、发布区 / 工作区角色）+ MCP 8 个只读工具（经公司网关、Keycloak 令牌）+ 4 个姊妹技能 + probe CLI |
| 治理 | RBAC + FGAC + ABAC；Polaris 跨引擎 | 资源级 RBAC | 发布区 / 工作区两套层、每日原子快照发布（黄灯门禁）、服务端脱敏、审计；无跨引擎 / 开放格式（ADB-PG 专有） |
文章没说透的三件事
① Semantic View 的要害不是"关系"，是"受控词汇 + 度量"
文章把语义层描述为"哪些表构成实体、实体间什么关系"。但对 NL→SQL 真正起作用的是另外两件事：同义词（业务名词 → 列 / 实体）与度量（可聚合的量及其口径）。Cortex Analyst 85–90% 的准确率来自"骨架 + 词表 + 口径"三者，不只是骨架。OntoOS 的报障场景（页面名词 → 微应用 → 仓）今天靠 ILIKE 兜底，缺的正是词表。
② "图存进仓"是一种分工，不是一种妥协
Snowflake 把 KG 限定在"本体级"（实体与关系），不把事实级的大图（点击流、调用图）塞进 KG_EDGE，所以百万边以下的判断成立。OntoOS 恰好有两种图：本体级的（工作负载 ↔ 仓 ↔ 库 ↔ 表 ↔ 接口）和事实级的（2,800 万调用边、404 万 SQL 字段引用）。前者该进 KG，后者该留在事实表并以"线索摘要"（code_call_threads，≈501 万行物化闭包）挂进本体。分工对了，递归 CTE 在 ADB 上才跑得动。
③ Cortex Sense 的 Scan → Build → Share，OntoOS 各做到了哪一步
Scan：OntoOS 比 Sense 深——不只扫仓内元数据，还扫 GitLab / K8s / DMS / Apollo / 云网络 / ECS / 门户 / 镜像反解 / 活体 JVM 九个域。Build：Sense 是自动的，OntoOS 是人工策展（ADR-0045 否决了纯自动推导，理由是零外键、同名列不可信、跨域桥全是带解析逻辑的推断）。Share：Sense 把全局本体作为基底一次性暴露给 Agent；OntoOS 是 Agent 按需调 8 个工具逐跳取。差距集中在 Build 的自动化辅助与 Share 的预加载形态。
范式结论。文章说"有数仓 + 数据团队的企业接 Snowflake 范式最顺"。OntoOS 的起点正是如此：已有湖仓、已有 ODS / DWD / DWS 分层、已有每日发布。所以不该去模仿 Palantir 的独立 ontology 层与 Action 语义，而应沿范式 B 把三样东西补齐——可声明的语义层、统一的节点边面、给 Agent 的全局基底——同时守住 OntoOS 独有的两件事：命中率是一等属性、行为语义边来自代码反解。
OntoOS 今天站在哪一层（发布区快照 2026-10-01）
以下数字全部来自发布区快照（publish_20260930_130033，2026-10-01 05:17 发布，最近三次发布均为黄灯）、控制台注册表与 ontoos_extract 仓库，不引用技能文档里的历史数字。行数为 pg_class 估算或直连 count，口径在附录。
四层对位
catalog / freshness 工具；服务端脱敏 + 审计。缺 开放表格式与跨引擎读（ADB-PG 专有）；Maintain 只有抽取侧的覆盖台账，没有"数据质量"产品面。registry/*.py（Python dataclass，随仓发版、PR 评审——这已是 Studio 的 git 工作流的穷人版）；列注释真源在 schema.py（ADR-0045 记：DB 列注释 563/1602，视图层全部丢失）；术语在 nav.py 词汇表与 CONTEXT.md。缺 度量、同义词、可被 Agent 读取的 spec 形态；DMS 侧表注释仅 35.6%。drill 沿一条登记关系走一跳。缺 统一的节点 / 边表与多跳遍历——多跳要 Agent 自己串 drill；7 个视图在 ADB 上实测 OOM / 超时（标 heavy）；"服务"是合成实体、无表无主键。/mcp（ADR-0050），经公司 agentgateway、Keycloak 令牌（ADR-0052）；search → describe → query/drill 三步工作法；结果信封带 snapshot / pin / truncated。缺 全局本体的预加载形态（manifest）；评测基线仅 8 用例；运维 Agent 严格准确率 ≈22% 停滞、Agent 字典滞后本体 4.7–9.7 倍（2026-09 台账）——这正是 Sense 要解的"context 瓶颈"。13 条跨域桥：登记时实测命中率
命中率是关系登记时的基线值，不是当前值（v2.0 评审 CC-06 已裁定要拆成 RelationDefinition 与 RelationObservation）。斜纹 = weak（推断关系，不能当等值连接）。命中率偏低多半是业务覆盖缺口（如镜像未抽取、库未纳管），不是关系错误。
读法：前六条是"身份桥"（标签 / 名字 / 资源 id 直接对上），后七条是"推断桥"（解析连接串、文本匹配表名、Feign 名对 Service 名）。Snowflake 的 KG_EDGE 不区分这两种；OntoOS 把置信度与命中率做成一等属性，是对的——下一步要让它们随发布每天重测而不是停留在登记时的基线。
以 Snowflake 为镜：OntoOS 的五个结构性缺口
G1 语义层不是一等公民
本体知识今天住在三处：技能仓 Markdown（relationships.md + 24 个 references，952 KB，SKILL.md 内 245 处会漂移的数字）、控制台 Python 注册表（43 实体 / 79 关系，ADR-0045 定为唯一真源）、以及 36 个派生视图的 SQL 体内。没有一处是可声明、可被 Agent 读取、可随发布版本化的 spec。Semantic View 的另外两个要素——度量（服务的端点数、依赖数、爆炸半径、配置漂移数的口径）与同义词（报障名词、拼音、英文名、门户菜单名、枚举中文）——完全缺席；门户微应用解析 exact 3,070 / unresolved 388 / ambiguous 112，报障名词落点靠 search 的 ILIKE。上游语义供给也薄：DMS 表注释覆盖 35.6%、字段注释 45.5%，OntoOS 能暴露这个缺口，但没有把"注释覆盖率"做成可巡检的度量。
G2 图没有统一抽象
79 条关系散落在注册表，36 个视图各自物化一条链（入口链 7 跳、MQ 闭合、FE→BE→DB），Agent 要跨三跳只能串 drill。没有 KG_NODE / KG_EDGE 式的统一节点边面，就没有"任意实体 k 跳邻域"与"两实体间路径"这类通用查询，GraphRAG 无从接起。ADB 的现实约束也在这里：v_ingress_chain、v_scheduler_outbound、workload_active_gitlab 等 7 个视图实测段级 OOM 或超 60 s——说明"用视图现算多跳"已到天花板，Snowflake 的做法（物化节点边表 + 递归 CTE + 跳数上限）才是出路。"服务"是合成实体（工作负载名 / spring.application.name / feign_name / 仓 / Apollo app_id 的等价类），无表无主键，闭包有损（64.7% 调用方天花板）——它恰恰应该成为 kg_node 里的第一等节点。
G3 Agent 的 context 是按需拉取，不是全局基底
MCP 的三步工作法（search → describe → query）要求 Agent 每次从零摸索；8 个工具的描述与 7 条命名查询的 notes 是它能拿到的全部"全局知识"。Cortex Sense 的 Share 做的是反过来的事：把全局本体压成基底，一次性进 Agent 的上下文。OntoOS 这边的证据已经很清楚——运维 Agent 覆盖率 93% 但严格准确率 ≈22% 停滞，根因是知识供给断层（Agent 字典滞后本体 4.7–9.7 倍：边表 178 vs 844、MQ 565 vs 5,454）。评测只有 8 条用例，没有"有 / 无本体"的对照实验，所以说不出 OntoOS 对 Agent 准确率的贡献是多少。
G4 开放性：一套专有仓、两套湖仓、零开放格式
Horizon 的 Extend 让其他引擎直接读目录；OntoOS 的消费方只有控制台、MCP 与四个技能，发布区锁在 ADB-PG 里。公司同时在建业务湖仓（Hologres + DataWorks，核心库 110 张表同步），研发本体与业务数据分处两套仓、零桥——而 Snowflake 路线的终点恰恰是"业务对象 ↔ 物理表 ↔ 使用它的应用"连成一张图。另一个开放性债务是安全：发布区约 1,961 个明文凭据（2026-09 台账 SEC P0），不收口就不能把 KG / manifest 开给全员。
G5 Action 层缺位——但缺得对，要补的是它的只读半身
Palantir 把每一次对本体的修改包成 Action（validate + 权限 + 副作用）；Snowflake 没有，OntoOS 也没有，而且 OntoOS 的只读边界是明确的产品决策（改配置 / 重启 / 发布一律交接）。该补的不是写操作，而是"变更意图"的建模：改表 / 改接口 / 改配置 / 下线服务 四类意图各有一条可预检的影响面查询（v2.0 设计的 ontoos_impact 是雏形），输出结构化的交接单到发布流程与 Apollo，并把预检结果写回审计。这样本体对变更的价值从"事后排障"前移到"事前预检"，又不越过只读红线。
不盲从清单
✗ 不把事实表灌进 KG
2,800 万调用边、3,268 万方法、404 万 SQL 字段引用是"发生"不是"东西"；进 kg_edge 会直接把 ADB 递归 CTE 压垮，也违背 Snowflake "百万边以下"的前提。KG 只装本体级边，事实级以物化线索（code_call_threads）摘要挂接。
✗ 不采购独立图数据库
两家都证明"图在仓里 + 递归 CTE"对本体级规模够用；多一套引擎就多一套治理边界与一份凭据分发，正是 v2.0 要消灭的东西。
✗ 不把 NL→SQL 自由问答做成全员面
Snowflake 有 Cortex Analyst 的 85–90% 是因为语义层先行。OntoOS 的全员面坚持命名查询 + 受限 DSL（v2.0 D3），自由 SQL 挡不住派生表达式推断秘密列。先把语义层做实，再谈 NL→SQL。
✗ 不让"自动推荐边"绕过策展
ADR-0045 否决纯自动推导的三条实测理由（零外键、同名列不可信、跨域桥皆推断）依然成立。可以借鉴 Autopilot / ontology-stack-builder 做候选提案，但入库必须经 PR 评审与命中率守卫——真源不变。
规划：四层 × 三阶段
原则只有三条：本体是湖仓里的一等对象（可查询、可版本、可评测）；每一步都能用现有机制承接（ADR、PR 评审、命中率守卫、发布门禁、命名查询 lint）；每一步都有可复现的数字验收。与 v2.0 查询服务（执行与事实上收服务端、Go CLI、薄 Skill）并行推进，共用契约包，不重复造轮子。
阶段 A · 本体入仓 2026-10 → 2026-12
目标：本体从 Python 与 Markdown 搬进湖仓与契约包，Agent 第一次拿到"全局本体"，并有一个可复现的准确率对照数。
registry/entities.py + relations.py + schema.py 列注释 + nav.py 词汇表导出为版本化的 ontology.yaml 契约包（实体 / 关系 / 列说明 / 术语，含 contract hash）；注册表仍是真源，YAML 是生成物，CI 门禁"生成物与真源一致"。验收：契约包随 release tag 发布；v2.0 服务端只消费契约包，不再 import extract 仓。dws.kg_node / dws.kg_edge：节点 = 42 类表实体的实例 + 合成实体"服务"的等价类；边 = 79 条登记关系的实例化（列：relation_key / cardinality / confidence / evidence / observed_hit_rate），首批覆盖 13 条跨域桥与所有"实体 ↔ 实体"的域内边；6 张事实表与子表属性不进图。验收：节点 ≥50 万、边 ≥100 万；全量生成 ≤30 min；每条关系的当日命中率入 kg_relation_observation，与登记基线偏差 >10 pp 自动开 issue。neighborhood（实体 k 跳邻域，k ≤ 3，可按边类型过滤，递归 CTE）与 path_between（两实体最短路，≤ 4 跳）。它们是 GraphRAG 的最小接口，也让"共享库故障传播""2 跳 Feign 上游"这类场景不再各写一张视图。验收：在 kg 表上 p95 ≤ 5 s；替换 ≥3 个 heavy 视图的用途。instructions 与 Resource ontoos://manifest 下发（对应 Sense 的 Share）。验收：零运行时数字（CI 门禁）；Claude Code / Codex 两类客户端加载后 tools/list 不膨胀。ontoos_ro 真正授权。这是 kg / manifest 能开给全员的前提，不是本阶段的可选项。验收：发布区可打码列之外的明文凭据值 = 0；安全测试集通过。阶段 B · 语义层成为一等公民 2027-01 → 2027-06
目标：补齐 Semantic View 的另外两件事（度量、同义词），把 Build 的半自动化与 Studio 的编辑体验做成控制台的一页，并打开第一个开放出口。
v_service_iface_summary（1,833 服务）升级为"服务度量面"。验收：≥20 个度量入 spec 并可经命名查询取值；面板不再用单数字冒充分母。search 先走词表再 ILIKE 兜底；报障名词 → 实体的落点率成为度量。验收：43 个实体全部有 ≥1 组同义词；incident 分诊 100 条真实工单路由仍全对且首跳命中率提升。service_context / impact（v2.0）落地；Manifest v1 带度量与同义词。验收：MCP 调用中命名查询占比 ≥70%；bench 第二轮对照。阶段 C · 从研发本体到企业上下文基底 2027-07 → 2027-12
目标：把本体从"研发资产"延伸到"业务对象 ↔ 物理表 ↔ 服务 ↔ 页面"的一张图，并给变更以事前预检。
验收指标：现值 → 阶段目标
| 指标 | 现值（2026-10-01） | A 结束（2026-12） | B 结束（2027-06） | C 结束（2027-12） |
|---|---|---|---|---|
| L1 发布区明文凭据值 | ≈1,961 | 0 | 0 | 0 |
| L1 开放格式消费方（非 MCP / 控制台） | 0 | 0 | 1（DuckDB / Hologres 读 Parquet） | ≥2 |
| L1 业务湖仓同步表挂回 DMS 物理表 | 0 / 110 | — | 110 / 110 | 110 / 110 |
| L2 契约包 / spec 版本化 | 无（Python 注册表） | ontology.yaml v0 | v1：度量 ≥20、同义词 43/43 | v2：含业务实体 ≥10 |
| L2 跨域桥数 / weak 桥数 | 13 / 3 | 13 / 3 | 18 / ≤1 | ≥23（含跨仓）/ 0 |
| L2 报障名词首跳落点率（incident 100 条） | 路由全对；首跳落点未量化 | 基线建立 | +10 pp | 持平或更好 |
| L3 kg_node / kg_edge | 无 | ≥50 万 / ≥100 万 | + 每日 Observation | + 跨仓边 |
| L3 heavy 视图数（OOM / 超时） | 7 | ≤3 | 0 | 0 |
| L3 多跳查询 p95（k ≤ 3） | 不可用 | ≤5 s | ≤3 s | ≤3 s |
| L4 Manifest | 无 | v0 ≤32 KB、零数字 | v1 带度量 | 按角色裁剪 |
| L4 bench 对照（AC@1，有 vs 无 manifest） | 无对照；严格准确率 ≈22% | 报告 + 差值 ≥5 pp 才继续加码 | ≥ +15 pp | 看板常态化 |
| L4 命名查询数 / MCP 调用中命名查询占比 | 7 / 未统计 | 12 / 基线 | 30 / ≥70% | ≥40 / ≥80% |
| L4 变更意图预检接入发布流程 | 无 | — | 协议定稿 | ≥1 条产品线 |
所有"现值"可在发布区上重算；所有"目标"写成可被 CI / 连库守卫断言的形式，不写"显著提升"。
风险与需要拍板的问题
风险 ADB 递归 CTE 的性能
段级 OOM 已有 7 个视图的先例。对策：kg 两表物化 + 跳数上限（≤3）+ 预算（statement_timeout）+ 边类型过滤；超出的走离线 job。阶段 A 的 A3 验收就是这条风险的试金石。
风险 策展人力是瓶颈
13 条桥是 4 个月人工实测的结果。推荐边只能产候选，入库仍要人审；若无专人，季度 +5 条桥的目标会落空。建议明确 1 名本体策展 owner（兼），本体页把评审成本降到"看命中率 + 点合入"。
风险 两套湖仓、两套真源
研发本体在 ADB，业务数据在 Hologres。若业务本体试点在 Hologres 上另起一套 spec 语法与注册表，就会复刻"技能仓 vs 注册表"的双真源问题。对策：同一套 spec 语法、同一个契约包、不同的存储。
风险 Manifest 吃掉 Agent 的提示预算
全局本体一旦超过几十 KB 就会挤掉任务上下文。对策：≤32 KB 硬上限、按角色 / 场景裁剪（Sense 也是按用户角色注入）、深层内容留在 Resources 按需拉取。
风险 评测可信度
LLM-Judge 与人工评价相关系数仅 0.11（2026-08 台账），自动评分暂不可信。A5 的对照实验必须保留人工校准环，否则"+X pp"没有说服力——这也是为什么要自己做，而不是引用 Snowflake 的 47→83。
风险 安全 P0 阻塞全员开放
明文凭据不收口，kg / manifest / 开放导出全部只能在小范围用。A6 排在阶段 A 不是偶然。
需要拍板
附录：事实口径与来源
A · 湖仓与仓库事实（本文引用的数字从哪来）
| 事实 | 值 | 口径 / 来源 |
|---|---|---|
| 发布区快照 | publish_20260930_130033，2026-10-01 05:17 发布，4,157 源 / 4,113 活跃批次，最近三次发布黄灯 | MCP freshness（发布区） |
| 对象目录 | 148 = 112 ODS 当前视图（契约 112/112）+ 36 关联模型域视图；7 个视图标 heavy | MCP catalog；heavy 为实测 OOM / 超时标注 |
| 注册表 | 43 实体（1 合成）、79 关系（76 confirmed / 3 weak；57 1:N、10 N:1、7 N:M、5 1:1）、13 跨域桥、6 事实表 | ontoos_extract/console/registry 直接计数（2026-09-30 代码） |
| 桥命中率 | 见第 3 节条图 | 注册表 hit_rate（登记时基线，非当前值） |
| MCP 面 | 8 只读工具、7 命名查询、≤200 行 / 64 KB、并发 4、逐次审计、网关 Keycloak 令牌 | ADR-0050 / ADR-0052、docs/console.md §7、MCP queries |
| 资产规模 | GitLab 2,000 仓；K8s 14 集群 5,589 工作负载；DMS 604 实例 / 17,027 库 / 104,098 表 / 1,904,709 列；代码归档 4,134；Apollo 113 应用；服务接口汇总 1,833 | 直连 ods_current / dws count（2026-10-01 21:00） |
| 语义覆盖 | DMS 表注释 37,095 / 104,098 = 35.6%；字段注释 866,417 / 1,904,709 = 45.5%；门户微应用 exact 3,070 / unresolved 388 / ambiguous 112 / assets-path 3 | 直连 count；ADR-0045 另记 DB 列注释 563/1602、视图层丢失 |
| 事实表量级 | 调用边 ≈2,807 万；方法 ≈3,268 万；调用线索 ≈501 万；SQL 字段引用 ≈404 万；端点 ≈30.7 万；错误签名 ≈73.1 万；枚举 ≈55.6 万 | pg_class 估算（含历史批次，对当前视图偏高） |
| 工程规模 | 2,205 提交（2026-05-13 → 09-30）、52 ADR、112 张 ODS DDL + 45 视图、9,317 测试函数、86,557 行 Python、issue / PR 至 #525 | git 与源码统计 |
| Agent 现状 | 运维 Agent 覆盖 93% / 严格准确率 ≈22%；Agent 字典滞后本体 4.7–9.7 倍；bench 85 题；LLM-Judge 相关性 0.11；发布区明文凭据 ≈1,961 | 半月台账 2026-09-01 / 09-15 |
| 技能面 | ontoos-probe 6 层面 77 场景 48 模板；references 952 KB；SKILL.md 245 处数字 | v2.0 架构设计（2026-09-20）与台账 |
B · 外部来源
- 线索文章：《Snowflake 怎么把本体论塞进数仓：四款产品对比 Palantir Ontology》（公众号，作者 hyj）— mp.weixin.qq.com/s/z8F_4wxJLQj1CIhwwfbfMg
- Snowflake 工程博客《Ontology in Snowflake: Building Cortex Agents》— snowflake.com/…/ontology-grounded-cortex-agents；参考实现 Snowflake-Labs/knowledge-graph-snowflake
- Snowflake 发布说明：2026-08-26 Semantic Studio（Preview）；2026-06-26 语义视图逻辑表 GA
- Apache Polaris 顶级项目公告（2026-02-19）— polaris.apache.org；Snowflake《Apache Polaris: The End of Data Vendor Lock-In》— snowflake.com
- Summit 2026 报道：SiliconANGLE、Constellation Research、Atlan：Cortex Sense、typedef：What Is Cortex Sense
- Semantic Views 时间线：Atlan 2026 指南
- Capital One《Scaling Agent Context with Knowledge Graphs on Snowflake》— capitalonesoftware.com
C · 内部关联文档
- 《OntoOS 查询服务架构设计 v2.0》（2026-09-20）：执行与事实上收服务端、13 工具、RelationDefinition / RelationObservation 拆分、P0–P3 路线图。
- ADR-0017 快照发布、ADR-0045 策展关系注册表、ADR-0049 发布快照保留、ADR-0050 控制台 MCP 端点、ADR-0052 网关 Keycloak 令牌；CONTEXT.md「本体控制台」与「Relationships」段。
- 半月对齐台账 2026-09-01 / 2026-09-15（运维 Agent 基线、安全 P0、Hologres 业务湖仓）。
本页为内部规划稿，noindex；数字以发布区当日快照为准，复查请重跑附录 A 的口径。