Palantir AIP Agent 与 Ontology
的交互机制

0. 核心结论

在 Palantir 体系里，Agent 不直接访问底层数据库表，也不自由扫描完整 Ontology schema。它是在被配置和授权的边界内，通过 Ontology 暴露的对象、关系、上下文、函数和动作完成业务交互。

Ontology 是企业业务世界的受治理语义接口；Agent 是通过自然语言使用这些接口的操作员。

你可以把 Ontology 理解为 Agent 的"操作系统"（AgentOS）——Agent 的一切能力都在 Ontology 这个受控边界内运行。

各部分的分工：

• LLM — 理解用户意图，决策下一步
• Retrieval Context — 确定性为 LLM 提供业务上下文，避免 Agent "两眼一黑"
• Ontology — 企业业务对象、关系、函数、动作的语义模型
• Tools — 把 LLM 意图转换成可执行的查询、函数调用或业务动作
• Governance — 约束 Agent 能看什么、能调什么、能改什么，并记录审计与 lineage

1. Ontology 在 Agent 眼里是什么？

Palantir Ontology 是企业的 operational layer，坐在 datasets、virtual tables、models 之上，把底层数字资产映射成现实世界对象。它不是传统数据目录，也不只是知识图谱。

关键理解：Palantir Ontology 的核心不是"把表换个名字"，而是把企业的名词、关系、规则、动作和权限放到同一个受治理的语义层里。

2. Agent 与 Ontology 的交互分层

建议把交互分成五层来看：

3. Layer 1 · Context Layer（Retrieval Context）

Context Layer 的作用是：在用户每次提问时，系统自动给 Agent 提供相关背景。关键特征：确定性触发 — 每条用户消息到达时自动执行，不依赖 LLM 自己判断要不要检索。

3.1 Ontology Context

从 Object Type 检索对象，支持固定对象集（Variable Input）和语义搜索（Vector Embedding）两种方式。

3.2 Document Context

从文档中检索相关内容，支持全文模式和语义 Chunk 模式两种方式。

3.3 Function-backed Context

当内置检索不够用时，用 TypeScript 写自定义检索函数。函数输出 retrievedPrompt 字符串注入 LLM context。适合多数据源、多检索策略、多业务规则组合的复杂企业场景。

4. Layer 2 · Query Layer（Object Query Tool）

Context Layer 是系统自动注入；Query Layer 是Agent 主动查询。Object Query Tool 允许 LLM 在配置边界内访问指定 Object Types 和 Properties，支持 filtering、aggregation、inspection、traversal of links。

三种典型查询模式

5. Retrieval Context 与 Object Query 的关键区别

这是设计 Agent 时最容易混淆的一点。

6. Layer 3 · Logic Layer（Function Tool + AIP Logic）

Agent 查询到对象后，需要调用封装好的业务逻辑，而不是让 LLM 自己"脑补规则"。分工原则：LLM 负责理解意图、选择函数、解释结果；Function 负责执行业务规则、调用模型、做优化计算。

三个典型例子说明为什么不能让 LLM 自己算：

7. Layer 4 · Action Layer

Action Layer 是 Agent 从"问答助手"变成"业务操作员"的关键。Action Tool 让 Chatbot 执行 ontology edit，可配置为自动执行或用户确认后执行。

辅助工具

• Update Application Variable — Agent 改变 Workshop 等应用状态（如"只看华东数据"→ 页面联动刷新）
• Command Tool — 触发其他 Palantir 应用操作（如"在地图上标出这 5 个订单"）
• Request Clarification — 执行前向用户确认模糊指令（如"您指的是哪个订单？"）

8. Layer 5 · Governance Layer

Governance 是 Palantir AIP 和普通 Agent 框架的核心差异之一。它不是单独的一步，而是贯穿全链路的约束机制。

同一 Agent，不同角色 — 权限分层示例

防幻觉的 Governance 约束

用户问"公司今年总营收多少？" → 没有 Governance 的 Agent 可能"脑补"一个数字 → 幻觉。但有了 Governance：

L1 没配置财务 Context → L2 没 FinancialReport Object Type → L3 没授权财务 Function → Agent 只能诚实回答："我没有权限访问公司财务数据"

9. Tool Calling Mode：工具如何暴露给 LLM？

关键澄清：Palantir 不是把整个 Ontology schema 全量塞进 system prompt。更准确的理解是 — 在具体 Chatbot / Application / Workflow 中，被配置、被授权、和当前任务相关的 Ontology 能力，以工具说明、上下文片段、函数签名、动作定义等形式暴露给 LLM。

10. 一次端到端交互链路

下面用一个物流延误风险场景串联全部五层。以下流程是基于官方文档所做的推演，数字均为业务示例值。

11. 内部 Agent 与外部 Agent

上述五层架构主要描述内部 Agent（AIP Chatbot Studio / Workshop / AIP Logic）。外部 Agent 接入时需区分两个机制：

核心原则不变：Agent 通过受治理的 Ontology 接口访问对象、关系、函数和动作，而非绕过 Ontology 直接访问底层数据。

12. 最小可工作版本设计

如果要设计一个类似 Palantir Ontology-aware Agent 的最小版本：

13. 总结

Palantir AIP Agent 与 Ontology 的交互，不是简单的 RAG 架构，也不是 LLM 直接查数据库。它是一个五层协同的 enterprise agent runtime：

真正值得借鉴的不是某一个 tool，而是这套设计思想：

把企业业务世界先建模成可查询、可计算、可执行、可治理的 Ontology，再让 Agent 在这个受控语义层上工作。

参考文档

数据来源：Palantir 官方文档（截至 2026 年 6 月）。推断性内容已在文中标注，数字均为业务场景示例值。