大家好，我是独孤风。

这几天我们连续聊到了本体论、知识图谱、元数据和语义层。如果只从概念上看，这些词很容易变成一堆抽象名词。但一旦放到企业 AI 里，问题就会变得非常具体。

大模型能理解自然语言，但它不一定理解一家企业的业务对象。RAG 能检索文档，但它不一定知道这些文档、指标、字段和业务流程之间是什么关系。Agent 能调用工具，但它不一定知道什么动作可以做、谁有权限做、做完以后如何审计。

所以，企业 AI 真正难的地方，并不是把模型接进来，而是把企业自己的业务世界组织起来，让 AI 能理解、能约束、能执行、能追溯。

这也是为什么 Palantir 一直强调 Ontology。

我对 Palantir 的 Ontology 有一个判断：

它不是一个单纯的本体论概念，也不是普通意义上的知识图谱，而是一套把企业业务对象、数据、逻辑、动作和安全控制连接起来的业务语义操作层。

换句话说，Palantir 真正想解决的不是“怎么让 AI 更会聊天”，而是：

怎么让 AI 在企业真实业务系统里可靠地理解和行动。

一、为什么 Palantir 一直强调 Ontology

很多人第一次看到 Ontology，会把它理解成“本体论”，然后自然联想到哲学、知识图谱、概念分类。这当然没错，但如果只停在这个层面，就很难理解 Palantir 为什么把它放到这么核心的位置。

Palantir 官方架构文档里有一个很关键的表述：Ontology 位于 Palantir 架构的核心，它要表达的是企业复杂、相互连接的决策，而不只是数据本身。

这句话很重要。因为在很多数据平台里，数据是核心。平台会关注数据从哪里来、存在哪里、谁能用、怎么分析。但在 Palantir 的语境里，企业真正要管理的不是一堆表，也不是一堆看板，而是一个不断变化的业务世界。

比如一家航空公司，不只是有航班表、飞机表、机组人员表、维修记录表。它真正关心的是：

• ① 哪架飞机正在服务哪个航班；

• ② 哪些机组人员可以被重新调度；

• ③ 哪个航班延误会影响后续航班；

• ④ 哪些规则限制了调度动作；

• ⑤ 哪个动作会触发系统更新；

• ⑥ 谁有权限做这个决策；

• ⑦ 决策完成后如何记录和复盘。

这些问题不是单靠数据目录能解决的。它需要把数据、业务对象、规则、权限、动作和工作流放在一个统一的语义结构里。

这就是 Palantir Ontology 的核心价值。它不是只回答“数据在哪里”，而是回答：

企业业务世界里有什么？它们如何关联？能做什么？谁能做？按什么规则做？结果如何写回和审计？

这也是企业 AI 和传统 BI、传统数据平台最大的区别。BI 更多是看数据，企业 AI 则开始要参与行动。一旦 AI 要参与行动，就必须有业务语义边界。

二、Palantir Ontology 不是普通知识图谱

很多人会问：这不就是知识图谱吗？

我的看法是：有关系，但不能简单等同。

普通知识图谱更强调实体和关系。它让系统知道“谁和谁有关”。比如客户购买产品、订单关联合同、设备产生工单、指标依赖字段，这些当然重要。

但 Palantir 式 Ontology 更进一步。它不只是让系统知道“谁和谁有关”，还要让系统知道：

• ① 这个对象当前是什么状态；

• ② 这个对象有哪些属性；

• ③ 这个对象能执行哪些动作；

• ④ 动作背后有哪些业务逻辑；

• ⑤ 谁有权限执行动作；

• ⑥ 动作完成后如何影响真实系统；

• ⑦ 这个过程如何记录、审计和反馈。

所以我更愿意把 Palantir Ontology 理解成一层“业务语义操作系统”。知识图谱解决的是关系表达，Ontology 还要进一步解决业务操作。

这也是官方文档里特别强调的四个维度：

• data：把分散数据统一成业务对象、属性和关系；

• logic：把业务规则、算法模型、LLM 函数和复杂编排接进来；

• action：让用户或 AI 能对对象执行操作，并把结果写回系统；

• security：控制谁能看、谁能改、谁能触发什么动作。

如果只有 data 和 relation，它更像知识图谱。如果同时有 logic、action 和 security，它才更接近企业 AI 可以依赖的语义操作层。

三、为什么企业 AI 不能只靠大模型

现在很多企业做 AI 应用，容易把注意力放在模型上。模型要不要更强？上下文要不要更长？推理能力要不要更好？工具调用能力要不要更稳定？这些都重要，但企业 AI 真正进入业务系统时，问题会变成另一种形态。

比如一个 Agent 要处理客户风险。它不能只是回答“这个客户可能有风险”。它要知道这个客户是谁，关联哪些订单，欠款是否逾期，风险等级怎么算，当前状态能不能修改，是否需要审批，谁负责跟进，处理记录写到哪里。

如果 Agent 要创建工单，它还要知道：

• ① 工单对象是什么；

• ② 工单需要哪些字段；

• ③ 哪些字段必须来自可信数据源；

• ④ 当前用户有没有权限；

• ⑤ 创建工单是否会触发通知；

• ⑥ 是否会影响下游流程；

• ⑦ 后续谁来处理和关闭。

这些不是大模型自己能凭空知道的。提示词可以提醒模型“请谨慎”，但提示词不能真正保证权限正确、状态合法、字段可信、动作可审计。

企业 AI 的可靠性，更多来自数据、语义、权限、规则、工具和流程工程，而不是单纯来自模型能力。Palantir Ontology 给我们的启发就在这里：企业 AI 不是让大模型自由发挥，而是要把大模型放进一个被建模、被约束、可执行、可追溯的业务世界里。

