# 本体论、AI 与 Palantir：从知识表示到可治理行动的语义操作层

> 工作稿。生成自本地 ontology 研究知识库，时间为 2026-06-25。当前知识库包含 803 条去重来源、150 条核心来源、332 条候选来源、2157 个检索分片、1307 条抽取声明和 16721 条关系边。本文中的方括号不是最终引用格式，而是可回溯的 source ID 证据锚点。

## 摘要

生成式 AI 让机器更会说话，但没有自动让机器更懂世界。高后果场景中的 AI 系统必须知道对象是什么、对象如何被识别、哪些关系可以成立、哪些数据可以被使用、哪些动作可以被执行、谁需要负责，以及事后如何审计。本体论 ontology 正是在这些问题上重新变得关键：它不只是分类表，也不只是知识图谱的数据库结构，而是一套让概念、身份、关系、约束、来源、政策、工具和行动显式化的语义操作层。

本文的中心判断是：agentic AI 的下一阶段，不是“大模型替代本体论”，而是“大模型需要本体论”。形式本体论和语义网标准提供了可计算语义的底层语言；生命科学中的 Gene Ontology、OBO Foundry、HPO、Monarch、ROBOT、ODK、DeepGO-SE 等案例证明，科学共同体已经把 ontology 用作长期维护的机器可读知识基础设施；LLM、KG 与 RAG 的最新研究则显示，语言模型需要外部语义记忆、图结构检索、来源和验证；Palantir 的 Foundry Ontology 与 AIP 提供了一个产业样本，把对象、关系、动作、权限、函数、评估、可观测性和 MCP 工具暴露连接成可执行操作层。这个样本很有价值，但它也暴露出治理、公共信任、供应商依赖和责任边界问题。

## 1. 本体论不是分类表，而是显式承诺

计算机科学中的 ontology 常被误读成 taxonomy、schema、data catalog 或知识图谱的节点标签集合。这种弱化会掩盖它最重要的作用：ontology 是关于某一领域“什么存在、如何命名、如何关联、如何约束”的显式承诺。Gruber 的经典定义强调 ontology 是 conceptualization 的显式规格；Uschold 与 Gruninger 强调清晰性、一致性、可扩展性、编码中立和最小承诺；Guarino 则把形式本体论放回信息系统的语义基础中。对 AI 来说，这些原则不是哲学装饰，而是决定系统能否稳定共享知识、检查约束和解释推理路径的前提。

如果一个组织只把 ontology 当成字段字典，它会得到更漂亮的数据目录，但不会得到可靠的行动语义。真正有用的 ontology 要回答更硬的问题：一个“客户”“病人”“供应商”“任务”“告警”“资产”“模型输出”分别是什么？什么时候两个标识符指向同一对象？某种关系是否可传递、是否有方向、是否有时间范围？哪些属性是观测值，哪些属性是推断值？哪些动作会改变真实世界状态？这些问题决定了 AI 系统是在操纵文本，还是在可审计地操纵一个被明确建模的世界。

证据锚点：`core-gruber-1993-portable-ontology`, `oa-https-doi-org-10-1006-ijhc-1995-1081`, `core-guarino-1998-formal-ontology-information-systems`, `guarino_oberle_staab_2009_what_is_ontology`, `core-noy-mcguinness-2001-ontology-101`, `core-baader-2003-description-logic-handbook`, `core-bfo-iso-21838-2`.

## 2. 标准栈把语义从文档推进到可验证系统

ontology 要服务 AI，必须落到可运行的标准栈上。RDF 给出图数据模型，OWL 给出形式化语义和推理基础，SPARQL 给出图查询语言，SKOS 支持轻量概念体系，SHACL 支持图约束验证，PROV-O 支持来源和生成过程描述。再往治理层走，LinkML、SSSOM、Schema.org、FAIR Data Point、FAIR Digital Object、DCAT、DQV、ODRL、DPROD、OpenLineage、Open Data Contract Standard 和 DMN 等标准与框架把 schema、mapping、metadata service、目录、质量、使用政策、数据产品、血缘、契约和决策模型纳入机器可处理的范围。

