爱分析发布2026中国本体平台市场洞察报告

大模型和Agent加速进入企业后，如何让AI理解真实业务并参与业务执行，成为企业智能化落地的关键问题。本体通过描述业务对象、关系和规则，为AI建立企业业务认知基础，正受到越来越多企业和技术厂商关注。

然而，中国市场对于本体的理解仍存在明显差异：有的侧重知识组织，有的强调统一数据语义，也有厂商开始将业务逻辑和行动纳入其中。相同的概念背后，对应着不同的建设目标、产品边界和业务价值。

在此背景下，爱分析发布《2026爱分析·中国本体平台市场洞察报告》，系统梳理中国市场的本体实践路径与能力演进方向。爱分析认为，本体平台的价值需要从语义表达进一步延伸至业务计算、行动执行和持续治理。完整的平台既要帮助企业建立统一的业务认知，也要支持本体随业务运行和规则变化持续更新，并推动数据、判断与行动形成闭环。

核心观点

随着Palantir受到资本市场和企业用户关注，本体成为中国AI市场热点概念。中国市场厂商实践并没有完全照搬Palantir路径，而是基于不同技术路线和应用场景进行探索，中国市场尚未形成统一的本体定义，本体平台的产品能力边界也处于探索阶段。

中国市场围绕本体形成了四类实践路径。知识工程路径侧重将文档和专家经验组织为结构化知识；语义层路径侧重统一业务术语和指标口径，并建立语义与数据之间的映射；业务本体路径围绕客户、订单和设备等业务对象，描述其属性、关系和状态；可执行本体路径进一步管理业务规则、Functions和Actions，让本体能够参与业务计算和流程执行。

Palantir为理解完整本体能力提供了重要参照。其当前体系来自长期的数据治理、决策应用和项目交付实践，随后逐步扩展到业务对象、Functions、Actions及动态安全。中国厂商可以借鉴其平台架构，叠加大模型与智能体技术带来的能力提升，形成不同的产品架构和演进路径。

本体平台的评估需要关注语义表达、业务计算、行动执行和持续治理能否形成闭环。对象、属性和关系构成语义表达，Functions承载业务计算，Actions负责行动执行，全生命周期治理支持本体持续迭代和稳定运行，四类能力共同形成从理解业务到推动行动的闭环。

动态本体能力包含运行动态性和演进动态性。前者是指对象状态、计算逻辑与行动结果在业务过程中的联动，完成行动执行闭环；后者是指本体能够随数据和业务变化持续迭代。AI自动生成本体可以提高发现对象、关系和规则的效率，但当前仍然存在大量幻觉，应用到生产场景仍然需要人工审核验证。

本体平台需要在真实场景中持续成长。厂商通过项目识别关键对象，验证计算逻辑和行动，再将稳定经验沉淀为平台资产。FDE的核心任务是交付可衡量的业务结果，并推动现场经验进入标准产品和后续项目。

1. 中国市场形成多种本体实践路径，能力边界尚未统一

2026年模型能力大幅提升后，企业对AI的期待正在从知识问答转向业务执行落地。AI既要理解用户的问题，还要知道企业中有哪些客户、设备和订单，掌握这些对象之间的关系，并按照业务规则完成决策与执行。

企业现有的数据和知识通常分散在不同系统中。数据平台保存业务数据，知识库管理文档资料，规则则分布在业务系统和人员经验中。企业需要一套统一机制，将业务对象、数据含义和业务规则关联起来，并为AI调用企业资源提供清晰边界。

本体平台因此受到关注。它可以将企业中的业务对象及其关系组织起来，进一步连接真实数据，承载业务规则和行动，使数据、知识与业务流程形成统一的业务表达。

Palantir的市场表现进一步带动了中国企业和厂商对本体的关注。中国市场并未形成统一的产品形态。不同厂商分别从知识工程、语义层、业务对象建模和业务行动等方向进入，并结合自身客户和项目逐步扩展能力。

