《AI即软件》第十二章:数据中台——操作系统内核

一

构建新AI软件架构设计的第一个重大决策就是：AI时代的企业IT架构，中心到底是谁？

如果是AI，那么数据就是AI的燃料库，AI想来取就来取——聪明，但危险。你想象一下：一个Agent拿着AI的尚方宝剑，直接连上数据库，为了完成你交给它的任务，它改一条价格、删一批"过期"记录、合并两个"重复"客户——每一步都符合"任务的意图"，每一步都可能是一场灾难。

如果是数据，那么AI就是数据面前的一个办事员——谁来办事、按什么规矩办、办完留什么痕，全由数据这一侧说了算。AI再聪明，也得在窗口排队。

第十一章说过，数据中台是"金库的防盗门，不是金库本身"。这一章，我们把这道门拆开来，看看它凭什么守得住一家企业的全部家当。

我的答案，先放在这里：新架构的中心不是AI，也不是数据，而是"AI与数据之间的关系"——数据中台就是这个关系的具体化。 AI负责理解与裁量，确定性系统负责边界与副作用（这是全书反复出现的第三条命题）——落到数据这件事上，数据中台就是那个"确定性系统"。

所以，第一块基石不是AI，是数据的围栏。这不是保守，这是第十章裁量度模型的直接推论：AI可以自由发挥的，永远只是"判断"；它碰"事实"的每一步，都必须走确定性的通道。

二

在画新一代数据中台之前，得先诚实地面对一段行业历史——以及一个需要纠正的流行印象。

"数据中台"这个词，不是本书发明的。2015年前后，大型互联网公司把它当成战略级工程，一时间各行各业纷纷上马。它的核心思路到今天看依然是清晰的：把散落在几十个系统里的数据汇聚起来，统一建模、统一口径，然后以数据服务的形式开放出去——这套方法论有一个著名的名字：OneData + OneService。OneData管"数据资产怎么定义"，OneService管"数据怎么变成服务"。

很多朋友对数据中台有一个印象：它不就是个大型只读数据库，给老板做报表用的吗？

这个印象是错的，我要先替它正名。 我做数据中台那些年，见过它最完整的样子：主数据管理提供增删改查接口——客户、物料、供应商的档案，在统一平台上创建、修改、审批、分发到各业务系统；数据服务层把加工好的数据封装成API，供各业务系统调用——订单系统查客户信用、供应链查物料齐套，调的都是中台的接口。它从来不是只读的，它一直在"给业务用"，而不是"给人看"。

那它后来为什么还会被质疑？投入巨大、回报平平的案例，又出在哪？

我的看法是：上一代数据中台把"开放"做得很出色，把"守护"留给了调用方。

开放——打破孤岛、统一口径、数据资产化、以API形式送到每个业务系统的门口。这些它都做到了，数据确实"用起来"了。

守护——谁来改数据、改得对不对、改完有没有痕迹。这些，旧数据中台主要交给调用方自觉。它服务的是确定性程序：业务系统里写好的代码。代码是可信的——它执行写死的逻辑，不会自作主张，不会被一封信诱导。所以旧架构的默认假设是：调用方守规矩，数据中台管好"供"，各系统自然会管好"用"。

这个假设，在AI时代第一次不再成立。调用数据服务的，从训练有素的代码，变成了概率性的Agent——它可能被注入的指令诱导，可能自己犯浑，可能为了完成"任务"去做一件没人批准的事。当"改数据"的主角变成这样的存在，企业凭什么放心？

用一个类比：上一代数据中台是自来水厂——把水净化好，管道铺到每个业务系统门口，各系统按需取用。水厂管供水，不管每个水龙头后面接的是什么机器、会不会乱放水。以前没事，因为水龙头后面都是守规矩的机器；现在，水龙头后面来了一个手脚麻利、心思活络的新住户——Agent。

所以，新架构里的数据中台，不是给老概念翻烧饼，而是把"开放"升级为"守护"：