这条标准栈的重要性在于，它把 ontology 从“我们有一套业务术语”推进到“我们有一套可以被查询、验证、审计和治理的语义系统”。LLM 可以根据自然语言生成答案，但答案是否引用了正确的数据、是否违反了使用政策、是否基于过期血缘、是否经过约束校验、是否可以追溯到生成活动，这些问题不能靠提示词解决。它们需要标准化的图表示、schema、mapping、metadata、验证机制、来源机制和政策表达。

证据锚点：`core-w3c-rdf-11-concepts`, `core-w3c-owl2-overview`, `core-w3c-sparql-11-query`, `w3c_shacl_2017`, `w3c_skos_reference_2009`, `phase2-w3c-prov-o-2013`, `p2-llm-ont-032`, `phase14-schemaorg-evolution-structured-data-web-2016`.

## 3. 质量、演化与报告决定 ontology 能否进入行动系统

如果 ontology 要成为 AI 的操作层，它必须像软件和数据产品一样被测试、报告、版本化和维护。OntoClean 说明分类层级会出现深层概念错误，例如把角色、阶段、物理对象和事件错误地放进同一稳定类层级；OOPS! 说明常见建模缺陷可以被自动扫描；ontology evolution 的研究则提醒我们，ontology 变化不是普通数据库 schema 变化，因为它改变的是共享意义、依赖应用、映射关系和下游推理边界。

这对 LLM 时代尤其关键。LLM 让生成候选概念和关系变得便宜，也让低质量 ontology 被快速扩散成为可能。METHONTOLOGY、NeOn、MIRO、ODK、ROBOT 和 FAIRsharing 共同指向一个更工程化的答案：ontology 需要需求、复用、报告、发布、质量检查、标准注册、维护责任和变更治理。没有这些机制，所谓“语义层”很容易变成另一层无人负责的技术债。

证据锚点：`fernandez_lopez_gomez_perez_juristo_1997_methontology`, `guarino_welty_2002_ontoclean`, `phase2-poveda-2014-oops`, `suarez_figueroa_2015_neon`, `phase16-noy-klein-2004-ontology-evolution-schema-evolution`, `phase16-miro-guidelines-minimum-information-reporting-ontology-2017`, `phase16-fairsharing-community-standards-repositories-policies-2019`, `phase7-ontology-development-kit-toolkit-2022`, `phase7-robot-automating-ontology-workflows-2019`, `phase6-lippolis-2025-llm-assisting-ontology-evaluation`, `phase6-kampars-2025-llm-collaborative-ontology-design`.

## 4. 科学 ontology 说明共享语义可以成为长期基础设施

生命科学是 ontology 成功运行的强证据。Gene Ontology 从 2000 年的统一生物学工具发展为持续维护的知识库；GO-CAM 把单个术语注释推进到因果活动模型；OBO Foundry 把开放性、标识符、定义、关系、版本和正交性变成可评估的治理原则；Ontology Development Kit 与 ROBOT 把 ontology 的构建、导入、发布、报告和质量检查工程化；HPO 与 Monarch 把表型、基因、疾病和跨物种知识连接起来；BioPortal、OLS4、Ontobee 和 Bioregistry 则说明 ontology 生态需要可搜索、可解析、可映射、可调用的服务层。

更关键的是，ontology 已经进入 AI for science 的模型结构中。DeepGO、DeepGOPlus 和 DeepGO-SE 不只是把 Gene Ontology 当成标签集，而是把 ontology 的层级、语义和公理用于蛋白功能预测、近似语义蕴含和可解释性。这说明 ontology 不只是 AI 生成结果之后的整理工具，它可以直接定义神经模型的输出空间、约束和解释层。

这条证据链对 Nature 风格文章尤其重要：它把论点从企业数字化扩展到科学知识基础设施。Palantir 不是 ontology 重新重要的唯一原因；科学共同体几十年的实践已经证明，长期维护的共享语义可以成为机器可读知识、数据复用和 AI 建模的基础。

证据锚点：`core-gene-ontology-2000`, `phase7-gene-ontology-knowledgebase-2023`, `phase7-go-cam-causal-activity-modeling-2019`, `smith_etal_2007_obo_foundry`, `phase7-obo-foundry-2021-operationalizing-open-data-principles`, `phase7-ontology-development-kit-toolkit-2022`, `phase7-robot-automating-ontology-workflows-2019`, `noy_etal_2009_bioportal`, `phase7-ols4-ontology-lookup-service-2025`, `phase7-ontobee-linked-ontology-server-2016`, `phase7-bioregistry-biomedical-entity-identification-2022`, `wilkinson_etal_2016_fair`.