1.1 四类本体实践路径对应不同建设目标

中国市场对本体的探索并非从同一种需求出发。有些企业希望把文档和专家经验转化为机器可以理解的知识，有些企业希望统一业务术语和数据口径，还有一些企业希望围绕真实业务对象组织数据，并进一步支持业务计算和流程执行。建设目标不同，形成的本体形态和平台能力也存在明显差异。

为了更清晰地呈现当前市场实践，爱分析根据本体的建设对象、核心目标和使用方式，将相关实践归纳为四条路径：知识工程路径、语义层路径、业务本体路径和可执行本体路径。

知识工程路径主要处理文档、术语和专家知识；语义层路径主要连接业务语义与底层数据；业务本体路径围绕客户、订单和设备等业务对象，描述其属性、关系和状态；可执行本体路径进一步管理业务规则、Functions和Actions，让本体能够参与业务计算和流程执行。

图1：中国市场四类本体实践路径及能力边界

四条路径的主要差别，在于本体需要组织什么内容，以及最终要支持什么应用场景。知识工程路径关注知识的提取和组织，语义层路径关注数据含义和指标口径，业务本体路径关注真实业务对象及其上下文，可执行本体路径关注规则运行和业务行动。

1.2 知识工程路径与语义层路径分别从知识和数据切入

知识工程路径主要从制度文件、技术文档和专家经验中提取概念及其关系，建设重点通常落在本体建模、实体抽取和知识融合。治理后的知识可以进入知识图谱，也可以成为企业Agent的知识来源，主要价值是提升知识质量和跨文档理解效率。

语义层路径主要面向企业智能问数等场景。平台统一业务术语和指标口径，再将语义映射到底层数据。用户通过自然语言提出问题后，系统可以依据语义模型生成查询。部分厂商已实现从决策到行动，将数据分析与行动机制相结合。

1.3 业务本体路径与可执行本体路径，推动本体进入业务运行

业务本体路径从企业的真实业务对象出发。平台以客户、订单和设备等对象为核心，统一描述对象属性、关系和状态，再把不同系统中的数据组织成连续的业务上下文。这为Agent理解业务场景和推理召回奠定基础。

可执行本体路径在业务本体之上进一步实现对业务规则与Functions的管理，平台根据对象状态运行Functions，形成业务判断后调用Actions，触发流程或外部系统。行动完成后，执行结果可以回到本体并更新对象状态。

2. 中国本体能力从模型构建走向动态运行

中国四条本体实践路径具有不同的建设目标，但在落地过程中面临相似问题：本体如何快速构建，如何与真实数据保持同步，以及如何适应业务变化。

早期本体建设主要依赖领域专家进行人工建模。随着数据规模扩大和业务变化加快，单纯依靠人工已经难以承担持续建设和维护成本。当前市场开始通过数据结构、业务文档、应用场景和AI共同参与本体构建，并逐步形成动态运行和持续演进能力。

2.1 本体构建正在从专家主导走向多源协同

传统本体构建主要依赖领域专家。团队先确定对象和关系，再定义属性与约束。这种方式建设周期较长，并严重依赖专家资源和组织协同。

越来越多厂商开始利用数据结构和业务文档辅助本体建模。本体建模工具可以读取数据库元数据，识别潜在对象，并给出字段映射建议；对于文档等非结构化数据，本体建模工具可以先生成模型草稿，再由领域专家确认边界和含义。

另一种方式是从场景出发构建本体。团队先确定应用场景和业务痛点，再反向寻找相关对象、计算逻辑和Actions。这种方式能够缩小初始建设范围，并更早检验本体对真实业务场景的价值。

生产环境中的本体建设往往需要采取多种方式融合。数据结构提供对象候选和字段映射，业务材料提供规则依据，领域专家负责解释边界。

多源协同提高了本体初始构建效率，但模型完成并不代表建设结束。当本体连接实时数据并进入业务流程后，对象状态需要持续更新，模型和规则也会随着业务变化不断调整，由此产生动态本体能力。

