Palantir Ontology 技术研究与 TAOS 实现借鉴

1. 研究结论摘要

先说结论：Palantir Ontology 最值得借鉴的地方，并不是它把企业数据做成了“知识图谱”，而是它把企业里的数据、规则、动作和权限，收束到了一套可以被人、应用和 Agent 共同使用的业务对象体系里。

这点很关键。很多企业做 AI 平台时，第一反应是接模型、接知识库、封装工具。但真正落到业务执行时，Agent 面对的往往还是零散接口、散落文档、口径不一的数据表和各自为政的权限体系。Palantir 的思路更接近“先建立企业的业务世界模型，再让 AI 在这个模型里行动”。

我把它拆开看，核心大概是四层：

1. 业务对象建模层：用 Object Type、Property、Link Type、Interface 等抽象表达真实业务世界。
2. 数据映射与索引层：把数据库、数据湖、流数据、文件、外部系统中的数据映射成对象、属性和关系，并构建对象查询、图查询、搜索、时序、地理等多种索引。
3. 行动与逻辑层：用 Action Type、Function、Query、Workflow 等机制，把“查询数据”升级为“触发业务动作”，支持审批、校验、写回、自动化和人机协同。
4. 治理与安全层：把权限、数据血缘、审计、对象级安全、属性级安全、动态安全策略贯穿到对象查询、动作执行和 Agent 工具调用全过程。

对 TAOS 的启发也比较直接：企业级 Agent OS 不能只停留在模型接入、Prompt 管理、MCP 工具网关和知识库问答。它需要一层 Enterprise Operational Ontology（企业运营本体层），让 Agent 面对的是受治理的“客户、订单、产品、门店、套餐、工单、合同、设备、策略、审批”等业务对象，再通过受控 Action 完成业务闭环。

2. 资料池与文献清单

这里需要先说明一点：严格意义上的 Palantir Ontology 学术论文并不多，公开信息主要散在官方白皮书、产品文档、SDK、专利和少量会议论文里。所以这份材料不是单纯的论文综述，而是把这些公开资料放在一起，从工程实现角度反推它背后的设计思路。专利和产品文档里的描述会带有厂商表达，下面的技术推断也会尽量标明边界。

2.1 官方白皮书与技术文档

2.2 官方博客与 AI Agent 资料

2.3 专利与工程实现线索

2.4 学术与研究资料

3. Palantir Ontology 到底是什么

3.1 一句话定义

如果用一句话概括，我会把 Palantir Ontology 理解为企业业务世界的“可执行对象层”。它不是只描述“有哪些实体、实体之间有什么关系”，而是进一步描述“这些对象能被谁看、能执行什么动作、动作如何校验、执行后写回哪里、全过程如何审计”。

3.2 它不只是知识图谱

传统知识图谱偏重“实体、关系、语义查询”，主要回答“是什么、有什么关系”。Palantir Ontology 的重心更偏运营系统，回答的是“基于这些业务对象，我们能做什么、谁能做、做完写到哪里、怎么审计”。

3.3 它也不只是数据中台

数据中台通常重在数据采集、建模、指标、报表、标签和服务。Ontology 往前多走了一步：把数据资产翻译成业务人员、应用系统和 Agent 都能理解的对象，并把这些对象和动作绑定起来。例如：

• 数据中台关心“订单表、客户表、产品表、指标表”。
• Ontology 关心“客户对象、订单对象、产品对象、客户属于哪个组织、订单当前风险、可以发起哪些动作、动作是否需要审批、执行后写回哪个系统”。

所以我更倾向于把 Ontology 看成数据中台和业务应用之间的一层“运营对象模型”。对 Agent OS 来说，这一层尤其重要，因为它决定了 Agent 到底是在“读资料、调接口”，还是在一个受治理的业务世界里工作。

4. 核心抽象模型

4.1 Object Type：业务对象类型

Object Type 是对真实世界实体、事件或业务概念的 Schema 定义。典型对象包括：

