引言

如果你关注企业级 AI 领域，Palantir 是一个绕不开的名字。这家公司的核心产品 Foundry 之所以能服务于全球顶级军工、能源、制造业客户，底层支撑就是一套叫 Ontology（本体） 的系统。

Palantir 自己对 Ontology 的定义是：“一个位于组织之上的操作层，包含语义元素（对象、属性、链接）和动力学元素（操作、函数、动态安全），两者共同支撑各类用例。”（来源：Palantir Foundry 官方文档）

这不是学术论文里的本体论，而是一套 产品化的企业知识操作系统。本文拆解它的五个核心原语，讨论每个原语的设计意图，以及国内企业 AI 架构师能从中借鉴什么。

---

一、五原语总览

Palantir Ontology 由五个原语构成：

原语	一句话定义	作用
Object Types	实体类型定义	告诉系统"业务世界里有哪些东西"
Link Types	类型化的关系定义	告诉系统"这些东西之间怎么关联"
Action Types	受治理的操作定义	告诉系统"可以对这些东西做什么"
Functions	可注册的服务端逻辑	告诉系统"怎么计算/怎么处理"
Interfaces	多态接口	让不同类型的对象可以被统一操作

前两个（Object + Link）构成 语义层——描述世界是什么样的。
后三个（Action + Function + Interface）构成 动力学层——描述可以对世界做什么。

这种二层设计是 Palantir 区别于传统知识图谱的核心差异。传统知识图谱（Neo4j、Stardog）只有语义层，没有将"操作"纳入本体的定义。

---

二、逐一拆解

2.1 Object Types：不只是"表"

在关系数据库里，我们定义"表"来存储数据。在 Palantir 的世界里，Object Type 是表的语义升级版。

它比表多了什么？

• 主键 + 属性 + 显示配置：不仅定义字段类型，还定义"这个属性怎么展示给用户"（格式、条件着色等）
• 与底层数据解耦：Object Type 是一个逻辑抽象，底下可以是一个 Foundry Dataset、一个虚拟表、甚至一个模型输出。底层存储变了，上层不变
• 可被 AI Agent 发现：Agent 能通过 SDK 或 MCP 协议"发现"有哪些 Object Types、每个 Type 有什么属性，而不需要人工编写工具描述

对我们的启发：

很多国内项目的做法是"Java 实体类 → MyBatis → MySQL"，实体定义散落在 Java 代码里，AI 系统无法感知。如果要让 Agent 理解你的业务实体，需要一个 独立于代码实现的实体类型注册表，能被 AI 系统以元数据的形式发现和消费。

---

2.2 Link Types：有向、有类型、有属性的关系

Link Type 定义两个 Object Type 之间的关系。

关键设计点：

• 有方向：员工 → 隶属于 → 部门（不是双向的"有关系"）
• 有类型名：不是笼统的"关联"，而是具体的"隶属于"“维护”“依赖于”
• 可携带属性：关系本身可以有属性（比如"设备A manifests_as 故障现象B"这条关系上，可以挂概率值 0.7）
• Schema 级别定义：先定义"员工-公司"的 Link Type，再实例化具体的链接

对我们的启发：

很多项目用知识图谱时，关系类型设计得太粗（只有"相关"“包含”"属于"三种），导致图遍历没有语义区分度。Palantir 的做法暗示：关系类型应该是本体设计中投入最多思考的部分，因为它决定了 Agent 能做什么样的推理路径。

一个好的关系类型设计应该满足：

1. Agent 看到关系名就知道沿着它走能得到什么
2. 不同关系类型之间有明确的语义边界
3. 关系属性能携带业务决策所需的辅助信息（概率、优先级、区分性问题等）

---

2.3 Action Types：最被低估的一环

这是 Palantir Ontology 与传统知识图谱最根本的差异。

Action Type 定义了"对本体中的对象可以执行哪些受治理的操作"。每个 Action Type 包含：

• Parameters（参数）：这个操作需要什么输入（类型、是否必填、默认值、下拉选项来源）
• Rules（规则）：执行这个操作时要做什么（创建对象、修改属性、添加/删除链接）
• Submission Criteria（提交条件）：什么条件下允许执行（前置校验）
• Side Effects（副作用）：执行后触发什么（通知、审计日志、下游 Pipeline、外部系统调用）
• 权限控制：谁能执行这个 Action