自来水厂升级成了什么？金库。 管道的功能保留——数据依然要送到每个需要它的地方；金库的功能新增——任何人、任何AI，想动里面的东西，必须走门，而门上装满了校验、审批和记录装置。

这个转换，才是"AI时代数据中台"的真实含义。

三

先澄清一件事，免得读者以为前面刚说完"旧中台就有"，这里又要"重新发明"。

主数据、统一接口、校验规则、审计日志——这四样，上一代数据中台多少都有一些。但它们的定位是"好习惯"：调用方是守规矩的代码，校验尽力而为、审计事后能翻，也就够了。新架构把这四样全部升级为"架构强制"：调用方是不可全信的Agent，所以校验不再是尽力而为，而是绕不过去的门；审计不再是事后能翻，而是只许追加的账。同一个名字，从"建议"变成了"闸门"——这就是新旧中台在技术细节上的全部差别，也是"开放"与"守护"两种姿态的落地。

金库要怎么建？把新数据中台的核心功能拆开来看，一共四件，一件比一件关键。

第一件：主数据——每样东西只有一个"户口本"。

客户、产品、物料、组织、员工——企业的核心业务对象，在数据中台里只存在一份权威定义，行话叫"单一事实来源"。谁是对的呢？户口本是对的。别的系统想用"客户"这个概念，引用的就是这一份。

第二件事是统一通道——所有读写都走一个门。

技术上这叫"微服务化的CRUD接口"，翻译成人话：企业里所有想查数据、增数据、改数据、删数据的动作，不管是人发起的还是Agent发起的，都必须调用数据中台提供的标准接口，没有第二扇门。想绕过接口直连数据库？在架构上就不给这条路。

这不是技术洁癖。这是安全模型的根基：破坏力被限定在门口。即使一个Skill写错了，即使一个Agent犯浑了，即使有人恶意篡改了Skill的文本——它最终能对数据做的，也仅仅是"调用接口"这一个动作。而接口上装着第三件东西。

第三件事是校验内置——门上装着安检仪。

字段完整吗？金额在权限范围内吗？这条记录允许这个身份修改吗？工号符合规则吗？——这些校验规则长在接口里，是数据中台的一部分，不依赖任何调用方的自觉。AI想让数据通过校验，靠的不是"它表现好"，而是"数据本身过关"。第十章说过"严格执行区连人都不该自由发挥"——在数据这件事上，校验就是那个不容发挥的严格执行区。

第四件事是审计留痕——门上还装着摄像头。

谁、在什么时候、改了什么、从什么改成了什么——每一次数据变更都留下完整记录。而且这里有一条铁律，值得用一句重话来说：审计记录只许追加、不许涂改。 就像财务的账本：记错了，划线更正、再记一笔，而不是撕掉重写。工程师的说法叫append-only——"能改的证据，等于没有"。一条可以被人随手修改的审计日志，在追责的那一刻毫无价值。

这四件合起来，工程师圈子里有一个更系统的说法，来自我们第十章致敬过的那部开源著作：真相契约——每一个持久状态，都有明确的当家人（owner）、唯一标识、版本，和合法的读写路径。"哪份数据算数"这个问题，从制度上就没有模糊空间。

我来把这个契约翻译成业务语言，就是四句口诀：

每份数据有当家人；每次修改走大门；每道关口有安检；每笔变更进账本。

第四句，也可以说成：一次修改有没有真的生效，账本说了算，不靠调用方自己报功。 这句的口径，和第十五章讲工具执行时的"对账"是一脉相承的——企业级系统与玩具系统的分水岭之一。

四

第三节说的"升级为强制"，解决的还是老问题——谁能改、改得对不对。但新架构里有一件东西，是上一代数据中台几乎没有的：语义层。

设想一个场景：业务人员在写一份"大客户关怀Skill"，其中有一条规则——"合同到期前60天，自动提醒客户经理跟进"。写这条规则的时候，他需要知道"合同"这个数据从哪张表里取吗？需要知道客户的合同记录存在ERP的哪张表里、到期日是哪个字段、字段格式是日期型还是文本型吗？

