AI会聊天,为什么还办不好事?读懂Palantir的关键一层:Ontology,即本体

临界点AI｜一文读懂Palantir 第03篇

01｜有了大模型，为什么还需要Ontology？

让大模型读完一份设备维护手册，再写一份维修建议，已经是一项容易理解的应用。把要求向前推一步：“找到这台设备，核对故障，安排有资格的人，申请合适的备件，完成工单。”

原本流畅的对话，开始碰到一连串具体问题。

台账里的设备编号，与维修系统里的编号对不上。库存显示有货，却已经被另一项工作预留。某位人员具备维修资格，今天却没有对应的操作权限。工单显示完成，设备仍在等待复核。

模型可以解释这些词语，系统还要确认它们分别指向什么。

设想一个舰艇装备保障部门正在处理设备异常。AI找到相似的历史记录，提出了合理建议。负责人批准后，软件还要生成有效工单，把任务交给具体人员，核对备件和资料，并在处理后记录结果。

每一步都涉及业务对象、当前状态、责任与授权。

在复杂组织中，AI进入工作流程，需要一套可以查询、可以操作、能够持续更新的业务世界。 大模型的语言能力进入这个世界后，才有机会与真实工作衔接。

Palantir把Ontology放在公开架构的中心位置。这个词通常译为“本体”。在本文讨论的产品语境中，它组织业务对象及其关系，并将逻辑、动作和安全要求接入同一套系统。

我们可以沿着一次维护任务，理解这套结构究竟解决了哪些问题。

“核心”是本篇基于公开技术资料形成的判断：随着应用和模型变化，一套共同的业务模型有机会持续被复用。要评估这种价值，需要看清它怎样运行，也需要算清背后的实施与维护成本。

前两篇已经介绍公司与产品分工。本篇向下深入一层，关注应用共同使用的对象、规则和操作机制。这套思路同样可以用来分析工厂维修、航空保障、医院资源管理和企业供应链。

图1｜语言模型通过工具使用业务对象，查询、计算、审核和操作共同构成一条可检查的业务路径。

知识卡片1｜一句话理解Ontology

可以把Ontology理解为一套可运行的业务对象体系。设备、人员和工单分别有明确身份与属性，关系说明它们怎样协作，规则帮助判断条件，动作负责受控修改。例如，查询设备甲可以找到关联工单，再按权限提交维护安排。团队还需要配置数据映射、业务规则与更新机制，才能让这套模型持续反映实际工作。

02｜数据放在一起，业务为什么仍然连不起来？

某组织管理一批舰艇与配套设备。装备台账保存资产身份和型号，维修系统保存故障与处理经过，库存系统保存部件，人员系统管理资格，任务系统负责安排，技术资料库保留维护手册。

六类数据来自不同团队，也有不同的更新节奏。

在这个假设场景中，同一台设备在台账中使用A100，在维修系统中使用EQ100。库存通过设备型号寻找适配部件，人员通过资格类别与维护任务关联。

把这些表搬进一个仓库，软件仍然需要知道：两条编号为何对应同一台实物，哪些关联依据可靠。

第一项工作是建立稳定身份。设备的名称可以改，位置可以变，型号可能被补充，业务记录仍需指向同一个受管理的实体。工程团队需要维护源系统标识与统一对象标识的对应关系，明确匹配依据、冲突处理办法及责任人。

第二项工作是对齐字段含义。维修系统的“完成”可能指人员提交了处理记录，设备管理的“正常”可能要求通过检验。库存的账面数量、已预留数量与可领取数量又是不同概念。

它们分别服务于不同问题，建模时需要保留各自的业务口径。

第三项工作是确定数据来自哪里、何时有效。设备更换部件后，旧部件的历史要留在旧身份上；新的装配关系需要生效时间。出现两份相互冲突的状态时，应当保留来源和待核实信息，再按负责部门确认的规则处理。

