"本体论"这个词指的是什么
在 Palantir 的文档里，Ontology 不是学术词汇，而是 产品的一层。概览文档这样定义：
The Ontology is an operational layer for the organization. The Ontology sits on top of
the digital assets integrated into the Palantir platform (datasets and models) and
connects them to their real-world counterparts, ranging from physical assets like
plants, equipment, and products to concepts like customer orders or financial transactions.
数据湖里有表，模型仓库里有模型。Ontology 是位于两者之上、给它们贴上"工厂""订单""交易"这类 现实名字，并定义对每个名字能做什么的那一层。文档说明投资的目的只有一句："The goal of investing in the Ontology is to facilitate better decision-making in an organization at scale."
本文只用 Palantir 官方文档（palantir.com/docs/foundry）的原句来跟随这一层的构成。文档里没有的，这里不写。
六个部件 — 语义与动力
概览文档把 Ontology 的组成分为两组：定义组织 语义（semantics） 的，和定义 动力（kinetics） 的。
Defining the semantics of your organization happens by mapping existing datasources
into objects, properties, and links in the Ontology.
The kinetics of the organization—enabling change while complying with organizational
controls and governance—are defined in the Ontology using action types and functions.
照抄核心概念文档的定义，就得到六个部件。
| 部件 | 官方定义 |
|---|---|
| 对象类型（object type） | "the schema definition of a real-world entity or event" |
| 属性（property） | "the schema definition of a characteristic of a real-world entity or event" |
| 链接类型（link type） | "the schema definition of a relationship between two object types" |
| 动作类型（action type） | "the schema definition of a set of changes or edits to objects, property values, and links that a user can take at once" |
| 函数（function） | "a piece of code-based logic that takes in input parameters and returns an output" |
| 接口（interface） | "an Ontology type that describes the shape of an object type and its capabilities" |
为熟悉数据库的人，文档还给出对应表：数据集对应对象类型，行对应对象，列对应属性，连接（join）对应链接类型。所以前三个部件（对象、属性、链接）还只是"整理得很好的模式"。Palantir 与其他数据平台分道的地方在后三个：它把 人可以采取的行动（动作） 和 用代码写的逻辑（函数） 放在与模式同一层里。
数据集变成对象的路
对象类型从哪里拿数据？对象类型概览文档给出两条路。
Objects are created and displayed in user applications by adding backing datasources
or configuring actions that create objects of an object type in Ontology Manager.
也就是 (1) 把现有数据集作为 backing datasource 挂上，或 (2) 不要数据集、只靠动作创建对象。文档举了把员工目录数据挂到 Employee 对象类型的例子，并反过来说"如果所有对象都将由动作创建，可以不带 backing datasource 创建对象类型"。
把数据集索引成对象的过程由 Object Storage v2 的 Funnel 负责。
Funnel reads data from Foundry datasources (such as datasets, restricted views, and
streaming datasources) and user edits (from Actions) and indexes these data into
object databases. Funnel also ensures that indexed data is kept up-to-date as the
underlying datasources update.
关键在于 "user edits (from Actions)" 与数据集 并列 作为输入。来自原始表的值和人在界面上改过的值进入同一个索引。那么两者冲突时谁赢？
编辑与原始数据冲突时的规则
这一部分是 Ontology 区别于"只读视图"的核心，文档明确写了规则。
the final state of an object is always determined by the user edits applied to it,
regardless of any future datasource updates for edited properties in the same object.
在默认策略下 用户编辑永远获胜。 人改过的属性，即使原始数据集之后变了也不会被覆盖。而没改过的属性照常接收原始更新（"An unedited property receives data update from the input datasource, and it is applied to the object"）。
删除不算编辑："Deletions are not considered an edit. Once a deletion is applied, the object is no longer visible regardless of datasource state." 同一键的对象若再次创建，也不会继承之前的编辑（"If the object is later recreated, it will not inherit the previous edits"）。
仅编辑属性（edit-only property）更强。即使选择替代策略（"应用最新值"），也是 "user edits will always apply regardless of the timestamp on the input datasource"。
为什么有这条规则？现场负责人把某台设备标为"已检查"，夜里原始系统又把旧状态推下来抹掉标记，Ontology 就成了没人相信的界面。编辑获胜的规则守住的是这份信任。代价是原始数据里真正变化的值可能被忽略，所以哪些属性允许编辑成为设计的核心。
动作 — 事务、校验、副作用
动作类型文档这样界定动作：
An Action in Foundry is a single transaction that changes the properties of one or
more objects, based on user-defined logic.
一个动作是对对象、属性、链接的一组变更；参数把输入标准化；提交条件检查权限。文档的例子是"校验只有人力资源部门这类有权限的员工才能执行此动作"，并在提交时包含"自动在相关对象之间创建链接的规则"。副作用（side effect）有通知和 webhook，例子是"通知旧经理和新经理这一变更"。
而这句话说明了动作为何放在 Ontology 里：
the same action logic and validations can be made available across all user-facing
applications, ensuring consistent edits.
不是每个界面各写一个"保存按钮"，而是在 Ontology 里定义一次动作，所有界面用同一套校验。规模上限也在文档里：一个动作默认可编辑 10,000 个对象，更大的值可申请开放。
函数 — 在服务器端运行的逻辑
函数文档把语言定为两种："The languages supported by functions are TypeScript and Python." 函数把 Ontology 当作一等公民。
This includes support for reading the properties of various object types, traversing
links, and flexibly making Ontology edits.
文档列出的用途有四：向 Workshop（Palantir 的应用构建器）返回对象集或值，"通过函数支持的动作表达一次更新许多对象的复杂编辑"，在派生列中显示转换后的值，为图表做聚合。执行模型是 "executed on the server side in an isolated environment"，为配合语言模型还能"逐步流式返回结果"。
接口 — 多态
接口让多个对象类型共享同一形状。文档的例子是 Facility 接口带有位置、名称等公共属性，由 Airport、Manufacturing Plant、Maintenance Hangar 实现。于是 "workflows can interact with Airport, Manufacturing Plant, and Maintenance Hangar object types, either in aggregate or independently"，新类型一实现接口就立刻进入现有工作流。接口属性 "defined locally on the interface (recommended) or using shared properties"，一个对象类型可以实现多个接口。
规模与架构 — 用数字说
Object Storage v2 文档给出的数值如下。
| 项目 | 文档数值 |
|---|---|
| 单个对象类型的索引吞吐 | "on the order of tens of billions of objects for a single object type" |
| 每个对象类型的属性上限 | 2,000 |
| 单个动作可编辑的对象数（默认） | 10,000 |
| 增量索引 | 对所有对象类型默认启用 |
| OSv1（Phonograph）退役 | 2026 年 6 月 30 日 |
v2 的设计要点是一句话："by separating the subsystems responsible for indexing and querying data, Object Storage v2 can scale horizontally more easily to meet future needs." 索引一侧与查询一侧被拆开了。
模型与 LLM 接在哪里
模型文档把在 Ontology 上运营模型的步骤写成四步：创建模型，配置直接部署（direct model deployment），"为模型发布一个简单的包装函数"，再在 Workshop 这类用户应用里用该函数做实时推理。模型的结果被定义为 "real-world concepts (properties of an object type)" — 预测值不是单独的技术产物，而是对象的属性。
LLM 一侧是 AIP。AIP Logic 的定义是 "a no-code development environment for building, testing, and releasing functions powered by LLMs"，这类函数以 "Ontology objects or text strings" 为输入，能 "return an output (objects and/or strings) or make edits to the Ontology"。也就是说 LLM 生成的逻辑最终仍以 函数 这同一个部件进入 Ontology，其编辑走与动作相同的路径。AIP 概览写道，这些工具构建 "production-ready AI-powered workflows, agents, and functions on top of the Ontology"。
给开发者的 SDK
Ontology SDK（OSDK）文档这样写支持路径："The OSDK supports npm for TypeScript, pip or Conda for Python, Maven for Java, and OpenAPI spec for any other language." 它从 Ontology 生成函数与类型，令牌 "scoped only to the ontological entities you want your application to access"。对象类型直接成为代码中的类型，因此改了 Ontology 就重新生成 SDK，成了开发流程的一部分。
以工程师的眼光再读一遍
一句话概括 Palantir Ontology："模式 + 编辑规则 + 行动定义 + 逻辑，放在同一层"。听起来陌生，其实多数内部系统都以零散的形式拥有这些：表在仓库里，保存按钮的校验在各个应用里，批处理逻辑在调度器里，预测在笔记本里。Ontology 把它们收在一处，并在那里定义"谁能以何种方式改变哪个对象"。
仅凭文档无法知道的事也记下来。编辑获胜的规则在实际运营中会引发什么冲突，2,000 个属性或 10,000 次编辑的上限会卡在哪些业务上，Funnel 的更新延迟有多大，文档里都没有。本文在官方文档所述的范围内止步。
来源
本文的引用全部来自下列 Palantir 官方文档（2026 年 9 月 11 日查阅，均确认响应 200）。
이 글의 인용은 전부 아래 팔란티어 공식 문서에서 가져왔다(2026년 9월 11일 열람, 응답 200 확인).
- Ontology overview
- Ontology core concepts
- Object types overview
- Object backend (Object Storage v2) overview
- Object edits overview
- How user edits are applied
- Action types overview
- Functions overview
- Interfaces overview
- Models in the Ontology
- AIP overview
- AIP Logic overview
- Ontology SDK overview
- Ontology Manager overview
현재 단락 (1/82)
在 Palantir 的文档里，Ontology 不是学术词汇，而是 **产品的一层**。概览文档这样定义：