Palantir把“软件要理解的数据世界”拆成三层——先看清楚世界长什么样（语义层），再让世界能动起来（动力层），最后让世界学会自己拿主意（动态层）。三层由静到动，从“描述现实”逐步走向“决策现实”。

图 1 本体论的三层架构

一、语义层（Semantic Layer）——“名词”

在动态本体的三层架构中，语义层（Semantic Layer）构成了最基础的层面。如果将本体比作组织的数字神经系统，语义层便是其中的感知网络——它负责将现实世界中的实体、属性和关系映射为数字世界可理解和可操作的结构化表达。语义层的设计决定了本体的表达能力和适用范围，是构建决策与行动层的前提。

（一）语义层的定位与功能

1. 定义企业世界的“名词”

语义层的核心功能是为组织业务世界提供一套统一的“名词”体系。在Palantir的框架中，这一功能通过三类基本要素实现：

实体（Objects）：语义层中的实体是对象类型的实例，每一个实体代表现实世界中的一个具体的人、事、物或事件。实体是语义层中最基础的“名词”，如同句子中的主语，是属性和关系的承载主体。

属性（Properties）：属性描述实体的特征或状态，例如一个人的姓名、一台设备的温度读数、一笔订单的金额。属性构成了实体的可量化维度。

关系（Links）：关系定义了实体之间的关联，例如员工“属于”某个部门、航班“执飞”某条航线、订单“关联”某个客户。关系将孤立的实体连接为具有业务语义的知识图谱。

语义层通过这三类要素，将业务世界中的一切重要事物及其关联系统性地编码为数字世界可处理的语义结构。

2. 构建独立于原始数据格式的统一语义模型

语义层的另一个核心功能是构建一个独立于原始数据格式的统一语义模型。在传统数据架构中，数据往往以多种格式分散存储于不同系统——关系数据库中的结构化表、文档库中的半结构化数据、日志系统中的流数据、以及非结构化的文本和图像。这些数据格式的差异使得跨系统查询和数据整合面临较大困难。

语义层通过在原始数据之上构建一层语义抽象来解决这一问题。这一抽象层不改变底层数据的物理存储方式，而是在逻辑层面为不同来源的数据提供统一的命名规范、类型系统和关联规则。用户查询的是业务实体（如“客户”），而非底层的表或文件。原始数据格式的差异被语义层封装和隐藏，用户可以在统一的语义框架内进行跨源查询和分析。这种设计与哲学本体论中将实体从具体存在中抽象出来的思路一脉相承——正如亚里士多德将“作为存在的存在”作为研究对象一般，语义层将“作为业务实体的业务实体”作为操作对象，从而摆脱了底层存储格式的束缚。

（二）核心要素

1. 对象（Objects）

对象是语义层中最基本的构成单元。一个对象就是一个数字化代表——它对应现实世界中的一个实体（如“员工张三”或“订单编号9527”）或一个事件（如“2025年10月9日HS302航班起飞”）。在技术实现上，对象是对象类型的实例化：每个对象都归属于一个对象类型，并继承该类型所定义的所有属性和关系模板。

对象的意义在于为数据赋予身份和上下文。传统数据仓库中，同一客户的信息可能分散在订单表、客服记录表和付款记录表中，彼此之间通过外键连接，但缺乏统一的“客户”实体。在语义层中，客户是一个可识别的对象——它承载了该客户的所有属性、历史状态、以及与其他对象的关系，是贯穿所有相关数据的锚点。

2. 属性（Properties）

属性定义了对象的特征、状态或度量。属性的来源具有多样性：可以来自结构化数据源中的字段（如关系数据库中的列），也可以来自流数据（如物联网设备的实时传感器读数）、地理空间数据（如经纬度坐标）或模型衍生属性（如机器学习模型的预测结果）。

属性支持不同的数据类型和约束条件。Palantir Foundry支持在对象类型上定义各种类型的属性，包括但不限于字符串、整数、浮点数、布尔值、时间戳和地理坐标。属性的值既可以是静态的（如产品的出厂日期），也可以是动态计算的（如某个地区基于实时传感器数据计算的平均温度）。这种灵活性使语义层能够适应不同业务场景的数据需求。

在语义层的实际应用中，一个实体类型可能拥有多个属性，其中具备唯一性的属性可作为主键（primary key），另外可选择某个属性作为在前端展示的标题键（title key）。例如，员工实体的工号可作为主键，姓名可作为标题键。

3. 链接（Links）

链接定义了对象之间的关系。链接可以连接不同类型的实体（如员工“属于”某公司、航班“降落”某机场），也可以连接相同类型的实体（如某员工的“下属”是另一名员工）。

链接的定义通常涉及三种关系类型：

对象类型外键。通过外键属性来关联两个对象类型，支持一对一或一对多关系，例如一个航班对应一架飞机。

合并表数据集。通过包含对象类型主键列的数据集来关联多个对象类型，支持多对多关系，例如一个航班可以对应多架飞机，一架飞机也可以对应多个航班。

后置对象类型。通过一个中间辅助对象类型来关联两个对象类型，并允许为关联本身定义属性，支持包含属性的多对多关系，例如一架飞机可以在多个航班清单上，从而对应多个航班；一个航班也可以有多个航班清单，从而对应多架飞机。

