从Palantir谈起：中国企业如何让本体产生业务价值？

Palantir让市场看到，本体可以将企业数据、业务逻辑与Action组织进统一的运营语境。但当这套范式进入中国企业，一个更具体的问题随之出现：Action调用成功之后，订单风险真的解决了吗？由谁负责最终的验收？依据是什么？

本体已经不是企业AI市场里的陌生概念，越来越多企业开始用本体为AI补充企业特有的业务语义和规则。但从“看懂业务”到“推动业务完成”，仍有一段距离。AI可以发现问题、提出建议、创建任务，甚至调用工具写回业务系统，却未必能够验证行动是否改善了经营结果。如果系统不能继续观察结果、核验完成条件，并让结果进入下一轮判断，本体就仍然停留在认知层，而没有真正进入企业运行。

百特搭联合创始人兼CPO戚雨长期参与BPM、企业应用与业务系统建设。在大量项目中，他反复观察到一种断层：系统显示流程已经结束，接口也返回成功，但业务问题并没有真正解决。由此，他将企业本体的研究重点从语义理解和Action调用，进一步推进到结果依据、验收责任与持续反馈。

在戚雨看来，企业本体建设的下一步，不只是让AI理解企业，而是让这种理解能够支撑一条完整链路：识别问题、理解上下文、形成决策、制定方案、执行动作、验证结果，再将结果反馈给下一轮决策。围绕这一判断，百特搭提出“本体运营六步法”，将企业本体的价值，从建立共同业务认知，进一步走向推动业务持续闭环。

核心观点

本体建设不是从数据清单开始，而是从关键业务决策开始。先明确企业需要作出什么决策，再反向定义对象、关系、指标、规则、权限与动作。

本体不是要替代数据模型、知识图谱和业务系统。既有系统记录经营事实，本体将这些事实与业务对象、规则、权限和动作连接起来，让人和 AI 能有共同的业务依据。

中国企业建设本体，不必从大而全的体系建设做起。边界清晰、人工决策密集、跨部门协同突出、业务结果可衡量的高价值场景，更适合作为早期落点。

企业可以把行动权交给AI，但不能把责任一并交出去。让 AI 开始行动，应按业务风险分级开放权限，涉及客户权益或可能造成损失的高风险操作，仍需由人审核或决策。

执行成功不等于业务完成。接口返回、任务创建和系统回写，只能证明动作发生，不能证明业务目标已经达成。

AI完成一次任务，不等于形成行动闭环。完整闭环还需要验证执行结果，并把结果反馈给下一轮决策，这样企业才能持续优化。

01 企业本体的起点，是关键业务决策

爱分析：从你的观察来看，当下企业关注本体最核心的诉求是什么？目前整体处于什么阶段？

戚雨：企业一方面想用AI，另一方面还在摸索AI到底能做什么。很多企业已经引入了一些AI工具，用来写文档、做PPT，或者辅助个人办公。这些事情当然有价值，但企业真正想要的，是让AI参与日常经营，而不是停留在办公材料生成。要做到这一点，人和AI之间需要一套对企业运作方式的共同认知，这正是本体要解决的问题。

比如，一个销售人员问，某个客户最近有哪些订单、有哪些商机，应该提供什么方案。要回答这个问题，AI不仅要知道“客户”这个词，还要得知道销售问的客户是集团公司，合同是与集团下的科技公司签订的，而项目是为生产工厂服务，甚至付款都是来自不同主体公司，把这些信息串起来去追溯历史交付有没有延期，回款有没有违约。缺少这些信息，AI给出的内容就很难真正满足需要。

从实践阶段看，我把市场大致分为三类。第一类企业还没有系统了解本体，但已经遇到AI幻觉、回答不准确、智能体各自为战等问题。第二类企业认同本体的理论价值，却没有看到足够多的实际案例，正在寻找可验证的业务切口。第三类已经进入局部场景试点，开始把本体与业务系统、流程和Agent连接起来，希望找到可以落地的路径。

所以，我认为中国企业本体正从“解释概念”进入“验证价值”的阶段。真正的分水岭，不是建出了多少对象和关系，而是本体能否支持一次真实业务决策，并推动这次决策产生可验证的业务结果。

爱分析：你为什么认为“业务闭环”是企业本体必须突破的问题？

戚雨：这个问题并不是从一个抽象概念出发的，而是来自我们过去做BPM和企业业务系统时反复遇到的现象：流程走完了，业务不一定完成；系统返回成功，风险也不一定解除。

例如，AI发现订单存在延期风险，随后给供应商发了消息、创建了协调任务，接口也返回成功。从技术上看，每个Action都成功了。但供应商是否确认新的交期、物料是否按时到位、生产计划能否恢复，这些问题仍然没有答案。