• 通信行业：客户、号码、套餐、账单、资费、基站、工单、投诉、营销活动。
• 餐饮行业：品牌、门店、菜品、订单、会员、库存、供应商、员工、班次、活动。
• 制造行业：设备、产线、工单、物料、批次、质量事件、维护计划。
• 政企场景：企业、项目、合同、人员、资产、审批单、风险事件。

Object Type 不应该简单复制数据库表，而应该表达业务用户和 Agent 能理解的稳定业务概念。

4.2 Property：对象属性

Property 是对象的字段和特征，例如：

• 客户对象：客户编号、客户等级、归属区域、ARPU、流失风险、最近投诉时间。
• 门店对象：门店编码、品牌、城市、营业状态、日营业额、客诉率、库存风险。
• 工单对象：工单类型、优先级、当前状态、处理人、SLA 剩余时间。

技术实现上，Property 需要支持：

• 基础类型：String、Number、Boolean、Date、Datetime、Enum。
• 复杂类型：JSON、Array、Geo、Media、Attachment。
• 分析类型：Time Series、Metric、Embedding、Score、Feature。
• 治理属性：来源系统、更新时间、血缘 ID、可信等级、脱敏等级。

4.3 Link Type：对象关系类型

Link Type 描述两个对象类型之间的业务关系，例如：

• 客户“订购”套餐。
• 门店“属于”品牌。
• 工单“关联”客户。
• 设备“位于”站点。
• 菜品“消耗”原材料。

关系需要表达方向、基数、可导航性和安全策略。Agent 的很多推理能力并不是来自大模型本身，而是来自这些明确的业务关系。例如“找出某门店最近 7 天差评上升的原因”，需要沿着门店、订单、评价、菜品、班次、员工、库存等关系搜索。

4.4 Interface 与 Shared Property Type：共享语义

Interface 可以理解为跨对象复用的一组属性和行为。例如：

• 可审批对象：审批状态、申请人、审批人、审批时间。
• 可定位对象：经度、纬度、行政区划。
• 可追踪对象：创建时间、更新时间、来源系统、血缘 ID。
• 可风险评估对象：风险等级、风险原因、评分模型版本。

这类设计能避免每个对象重复定义相似字段，也能让 Agent 使用统一逻辑处理不同对象。例如所有实现“可审批对象”的对象，都可以接入同一套审批 Action。

4.5 Action Type：业务动作类型

Action Type 是 Palantir Ontology 区别于普通知识图谱的关键能力。Action 不是普通按钮，而是受 Schema、规则、权限、审批、审计约束的业务操作。

典型 Action 包括：

• 创建工单。
• 修改客户套餐。
• 调整门店库存预警阈值。
• 发起营销活动。
• 批准价格变更。
• 将设备标记为故障。
• 触发外部系统写回。

Action Type 通常需要定义：

• 输入参数：动作需要哪些字段。
• 作用对象：动作作用于哪些 Object Type 或 Link Type。
• 校验规则：哪些情况下允许提交。
• 权限策略：谁能执行，Agent 是否能执行。
• 审批规则：是否需要人工确认。
• 执行逻辑：规则型更新、函数调用、工作流调用、外部 API 调用。
• 写回策略：写回 Ontology、本地对象库、源系统或消息队列。
• 审计信息：谁在什么时候因为什么上下文触发了动作。

4.6 Function / Query：业务逻辑封装

Function 和 Query 用于封装可复用业务逻辑：

• Query 偏只读，用于对象过滤、图遍历、聚合、指标计算和复杂查询。
• Function 可封装计算、模型推理、外部服务调用和对象编辑。
• Function-backed Action 可把复杂动作逻辑托管给代码执行。
• External Function 可通过 Webhook 与企业内部接口、模型服务、ERP、CRM、工单系统连接。

对 TAOS 而言，这部分可以和 MCP、企业内部 API 网关、工作流引擎结合。MCP 工具不应该只是“裸接口”，而应该挂载到具体对象和动作上。

4.7 Security Policy：对象级安全与动作级安全