这些决定直接影响上层应用。若系统把整机与可拆换部件合成一个对象，后续追踪部件维修履历就会困难。若把同一设备按部门复制成多个对象，库存页面和维修页面又会继续使用各自的身份体系。

Palantir的建模指南建议围绕真实业务实体设计对象，让跨团队人员共同参与，并为属性与关系写清含义。 数据连接器承担接入工作，业务身份与字段口径则需要领域知识和治理过程。

从数据走向业务对象，可以沿一条明确的路径检查：先认清实体，再映射属性，建立关系，补上状态、来源和权限。对象模型的质量，取决于这些具体决定能否经受真实业务问题的检验。

图2｜同一设备的不同标识经过映射与校验，连接到统一对象；冲突记录进入核实流程。

03｜Ontology究竟组织了哪些东西？

理解Ontology，可以先抓住七个概念：对象类型、对象实例、属性、关系类型、具体关系、动作类型与函数。它们分别回答“有什么”“具体是谁”“怎样描述”“如何关联”“可以做什么”和“怎样计算”。

对象类型，Object Type，定义一类实体或事件的结构。 “设备”类型可以规定标识、型号、状态和所属位置。

“设备甲”则是一个对象实例，Object Instance，对应具体的一台设备。舰艇、人员、故障事件和维修工单，也可以分别建立类型。

属性，Property，用来描述对象。字段需要明确数据类型和业务含义：故障时间如何记录，状态允许哪些值，维护资格怎样表达。

型号这种长期属性、传感器的连续观测和工单处理事件，变化节奏不同，适合按实际查询需要分别组织。

知识卡片2｜类型与实例怎样区分？

对象类型像一张规定填写内容的信息卡模板，实例是具体填好的一张卡。“设备”定义标识、型号和状态；“设备甲”“设备乙”各自拥有这些属性的实际值。按“状态为待检”筛选得到的对象集合，还会随数据更新而变化。类型定义、具体事实与查询集合分别管理，应用才能准确使用它们。

图3｜类型定义共同结构，实例保存具体事实；实例之间的业务关系可以继续被查询和使用。

关系类型，Link Type，规定两类对象怎样关联；具体关系，Link，对应两个实际对象之间的一次连接。例如，“工单关联设备”是关系定义，“工单甲关联设备甲”是一项事实。

Palantir文档说明，一个关系类型具有可从两端遍历的两个侧面。

从设备查相关工单，从工单反查设备，可以使用同一个关系类型的两侧。图中箭头用来标明业务语义与阅读方向。业务是否允许一张工单关联多台设备、一个任务申请多种备件，还要根据真实的数量关系设计。

有些关联需要保存额外信息。人员何时开始负责某项任务，何时结束，责任范围是什么？可以把“分配记录”建成独立对象，再让它关联工单与人员。

时间和职责成为这项记录的属性，后续查询就能分别还原当前安排与历史安排。

知识卡片3｜关系类型与具体关系

“工单关联设备”描述一种关系；“工单甲关联设备甲”描述一次具体连接。关系类型还要考虑数量关系与两端名称，方便从不同对象出发查询。需要保存分配期间、职责等信息时，可以建立独立的分配记录对象。这样，每个属性都有明确归属，人员调整后也能保留之前的工作安排。

动作类型，Action Type，定义一组可提交的业务修改。创建工单、分配人员、记录处理结果，都可以围绕业务目的设计。

函数，Function，则承载可执行逻辑，例如读取设备属性、沿关系查工单、计算符合条件的候选人员。

当不同对象类型共享一组特征时，还可以使用Interface，即接口，表达共同能力。例如多类设备都具有维护状态，应用可以围绕共同定义组织处理。

具体抽象程度要服务于实际复用，过深的继承层次会增加理解和变更成本。

这些概念合在一起，形成一套共同语言。维修人员看到的是设备与工单，程序调用的是明确的类型和接口，AI工具获得的是经过选择的对象与操作。共同定义帮助各方围绕同一项工作进行沟通。