链接形成的网络结构使语义层不再是一组孤立的实体列表，而是一个具有图结构的知识图谱。这一图谱是实时可探索的——用户可以从任意一个对象出发，沿链接遍历整个网络，追溯业务事件的因果链条，或发现实体之间隐藏的关联模式。

（三）关键机制

1. 本体水合（Ontology Hydration）

本体水合（Ontology Hydration）是将原始数据转换为本体对象的核心机制。在Palantir Foundry中，这一过程通过Pipeline Builder实现。Pipeline Builder是一个声明式的数据转换工具，用户无需编写代码即可定义从原始数据到本体对象的映射规则。

具体而言，本体水合包括三个步骤：一是从源系统中抽取数据（包括结构化数据、半结构化数据和非结构化数据）；二是按照预定义的规则对数据进行清洗、格式化和标准化处理（例如统一日期格式、解析地址字符串、处理缺失值）；三是将处理后的数据映射到本体中预先定义的对象类型、属性和链接类型，使原始数据成为带有业务语义的对象实例。

本体水合的核心价值在于将“数据搬运”转化为“语义构建”。传统ETL仅关注数据格式的转换和位置的移动，而本体水合关注的是数据在业务语义层面上的对齐和整合——每条原始记录不再是数据仓库中的一行，而是作为某个对象的属性值或属性值的一部分，被纳入本体所描述的完整业务图景中。

2. 动态对象映射

动态对象映射（Dynamic Object Mapping）是本体的另一个关键机制。它负责将底层异构数据源中的原始记录实时或近实时地“投影”为本体层的对象实例，而不需要预先将数据迁移或复制到单一的数据存储中。

这一机制的运作方式如下。当用户通过本体查询某个对象时，系统根据本体中定义的映射规则，动态地从相关的底层数据源中检索、组合并返回该对象的所有属性值和关联关系。如果某个属性来自关系数据库，另一个属性来自流数据平台，还有一个属性是由机器学习模型实时推理生成的，动态对象映射会在查询时协调所有这些来源，为用户呈现一个统一的、完整的对象视图。

这一机制与本体水合形成了互补。本体水合处理的是批量的、结构化的数据加载，而动态对象映射处理的是实时的、事件驱动的数据投影。两者共同确保本体能够在不同时间和粒度维度上保持与底层数据的一致性。

（四）语义层解决的问题

1. 传统架构中系统命名混乱

在传统企业数据架构中，命名不一致是一个普遍存在的问题。同一业务概念在不同系统中可能有不同的名称、不同的数据类型和不同的取值范围。以“客户”为例，CRM系统可能将其命名为“Customer”，财务系统可能称其为“Account”，而订单系统可能使用“Client”。更复杂的情况是，同一名称在不同系统中指代不同的业务概念——一个系统中的“订单状态”可能与另一个系统中的“订单状态”具有完全不同的取值集合和业务含义。

语义层通过建立统一的对象类型命名规范和属性定义标准来解决这一问题。所有对象类型和属性的名称、描述、数据类型和取值范围都在本体中集中定义和管理，所有基于本体的应用共享这一语义规范。用户在查询“客户”时，无论在哪个系统或工具中发起查询，都指向同一个语义定义的对象类型——语义层确保“同一事物在不同上下文中具有一致的理解”。

2. 多源异构数据的语义割裂

命名混乱是症状，语义割裂是病因。在企业数据生态中，不同系统不仅命名不同，更根本的是对同一业务实体的理解存在差异：订单系统把“客户”定义为“下单的人”，物流系统把“客户”定义为“收货的人”，而财务系统把“客户”定义为“付款的人”。这些都是同一个真实世界客户的不同侧面，但在传统架构中，这些侧面被分散在不同的数据库中，缺乏统一的语义关联。

语义层通过在数据源与应用之间插入一个统一的语义抽象层，使分散在不同系统中的数据能够在业务语义层面实现互联互通。异构数据源的原始格式差异被语义层封装，用户和应用程序面对的是一个以业务实体为中心的语义网络，而非散落在多个系统中的数据孤岛。不同来源的数据以对象、属性和链接的形式被整合到同一语义框架中，使跨源分析和跨系统协作成为可能。

以情报分析场景为例，分析师面对的数据往往来自信号情报、人力情报和公开来源等多个渠道。一个嫌疑人的姓名可能以不同拼写出现在不同来源中。语义层的统一语义模型可以识别这些不同拼写指向同一对象，将该对象及其在不同数据源中的相关记录整合为统一的视图，使分析师能够在一个界面中看到该对象在多个系统中的关联信息。语义层将数据价值从“可查询的记录”提升为“可理解的事实”。二、动力层（Kinetic Layer）——“动词”

 语义层为组织业务世界构建了一套统一的“名词”体系，回答了“业务世界中有哪些事物、它们之间如何关联”的问题。然而，仅靠名词无法构成一个可运转的业务系统。在现实世界中，业务是动态的——订单会被创建、审批和取消，设备会启动和停止，客户会投诉和满意。这些“动词”层面的行为与变化，是业务系统区别于静态知识图谱的关键所在。Palantir将这一层面定义为动力层（Kinetic Layer），它负责定义业务世界中实体之间发生的所有动态过程。

（一）动力层的定位与功能