Ontology 的安全不是只在页面菜单上做控制，而是贯穿：

• 对象类型是否可见。
• 对象实例是否可见。
• 属性是否可见。
• 关系是否可遍历。
• Action 是否可执行。
• Function 是否可调用。
• Agent 是否可以代表用户执行。
• 输出内容是否可被写入记忆或日志。

这对企业级 Agent 非常关键。Agent 不能因为能调用工具，就绕过企业已有权限体系。更合理的做法是：Agent 继承用户身份、岗位角色、数据域、密级和场景授权，并且每次对象查询和动作执行都进行策略评估。

5. Ontology 的技术实现思路

5.1 总体架构

如果只看产品介绍，很容易把 Ontology 理解成一个“高级数据目录”或“业务图谱”。但从公开文档、SDK 和专利信息综合看，它更像一套元数据驱动的运行时体系。上图里我把它拆成三块：

1. Ontology Language：定义业务世界的语言，包括对象、属性、关系、动作、函数、安全策略。
2. Ontology Engine：执行这套语言，包括对象查询、图遍历、索引、动作执行、事务、写回和订阅。
3. Ontology Toolchain：围绕建模、发布、SDK 生成、应用构建、权限治理、审计运维提供工具链。

这里最值得注意的是 Engine。没有 Engine，Ontology 只是一个漂亮的元模型；有了 Engine，它才能把对象定义编译成查询、索引、权限判断和动作执行。

5.2 数据进入 Ontology：Hydrate

Hydrate 可以理解为“把已有企业数据灌入业务对象世界”的过程。这个过程不只是 ETL，真正麻烦的是把技术字段翻译成业务语义。

我认为这里有几个容易被低估的点：

• 先识别源系统的主键、外键、枚举、时间字段、状态字段和权限字段。
• 再设计业务对象，而不是机械复制表结构。
• 用 Mapping Profile 描述“源字段如何映射为对象属性、源表关系如何映射为 Link”。
• 用 Parser 和 Validator 做数据类型转换、质量校验、标准化和异常记录。
• 对每个对象、属性、关系记录来源、更新时间、血缘和可信等级。

5.3 从对象到行动：Activate

Activate 解决的是另一个问题：对象建好了以后，怎么让它真正参与业务动作。只读对象模型只能支撑分析，绑定 Query、Function、Action、Policy 之后，才会变成可运营的对象层。

例如在通信行业中：

• 客户对象绑定“查询客户画像”Query。
• 套餐对象绑定“适配套餐推荐”Function。
• 客户-套餐关系绑定“变更套餐”Action。
• 高价值客户和敏感资费属性绑定更严格的访问策略。
• Agent 只能通过这些受控 Query、Function、Action 访问和操作业务对象。

5.4 动作执行链路

这条链路也是我认为 TAOS 需要吸收的关键边界：Agent 不应该直接调数据库或裸 API，而是通过受治理的 Action 执行业务动作。这样才能把权限、审批、审计、失败补偿和业务责任都放到同一条链路里。

5.5 对象存储与多后端索引

公开专利和官方资料给人的一个明显信号是：Ontology 后端大概率不是单一数据库，而是一个多后端对象索引体系。不同查询负载交给不同存储会更合理：

• 关系数据库适合存储规范化对象属性、版本、事务和元数据。
• 图数据库适合关系遍历、Search Around、路径查询和网络分析。
• 搜索引擎适合全文检索、模糊匹配、多条件过滤。
• 时序数据库适合 IoT、指标、性能曲线、历史趋势。
• 向量数据库适合文档语义、对象相似度、案例推荐和 Agent 记忆检索。
• 对象存储适合附件、图片、合同、音视频、模型文件。

所以技术关键不在于选一个“万能数据库”，而在于用 Ontology Metadata 作为统一 Schema，把同一个业务对象编译到不同后端索引中，并在查询时由 Engine 选择合适执行计划。

5.6 元数据驱动与 SDK 生成

