内容摘要
报告通过调研全球领先的数智化转型服务商 Palantir，分析其如何面向大型企业客户，解决数据整合、业务协同、运营决策和流程执行等方面的关键问题，并借助大模型与智能体能力推动企业级人工智能应用落地。报告旨在通过研究 Palantir 的产品体系与实践路径，了解行业最新发展趋势，为公司数字业务发展提供概念性启示。
当前AI行业中，能够将大模型应用转化为持续收入增长和利润改善的企业并不多，Palantir是其中较有代表性的案例。
Palantir（无官方中文译名）是一家面向政府和大型企业的数据与人工智能软件公司，主要在企业既有数字系统基础上整合分散数据、建立业务模型，并将数据分析和人工智能能力应用于运营管理、辅助决策和业务执行。其基础平台中，Foundry负责连接ERP、MES、WMS、QMS等不同系统中的数据，Ontology则按照企业实际运行方式，将数据建模为订单、设备、工单、库存、质量问题等业务对象，使原本分散在不同系统中的数据形成关联，并能够进一步服务于经营分析、风险识别和运营决策。
在此基础上，Palantir于2023年推出AIP，即用于接入大模型和智能体能力的企业级人工智能平台。AIP建立在Foundry的数据整合和Ontology的业务建模能力之上，使大模型和智能体能够理解企业数据、调用业务工具，并逐步应用于国防、制造、能源等复杂业务场景。2022年至2025年，Palantir营业收入增长至约2.3倍，归母净利润由亏损3.74亿美元转为盈利16.25亿美元。
总结而言，Palantir的做法可以概括为：以企业数据连接和治理为基础，围绕实际业务场景构建业务对象、关系模型和可执行流程，在此基础上引入大模型和智能体能力，进一步提升企业在问题识别、决策辅助和业务执行方面的效率。
Palantir与智奇在服务范围上存在差异，但两者在AI应用路径上具有一定相似性。Palantir并不以自主研发通用基础大模型为主要方向，而是将外部模型能力与自身原有的数据平台和业务经验结合起来。智奇目前同样主要处于AI应用端，并已围绕MES、MOM、WMS、QMS、设备数据采集和数字驾驶舱等方向开展数字业务。因此，Palantir如何在既有数字系统和业务场景基础上引入大模型，对智奇进一步探索AI与数字业务的结合具有一定参考价值。
报告共分五章展开：第一章说明研究Palantir的背景与意义；第二章梳理Palantir的产品体系；第三章分析AIP将大模型和智能体引入企业业务场景的应用逻辑；第四章选取典型应用案例进行说明；第五章归纳Palantir的成功路径，并结合公司实际提出相关启示。
正文
1
为什么研究Palantir
1.1 Palantir率先通过大模型实现盈利
Palantir是一家面向政府及大型企业客户的数据与人工智能软件公司，核心业务是通过Foundry、Ontology和AIP等平台，帮助客户连接分散数据、建立业务模型，协助企业提升生产经营决策效率。
与以训练通用基础大模型为主的企业不同，Palantir更强调把数据、模型和工具嵌入业务场景，使AI能够参与生产运营、供应链管理、设备运维、风险控制和任务决策等复杂流程。
当前AI产业链中，既有OpenAI、Anthropic等专注于基础模型研发的技术提供者，也有微软、谷歌等提供云平台和AI基础设施服务的科技巨头，还有大量围绕具体业务场景开发AI应用的行业解决方案企业。如果从模型能力的角度来看，Palantir并非最突出的AI企业。报告选择 Palantir 作为研究对象，核心原因不在于其拥有最强的大模型，首要原因在于其是少数实现 AI 商业价值规模兑现的企业。
过去两年，大量AI企业实现了模型能力的进步，但从商业结果看，能够实现收入增长和客户扩张的AI公司并不少见，真正稀缺的是将技术投入持续转化为稳定利润的商业模式。尤其是以大模型研发为核心的企业，普遍面临超高算力投入和持续资本支出压力，需要长期承担模型训练、推理服务等高额成本，普遍面临资本投入大、盈利模式跑不通等问题，长期处于增收不增利的状态。
在这一背景下，能够持续验证AI商业价值并实现规模化盈利的企业少之又少。Palantir是其中较具代表性的案例。2023年推出AIP（企业AI平台）后，公司将大模型和智能体能力接入原有的数字系统中，在政府、能源、制造等复杂组织场景中实现商业化落地。伴随AIP业务扩张，Palantir的经营表现显著改善。以AIP推出前的2022年与2025年相比，公司营收增至约2.3倍，归母净利润由亏损3.74亿美元转为盈利16.25亿美元。
图1 Palantir 2022-2025财年实现营收与利润双增
对于大多数AI应用企业而言，基础模型和算力技术的发展固然重要，但相关技术路线往往由少数头部厂商主导，应用企业更多是技术成果的使用者而非决定者。相比之下，如何将现有AI能力与业务场景深度结合，形成可复制、可盈利的商业模式，才是更具现实意义的问题。从这一角度看，Palantir作为少数较早实现AI商业价值规模化兑现并持续盈利的企业，其发展路径具有更强的研究价值。
1.2 从AI产业分层看Palantir的研究价值
当前AI产业大致可以分为三个环节：
上游是基础设施层，包括英伟达、AMD等算力芯片企业，以及微软Azure、亚马逊AWS、谷歌云等云计算基础设施提供商；
中游是模型层，包括OpenAI、Anthropic、Google DeepMind等基础模型研发机构；
下游是应用层，即将大模型能力与具体行业场景、业务流程和组织运营相结合的企业，其核心任务是把AI能力转化为可落地、可衡量、可持续创造价值的业务成果。
对于智奇而言，基础设施层和模型层虽然重要，但并不是公司当前重点参与的领域。智奇是这些技术的使用者，需要根据市场发展情况选择合适的算力、模型和工具，而不是直接参与底层技术研发。
相比之下，AI应用层更接近智奇的现实需求。智奇正在探索的是如何将成熟的AI能力与数字化产线、数字系统、智能装备等具体场景结合起来，形成能够提升效率、降低成本、改善质量、支撑决策的实际业务成果。
基于这一研究取向，在众多AI应用企业中，Palantir具有较强代表性。
一方面，Palantir并不以自研通用基础大模型作为主要竞争壁垒，而是通过AIP接入和管理不同来源的大语言模型及其他AI模型，并将模型能力与企业数据、业务对象和工作流程相结合，转化为面向具体场景的应用能力。Palantir官方资料显示，AIP支持来自OpenAI、Anthropic等不同厂商的模型，也支持企业接入自有模型。
另一方面，Palantir的平台通常建立在企业既有数字化基础之上，通过连接ERP、MES、WMS等业务系统及相关数据资产，进一步形成跨系统的数据整合、业务建模和流程协同能力。这与智奇目前围绕MES、MOM、WMS、QMS等系统开展的数字业务具有较强关联，也使Palantir的技术路径对智奇具有更直接的参考价值。
1.3 问答式AI难以直接转化为企业级生产力
自生成式AI快速发展以来，大模型在文本生成、知识问答、代码辅助、办公协同等领域迅速形成示范效应。ChatGPT等产品的广泛普及，使社会各界第一次直观感受到人工智能在信息处理和内容生成方面的能力跃迁。但从企业级应用角度看，当前很多AI使用仍停留在个人层面的“增强型搜索引擎”和“智能办公助手”阶段：它可以帮助个人更快查资料、写文档、做总结、改代码，但这种效率提升更多是局部的、分散的、个体化的，并不必然转化为企业整体生产力。
企业真正关心的不是员工个人少花了多少时间写一份材料，而是AI能否进入经营活动的核心环节，能否打通数据、流程、决策和执行，能否在质量、成本、效率、安全、交付等关键指标上形成可衡量的改善。换言之，AI从“好用的个人工具”走向“有价值的企业能力”，其中间隔着企业数据体系、业务流程、组织协同和管理机制这几道门槛。只有当AI不再只是回答问题、生成内容，而是能够嵌入具体业务场景，参与流程运行、辅助管理决策、驱动现场执行，并最终带来效率提升、成本下降、风险控制或收入增长时，AI才真正完成了从技术示范到经营价值的转化。
因此，大模型应用的重点正在从“能不能回答问题、能不能生成内容”，转向“能不能理解业务、能不能调用工具、能不能推动任务”。例如，在制造业中辅助生产调度和设备维护，在能源行业中优化资源配置和风险管理，在医疗领域支持诊疗流程和运营管理。要实现这些目标，仅依靠模型本身的推理和生成能力远远不够，还需要让模型能够理解组织内部的数据结构、业务规则和管理逻辑，并与现有系统实现深度连接。
这一变化意味着，企业AI建设的核心不再只是模型能力本身，而是围绕模型构建数据连接、进行业务建模、实现流程协同。企业级AI竞争的关键正在从“谁拥有更强的模型”，逐步转向“谁能够更有效地将模型嵌入真实业务场景”。只有当AI能够在安全可控的前提下参与业务流程，并与企业现有的信息系统形成协同，才能真正实现从技术能力到商业价值的转化。
在这一背景下，Palantir正是这一阶段的重要代表案例。与许多聚焦模型研发的企业不同，Palantir并非以自研通用基础大模型作为主要竞争壁垒，而是通过数据整合、业务建模、流程协同和AI应用平台建设，将不同模型能力嵌入复杂组织场景之中。其发展路径为观察AI如何从技术创新走向组织级应用、如何实现商业价值落地提供了具有代表性的研究样本。
1.4 智奇业务场景与Palantir的企业级应用逻辑具有相似性
智奇正在拓展的机车车辆轮对智能造修产线及数字化系统，与Palantir所服务的企业级应用场景虽然在行业属性和业务内容上存在差异，但在客户特征、业务复杂度和系统要求等方面具有相似性。
从客户类型看，智奇主要面向铁路局、主机厂、车辆段所等大型组织和政府关联客户。此类客户通常组织层级较多，职责边界和管理流程明确，内部数据分散于生产、质量、设备、物料和经营管理等不同系统，跨部门、跨系统协同难度较高。相关数字化项目不仅需要实现具体业务功能，还需要适应客户既有的管理制度、信息系统、权限体系和安全要求。
从业务属性看，轮对生产与检修、智能装备和数字化产线均属于安全责任较高、过程控制严格的工业场景。其业务运行涉及工艺标准、设备状态、质量检测、作业记录、人员操作和责任追溯等多个环节，任何数据偏差、流程失控或操作错误，都可能影响产品质量、生产效率乃至铁路运输安全。因此，此类项目不能仅依靠标准化软件产品完成，还需要对客户业务流程进行深入理解，并具备较强的系统集成、现场实施和持续运维能力。
从基础能力看，智奇已积累MES、WMS等生产运营系统的开发与落地经验，并具备数字驾驶舱、设备数据采集和产线系统集成能力。依托对轮对制造与检修业务的理解，智奇已初步具备推动业务系统、现场设备和管理流程协同贯通的基础。
因此，研究Palantir的意义不在于简单复制其产品体系或商业模式，而在于理解其如何以数据整合、业务理解、工程实施和复杂场景运维等既有能力为基础，引入大模型和智能体技术。这一路径对于智奇推动AI能力与轮对智能造修产线、数字化系统及客户实际业务场景深度融合，具有一定的方法论参考价值。
2
Palantir产品体系
引言
Palantir的产品体系并非围绕大模型一次性构建，而是在长期服务政府、国防和大型企业客户的过程中逐步演化形成的。早期，Palantir主要通过Gotham情报系统服务政府和国防客户，帮助其整合分散信息、识别复杂关系并支持任务决策。在此过程中，公司逐步积累了复杂系统集成、业务建模、跨环境部署和持续运维等工程化能力，并将相关能力延伸至商业企业市场。
围绕企业级应用，Palantir逐步形成了由Foundry、Ontology、Apollo共同构成的产品体系。Foundry负责连接和治理企业分散于ERP、MES、WMS、QMS等系统中的数据；Ontology将底层数据组织为订单、设备、工单、库存等业务对象，并定义对象之间的关系和可执行动作；Apollo负责软件在公有云、私有云、本地数据中心、边缘设备和隔离网络等复杂环境中的部署与持续运行。
图2 Palantir产品发展历程
2.1 核心产品功能概述
在Palantir的产品体系中，Foundry、Ontology和Apollo并不是彼此割裂的独立模块，而是围绕复杂组织的业务运行过程形成的一套连续能力。Foundry负责将分散数据接入并进行治理，Ontology负责将数据转化为业务对象和可执行动作，Apollo则保障整个平台能够在复杂环境下持续部署和稳定运行。
图3 Palantir产品架构
2.2 Foundry：企业数据整合与运营平台
Foundry是Palantir面向商业企业的核心运营平台。它不替代ERP、MES、WMS、QMS等业务系统，而是将这些系统中的数据接入、治理和组织起来，形成统一、可信、可分析、可操作的企业运营基础。从能力结构看，Foundry并不是单纯的数据仓库或BI工具，而是由数据集成、数据管道、数字孪生、动态调度、流程挖掘流式处理等能力共同组成的企业运营平台。
核心能力（一）：Data Integration，数据连接与集成。
数据连接与加工是Foundry构建企业数据基础的起点。它通过连接器、数据库接口、API和流式数据接口，将分散在不同系统中的数据持续接入统一平台。其处理对象既包括订单、库存、质量记录等结构化数据，也包括JSON、传感器数据、图片和文档等不同类型的数据。
图4 数据流经foundry平台的交互式视图
数据接入后，Foundry将其组织为统一的数据集，并通过数据生产管道（Pipeline Builder），对原始数据进行清洗、字段映射、格式转换、关联、聚合和计算。Pipeline Builder提供可视化和代码两种开发方式，使用者可以添加数据源、配置转换逻辑、预览处理结果并生成输出数据集，使接入平台的原始数据逐步转化为可供分析和业务应用使用的标准数据。
图5 Pipeline Builder工作流程
Foundry支持批量同步、增量同步、变更数据捕获和实时流式处理，可根据数据规模和更新频率选择不同的数据处理方式。例如，ERP中的订单数据、MES中的工序数据、QMS中的质量数据以及设备系统中的状态数据，可以在保留原系统运行方式的基础上，在Foundry中完成匹配和关联，形成跨系统的业务数据基础。
核心能力（二）：Dynamic Scheduling，动态调度
动态调度用于解决复杂业务环境中的计划调整和资源配置问题。当订单、设备、人员或供应条件发生变化时，企业可以根据最新业务状态重新安排任务，减少静态计划与实际执行之间的偏差。
在技术实现上，Foundry通过Ontology将调度任务和相关资源定义为可关联的业务对象。调度对象用于表示生产任务、检修任务或运输任务，并记录开始时间、结束时间和持续时长；资源对象则可以表示人员、设备、车辆、场地或项目。任务与资源之间的分配关系、时间依赖和业务约束共同构成调度模型。
业务人员可以通过Workshop中的甘特图和日历组件查看任务计划、资源占用及相互依赖关系，并通过拖拽方式调整任务时间或重新分配资源。系统可依据企业预先配置的规则校验时间冲突、资源条件和任务约束，也可以通过建议函数标识可安排和不可安排的时间区间。计划调整确认后，可通过Ontology Action更新业务对象或触发相关流程，使调度结果进入实际业务执行。
图6 Foundry dynamic scheduling工作流程
核心能力（三）：Process Mining，流程挖掘与过程优化
Process Mining用于识别企业业务流程的实际运行情况。Foundry通过连接订单、工单、维修、质量和审批等业务数据，记录业务对象在不同状态之间的流转过程，并生成可交互的流程图，还原流程真实执行路径。
业务人员可以将实际流程与标准流程进行比较，识别异常流转、重复退回、等待时间过长和流程瓶颈，并进一步定位相关业务对象和影响环节。例如，可用于分析质量问题闭环周期、维修任务停滞、生产工单流转异常和审批效率偏低等问题。
图7 Process Mining工作流程
核心能力（四）：Real-Time Alerting与Streaming，实时警报与流式处理
Real-Time Alerting与Streaming用于解决企业运营中的实时监控和及时响应问题。对于设备异常、生产波动、质量偏差和交易风险等事项，仅依靠周期性报表或事后分析往往难以及时处置。Streaming能够持续接入和处理设备状态、生产过程、交易行为及传感器等实时数据，使Foundry及时获取业务运行状态。
在实时数据基础上，Real-Time Alerting可以针对数据集、业务对象和时间序列配置监控规则。当相关指标达到阈值、业务状态出现异常或数据变化符合特定条件时，系统自动生成警报，并关联相应的设备、订单、工单或风险事项。
图片8 Real-Time Alerting工作流程
2.3 Ontology：把数据转化为业务对象和可执行动作
Ontology是Palantir产品体系中的核心业务操作层。Foundry能够将ERP、MES、WMS、QMS、设备系统、数据库和文档系统中的数据接入平台，并完成清洗、转换和治理，但完成数据整合并不等于系统已经理解企业如何运行。
图9 Ontology用户操作界面
企业实际经营并不是围绕数据表和字段展开，而是围绕订单、产品、设备、工序、工单、库存、人员和质量问题等具体业务对象展开。这些对象之间存在复杂关系，同时还受到业务规则、操作权限和管理流程的约束。
Ontology的作用，就是将企业分散的数据、模型、业务规则、可执行动作和安全要求组织到一套统一的业务体系中。它不仅描述企业中“有什么”，还描述这些业务对象“如何关联、如何判断、能够执行什么操作，以及谁可以执行”。
Palantir将Ontology的核心能力概括为Data、Logic、Action和Security四个方面。
图10 Ontology技术架构
核心能力（一）：Data——将分散数据组织为业务对象和关系
Data解决的是“企业中有哪些业务对象，以及这些对象之间存在什么关系”的问题。
传统数据平台主要以数据表、字段和指标组织信息。例如，设备状态可能存储在设备管理系统中，生产任务存储在MES中，物料库存存储在WMS中，质量异常记录在QMS中。即使这些数据已经被接入同一个平台，它们仍然可能只是相互独立的数据记录。
Ontology将不同数据源中的信息映射和组织为统一的业务对象、对象属性和对象关系。例如，可以将订单、产品、工序、设备、工单、库存、供应商、质量缺陷和人员分别定义为业务对象，并建立以下关系：
·某项订单包含哪些产品；
·某种产品需要经过哪些工序；
·某道工序由哪些设备执行；
·某台设备当前关联哪些工单；
·某个质量问题可能影响哪些产品和订单。
完成建模后，平台面对的就不再只是“设备状态表中的某条异常记录”，而是“某台具体设备发生异常，并可能影响相关工序、生产工单和客户交付”。Data层的核心价值不是简单汇集更多数据，而是按照企业真实业务结构重新组织数据，使不同系统中的信息能够围绕同一业务对象形成关联。
核心能力（二）：Logic——将业务规则和模型连接到业务对象
Logic解决的是“系统应当如何分析和判断业务状态”的问题。仅仅知道设备、订单和工单之间的关系，还不足以支持业务决策。系统还需要了解企业采用什么规则判断异常、如何计算风险、如何预测结果，以及不同情况下应当采用什么处理逻辑。Ontology可以将业务规则、计算函数、机器学习模型、预测模型和优化模型与具体业务对象连接起来。例如：
· 根据设备温度、振动和历史故障记录计算故障风险；
· 根据订单进度、设备状态和物料库存判断交付风险；
· 根据产能、工序约束和订单优先级优化生产计划；
· 根据质量检测结果判断是否需要触发复核或隔离流程。
这些逻辑不再孤立地运行，而是围绕统一的业务对象进行计算。模型输出也可以成为对象的属性或状态，例如将“故障概率”“预计完工时间”或“订单风险等级”直接关联到相应设备、工单和订单。Logic层的作用，是把企业经验、管理规则和算法模型转化为可持续运行的业务判断能力。
核心能力（三）：Action——将分析结果转化为业务操作
Action解决的是“系统完成判断后，可以进一步采取什么行动”的问题。
传统数据分析平台通常止步于发现问题、生成报表或提供预警。Ontology则进一步将可以执行的业务动作与具体对象连接起来，使系统不仅能够说明发生了什么，还能够支持人员或AI推动后续处理。
例如，当设备发生异常时，可以围绕设备对象设置以下动作：
· 创建维修任务；
· 调整设备运行状态；
· 发起质量复核；
· 通知设备或生产负责人；
· 申请调整生产计划；
· 查询和申请所需备件；
· 将处理结果写回MES、ERP或设备系统。
相关动作可以由业务人员在应用界面中发起，也可以由自动化流程或AI智能体在授权范围内调用。对于风险较高的操作，可以要求人工审批；对于规则明确、风险可控的任务，则可以按照预设条件自动执行。
通过Action，Ontology将业务对象、判断逻辑和系统操作连接起来，使数据分析结果能够进一步进入业务流程，而不只是停留在看板和报告中。
核心能力（四）：Security——将权限和治理嵌入业务全过程
Security解决的是“谁可以看到什么、调用什么逻辑、执行什么动作，以及相关过程如何被记录”的问题。
在大型企业、政府和工业场景中，同一业务对象可能涉及多个部门和不同责任人员。不同用户对设备、订单、人员和质量数据的访问权限不同，对业务动作的执行权限也不同。AI智能体同样不能无限制地访问数据或操作系统。
Ontology将权限、安全规则和数据治理机制与对象、逻辑和动作共同建模。例如：
· 哪些人员可以查看某类设备或订单；
· 哪些部门可以访问质量异常和人员信息；
· 哪些用户可以调整生产计划；
· 哪些动作必须经过审批；
· AI智能体可以调用哪些数据和工具；
· 每次数据访问、判断和操作如何记录与追溯。
这种安全机制并不是在业务应用建成后再额外增加，而是贯穿数据访问、模型调用和动作执行全过程。业务人员、应用程序和AI智能体均需要在相应权限边界内运行。
Ontology的整体作用
Data、Logic、Action和Security共同构成一套企业业务运行模型。以设备异常为例：
· Data识别发生异常的是哪台设备，以及它关联哪些工序、工单和订单；
· Logic判断异常原因、故障风险及其对生产和交付的潜在影响；
· Action提供报修、复核、通知和计划调整等处置方式；
· Security决定哪些人员或AI可以查看相关信息和执行操作。
Ontology的核心作用，是将数据、判断逻辑、可执行动作和安全规则组织为统一的业务模型，供业务人员、软件应用和AI智能体共同使用。它连接Foundry底层数据与上层业务应用，将分散数据转化为可理解、可操作的业务对象，使Palantir由数据分析进一步延伸至业务操作。
2.4 Apollo：复杂环境下的软件部署和持续运行底座
Apollo主要解决Palantir软件如何在不同客户基础设施和网络环境中完成部署，并在投入运行后实现持续升级、统一管理和稳定运维的问题。相比Foundry和Ontology，Apollo不直接承担数据分析、业务建模或AI应用功能，而是为上述平台能力在客户现场的长期运行提供技术支撑。从实际应用看，Apollo可以理解为在传统私有化部署基础上，进一步叠加持续交付、版本控制和集中运维能力。
核心能力（一）：跨环境部署能力
大型政府、国防、能源和制造客户通常同时使用公有云、私有云、本地数据中心、专用网络和边缘设备，部分关键业务还需要运行在断网或物理隔离环境中。不同环境在基础设施架构、网络条件、安全等级和变更要求等方面存在较大差异，难以采用完全统一的云端部署方式。
Apollo通过统一的软件部署和环境管理机制，使Foundry、AIP及相关软件产品能够根据客户现场条件，运行于云端、本地、边缘或隔离网络等不同环境。其作用并不是改变客户既有基础设施，而是在不同环境之间建立相对统一的软件交付方式，降低因基础设施差异带来的重复适配和现场实施成本。
核心能力（二）：持续交付与版本管理
企业级软件完成首次部署后，仍需要持续进行功能升级、缺陷修复、安全补丁更新和配置调整。对于分布在不同客户和不同网络环境中的软件系统，如果长期依赖工程人员逐一进行现场操作，容易造成交付效率低、版本不一致和变更风险较高等问题。
Apollo通过发布通道、部署计划、维护窗口和回滚机制，对不同运行环境中的软件版本和配置进行统一管理。新版本可以先在测试环境或部分运行实例中进行验证，在满足既定条件后再逐步推广至其他生产环境。
核心能力（三）：安全合规与稳定运行
在软件投入运行后，Apollo还承担不同环境下的软件运行管理职责。平台可以集中掌握各客户现场的软件版本、配置状态、部署进度和异常信息，帮助运维人员及时识别版本偏差、升级失败、配置错误和安全风险。
对于安全和合规要求较高的客户，Apollo还可以将访问权限、变更审批、安全检查和环境限制纳入发布过程，使软件变更按照客户既有的管理要求受控执行，并保留相应的版本、配置和操作记录。
3
AIP核心机制：大模型如何进入业务流程
引言
AIP是Palantir在大模型时代推出的企业AI平台，但它并不是一个简单的企业版ChatGPT，也不是在Foundry上增加一个智能问答窗口。AIP是一套面向复杂组织的AI业务操作入口，其核心作用是把大语言模型、企业数据、Ontology业务对象、工具调用、权限治理、审计追踪和工作流连接起来，使AI能够在受控条件下参与业务分析、任务生成和流程执行。
普通大模型应用的基本逻辑是“用户提问—模型回答”，适合用于文本生成、知识问答、文档总结、代码辅助等相对轻量的场景。但在大型企业、政府、国防、能源、制造等复杂组织中，AI如果要进入真实业务流程，仅仅会回答问题远远不够。它还必须知道企业内部有哪些数据、这些数据代表什么业务对象、对象之间有什么关系、哪些动作可以被执行、谁有权限执行、执行结果如何追溯，以及关键动作是否需要人工确认。
AIP要解决的正是这个问题。它不是让大模型孤立地面对一堆文档和数据表，而是把大模型放入Palantir已有的数据和业务操作体系中运行。Foundry提供数据接入、治理和运营基础；Ontology把数据转化为业务对象、对象关系和可执行动作；AIP在此基础上接入大模型、Agent、工具调用和自动化能力。由此，AI不再只是一个回答问题的工具，而是可以在权限约束和人工确认机制下，参与业务判断、任务生成和流程闭环的操作入口。AIP的价值不是“让AI更会聊天”，而是“让AI能够在复杂组织的业务边界内安全、可控、可追溯地做事”。
图11 AIP应用示例
3.1 AIP不是企业版ChatGPT，而是AI业务操作入口
很多企业在理解大模型应用时，容易将其等同于智能问答工具。比如，员工输入一个问题，系统根据已有知识库或文档内容生成回答；或者用户上传一份文件，系统帮助总结、改写和提炼。这类应用能够明显提升个人办公效率，但它距离企业核心业务流程仍然有较大距离。
原因在于，企业经营活动不是单纯的信息问答，而是由数据、系统、流程、权限和责任共同构成的复杂过程。例如，在制造企业中，设备异常并不只是一个“故障描述”问题，它可能影响某道工序、某个工单、某批订单、某个客户交付节点，甚至影响库存、采购、质量复核和人员排班。如果AI只能生成一段分析意见，却不能识别受影响的业务对象、调用相关数据、形成处置任务、进入审批或执行流程，并将处理结果反馈至业务系统，那么其作用仍主要停留在信息辅助层面。
AIP与基础知识库问答或办公助手类应用的主要区别正在于此。后者通常以自然语言交互为核心，其基本过程可以概括为“用户提问—模型回答”；AIP则将模型能力接入企业数据、Ontology业务对象、工具动作、权限规则和工作流程。AIP不仅回答“发生了什么”，还可以进一步辅助判断“影响了哪些业务对象、应当采取什么措施、由谁负责处理、哪些操作需要审批，以及执行结果应当记录在哪里”。
AIP把大模型的语言理解、推理和生成能力，与企业内部的数据平台、业务对象、权限规则和工作流连接起来，使AI能够围绕具体业务对象展开工作。例如，当用户询问某条产线为什么交付风险上升时，系统不应只给出一段概括性解释，而应能够关联订单、工序、设备、工单、库存、人员和质量数据，识别风险来源，并生成可供负责人确认的处置建议。
因此，AIP的价值不在于提供一个更智能的聊天窗口，而在于使AI从“问答工具”进入“业务流程”。它让大模型不再只是外部的信息生成工具，而是嵌入到企业数据、业务对象和工作流中的操作能力。这也是AIP区别于普通SaaS+AI和企业知识库问答系统的关键所在。
图12 AIP应用示例
3.2 安全接入多类型大模型：把模型变成可治理的能力组件
AIP的第一个核心机制，是把大模型从一个外部工具转化为企业内部可管理的能力组件。Palantir并不把AIP建立在某一个单一模型之上，也不强调必须由自身训练通用基础大模型，而是支持将不同来源的大语言模型接入平台，并根据不同场景进行调用。
图13 AIP可自由选择启用的AI模型
这种设计有两个重要意义。
一方面，AIP的重点不是“哪个模型最强”，而是“模型如何在企业场景中被安全使用”。在企业级应用中，模型能力固然重要，但更重要的是数据能否受控、不同业务场景能否选择不同模型、模型输出能否被评估，以及敏感数据是否会被外部模型服务不当使用。
另一方面，多模型架构有利于企业根据具体场景选择适用模型，降低对单一模型技术路线的依赖。不同业务场景对语言理解、推理、代码生成、多模态处理、响应速度、运行成本和部署环境的要求并不相同。企业可以在平台允许的模型范围内，根据任务特点选择相应模型，并结合使用效果、成本和安全要求进行调整。
除大语言模型外，企业已有的机器学习模型、预测模型和优化模型，也可以通过Foundry和Ontology与业务对象、逻辑和流程结合，共同参与分析和决策。由此，AIP并不是孤立地调用一个大模型，而是将不同AI能力纳入企业现有的数据与业务运营体系。
AIP通过统一的模型接入和治理机制，让大模型成为平台能力的一部分，而不是游离于业务系统之外的外部工具。由此，AIP解决了大模型进入企业的第一道门槛：模型可以被接入，但不能无边界地接入；模型可以被调用，但必须在企业设定的数据、权限和安全规则之内被调用。只有先把模型变成可治理的能力组件，后续的业务理解、工具调用和流程闭环才有基础。
3.3 通过Ontology提供业务上下文：让大模型理解业务对象和关系
大模型具备自然语言理解和生成能力，但并不天然掌握企业内部的具体业务结构。它可以理解“设备异常”“订单延迟”“库存不足”等概念的一般含义，却不知道某家企业具体有哪些设备、工序、工单和库存，也不了解这些业务对象之间的实际关系、运行状态和责任边界。
因此，要让大模型进入真实业务流程，仅将数据和文档提供给模型并不充分，还需要按照企业实际运行方式组织相关信息，使模型能够在权限约束下识别业务对象、获取业务上下文并调用相应工具。这正是Ontology在AIP体系中的关键作用。
第二章已经介绍，Ontology是Palantir体系中的业务语义与操作层。它将分散在ERP、MES、WMS、QMS、MDC、SCADA、文档系统和数据库中的数据，映射和组织为业务对象、属性及其关系，并进一步连接业务逻辑、可执行动作和安全权限。例如，在制造场景中，可以将订单、产品、工序、设备、工单、库存、供应商、质量缺陷、人员、任务和风险建模为相互关联的业务对象。
有了Ontology之后，AIP调用的不再只是孤立的数据表和文档，而是经过统一建模和治理的业务上下文。模型可以围绕“某台设备”查询其状态和关联对象，也可以围绕“某项工单”获取相关工序、订单、人员、物料和质量信息。在相关数据、对象关系和判断逻辑已经完成配置的前提下，AI可以由单纯解释数据，进一步分析业务影响并形成处置建议。
以设备故障为例，基础知识库问答应用通常可以根据设备手册和历史文档，回答某类故障可能由哪些原因引起。基于Ontology运行的AIP则可以进一步调用当前业务数据，关联该设备所属产线、正在执行的工序、相关生产工单、备件库存、历史故障记录和责任人员，分析设备异常可能对生产和交付造成的影响。如果Ontology中还配置了相应的Actions，AIP可以进一步形成维修、质量复核、人员通知或生产计划调整等处置任务，并根据权限和风险等级，提交人员确认或在授权范围内执行。
因此，AIP与基础知识库问答应用的区别，不仅在于能够获取更多信息，更在于其可以围绕业务对象调用数据、逻辑和动作。知识库问答主要提供信息检索与内容生成，而基于Ontology的AIP可以进一步连接业务状态、判断逻辑和执行流程。
3.4 通过工具调用与Action机制：把回答转化为任务和流程
工具调用是指模型在自然语言生成之外，根据任务需要调用经过授权的外部功能或接口。在AIP中，相关工具可以包括Ontology对象查询、Foundry函数、AIP Logic、业务规则、计算模型、Ontology Action以及其他应用命令。
图14 AIP可调用的工具类目
例如，AI可以查询设备历史维修记录和实时状态，调用质量判定规则，检索备件库存，计算订单延期风险，并根据分析结果形成维修建议或待审批事项。这样，模型不再只是给出一般性建议，而是可以利用企业已有的数据、函数和业务能力完成分析与处置的部分环节。
Ontology Action则用于定义围绕业务对象可以执行的具体操作。例如，可以为“设备”对象定义创建维修任务、更新运行状态和通知责任人员等动作；为“质量缺陷”对象定义发起复核、调整状态和升级处理等动作；为“工单”对象定义调整计划、变更状态和提交审批等动作。
以设备异常为例，在相关数据、对象关系、函数和业务流程已经完成配置的前提下，AIP可以查询设备状态和历史记录，关联受影响的工序、生产工单和备件库存，分析异常可能造成的影响，并形成维修任务或处置方案。如果相关动作需要审批，系统可以提交责任人员确认；如果属于规则明确、风险可控的操作，也可以在授权范围内自动执行。质量、工艺和生产管理人员还可以根据预设流程参与后续复核和协同处理。
3.5 通过权限、审计和人工闭环：把AI控制在业务边界内
大模型具有一定的不确定性，可能出现幻觉问题。在一般办公场景中，相关结果通常可以由使用者判断和修正；但在生产、质量、安全、调度、财务和国防等关键业务场景中，若AI输出将进一步触发系统操作或影响实际决策，就需要建立相应的权限控制、过程留痕和人工监督机制。
在AIP相关应用中，模型和智能体对企业数据、业务对象、工具及Action的访问和调用，受到Foundry与Ontology权限体系、应用配置及运行身份的共同约束。权限控制决定其可以读取哪些数据、调用哪些工具和执行哪些业务操作，避免越权获取信息或直接影响超出授权范围的业务系统。
审计与日志机制用于记录AI参与业务流程后的关键操作和结果。例如，Foundry可记录操作主体、操作时间、涉及资源及相关行为；对于Ontology Action，还可记录Action提交、关联业务对象、参数及对象编辑结果。对于需要进一步分析AI决策过程的场景，还可结合应用日志、Agent proposal和决策记录等能力进行追溯。
人工闭环机制则由企业根据业务风险和责任边界进行配置。对于高风险、责任明确或影响实际生产经营的事项，可由AI完成信息检索、分析和方案建议，再由具备权限的人员审核确认后执行；对于规则明确、风险可控的重复性任务，则可在限定范围内配置自动执行或自动化处理。
3.6 通过评估和可观测能力：让AI可测试、可监控、可迭代
大模型输出具有一定的不确定性，同一问题在采用不同模型、提示词或上下文信息时，可能产生不同结果。因此，AI要进入生产级业务流程，必须具备可测试、可评估、可监控和可持续改进的能力。
AIP通过评估和可观测能力为此提供支撑。对于AI工作流或Agent，企业不能仅凭主观感受判断其输出是否合理，而需要建立测试用例、评价标准和版本对比机制。例如，用于设备故障分析的AI流程，应当在不同故障类型、数据完整程度和历史记录条件下进行测试；用于质量缺陷复核的AI流程，则需要将其判断结果与专家意见或历史处理结果进行比较。通过持续评估，企业可以判断模型和Agent的准确性、稳定性及其是否需要进一步优化。
可观测能力主要解决AI运行过程能否被监控和定位的问题。企业不仅需要关注最终输出，还需要了解AI工作流调用了哪些数据、模型和工具，经过了哪些执行环节，各环节耗时多少，以及是否出现异常。复杂Agent通常需要经过多轮数据查询、模型推理和工具调用才能完成任务，如果缺少对执行过程的记录和监控，出现问题后就难以定位具体环节。
图15 AIP提供可灵活二开的自定义应用
4
Palantir在制造业场景中的应用实践
引言
Palantir的企业级AI应用并不局限于单一行业，而是广泛服务于政府、国防、能源、航空、汽车、电子制造、食品制造等大型组织客户。尤其在制造业场景中，Palantir通常不是以单点软件工具的形式进入企业，而是围绕企业既有信息系统、生产运营数据和业务流程，帮助客户打通分散数据、建立业务对象模型，并将数据分析、人工智能和流程执行能力嵌入实际生产经营环节。为进一步理解Palantir在制造业中的落地方式，本章选取松下和两个具有代表性的案例，分析Palantir如何将平台能力转化为具体业务价值。
4.1 松下能源：面向电池智能工厂的生产现场AI应用
松下能源是Palantir近年来在制造业领域的重要案例之一，其特点在于直接面向电池制造工厂的生产现场，将产线、设备、传感器、质量检测和维护活动连接起来，服务于高节拍、高质量要求的生产过程。
电池制造本身就是一个对数据和过程控制要求极高的行业。产线节拍快，设备连续运行时间长，质量缺陷容忍度低，材料、工艺参数、设备状态和检测结果之间又存在复杂关联。一个质量误判，可能造成合格产品被报废；一个设备异常，可能影响整条产线的节拍；一个材料批次或工艺参数波动，也可能在后续检测、良率和客户交付中体现出来。因此，电池工厂的智能化不是简单增加几套AI模型，而是要把现场数据真正组织起来，让质量、设备和生产执行之间形成连续反馈。
松下能源最初面临的问题，正是许多制造企业在推进智能工厂时都会遇到的问题：数据并不是完全没有，而是散落在不同设备、不同系统和不同人工流程中。产线边缘传感器在采集数据，MES等系统在记录生产过程，质量检测系统在输出结果，维修和异常处理也有自己的工单记录，但这些信息如果不能被统一理解和关联，就很难支撑现场人员做出及时判断。过去很多环节还需要人工汇总、人工判断、人工流转，数据分析容易滞后，也容易出现口径不一致。
Palantir在松下能源的切入，并不是先部署某一个单点AI模型，而是先为工厂建立统一的数据基础。产线传感器、设备运行信息、生产记录、质量结果和现场运营数据原本分散在不同系统和环节中，现场人员往往需要反复查询、人工汇总，才能判断问题发生在哪里。
以质量检测为例，视觉模型识别出缺陷后，真正有价值的并不只是“发现了缺陷”，而是进一步判断缺陷与哪条产线、哪台设备、哪个材料批次或哪段工艺有关。只有将检测结果与生产过程和历史记录结合起来，企业才能区分偶发问题与系统性问题，并据此开展质量追溯、工艺调整或设备排查。计算机视觉由此不再只是一个单点识别工具，而成为质量判定和持续改进流程的一部分。
设备维护也是同样的逻辑。对于连续运行、节拍较高的电池产线，设备问题不仅影响维修本身，还会进一步影响产能、良率和交付。将设备状态、运行参数、历史故障和维护记录放在同一业务视图下，有助于现场团队更早识别异常趋势，判断是否需要干预，并在维护安排与生产节奏之间作出平衡。
Palantir在制造业中的价值并不只是“把数据打通”，也不只是“把AI模型接进来”。更关键的是，它把工厂里原本分散的数据、对象和流程组织成一个可以持续运行的业务体系。质量检测、设备维护、材料追溯、生产判定等应用，表面上是不同功能，底层其实依赖同一套现场数据和业务对象关系。正因为有了这个底座，AI应用才不只是一次性项目，而可以随着工厂运行不断积累数据、优化判断、反馈到生产过程。
4.2 李尔：面向汽车零部件制造的AIP与制造操作系统应用
李尔是Palantir在汽车零部件制造领域较新的代表案例。与松下能源更偏向单个工厂现场不同，李尔的案例更能体现Palantir在大型制造集团中的作用：它不是只解决某条产线、某个设备或某个质量模型的问题，而是把制造、质量、供应链、采购、财务、设计等多个环节放到同一个运营体系中，让AI参与更复杂的企业运营决策。
李尔是一家全球汽车零部件供应商，业务主要覆盖汽车座椅和电子电气系统。面对不同整车厂、车型和订单需求，李尔需要同时协调采购、生产、物流、质量和交付等多个环节；订单变化、原材料波动、关税调整或供应链中断，都可能迅速影响整体运营。
传统管理方式下，这些环节往往由不同系统分别支撑。采购系统记录供应商和物料价格，生产系统记录产线节拍和工单状态，质量系统记录缺陷和返工，财务系统掌握成本和利润影响，设计部门管理产品结构和变更信息。但当市场需求、客户订单、供应链价格或政策环境发生变化时，企业真正需要的不是分别查看各个系统的报表，而是快速判断：哪些产品受影响，哪些工厂需要调整，哪些订单存在风险，哪些产线可以重新平衡，哪些成本变化会影响经营结果。
Palantir在李尔的价值，正是把这些原本分散的业务信息组织到一个统一的运营体系中。Foundry负责连接企业已有数据和系统，AIP把AI能力引入业务流程。这样一来，平台不只是展示数据，而是围绕订单、产线、物料、工厂、客户、质量问题和成本变化等具体对象，帮助业务人员理解问题、判断影响并采取行动。
例如，在产能出现瓶颈的场景中，问题并不只是“某条线产能不足”。产线是否需要调整，背后要同时考虑客户订单、产品结构、物料供应、人员安排、设备状态、质量风险和交付时间。普通系统往往只能分别反映这些信息，真正的协调仍然依赖人工经验。Palantir的做法，是把这些因素放到同一个业务视图中，使管理人员能够看到某一项变化对多个环节的影响，并基于系统建议重新安排产线、调整优先级或推动相关部门处理。
在关税和成本管理场景中，李尔的需求也不是简单计算某项税率变化，而是判断政策变化如何影响不同产品、供应商、工厂、客户项目和财务结果。对于全球制造企业来说，关税、原材料价格和跨区域供应链调整会直接影响产品成本和利润水平。Palantir通过连接供应链、采购、生产和财务数据，使企业能够更快识别风险敞口，并为业务调整提供依据。
流程自动化也是李尔案例中的重要部分。大型制造企业中存在大量跨部门、重复性、规则复杂但又无法完全标准化的流程，例如异常处理、审批流转、数据核对、问题跟踪和任务分派。过去这些工作往往依靠邮件、Excel、会议和人工协调推进，效率低且过程难以沉淀。AIP进入后，AI可以基于企业内部的业务对象和权限规则，辅助生成任务、解释异常、推荐处理路径，并把处理结果沉淀回平台。
李尔案例中值得关注的，不是某一个单独功能，而是Palantir在制造企业内部形成了一种新的连接方式。质量问题不再只是质量部门的记录，供应链变化不再只是采购部门的信息，产线波动也不再只是生产部门的局部问题。它们被放到同一套运营体系中，相互之间的影响关系变得更加清晰。业务人员能够围绕具体对象开展协同，而不是围绕各自系统反复对账和沟通。
这一点也是Palantir与普通“统一工作平台”的区别。普通平台往往解决的是入口统一和流程线上化问题，用户可以在一个界面里打开不同系统、提交不同表单、查看不同报表。但李尔案例所体现的能力更进一步：平台把数据、对象、关系和动作组织起来，使业务人员不仅能看到问题，还能理解问题如何传导，并推动相关动作落地。
5
Palantir企业级AI的成功经验
引言
如果说普通数据平台更多解决“数据可视化”的问题，普通AI应用更多解决“知识问答”的问题，那么Palantir进一步解决的是“数据和AI能不能进入真实业务流程”的问题。它不是停留在看板展示、智能问答或单点算法应用，而是进一步连接企业数据、业务判断和任务执行，推动AI进入实际业务流程。
综合来看，Palantir企业级AI落地的成功逻辑主要体现在三个方面：一是选择复杂、高价值和高进入门槛的客户场景；二是抓住从数据分析向业务动作延伸的关键环节，使AI不再停留在展示和问答层面，而是进入任务生成和流程执行；三是并非以全面替代客户既有系统为主要路径，而是在ERP、MES、WMS、QMS等系统之上构建跨系统的数据与业务操作层。
5.1 选对了复杂的高价值场景
Palantir首先形成差异化的地方，在于长期聚焦政府、国防和大型企业等复杂组织场景。这类客户通常存在数据来源分散、历史系统众多、业务流程复杂以及权限、安全和责任追溯要求较高等问题，单一软件模块或通用AI工具难以直接进入其核心业务流程。
这类项目的实施难度也相对较高。客户可能同时使用公有云、私有云、本地数据中心、边缘端和隔离网络，不同部门之间还存在数据标准、系统接口和权限规则差异，因而往往具有销售周期长、部署成本高和项目风险较大的特点。但也正因为如此，这些场景对数据整合、跨系统协同、权限治理和持续运维提出了更高要求，为Palantir沉淀产品能力并形成竞争壁垒提供了基础。
相比主要服务于文本生成、知识问答和办公提效的轻量AI应用，Palantir更强调让数据和AI进入生产、供应链、设备运维、风险管理和任务决策等实际业务流程。复杂场景虽然实施难度更高，但其问题价值、客户投入和系统嵌入程度也相对更高，是Palantir企业级AI平台形成差异化的重要基础。
对智奇而言，铁路局、主机厂和动车段所等客户同样具有业务流程长、系统环境复杂、质量安全要求高等特点。Palantir的实践表明，相较于通用化AI工具，围绕问题明确、业务价值较高且能够嵌入核心流程的场景开展探索，可能更有利于形成差异化能力和可持续应用价值。
5.2 抓住了“数据到业务动作”的关键环节
Palantir形成差异化的另一个关键，在于其平台能力不止停留在数据展示和分析层面，而是进一步向任务生成和流程执行延伸。
传统数据平台和BI系统主要侧重数据汇总、指标分析和可视化展示，帮助用户识别异常、趋势和经营结果。但在复杂组织中，发现问题只是业务处理的起点。后续还需要判断异常影响哪些业务对象、可能由什么原因造成、应当采取什么措施、由谁负责确认，以及处置结果如何反馈至原有系统。
多数通用AI应用则主要侧重知识检索、内容生成和分析建议。如果AI无法进一步调用业务工具、生成任务或进入审批和执行流程，其作用仍以信息辅助为主，尚未形成完整的业务闭环。
Palantir通过Foundry、Ontology和AIP，将数据、业务逻辑和可执行动作连接起来。Foundry负责接入和治理企业数据；Ontology将数据组织为设备、订单、工单、库存等业务对象，并定义对象之间的关系和可执行动作；AIP则使大模型和Agent能够基于这些业务对象开展分析、调用工具和生成任务。其基本链路可以概括为：数据 → 业务对象 → 分析判断 → 任务生成 → 人工确认 → 执行与结果反馈。
这种机制使平台不只是提示“某项指标出现异常”，还能够进一步分析异常涉及哪些对象、可能影响哪些业务流程，以及需要触发哪些后续任务。在典型制造场景中，当设备发生异常时，系统可以关联相关工序、工单、备件库存和交付计划，形成维修或调整建议，并在责任人确认后进入后续处理流程。
对智奇而言，智能问数、异常识别和报告生成可以作为AI应用的切入点。在此基础上，可进一步探索与派单、复核、审批、整改和结果反馈等流程的衔接，使分析结果逐步转化为可执行任务，从而提升AI应用对实际业务运行的支撑作用。
5.3 没有替代客户系统，而是成为跨系统操作层
Palantir第三个做对的地方，是没有试图全面替代客户已有的业务系统，而是在这些系统之上构建跨系统的业务操作层。
大型组织往往已经拥有大量信息系统，例如ERP、MES、WMS、QMS、MDC、SCADA、文档系统、数据库和各类业务应用。这些系统承担着企业日常运行中的基础职责，对于客户而言，这些系统已经深度嵌入业务流程，不可能轻易被推倒重来。
Palantir的路径并不是替代这些源系统，而是连接这些系统。它关注的不是单个系统内部如何运转，而是多个系统之间的数据、对象、规则和动作如何协同起来。Palantir不是ERP，也不是MES，更不是传统意义上的工业控制系统；它更像是位于原有系统之上的数据与业务操作层。
这种定位非常关键。因为复杂组织的问题往往不在于缺少某一个系统，而在于系统之间相互割裂。订单在ERP里，工单在MES里，库存和备件在WMS里，质量问题在QMS里，设备状态在MDC或SCADA里，文档和规范又在其他系统中。单独看任何一个系统，都只能看到局部信息；只有把这些系统中的数据和业务对象连接起来，才能形成全局运营视角。
Palantir通过Ontology把不同系统里的数据映射成业务对象，再通过对象关系和可执行动作建立跨系统协同。例如，一台设备不仅是设备系统中的一条记录，也可能关联工序、工单、产线、维修记录、备件库存和交付风险。围绕这台设备，系统可以形成分析、预警、派单、复核、审批、状态更新和系统写回等动作。这样，Palantir就不是在替代原系统，而是在原系统之上形成统一的业务操作入口。
这一点对于智奇也很有启发意义。轨交装备和检修场景中，客户往往已经有自己的生产系统、质量系统、设备系统、检修系统和管理制度。AI赋能不可能以推翻原有系统为前提，而应当在既有系统之上做连接、协同和智能增强。也就是说，真正可行的路径不是另起炉灶，而是把已有系统中的数据、业务对象和动作流程连接起来，逐步形成跨系统的智能业务操作层。
资料来源：
Palantir官方技术文档《平台概览》（Platform Overview）
Palantir官方技术文档《Integrated Platforms: AIP, Foundry, and Apollo》
Palantir官方技术文档《AIP Architecture Overview》
Palantir Technologies Inc.财务报告《2025 FY PLTR 10-K》
Palantir Technologies Inc.公开演讲《Q4 2025 Investor Presentation》
Palantir Technologies Inc.官方技术文档《Connecting AI to Decisions with the Palantir Ontology》
Palantir Technologies Inc.官方技术文档《Palantir AIP & Foundry Pricing Document》
Panasonic North America官方新闻报道《Palantir and Panasonic Energy of North America sign multi-year agreement》
Lear Corporation官方新闻稿：《Palantir and Lear Announce Five-Year Partnership Expansion to Accelerate Automotive Technology Transformation》
关注我们，获取更多行业前沿信息。