1. 系统的动作与执行中心

动力层是Palantir本体的动作与执行中心。Palantir官方文档将动力层描述为组织的“动力学”（kinetics of the organization），在遵循组织控制和治理的前提下实现变更的能力。如果说语义层回答了“业务世界是什么样的”，动力层则回答了“业务世界如何变化”。

这一层包含行动（Actions，受控的写回操作）和函数（Functions，基于代码的业务逻辑），还包含流程挖掘与自动化、动作编排、实时监控等执行能力。Palantir的设计出发点是“帮助用户做决策并执行决策”，本体从一开始就被定位为操作层，而非展示层。这一架构要求的核心区别在于：系统不仅要能“看”（读取和展示数据），还要能“做”（执行操作并改变状态）。停在语义层的是概念图，能够执行操作的才是业务操作系统。

2. 对语义层数据进行交互与变更

动力层直接作用于语义层数据，对其进行交互与变更。操作类型（Action Types）使应用程序能够以灵活且安全的方式修改Foundry本体中的对象，并触发外部通知和副作用。函数（Functions）则提供了编写和演化具有任意复杂度的业务逻辑的能力。

动力层与语义层的关系可以这样理解：语义层定义了“一个工单有一个状态”，动力层则定义了“关闭它的函数、执行此操作所需的权限，以及它回写到的下游系统”。换言之，语义层提供了数据结构，动力层提供了改变这些结构的能力和规则。

（二）核心要素

1. 行动（Actions）

行动（Actions）是动力层中最直接体现“动词”概念的元素。操作类型定义了对象在组织控制和治理下可以被修改的方式。一个行动本质上是一个受控的事务——它一次性编辑对象、属性和链接，包括提交时触发的所有副作用。

行动的具体形态包括：创建订单、审批流程、触发警报、变更状态等。每一个行动都封装了三个层面的内容：参数（执行操作需要用户输入哪些信息）、应用逻辑（系统应执行什么逻辑）、副作用（操作成功执行后应触发的额外行为，如发送通知或触发另一个函数）。通过这种封装，行动将业务规则从应用代码中抽离出来，集中在本体层进行管理和治理。

行动的另一个关键特征是权限控制。操作类型是受治理的事务（governed transactions），它们确保只有经过授权的用户才能在符合组织控制的前提下执行变更。这种“权限化的行动层”使动力层在提供执行能力的同时，保留了组织所需的管控能力。

2. 函数（Functions）

如果说行动是“做什么”，函数则定义了“怎么做”。函数是服务端代码，在本体的受治理执行环境中针对本体对象运行。它们提供了编写和演化具有任意复杂度的业务逻辑的能力。

函数可以承担多种职责。计算对象的衍生属性、执行复杂的查询、驱动工作流、调用大语言模型、执行机器学习推理等。通过函数，系统可以将复杂的计算逻辑封装为可复用的单元，供不同的行动和应用调用。这种封装既保证了逻辑的一致性（同一业务规则在不同场景下行为相同），也降低了维护成本（逻辑变更只需修改函数定义，而非散布在各处的代码）。

函数与行动的关系是互补的。行动定义“可以做什么”，函数定义“如何计算和判断”。在实际使用中，一个行动可以背靠一个函数——函数负责执行核心的业务逻辑和计算，行动负责定义用户交互界面、参数收集和权限控制。

3. 执行与自动化

动力层不仅仅是定义行动和函数，更重要的是将语义层的对象定义与业务规则组合成可执行的逻辑计划，并自动执行这些计划。Palantir通过多种机制实现这一目标：

⚫ Workshop：利用本体中的语义原语（对象、链接）和动力原语（行动、函数），实现高交互性桌面和移动应用的快速交付。

⚫ Automate：与AIP Logic配合，在本体上编排自动化行动。

⚫ 调度与构建：通过调度器定期自动运行构建，执行正确的变换逻辑。

执行与自动化的核心在于将“人做决策、系统执行”的单次交互模式，升级为“系统持续监测状态、自动触发决策和执行”的持续运行模式。业务规则一旦在本体中被定义和部署，就不再需要人工干预即可持续运行。

（三）关键机制

1. 编译（Compile）

编译是动力层将语义定义转化为可执行逻辑计划的关键机制。在Palantir Foundry中，开发阶段通过Foundry CLI在本地运行SuperRepo，使开发者能够在本体、函数和应用上协同迭代。构建步骤将SuperRepo中声明的组件转化为一个单一的可复现制品。

在更宏观的层面上，编译机制涉及将本体元数据服务（OMS）中定义的对象类型、链接类型和操作类型，与函数中封装的业务逻辑组合在一起，形成可部署和可执行的逻辑计划。这一过程类似于传统软件工程中的编译，但对象不再是源代码，而是本体中定义的语义结构和业务规则。

编译机制的核心价值在于“声明式”而非“命令式”——用户声明期望的业务状态和规则（“当一个订单状态变为‘已发货’时，通知客户”），系统自动计算并执行所需的底层操作序列。声明式方法降低了业务逻辑的维护成本，也使系统能够更好地进行优化和推理。

2. 回写（Write-back）

回写（Write-back）是动力层最关键的差异化机制之一。传统的ETL是单向的——数据从源系统抽取、清洗、加载到数据仓库，之后仅用于查询。动力层的数据管道是双向的——数据不仅从源系统流入本体，也能从本体写回源系统。