Ontology 的另一个工程价值是元数据驱动。对象、属性、关系、动作、函数、接口和策略一旦被注册为元数据，就可以进一步生成：

• API 文档。
• TypeScript / Python / Java SDK。
• MCP 工具描述。
• 低代码表单。
• 权限配置界面。
• Action 参数校验器。
• Agent Tool Schema。
• 审计和血缘模板。

换句话说，业务模型一旦沉淀下来，就不只是给人看的建模文档，而会变成人、应用和 Agent 都能调用的“业务操作系统 API”。

6. Ontology 与 Agent OS 的关系

Agent OS 要真正进入企业生产环境，我觉得必须先回答三个问题：

1. Agent 看什么：能否看到正确、最新、受权限控制的业务上下文。
2. Agent 能做什么：能否通过受控动作影响真实业务系统。
3. Agent 做完如何负责：能否记录原因、上下文、执行人、审批人、输入输出和结果。

Ontology 的价值就在这里：它把这三个问题放到了同一个框架里处理。

7. TAOS 可借鉴的企业运营本体设计

7.1 TAOS 中的核心对象

对 TAOS 来说，可以先把企业 Agent 运行中最容易失控、也最值得沉淀的资产对象化：

7.2 TAOS Ontology 元模型建议

7.3 TAOS 技术模块拆分

8. TAOS 中 MCP、Prompt、Skill 与 Ontology 的结合

8.1 MCP 不是接口市场，而是 Action 的执行通道

企业内部接口封装成 MCP 以后，我不建议直接暴露给 Agent 使用。更稳妥的方式是先绑定到 Ontology Action。

例如：

• 裸 MCP 工具：changeCustomerPlan(customerId, planId)。
• Ontology Action：客户.变更套餐。
• Action 治理：校验客户是否存在、套餐是否可售、用户是否有权限、是否需要审批、是否需要记录变更原因、是否要写回 CRM/BOSS。

这样做的好处比较实际：

• Agent 看到的是业务动作，不是技术接口。
• 参数校验、权限、审批、审计统一收口。
• 同一动作可以替换底层实现，不影响 Agent 和应用。
• 动作可以被人、Agent、工作流、低代码应用复用。

8.2 Prompt Asset 应该成为 Ontology 资产

Prompt Library 如果只是一个 Prompt 文本仓库，价值会比较有限。真正能沉淀下来的，应该是 Prompt Asset System。

PromptAsset 建议纳入 Ontology 管理：

• Prompt 类型：Architecture Prompt、Security Prompt、Domain Prompt、Review Prompt、Operation Prompt。
• 适用对象：绑定到 Object Type、Action Type、Agent Role、业务场景。
• 版本治理：草稿、评审、发布、废弃、回滚。
• 质量指标：命中率、满意度、错误率、工具调用成功率、人工修正率。
• 安全策略：是否可用于敏感数据、是否允许外发、是否允许自动执行动作。
• 优化闭环：结合 SkillOpt / PromptOpt 思路，基于评测集和真实运行日志持续优化。

Prompt Governance 的核心不是“谁写 Prompt 快”，而是谁能把 Prompt 变成可治理、可评估、可复用、可审计、可持续优化的企业级资产。

8.3 Skill 管理也应对象化

Skill 是 Agent 的可复用能力单元，可以包括：

• 领域分析技能。
• 工具调用技能。
• 审查技能。
• 摘要技能。
• 规划技能。
• 报告生成技能。
• 代码生成技能。
• 安全检查技能。

SkillAsset 需要记录：

• 输入输出 Schema。
• 可调用工具。
• 依赖 Prompt。
• 依赖知识资产。
• 适用 Agent。
• 权限边界。
• 评测结果。
• 版本和发布状态。

这样 Skill 可以像 SDK、组件库、规则库一样沉淀复用。

8.4 记忆也应该进入 Ontology 治理

企业 Agent 的记忆不能只是向量库里的碎片。我的建议是把记忆拆成四类，再纳入对象化治理：

会话 ID 隔离可以体现在 Session 对象上：

