一、一个让工程师头疼的问题

大模型接入企业系统之后，有一类问题最难解决：模型给的答案，外行读起来头头是道，内行读起来胡说八道。

举个例子。你让 AI 帮你决策"明天哪批原材料可以优先入库"，它给出了一份排序合理、逻辑自洽的清单。但你的库管主管一眼就看出问题：清单里第一位的供应商，合同上有一条"季度末不接收入库"的条款，今天恰好是季度末倒数第二天。

模型没有撒谎。它只是不知道那条合同条款的存在。

这类错误，工程师通常把它归结为"幻觉"。但准确地说，这不是幻觉，是因为大模型不懂业务规则。模型的问题不在于它在概率上算错了，而在于它根本没有接触过那条约束它行为的"业务规则"。

解决这个问题，需要的不是更大的模型，而是一个不同的架构层——业务本体层。

二、数据中台做了什么，没做什么

过去十年，国内企业数字化最流行的架构选择是数据中台。它解决了一个真实且重要的问题：把散落在各业务系统里的数据统一起来，建立一致的指标口径，给报表、分析和决策提供可信的数据来源。

这件事做成了。大多数完成数字化建设的企业，今天都有一张能出实时报表的数据大屏。

但数据中台有一个根本性的设计边界：它只管数据的流动，不管业务的逻辑。

它能告诉你"这个供应商今年交货了 1200 次"，但不知道这个供应商的合同当前是否处于合规状态；它能告诉你"库存余量是 8000 件"，但不知道这 8000 件里哪些已经被预占、预占的优先级是什么、谁有权调整。

把这张数据表直接喂给大模型，模型拿到的是一堆精确的数字，但没有数字背后的运转规则。它能做出看起来合理的推断，但无法保证推断在你的业务现实里成立。

这就是 Palantir Foundry 出现的背景。

三、Foundry 不是更好的数据中台

很多人第一次看 Foundry 的产品介绍，会以为它是一个功能更强的数据平台。这个理解是错误的。

Foundry 的核心不是数据处理能力，而是在数据层之上引入了一个新的层次：Ontology（本体层）。这一层的职责是把数据从"记录事实"升级为"描述规则"——不只存储对象，还存储对象之间的关系、允许的操作、前置约束和连锁反应。

两者的本质区别如下：

详细来说：

这张表里最关键的一行是"对 AI 的约束"。传统数据中台的设计假设是：AI 只负责分析，人负责决策和执行。但 Agentic AI 的出现打破了这个假设——AI 开始执行操作，而不只是给出建议。如果 AI 能直接写入系统，而系统没有业务规则层来约束它，出问题只是时间问题。

四、本体层在 IT 架构中的位置

理解了 Foundry 的定位之后，再来看它在整体 IT 架构里的坐标。

从下到上，一个完整的架构包含四层：

L1 源系统：ERP、CRM、生产控制系统、IoT 传感器——原始数据的产生地，通常是割裂的、异构的。

L2 数据仓库 / 数据湖：对源系统数据进行清洗、加工和沉淀。ODS → DWD → DWS 是国内最常见的建模范式。这一层输出的是结构化的事实数据，但没有业务语义。

L3 业务本体平台：这是 Foundry 的核心所在。它不重新存储数据，而是在数据之上建立语义模型——Object（对象）、Link（关系）、Action（操作）。这一层向下拉取 L2 的清洗数据，向上为 L4 的 AI 应用提供受约束的操作接口。它是数据层和应用层之间的语义枢纽。

L4 业务消费层：AI Agent、业务应用、决策看板——所有的消费者都通过 L3 的本体接口与数据和业务交互，而不是直接访问底层数据库。

这个架构有一个重要的意义：AI 看到的世界，是被本体层"翻译"过的世界。它看到的不是原始表，而是有名字、有关系、有规则的业务对象。

五、本体为什么能解决"幻觉"问题

回到开篇的问题——为什么大模型会给出"业务上错误"的答案？