图4｜沿设备、故障、工单和资源之间的关系，可以追查一项维护工作需要哪些信息与条件。

04｜Data、Logic、Action、Security怎样一起工作？

Palantir的Ontology系统说明将数据、逻辑、动作和安全列为四个相互结合的维度。 用维护场景理解，这四者分别承担业务事实、处理方法、状态修改和访问约束，缺少任何一项，流程都会出现断点。

Data先回答当前知道什么。设备甲属于哪艘舰艇，最近有哪些异常，关联工单处于什么状态，哪些维护资料适用，这些信息通过对象、属性与关系提供。数据还需要保留来源和有效时间，方便使用者判断它能支撑哪项决定。

Logic回答怎样处理这些事实。库存计算可以扣除已预留部分，资格检查可以筛选候选人员，模型可以辅助识别异常模式，大模型可以归纳维修经过。

不同工具产出的结果，需要有明确类型和适用条件，才能被下一步可靠使用。

例如，本篇设定“资格有效且备件可用”作为提交维护安排的条件。人员资格来自业务记录，可用备件由库存口径计算，规则函数返回条件是否满足。维护优先级还可以加入业务人员确认的排序原则。

每条规则都要说明输入、版本与负责人。

Action接着回答可以怎样改变业务状态。负责人批准一项维护安排后，系统按定义创建工单、关联设备、分配人员或修改进度。应用围绕同一个动作定义提交请求，可以减少不同页面各自实现一套修改逻辑的重复工作。

Security贯穿上述过程。谁可以看某类设备，谁能读人员信息，哪个身份可以调用计算，什么角色能够批准工单，这些都是独立的授权问题。

Palantir将模型定义资源的权限，与对象和关系数据的权限分层管理。

一个具体例子是：维护人员能够查看自己负责的设备，仓储人员能够确认备件，审批人员能够批准安排。AI助手使用被配置的身份与工具范围，参与同一套权限检查。能够读到数据，与能够提交某项修改，各有自己的条件。

最后还要留下可追溯记录。某项建议用了什么证据，谁批准，哪个动作成功，后续状态是什么，分别需要对应的观测与记录机制。

官方Action log面向成功提交的动作；全量对象编辑历史和失败调用，还需使用相应记录能力。

当四者共同工作时，维护建议可以沿着事实、规则、审核、修改与回读继续推进。系统中每个“完成”都有具体对象和判定条件，团队才能找到未完成的环节。

图5｜数据提供事实，逻辑检查条件，动作修改状态，安全分别约束读取、调用和提交。

05｜一次Action，怎样把建议带进工作流程？

现在给设备甲建立一张维修工单。输入参数可以包括设备、故障事件、维护内容与拟定责任人。创建工单这个动作，把这些参数组织成一次业务请求，随后依据规则生成对象属性和必要关联。

Action Type规定允许发生的一组修改；一次Action则携带具体参数执行这组修改。

Palantir将Action中的Ontology编辑组织为事务，支持在一次动作中修改相关对象与关系。 业务团队仍然需要明确每个动作应当改变哪些事实。

在本篇流程里，工单创建后处于待处理状态。责任人补充资料并提交申请，工单进入待审批；审批通过后进入处理中；维护完成并通过工单验收后，进入已完成。需要补充材料时，按流程退回前一步。

这些状态构成一个业务状态机。状态机要定义允许的迁移及条件：待审批的工单由谁批准，处理中能否转派，已完成后发现问题怎样返工。状态名称只有与规则相连，才会成为可以执行的流程。

提交条件，Submission Criteria，用来判断当前请求是否允许提交。官方文档说明，条件可以组合用户、参数、对象和关联等信息。

在此场景中，可以检查责任人资格、工单当前状态和必填资料，并把失败原因返回给操作者。

并发请求还会带来另一类问题。两名负责人先后读到同一份可用库存，各自批准一项任务，提交时库存可能已经改变。团队需要按实际并发需求选择适当的隔离与校验方式，并在关键资源的权威系统中完成确认。