• 每个会话创建独立 Session ID。
• Session 绑定用户、组织、Agent、任务、权限上下文。
• Working Memory、工具调用、临时文件、上下文摘要都绑定 Session ID。
• 跨 Session 复用的信息必须经过摘要、脱敏、权限校验和资产化。
• 高风险场景下，Session 结束后只保留审计摘要，不保留完整上下文。

9. TAOS 落地路线建议

9.1 第一阶段：只读业务对象层

第一阶段不要急着做复杂动作，先让 Agent 和应用“看懂企业”。

关键工作：

• 选择 2 到 3 个核心业务域，例如客户、产品、工单或门店、订单、会员。
• 建立 Object Type、Property、Link Type。
• 接入核心数据源，完成 Mapping Profile。
• 建立对象查询 API、图遍历 API、搜索 API。
• 接入基础权限和审计。
• 让 Agent 通过对象查询回答业务问题。

交付物：

• 业务对象模型。
• 数据映射表。
• 对象查询服务。
• 对象图谱可视化。
• Agent 只读问答 Demo。

9.2 第二阶段：受控 Action 与 MCP 写回

第二阶段再把 Agent 从“问答助手”往“可执行助手”推进，但动作要从低风险场景开始。

关键工作：

• 选择低风险动作，例如创建工单、生成报告、发起审批、查询库存、发送通知。
• 将内部接口封装为 MCP 工具。
• 将 MCP 工具绑定到 Ontology Action。
• 增加 Action 参数校验、权限、审批和审计。
• 支持动作执行结果写回对象层和源系统。

交付物：

• Action Registry。
• MCP Gateway。
• Action Runtime。
• 审批与审计链路。
• Agent 执行动作 Demo。

9.3 第三阶段：Prompt / Skill / Memory 资产化

第三阶段的重点，是把 Agent 能力从个人经验变成企业资产。

关键工作：

• 建立 PromptAsset、SkillAsset、Memory、Decision 等对象。
• 建立 Prompt 版本管理、评审发布、评测优化流程。
• 建立 Skill 注册、依赖管理、评测、灰度发布机制。
• 建立 Session 隔离、上下文摘要和记忆治理。
• 建立运行日志到优化数据集的闭环。

交付物：

• Prompt Asset System。
• Skill Registry。
• Agent Memory Service。
• PromptOpt / SkillOpt 评测优化闭环。

9.4 第四阶段：决策闭环与行业场景复制

第四阶段才适合谈行业复制。前面三步没有跑通时，行业模板往往只是概念包装。

关键工作：

• 将行业对象、动作、Prompt、Skill、Workflow 打包为行业模板。
• 建立场景模拟、方案比选、人工审批、执行反馈闭环。
• 接入 BI、低代码应用、移动端和业务工作台。
• 建立多租户、多组织、多数据域隔离。
• 建立资产市场和复用机制。

交付物：

• 行业 Ontology 模板。
• Agent 场景包。
• 决策闭环工作台。
• 企业级资产市场。

10. 关键设计原则

1. 先业务对象，后技术接口

不要让 Agent 面对表、接口、文档碎片。先抽象客户、订单、门店、产品、工单等稳定业务对象。

1. 对象模型不等于数据库表模型

Object Type 要服务业务理解和行动闭环，不能简单复制源系统表结构。

1. Action 是一等公民

企业级 Agent 的价值不只是回答问题，而是安全、可控、可审计地完成动作。

1. 权限必须下沉到对象、属性、关系、动作和记忆

不能只做菜单权限或接口权限。Agent 访问什么、记住什么、输出什么、执行什么都要受策略控制。

1. Ontology 是运营投影，不一定替代源系统

源系统仍然可以是事实来源，Ontology 负责统一对象视图、操作抽象、写回协调和审计闭环。

1. Prompt 和 Skill 要像代码资产一样治理

需要版本、评审、发布、评测、回滚、依赖、权限和使用统计。

1. 记忆需要治理，不只是存储

企业 Agent 的记忆要绑定 Session、用户、权限、任务、来源和生命周期。