回写机制的具体运作方式如下。当用户通过Workshop等应用提交一个行动（Action）后，整个流程包括：验证与执行，请求发送至服务器，通过权限和逻辑验证，写入Write-back Dataset，然后索引更新，变更被传播到对象索引服务。这一过程将决策指令直接下达给底层数据源层，实现物理层面的状态更新。

回写机制的实际效果是：用户在本体中修改一个订单的状态，这一变更能够同步回企业资源规划（ERP）系统。行动不仅会修改Foundry内部的本体状态，通常还会触发Webhook，将修改指令实时回写到企业底层的SAP、Oracle或其他系统中。通过这种方式，动力层闭合了“感知—决策—行动”的控制论环路。

回写机制使本体从“只读的语义层”升级为“可读写的运营层”。如果说ETL解决的是数据搬运问题，动力层解决的是让业务对象在数字系统中真正“运转”的问题。

（四）动力层的核心价值

1. 填补“洞察与执行”之间的控制论缺口

在传统数据架构中，从数据洞察到业务执行之间存在一个显著的控制论缺口。分析团队可能通过数据仓库和BI工具发现：某条供应链存在瓶颈、某类订单的审批周期过长、某批设备的故障率偏高。然而，这些洞察往往停留在报告层面——决策者看到了问题，但将决策转化为实际行动（调整供应链、优化审批流程、安排设备维护）需要跨越多个系统和部门，过程漫长且容易出错。

动力层通过将洞察与执行整合在同一语义框架中，填补了这一缺口。当系统在本体中检测到一个异常状态（如某设备温度超过阈值）时，它可以自动触发预定义的行动（如生成维护工单并通知相关人员），而无需人工将洞察从分析系统“翻译”为执行系统中的操作。动力层使“发现问题”与“启动应对”之间的时间间隔从数天缩短至实时。

2. 使系统从“描述现状”升级为“主动干预”

语义层使系统能够“描述现状”，它知道业务世界中有哪些实体、它们的状态如何、它们之间有何关联。动力层则使系统能够“主动干预”，它不仅知道世界是什么样，还能改变世界。

这种从“描述”到“干预”的升级体现在多个层面：系统可以基于预设规则自动执行业务操作（如库存低于阈值时自动补货）；系统可以响应用户的决策指令，将变更写回源系统（如审批通过后自动更新订单状态）；系统可以编排跨系统的复杂业务流程（如创建订单时同步触发库存预留、物流调度和财务记账）。

总之，动力层的核心价值可以概括为，它使本体从结构精致但不生长、不结果的“数字盆景”般的静态模型，升级为“业务操作系统”。语义层提供了业务世界的结构骨架，动力层则注入了让这个骨架运转起来的力量——数据在框架中流动、对象在框架中变化、决策在框架中被执行。

三、动态层（Dynamic Layer）——“智能决策”

在语义层和动力层的基础上，Palantir本体向上延伸出第三层——动态层（Dynamic Layer）。语义层定义了业务世界的“名词”，动力层定义了改变世界的“动词”，而动态层则负责“判断何时、为何以及如何改变世界”。这一层将AI模型、模拟推演和业务规则整合为统一的决策框架，使系统从“能够执行操作”升级为“能够自主判断应当执行什么操作”。

（一）动态层的定位与功能

1. 实现智能体驱动决策的最高层级

动态层是Palantir本体三层架构中的最高层级，其核心使命是实现智能体（AI Agent）驱动的决策。语义层和动力层提供了业务世界的结构框架和操作能力，动态层则在此基础上引入智能体——它可以读取、推理并在本体的约束和权限下自主执行行动。

动态层与AI平台（AIP）中的多个组件深度集成，包括AIP Logic（用于在本体上构建AI驱动的无代码函数）、AIP Agent Studio（用于构建基于本体的AI助手）以及AIP辅助应用。通过动态层，组织可以将AI模型从“被动响应查询”的工具升级为“主动感知、推理和执行”的智能体。

2. 建立在语义层与动力层之上

动态层并非独立于语义层和动力层的附加模块，而是建立在前两层基础之上的叠加层。具体而言：

动态层依赖语义层提供的对象、属性和关系作为AI推理的知识基础。AI模型理解业务世界的结构——它知道什么是“客户”、什么是“订单”、两者之间如何关联——不是通过解析文档或API，而是通过本体所提供的统一语义框架。

动态层使用动力层中的行动（Actions）和函数（Functions）作为AI可调用的执行能力。AI驱动决策后，其输出通过动力层的回写（Write-back）机制转化为对底层系统的实际变更。

动态层使AI不再是一个外挂于系统的独立模块，而是被“锚定”在本体中的原生能力。AI感知业务状态、推理最优决策、执行具体操作的全流程，都在本体所定义的语义约束和权限边界内运行。

（二）核心能力

1. AI引导的决策

动态层的第一个核心能力是将AI模型、业务规则和模拟推演集成到统一的决策框架中。这一集成体现在多个层面：

规则引擎与本体的融合。业务规则（如“当订单金额超过10万元时需要二级审批”）在本体中被定义和存储，动态层在执行决策时自动加载并应用这些规则。