在过去，他需要。这正是业务人员永远写不了程序的根本原因之一——哪怕只有一条规则，他也得先搞懂底层的表结构。懂表结构的人是IT的人，于是逻辑又回到了IT手里，二元割裂的死结又系上了。

语义层就是用来斩断这个死结的。它在物理数据之上，盖了一层业务概念的统一视图：业务人员说"客户"，语义层知道这对应底层系统里的哪个对象；说"合同到期日"，语义层知道去哪张表、哪个字段取，格式怎么转。Skill直接面向"客户""合同""订单"这些业务概念编程，而不面向表和字段编程。

我在那家科技公司做主数据那些年，最深的体会就是这件事的分量。同一个"客户"，在销售系统里叫一个编号，在财务系统里叫另一个编号，两个编号背后才是同一家公司。客户公司改了个名字，销售系统改过来了，财务系统还是旧名，客服系统里干脆两个名字并存——三个名字一张脸，谁能说清哪个是对的？语义层的价值，就是让这种"同一种事物、多副面孔"的局面从此终结：企业第一次用同一种语言谈论自己的业务对象，而且这门语言，人和AI都说得。

第2章说过，我们当年把"名词"们统一管起来，是数字化的上半场最大的成就。但那一轮统一的止步于"管起来"——各系统的数据物理上汇聚了，业务概念上仍然是各说各话。语义层是把这场统一推向逻辑层：统一的不只是数据的存放，更是数据的含义。

对业务读者，我可以用一句话概括这一节：语义层之前，数据是IT的方言；语义层之后，数据是全企业的普通话——AI说的也是这门普通话。

这也是为什么业务人员敢写、能写Skill的架构前提：写Skill的时候，他使用的是自己讲了半辈子的业务语言。语言没有换，只是现在，机器听懂了。

五

到这里，数据中台的主体讲完了。还剩一个第十一章留的尾巴要收：它和动作网关，到底怎么分工？

回顾一下第十一章那两个"唯一通道"：

• 数据中台，是数据的唯一通道
  ——管"读"和"写"
• 动作网关，是行为的唯一通道
  ——管"做"

"读"和"写"好理解：查一个客户、改一笔订单，都是数据操作，走数据中台。

"做"是什么？是那些不落成数据、却改变真实世界的动作：发一封邮件、调一个外部物流接口、创建一张采购工单、修改一条系统配置、给某个审批流点一个"同意"。这些动作的共同点是——它们不是"对数据的修改"，而是"对世界的作用"。

为什么要分两个门？因为这两类风险的形态完全不同。

数据的风险，是记录被改坏——改错了可以回滚，账本可以还原。所以数据中台的策略是"校验+审计"，事后有账可查。

行为的风险，是后果泼出去——邮件发出去了就是发出去了，采购订单传给供应商了就是传出去了，泼出去的水收不回。所以动作网关的策略更前置："确认+闸门"——Skill标注了要人批准的动作，网关在执行前硬性拦下，弹到人面前；没有任何"先斩后奏"的空间。

用一句话记住这对分工：数据中台管"纸上"的事——写错了能涂改；动作网关管"泼出去"的事——出手前必须拦住问一问。

两个门合起来，覆盖了Agent全部三种动作——读、写、做。这就是第十一章说的"双唯一通道"：Agent的每一步，要么在门里被放行，要么在门里被拦下，不存在第三种走出大门的方式。

有读者可能会问：发一封邮件这种事，为什么不能也算"写数据"——把邮件写进数据库，不就归数据中台管了？问得好，这恰恰是动作网关必须独立存在的理由：邮件写进数据库，只是记录了"邮件的内容"；而"把邮件送达对方的邮箱"是一个外部副作用——它依赖外部系统、产生外部后果、可能失败、可能重复。数据库管不了别人家的门。这就是第十章引过的那句"数据库说成功，外部世界另有一本账"——对账的两本账，就必须有两个管账的门。

六

架构讲到这里，我欠了读者一个旧账，该还了。