2.2 动态本体能力同时关注业务运行与持续演进

根据爱分析调研，当前市场对“动态本体”主要有两类理解。第一类强调本体能够参与业务运行，第二类强调本体模型能够随着业务变化持续调整。两类理解分别对应运行动态性和演进动态性，各自解释了动态本体的一部分。只有将两类能力结合起来，才能形成真正的动态本体。

运行动态性强调本体需要具备完整的构成。本体除了包含对象、属性和关系，还需要管理业务规则、Functions和Actions。对象、属性和关系帮助系统理解企业的业务世界，Functions负责完成业务计算和判断，Actions负责触发流程或调用外部系统。

例如，在客户风险管理场景中，本体首先需要描述客户、账户和交易之间的关系。当客户风险发生变化时，Functions可以根据业务规则重新计算风险等级，Actions再触发人工审核、限制交易或发送预警。通过这一过程，本体可以从描述业务对象延伸到支持业务判断和行动执行。

演进动态性强调本体模型能够随着业务变化持续调整。企业会不断增加新的业务对象，修改数据口径，并调整业务规则。例如，银行改变客户风险评估标准，制造企业增加新的设备类型，供应链企业调整库存预警规则，本体中的对象、关系、映射和业务逻辑也需要同步变化。

本体模型的调整可能影响已有数据、Functions、Actions和业务应用。项目落地中，需要识别哪些内容会受到影响，并支持修改、测试、审核和发布。

运行动态性和演进动态性关注本体的两个不同层面。运行动态性解决的是本体在当前版本下能否参与业务计算和行动，演进动态性解决的是本体能否通过版本迭代长期适应业务变化。

任何一项能力单独存在，都只能覆盖动态本体的一部分。真正的动态本体需要同时具备完整的运行能力和持续演进能力。

图2：动态本体由运行动态性与演进动态性共同构成

2.3 AI自动生成本体进入生产质量验证阶段

随着本体包含的对象、关系和业务规则不断增加，依靠人工完成初始构建和持续更新会带来较高成本。AI开始被用于辅助识别对象、生成关系和规则建议，并帮助团队发现业务变化对本体模型的影响。

AI可以帮助企业完成本体建设中的大量基础工作，部分厂商的本体建模工具已经开始利用AI提取业务规则。例如，AI可以从信贷制度中整理风险判断条件，或者从设备运维手册中提取故障处理规则，并形成Functions草稿。不过，业务文档中可能存在口径不一致或表述不清的情况，AI也可能遗漏重要条件。因此，当前生成结果仍然需要领域专家审核，并在测试通过后才能用于实际业务，金融和工业等高风险场景尤其如此。

评估AI自动生成本体的能力，不能只看建模速度。还要看AI能够生成哪些内容，能否说明这些内容来自哪些数据和文档，以及能否发现重复对象、关系冲突和规则错误。生成结果还要便于后续修改和维护。只有效率、准确性和维护成本同时得到验证，AI生成本体才具有生产应用价值。

中国市场已经形成专家建模、数据辅助和AI协同等多种构建方式，部分产品也开始支持本体运行与持续演进。AI能够降低本体初始建设和持续更新的成本，但本体建模工具的价值还取决于模型能否连接真实数据，能否承载业务计算，能否推动业务行动，以及能否随着业务变化长期更新。Palantir的长期实践为理解这一方向提供了较完整的参照。

3. Palantir Ontology在长期实践中形成完整的本体能力架构

理解Palantir Ontology，既要看当前具备哪些能力，也要关注这些能力的形成路径。当前Ontology已经整合语义要素、业务计算、Actions和动态安全。这套体系来自长期的数据治理、决策应用及项目交付之上。Palantir可以作为能力参照，但中国厂商不必完全复制Palantir的建设路径。

图3：Palantir Ontology核心架构

3.1 Palantir Ontology从数据分析与业务应用中逐步形成