大模型负责理解和规划，Ontology 负责告诉它业务世界长什么样，哪些动作能做，哪些边界不能越过。

这也是为什么我一直认为，企业 Agent 工程化不能只讨论 Prompt、RAG、工具调用和多 Agent 编排。真正要落地，还必须讨论业务对象、语义边界、权限规则、动作审计和数据治理。

四、Action 才是 Palantir Ontology 很关键的一点

理解 Palantir Ontology，不能只看对象和关系，还要看 Action。

Palantir 官方文档里，Action type 不是简单的按钮。它定义的是一组可以一次性修改对象、属性值和关系的变化，同时还包括提交动作时发生的副作用。

这句话翻译到企业场景里，就是：

Ontology 不只是让你看见业务对象，还让你在规则约束下改变业务对象。

比如一个 HR 系统里有员工对象、岗位属性、上级关系。一个“调整岗位”的 Action，不只是把员工的岗位字段改一下。它可能还要校验执行人是不是 HR，要求输入标准化的新岗位，自动更新员工和新经理之间的关系，并通知原经理和新经理。

这就完全不只是知识图谱了。这是一个被语义建模、被权限控制、被规则校验、能写回系统的业务动作。

对企业 Agent 来说，这一点非常关键。因为 Agent 最终不是只回答问题，而是要帮助人完成任务。任务一旦涉及修改、审批、分配、触发、写回，就必须经过 Action 这一层。

否则 AI 调用工具就会变成一件很危险的事：它知道工具名字，却不一定理解业务后果；它能生成参数，却不一定知道参数是否合法；它能提交动作，却不一定知道谁对结果负责。

所以 Palantir Ontology 里 Action 的意义，是把“AI 会做事”变成“AI 在企业规则里做事”。

五、Action Log 说明企业 AI 必须可追溯

只要 AI 进入真实业务流程，审计就不是可选项。Palantir 的 Action Log 就体现了这一点。

官方文档说明，Action Log 会把动作提交建模为对象类型，用来分析、展示、监控 Ontology 的变化，并支持回答“什么发生了变化、由谁改变、什么时候改变”这类审计问题。

这对企业 AI 很重要。因为企业里很多事情不是“做了就行”，而是要能解释：

• ① 当时谁发起了动作；

• ② 动作基于哪些对象；

• ③ 修改了哪些属性；

• ④ 是否影响了其他对象；

• ⑤ 当时的业务上下文是什么；

• ⑥ 后续结果如何；

• ⑦ 责任如何追溯。

这也是企业 AI 和个人 AI 工具最大的区别。个人工具可以追求方便、快速、灵活，企业系统必须追求可信、可控、可追溯。

如果一个 Agent 只是给出建议，风险还相对有限。但如果它开始创建工单、改客户状态、调整库存、触发审批、调用模型、写回数据，那么每一步都必须有记录。

没有审计的 Agent，只能停留在演示阶段。真正进入生产环境的企业 Agent，一定要被纳入权限、流程和审计体系。

六、这和数据治理是什么关系

很多人会觉得 Palantir Ontology 是一个很新的东西，和传统数据治理没有关系。我不这么看。

从数据治理视角看，Palantir Ontology 其实是在把很多传统能力重新连接起来。可以简单映射一下：

这张表背后的意思是：企业不是突然多了一个叫 Ontology 的新概念，而是 AI 时代要求我们把原来分散在主数据、元数据、数据标准、数据质量、权限、安全、流程里的东西重新组织起来。

过去做数据治理，很多时候是为了让人更好地找数据、懂数据、用数据。现在做 AI 时代的数据治理，还要让 AI 能在正确的语义边界内理解数据、使用数据、调用系统和执行动作。

这就是我认为 Palantir Ontology 对国内企业最有启发的地方。国内企业不一定要复制 Palantir，也很难一开始就做出一个完整的企业 Ontology 系统，但可以先从几个最基本的问题开始：

• ① 我们的核心业务对象是什么；

• ② 这些对象有哪些关键属性；

• ③ 对象之间有什么关系；

• ④ 这些对象对应哪些数据资产；

• ⑤ 哪些动作可以被系统执行；

• ⑥ 执行动作前有哪些权限和规则；

• ⑦ 执行结果如何记录和审计。

把这些问题讲清楚，企业 AI 才有可能从“会回答”走向“能执行”。

七、最后说几句

Palantir 的 Ontology 之所以值得关注，不是因为它把“本体论”这个词讲得多高级，而是因为它把一个抽象概念落到了企业运营系统里。

它告诉我们，企业 AI 的关键不只是模型能力，也不是单独的知识库和工具调用。企业 AI 真正要补的是一层业务语义操作层：

• 让 AI 知道业务世界里有什么；

• 让 AI 知道对象之间如何关联；

• 让 AI 知道哪些动作可以执行；

• 让 AI 知道动作背后的规则和权限；

• 让 AI 执行以后留下可追溯记录。

这就是我认为 Palantir Ontology 值得数据治理、大数据平台和企业 AI 团队认真研究的原因。

大模型是入口，RAG 是知识连接，Agent 是执行形态。但真正决定企业 AI 能不能进入核心业务的，往往是这些更底层、更朴素的东西：

对象、关系、规则、权限、动作、审计。

这些能力看起来不性感，却决定了企业 AI 能不能真正落地。

我正在持续整理《AI时代数据治理实战库》。

它会围绕两条主线展开：

• Data for AI：数据如何支撑 AI。

• AI for Data：AI 如何反过来改造数据治理。

前者是基础，后者是新机会。

如果你关心 AI 时代的数据治理、企业 AI 数据底座、RAG、Agent、元数据、血缘、质量、标准、知识图谱、本体论和 Palantir Ontology，可以扫码订阅知识库。