今年，Palantir 作为备受关注的企业，许多用户都希望了解其能力在国内有哪些具体场景可以实现落地。我们也注意到，在某些企业的招投标项目中，已开始将本体论等相关能力列为评估项之一。与此同时，大家也普遍存在一些疑问：Palantir 的核心能力究竟包含哪些？目前国内不少厂商正在对标或学习 Palantir 的能力，并为企业提供相应解决方案，又该如何评估这些能力的具体标准？针对以上问题，今天会分享已有的实践与成果。这一方向我们后续将持续推进，并定期与大家交流相关进展。内容已做精简，如需获取专家完整版视频，请扫码领取。
01
Palantir 核心产品：AIP、Foundry 值得借鉴首先，我们来看一下 Palantir 的核心产品。Palantir 发展了约二十年，其核心产品可归纳为四个。Apollo 是一个集运维、部署与交付于一体的平台。它的主要目标是使上层产品能够适应企业用户多元异构的环境，无论是云端、边缘端还是本地化场景，实现统一的部署、运维和交付。Apollo之上是Palantir两个核心数据平台：Gotham 与 Foundry。- Gotham 主要面向政府与公共领域客户，例如国防、情报与执法机构，用于情报分析与数据决策，因此与大多数企业用户的关联性不大。
- Foundry 则更值得企业用户关注。它主要服务于商业客户，是一个涵盖数据开发、管理、治理到上层服务的企业级一体化平台。它在功能上与常说的“数据中台”有相似之处，但也存在差异。其核心是以本体论（Ontology）为基础，进行数据整合、清洗、建模与可视化应用。许多基于 Palantir 的数据决策类应用，在企业环境中都构建于此平台之上，因此 Foundry 也是目前市场上关注度较高的部分。
最上层是 AIP。它类似于国内常说的智能体开发平台，能够帮助企业快速构建与部署各类智能体应用。总结来说，我们认为值得企业重点关注的，主要是 Foundry 与 AIP 这两个平台：- Foundry 着力于构建 AI-ready 的数据基础；
02
关于 Foundry 这个平台，我们可以将其与我们熟悉的数据架构进行对照理解。传统的数据架构通常包含以下层次：底层是数据仓库、数据湖等数据存储与计算基础；之上是数据集成、开发、治理与服务化的能力层；再往上则是直接面向业务的应用层。
而 Foundry 的一个关键差异，在于它在数据基础与上层应用之间，引入了一个“本体层”，或称统一语义层。这一层的核心在于定义对象（Object）、关系（Link）、逻辑（Logic）与动作（Action）。
因此，其架构可以理解为，底层是数据基础设施，中间是数据中台能力，而Foundry在此基础上新增了一个本体层，其上再对接如 AIP 这类智能体开发平台以及最终的智能体应用。
这一设计的根本价值在于，它使得上层的所有应用能够基于一致的业务语义来理解和处理数据，而不仅仅是进行孤立的数据调取与计算。通过本体层对业务概念、关系与规则进行建模，数据被赋予了明确的业务含义，从而让应用能够真正“理解”业务。这构成了 Foundry 最为核心的能力与创新之处。03
在 Palantir 的本体层设计中，其核心目标在于让 AI 真正理解业务。这一目标通过三个层次来实现，分别是对象层、逻辑层和行动层。首先，对象层的主要作用是统一业务概念。在企业中，不同部门对同一事物的描述和称呼往往存在差异。对象层的任务正是将这些概念进行标准化，形成一致的理解。虽然传统数据平台也尝试通过数据字典等方式实现类似目标，但 Palantir 的独特之处更体现在上层的逻辑与行动两层。
其次，逻辑层的关键在于明确业务规则。它将业务专家的决策经验、流程逻辑等转化为 AI 可以严格执行和理解的规则库。这既包括基于统计的规则引擎，也涵盖传统的机器学习、深度学习等行业小模型。本质上，这一层沉淀了企业业务决策中的所有规则，使 AI 能够基于历史经验和模型进行判断。
最后，行动层则实现了从决策到执行的跨越。传统数据处理往往停留在给出答案的层面，而行动层则将决策结果与实际业务系统的操作相连接。它通过预定义的行动接口，与现有业务系统进行对接和集成，从而驱动整个业务流程的端到端执行。这使得 AI 不仅能分析问题，还能推动具体操作落地。04
在探讨如何用 Palantir 的本体论实现企业内部知识与工具的运营时，我们发现它提供了一条非常清晰的路径。
当前，许多企业都在尝试落地 Agent 应用，但在实践中常遇到一个关键难题：缺乏足够的企业内部知识。
以之前提到的设备运维场景为例，企业可能已定义了设备名称、具备运维巡检和故障维修的基本 SOP 与标准，但仍然缺失大量关键内容。
缺失的主要是两类知识：一是过程性案例与行动记录。过去，维修人员现场解决问题后，很少会将维修过程中的思考逻辑、依据何种规则进行故障判断和选择检修方式的经验沉淀下来。二是具体行动与系统交互。维修中涉及的实际操作，例如去库房领取配件或工具，以及这些行动与现有系统（如库存系统）的关联，通常也未被系统化记录。
然而，当企业试图让 AI 智能体来承担类似任务时，会发现这些知识和数据恰恰是 AI 理解并完成整个流程所必需的。没有它们，AI 无法实现端到端的执行。
此时，在积累这类知识的过程中，又会浮现一个新的问题，企业内可能存在多个场景、多个团队同时在进行知识积累。如果每个团队都按照各自独立的方式和框架去做，最终很可能又形成一堆“知识孤岛”，这些知识仍然无法被统一调用和整合。
而 Palantir 的本体论恰恰为此提供了一个非常好的知识与工具运营思路。它核心是提供一套统一的理念和知识整理框架，能够将各个场景中 AI 所需的知识有效地统一起来，实现整合管理。
具体来说：
对象与关系层，可以对应解决领域专业知识术语、组织架构、岗位职责等静态知识及其关联关系的定义与统一。
逻辑层，则能沉淀内部的决策规则、经验机制和合规要求。例如设备维修中从故障判断到方案生成的背后规则，或是现场施工必须遵守的安全规定，这些都可以纳入此层。它最终沉淀的将是一系列的规则引擎和行业小模型。
行动层，关注的是将思路转化为具体步骤。在判断之后，第一步、第二步要做什么？这涉及到具体的工作流，并且需要与原有的业务系统集成对接，例如从设备管理系统开立工单，从资产管理系统申领物料等。
因此，我们认为本体论在当前市场中的一个重要价值在于，它提供了一个基于统一框架进行知识运营与工具运营的实践思路。这对于系统化构建AI可理解、可运用的企业能力，是一个非常有前景的实现路径。05
接下来，我们谈谈本体论的技术特点，以及它与当前常见技术路径的差异。
大家通常会提到第一代的知识图谱，以及近两年兴起的 RAG，还有两者结合的 Graph RAG 等技术。那么，以本体论为核心的 OAG 与它们究竟有何不同？
首先，与知识图谱相比。知识图谱本质上处理的是对象和关系，它提供的是一个静态的知识网络。它的局限在于，一方面，难以承载动态的逻辑决策；另一方面，也无法驱动具体的行动执行。因此，它更多是呈现一个关系结构，而非一个可运行的决策系统。
其次，与 RAG 相比。RAG 通过检索外部知识来增强大模型的生成，已经引入了动态“思考”的过程。但其主要问题在于精度不足。由于其检索机制与语义相似性，若要获得非常精确的结果，则需在提示词工程和上下文优化上投入大量精力。而且，整个过程高度依赖大模型本身的泛化能力，人为可干预和控制的节点相对有限。
相比之下，基于本体论的路径具有以下明显优势：
1.可执行的决策：它不仅描述知识，还能将逻辑与行动纳入体系，最终输出可落地、可执行的决策或工作流。这是它与静态知识图谱的根本区别。
2.精准的检索：由于本体论在构建时形成了高度结构化的对象、关系、逻辑与行动网络，基于此的检索可以非常精准，直接定位到所需的业务实体、规则或操作步骤，而非模糊的语义近似。
3.深度结构化的上下文：它所提供的上下文具有高度结构化与丰富的业务语义，相比基于文档片段的传统 RAG ，其知识增强效果和理解能力更强。
4.显性化、可调整、可追溯：
本体论构建的规则和逻辑是显性化的，可以图形化地呈现出来。
业务专家能够基于这些显性规则进行审查、优化和调整。
整个分析决策过程是可追溯的。如果最终结果或行动出现错误，可以回溯到中间具体环节，定位问题根源并进行修正。
相比传统的知识图谱与 RAG 技术，本体论驱动的 OAG 在技术的可落地性、精准性、可控性和可解释性上，都提供了显著增强，在实际企业应用中具有比较明显的优势。06
关于其实现方式，从技术路径上看，它与我们熟知的数据平台或知识工程平台有相似之处。传统数据平台通过开发流程构建数据资产，知识工程平台则将碎片化文档与知识组织成图谱结构。而我们可以将这类平台理解为 “数智本体平台”，其核心同样是进行构建，只不过最终产出的是一个统一的语义层，即本体。
该本体一旦构建完成，其全生命周期的管理、迭代、呈现，以及与智能体等应用的对接，都将基于这个平台来实现。因此，整个技术开发和实现的框架，与原有数据平台并无本质差异。
真正的区别和难点在于构建过程本身。与以往一样，它高度依赖业务专家的深度参与，共同完成本体的设计与填充。这一构建的难度和复杂性，目前看来远超传统数据平台中对数据字段的梳理，也高于一般知识图谱的构建。
因此，本体构建并非适用于所有场景。它更适用于那些流程复杂、需要深度推理，且需求具有重复性的业务场景。这一点很关键，如果一个应用场景只是偶尔出现，或解决问题后类似需求不再频繁发生，那么为此构建本体的投入产出比可能不高。
本体构建的价值，恰恰体现在能够反复应对复杂性高、流程化强的重复性问题之上。这才是它最适合发挥作用的领域。
07
API 平台调用本体层能力，构建可执行的 Agent
接下来我们探讨 AIP 这一部分。通常来说，Agent 的落地会涉及几个关键组件：大模型、知识库、流程编排与工具调用。
左图展示了我们以往对 Agent 落地的典型理解，通过一个 Agent 去调用企业的小模型、知识库、辅助流程与工具。这种方式往往是分层、分散的，并且需要部署多种不同能力的 Agent 来逐步完成任务。
而 Palantir 的 AIP 平台在 Agent 开发的产品功能层面，与目前市场上多数的 Agent 开发平台存在较多相似之处，其真正的差异点在于如何更有效地调取本体层的能力。
由于本体层中包含了大量的“行动”，AIP 在设计上会更侧重于与这些行动的安全、可靠集成。相比传统偏静态的工作流实现，AIP 加强了与安全性和合规性相关的优化。例如，它提供了流程模拟功能，允许在实际执行前对整个流程进行预跑，验证其是否能够顺畅执行，如有问题可及时调整。同时，由于许多流程和接口需要与外部业务系统打通，平台在合规与安全层面也会有更多的考量。
因此，从 AIP 这一层来看，目前 Palantir 的产品功能与其他同类 Agent 产品在表面上差异并不显著。它的主要定位，是为了更高效、更安全地调用和支撑下层本体层的能力。这也印证了我们之前的观点，Palantir 目前的核心能力与创新，重点仍在于本体层本身的构建与应用。
08
在与众多企业用户交流时，许多人会提出一个共同问题：面向 AI 时代，企业内部团队应当如何构建？许多企业既拥有自身的 IT 团队，也成立了数字化公司或数据科技子公司。这些团队都需要思考，面对 AI 场景，应该配备怎样的人才，或者现有的 IT 团队需要培养和构建哪些新的能力。
在这方面，Palantir 的应用开发模式提供了一些值得借鉴的思路。从图中可以看到，Palantir 在面向客户时，设有一个专门的 FDE 团队。实际上，绝大多数项目落地交付都由这个团队完成。就公司结构而言，Palantir 主要是将四个核心产品作为工具赋能给 FDE 团队，由该团队面向政府机构或大型企业进行最终的应用落地。FDE 团队内部主要包含两个核心角色：Echo 团队与 Delta 团队。- Echo团队主要负责与客户共同挖掘场景。其核心工作是深入客户交流，一方面展示相关的用例或 Demo，另一方面通过理解客户需求，共同探讨并确定在现阶段，哪些 Demo 或产品方向能够有效解决客户的实际问题，并为客户带来显著价值。
- Delta团队（部署工程师团队）则更侧重于快速实现。他们擅长利用现有工具，通过快速编写代码来构建解决方案和产品原型。目标是让客户能够迅速看到可交互的 Demo，验证其是否真正符合需求，进而将其部署为可运行的产品。Palantir 的模式核心在于，一方面通过与客户紧密共创来挖掘需求、确定场景方向；另一方面依靠强大的工程能力快速构建原型、迭代验证，直至找到真正契合客户需求的解决方案。目前来看，FDE 团队正是这一模式得以有效运行的关键。
09
那么，对于企业用户而言，具体有哪些可以借鉴之处呢？
我们可以看到，传统的开发模式通常是：业务部门提出明确需求，由IT部门承接后，或依靠内部开发团队，或寻找外部供应商。再由产品经理或项目经理统筹，进行 IT 开发与实施，最终上线。整个过程是一个传导链条长、周期漫长的线性流程。
然而，在当前尤其是 Agent 应用的场景下，情况发生了很大变化：它要求开发过程高度敏捷，并且能够快速迭代。
这背后有两层原因：
一方面，从技术角度看，模型本身仍处于持续迭代和快速演进阶段。这意味着更先进的工具会不断涌现，团队需要持续学习和应用新技术，因此必须具备较强的快速迭代能力。
另一方面，从客户或业务部门角度看，Agent 场景有一个显著特点，效果立即可见。与建设一个信息化系统需要很长的开发周期、上线后一两年才能看到效果不同，Agent 应用在开发后能快速呈现结果。
业务部门提出需求，可以迅速验证该需求是否能够被响应和满足。如果可以，再逐步完善。因此，整个建设思路与以往大不相同。
在这种情况下，需要一个关键的中间角色，既要深刻理解业务部门的实际场景与需求，又需要清晰把握 AI 的能力边界。这样，才能基于业务需求快速判断，哪些需求当前能力可以解决，哪些暂时无法解决。
这个角色，我们更倾向于称之为“AI BP”。他/她应该与业务部门站在一起，帮助设计和规划产品或方向。这个角色有点类似于Palantir FDE 团队中的成员，兼具共同设计产品和推动快速部署落地的双重能力。
因此，对于整个IT组织而言，未来的工作方式可能会发生改变：
我们认为 Palantir 的这种模式，以融合业务与技术的敏捷团队为核心，通过快速迭代验证价值，并持续沉淀企业独有的语义层，能够很好地适用于企业面向 AI 的组织转型与场景落地。
粤ICP备14082021号
免费POC，
零成本试错