为什么这很重要？

因为在企业环境中，AI Agent 不能只是"回答问题"，它需要"做事"。但"做事"意味着对业务状态的改变，必须是受控的。Action Types 本质上是一套 操作契约（Operation Contract）：

1. Agent 可以通过元数据发现"在这个场景下我能做什么"
2. 参数 Schema 告诉 Agent “做这件事需要提供什么信息”
3. 提交条件防止 Agent 在不满足前置条件时执行操作
4. 副作用确保操作的后果是可预期的（通知该通知的人、记录该记录的日志）
5. 权限控制确保 Agent 不越权

对我们的启发：

国内大多数 AI 项目（包括 LangChain Agent）的工具定义是 函数签名 + 一段自然语言描述。这够 LLM 调用，但不够企业治理。缺失的部分：

• 没有统一的操作注册表（工具散落在各个 Python 模块里）
• 没有提交条件（Agent 什么时候"不该"调用某个工具？）
• 没有副作用声明（调用完会触发什么？对其他系统有什么影响？）
• 没有操作级别的权限（谁能让 Agent 执行"创建工单"？谁只能让它"查询设备信息"？）

如果你的 Agent 要在生产环境中真正"做事"（不只是聊天），Action Types 的设计是迟早要补的课。

---

2.4 Functions：可注册的计算逻辑

Function 是在 Foundry 的受治理执行环境中运行的服务端代码。它可以读取属性、遍历链接、做计算、触发编辑。

与普通后端函数的区别：

• 注册到本体：不是散落在某个服务里的 API，而是本体层面的"已注册能力"
• 可被发现：其他应用、Agent、工作流可以通过 SDK 知道"这个本体上有哪些 Functions 可用"
• 类型安全：输入输出都基于 Object Types 定义，编译器能检查

对我们的启发：

这与 MCP（Model Context Protocol）的工具注册机制高度类似。MCP 让工具可被 Agent 发现和调用——这其实就是 Function 原语的开放标准版本。如果你的项目已经接了 MCP，某种意义上你已经在做 Palantir Functions 做的事了，只是没有和本体的实体/关系定义绑定在一起。

进一步的启发：把 Function 和 Object Type 关联起来（“这个函数操作的是哪种实体”），能让 Agent 的工具选择更精准——不是从几十个工具里盲选，而是先确定当前操作的实体类型，再看这个类型上注册了哪些 Functions。

---

2.5 Interfaces：多态的力量

Interface 定义了一组 Object Types 的公共"形状"。如果多个 Object Types 都实现了同一个 Interface，上层应用可以统一操作它们。

举例：

假设你有"离心泵"“电动机”"减速机"三种设备类型，它们的属性不同（泵有流量、电机有功率、减速机有传动比）。但如果定义一个 Diagnosable Interface（包含 name、status、last_maintenance_date），诊断 Agent 就可以用一套逻辑处理所有可诊断设备，无需为每种设备写不同的处理代码。

对我们的启发：

多数国内项目在扩展设备类型时，做法是"为每种设备复制一套代码"。如果在本体层面有 Interface 概念，Agent 的推理逻辑就可以写成"面向接口"的——只要实体实现了某个接口，通用的诊断/分析/报告逻辑就能自动适配。

---

三、Palantir 的设计哲学总结

从五原语的设计中，可以提炼出三条核心哲学：

3.1 “本体建模决策，而非数据”

Palantir 反复强调：本体不是数据字典，不是 ER 图。它建模的是 企业的决策结构——谁（Object）在什么关系（Link）下，可以做什么（Action），用什么逻辑（Function）。

这意味着本体设计的起点不是"我有哪些数据表"，而是"我的业务决策链路是什么"。

3.2 “治理内建，而非外挂”

权限、审计、校验不是事后加的中间件，而是本体定义的一部分。Action Type 自带提交条件和权限配置；Function 运行在受治理的沙箱中；Object 有属性级别的安全策略。

对比国内的常见做法：先写业务逻辑，再加权限拦截器，再补审计日志。这种后补式治理很容易有遗漏。

3.3 “一次定义，多端消费”

