Palantir Ontology 系统：从数据表到企业决策对象

在 Palantir Architecture Center 中，Ontology 被称为整个架构的核心。它不是普通的数据字典，也不只是给数据仓库加一层标签，而是用来表达企业如何观察世界、如何做决定，以及如何在权限约束下采取行动。

如果你正在做企业知识库、流程 Agent 或 AI FDE 项目，Ontology 是最值得掌握的概念。Agent 真正需要的不是更多文本，而是可查询的业务对象、清晰的关系、可执行的动作和明确的责任边界。

从数据转向决策

传统数据系统通常以表、字段和记录为中心：

orders(order_id, customer_id, status, amount)
shipments(shipment_id, order_id, eta, status)
inventory(sku, warehouse_id, quantity)

这些表可以支撑查询，但业务人员和 Agent 实际关心的是：哪些订单正在延迟，延迟会影响哪些客户，哪些库存可以替代，谁可以批准改派，以及改派后需要更新哪些系统。

Ontology 关注的是把数据转换为订单、客户、运输、库存、仓库这些对象，并把它们之间的关系、动作和逻辑显式化。

Ontology 的四个组成部分

1. Data：对象和状态

数据进入 Ontology 后，不再只是孤立记录，而是成为具有业务语义的对象。

一个订单对象可以包含订单编号、客户、金额、创建时间、当前状态、风险等级、交付承诺、关联商品、仓库、物流、客服事件、数据来源和更新时间。

对象的价值在于让不同应用、分析和 Agent 使用同一套业务语言。

2. Logic：为什么做出这个判断

业务决策不会只依赖一条字段。它可能需要规则、预测模型、优化器、统计计算或 LLM 函数。

例如“是否需要升级订单”可能由下面的逻辑组合：

交付延迟概率
+ 客户优先级
+ 替代库存情况
+ 合同 SLA
+ 当前运输事件

关键规则应可测试、可版本化、可审计，而不是只隐藏在 Prompt 中。

3. Action：从建议到改变世界

对象和属性是名词，动作是动词。没有动作，Ontology 只能描述企业，不能帮助企业执行。

常见动作包括批准采购单、分配库存、修改运输计划、创建工单、关闭告警、升级负责人和回写外部系统。

每个动作都应明确输入、权限、校验、外部副作用和失败处理。

4. Security：谁可以看到和做什么

同一个对象，不同角色可能拥有不同的查看范围和动作权限。用户可能可以查看库存，但不能修改库存；可以模拟采购方案，但不能直接创建采购单。

Agent 的权限不能只由模型决定。它应继承用户、项目或明确的服务身份，并在每次读取和动作时重新检查。

Ontology 不是普通语义层

薄语义层通常解决字段命名、指标口径、查询抽象和数据发现。面向运营的 Ontology 还需要解决对象如何表示现实世界、关系如何组成决策图、状态如何变化、动作如何写回系统、逻辑如何演化，以及 Agent 如何在权限内参与。

因此，它更像一个面向决策的后端系统，而不是给 BI 查询加一层别名。

Language、Engine、Toolchain

Ontology Language

负责定义对象、属性、链接、动作、自动化和逻辑，回答系统中有哪些概念以及它们如何关联。

Ontology Engine

负责把定义变成可查询、可订阅和可写入的运行时。它既要支持对象查询，也要支持状态变化、事务更新、批量变更和低延迟同步。

Ontology Toolchain

包括 SDK、开发工具、应用框架和治理能力。开发者可以在 Ontology 之上构建应用、Agent 和工作流，而不必为每个项目重新拼装数据访问、权限和动作回写。

一个完整的 Agent 读写闭环

以“设备故障处置 Agent”为例：

读取

Agent 查询设备对象、最近遥测、历史维修、备件库存和当前工单。

推理

Agent 调用规则、预测模型或诊断工具，判断故障等级与可能原因。

建议

Agent 生成维修方案，列出证据、影响范围、预计成本和不确定性。

执行

授权用户确认后，Agent 可以创建工单、预留备件或通知现场人员；高风险动作需要人工确认。

反馈

维修结果、人工修改和最终状态回写 Ontology，成为后续评估和学习的数据。

对象状态 → 逻辑 / 模型 → Agent 建议 → 授权动作 → 新状态 → 反馈

Ontology 与普通 RAG 的区别

维度	普通 RAG	Ontology 驱动 Agent
上下文	文档片段	对象、状态、关系、文档和指标
主要任务	找到并生成答案	理解决策状态并推进流程
权限	常见为文档级过滤	对象、字段、动作和用户上下文的组合控制
输出	文本	建议、结构化结果或授权动作
回写	通常需要人工复制	可通过动作、函数和 Webhook 回写
反馈	点赞、评分或日志	业务状态变化、人工修正和执行结果

RAG 仍然有价值，它是文档上下文的重要组成部分，只是应被放进更完整的对象和决策体系中。

AI FDE 建模实操

面对新项目，可以按下面顺序：

1. 写出业务流程中的名词：订单、客户、设备、人员、告警；
2. 记录每个对象的状态和变化来源；
3. 画出对象之间的链接；
4. 列出流程中的动词：批准、分配、升级、关闭、回写；
5. 为每个动作记录输入、权限、审批和失败结果；
6. 再决定哪些逻辑由规则、传统模型、LLM 或 Agent 负责；
7. 最后设计评估和审计字段。

可以用一张最小表格开始：

对象	关键状态	可执行动作	负责人	风险
订单	待确认、运输中、延迟	改派、升级	供应链	中
设备	正常、告警、停机	创建工单、停机	生产	高
客户	活跃、风险、流失	联系、升级	客服	中

常见错误

只建对象，不建动作

对象模型做得很漂亮，但没人定义如何改变状态，最终仍然是只读分析系统。

把业务规则藏在 Prompt 中

Prompt 可以解释任务，但不应成为唯一的业务规则载体。关键规则要可测试、可版本化、可审计。

让 Agent 直接访问底层数据库

这会绕过语义、权限和动作治理。应通过受控的对象查询、函数和工具访问业务能力。

把权限理解为 UI 功能

隐藏按钮不等于保护动作。权限必须在 API、函数、对象读取和外部写入时都生效。

参考资料

• The Ontology system
• Ontology overview
• Why create an Ontology?

企业 AI 的长期竞争力，通常不在谁接入了哪个模型，而在谁把业务对象、逻辑、动作和权限建成了可复用的决策系统。