## 5. LLM 让 ontology 更必要，而不是更过时

大模型降低了语言接口和初步建模的成本，也放大了语义漂移的风险。LLM 可以抽取术语、生成候选关系、辅助本体匹配、产生查询、总结图社区，甚至从论文中构建科学知识图谱。但它们生成的结构如果没有实体解析、关系语义、来源、版本、约束和人工审查，很快会变成另一种不可维护的文本幻觉。

LLM+KG 和 GraphRAG 研究正在把这个问题推到中心位置。RAG 解决了“答案需要外部资料”的问题，但普通文本块检索无法充分表达对象、关系、路径、时间、规则和来源。GraphRAG、KAG、HippoRAG、LightRAG、OG-RAG、KGQA 和 KG-RAG 评测开始探索什么时候图结构有帮助、图不完整时会怎样失败、ontology 如何组织检索上下文、KG 路径如何约束推理。一个实际可用的企业或科研 AI 系统需要的是：LLM 负责语言和候选推理，ontology/KG 负责外部语义记忆、检索路径、约束边界和证据来源。

证据锚点：`arxiv-2306-08302v3`, `oa-https-doi-org-10-1145-3447772`, `oa-https-doi-org-10-1109-tnnls-2021-3070843`, `core-lewis-2020-rag`, `core-edge-2024-graphrag`, `phase6-sharma-2025-og-rag`, `phase6-oarga-2026-scientific-kg-ontology-open-llms`, `phase6-zhou-2025-kg-rag-incompleteness`, `phase6-xiang-2025-when-to-use-graphs-rag`, `phase11-ali-2026-ontology-grounded-kg-clinical-hallucinations`, `phase11-wu-2026-memgraphrag-memory-multi-agent-graphrag`, `ont-ai-024`.

## 6. LLM 可以辅助 ontology 工程，但不能替代治理

LLM 在 ontology engineering 中最有价值的角色不是“一键生成本体”，而是把建模过程拆成可审查的协作工作流。它可以帮助提出 competency questions，整理用户故事，抽取候选概念，建议关系类型，辅助 ontology matching，生成 SHACL-like 约束草案，或在已有 ontology 上执行一致性检查。但是，ontology 的质量最终取决于领域边界、建模承诺、评估指标和维护制度，而不是文本看起来是否合理。

近期研究已经开始从“prompt 生成 ontology”转向更严肃的生命周期问题：LLM 如何辅助 ontology requirements engineering，如何验证 competency questions，如何生成领域 ontology，如何参与协作式 ontology 设计，如何在学术主题中分类关系，如何评估匹配质量和图级可用性。这里的关键不是让 LLM 取代 ontology engineer，而是让 LLM 成为一个可控的、可审计的建模助手。

证据锚点：`phase2-li-garijo-poveda-2025-llm-oe-review`, `ont-ai-004`, `p2-llm-ont-006`, `phase3-llm-ontmem-023`, `phase2-llms4om-2024`, `phase2-agent-om-2023`, `p2-llm-ont-007`, `p2-llm-ont-030`, `phase6-lippolis-2025-llm-assisting-ontology-evaluation`, `phase6-zhao-2025-llm-ontology-requirements-engineering`, `phase6-lippolis-2025-domain-specific-ontology-generation-llms`, `phase6-kampars-2025-llm-collaborative-ontology-design`.

## 7. Palantir 的独特性：把 ontology 变成可执行操作层

Palantir 是当前最具体的商业案例，因为它公开把 ontology 描述为企业运营层，而不只是语义模型。Foundry Ontology 中的 object types、properties、link types、actions、functions 和 dynamic security 把数据对象、业务关系、计算逻辑和权限边界放到同一语义界面中。AIP 则把 LLM agent、AIP Logic、AIP Evals、observability、workflow lineage 和应用开发连接到这套 ontology 上。Ontology MCP 进一步把选定 object types、action types 和 query functions 暴露成外部 agent 可调用的 MCP tools。