AI推理与业务上下文的融合。AI模型不再是孤立的黑箱，而是能够访问本体中的所有相关对象、属性和关系作为推理上下文。AI在做出建议时，能够基于完整的业务图景而非孤立的输入数据。

模拟推演与决策的融合。动态层支持通过修改本体的特定分支来创建沙盒环境，在沙盒中执行多步模拟（Multi-step Simulation），预测不同决策方案在限定范围内的潜在结果。

这一集成使决策过程从“人查阅多个系统→人综合分析→人做出判断”的串行模式，升级为“系统自动感知状态变化→AI模拟多种方案→系统推荐最优方案→人确认或系统自动执行”的并行模式，提升了决策速度和质量（Palantir Technologies，2024c）。

2. 多步模拟

动态层的第二个核心能力是多步模拟与假设分析。在现实业务场景中，决策往往不是单步的——一个决策会引发一系列连锁反应。例如，将生产线上的某台设备停机检修，不仅影响该设备的产出，还会影响后续工序的进度、原材料的消耗、以及最终订单的交付时间。

动态层通过“场景推演”（Scenario Simulation）机制来支持这类复杂决策场景。具体而言，用户可以通过修改本体的特定分支来创建沙盒环境（sandbox environment），在该环境中模拟执行一系列操作，观察这些操作对相关对象状态和业务指标的级联影响，而不影响生产环境中的真实数据。

这种能力在复杂决策场景中具有实际价值（Palantir Technologies，2024c）：

⚫ 供应链决策：当某个供应商出现延迟时，系统可以模拟“切换供应商”“增加备货库存”“调整生产计划”等多种应对方案，预测每种方案的成本、交付时间和风险。

⚫ 资源配置决策：当突发任务需要调度资源时，系统可以模拟多种调度方案，比较不同方案在效率、成本和公平性等方面的表现。

⚫ 战略规划决策：当组织面临市场变化时，系统可以模拟多种战略方向下的中长期发展路径。

多步模拟的价值在于将不确定性转化为可管理的风险。决策者不再需要仅凭直觉或简化模型来预判未来，而是可以在本体的数字孪生环境中“预演”未来，以数据驱动的方式比较不同决策方案的优劣。

3. 持续学习闭环

动态层的第三个核心能力是建立持续学习闭环。在传统决策系统中，决策一旦做出并执行，其效果往往不会被系统地记录和分析，导致组织无法从历史决策中有效学习。

动态层通过“决策捕获”（Decision Capture）机制来解决这一问题。每个AI驱动的决策及其执行结果都被记录为本体中的决策对象——包括决策时的上下文状态、所考虑的选项、选择的方案、执行后的实际结果。这些决策记录成为后续AI模型训练和评估的素材，构成持续优化的数据基础。

具体而言，持续学习闭环包括以下环节：

⚫ 感知：动态层持续监测本体中对象的状态变化，识别需要决策或可优化的场景。

⚫ 推理：AI模型基于当前本体状态和历史决策记录，生成推荐方案。

⚫ 执行：决策经用户确认后（或在预设权限范围内自主执行），通过动力层回写机制更新本体状态。

⚫ 捕获：决策的上下文、推理过程和执行结果被记录为本体中的结构化数据。

⚫ 学习：累积的决策数据用于评估AI模型性能、发现决策模式、识别系统性的偏差和优化机会。

闭环的存在使决策系统具备自我完善的能力——系统运行的越久，积累的决策数据越多，AI模型的决策质量就可能越高。这种增强回路是动态层区别于静态决策支持工具的本质特征。

（三）关键机制

1. 场景推演

场景推演（Scenario Simulation）是动态层支持多步模拟和假设分析的核心机制。其技术实现方式是通过修改本体的特定分支来创建隔离的沙盒环境。

具体而言，场景推演涉及以下几个步骤：

⚫ 分支创建：系统在本体中创建一个隔离的“分支”（branch），该分支是主本体的一个可修改副本。

⚫ 参数调整：用户在分支中修改特定对象的状态或属性值（如“将某航班的起飞时间延迟4小时”），模拟外部事件或政策变化带来的影响。

⚫ 级联模拟：系统根据本体中定义的业务规则和函数，自动计算并更新分支中所有受影响的关联对象状态（如该航班延误后，关联的乘客、机组人员、后续航班的状态变化）。

⚫ 方案比较：用户可以创建多个分支，对应不同的假设或决策方案，分别模拟各自的演化路径。

⚫ 结果评估：系统对每个分支的模拟结果进行比较，量化不同方案在关键指标（成本、时间、风险等）上的差异。

场景推演的价值在于将真实世界中的“试错成本”转移到数字孪生环境中。组织可以在不中断实际业务的前提下，安全地测试各种决策方案，识别潜在的风险和机遇。

2. 决策捕获

决策捕获（Decision Capture）是动态层中连接AI决策与业务执行的关键机制。其核心含义是：AI不仅做出决策建议，而且决策的产生过程和执行结果都被系统性地记录和反馈，形成“决策—执行—反馈”的双向连动。

这一机制体现在多个层面：

⚫ 决策上下文的捕获：当AI做出决策时，系统自动记录决策时的本体状态——相关对象的属性值、关系状态、可用资源等。