Palantir早期首先解决多源数据连接、分析和协作问题。随着项目深入，单纯的数据表和分析结果难以满足客户的业务诉求，平台逐步以人员、设备和事件等业务对象组织数据，并建立对象之间的关系。

当这些对象进一步被应用和流程持续调用时，Ontology逐步加入业务规则、计算逻辑和行动边界。AIP又将大模型与Ontology连接，使模型能够在企业上下文和权限范围内调用数据及Actions。由此可见，Palantir的本体能力是在真实业务问题中逐步扩展形成的。

3.2 语义要素与行动要素共同构成Palantir Ontology

Palantir官方将Ontology分为semantic elements和kinetic elements。semantic elements包括对象、属性和关系，用于描述企业业务世界；kinetic elements包括Functions、Actions和动态安全，用于计算业务状态并推动业务变化。

Functions是围绕本体对象运行的业务计算与处理逻辑，它可以读取对象、执行判断并返回结果。Actions规定对象如何被创建或修改，也可以触发外部系统。两者结合后，本体才能真正进入可执行的业务过程。

动态安全在用户和Agent发起交互时计算访问和执行权限。不同用户看到的对象范围可能不同，可执行的Actions也可能不同。semantic elements、kinetic elements与动态安全结合后，分析结果才能在受控环境中进入业务流程。

3.3 Palantir Ontology连接数据、模型与应用

在Palantir产品体系中，Ontology建立在数据资产之上，并为分析工具和运营应用提供统一业务接口。开发者可以通过Ontology API调用对象，业务人员也可以使用低代码工具构建工作流。

AIP进一步支持大模型和Agent在权限控制下调用对象、Functions和Actions。Ontology因此成为企业AI上下文、业务逻辑和行动执行的重要基础。

4. Palantir以全生命周期管理保障本体持续运行

Ontology进入企业核心流程后，会被多类应用使用。数据结构变化、业务逻辑调整或权限更新都可能影响下游应用，因此Palantir把本体管理贯穿建设、连接、运行和治理的全过程。

4.1 本体能力贯穿建设、连接与运行

Palantir没有“本体平台”作为一条单独产品线。Ontology能力分布在Ontology Manager、Pipeline Builder和AIP等工具中，由统一对象体系连接起来。

本体管理的生命周期可以概括为四个环节。建设环节定义对象及行动，连接环节将数据或模型映射到对象，运行环节通过Functions与Actions进入业务流程，治理环节负责权限、版本和运行监控。

4.2 变更治理保障生产环境稳定

本体进入生产环境后，每次变更都可能影响现有系统，因此需要先在隔离环境中测试。团队通过提案和评审识别潜在冲突，再决定是否合并。

Palantir更值得借鉴的是全生命周期管理方法。企业在建模时就要考虑数据连接和运行机制，模型上线后的版本、权限管理。

4.3 运维治理关注权限、使用与执行结果

本体上线后，平台需要持续监控资源使用情况。一方面是识别对象的访问和依赖关系，另一方面是跟踪Functions与Actions的执行表现。Action Log保存行动提交及数据修改记录，为审计和复盘提供依据。

权限治理需要覆盖模型资源和对象实例。项目权限控制资源的查看与编辑，对象安全策略进一步约束实例访问。动态安全还会根据交互上下文计算权限，使Agent在企业环境中的调用保持可控。

Palantir的实践表明，本体能力需要覆盖建设、运行和治理全过程。多数中国厂商会研发独立的本体平台，覆盖本体全生命周期管理。

5. 中国本体平台评估应关注能力闭环与实际效果

Palantir提供了较完整的系统参照，中国市场仍需要形成一套独立的厂商本体平台定义和评估体系。这套体系既要识别平台具备哪些能力，也要验证相关能力能否在真实环境中协同运行。产品架构不一定要照搬Palantir技术框架。

5.1 本体平台定义

爱分析认为，本体平台是用于构建、运行和治理企业业务本体的软件平台。它将分散的数据和知识映射为统一的业务对象及其关系，在同一业务表达体系中管理规则、Functions、Actions和权限，企业用户可以基于这个平台开展本体的查询、计算、决策和流程执行。