这件事至少包含三个层次：技术动作是否执行成功，流程节点是否按要求完成，以及业务目标是否真正达成。过去的系统通常能够记录前两层，第三层却往往依赖人工经验、会议判断和事后复盘。

所以我提出“执行成功不等于业务闭环”。这不是对Action能力的否定，而是希望把本体研究从动作调用继续推进到业务结果：目标状态是什么，什么业务依据足以证明目标达成，谁拥有验收权，依据不足时又应该如何继续推进。

爱分析：企业已经有数据模型、知识图谱和各种业务系统，本体带来的增量价值是什么？

戚雨：企业是不是要把原来的东西全部重建一遍？我的答案是否定的。数据模型、知识图谱和业务系统都不会因为本体出现而被替代。

CRM系统记录客户和商机，ERP系统记录生产资源，仓储和物流系统记录交付过程，这些都是企业经营中已经发生的事实。但是AI要回答一个客户是否值得继续投入，或者一份合同可能有哪些风险，就必须找到支撑判断的事实。

本体的作用，就是把原有系统中的事实接入一套业务对象和关系中，使它们成为AI可以理解和追溯的依据。以一笔订单为例，数据模型可以描述订单字段，知识图谱可以关联客户、产品和供应商，流程平台可以配置审批或交付流程。但企业AI还需要知道，这笔订单当前处于什么业务状态，哪些指标意味着交付风险，哪些角色有权调整计划，哪些动作需要人工确认，以及什么结果能够证明风险已经解除。

因此，本体建设不应该从“企业有哪些数据”开始，而应该从“企业最关键的业务决策是什么”反向定义。企业真正关心的不是系统里有多少供应商字段，而是这个供应商能否保障交付、当前订单是否存在风险、是否需要调整采购计划。确定关键决策之后，再反向寻找所需的对象、关系、指标、规则、依据和动作。

02 让定义进入实例，让本体持续反映真实业务

爱分析：在你的研究中，业务本体的定义和业务运行中的实例，分别解决什么问题？

戚雨：本体定义描述的是企业如何认识一类业务事物，本体实例则是这类事物在真实业务中的具体运行状态。

以合同为例，定义层要说明合同有哪些属性，与客户、项目、供应商是什么关系，适用哪些规则，可以触发哪些动作，边界在哪里。

这些定义构成了企业业务运行的框架。而在框架之上，每一个具体客户、每一份具体合同、每一张具体单据，都是运行中的实例。企业真正做决策时，面对的不是抽象的“合同”，而是某一份合同能不能签、有没有法律风险、供应商能不能支撑交付，以及它是否会与历史合同发生冲突。

定义让AI知道业务逻辑和边界，实例让AI面对企业当下正在发生的事情。只有定义没有实例，本体只是一套抽象概念；只有实例没有统一定义，AI看到的仍然是分散的数据记录。二者结合，AI才能既理解业务逻辑和边界，又面对企业当下正在发生的具体事项。

我的观点是，本体不仅要记住业务现在是什么状态，还要记住为什么形成这个状态。只有这样，人和AI才能围绕同一个业务对象，基于同一套业务依据协同，并在条件变化后重新验证判断。

03 不要盲目追求大而全的本体建设，中国企业应从高价值场景切入

爱分析：Palantir为企业本体落地提供了重要参照，相比之下，中国企业需要怎样的本体落地路径？

戚雨：Palantir值得借鉴的，是围绕关键任务将业务对象、数据、逻辑与Action组织起来，而不是简单复制其项目规模和交付方式。中国企业的差异，不在于是否选择高价值场景，而在于首次建设范围、验证节奏和能力沉淀方式。中国企业不需要先梳理覆盖全公司的对象、关系和规则，再寻找本体的应用场景。更可行的路径，是先找到业务价值明确、改造价值清晰的关键业务决策点。例如，某个订单是否存在交付风险、某个项目是否可能延期、某份合同能否按期回款。

围绕这个判断，企业再反向定义需要哪些业务对象、数据和指标，采用什么规则，谁拥有判断与行动权限，可以触发哪些动作，以及什么证据能够证明问题已经解决。这样形成的是一个范围有限、但判断、行动和结果验证完整的业务闭环。

过去梳理复杂业务，通常需要经验很强的咨询顾问长期进入企业。现在，大模型和语义化工具可以辅助行业专家分析材料、整理业务对象和识别潜在问题，降低早期建模与验证成本。但它们不能替代业务规则确认、系统集成、权限治理和结果验收。当第一个场景得到验证后，中国企业可以把形成的对象模型、规则、流程、Action和验证方法沉淀为平台能力，再复制到相邻场景。