⚫ 决策过程的捕获：系统记录AI推理的关键步骤——考虑哪些选项、基于什么规则做出选择、以及每个选项的评分或置信度。

⚫ 决策结果的捕获：决策执行后，系统记录实际结果与预期结果的对比，识别偏差及其原因。

⚫ 决策质量的评估：系统可以基于预设的评估函数（在AIP Evals中定义），自动评估AI决策的质量，识别需要改进的模式。

双向连动的核心价值在于将AI决策从“一次性建议”升级为“持续学习的智能体”。每次决策的执行结果都会反馈到系统中，用于评估和优化后续决策，形成持续改进的循环。

3. 本体约束下的自主决策

动态层的第三个关键机制涉及AI自主决策的范围和边界。在传统观点中，AI自主决策往往被视为一种“失控”的风险——AI可能做出不符合业务规则、违反伦理准则或超出安全边界的决策。

动态层通过将AI决策“锚定”在本体约束之内的方式，有效管理这种风险，主要通过以下主要手段。

语义约束。AI只能在语义层定义的对象类型和属性的范围内进行推理和决策。AI不能“发明”新的业务实体类型或属性，只能操作本体中已定义的实体和属性。

规则约束。AI的决策必须满足动力层中定义的业务规则和权限控制。如果一个行动需要特定权限或触发特定的业务规则，AI在执行该行动时必须满足这些条件。

行动边界的约束。AI只能调用动力层中已定义并赋予其权限的行动，不能自行创造新的行动或绕过行动定义。

审计约束。AI的每一次决策和执行都被完整记录，可追溯、可审计、可回溯。

这种“本体约束下的自主决策”机制有两个核心价值。其一，它大幅降低了大语言模型在实际业务应用中最受关注的风险——幻觉（hallucination）。在缺乏本体约束的场景中，大语言模型可能会生成虚构的事实、不存在的实体或不合理的推理链路。当AI通过本体定义的查询和行动来操作时，所有输入和输出都被限定在业务规则的边界之内——AI的“想象空间”被业务规则所约束（Palantir Technologies，2024d），有效消除了幻觉问题。其二，它使组织可以在可控的范围内逐步提升AI的自主权——从“AI建议、人执行”到“AI执行、人监督”，再到“AI在预设边界内自主决策并执行”，每个阶段的自主权提升都伴随着本体约束的清晰界定。当AI在既定的对象、属性和关系框架内运作时，其输出自然具备可操作性。

（四）动态层的核心价值

动态层的核心价值可以概括为三个层面。

第一，将AI从“对话工具”升级为“执行引擎” 。在缺乏动态层的架构中，AI（特别是大语言模型）通常以对话界面的形式存在——用户可以提问，AI可以回答，但回答停留在文本层面。动态层赋予AI调用动力层行动和函数的能力，使AI的回答可以直接转化为业务操作。AI不再是只能“说”的助手，而是可以“做”的执行者。

第二，将决策从“一次性事件”升级为“持续学习过程” 。传统决策往往是一次性的——决策做出、执行、归档，组织很少系统地评估决策质量和学习经验。动态层的决策捕获和持续学习闭环，使每一次决策都成为后续决策的“训练数据”，系统能够持续优化自身的决策能力。

第三，将系统从“辅助工具”升级为“决策伙伴” 。在本体架构中，动态层使AI能够理解业务上下文、在约束内自主推理、执行决策并学习结果。AI不再是等待被调用的工具，而是能够主动感知状态变化、主动提出建议、主动执行操作的决策伙伴。人与AI的关系从“用户操作工具”转变为“人与智能体协同决策”，这一转变对组织的运营方式和决策能力具有深远影响。

四、三层架构的协同逻辑

语义层、动力层和动态层并非三个独立的模块，而是同一架构中相互依存、逐层递进的三个层面。语义层构建了业务世界的统一语义模型，动力层为这一模型注入了执行与变更的能力，动态层则在语义和动力的基础上实现了智能化的决策与学习。三者的协同运作构成了本体从静态描述到动态自治的完整能力链条。

图 2 本体论三层架构协同

（一）三层的职责分工

三层架构的协同逻辑建立在清晰的职责分工之上。每一层都有明确的边界和功能定位，层与层之间通过标准化的接口进行交互，共同构成一个可运行、可演化、可治理的业务操作系统。

1. 三层架构的分工

语义层负责定义业务实体、属性和关系，为组织提供统一的“业务名词”体系；动力层通过行动和函数提供可执行的“业务动词”，将语义定义转化为对数据源的实际变更；动态层则在语义和动力的基础上，通过AI推理、多步模拟和持续学习实现“智能判断”，使系统能够自主感知状态、决策最优方案并从中学习进化。三者逐层递进、各司其职，共同构成完整的业务操作系统。

2. 三层的依赖关系

三层之间的依赖关系是单向的、逐层递进的：语义层不依赖动力层或动态层，动力层依赖语义层但不依赖动态层，动态层同时依赖语义层和动力层。这种单向依赖确保了架构的稳定性和可维护性——底层的变化（如新增一个对象类型）不会破坏上层功能，而上层的变化（如新增一个AI决策流程）可以充分利用底层已有的语义和执行能力。

（二）完整的控制论闭环

1. “感知→决策→行动→反馈”的闭环链路

三层架构的协同运作形成了一个完整的控制论闭环。这一闭环的运作流程如下：

