第二篇｜讲懂 Palantir Ontology 本体论，市值翻 40 多倍的秘密

作者：谯洪敏｜零一道

导读：让 AI 参与业务，既要让它认识业务里的"名词"，也要定义它可以参与哪些"动作"。

上篇我们聊了 Palantir 的 FDE 模式，今天继续拆解它的核心技术底座——Ontology（本体论）。

很多人一听到"本体论"就头大，觉得这是哲学课的东西。别怕，咱们用一张维修工单，就能把它讲明白。

场景还原：派工这件事，AI 真的懂吗？

假设你负责一个维修团队。系统里有一张工单 W007：某台设备需要维修。你想把它派给张工，但派之前得确认几件事：

• 张工资质够不够？
• 张工那个时间段有没有空？
• 这张工单是不是还"活着"（没被其他人抢走）？
• 谁有权限点下"确认派工"这个按钮？

如果只把几张数据库表扔给 AI，它可能生成一段看起来很像样的建议。但真正执行时，问题就来了：

数据里的"人员"到底指谁？"空闲"按哪个时间段判断？派工会改动什么？谁有权提交？

Palantir 的 Ontology，就是从这组问题开始理解的。官方资料将它描述为连接数据、逻辑、行动和安全的系统。

对象和关系能够帮助我们理解其中的语义部分；执行动作及其控制机制，同样是这套系统的重要组成。[1]

先把业务世界里的"名词"讲清楚

Ontology 的第一层，是把业务世界翻译成系统能理解的"语言"。核心就三样东西：对象、属性、关系。

对象（Object）：你需要管理的业务实体

在这个教学案例中，"工单 W007"和"工程师张工"是两个具体对象。系统还可以有设备、班次和维修资质等对象，是否单独建模取决于业务需要。

属性（Property）：描述对象当前的状态和特征

• 工单可能有：故障类型、优先级、创建时间、状态（待分配/处理中/已关闭）。
• 工程师可能有：所属团队、资质等级、可用时间段。

字段的含义、数据来源和更新时间，需要与业务人员一起确认。这一步看似简单，但往往是项目最容易翻车的地方——你以为"空闲"就是没人派工，业务方理解的"空闲"是"今天没请假且不在其他现场"。

关系（Relationship）：把对象连接起来

工单关联某台设备，也可以指派给一位工程师。业务使用者因此能够顺着关系查看"这张工单涉及什么设备""谁正在处理"，而不必先理解底层表如何连接。

关系如何存储，是实现层面的选择。可以使用外键或连接表等建模方式，但不应把某一种数据库实现方式写成所有 Ontology 场景的唯一规则。

从认识对象，走到改变业务状态

看清工单和人员之后，还需要定义一次合法的派工操作。它至少要知道：目标工单是谁、候选工程师是谁、预计时间、提交者身份。

这就引出了两个容易混淆的概念：Function 与 Action。

Function：承载可复用的计算或业务逻辑

例如，根据排班和资质计算候选人，或者判断一个时间段是否有冲突。官方文档列出的用途包括应用中的查询、聚合、计算，以及为复杂变更提供逻辑支持；Function 并不只能存在于 Action 内部。

在这里的入门例子中，可以先把 Function 理解为“算一算”：计算结果与通过 Action 提交业务变更，分开处理。

Action：定义对对象、属性或关系的一次受控变更

在这个例子里，它可以是"将 W007 指派给张工"：检查输入与提交条件，更新指派关系和工单状态，并记录结果。具体如何接入外部工单系统，还需要配置相应的集成能力。

简单说，Action 是"改一改"，它会真正改变业务状态。

对派工流程，可以先用 Function 计算候选建议，再让 Action 按规则提交变更。这样，候选人推荐与真正改变业务状态的责任边界就清晰了。

AI 应该获得多大的行动空间？

在这个教学方案里，我们可以让 AI 帮助理解报修描述、归纳维修要求，或解释候选人的选择依据。但资质是否有效、排班是否冲突、工单是否已关闭，则由明确的业务逻辑和系统状态共同校验。

接下来，按照动作风险设计审批：

• 高风险操作（如跨团队、影响重要设备的派工）：可以先提交调度员确认。
• 低风险操作（规则明确的辅助操作）：可以在授权和验证充分的前提下自动执行。

这是方案设计选择，不是"所有 AI 动作必须人工点击"的固定规定。

Palantir AIP Logic 的官方文档也说明，Ontology 变更既可以自动应用，也可以暂存后交由人审阅。平台提供能力，具体系统仍需配置权限、测试逻辑、检查数据质量，并持续观察运行情况。

尤其要分清两个状态：

"模型生成了派工建议" ≠ "工单系统已经接受派工"

如果外部系统写入失败，界面应明确显示失败或待处理，不能把一段自然语言回复当成执行成功。

没有 Palantir 环境，也可以先练业务建模

拿一张纸或者一个表格，就能开始第一轮练习。

第一步：列出"工单"和"工程师"，为它们各选几个必要属性，再画出指派关系。

第二步：写下"指派工单"需要哪些输入、允许谁操作、什么情况下必须拒绝，以及成功之后应看到什么变化。

第三步：试着走一遍三种情况：

1. 张工资质合格且有空 → 正常派工
2. 张工正在处理别的任务 → 拒绝并提示
3. W007 已被另一位调度员分配 → 拒绝并提示冲突

你会很快发现，异常路径能帮助我们补齐原先遗漏的规则。

这份纸面模型还不是生产系统，但它会成为开发、沟通和测试的共同依据。之后选择数据库、API、工作流工具或模型时，每一项技术才有明确用途。

这样的业务建模练习，可以继续与原型、评估和交付连接起来。对于学习者，能够解释清楚一次动作为什么可以执行、失败后怎样处理，是一个很有价值的进步。

我翻译为中文的官网本体架构图

系列进度提醒

这是 Palantir FDE 系列三篇中的第二篇。

• 第一篇（已发）：会用AI，为什么还是做不成项目？从 Palantir 看懂 FDE
• 第二篇（本篇）：用一张工单，讲懂 Palantir Ontology
• 第三篇（已更新）：实战篇——普通人怎么学 FDE？从0到1把这套方法论用在自己的 AI 项目上

下一篇继续用这个案例，讨论一个可验证的小项目怎样推进到交付。欢迎继续阅读第三篇。

参考资料：

[1] Palantir：The Ontology system；

[2] Functions overview；

[3] Action types overview；

[4] AIP Logic overview。