百特搭更倾向于把这条路径概括为：不是降低场景价值，而是缩小首次建设范围；不是先建完本体再寻找场景，而是让本体从高价值场景中逐步生长出来。

04 行动闭环，不是把动作做完，而是证明业务做成

爱分析：在你的定义里，一个完整的业务行动闭环包含哪些关键环节？

戚雨：行动闭环不能简单理解为“发现问题以后调用一个工具”。它需要完成从状态识别、问题理解、决策形成、行动执行，到结果验证和反馈迭代的完整链路。

举例来说，一家制造企业发现利润率偏低，就不能停留在“利润率下降”这个表面现象上，而要继续分析问题是否与库存周转有关。如果行业中较好的库存周转周期是三十天，企业就要判断自己的差距来自哪里：供应商备货方式、付款周期、销售下单节奏，还是生产安排。

这些方向都可能成为解决方案，但企业需要比较哪一个动作带来的改善最大。执行后，还要验证库存周转是否真正改善，并把结果带入下一次客户下单和生产安排。只有结果能够回到判断环节，企业才能持续优化，这才是我们所说的闭环。行动是闭环的中间环节，结果验证才是闭环的核心节点。

所以，真正的行动闭环需要建立一条从业务决策到结果验证的连接：以目标状态定义行动方向，依据结果判定是否完成，用反馈结果影响下一次决策。如果结果没有重新进入决策和行动，所谓闭环只是技术链路闭合。

爱分析：哪些场景适合验证从发现问题到系统回写的闭环？

戚雨：适合验证这一过程的场景通常有三个特点：业务对象明确、完成标准相对清晰、行动结果可以持续观察。质检是一个比较典型的场景。生产线上发现不合格品后，过去通常由质检人员线下分析，再把调整建议提交给设备或工程部门。建立闭环后，系统可以把质检问题与设备、工艺参数和历史记录关联起来，辅助判断原因，并把任务写回工单系统，交由相关部门处理。

另一个例子来自汽车生产。车辆要出口到多个国家，车机界面需要检查不同语言的文字是否准确、是否超出可阅读范围。AI可以先完成部分检查，把发现的问题反馈给研发部门；研发调整后，新的生产和检查结果再次进入系统；问题发现、研发修正、生产验证由此形成循环。

当前，这些环节仍然需要人参与。随着企业对结果更有把握，可以逐步给AI更多权限，缩短问题发现到修正验证的周期。

爱分析：一旦AI开始回写系统，企业会担心权限、责任和数据修改风险。那么，应该如何开放AI的行动权限？

戚雨：AI行动治理不能只靠一个“是否允许调用”的开关，也不存在适用于所有企业的固定授权顺序。权限必须与业务对象、动作类型、风险等级和责任角色绑定。AI可以获得行动权，但不能因此消除责任主体。

规则明确、依据充分、风险较低且结果可逆的动作，可以由AI在授权范围内执行；涉及资金、合同、核心客户、生产安全或重大经营结果的事项，则应保留人工审批和责任确认。即使同样是创建任务或修改字段，在不同业务场景中产生的后果也可能完全不同，不能仅按技术动作类型判断风险。

企业还需要能够追溯AI基于什么事实作出判断、为什么选择这个动作、谁授予了权限、谁确认了结果。是否扩大AI权限，也不能只看模型准确率，还要看过去的业务结果是否稳定、判断理由是否可解释、异常是否可追踪。

我的原则是：企业可以把行动权交给AI，但不能把责任一并交出去。

05 从BPM走向本体，关注的是业务如何被推动

爱分析：你一直从BPM和业务执行的视角研究本体，这个起点带来了什么不同？

戚雨：从数据平台出发，首先看到的是数据连接和语义统一；从知识图谱出发，首先看到的是对象关系和推理；从BPM出发，我们首先看到的是一件事情如何在组织中被推动。

很多一线业务数据就是在流程执行中产生的。业务部门正在处理什么任务，流程走到哪一步，客户提出了什么问题，这些信息可以直接升级为本体实例。AI在此基础上做分析，更容易理解企业当前状态，也更容易把结果重新带回执行流程。

在我看来，业务流程管理仍然承担底层执行，保证每个业务单元按要求完成任务。本体位于其上，把不同流程中的对象、数据和规则连接起来，支持风险发现、原因分析、方案推演和行动建议。二者的关系不是相互替代，而是执行基础与业务认知之间的配合，本体让流程知道为什么行动，BPM让本体中的判断真正进入组织运行。

这也是百特搭与许多数据型产品路径不同的地方。我们不是因为掌握了更多数据才研究本体，而是因为长期参与流程和企业应用建设，更熟悉业务状态如何在任务、审批、协同和执行过程中形成，也更关注本体如何连接责任、权限、行动与结果。