⚫ 感知（Sense） ：系统通过语义层持续感知业务世界的状态。本体中的对象和属性实时反映业务实体的当前状态——无论是传感器读数、订单状态、还是设备健康度。语义层为系统提供了“看到”业务状态变化的统一语义框架。

⚫ 决策（Decide） ：系统通过动态层在感知到的状态基础上进行智能决策。AI模型基于本体上下文（相关对象、属性和关系）进行推理，生成决策建议或自主做出决策。动态层支持多步模拟和假设分析，使系统能够在决策前预判不同方案的潜在结果。

⚫ 行动（Act） ：决策形成后，系统通过动力层将决策转化为具体操作。行动（Actions）封装了操作所需的参数、逻辑和副作用，回写（Write-back）机制将变更指令下达到底层数据源。动力层将抽象的决策“翻译”为具体的、可执行的业务操作。

⚫ 反馈（Feedback） ：行动执行后，语义层中的对象状态被更新，系统“感知”到状态变化。动态层中的决策捕获机制记录决策的上下文、过程和结果，这些数据成为后续决策的训练素材。闭环在此处闭合——一次决策和执行的“经验”被系统吸收，用于优化下一次决策。

这一闭环链路意味着系统不再是被动的工具，需要等待用户输入、执行一次性查询、生成静态报告。相反，系统成为主动的参与者，持续感知状态、自主判断需求、自动执行操作、不断学习改进。

2. 从数据到业务自治的完整能力链条

三层架构的协同实现了从数据到业务自治的完整能力跃迁。

第一阶，数据可读。语义层将分散在异构数据源中的原始数据整合为统一的业务语义模型。数据从“分散的、格式各异的记录”转变为“有结构的、有意义的业务对象”。这是能力链条的起点——没有语义层的统一化，后续的决策和行动将缺乏可靠的语义基础。

第二阶，数据可写。动力层使数据不仅可读，还可写、可执行。操作和回写机制使系统能够将决策转化为对数据源的实际变更。数据从“只读的观察素材”升级为“可读写的运营介质”。

第三阶，系统可判。动态层使系统不仅能够读写数据，还能判断“应该读什么、应该写什么”。AI推理、多步模拟和决策机制赋予系统在复杂业务场景中自主判断的能力。

第四阶，系统可学。动态层的决策捕获和持续学习机制使系统能够从自身经验中学习。每一次决策和执行的“成功”或“失败”都被记录和分析，用于优化后续决策。系统具备自我完善和自我进化的能力（Jacquette，2002）。

第五阶，业务自治。当上述四阶能力成熟后，系统可以在预设的业务规则和权限边界内，自主完成从感知到决策到行动到学习的完整闭环。人从“操作者”转变为“治理者”——设定目标和规则，系统在边界内自主运行，人仅需在关键节点进行审核和干预。

能力链条的每一阶都依赖前一阶的完成。没有语义层的统一语义基础，动力层的操作将缺乏语义上下文（可能错误地修改数据）；没有动力层的执行能力，动态层的决策将停留在文本建议层面，无法转化为实际业务变更。

3. 解决传统架构中系统命名混乱、语义割裂的问题

三层架构的协同运作从根本上解决了传统数据架构中两个长期存在的系统性问题，即系统命名混乱和语义割裂。

系统命名混乱的解决。在传统架构中，同一业务概念在不同系统中被赋予不同的名称、数据类型和取值范围。这种不一致性导致跨系统查询需要复杂的映射逻辑，也增加了新应用开发和系统集成的成本。Palantir通过语义层建立统一的对象类型命名规范和属性定义标准，使所有基于本体的应用共享同一套业务名词体系（Palantir Technologies，2024a）。当一个新应用需要访问“客户”数据时，它无需理解CRM中的“Customer”、财务中的“Account”和订单中的“Client”之间的差异，只需通过本体中统一的“客户”对象类型进行查询。

语义割裂的解决。命名混乱是症状，语义割裂是病因。在传统架构中，同一业务实体的不同侧面被分散在不同的数据库中，缺乏统一的语义关联。客户在订单系统中的“下单人身份”、在物流系统中的“收货人身份”、在财务系统中的“付款人身份”，虽指向同一现实实体，但在数据层面彼此孤立。语义层通过在数据源与应用之间插入统一的语义抽象层，将这些分散的数据整合为统一的业务对象视图。异构数据源的格式差异被语义层封装，用户和应用程序面对的是一个以业务实体为中心的语义网络（孙新雨和李随科，2025），而非散落在多个系统中的数据孤岛。

三层架构的协同运作使企业数据架构从“碎片化的数据集合”升级为“统一的业务操作系统”。语义层提供了共同语言，动力层提供了执行能力，动态层提供了智能判断——三者共同构成了一套能够持续感知、决策、行动和学习的完整体系。这一体系不仅解决了传统架构中因命名混乱和语义割裂导致的数据质量问题，更重要的是，它为组织在AI时代构建智能化的业务运营体系提供了统一的架构底座。

（三）运行机制的协同时序