这意味着 Palantir 的 ontology 至少承担三种角色。第一，它是企业状态的语义模型：把数据、模型和业务对象映射成统一对象层。第二，它是 agent 的工具和行动目录：哪些对象可读，哪些动作可执行，哪些函数可调用，哪些权限必须满足。第三，它是治理和审计界面：evals、simulation、logs、traces、lineage、permission scopes 和 observability 用来约束或追踪 AI 行动。

必须区分两类证据。Palantir 官方文档可以支持“架构如何设计”和“系统声称有哪些控制面”的事实判断；客户案例和商业叙事只能作为采用信号或产品叙事，不能作为学术效果证明。Palantir 的案例说明 ontology 可以成为 agentic AI 的操作层，但它不能证明这种操作层天然安全、公平、透明或公共合法。

证据锚点：`core-palantir-ontology-overview-2026`, `core-palantir-aip-overview-2026`, `phase2-pal-ontology-mcp-overview-2026`, `phase2-pal-aip-evals-ontology-edits-2026`, `phase2-pal-aip-observability-overview-2026`, `pal-doc-aip-ethics-governance-2026`, `phase3-pal-mcp-installation-2026`, `phase3-pal-mcp-security-2026`, `phase5-palantir-connecting-agents-decisions-2026`, `phase5-palantir-mcp-hub-announcement-2026`, `phase5-palantir-foundry-platform-summary-llm-2026`.

## 8. 非 Palantir 系统也在收敛到同一组语义原语

Palantir 不是孤例。现代数据平台、BI 平台、语义层、OBDA/virtual knowledge graph、数据产品标准、数据契约、血缘系统、工业数字孪生、工业信息模型和 agent memory 研究都在收敛到类似原语：对象、指标、维度、数据产品、质量规则、血缘事件、时间状态、工具语义、访问政策和可更新记忆。Databricks Genie、Looker semantic model、Microsoft Fabric semantic model、dbt Semantic Layer、data.world AI Context Engine 等商业材料显示，企业希望让 LLM 查询和行动建立在被认证的语义层上，而不是直接面对数据湖和 SQL 表。

这些材料应被谨慎使用。它们不能证明某种产品效果，但能说明产业需求：企业不希望 LLM 只做开放式文本生成，而希望它使用组织认可的指标、关系、定义、数据产品和权限边界。OBDA、Ontop、Wikidata、Croissant 以及开放标准如 ODCS、OpenLineage、ODPS、AAS、OPC UA、SAREF、eCl@ss、IEC CDD、Solid 和 DMN 则提供了更中立的证据，说明语义层正在从“描述业务”扩展到“约束机器可执行的业务”。

证据锚点：`phase3-llm-ontmem-024`, `p2-llm-ont-029`, `phase4-enterprise-databricks-genie-semantic-model-2026`, `phase4-enterprise-google-looker-semantic-model-gemini-2026`, `phase4-enterprise-microsoft-fabric-semantic-model-copilot-2026`, `phase4-enterprise-dataworld-ai-context-engine-2026`, `phase4-enterprise-dbt-semantic-layer-2026`, `phase14-xiao-2018-ontology-based-data-access-survey`, `phase14-calvanese-2016-ontop-answering-sparql-relational-databases`, `phase15-arenas-2024-morph-kgc-scalable-kg-materialization`, `phase14-croissant-ml-ready-dataset-metadata-2024`, `phase14-wikidata-free-collaborative-knowledgebase-2014`.

## 9. 治理问题：ontology 也是分类基础设施

ontology 的力量来自显式建模，但风险也来自显式建模。Bowker 与 Star 关于分类和基础设施的研究提醒我们，分类系统不是中立的标签集合，而是会塑造组织行为、资源分配和可见性的基础设施。Star 与 Griesemer 的 boundary object 概念说明，共享对象模型可以促进跨群体协作；但同一套模型也可能固化某些分类、遮蔽少数群体经验、扩大机构监控能力，或把争议转化成看似技术性的字段选择。

NHS Federated Data Platform 是有价值的治理案例，因为它有采购记录、隐私通知、DPIA、ICO 决定、议会报告、医学评论和公民社会批判，可以比较官方控制与外部担忧。这里的核心问题不是简单判断 Palantir 是否“好”或“坏”，而是问：谁定义对象模型？谁能访问可识别数据？哪些用途被允许？公众如何理解和挑战分类？供应商锁定如何影响公共部门主权？当 agent 能通过 ontology 暴露的工具行动时，责任边界在哪里？