1. 从窄场景做深，再做行业模板

不要一开始就建设全企业大而全 Ontology。优先选择高频、高价值、边界清晰的业务闭环。

11. 对 TAOS 方案的具体增强建议

建议在 TAOS 升级方案中新增一个核心章节：Enterprise Operational Ontology：企业运营本体层。

该章节可以作为 TAOS 的中枢能力，与原有能力关系如下：

建议 TAOS 的技术定位从“企业级智能体管理平台”进一步升级为：

TAOS 是面向企业生产环境的 Agent Operating System，以企业运营本体为核心，将数据、知识、Prompt、Skill、MCP 工具、业务动作、安全策略和 Agent Runtime 统一治理，帮助企业把 AI 从问答能力升级为可控、可审计、可复用的业务执行能力。

12. 面向售前的表达方式

售前场景里，可以用下面这段话解释为什么 TAOS 需要 Ontology：

企业做 Agent，最大的难点不是接入多少模型，也不是封装多少工具，而是 Agent 是否真正理解企业业务世界。TAOS 通过企业运营本体，将客户、产品、订单、门店、工单、合同、知识、Prompt、Skill、工具和动作统一建模，让 Agent 在同一套业务语言下获取上下文、调用能力、执行动作，并接受权限、安全和审计约束。这样，AI 才能从“会回答”变成“会办事、办得准、办得稳、办得可追溯”。

如果客户已经在做知识库、工具平台或 Agent 平台，也可以用下面这个对比表沟通差异：

13. 风险与约束

13.1 过度建模风险

Ontology 最容易走偏的地方，就是一上来做成庞大而沉重的企业模型工程。建议从场景出发，只建当前业务闭环真正需要的对象、关系和动作。

13.2 数据质量风险

如果源系统主数据混乱、字段含义不一致、权限标记缺失，Ontology 只会把问题暴露得更清楚。需要配套数据质量、主数据、血缘和责任人机制。

13.3 写回一致性风险

Agent 执行动作后，可能同时影响 Ontology 对象库和多个源系统。需要明确事实来源、事务边界、补偿机制、失败重试和人工兜底。

13.4 安全复杂度风险

对象级、属性级、动作级、Agent 级权限会显著增加治理复杂度。建议早期先建立清晰的数据域、角色、密级和审批规则，逐步细化。

13.5 Agent 幻觉与误操作风险

Ontology 可以约束 Agent 的输入、上下文和行动边界，但不能完全消除模型幻觉。高风险 Action 必须加入人工确认、规则校验和执行回滚。

14. 最小可行架构建议

如果 TAOS 要做一个可落地 MVP，我建议先从下面这个最小闭环开始：

MVP 不需要一开始就做完整知识图谱和全量对象库。更重要的是验证几个基本问题：

• Agent 是否能通过对象模型稳定理解业务。
• MCP 工具是否能通过 Action 安全执行。
• Prompt、Skill、Memory 是否能资产化管理。
• 权限和审计是否能覆盖一次完整决策链路。
• 业务人员是否能基于对象和动作持续扩展场景。

15. 推荐后续工作

1. 将 TAOS 方案中的知识治理升级为“企业运营本体治理”

不只治理文档知识，还治理业务对象、关系、指标、动作、Prompt、Skill 和记忆。

1. 补充 TAOS Ontology Studio 设计

包括对象建模、关系建模、数据映射、动作配置、权限配置、版本发布和影响分析。

1. 补充 TAOS MCP Action Gateway 设计

明确 MCP 工具如何注册、如何绑定对象、如何纳入权限、审批和审计。

1. 补充 TAOS Prompt / Skill / Memory 资产模型

将 Prompt Library、Skill 管理、上下文摘要、会话隔离和记忆治理统一到 Ontology Asset 体系。

1. 选一个行业样板做 PoC

对通信客户可以选择“客户-产品-资费-工单-营销”闭环；对餐饮客户可以选择“品牌-门店-订单-会员-库存-评价”闭环。