本体平台覆盖本体设计、数据连接、发布运行、监控维护和版本迭代等环节。平台既要让本体持续反馈真实业务状态，也要让业务逻辑和行动在权限约束下持续运行，从而支持本体长期演进。

具体来看，本体平台需要三个核心特征。

第一，能够构建完整本体。平台需要管理对象、属性和关系，也应覆盖业务规则、Functions、Actions及相应权限，使语义表达能够进一步支持业务运行。

第二，能够连接真实数据与业务行动。平台需要持续将企业数据映射为本体对象，并通过Functions和Actions连接业务流程或外部系统，使计算结果能够进入实际运营。

第三，能够管理本体全生命周期。平台需要提供发布、版本和血缘管理，也要覆盖权限控制、运行监控和变更治理，保障本体持续更新及稳定运行。

5.2 本体平台六项关键能力

围绕本体从建设、演进到运行治理的完整过程，本体平台可以归纳为六项关键能力。通过这六项能力来评估本体平台的完整度，同时结合实际落地场景和真实案例判断不同功能是否实现等效结果。

在这一评估体系中，动态本体属于综合判断。逻辑运行与行动闭环能力体现运行动态性，本体持续演进能力体现演进动态性。两项能力共同具备，才能形成完整的动态本体能力。

图4：本体平台六项关键能力框架

第一，完整本体构建能力。平台需要统一管理对象、属性和关系，并将业务规则、Functions和Actions纳入本体。该能力重点考察平台能够管理哪些本体资源，以及不同资源之间能否建立清晰关联。

第二，数据连接与映射能力。平台需要连接企业中的多源数据，并建立数据资源与本体对象之间的稳定映射。当源系统中的数据发生变化时，本体中的对象状态能够同步更新。

第三，逻辑运行与行动闭环能力。平台需要运行规则和Functions，根据业务对象的当前状态完成判断，并通过Actions触发流程或调用外部系统。行动结果还需要回到本体，更新相关对象的状态。这项能力体现本体的运行动态性。

第四，本体持续演进能力。当业务流程、数据结构或管理规则发生变化时，平台需要支持对象模型和业务规则的调整，并提供影响分析、测试和版本发布机制。这项能力体现本体的演进动态性。

第五，AI辅助构建与维护能力。平台可以利用AI从数据结构和业务材料中识别对象、关系及规则，辅助生成本体草稿。在本体运行过程中，AI还可以识别变化并提出调整建议。相关结果需要保留生成依据，并接受人工审核。

第六，全生命周期治理能力。平台需要对本体资源进行持续治理，覆盖权限控制、血缘追踪和变更审批，同时支持运行监控与审计。治理能力贯穿本体建设、发布和运行全过程，保障本体在生产环境中稳定使用。

5.3 平台评估需要结合产品演示与案例验证

产品演示需要围绕一个真实业务对象展开。厂商应展示对象如何连接数据，规则和Functions如何运行，Actions如何受到权限控制，以及执行结果如何回到业务系统。只有这些功能在同一流程中协同运行，才能证明平台具备完整闭环。

评估动态本体时，需要分别验证运行和演进。运行侧关注数据变化后对象状态是否及时更新，Functions是否按条件触发；演进侧关注模型变更能否隔离测试，依赖冲突能否被发现，稳定版本能否恢复。

案例验证的重点，是判断平台能力是否已经进入生产流程。案例关注本体平台上线后解决了哪些业务痛点，带来哪些业务增量价值。

由此，本体平台评估形成两个相互关联的维度：一是平台能力，观察完整构建、动态演进和运行治理；二是落地验证，观察进入哪些流程、产生何种结果以及项目经验能否复用。本报告重点建立平台能力框架，后续爱分析针对中国本体平台厂商评估将结合两个维度展开。

6. 中国本体平台能力需要在场景中持续生长