06 本体运营六步法，把一次交付沉淀为可复用能力

爱分析：你如何把企业本体从建设方法推进到持续运营？

戚雨：我们把这套思考概括为“本体运营六步法”：定决策、建依据、验完成、用反馈、积经验、做复用。它不是六个孤立功能，而是本体从建模走向企业运营的完整路径。

定决策，是先明确企业需要作出什么关键业务决策；建依据，是围绕判断建立对象、关系、指标、规则、权限和动作，让人和AI拥有共同的业务依据；验完成，是用目标状态、结果证据和责任验收判断业务是否真正完成。用反馈，是让执行结果重新进入本体状态，影响下一步判断和行动；积经验，是记录当时为什么这样判断、采取了什么行动、最终是否有效；做复用，是把项目中形成的对象模型、规则、流程、Action和场景方法沉淀为平台资产。

六步法要解决的核心问题，是让企业本体不再停留在一次性建模，而是随着业务运行持续更新、验证和积累。

爱分析：这套本体方法论是否已经转化为百特搭可运行、可展示和可验证的产品能力？

戚雨：这套方法论已经形成了产品层面的工程承载。百特搭目前以企业本体引擎为统一业务语义底座，并围绕本体形成构建、决策分析、智能预测、数字员工协同、业务行动闭环和FDE工作台等能力。

企业本体引擎统一对象、关系、指标、规则、权限和动作，并持续管理运行中的对象实例；构建能力把本体转化为应用、流程、Agent和业务工作台；决策分析与预测能力围绕对象状态开展实时分析、异常解释、根因诊断、风险预警和经营推演。

当系统形成决策后，数字员工与BPM执行引擎再将判断联动到任务、审批、系统调用、结果回写和验收反馈；FDE工作台则为管理者、业务人员和运营角色提供统一的分析与行动入口。

本体不是其中一个孤立模块，而是连接理解、构建、决策、预测、行动和结果的共同业务层。FDE团队进入客户现场的目标，也不只是完成一次项目交付，而是把场景中的对象模型、规则、流程和Action沉淀为后续可复用的平台能力。

同时，百特搭也正在通过真实客户场景持续验证这些能力的业务效果和复用价值。

爱分析：刚刚提到，百特搭正在持续验证产品能力，那么未来几个月，百特搭计划重点验证什么业务命题？

戚雨：我们希望围绕真实客户场景验证三个问题。第一，本体能否让人和AI基于同一套业务依据形成决策；第二，AI采取行动后，系统能否依据目标状态、结果证据和责任验收判断业务完成；第三，一次项目交付形成的经验，能否沉淀并复用到后续业务场景。

验证不会只看模型回答准确率或接口调用成功率。我们还会关注问题发现时间、判断时间、处置周期等效率指标，事项完成率、逾期率和重复问题率等闭环指标，以及对象、规则、Action和模板的复用情况。

这不是在验证某一个孤立功能能不能运行，而是在验证本体能不能从认知工具进入企业运营。后续，百特搭也计划结合客户实践，进一步披露验证方法和阶段性结果。

07 企业本体将成为AI进入组织运行的共同业务层

爱分析：长期来看，本体将在中国企业AI体系中扮演什么角色？

戚雨：长期来看，我认为本体不会只是一种建模工具，也不会只属于某个独立系统，而会逐步成为企业数据、AI、流程和应用共同依赖的业务层。在产品形态上，本体既可能以独立平台存在，也可能作为基础能力嵌入数据平台、智能体平台和企业应用。两种形态并不矛盾，关键不在于它以什么产品名称存在，而在于它能否为企业中的人和AI提供一套共同的业务依据。

Palantir Ontology的重要启发，是让对象、数据、逻辑和Action进入统一运营语境。但中国企业的系统环境、组织结构、权限体系和交付方式有自己的复杂性。中国企业本体不能只复刻一种产品结构，还要回答如何进入既有系统、如何连接复杂流程、如何闭合证据与责任，以及如何通过FDE把一次交付沉淀为可复用能力。

本体对企业迭代速度的提升。也不只是让软件开发得更快。更重要的是，当业务发生变化时，企业可以围绕同一套对象、规则和权限，快速调整决策逻辑、行动路径和验收标准，并把验证有效的经验复用到新的业务场景中。

个人效率提升并不等于组织效率提升。只有当业务对象、数据、知识、流程和行动被连接起来，人与AI、AI与AI才能围绕共同目标协作。所以，本体将成为AI进入企业组织运行的共同业务层，它真正的价值也不在于让AI知道得更多，而在于让企业更快地形成决策、推动行动、验证结果，并将有效经验持续复用。