上一篇《什么是本体？从认出一只猫，到读懂一张表》，我们讲清了一件事：数据库保存的是一个个值，本体负责告诉机器，这些值在现实业务中代表什么。
例如，PO-20260806-01 在数据库里只是一串字符。经过本体解释，机器才知道它是一张采购单，采购的是哪种原料，来自哪个供应商，要送到哪个仓库，又会影响哪些生产任务。
有了这层理解，下一个问题自然就来了：机器能不能沿着这些关系找到受影响的订单？能不能调用业务规则计算处理方案？方案获批以后，能不能修改采购单和生产计划？谁有权批准，谁只能查看？
Palantir 的本体系统，回答的就是这些问题。
第一篇讲的是让机器看懂业务。今天这一篇讲的是，机器看懂以后，怎样在人的控制下参与业务决策。
先认识 Palantir：一家把数据接到实际业务上的软件公司
你可以先把 Palantir 理解成一家大型企业软件公司。它帮助企业收集和整理数据，并把数据接到采购、生产、供应链和运营等实际工作中。
“本体”这个概念并不是 Palantir 发明的。Palantir 的做法，是把计算机领域中描述对象、属性和关系的本体思想放进企业信息化系统，再接上计算规则、业务操作和权限控制。它把原本用于“说明业务是什么”的模型，做成了能够参与企业日常工作的软件系统。
Palantir 现在有三个主要平台。名字不重要，先看它们各自干什么。
- 数据平台（Foundry）：把 ERP，也就是企业管理采购、财务等核心业务的系统，以及仓储、生产、销售系统里的数据接进来，整理并持续更新。
- AI 平台（AIP）：让大模型和 AI Agent，也就是能调用工具完成任务的智能助手，在企业的数据、规则和任务中工作。
- 软件部署平台（Apollo）：负责把软件安装到不同环境，并持续升级和维护。
贯穿这些平台中心的，是 本体系统（Ontology）。它让数据平台、AI 和业务应用对“供应商、原料、采购单、库存、生产线”这些东西有同一套理解。
Palantir 官方把它称为组织的“运营层”。直白地说：它夹在底层数据系统与上层业务操作之间，把数据翻译成业务对象，再把业务对象接到计算规则、可执行操作和权限上。
Palantir 的本体包含对象关系图，也包含一套企业业务运行说明书：既写清楚企业里有什么，也写清楚遇到事情该怎么算、允许做什么、谁能做。
先看全貌：四样东西，加上三部分系统
理解 Palantir 的本体，只要先分清两套说法。
第一套说法是，一次业务决策需要四样东西：
- 数据：现在发生了什么。
- 逻辑：应该怎样判断和计算。
- 行动：选定方案后，系统可以做什么。
- 安全：谁能看、谁能算、谁能改。
第二套说法是，要让这四样东西实际运转起来，需要三部分系统：
- 业务说明书：把对象、关系、规则和动作写清楚。
- 执行机器：连接真实系统，让查询、计算和修改跑起来。
- 操作台和工具箱：让员工、开发者和 Agent 能够使用这些能力。
两套说法回答的是不同问题：四样东西回答“一次决策需要什么”，三部分系统回答“这些东西靠什么运行”。
下面用同一个例子，把它们逐一对上。
一次原料断供，四样东西分别在哪里发挥作用
Palantir 官方文档虚构了一家名叫 Onyx 的医疗用品制造商。它只是讲解产品的示例，并非真实客户案例。
现在，一种生产口罩和手套的关键原料突然断供。公司必须尽快回答三个问题：哪些订单会受影响？有什么替代方案？批准以后要怎样调整采购和生产？
第一步，数据告诉我们“发生了什么”
系统先读取采购系统里的供应商和采购单、仓库系统里的原料库存、生产系统里的产线安排，以及销售系统里的客户订单。
本体已经说明了这些数据之间的关系：某种原料用于哪些产品，产品在哪条产线生产，一张客户订单需要多少产品。
机器因此可以沿着“原料—产品—产线—订单”一路查下去，找出受影响的库存、生产任务和客户订单。
这就是数据发挥作用的地方。数据告诉团队问题有多大、影响了谁。
第二步，逻辑计算“可以怎么办”
看清影响以后，系统再调用企业已有的判断规则和计算模型。
例如，替代材料规则会检查另一种原料能不能使用；排产模型会计算把口罩换到另一条产线后，手套订单会不会延期；需求预测模型会判断有限库存应该优先分给哪些订单。
系统可以给出几个方案：更换原料、调整产线、重新分配库存，或者修改部分订单的交付日期，并算出每个方案的影响。
这就是逻辑发挥作用的地方。逻辑不负责拍板，它负责把可选方案和后果算清楚。
第三步，行动把获批方案送回业务系统
企业需要提前定义系统允许执行哪些操作，例如“调整采购数量”“重新分配库存”“修改生产计划”“更新交付日期”。每个操作都要写明需要哪些信息、会改哪个系统。
模型或 Agent 给出的方案可以先放在临时场景里试算，不直接修改真实数据。人确认方案以后，系统才执行已经定义好的操作，把变更写回仓储系统、ERP 或生产计划系统。
这就是行动发挥作用的地方。分析不再停在一张报表上，而是可以变成一项受控的业务操作。
安全贯穿数据、逻辑和行动三步
系统从读取数据时就要检查权限。后面的模型调用、方案提交、审批和修改，也要分别检查。
仓库员工可能只能看自己区域的库存；供应链分析师可以运行排产方案，却不能直接修改采购单；Agent 可以查询和提出建议，把修改送回 ERP 仍要由采购负责人批准。
系统还要留下记录：这次用了哪份数据，运行了哪个规则或模型，Agent 提出了什么建议，谁批准了操作，最后修改了哪些内容。
所以，整个过程可以记成：
数据告诉我们发生了什么 → 逻辑算出可选方案 → 行动改变业务状态 安全贯穿三步，决定谁能看、能算、能改
三部分系统，用一张采购单就能看懂
Palantir 官方把本体系统概括为 Language、Engine 和 Toolchain。直接记英文很容易更糊涂，我们把它们翻成三件日常能理解的东西。
第一部分：业务说明书（Ontology Language）
它像一本全公司共同使用的业务词典和操作手册。
以采购单为例，说明书要写清楚：采购单有哪些字段，关联哪个供应商和哪种原料，可能处于草稿、待审批、已下单还是已关闭状态；它允许执行“修改数量”“提交审批”“取消订单”等哪些操作，每项操作又需要满足什么条件。
它解决的是“业务应该怎样被描述”。这里的 Language 指的就是描述企业业务的一套统一说法，与英语或编程语言无关。
第二部分：执行机器（Ontology Engine）
说明书写得再清楚，也不会自己工作。执行机器负责把说明书接到真实世界。
业务说明书里写着“采购单数量”，执行机器要知道这个数从哪个 ERP 字段读取；库存发生变化时，它要把新状态同步过来；“修改采购数量”获批后，它还要把新数量正确写回 ERP。
它解决的是“定义好的东西怎样真的跑起来”，包括读取、查询、同步、计算和写回。
第三部分：操作台和工具箱（Ontology Toolchain）
普通员工不应该面对数据库表，Agent 也不应该直接拿数据库账号。
操作台把底层能力做成订单页面、供应链看板、审批按钮和模拟工具；工具箱则让开发者把“查询受影响订单”“运行排产方案”“提交采购单修改”做成应用接口或 Agent 可以调用的受控工具。
它解决的是“人和 Agent 怎样安全地使用这些能力”。
三者放在一起，就像一间业务车间：业务说明书规定做什么，执行机器负责运转，操作台让人和 Agent 发出指令并看到结果。
四样东西通过这三部分落地：说明书定义数据代表什么、规则怎么算、动作允许做什么；执行机器读取真实数据并运行计算和修改；操作台把查询、模拟、审批和操作交给有权限的人或 Agent。安全要求则贯穿三部分。
如果参考 Palantir，我们至少要建设什么
Palantir 的完整平台非常庞大，普通团队不需要照抄。它把 Ontology 放在已经接入并整理好的数据和模型之上。这个位置说明：本体不能凭空运行，下面必须有数据和计算基础，上面必须有安全的使用入口。
一套能进入实际业务的本体系统，至少要补齐六块基础能力。
1. 数据接入和同步
先把 ERP、仓储、生产、销售等系统列清楚，确认数据负责人、更新时间、质量问题和唯一编号，再建设数据连接、清洗和同步能力。
如果同一个供应商在三个系统里有三个编号，本体连出来的关系就不可信。数据梳理是第一项基础工作，不能跳过。
2. 业务对象管理
要有一套本体管理工具，统一维护“供应商、原料、采购单、库存、生产线、客户订单”这些对象，以及它们的属性、关系、状态和名称。
这套内容还要支持审核、版本记录和变更发布。否则一个部门修改了“已交付”的定义，其他应用和 Agent 可能完全不知道。
3. 规则和模型的运行环境
库存规则、替代材料规则、预测模型和排产算法，不能只写在文档里。它们需要成为可以调用、测试、更新和监控的计算能力，并写清楚输入什么、输出什么、适用于什么条件。
4. 受控的行动和业务系统修改
要给 ERP、仓储和生产系统准备可靠的接口，明确哪些修改可以执行、由谁批准、失败以后怎样恢复。
还要防止一次操作因为网络重试被执行两遍。Agent 不应该自由拼接数据库修改语句，而应从已经审核过的操作菜单中选择。
5. 身份、权限、审批和审计
每个人和每个 Agent 都要有明确身份。系统要控制他们能看哪些对象和字段，能运行哪些模型，能提交或批准哪些动作，并完整记录调用、审批和修改过程。
这是系统敢不敢从“给建议”走到“改业务”的前提。
6. 给人和 Agent 使用的入口
最后还要有业务页面、查询接口、审批入口和 Agent 工具。员工直接看到“受影响订单”和“提交调整方案”，无需面对十几张底层表；Agent 只能调用“查询库存”和“提交待审方案”等受控工具，不会获得数据库总钥匙。
真实落地就按“结果导向”来做
这些能力可以按下面五步落地。
第一，先定一个具体结果。
不要一上来就说“建设全企业本体”。可以先定成：“原料断供后，十分钟内找出受影响订单，并给出两套可审核的调整方案。”
第二，同时做业务梳理和数据梳理。
业务梳理要问清楚：现在谁发现问题、谁计算影响、谁批准、最后在哪个系统修改。数据梳理要找出：这些步骤分别使用哪些表、字段、文档、规则和模型，数据质量怎样。
第三，只建这项任务需要的最小本体。
先定义供应商、原料、采购单、库存、生产线和客户订单，不要试图一次描述整家公司。把它们的关键属性、关系和状态说清楚，就可以开始验证。
第四，接上规则、模型和操作。
让系统能够查影响、算方案，并把“调整采购单”“重新分配库存”等动作做成受控接口。同时写清每项动作的输入、审批人、目标系统和失败处理方式。
第五，从只读和建议模式开始。
先让系统查数据、跑模拟、给建议，由人手工执行。结果稳定以后，再开放“提交待审批方案”；继续验证以后，才考虑让少数低风险动作自动执行。
这就是结果导向：先证明一个具体问题能不能更快、更准、更安全地解决，再逐步扩大对象、规则和动作的范围。
回到标题，Palantir 的本体到底是什么
第一篇讲的是，怎样把数据库里的值解释成采购单、供应商、库存和生产线。
Palantir 在这层理解之上又多走了一步：它把这些业务对象接到真实数据、计算规则、可执行操作和权限体系。员工和 Agent 由此既知道“这是什么”，也知道“出了问题可以怎样处理，以及谁有权处理”。
Palantir 本体最值得借鉴的地方，是让统一的业务理解进入查询、判断、审批和行动，而不是停在一张更大的关系图上。
下一篇，我们就用这六块基础能力和五个落地步骤，具体看看我们自己的本体工程已经做了什么、还缺什么，以及怎样让模型发现的业务知识能够审核、发布、追溯并被业务使用。
以上就是这次的侦察。
如果对你有用，顺手点个赞 +「♥️」。
想第一时间收到前线情报，关注「硅基斥候S01」。我们，下次侦察见。