三层架构的各项机制并非孤立运作，而是在业务场景中以明确的时间顺序协同配合，构成一条从数据接入到业务自治的完整运行链路。本体管理的生命周期可以概括为四个环节：建设环节定义对象及行动，连接环节将数据或模型映射到对象，运行环节通过Functions与Actions进入业务流程，治理环节负责权限、版本和运行监控。以下以航空公司的航班延误处置场景为例，展示各项机制如何按时间顺序协同运作。

1. 数据接入与语义映射阶段

运行链路的起点是数据接入。在这一阶段，Pipeline Builder通过本体水合（Ontology Hydration）机制，将来自多个源系统的原始数据转换、清洗并映射到本体中预定义的对象类型。航空公司的数据可能来自航班计划系统、机组排班系统、乘客服务系统和飞机维修系统等多个异构来源。本体水合将这些分散的数据整合为统一的对象实例——每一个航班、每一架飞机、每一位乘客、每一位机组成员都被实例化为本体中的对象，并赋予其预定义的属性。

与此同时，动态对象映射机制将底层数据源中的原始记录实时投影为本体层对象，确保本体始终与源系统保持同步。当航班计划系统中一个航班的起飞时间被修改时，这一变更通过动态对象映射实时反映在本体的对应航班对象中。

2. 感知与场景推演阶段

当本体中某个对象的状态发生变化时，动态层开始介入。以航班延误为例：当“HS302航班”的“预计起飞时间”属性因机械故障从10:00更新为14:00时，语义层感知到这一状态变化。

动态层的场景推演（Scenario Simulation）机制随即被触发。系统通过修改本体的特定分支创建隔离的沙盒环境，在沙盒中模拟该变更的级联影响。推演过程会遍历与该航班关联的所有对象——该航班的执飞飞机、已预订的乘客、执飞的机组人员、后续衔接航班等——计算每个关联对象受到的影响。

具体而言，系统在分支中自动执行以下推理：该飞机原计划执飞的后续航班是否也会延误？有多少乘客可能错过中转航班？机组人员的执勤时间是否仍符合法规要求？是否需要调配备用飞机？每条推理路径都依赖本体中预先定义的链接类型（如“执飞”“预订”“隶属于”）和函数（如计算中转时间、检查执勤时限）来完成。

3. 智能决策阶段

场景推演完成后，动态层进入决策阶段。AI模型基于推演结果生成了多个可行方案，例如“调换备用飞机B-5588执飞HS302航班”“将HS302与HS305航班合并执飞”“通知所有乘客延误信息并提供改签建议”等。

AI的推理和决策在“本体约束”下进行——所有候选方案中的操作都必须是动力层中已定义的操作类型，所有涉及的对象和属性都必须是语义层中已定义的类型和属性。AI无法“发明”新的操作或访问未定义的属性，这种约束机制有效消除了大模型在实际业务场景中最受关注的风险——幻觉（hallucination）。

4. 执行与回写阶段

决策方案经用户确认后，动力层的执行机制开始运作。动力层通过编译（Compile）机制将语义层的对象定义与业务规则组合成可执行的逻辑计划。具体的操作类型（Action Type）封装了执行“飞机调换”所需的全部参数、业务逻辑和副作用。

用户通过Workshop等应用界面提交操作后，动力层执行完整的操作流程：请求发送至服务器、通过权限验证、执行逻辑、写入Write-back Dataset、索引更新。回写（Write-back）机制将决策指令直接下达给底层数据源——备用飞机的分配信息被写回机队管理系统，航班变更信息被写回航班计划系统，乘客通知记录被写回客服系统。本体中的相关对象状态同步更新，形成了一个“感知—决策—行动”的完整闭环。

5. 反馈与学习阶段

运行链路的最后一个环节是反馈与学习。行动执行后，语义层中的对象状态已更新（HS302航班现在由B-5588执飞、原定乘客已转移至新航班），系统再次“感知”到状态变化。

动态层的决策捕获（Decision Capture）机制记录本次决策的完整信息，包括决策时的本体状态（哪些对象处于什么状态）、AI推理过程（考虑了哪些方案、基于什么规则选择）、执行结果（方案是否按预期执行、实际效果如何）。这些决策记录被存储为本体中的结构化数据，成为后续AI模型训练和评估的素材。决策捕获使系统能够从每次决策中学习，持续优化对业务规则的理解契合度。

反馈环路的闭合意味着，下一次遇到类似的航班延误场景时，系统已积累了历史决策的经验数据，能够更快地识别有效方案、避免已知的无效路径。系统运行的越久，积累的决策数据越多，其决策质量就可能越高。

6. 协同时序的整体图景

上述五个阶段构成了运行机制协同时序的完整图景。从数据接入到语义映射，从场景推演到智能决策，从执行回写到反馈学习——语义层、动力层和动态层的各项机制在时间序列上依次激活、接力运转，共同完成一次从“感知状态变化”到“驱动业务变更”再到“学习决策经验”的完整循环。这一时序协同的核心价值在于：它将传统架构中分散在不同系统、由不同角色手工完成的多个环节，整合为一条自动化、可编排、可优化的端到端运行链路。传统流程中，数据工程师负责数据接入、分析师负责发现问题、业务专家负责制定方案、操作人员负责执行变更——每个环节之间存在信息损耗和时间延迟。在Palantir的三层架构中，这些环节在同一语义框架内自动衔接，数据在流转过程中持续增值，最终形成一条从数据到业务自治的完整能力链条。