企业采购AI的热潮正遭遇ROI困局——多数项目难以产生可量化收益，根因在于AI仅被当作“更聪明的对话工具”，尚未真正进入核心业务。Palantir（PLTR）以Ontology构建业务语义底座，让AI在结构化的业务世界中理解、行动并持续改进；而AIKC则在此基础上“锦上添花”，通过知识编织持续注入静态、动态与过程知识，让AI能够更实时、更动态、更可持续地理解业务世界。由此可以得出结论：企业AI的价值，正从“对话工具”向“核心业务”跃迁，而垂直领域知识的构建与迭代，才是其可持续价值的根本所在。
01
企业采购AI的繁荣与ROI的困局
过去三年，生成式AI大模型的迭代速度令人目不暇接——从GPT-4到Claude，从Gemini到各类开源模型，参数规模不断膨胀，基准测试成绩屡创新高。然而，与企业端热火朝天的技术采购形成鲜明对照的，是一个令CIO和CFO越来越不安的现实：AI买回来了，但真正的ROI在哪里？
波士顿咨询2025年的一项调研显示，超过60%的企业在部署生成式AI后的一年内，未能识别出可量化的业务收益；Gartner更是预测，到2026年底，至少30%的生成式AI项目将在概念验证后被放弃。这些数字背后，是大量企业陷入的典型困境：员工用大模型写邮件、做摘要、生成PPT，效率看似提升，但核心业务流程纹丝未动；客服机器人上线了，但复杂投诉依然只能转人工；知识库建起来了，但面对新政策、新场景，系统给出的答案依然“对不上号”。
问题的根源在于，当前企业采购AI的主流模式，本质上是将大模型当作一个“更聪明的聊天窗口”来使用——它能够理解和生成语言，但它不理解企业的业务对象、不掌握业务的流程规则、不感知环境的变化、更无法在动态情境中调用沉淀在专家头脑中的隐性经验。这样的AI，注定只能停留在业务的“表皮层”。
Palantir（PLTR）的实践路径，为破解这一困局提供了一条清晰的参照。技术路线上，Palantir（PLTR）以Ontology（本体论）为核心，构建了一个涵盖企业业务对象、关系、规则、权限和可执行动作的语义层，使AI能够在结构化的“业务世界”中工作。产品策略上，Palantir（PLTR）打造了Foundry（数据与运营基础）、Ontology（业务上下文与行动）、AIP（Agent、工作流与评估）协同的技术栈，并辅以AIP Evolve和模型后训练，将运行经验持续转化为模型与工作流的改进。市场策略上，Palantir（PLTR）聚焦于客户内扩张与行业化复制——先在一个客户的多个业务领域做深，再将沉淀的能力复制到更多行业。交付策略上，FDE（Forward Deployed Engineer，前置部署工程师）和AIFDE扮演着关键角色，他们将客户的实际业务问题和工作流经验带回平台，转化为可复用的交付能力，使交付不再随业务规模等比例增加人力。
高盛（GS）近期关于Palantir（PLTR）的研报，正是对这一路径的精准捕捉。报告的核心判断是：Palantir（PLTR）的可触达市场（TAM,Total Addressable Market）正在酝酿新一轮跨越式扩展，且主要体现在业务覆盖深度上。2026年Q2的数据印证了这一判断——商业收入同比增加4.95亿美元，其中4.07亿美元来自既有客户；净收入留存率达到157%；前20大客户过去12个月平均收入同比增长67%；员工人数增长约5.7%，而收入增长约92.8%……，这些数字揭示了一个清晰的产业信号：企业采购AI的重心，正在从“买一个对话工具”转向“让AI进入核心业务，并在真实运营中持续改进”。
02
Ontology：让AI进入核心业务的“业务语义底座”
那么，这一转向究竟如何落地？Palantir（PLTR）给出的答案，集中体现在其核心思想——Ontology之中。
Ontology并非哲学意义上的本体论，而是一个工程化的业务语义层。其核心思想可以概括为：将企业中的所有业务要素——对象、关系、规则、权限、动作——统一组织成一个可计算、可追溯、可执行的语义网络，让AI能够在这个结构化的语义网络中理解上下文、调用动作、执行任务。
构建Ontology，通常包含以下几个关键步骤。第一步是业务对象建模，将企业中的客户、订单、设备、合同、供应商等核心实体抽象为“对象”，并定义其属性与状态。第二步是关系建模，明确对象之间的关联，如“客户拥有订单”“订单依赖库存”“设备属于产线”，使AI能够理解业务要素之间的拓扑结构。第三步是规则与约束建模，将业务规则、合规要求、权限边界等编码为可执行的逻辑，确保AI的行动始终在授权的范围内。第四步是动作建模，定义每个对象上可执行的操作，如“创建工单”“调整额度”“触发审批”，使AI不仅能够“理解”业务，更能够“操作”业务。第五步是执行轨迹与反馈建模，让每一次AI的决策和执行都被记录、可追溯、可评估，为后续的持续改进提供数据基础。
以上五步构成了一个业务语义底座。当AI接入这个底座，它就不再是一个在抽象知识库里找答案的聊天机器人，而是一个在真实业务中工作的执行者——它清楚自己面对的是哪个客户、受什么规则约束、可以调用什么动作、执行后会产生什么后果。
而以Ontology为核心技术栈，则进一步把这一底座转化为完整的业务闭环。Foundry提供数据与运营基础，确保业务对象和关系有可靠的数据支撑；Ontology组织业务上下文与可执行行动，为AI提供结构化的业务理解；AIP承载Agent、工作流与评估，让AI能够在真实流程中提出建议、执行动作；FDE与AI FDE推动系统进入真实业务场景，把客户的工作流经验带回平台，转化为可复用的交付能力；AIP Evolve与模型后训练则将运行过程中的执行轨迹、人工修改和实际结果，反馈到下一轮模型与工作流的优化中。
这条链路的核心价值在于：业务问题进入流程，Agent提出建议并执行动作，系统记录运行轨迹与人工修改，再据此改进下一轮模型与工作流。专家经验由此从个人判断转化为企业可持续积累的能力，企业独特优势也沉淀到客户控制的技术栈和模型能力中——这正是Palantir（PLTR）客户内扩张和经营杠杆背后的根本原因。
03
AIKC：为Ontology装上“知识马达”
Ontology为AI进入核心业务提供了语义底座，但一个关键问题随之而来：这个底座本身，如何持续生长、不断丰富？静态的业务对象建模和规则定义，只能勾勒出业务的“骨架”，而真正让Ontology拥有生命力、能够应对动态变化和复杂场景的，是知识编织。
知识编织，是构建和维护Ontology的核心工程。它包含两个关键技术环节：知识抽取负责从海量信息中自动识别和提取实体、属性、关系及业务规则；知识融合负责对来自不同源头、可能存在冲突或冗余的知识进行对齐、消歧与整合，形成全局一致、可供计算的知识表征。通过知识编织，三类知识被系统性地融入Ontology：静态业务数据（历史工单、政策法规、产品参数）构成“事实锚点”，动态数据（新政策、市场信号、舆情热点）提供实时环境感知，过程数据（专家决策逻辑、沟通策略、创新方案）注入实践智慧。
没有知识编织，Ontology只是一个静态的业务建模工具，无法感知环境变化，无法吸纳专家经验，更无法在真实运营中持续改进；有了知识编织，它才真正拥有了“活的血液”和“成长的灵魂”——能够随业务实践不断丰富，随环境变化持续更新，随专家经验沉淀而日益智能。
而这，恰恰也是零点有数（301169）提出的AIKC（AI Knowledge-based Contents）战略框架中最本质的内核。AIKC的核心命题，就是通过数据编织与知识编织，构建一个融合静态数据、动态数据与过程数据的垂直领域知识体系，让AI真正理解业务、适配业务、并在业务中持续进化。需要强调的是，AIKC并非另起炉灶，而是在Ontology的基础上“锦上添花”：Ontology已为AI搭建起结构清晰的“业务世界”，AIKC则通过知识编织持续为其注入养料，让AI能够更实时、更动态、更可持续地理解业务世界——环境一变，它立刻感知；场景一新，它快速适配；经验一沉淀，它持续进化。
简言之，Ontology搭建起业务语义的骨架，AIKC则通过知识编织为其注入持续生长的养分——前者让AI“看得懂”业务，后者让AI能随业务“一起成长”。两者结合，企业AI才能真正摆脱“能说会道”的局限，在垂直领域持续创造价值。
结语
Palantir（PLTR）的实践与AIKC的范式，在底层逻辑上如出一辙。两者的落点都不在模型本身，而在垂直领域知识的构建与迭代。Palantir（PLTR）用Ontology组织业务语义，用FDE和AIP Evolve构建反馈闭环；AIKC用知识编织融合静态、动态与过程数据，用智能体承载知识的应用与进化。路径不同，本质相通：唯有让AI在垂直知识的深耕中运行，企业采购AI才会真正创造价值，交付结果。
高盛（GS）看对了Palantir（PLTR），但更值得所有企业看对的，是这个时代给出的信号：AI的下一站，不在云端，而在垂直领域的知识深耕之中。当大模型的算力与参数竞赛逐渐趋同，真正拉开差距的，不再是谁的模型更大，而是谁能把知识变成可运行、可迭代、可复制的业务能力。从“对话工具”走向“核心业务”，从Ontology走向AIKC，不是一道选择题，而是一道关乎未来的必答题——率先完成这一跃迁的企业，将在智能时代建立起真正可持续的竞争壁垒。