本质原因是：LLM 的结构是基于概率计算的，所以它一定会有幻觉，这和是否微调没什么关系，而且它的边界是自然语言，而业务的决策边界是规则空间。 两者之间没有等价关系。

以文章开头的案例为例，看一下有无本体层的差异：

没有本体层时：用户问 AI"明天哪批原材料优先入库"→ LLM 读取供应商表和库存表 → 基于概率推断给出排序 → 排序里有一个条款异常的供应商 → 执行后违约。

有本体层时：

1. 用户的问题被转化为对 Supplier 和 InboundOrder 两个 Object 的查询
2. AI 识别出需要执行 schedule_inbound 这个 Action
3. Action 的前置条件检查：Supplier.contract_status == 'active' 且 today NOT IN Supplier.restricted_dates
4. 系统发现该供应商的 restricted_dates 包含今日 → Action 被阻断，AI 自动转向下一个候选
5. 最终执行的操作，已经通过了所有业务规则的校验

这个拦截发生在系统层面，不依赖 prompt 工程，不依赖模型的"理解能力"。哪怕你用的是一个刚上线的小模型，只要它调用的是同一个 Action，就会经历同一套约束校验。

这是本体层解决幻觉问题的核心机制：把业务规则从"模型应该知道的事"变成"系统强制执行的约束"。前者依赖概率，后者是确定性的。

六、一个完整流程的拆解

用一个供应链场景把上面的机制走一遍。

场景：AI Agent 接到任务——"为 Q3 扩产 15% 补充备料，生成采购建议并提交审批"。

Ontology 里的定义：

• Object：Supplier、Material、PurchaseOrder、Contract、ProductionPlan
• Link：Supplier → Material（携带属性：交货周期、最低采购量、合规认证有效期）
• Action：create_purchase_order，前置条件：合同状态有效 + 采购金额未超预算 + 供应商认证未过期（30天内视为"即将过期"，需额外审批）

Agent 的执行过程：

   1.读取 ProductionPlan 对象，计算 Q3 扩产所需的物料缺口

   2.查询 Supplier 列表，通过 supplies Link 找到可供货的供应商

   3.对每个供应商调用 create_purchase_order Action：

• 供应商 A：合同状态正常，金额在预算内 → Action 执行，生成草稿工单
• 供应商 B：认证有效期剩余 18 天 → Action 标记"需额外审批"，自动通知采购负责人
• 供应商 C：合同状态为"暂停" → Action 被阻断，Agent 跳过并记录原因

   4. 将通过校验的工单汇总，提交至审批工作流

整个过程，LLM 负责理解任务、拆解目标、选择操作序列；Ontology 负责校验每一步操作的合法性。AI 的聪明，和系统的安全，分别由不同的机制保证，互不干扰。

七、理解这套架构的意义

Palantir 花了将近十年把这套架构做到生产可用，覆盖军事情报、供应链、金融风控等对决策准确性要求极高的场景。Foundry + AIP 是目前工程上把本体和大模型结合得最完整的实现。

它的价值不在于"用了 AI"，而在于解决了 AI 进入企业写操作环节时最根本的信任问题：如何保证 AI 的每一次操作都在业务规则的边界之内。

对架构师来说，这套架构有两点值得借鉴：

第一，业务规则应该是一等公民，不是散落在代码里的条件判断，而是可以被查询、被审计、被 AI 读取的结构化资产。

第二，AI 与业务系统之间需要一个中间层。这个中间层不是 prompt 模板，而是真实的业务语义模型，带约束、带权限、带写回能力。

至于这个中间层是 Palantir 的 Foundry，还是你自己构建的轻量本体引擎，取决于你的规模和预算。但架构原则是相通的。

八、下期预告

理解了 Object、Link、Action 这套语法之后，下一个问题是：如果我们要为自己的系统从零设计一套本体层，应该怎么建？

第三篇从一个具体的业务场景出发，把 Object 定义、Link 约束和 Action 校验逻辑一步步拆开来讲，把本体从概念变成可以真正运行的工程实现。

本体不是 Palantir 的专利，它是一种工程方法论。理解它，才能真正评估什么时候用它、用多深、用在哪里。