遇到冲突时，返回需要重新检查的对象，比沿用先前查询结果更容易保持流程可靠。

知识卡片4｜什么是Action？

Action把一个业务意图组织成受控修改。例如“批准工单”需要指定工单及审批意见，检查操作者权限、当前状态和提交条件，再按定义修改进度与相关记录。动作类型规定这项操作的结构，具体动作执行一次请求。工单完成、设备复核和外部同步可以分别保留状态，让应用准确显示后续工作。

工单完成后，设备状态也要按照自己的规则处理。维修记录已提交，可以先让设备进入待复核；检验人员确认结果后，再更新相应设备状态。这种设计保留了流程进展与现场确认之间的区别。

向外部维修系统同步，还要配置具体集成。Palantir的Webhook文档说明，可以把外部请求配置为写回或副作用。

写回Webhook先请求外部系统，失败后停止后续对象编辑；副作用Webhook在对象编辑后执行。

两种方式都有需要处理的失败情形。外部请求成功后，Ontology编辑仍可能失败；对象修改成功后，通知也可能尚未送达。团队需要保存回执、同步状态和请求标识，明确重试与人工处理办法。

官方的一致性文档将Action原子性的范围限定在Ontology编辑，外部副作用具有独立行为。

对维修团队而言，工单受理、库存确认与人员接单，最好各有可检查的记录，避免用一条笼统的成功提示代替整项工作。

应用最后重新查询相关对象，确认状态与记录是否符合预期。这样，人员、页面和AI助手可以共同使用一个流程定义，也能在出现问题时定位到具体失败步骤。

图6｜工单按条件迁移状态，设备另行复核；外部系统同步依赖已配置的接口、回执和失败处理。

06｜Language、Engine、Toolchain各管什么？

对象、关系和动作已经清楚，接下来还要回答：这些定义放在哪里，怎样执行，开发者怎样使用？

Palantir将Ontology系统的职责概念性分为Language、Engine和Toolchain。 三者从表达、运行和开发使用三个角度描述同一套系统。

Ontology Language负责表达模型。设备有哪些属性，工单怎样关联设备，批准工单需要哪些参数，动作怎样调用逻辑，都需要能被软件解释的定义。

这里的Language涵盖模型表达能力，具体工作可以通过管理界面及开发方式完成。

可以把它想成维修业务的共同说明书。说明书中要有名词，也要有操作：名词规定正在管理什么，操作规定可以怎样修改。模型定义清楚，应用才能生成相应查询、界面和请求。

Ontology Engine负责让定义运行起来。官方架构列出的能力包括查询、状态订阅、事务更新以及批量和流式处理等。

设备甲的属性怎样被读取，关联工单怎样被找到，一次修改怎样形成可用状态，都涉及运行服务。

具体实现还可以继续查看对象后端与索引文档。索引把数据组织成便于查询的结构，更新路径则把来源变化或编辑反映到对象中。 对象模型、索引和查询服务共同协作，查询表现取决于数据规模、关系结构及使用方式。

Ontology Toolchain提供构建与使用这些能力的工具。

Ontology Manager可以创建类型、定义动作、连接数据及检查更新情况；应用工具和开发者工具链帮助团队围绕模型开发业务页面与服务。

Ontology SDK，简称OSDK，则让开发者在自己的开发环境中使用相关对象。官方文档说明，SDK根据应用涉及的Ontology子集生成类型与函数，并结合应用访问范围和用户权限约束数据访问。

例如，维护页面可以使用设备类型查询待检对象，再调用创建工单的动作。库存页面使用同一工单定义，显示所需备件。开发者可以把精力更多放在任务体验上，同时仍需处理模型版本、错误反馈与界面状态。

三类职责分清后，就能更准确地诊断问题：字段含义错误要改模型，更新迟缓要查运行链路，应用调用失败要检查接口与授权。不同问题有不同的处理位置。