6.1 高价值场景决定建设起点

本体平台的成熟度最终需要由场景验证。本体平台更适合对象关系复杂、业务规则持续变化的场景。根据爱分析调研，本体平台特别适合涉及到跨系统协同和长链路复杂决策场景，若需求仅为知识检索或单一指标查询，企业用户应先判断AI知识库能否满足。

企业需要先明确业务问题和责任部门，再设定可验证目标。目标可以体现为决策周期缩短、异常损失降低或流程效率改善。清晰的交付边界有助于控制初始范围，也便于判断平台是否创造增量价值。

6.2 场景落地形成平台成长循环

本体平台建设可以从关键业务决策开始。团队识别相关对象和数据，定义业务逻辑与Actions，再接入应用并进入真实流程。项目需要同步设定结果指标，以便验证本体对业务产生的影响。

图5：场景落地与本体平台成长飞轮

实际运行会暴露对象缺失、逻辑冲突和权限边界等问题。团队根据反馈调整本体，再进入下一轮验证。经过验证的对象模板、连接器和行动组件进入平台后，后续项目可以在复用基础上扩展。

判断平台是否在场景中成长，可以观察三个结果：第一是项目是否进入核心流程并改善业务指标，第二是现场经验是否进入标准产品，第三是后续项目是否缩短交付周期。只有形成这一循环，项目数量才对于平台能力提升有帮助。

6.3 FDE连接业务现场与平台产品

FDE在本体平台建设中负责发现业务问题并交付结果。团队需要理解客户的决策与流程，也要掌握数据和工程能力。在现场工作，FDE需要完成对象抽象，组织业务逻辑，并与客户共同验证Actions及最终结果。

中国软件市场长期存在驻场实施模式，FDE的核心在于创造增量业务价值，实现交付目标和并沉淀能力。系统部署上线只是基础条件，还要关注业务指标改善，以及项目经验是否反向推动平台产品升级。

FDE团队应记录场景中的对象模板、规则依据和行动接口，并沉淀测试方法与复盘结果。产品团队再把这些经验转化成标准组件，供后续项目调用和扩展。这样一来，现场投入才能逐步转化为可持续的平台资产。

6.4 项目经验需要转化为平台成长

项目数量多并不等于平台成熟。某些厂商完成多个项目后，仍然需要依赖人力进行重复开发。平台成长需要体现为实施周期缩短、标准能力增加和交付质量稳定，也要形成可以跨客户复用的行业方法。

可复用资产包括对象模板、规则库和连接组件，也包括Actions与测试方案。资产进入平台后需要接受版本管理和质量检查。后续项目在复用基础上扩展，厂商才能形成规模效应，客户也能获得更稳定的实施结果。

结语

中国本体平台市场正在从概念讨论进入产品能力和场景价值验证阶段。随着企业AI应用从知识问答逐步延伸到业务决策与行动，市场关注重点将转向完整本体构建、动态演进、行动闭环和全生命周期治理。

本文从中国市场的多种实践路径出发，归纳本体构建和动态运行的共同演进，并以Palantir为参照提出本体平台定义及六项能力。Palantir展示了成熟体系的能力边界，中国厂商仍需结合本地客户的业务场景、既有系统和交付条件形成适合自身的演进路径。

本体平台的长期价值取决于平台能否形成稳定的业务表达，能否推动受控行动，以及能否随业务变化持续演进。厂商需要从高价值场景切入，通过FDE连接业务现场与平台产品，再将验证有效的项目经验沉淀为可复用资产。

后续，爱分析将围绕本体平台及应用持续开展厂商调研和案例验证，并重点形成两类研究成果。

第一，发布本体平台及应用厂商全景与实践研究，呈现市场参与者、重点行业场景和典型案例，进一步总结企业建设路径及关键成功要素。

第二，发布本体平台市场研究及厂商评估报告，建立覆盖平台能力和场景落地的二维评估体系，对代表厂商进行系统研究，并通过产品演示和生产案例验证能力。