三层架构:AI 商业决策不能停在“企业需要知识图谱”
很多关于企业 AI 的提案,讲到“企业需要知识图谱、需要知识库、需要本体”就结束了。这句话没有错,但它只是一个概念,甚至只是一个片面的需求。客户听完会点头,然后问一句:所以呢,我的业务到底怎么用起来?
我最近在整理自己的提案思路,越想越觉得这件事必须分三层看。我们公司目前只做到了第一层,而真正决定这件事有没有价值的,是下面两层。
第一层:概念层,正确但太浅
第一层的说法是:企业要做 AI 商业决策,得先有知识图谱、知识库,得把本体建起来。
这是对的。企业里的业务逻辑、客户关系、产品结构、历史项目,本来就是一张网,不是一堆互不相干的表。不把这张网建起来,AI 拿到的只是碎片。
但问题在于,这一层只回答了“需要什么”,没有回答“怎么用”。它更像一句行业口号,网上每天都能看到。如果提案停在这里,我们卖的就是一个概念,而不是一个能交付的东西。客户没有理由为一句正确的话付钱。
第二层:应用层,把业务逻辑变成“可判断的知识”
第二层要做的是把概念翻译成 IT 应用的设计:把这个模糊的需求抽象出来,回答企业到底怎么应用。
第一件事,是抽取企业自身的业务逻辑,把它变成带关联的知识。不是把资料堆进一个库就算完成,而是要弄清楚事物之间的连接:比如一份订单,它和哪个客户、哪条产品线、哪个交付环节有关;一次延期,又和哪些前置条件有关。关联建不起来,后面的判断就无从谈起。
第二件事是人机协同的界面。输入要有一套应用:让人能把业务信息录进来、修改、校验。输出也要有一套:把抽取和判断的结果展示给人看,让人确认或修正。这个闭环不能省——企业的数据往往不干净、口径也不统一,一开始就全自动,错误只会被放大。
可是只做人工录入和人工判断,这件事就没有意义了。人本来就在做这些。AI 的价值在于尽可能自动地判断。
所以这里需要引入一个新的概念:AI 判断。判断不能拍脑袋,得有依据。我目前的设想,是给企业建一套判断框架:企业的经营有周期性,可以分成 5 个周期;每个周期需要 6 种能力;每种能力对应一组判断因素。当一个问题出现时,把它放进“企业自身的数据 + 当前处于哪个周期 + 涉及哪种能力”的坐标里,再结合判断因素得出结论。
这套框架能不能站住,需要跟企业一起验证;但有一件事是确定的——这套数据非常关键。它要么提前准备,要么在跟企业合作的过程中一点点积累。没有它,AI 的判断就只能靠模型的泛化猜测,落不到企业的具体处境上。
判断完还不算结束。判断出问题之后要行动,这就到了工具层。
工具层要解决的是:AI 怎么真正操作企业现有的系统。这里有两个方向。一是把现有的 IT 资产、现有软件转换成 AI 能调用的工具;二是新做的 IT 系统从一开始就按“AI 能调用”来设计。同时还有登录、权限这些现实问题——AI 要动一个系统,先得能进得去。
我倾向于在中间加一层,叫 modernization。做法是:旧系统不动,业务逻辑不改,用它自己的代码和数据库把关联性抽出来,在外面包一层能被 MCP 访问的服务。AI 通过 MCP 的描述知道这个服务能做什么,通过 skill 决定什么时候用它;MCP 或 skill 里再写上 API,去调用旧系统原有的功能,或者直接访问它的数据库,把结果返回。
说白了,就是给旧系统套一层能跟 AI 通信的壳。这层壳把旧系统嫁接到上层的大脑,变成大脑可以执行的工具。这是第二层的核心工作,架构要设计,也要真的实现出来,不能停在方案图上。
第三层:云基础设施层,智能必须配得上执行
第三层是底层的系统架构。既然要上到企业层面,就绕不开云。不上云,这套东西跑不起来。
这一层要回答的是很具体的问题:接哪些云的服务?哪个云用哪家的哪个服务?整体架构怎么设计?
比如应用场景要先分清:哪些是用户交互型的,需要界面、需要人参与;哪些是自主执行的,后台跑完直接给结果。这两类场景对计算和调度的要求完全不同。
再比如数据:输入怎么进、怎么转换、存在哪里、怎么被上层调用。存在 Google,还是别的地方,还是直接连工具,这些都要在架构里定下来。
还有一个容易被忽略的点:系统不是只要“聪明”就够了。有智慧,还得能执行,这件事才有意义。而执行需要驱动——需要云端的一整套应用来跑任务、调工具、处理失败和重试。这部分架构不设计好,前面两层的判断再漂亮也落不了地。
三层打通,才叫产品
把这三层连起来看,逻辑其实是清楚的:第一层定义知识长什么样,第二层让知识可以被判断、被执行,第三层保证判断和执行真的跑得起来。
只做第一层,就是扯概念。网上概念太多了,谁都能讲两句,客户听多了只会觉得你在瞎吵吵。没有实现,信任就下来了。
三层都打通,我们拿出去的才是一个真正的产品,提案才有搞头。
这也解释了为什么第二层不能停:它是把“正确的话”变成“能用的东西”的那一段,也是最难、最容易被跳过的那一段。