图7｜Language表达模型，Engine支撑运行，Toolchain帮助开发和管理，三者共同服务于业务应用。

07｜现实发生变化，对象怎样跟着更新？

设备上午出现异常，现场人员稍后补录检查记录，库存系统又在下午更新预留数量。Ontology中的对象要反映这些变化，需要一条持续工作的数据链路。模型定义决定信息怎样组织，更新机制决定应用何时能读到它。

这条链路从数据接入开始。Palantir的Data Connection用于同步外部系统数据，并支持通过出站连接配置写回与数据导出。

不同来源有不同的连接条件，团队需要分别确定凭据、访问范围、同步计划和错误处理。

批量接入适合按周期收集一批记录；增量处理关注新增和变更部分；流式处理持续接收事件。变更数据捕获，CDC，可以依据受支持来源的变更信息进行复制。某个来源采用哪条路径，取决于连接器、源系统条件和实际配置。

接入后，原始字段还要经过转换、身份关联和质量检查。源记录中的设备编号映射到设备甲，状态代码转成确定含义，时间采用明确格式。身份有冲突、字段缺失或状态值超出约定时，可以先进入待核实流程。

随后，数据按对象属性与关系定义进入相应更新路径。官方索引文档分别讨论批量与流式索引方式，也列出直接数据源等低延迟写入路径。 上层查询能够看到什么，要结合数据源与对象存储的具体工作方式判断。

在维护场景中，来源记录把设备甲从正常改为待检。应用需要显示最新可用状态，同时让使用者知道观测发生时间与平台接收时间。现场事件发生得早，补录到达得晚，简单按接收顺序排列可能错过事件的实际先后。

一次同步成功，还要继续检查同步了什么。源系统可能没有新记录，某个字段可能长期为空，某条关系可能由于标识变化断开。数据血缘帮助追查来源与处理步骤，质量检查帮助识别缺失与异常，两者共同支撑运行维护。

人工编辑与来源更新之间也需要明确权威。型号通常由台账维护，审批意见由授权人员填写，当前检验状态由规定流程确认。字段负责人及覆盖规则清楚，后续同步才有稳定依据。模型修改时，还应检查哪些应用依赖旧字段。

更新速度最终要与业务需要匹配。月度统计可以接受周期性更新，现场安排则可能要求更短延迟和明确的过期提示。网络、源系统、转换、索引与应用刷新都会影响结果。把延迟测出来，才能选择合适的工程投入。

图8｜来源变化经过接入、映射、校验和索引进入对象；更新时间与数据来源共同决定状态的使用条件。

08｜Ontology与AIP结合，AI得到了什么？

一个维护助手通常需要两类信息。第一类是手册、维修说明与历史报告，适合按内容检索；第二类是某台设备的当前状态、未关闭工单和可用资源，适合按身份、属性和关系查询。两类信息回答不同的问题。

检索增强生成，RAG，会先寻找与问题有关的外部资料，再交给模型组织回答。对于“这种故障一般怎样检查”，维护手册中的相关段落很有用。对于“设备甲现在有哪些未完成工作”，系统还要定位设备甲及其关联记录。

工具调用让模型获得查询或计算能力。Agent进一步围绕任务组织多个步骤，决定先查对象、再读资料，还是请求补充信息。开发者要为工具定义输入、输出及允许的范围，模型才能使用可识别的接口。

Palantir的AIP架构将模型接入、上下文工程、Ontology、工具服务、智能体开发、评估与观测等能力放在共同体系中。

Ontology为其中的业务上下文和操作提供结构，模型则参与解释问题、选择工具与形成建议。

例如，用户问“请查看设备甲近期维护情况，并提出后续安排”。助手先查询设备对象，沿关系找到故障与工单，再检索适用手册。

需要核对人员或备件时，调用相应对象查询或规则函数，最后把证据与待确认条件一起交给负责人。

官方Chatbot Studio工具文档列出对象查询、函数和Action等工具，对象查询可以进行筛选、聚合和关系遍历，Action可以配置为自动执行或经用户确认。