证据锚点：`phase3-star-griesemer-1989-boundary-objects`, `phase3-bowker-star-1999-sorting-things-out`, `phase3-star-ruhleder-1996-ecology-infrastructure`, `phase3-nissenbaum-2010-privacy-context`, `phase3-selbst-etal-2019-fairness-abstraction`, `phase3-raji-etal-2020-accountability-gap`, `phase2-nist-ai-rmf-1-0-2023`, `phase2-nist-genai-profile-2024`, `phase2-eu-ai-act-2024`, `nhs-fdp-contract-explainer-2026`, `phase6-nhs-fdp-contracts-finder-2024`, `phase6-nhs-ndit-fdp-dpia-2026`.

## 10. 研究议程：从语义模型到可问责行动

未来研究不应停留在“ontology 是否比 LLM 更可靠”这种二分问题上。真正的问题是如何建造可问责的混合系统：LLM 提出解释、计划和候选动作；ontology 明确对象、关系和约束；KG 和图记忆提供可更新外部记忆；RAG 检索上下文；政策和权限决定可执行边界；SHACL、数据契约和 lineage 检查状态；observability 和 provenance 记录过程；人类仍对高后果行动负责。

这带来一组具体研究问题。生成的 triple 和 ontology update 如何验证、归因和回滚？agent memory 如何处理权限、纠错和遗忘？GraphRAG 什么时候真的优于文本 RAG？ontology-guided KGQA 的推理路径如何解释给人？跨组织 MCP tools 如何携带权限和责任？SPARQL federation、DPV、XACML、ODRL、Solid、VC、数据契约和 lineage 如何组合成可执行治理？公共部门如何在采购、DPIA、公众沟通和退出计划中治理这类语义操作层？这些问题比“更大的模型是否会自动解决语义问题”更接近 AI 走向真实行动时的瓶颈。

证据锚点：`phase11-tuan-sanyal-2026-ontology-constrained-neural-reasoning-enterprise-agents`, `phase5-liu-2025-ontology-guided-reverse-thinking-kgqa`, `phase6-sharma-2025-og-rag`, `phase6-xiang-2025-when-to-use-graphs-rag`, `phase11-joshi-2026-deontic-policies-agentic-ai-runtime-governance`, `phase11-tuan-sanyal-2026-predeployment-assurance-ontology-simulation`, `phase11-tuan-sanyal-2026-ontology-constrained-neural-reasoning-enterprise-agents`, `phase11-hamed-rocha-2026-biomedical-rag-majority-voting-verification-protocol`, `phase3-llm-ontmem-018`, `phase2-li-garijo-poveda-2025-llm-oe-review`, `phase2-nist-genai-profile-2024`, `w3c_shacl_2017`.

## 结论

ontology 的回归不是怀旧，也不是把符号 AI 重新包装。它是因为 AI 正在从回答问题走向使用工具、更新状态、参与流程和影响真实世界。只要 AI 需要知道“它在操作什么”“它凭什么这样说”“它能不能这样做”“谁应当负责”，ontology 就会重新成为基础设施。

对文章写作来说，最有力的结构不是把 Palantir 当成唯一主角，而是把它放在更大的证据链中：形式本体论提供概念承诺，语义网和治理标准提供机器可验证机制，科学 ontology 证明共享语义可以成为长期基础设施，LLM/KG/RAG 研究证明模型需要外部语义记忆，Palantir 展示 ontology 作为可执行操作层的产业形态，公共部门案例则提醒我们这种操作层必须接受治理和问责。

## 引用与写作注意

- 学术、标准和官方文档用于支撑事实与架构判断。
- Palantir 官方文档用于说明其系统设计，不等同于独立效果验证。
- 商业材料只作为采用信号和实现模式，不作为学术证明。
- NotebookLM 和 agent 报告只作为发现与综合线索，正式引用前必须回到原始 source ID。
- 下一步若转成 Nature 投稿，应把本文压缩为英文 Perspective/Comment 体裁，并把 source IDs 转为正式参考文献。