本体增强的AI:旧瓶新酒?空中楼阁?画蛇添足?以Palantir为代表的Foundry+AIP打法，为AI在B端的落地，示范了一套新的模式，我们姑且称之为“本体增强的AI”模式。当然，对这种打法，也有一些不同的声音。一种是复古派。他们看见本体，就想到了知识图谱，看到了知识图谱，就想到了实体关系网络乃至传统数据建模的E-R图。于是乎，结论自然是“古已有之，旧瓶新酒”，没啥新东西。一种是怀疑派。他们认为，没有全面的数据治理，数据的一致性、准确性和数据血缘的追溯就没有全面的保证，建立在这样不牢靠基础上的本体，犹如空中楼阁，不足以为B端AI落地所用。还有一种是实战派。他们认为，本体是不必要的，纯属“画蛇添足”。没有本体，Agent照样可以直接建立在业务系统、业务数据要素的调用接口之上，无需通过本体这个层次作为中间人“赚差价”。事情真的是这样吗？今天我们就来解读一下，Foundry+AIP打法到底是什么，它跟传统知识图谱是什么关系，跟数据建模是什么关系，跟数据治理又是什么关系。在AI时代，Foundry+AIP打法对于B端的AI落地，意义到底是什么。Foundry的本体观是把从业务视角抽象出来的顶层视图拆解为四大基础范畴：对象类型（Object Type）、属性（Property）、关联类型（Link Type）、和行为类型（Action Type）。前三种范畴，在知识图谱和数据建模的传统讲法里都有，但动作对于知识图谱而言并不是“古已有之”的。最接近动作概念的，是“事件”。在其中，面向实例的事件知识库和事件的抽取、关联、预测等工作更是占据了主流。很多研究都是把事件当作另外一种“时序性、带论元的实体”来对待的，只是操作执行的痕迹，并不是操作执行的潜在或现实能力，更没有真正触达事件的“可执行、可编程”的本质。将事件连同其本体纳入知识图谱的研究，其历史也就不到10年。把事件的执行效果反过来体现在实体、关系、属性的变化上，是笔者近10年来在“事理图谱/可编程本体”研究和实践中一直不断强调的重点，可惜真正听懂的人不多。一直到Foundry打法的浮出水面，才终于在这里找到了知音。真正留给面向本体的事件/事理图谱研究成果，本来占比就不高，更遑论在企业级的规模上将事件本体以“回写”的方式，与企业内部的可执行组件实例进行对接的案例了。至于E-R图和传统数据建模，其表达能力本就在传统知识图谱的范围之内，更不值得单独拿出来跟事理图谱比较了。所以不管动作也好，事件也好，指的都是“可编程的本体”。可编程，关键是一个“可”字，原生的也好，挂上去的也好，必须容许可执行成分的存在，并且执行的效果相当于回写到实体、关系、属性，并可以从本体层被观测到。这绝不是在传统知识图谱甚至在“事理图谱”的旗号下主流所做的事情，更与在企业落地的传统知识图谱项目没有半毛钱关系。忽略了这个重大差异，谈什么古已有之，新瓶旧酒，其实是没有读懂本体在企业落地的最核心的技术范式变化。
在这一波AI之前，可编程本体的实现，必须依托于一个支持本体架构的程序设计语言，这本身又是一个巨大的工程。但生成式AI的诞生和发展，给可编程本体的实现提供了另外一条路径，这就是借助生成式AI强大的原生能力，把需要对接的已存在的可执行组件封装成AI友好的原子能力（MCPs），把还不存在的可执行逻辑封装成AI友好的skills。这极大地减轻了“可编程本体”的实现工作量，也是Palantir在AI原生时代实现又一次腾飞的秘诀所在。
观察Palantir的技术架构，可以发现他们并不试图全面治理企业的全部数据，而是根据企业需求形成具体的任务，通过任务的驱动来倒推完成这个任务所需要的黄金数据集是什么，进而实现边治理边挂接。纵使他们已经有了一张企业级本体的蓝图，在具体的实施中也绝非把蓝图一股脑儿塞给客户，而是极为冷静地截取任务所需部分来做这件事。说得极端一点儿，哪怕你的数据在我实施的任务触达不到的地方烂成一锅粥，我也懒得去跨越任务的边界去做点什么。只要你的数据在我实施的任务可以触达的地方达到了黄金数据集的一致性、准确性和数据血缘的质量要求，就一切OK。这看起来非常不合常理，甚至有违所谓的“专业良心”。明明看到了有那么多的数据治理欠债，却仅仅治理自己任务可触达的那“一亩三分地”。这是不是太冷酷了？其实这恰恰是对数据治理的一种自顶向下的最实际的切入方式。多少大而全的数据治理项目，因为没有实际任务的牵引，一头栽进了深不见底的大坑而不自知。凡是成功的数据治理项目，一定是有所不为的，一定是以一批核心任务为驱动，以核心任务的闭环为标准进行了筛选的。离开了核心任务的牵引，数据治理就失去了方向，多少无用功就浪费在了这个深不见底的大坑里。相较于自底向上的技术路线，自顶向下的技术路线是数据治理更加符合实际也与AI原生能力更加匹配的切入方式。首先，不同的系统/数据模型建成的年代差异很大，建成时大概率彼此并不知晓知道对方的精准存在，更不知道多少年以后的数据基础设施（例如企业级数据仓库、数据中台）长什么模样，更不知道多少年以后基于AI原生能力的任务需求长什么样。所以，不可以站在上帝视角苛求前人。自底向上的切入方式，恰恰相当于带着上帝视角来改造当年的数据模型。这是不现实的，也是不必要的。反观自顶向下的切入模式，它承认存在的都是合理的，无需对之前的数据模型进行理想化的、一刀切的改造或者“再造”，只需要在任务可触达的地方进行有限的“适配”，提炼出“黄金数据集”了事。可以说，“黄金数据集”就是企业数据的“AI特区/AI根据地”，意味着这个地方是跟AI拉齐、跟业务拉齐的，是AI可以踩上去的结实的数据底座；除此以外的地方，我无法保证，当然传统怎么搞还可以继续搞。但是，今后的AI应用特别是AI原生应用，应该是在任务驱动下，从这个“AI特区/AI根据地”逐渐扩展出去的，而不是从一开始就建设一个大而全的AI数据底座。这是大的原则。从这里看，任务驱动的本体建设，不仅不是“空中楼阁”，反而是在任务的驱动下，精选合适的部位搭建的基础最牢靠的数据基础设施。从反面的角度看，考虑到AI原生能力本身也在快速迭代之中，处在发展早期的一个时间片段中，就要去规划今后长久使用的大而全的AI数据底座，也是过于自不量力了。不可否认，自从AI原生能力以Manus的推出为标志有了飞速的提升以来，很多B端企业都在进行各种尝试，面向B端的行业应用软件提供者们也在进行各种尝试，目标就是打造由AI原生能力支持的、面向业务的Agent。但是，这两类主体的尝试，有着不同的动力。从B端企业的业务视角看，AI原生能力的普惠化，以及AI中台最核心的Harness Engineering直接被AI通用技术提供者接管，使得强交互、强展现、强流程性质的需求实现的最佳方式从低码让位给了无码。“个性化定制”这项工作从依赖外包变成了依赖自研，从依赖IT部门变成了业务部门和只有业务背景而无IT背景的人们有条件自力更生了，这样的变化，尽管是尝试性质的，却是关系到主体的重大变化。对接口治理欠债很多的B端企业来说，出现了AI倒逼接口治理、skills和原子能力接口一对一的情况。的确，从单一任务驱动的角度，以及从业务一线的聚焦关注来说，这样是最经济的：既不用去操心架构性质的规划和共享，也不用去操心其他业务单元使用什么后台资源。当然，真这样做了，自然也就没有建立本体的必要了。岂止是本体，整个IT部门的活儿也会大大缩水。但是，这样做的代价就是新时代的新烟囱又要林立了。从B端企业的架构视角看，尽管AI中台的主要功能都是由通用AI技术实现的，但系统和数据的业务抽象，是无论如何也没有办法交给通用AI技术的。系统和数据的使用的语言是技术语言，业务和AI原生使用的语言是业务语言。这中间差着一座连接二者、沟通二者的巴别塔。维特根斯坦说：我的语言的边界就是我的世界的边界。没有巴别塔，业务的语言和技术的语言就分别界定了两个不同的世界。而这个巴别塔，就是本体。本体可以做到自顶向下定义业务语义，直到把它们落到所谓“黄金数据集”上。黄金数据集是经过治理的、向上可以支撑业务语义、向下可以坐实数据和接口资源源头的标准数据集。一开始它可以是任务驱动的小片根据地，但随着任务的增多，根据地不断创建、发展、扩大、整合，会逐渐接管对业务语义的“解释权”。未经本体解释的业务语言，落到实处时就难免会就事论事，歧义丛生。所以，仅仅看离了本体，原生AI的落地还“能不能做”，那实战派的回答是对的，能做。但是，这样做可能产生你不愿意看到的后果。借助于本体，就可以更有章法地去做，更少不良后果地去做，更高效率地去做。在这个意义上，本体这个环节不是“画蛇添足”，而是“定海神针”。语言学上讲，任何字面的东西落到现实世界的东西，都要有一个承接它的“grounding（根基）”。本体，就是承接企业业务语言的grounding。这不仅是静态对象的承接，而且还是已经固化的业务处理计算能力的承接。如果说Manus/Openclawy一类工具建立了C端的“个人上下文”的话，那么建立B端的“企业上下文”，就离不开本体的支撑。当然，手搓本体的时代早就一去不复返了。打造各种建设本体的自动化工具，让本体既是AI友好的，又是IT遗留资产友好的，这是本体建设和借助本体的企业上下文基础设施建设的应有之义。
夜雨聆风