本篇维护助手采用人员审核后提交动作的方式。

这套设计把“查询”“建议”和“执行”分成可观测步骤。模型推荐维护人员时，函数检查资格；负责人批准时，动作再次检查状态与提交条件；完成后，助手重新读取工单，说明下一步由谁处理。

模型输出与业务记录之间由明确接口衔接。

知识卡片5｜知识图谱、RAG与Ontology怎样协同？

知识图谱擅长组织实体和关系，RAG把检索到的资料送入模型上下文，Palantir Ontology将业务对象进一步接入逻辑、动作与授权机制。实际系统可以同时使用三者：从对象定位设备，沿关系找到适用文档，再检索具体内容。执行维护安排时，还要调用配置好的动作与业务接口。

权限也必须进入每一步。助手的可读范围应随调用身份和工具配置受到约束，检索材料中的内容也要按来源权限处理。工具返回数据后，应用还需考虑它怎样展示、保存与流转，避免在后续环节扩大原定访问范围。

知识卡片6｜为什么AI也需要权限？

AI调用工具时，实际使用的是某个执行身份及其授权范围。查询设备、读取人员资料、计算方案和批准工单可以分别配置权限。某个人有权查看一份记录，也可能需要另一名负责人批准修改。让这些约束在服务端生效，并记录调用与结果，团队才能检查一次操作由谁发起、依据什么完成。

评估则帮助团队发现工作链中的错误。测试可以检查对象是否找对、资料是否适用、条件不足时是否停下、未经授权是否被拒绝，以及修改后能否读到预期状态。每项检查对应实际业务结果，便于比较模型与工具配置的变化。

Palantir的Ontology增强生成文档也讨论了多种上下文检索方法，强调根据数据特点组合使用。 对建设者而言，值得研究的是怎样为当前问题选到合适证据，并让后续操作保持可控。

图9｜文档证据与结构化状态共同进入模型，建议经人员审核后提交动作，再回读结果。

09｜把一艘舰艇放进Ontology，会发生什么？

把前面的概念合起来，设想一艘舰艇的装备保障场景。舰艇甲配备多种设备，某台辅助设备的传感记录出现异常，需要维护部门检查。我们关心设备身份、维修、资源安排与状态确认，整条路径围绕一次普通维护展开。

模型首先建立十类主要对象：舰艇、设备、传感器、维护人员、故障事件、维修工单、备件、仓库、维护任务和技术文档。维护记录还可以作为独立事件保存。

对象划分依据是它们各自具有身份、状态、生命周期或被查询的价值。

舰艇与设备通过配备关系连接，设备与传感器通过对应测点关联。传感器发生更换时，设备身份保持稳定，测点对应关系按实际记录调整。这样，团队可以分别追踪设备履历和某个传感器的观测历史。

异常信息进入后，系统按来源和时间保存记录，经校验后关联到设备甲。故障事件记录现象与检查结果，维修工单记录办理过程，两者可以通过关系连接。持续的故障可能对应多次处理，关系模型要能容纳复查和返工。

负责人打开设备甲，就能沿着关系找到近期维护记录、当前工单与适用技术文档。文档还应保存版本或适用范围，使人员可以判断手册是否匹配当前设备配置。一次型号调整，可能影响文档关联和备件适配规则。

接下来需要安排任务。人员对象保存岗位、资格与可用安排，任务对象保存工作内容和计划信息。规则先筛选满足资格与授权要求的候选人，再把时间冲突交给相应排班逻辑或负责人处理。

人员与任务之间的分配记录保留调整经过。

备件也有自己的状态。库存记录可以区分账面、预留与待检验部分，维护任务通过需求记录关联具体部件。仓库对象说明存放位置与管理范围，领用是否成功则需要有效的仓储业务记录。

例如，设备甲待检，工单甲待审批，备件待确认，维护人员资格有效。此时系统已经知道不少事实，下一步仍需确认备件与审批。界面可以明确显示待办事项，AI也能据此组织建议，告诉负责人当前安排缺少哪项条件。

