企业 Agent 如果只是回答制度、产品或业务问题，RAG 往往是最先想到的方案：把相关资料找出来，交给模型生成答案。
但用户开始要求 Agent 查订单、改工单、触发业务流程时，问题就变了。系统不仅要找到相关资料，还要识别具体业务对象，读取它的当前状态，并在权限和规则允许的范围内执行动作。
这也是理解 Palantir Ontology 的入口。它不是用来替代 RAG 的另一套检索技术。从 Palantir 的产品分工看，RAG 主要给回答补充依据，Ontology 则把业务对象、当前状态、确定性逻辑和受控动作组织到一个操作层。
先看一个工单场景：Agent 同时接入了知识库和工单系统，既能查规则，也能查询和修改工单。
知识库里写着一条规则：生产中断或重大安全风险，应设为 P0。用户随后要求：
把 PDS-124 改成 P0。
系统可以检索到规则，也可以正确解析这条指令，P0 还是合法参数。但如果 PDS-124 已经关闭，这个修改就不该执行。
找到规则、读到工单的当前状态、真正修改工单，是三件事。它们可以共用一个聊天框，底层却不能只靠一套 RAG。
同一个聊天框可以接收三类任务，但三条路径不表示固定执行顺序
RAG 找到的是依据，不一定是当前事实
Lewis 等人在 2020 年的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 中，把预训练生成模型与外部非参数化记忆结合起来。论文里的外部记忆，是由神经检索器访问的 Wikipedia 稠密向量索引。
本文用 RAG 指代一种更宽泛的工程用法：它可以检索 PDF 和网页，也可以接数据库查询和 API；检索方式也不只向量搜索。这不是对 RAG 的统一学术定义。
Palantir 自己就没有把 Ontology 放在 RAG 的对立面。它的 Ontology-augmented generation 文档介绍了文档切块、Embedding、关键词搜索、HyDE、查询增强、混合检索和 RRF 排序。文档块可以被建模为带媒体引用等属性的 Chunk 对象。
所以，“RAG 只能处理文档，Ontology 才能处理对象”并不准确。
分界在这里：检索能给当前回答补材料，但一段材料不会自动变成一套持续运行的业务系统。
RAG 能找到 P0 的规定并附上来源，但这段规定回答不了：
- PDS-124 是哪一张工单；
- 它现在是 Open 还是 Closed；
- 当前优先级是什么；
- 谁有权修改它；
- 状态不符合条件时，系统是否应该拒绝。
数据库、API、权限系统和工作流可以分别补上这些能力，RAG 也可以接入它们。Palantir 的做法是围绕 Ontology，把它们组织成一套共享的业务操作模型。
Ontology 先把“哪一个”说清楚
Palantir 将自己的 Ontology 定义为组织的 operational layer，也就是业务操作层。它位于数据集、虚拟表和模型之上，把这些数字资产连接到设备、产品、订单和交易。这是 Palantir 的产品定义，不是行业对 ontology 的统一定义。
它有两类基础元素：
- 语义元素：Object、Property、Link；
- 动能元素：Action、Function、Dynamic Security。
Object Type 是现实实体或事件的类型定义，Object 是具体实例。Demo Ticket 可以是对象类型，PDS-124 是一张具体工单。
它看起来很像数据表和数据行。Palantir 的核心概念文档也用 Dataset 对应 Object Type、Row 对应 Object、Join 对应 Link Type。
但把表改名为 Object Type，不算建好了 Ontology。Palantir 的 Ontology 设计指南把“Model reality, not systems”列为第一条：对象代表现实实体，不代表某张数据库表、某个 API 响应或某个部门眼里的副本。
一行数据里可能同时有订单号、客户邮箱、商品 SKU 和购买数量。不能因为它们挤在同一行，就全部塞进一个 OrderData。应该拆出 Order、Customer 和 Product，再用 Link 表达关系。
据 Palantir Ontology 设计原则重画，仅作建模示意
这样做更贵，但目标很清楚：同一个客户，在系统里只有一个稳定身份。前提是主键、身份映射和跨来源对齐都做对。否则，Ontology 只是把三套混乱的数据重新包装了一次。
Object 说清楚“具体是哪一个”，Link 表达“它和谁有关”，Property 保存或派生状态。数据接入及时、身份映射正确时，系统可以按主键读取 PDS-124，不用从一堆提到工单的文字里猜。
模型理解了请求，Action 仍然可以拒绝
Palantir 官方的 Demo Ticket 教程很简单，正好能看清状态和动作的边界。
教程中的 Demo Ticket 只有四个属性：
| Ticket ID | Title | Status | Priority |
|---|---|---|---|
| PDS-123 | Demo Ticket One | Open | P2 |
| PDS-124 | Demo Ticket Two | Closed | P1 |
官方接着定义了一个 Change Ticket Priority Action：
- 新优先级只能是 P0、P1 或 P2；
- Ticket 的 Status 必须是 Open；
- 条件不满足时，Action 不会运行；教程要求配置失败提示，向用户说明原因。
据 Palantir 官方 Demo Ticket Action 教程重画，仅展示参数约束与 Submission Criteria
再看开头那条指令：
把 PDS-124 改成 P0。
假设模型已经正确解析这条指令，P0 也是合法参数。但 PDS-124 已经关闭，Action 不会运行。
“改优先级”不复杂，真正要看的是这套分工：
LLM：理解用户想做什么
Object：提供 PDS-124 的当前状态
Action：限制参数并检查提交条件
权限、Action 规则与编辑配置：共同约束是否可以执行模型听懂了，不等于条件成立。参数填对了，也不等于有权执行。
“只修改 Open Ticket”可以写进提示词，但不能只写在提示词里。必须执行的约束，要在模型之外校验状态和权限。
Palantir 的权限检查比“有权限才能操作”复杂。对单数据源对象，用户通常要能看到对象，并通过 Submission Criteria。多数据源对象要按编辑目标继续检查：修改属性、删除对象、创建 Link，规则并不相同。用户看不到的其他数据源属性，在部分校验中还可能以 null 出现。
看得到，不等于什么都能改。还要看改什么、能看到哪些数据源，以及 Action 规则和提交条件。
Function 把业务判断从提示词里拿出来
简单的 Action 用参数和规则就能配置。逻辑复杂了，再交给 Function。
Function 运行在服务端隔离环境中，可以读取对象属性、遍历 Link、查询 Object Set、计算聚合（见 Functions 文档）。Function 也可以生成 Ontology edits，但要实际应用这些编辑，仍须通过 function-backed Action；在 Action 外运行编辑函数，不会改动对象数据。
在官方的 Function-backed Action 教程中，一个带 @OntologyEditFunction() 注解的函数读取 Demo Ticket，再修改标题。这个功能没什么业务含量，工程细节更值得看：Function 要先发布，Action 引用一个明确版本。默认情况下，Function 发布新版后，Action 不会自动升级；也可以显式启用 Auto upgrade，让 Action 按设定的兼容版本范围解析可用版本。
业务逻辑可以离开提示词，进入代码、测试、发布和版本管理。它仍可能写错，但至少能审查、测试和追踪版本。
真实业务里的 Function 可以筛选候选项、遍历对象关系、计算风险。但这不等于 Foundry 自动保证所有外部系统的分布式事务。Ontology 编辑、外部 API 和通知副作用能否保持一致，要看具体实现。
一个聊天框，三套能力
把同一段对话拆开，系统至少要处理三类任务。
| 用户任务 | 主要路径 | 系统应该交付什么 |
|---|---|---|
| 什么情况应该定为 P0？ | 文档检索 | 规则原文、出处和适用条件 |
| PDS-124 当前是什么状态？ | 对象查询 | 按稳定身份读取的当前事实 |
| 把 PDS-124 改成 P0 | 受控 Action | 权限、参数和条件检查后的结果 |
它们可以由同一个 Agent 编排，但不能混成一件事：
文档说明应该怎么做
Object 说明现在是什么情况
Function 提供可测试的业务逻辑
Action 控制允许怎样改变状态从这套分工看，我的理解是：这些正是 Ontology 在文档检索之外试图接住的东西。
这不是 Palantir 独有的实现。数据库、API、知识图谱、规则引擎、权限和工作流也能组合出类似能力。Palantir 的做法，是让它们围绕一套共享对象模型协作。
统一不等于可靠。数据不新、身份没对齐、权限配错、Action 漏了条件，Ontology 一样会出错。
上线前，先问六个问题
一个 Agent 演示可以查政策、找订单、改状态。真要放进业务里，我会继续问：
- 业务对象有没有稳定身份？
- 当前状态来自哪个系统，什么时候更新？
- 对象关系由系统明确维护，还是由模型临时推断？
- 必须稳定执行的业务规则写在哪里？
- 谁能读，谁能执行状态变更？
- Action 失败、数据冲突和外部写回分别怎样处理？
这些问题答不上来，聊天框再流畅，也可能只是给知识问答套了一个“能办事”的外壳。
总结
有了 RAG，Palantir 为什么还要 Ontology？
因为找到资料只是起点。AI 还要知道眼前是哪一个业务对象、它现在是什么状态、当前用户能做什么，以及什么条件下系统必须拒绝。
企业 Agent 从“会回答”走向“能办事”，不能只加检索。它还需要一层业务对象、确定性逻辑和受控动作。Palantir 把自己的这一层叫作 Ontology。
