2025 年，Palantir 的收入达到 44.75 亿美元，同比增长 56%。当年商业收入的增量中，超过一半来自已有客户。作为一家商业软件加服务的公司，Palantir在商业上的巨大成功，与其独特的本体方法论息息相关。本文讲从本体的角度，理解为什么Palantir能够在商业上取得如此大的成功？
美国坦帕综合医院从 2021 年开始使用 Palantir，到 2024 年，应用已从一个场景扩展到十多个。医院披露，患者安置所需的时间减少了 83%。对医院而言，软件服务于日常资源协调，其价值也应通过资源协调效率与质量的提升来衡量。
Palantir 值得借鉴的一项核心设计，是把业务对象与操作组织在同一套模型中，让人能够依据数据作出判断，并继续处理业务。 这套模型就是它称为 Ontology 的本体。以医院为例，软件既要知道哪张床可用，也要能支持为某次入住安排床位。
对于已经积累大量数据的企业，值得追问的是，系统发现问题以后，能否帮助业务人员把问题处理下去？
如果你关心企业本体怎样利用已有数据，可以先了解 Dataphin 的数据建设与治理能力，再沿本文理解业务对象与行动的关系。
本体把业务对象、判断规则与行动组织起来
本体，是一套对企业业务世界的共同定义。 它明确客户、车辆、订单等业务对象分别代表什么，怎样描述它们，以及它们之间如何联系。在 Palantir 的体系中，本体还组织业务判断逻辑和可执行的行动，让业务人员与 AI 能够依据同一套含义理解情况、作出判断并推进工作。
可以把它理解为一本“企业操作说明书”。它说明企业里有哪些业务对象，也解释这些对象怎样联系、在什么条件下需要采取什么行动。下图用对象、关系、规则和行动四个部分展开这一比喻。
对象，是说明书里的“零件清单”。 对象代表企业需要识别和管理的业务事物，例如一辆车、一位客户或一笔订单。每个对象都有自己的身份，以及描述它的属性。车辆可以有车架号、车型和上次保养日期；订单可以有金额、下订时间和交付状态。团队由此能够明确，自己讨论的是哪个对象，以及它当前处于什么状态。
关系，是“零件”之间的“装配图”。 一位客户下了一笔订单，订单对应一辆车，车辆又有多次保养记录。把这些联系明确下来，就能沿着车辆找到相关客户和服务历史，让分散的记录形成可以核对的业务上下文。同一个人可以同时是购车人和用车人，也可能只承担其中一种角色，关系需要把这些含义区分清楚。
规则，是说明书里的“运行原理”。 假设企业约定车辆距离上次保养满12个月时需要提醒，就应明确从哪次记录开始计时、哪些车辆符合条件，以及已经预约的客户是否还需要提醒。规则把业务经验变成可重复使用的判断依据，让团队对“哪些客户需要跟进”的理解一致。这里的12个月仅用于解释规则，实际条件由业务确定。
行动，是说明书里的“操作按钮”。 行动定义可以对业务对象做什么，例如创建保养跟进任务、发送通知或登记预约。每项行动都需要明确操作对象、输入信息、执行条件和权限，并记录执行结果。“这辆车需要保养”的判断，才有可能落实为一次可追踪的客户服务。
在这个简化示例中，车辆对象提供上次保养日期，客户与车辆的关系确定联系对象，规则判断是否需要提醒，行动则完成通知或创建跟进任务。对象与关系帮助理解业务事实，规则和行动进一步把判断接到实际工作上。
先分清患者与本次入住，才能处理正确的那件事
我们现在利用患者安置的场景，理解这些定义怎样发挥作用。
一名患者可能多次入院。患者身份回答“是谁”，本次入住回答“正在处理哪一次就医”。这两个对象的含义不同，等待时间、床位安排和相关状态都应当对应到具体的一次入住。
假设工作人员要查看某位患者当前的安置情况。系统需要先找到患者，再找到本次入住，沿着入住与床位的关系查看安排。如果只按患者姓名汇总历史记录，就可能把上次入住的床位当成这次安排。即使姓名完全正确，业务含义仍然可能错位。
这就是本体首先要解决的问题。它要规定“患者”和“入住”各自代表什么，怎样辨认同一个对象，以及两者之间怎样关联。实际接入数据时，再把患者编号、入住编号和相应记录映射到这些定义。
本体中的对象还可以是医院资源。“床位”具有编号、当前状态等属性，通过“属于”关系关联到“病区”。业务人员从某次入住出发，可以查到对应患者和已安排的床位，再查到床位所在的病区。每一步都有明确的关系含义。
| 模型中的内容 | 医院模型中的例子 | 解决的问题 |
| 对象 | 患者、本次入住、床位、病区 | 当前讨论的是谁、哪件事或哪项资源 |
| 属性 | 入住时间、床位编号、床位状态 | 这个对象有哪些具体信息 |
| 关系 | 入住属于某患者，入住安排到某床位，床位属于某病区 | 不同对象怎样对应 |
| 业务逻辑 | 按业务条件判断本次入住可使用哪些床位 | 已有事实满足什么条件 |
| 行动 | 为本次入住分配床位，并记录安排结果 | 怎样按规定改变业务状态 |
本体定义“床位状态”的含义，业务数据提供某张床此刻的状态值。 当数据更新时，状态值会变化；当医院调整什么叫“可分配”时，业务定义也需要随之维护。把两者对应起来，软件才能使用数据回答业务问题。
这也说明，建设本体需要业务团队和数据团队一起参与。业务团队确认对象、关系和判断条件；数据团队核对标识、字段与更新方式。字段名称相同，不能保证含义一致；含义已经约定，也还需要可靠的数据来支持。
从空床到可分配床位，中间还有业务逻辑
床位处于空闲状态，只说明一项事实。它是否适合本次入住，还取决于患者需求、床位条件和医院规定的安排要求。
在医院废模型中，可以先找到当前等待安置的入住记录，再筛选状态可用、条件相符的床位，形成待确认的候选集合。这里的“条件相符”需要由业务人员明确，并由软件中的逻辑实现。涉及诊疗和护理的专业要求，仍由相应专业人员制定和判断。
本体将这段逻辑与它使用的对象联系起来。输入是某次入住和相关资源，输出是符合已定义条件的候选床位。使用者能够核对筛选依据，也能发现输入缺了什么。若缺少必要条件，系统应保留待确认项，不能仅凭“空闲”就认定可以安排。
逻辑还可以用于解释指标。若团队要比较患者安置耗时，就要约定从何时开始计时、何时算安排完成，并明确统计哪些入住记录。不同报表采用同一套定义，才有条件比较变化。统计结果可以提示哪一环节需要检查，后续处理仍要回到具体入住和资源。
已有数据建设中的对象、活动和指标定义，能够为这项工作提供材料。Dataphin 的业务实体指南介绍了对象、事件、快照与流程的区分，可以帮助团队梳理现有定义的适用范围。
行动把一次决定变成可以核对的业务变化
工作人员选择候选床位后，还需要正式提交安排。一次“分配床位”应当指明处理哪次入住、选择哪张床，以及提交后修改哪些关系和状态。
Palantir 用动作类型（Action type）定义一类操作允许进行的变更，以及相关处理逻辑。具体执行时，再传入本次操作的对象与参数。前面的“分配床位”可以用它理解动作类型与一次实际操作的区别。
对这项行动，需要分别核对两个条件。执行人是否有权分配床位，决定谁可以提交；提交时床位是否仍然可用，决定当前能否进行安排。能够查看床位信息，并不自动获得操作权限。几分钟前得到的候选结果，也不能代替提交时的状态检查。
安排成功后，系统应保留本次入住与床位的关联，使后续查询能看到已确认的结果。若还涉及外部医院系统，就需要按实际接口核对写入和回执。模型里的行动定义，要通过相应软件和业务流程执行，才能形成真实变化。
因此，查询与行动有不同的验收结果。查出候选床位，可以帮助工作人员作判断；确认并记录分配，才表示安排已形成。二者使用相同的业务对象，操作目标和完成证据各自明确。
不同应用可以使用共同定义，AI 也需要遵守它们
全院协调人员需要查看等待安置的整体情况，病区工作人员关注本病区的具体安排。两种界面可以不同，但“本次入住”和“床位”的含义应当一致，相关操作也需要遵循共同规则。
Palantir 的对象视图（Object Views）把一个对象的属性与关联信息组织在同一页面。下面的官方患者示例中，患者标识和就诊记录分别呈现。读者可以据此观察，对象定义怎样进入使用者实际看到的界面。
患者标识与就诊记录分别呈现，基本信息和关联记录围绕同一患者组织。
动作的处理逻辑与校验也可以供多个应用使用。若全院协调界面和病区界面都需要分配床位，共同适用的规则可以集中维护。部门之间确有差异的条件，则需要单独说明适用范围。复用成立的前提，是双方使用的业务含义和条件一致。
AI 参与工作时，同样需要这些定义。工作人员提出“找出当前等待安置、可以安排床位的患者”，系统需要将问题对应到本次入住，再按定义查找相关记录和候选资源。生成一段流畅建议，尚不能说明它找对了对象，也不能说明安排已经完成。
Palantir是一家面向政府及企业提供数据分析与AI软件的平台公司。它的一项核心理念，是让数据支持业务决定，并将决定落实为可执行的工作。
在 Palantir 的产品分工中，Foundry 支持数据管理、本体建设与应用开发，AIP 将大模型接入业务信息和工具，Apollo 支持部署与更新。三者为应用运行提供不同能力，本体把其中使用的业务含义组织起来。
业务应用与 AI 智能体（Agent）使用共同的本体定义。实线表示建设或使用关系，虚线表示部署与更新。
沿用医院模型，AI 可以协助整理候选方案，工作人员按任务设计确认，相关系统再按授权执行行动。每一步都要能回到所使用的对象、依据和结果。这样才能判断问题出在记录不完整、条件定义不清，还是操作没有完成。
从一项具体工作检验本体是否有用
对患者安置而言，本体建设是否有效，可以落到一个完整问题上。系统能否识别正确的本次入住，使用明确条件找到候选床位，再把经确认的安排记录到对应对象上？
其中任一步缺失，都会影响这项工作。对象混淆会指向错误的入住；判断条件不清会让候选结果失去依据；操作结果没有记录，后续人员就无法确认安排进展。把定义、数据与行动对应好，多个岗位才能围绕同一次入住继续协作。
企业开始建设本体，也可以先选一项需要改善的工作，确认完成它必须用到哪些对象和判断条件，再接入所需数据与操作接口。第一轮的范围由工作决定，效果也由具体过程验证。
下一篇从“这个月卖了多少辆车”出发，解释本体怎样统一客户、购车机会、订单和流程节点的理解。
如果正在考虑企业本体建设，可以带着一项具体业务问题，通过瓴羊官方联系入口咨询数据建设与 AI 应用需求。
继续阅读 02 业务对象与口径怎样统一 · 03 Dataphin 的数据模型与知识图谱
资料来源
Palantir 2025 年年度报告，年度收入、已有商业客户收入增量及公司背景。
坦帕综合医院与 Palantir 扩大合作，2024 年 6 月，合作过程、应用扩展及医院披露的患者安置指标。
空客 Skywise Core，平台数据与机队运营应用。
Palantir Ontology 概览与Ontology 系统架构，对象、关系、逻辑与行动。
平台协作关系、本体应用与动作类型，产品职责、对象应用及动作复用。
Palantir 对象视图与患者示例，患者对象视图原图及功能说明；中文导读为编辑注解。
系列作者：莫疑（工号264386）