负责人批准后，受控动作修改工单进度并建立任务关联。若仓储系统承担最终领用，集成请求还要获取该系统回执。工单、任务和同步状态分别更新，后续应用才能显示任务已安排、备件已确认或同步仍在等待。

维护人员处理完成后提交结果，系统增加维护记录，工单按验收规则结束。设备是否恢复可用，由对应复核流程确认。检验结果还可以成为后续分析输入，帮助团队比较原建议、实际处理和最终状态之间的差异。

AI在其中承担证据组织与辅助分析。它可以汇总历史异常，指出尚未完成的工单，检索适用资料，生成待审核建议。业务动作沿既定接口提交，所需权限与现场确认仍由相应机制处理。

一段时间后，管理人员可以按同一模型统计等待原因：哪些任务卡在资料，哪些等待备件，哪些需要资格人员，哪些处在外部同步阶段。这些统计依赖完整、准确的状态记录，团队可以据此改进流程。

这套结构的系统工程意义，在于把分散问题组织成可以协作的对象与过程。数据团队维护身份和来源，业务人员确定口径与责任，开发者实现操作和反馈。各方围绕共同模型持续修正，应用才能随着实际工作演进。

图10｜舰艇装备保障的假设场景，从异常记录、关系查询走到任务安排、资源协调和状态复核。

10｜它在Foundry、AIP、Apollo与Gotham之间是什么位置？

第二篇介绍四个产品时，容易记住各自名称。进入技术架构后，更有价值的问题是：哪些能力共同使用，哪些职责分别承担？

Palantir公开的标准架构将AIP、Foundry和Apollo描述为相互集成的平台。

Foundry提供数据管理、逻辑编写、Ontology开发、分析和工作流等基础能力。AIP聚焦生成式AI接入、智能体与自动化开发及评估。Apollo承担软件持续交付和相关服务环境管理。

Ontology位于业务模型与运行能力相结合的位置。

这可以解释应用复用。维修页面、库存协同页面和AI助手，都可能使用设备与工单对象。模型更新时，团队能够集中检查共同定义和依赖；新应用也可以沿用已有接口，减少重新解释数据含义的工作。

Gotham承担领域应用与工具的角色。官方架构文档明确提到，Gotham的核心多模态应用与工具使用由Foundry管理的Ontology。

具体客户的产品组合、版本、接入条件与交付范围，需要按实际部署说明确认。

架构中的部署支撑与业务流也要分开。Apollo管理服务交付，工单动作处理业务状态。应用升级可能改变接口或界面行为，业务记录则有自己的生命周期。两类变化都需要版本与验证，分别由对应机制管理。

围绕同一业务模型工作，还可以让模型与工具接入更有连续性。即使更换某个语言模型，设备身份、工单定义和审批规则仍可继续使用。迁移工作需要重新评估工具调用与结果表现，但已有业务知识可以成为可复用资产。

Ontology的技术地位可以从两个角度观察：它为上层应用提供共同对象与动作，也持续依赖底层数据、逻辑和工作流服务。共同模型与基础服务共同维护，才能支撑长期运行。

图11｜Foundry与AIP共同使用Ontology能力，Apollo支撑服务交付，Gotham提供相应领域应用。

11｜价值在哪里，建设的困难又在哪里？

评价Ontology，需要把它放回已有技术体系。关系数据库擅长持久化结构化记录、约束和事务；知识图谱以实体和关系组织信息，适合关联查询；语义层为业务指标、名称与口径提供共同解释。

它们都能成为大型业务系统的重要组成。

数字孪生关注现实对象及其状态的数字表达，工程实现可以结合几何、物理模型和运行数据。RAG知识库关注怎样找到适用资料并进入模型上下文。

Palantir Ontology把业务模型与可执行逻辑、动作、安全及工具链组织进一个产品体系。