本体定义一次之后，Workshop（低代码应用）、OSDK（类型安全 SDK）、AIP Logic（LLM 编排）、MCP（外部 Agent）都可以基于同一套定义工作。不存在"前端一套实体定义、后端一套、AI 一套"的不一致问题。

---

四、Palantir 的局限性

客观地说，Palantir 的方案也有明显的短板：

4.1 强平台锁定

本体活在 Foundry 里，无法导出到其他平台运行。你用了 Palantir，就绑定了 Palantir。对于国内企业（尤其是有自主可控要求的），这基本是不可接受的。

4.2 数据必须导入，不能联邦查询

Palantir 的 Object 存储在专有的索引层中，底层数据需要通过 Pipeline 导入。不能像 Virtual Graph 那样直接查询外部数据库。这增加了 ETL 负担和数据新鲜度延迟。

4.3 不支持跨本体链接

如果一个企业有多个业务域、各自有自己的本体，它们之间无法直接建立关系。这限制了联邦架构的适用性。

4.4 学习曲线陡峭

Object Types、Link Types、Action Types、Functions、Interfaces、Roles、Workshop、OSDK、AIP Logic、Ontology MCP……概念繁多，团队通常需要 Palantir 的工程师驻场辅导。

---

五、对国内企业 AI 架构的借鉴建议

你不需要用 Palantir，但可以借鉴它的设计思路：

5.1 分层建设，不要一步到位

第一阶段：Object Types + Link Types（语义层）
   → 用 Neo4j / Nebula Graph 承载
   → 让 Agent 能做结构化推理

第二阶段：Action Types（操作层）
   → 定义操作注册表（参数 Schema + 权限 + 副作用）
   → 让 Agent 能受控地"做事"

第三阶段：Functions + Interfaces（逻辑层）
   → 通过 MCP 暴露可发现的工具
   → 用 Interface 做多设备/多场景的统一抽象

5.2 用开源技术栈复刻核心能力

Palantir 能力	开源替代
Object + Link	Neo4j Property Graph / Nebula Graph
Action Types	自定义 JSON Schema 注册表 + FastAPI 路由 + 权限中间件
Functions	MCP Server 工具注册
Interfaces	Python Protocol / TypeScript Interface + 类型注册
索引层	Milvus（向量）+ Neo4j（图）+ MySQL（结构化）
安全策略	RBAC/ABAC + 操作审计日志

5.3 让本体可被 Agent 发现

不管用什么技术实现，核心原则是：Agent 在运行时能通过元数据 API 知道"当前上下文下有哪些实体类型、哪些关系类型、哪些可执行操作"。这是 Agent 自主决策的前提。

---

六、总结

Palantir Ontology 的五原语设计，核心洞见是：

企业 AI 系统需要的不只是一个知识图谱（理解世界），还需要一个操作注册表（改变世界），两者要在同一个治理框架下统一管理。

这个洞见对任何做企业级 AI Agent 的团队都有参考价值，不管你用不用 Palantir。

语义层（Object + Link）回答"是什么"。
动力学层（Action + Function）回答"能做什么"。
Interface 回答"怎么统一地做"。

三者缺一，Agent 就不完整：

• 没有语义层 → Agent 不理解业务
• 没有动力学层 → Agent 只能聊天，不能做事
• 没有 Interface → Agent 的能力不可泛化

当你下次启动一个企业 AI 项目时，建议先问自己三个问题：

1. 我的 Agent 能发现这个领域有哪些实体和关系吗？
2. 我的 Agent 知道它在当前场景下能执行哪些操作吗？
3. 这些操作的执行是受控的、可审计的、有权限边界的吗？

如果三个答案都是"否"，那么你需要的不是更大的模型，而是一层 Ontology。

---

参考来源（内容均基于公开信息重新组织表述）：

• Palantir Foundry Documentation: Ontology Overview, Action Types, Object Types
• Palantir Blog (2025): “Connecting AI to Decisions with the Palantir Ontology”
• Palantir Blog (2025): “Connecting Agents to Decisions”
• PuppyGraph Blog (2026): “Palantir Ontology: Architecture & Benefits”
• Forrester (2026): “Why Semantics, Ontologies, And Knowledge Graphs Matter For Agentic AI”
• Forrester (2026): “Combine Semantics, Ontology, And Knowledge Graphs For AI-Ready Data”