还记得第2章那个"0→1→0"的故事吗？PLM重构时，有人发现一段代码：把一个物料的状态从0改成1，再从1改回0。开发不知道为什么这么写，业务不知道，数据部门也不知道——没有任何人知道这段代码为什么存在。重构时它被当作垃圾删掉了。三天后，生产部门的计划调度软件瘫痪了。原来那段"莫名其妙的代码"维系着生产系统对物料状态的某种依赖。

当年那个会议室里的沉默，我到今天都记得。但这一章写到这里，我想邀请读者跟我一起，把这段故事放进新架构里重新演一遍——看看同样的代码，在新世界里还能不能活下来。

在新架构下，那个开发者面对的任务是一样的：让物料状态发生一次"0→1→0"的变化。他会怎么写？

他写不了"直接改库"的代码——因为架构上不存在直连数据库的路。他能做的，是调用数据中台的接口，提交一次状态变更。而接口会问他三个问题：这个状态变化，对应哪条已发布的Skill规则？变更的依据是什么？这个操作在你的权限范围内吗？

如果前两问答不上来——一次没有规则依据的状态回退，接口会拒绝。审计账本上会留下一条"被拒绝的写入"。

好吧，就算这位开发者很厉害，给这段操作编了一套说得过去的规则依据，把"0→1→0"做成了一个正式发布的流程。那么它就从"藏在代码里的私货"，变成了"Skill中台里一份有版本、有Owner、有审计记录的公开规则"。三年后重构，再也没有人需要对着一段代码面面相觑——翻开Skill，谁写的、为什么写、谁批准的、上一次变更是什么时候，清清楚楚。就算它真的错了，回滚的是一份文档版本，而不是一串生产事故。

看到了吗？同样的"0→1→0"，在旧架构里是一颗定时炸弹，在新架构里最多是一份被质疑的文档。

差别不在开发者，在架构。旧架构给"说不清的操作"留了藏身之处——代码深处，无人问津；新架构不给任何操作留藏身之处——所有对数据的触碰，都过门、过检、留痕。不是人变可靠了，是藏身之处没有了。

这就是我对"数据中台是不是又一个集权大泥球"这个质疑的回答。有人担心：所有数据都从一个门进出，会不会造出一个臃肿迟缓的庞然大物？请分清楚两件事：

数据中台的"厚"，是数据治理的厚——主数据、校验、审计，这些是必须厚的地基。但它不管逻辑——合同到期该提醒谁、折扣超限找谁审批、什么条件触发什么流程，这些业务逻辑住在Skill里，属于Skill中台和业务部门。数据中台不知道"业务应该怎么走"，它只忠于一件事：事实的记录与守护。

一个只管事实、不管逻辑的关口，厚而有界。这和大泥球——数据和逻辑搅成一团的旧应用——有本质区别。

七

收个尾。

这一章我们第一个重大决策问题开始，走完了数据中台的全部主体：它从"自来水厂"到"金库"的身份转换（开放升级为守护），四件套（主数据、统一通道、校验内置、审计留痕）构成的安全模型，翻译成业务语言的四句口诀，让业务语言成为编程语言的语义层，与动作网关"纸上/泼出去"的分工界面，以及——最重要的——"0→1→0"在新架构下的重演：架构的责任，是让说不清的操作无处藏身。

最后我要回答：为什么把数据画在最底层？

因为一座楼有多高，取决于它的地基有多实。AI的聪明决定这家企业能做什么新事情；而数据中台的可靠，决定这些新事情能不能放心地做。聪明决定上限，可靠决定下限——而企业级三个字，从来是由下限定义的。第十章讲裁量度时说过：AI的自由度，取决于它的输出可不可验收。现在可以再往前推一步：AI的可验收，最终落在数据的可追溯上。

地基夯实了。接下来上第二层：数据管的是"名词"，逻辑管的是"动词"——几万条企业规则，注册在哪、谁来编排、怎么晋升、如何退役？

第十三章：Skill中台，企业逻辑资产的注册与编排。