这些技术存在重叠，也可以组合使用。成熟数据库能够支撑复杂业务应用，知识图谱可以连接规则与工具，其他平台也能实现统一对象和授权。选型时应比较实际功能、现有基础、团队能力与维护成本。

本篇对Ontology价值的判断，主要来自共同模型的复用。当多个应用需要同一套设备身份、状态定义和审批操作时，集中维护能够减少重复解释与实现。

收益大小要看应用数量、跨部门协作程度以及模型是否确实被使用。

建设成本首先出现在业务概念上。“设备可用”由谁确认，“任务完成”需要哪些记录，“库存可用”扣除什么，都需要相关团队达成一致。分歧如果没有解决，会在属性、规则和页面中继续出现，平台很难替组织决定责任。

第二类成本来自数据与历史系统。标识映射需要维护，缺失记录要补齐，接口可能有频率和格式限制，网络中断后要恢复同步。接入完成后仍要持续监测，才能发现字段改名、来源停更及关系断开。

第三类成本来自模型演进。设备类型增加属性，维护流程调整状态，某项规则更换版本，都会影响依赖它的页面、函数与智能体。变更前应检查依赖与兼容，保留明确的迁移和回退办法。

权限也需要持续治理。人员调岗、任务结束、跨部门协作都会改变访问需求。团队应检查授权是否仍符合业务范围，并验证拒绝行为。共享业务对象越多，越需要清楚的责任人、权限设计和审计安排。

建设初期可以制作一张权限矩阵，把角色、对象范围、可读字段、可用动作和审批职责放在一起核对。让业务负责人检查实际工作，让工程师验证服务端行为，再用调岗、越权提交和资料过期等情况测试。

矩阵随着职责变化更新，能够减少只有页面按钮控制、后端规则未同步的遗漏。

第四类成本涉及应用运行。复杂关联查询、频繁状态更新和模型调用都会消耗资源。适合预计算的内容、需要即时查询的状态与适合独立处理的连续数据，应根据使用需求分别设计，持续测量延迟、失败与成本。

供应商依赖也要纳入预算。对象模型可以包含组织自己的业务知识，应用代码、动作配置和运行方式又可能依赖平台接口。团队可以提前检查数据导出、模型文档、API依赖和替代方案，让长期选择保持可评估。

一个可行的起点，是先完成边界清楚的维护流程，用真实任务验证模型。让业务人员尝试查设备、追工单、确认资源，再检查异常与权限失败。

Palantir的设计验证指南同样建议围绕具体问题，检验人员与智能体能否使用模型完成调查和决定。

只有在这些具体任务中，团队才能知道投入是否值得：信息查找有没有减少重复劳动，审批是否清楚，状态是否可信，错误能否被发现。长期价值来自持续使用和维护，而每一项改进都需要业务记录与运行证据支持。

图12｜业务建模、数据工程、动作权限和应用验证共同推进，运行反馈持续推动模型与流程演进。

12｜为什么它可能成为技术路线的核心？

回看一次完整维护，真正被反复使用的是一组共同定义：设备是谁，故障与工单怎样关联，哪些条件需要检查，谁能批准，状态怎样更新，后续如何确认。

Ontology将这些内容组织成能够被人员、应用与AI共同使用的业务体系。

这也给出了本篇标题的答案。以公开架构为依据，我认为Ontology的核心价值在于承接组织长期积累的业务模型，并让它与查询、逻辑、操作及安全机制一起运行。

模型和界面继续变化时，这些定义仍有机会被持续复用。

它的效果依赖数据质量、工程实施和组织治理。身份准确、规则清楚、权限有效、更新可靠，应用才能在共同基础上协作。建设者应当用具体任务检验每个环节，再决定扩展范围。

下一篇《什么是Ontology？一篇文章真正讲懂Palantir本体论》，将继续深入对象与关系建模、Schema、类型与实例，以及RDF、OWL等相关知识，把本篇的运行机制进一步连接到建模方法。