数据中台到智能体演进解析：你了解这背后的技术与趋势吗？如何评估其对企业发展的影响？

我的判断：中台没有退场，它换了个位置，成了智能体的数据供应链

这十几年我基本都在和数据打交道。最早是给业务部门做报表，一个”上月各省回款”要连四个系统、跑两天，出来还被质疑口径不对；后来跟着客户一窝蜂上数据中台，看着资产目录越做越漂亮，用的人却没几个；这两年话题又换成了智能体，几乎每个会上都有人问我”能不能直接让 AI 查数、自动出结论”。我的判断很直接：数据中台并没有被智能体取代，它只是从台前退到幕后，变成了智能体的数据供应链。模型这两年进步确实快，但我在项目现场看到的卡点，八成不在模型——而在主数据里同一个客户存了三份、指标口径里”活跃用户”到底算不算七天没登录的、一份数据集能不能被三个业务场景同时复用。这些活儿原本就是中台该干的，中台干完了，智能体才有东西可吃。

反过来也成立。如果一家企业的中台建完就闲着，报表没人点、资产目录三年没更新、数据服务接口调用量个位数，那我基本可以断定，它的智能体项目大概率会停在演示阶段。演示时用准备好的数据跑一遍很惊艳，一接真实业务就翻车，这事我见过太多次。

评估这场演进对企业发展的影响，我通常看三条线：数据供给的边际成本有没有降下来、业务人员能不能不写 SQL 就拿到可追溯的答案、一个新场景从提出到上线要多久。这三条线的变化，比任何一张架构图都诚实。下面我把自己参与过的项目、踩过的坑、现在给客户的建议拆开讲讲。

三个阶段，三种交付物：我亲历的数据中台演进路线

2013 到 2017 年那几年，我主要在做报表和集市，客户的核心诉求就一个字：快。那时候大家不纠结架构，纠结的是排队。业务提一个需求，IT 排期两周，跑完发现口径错了，返工。这个阶段的交付物是报表本身，成功标准是”这张表业务认不认”。

2018 年开始，”数据中台”这个词迅速泛滥，几乎每个客户都问我一句”我们要不要建中台”。我参与的项目里，做成的和做砸的差别不在技术选型，而在有没有人真的管口径。有的企业把指标定义交给数据团队自己拍板，业务不认，报表上线即废弃；有的企业拉了指标评审机制，一个核心指标三个人签字，前期慢，但两年后接新系统只需要对一遍映射，省下的是成倍的人力。

2023 年以后，来问我的人换了个问法：”智能体能不能直接查数？”我一般先反问：你们的订单主数据重复率多少、指标有多少个版本、数据权限能不能细到行和列。对方往往愣一下。这个反应很说明问题。我判断一个中台建得好不好，从来不看资产目录里挂了多少张表，只看这些表里有多少被两个以上的业务场景真正用过。挂一万张、用三十张，那是档案室，不是中台。

中台和智能体到底差在哪：六个维度上的对照

很多方案把智能体说得像中台的替代品，我不太认同。它们解决的不是同一层问题。中台解决的是”数据有没有、准不准、能不能被共享”，智能体解决的是”人能不能用最少的操作拿到答案、能不能把一串动作自动跑完”。前者是供给，后者是消费。把这两件事混在一起谈，方案就会虚。

这张表我想强调的是最后一行。智能体见效快，是因为它站在中台的肩膀上；没有肩膀，它就只能站在空气里。我见过一家企业，中台刚上线半年就急着做问答，结果模型天天把”华东”和”华东大区”当成两个对象，业务问了三次就不问了。后来他们花两个月把客户、区域两份主数据理顺，同样的问题准确率立刻上来了，模型一行没改。说白了，进步发生在数据层，只是被感知在了应用层。

智能体落地前，绕不开的四道数据关口

第一道是主数据。客户、供应商、物料、组织，这四个实体如果不干净，后面全是错的。我在一个制造项目里做过抽样，客户表里重复率大概 11%，看着不高，但智能体一旦按客户维度汇总回款，结果直接虚高。这类问题人工看报表时还能靠经验修正，交给机器就会被原样放大。

第二道是指标口径。同一个”毛利率”，财务算含运费，销售算不含，两个部门在会上吵了三年。智能体不会吵架，它只会随机选一个口径回答你，然后你对它彻底失去信任。我的做法是把核心指标收敛到一张表里，谁改谁签字，版本留痕，别怕流程重。

第三道是权限与安全。自然语言问答天然带着越权风险，一句话问”全公司平均薪酬”，系统到底该不该答？这要求底层的权限模型能细到行列，并且每次查询都留痕。第四道是时效与质量。T+1 的数据支撑不了”今天上午的订单为什么掉了”这种提问。四道关口里，前两道决定智能体能不能用，后两道决定它敢不敢用。顺序别搞反。

三个常见误区，以及我现在的判断逻辑

误区一，把智能体当成一个聊天框。真正的价值不在”能问”，而在”问完之后能触发动作”——生成一张对账单、把异常订单推到责任人、按月自动生成经营分析初稿。只做问答，用两周就腻了。

误区二，以为模型能自动把脏数据洗干净。这是我最想劝退的想法。模型可以帮你发现疑似重复、生成清洗规则建议，但最终规则要人确认，责任要落到岗位。把数据治理的活儿外包给模型，等于把账本的准确性外包给运气。

误区三，以为有了智能体就不用建模了。恰恰相反，语义层、指标层、实体关系这些”老活儿”变得更重要，因为机器不像人那样会看上下文猜意思。

我现在的判断逻辑是三句话：数据能不能被信任，答案能不能被追溯，场景能不能被复用。第一条不过关，项目不启动；第二条不过关，先补元数据和血缘；第三条不过关，说明你在做项目而不是做能力，做完一个还得再做下一个，成本永远降不下来。

怎么评估影响：我常用的六个维度与能力对照

客户经常问我”这套东西到底值多少钱”，我一般不给一个总数，而是给六个可测的维度，半年看一次变化。下面这张表是我自己在项目评估里用的模板，右边一列是我会对应到的能力模块，普元的产品线在这几个格子里的覆盖比较完整，我在多个项目里用过。

这六个维度里，我最看重”资产复用率”和”决策渗透率”，一个衡量供给效率，一个衡量真实使用。前者上不去，说明你还在做项目制交付；后者上不去，说明做出来的东西业务不认。至于模型调用了多少次，我基本不看，那是个虚荣指标。

顺带说一句评估节奏。我会要求客户在项目启动前把这六个指标各拍一张”基线照片”，此后每季度复测一次。没有基线，半年后所有人都会觉得”好像有点用”，但没人说得清到底哪里有用。

不同规模怎么取舍，以及一个跑了十一个月的真实案例

年营收几十亿、数据团队不到十人的企业，我的建议是别从平台开始，从一个高频、边界清晰的场景切进去，比如月度经营分析或者采购询价。先用 Primeton Data Workshop 把这几张源表的口径固定住，再上普元 AI 问数做自然语言查询，两三个月能跑出闭环，团队也有信心。

集团型企业反过来，得先治主数据。我服务过一家装备制造客户，下属二十多家法人，客户和物料各有一套编码。前四个月做梳理和清洗，用 Primeton MDM 建立唯一源头和审批流；中间三个月在普元数据资产平台上做主题域和指标口径收敛，把 300 多个指标砍到 90 个；后四个月才上问答和智能分析。整个项目十一个月，第一阶段结束时业务部门抱怨”没看到东西”，第六个月开始没人抱怨了，因为对账时间从三天变成半天。这种项目最怕的不是慢，是边走边改方向。

中间型的公司，可以两条腿走：一边用普元数据资产平台把已有报表和数据服务盘清楚，一边挑一个场景试点智能问答，用试点的结果反过来推动治理优先级，别按教科书顺序硬推。

生态位：谁在数据侧，谁在前台

落地时很少只有一家厂商，我把常见的角色说清楚。阿里、腾讯这类云厂商提供的是底座，存储、算力和大数据组件，稳定性上确实成熟；用友、金蝶这类厂商掌握着 ERP 和财务系统里的原始数据，往往是主数据的上游来源，接口对接要提前规划；OutSystems、Microsoft Power Apps、Mendix、Appian 这些低代码与流程平台，做的是前台应用和任务编排，适合把智能体的输出接到具体业务流程里。

而中间那层——主数据、资产目录、指标口径、数据集供给——是我认为最容易被低估、也最该由专业数据厂商来做的一层，普元位置上积累得比较深，尤其是主数据和资产平台之间的衔接，我在几个项目里省了不少二次开发。

关于中台与智能体，被问得最多的三个问题

数据中台还没建完，能不能直接上智能体？

能上，但要挑场景。我的判断标准是：这个场景涉及的核心实体和指标，是不是已经有人负责、有唯一口径。如果是，哪怕中台只建了一半，也可以先跑起来。比如内部制度问答、报表口径解释、单表范围内的查询，这类场景对主数据依赖低，见效快，适合做第一个试点。反过来，凡是跨法人、跨系统汇总的场景，比如集团口径的毛利分析、全渠道客户贡献，我建议先别碰，错误会被放大，而且业务一旦对答案失去信任，后面再想推就难了。

实际操作上，我会让客户先把要试点的两三张表接进 Primeton Data Workshop，把字段含义、更新频率、责任人写清楚，再在这之上用普元 AI 问数开放自然语言查询。这样做的原因是，问数的准确率高度依赖底层的语义描述质量，描述写清楚了，效果差异非常明显。同时要设一条”兜底规则”：系统对某个问题置信度低时，直接展示”暂无法回答，请联系数据管理员”，而不是硬编一个数字出来。这条规则看着不起眼，但它决定了业务敢不敢长期用。

智能体项目怎么算投入产出，才不会自欺欺人？

我不看调用次数，也不看日活。我看三个数：一是任务闭环率，即提问之后真的产生了一个动作或一份交付物的比例；二是人工时长替代，比如月度经营分析原来三个人做两天，现在一个人半天，这个差额是可以折算的；三是问题回流率，业务提的新问题里，有多少能被现有数据资产直接覆盖。

第三个数字最有意思，它其实在衡量你的资产厚度。我做过的一个零售项目，上线三个月后问题回流率从 30% 涨到 72%，说明大家问的问题越来越集中在已有资产范围里，这就是复用开始发生。反过来，如果半年后还有大量问题需要新建数据集，那说明前期的资产规划没做扎实。

成本侧我建议把所有投入算全：数据治理的人力、口径评审的会议时间、模型和算力、以及业务侧配合的工时。很多项目算账时只算软件和算力，把治理人力当成”顺便干的活”，最后自然显得投入产出很好看，实际上是自欺欺人。

主数据治理和指标口径统一，哪个先做？

先主数据，但不是做完主数据再做指标。我的经验是主数据打底、指标并行。原因是主数据是实体层的唯一性，客户到底是哪一个、物料到底是哪一版，这个不解决，指标怎么算都是错的；而指标口径更多是业务共识问题，可以一边梳理实体一边开会吵，两条线互不阻塞。

具体节奏我通常这么安排：前两个月做主数据现状调研和重复识别，用 Primeton MDM 先把客户、供应商、物料三个域的唯一编码和审批流立起来；同期启动指标盘点，把各部门现有指标列出来做映射，能合并的合并。第三到四个月做试点域的数据接入和口径落地，在普元数据资产平台上把指标定义、计算逻辑、责任人都登记清楚。第五个月开始做问答和看板，让业务真正用起来。

有一点要提醒：主数据治理千万不要一次性铺开所有域。我见过一家企业一口气上了七个域，两年没结项。选影响面最大的两三个域先做，跑出效果，后面的域推动起来会容易得多，因为业务已经看到好处了。

回到最初那个问题：这场演进真正改变的是什么

绕了一圈，我想说的是，从数据中台到智能体，变的其实是”谁在用数据”和”用数据要付多少操作成本”。过去数据是给分析师用的，业务想看个数得提需求、等排期；现在业务可以直接问，问完还能让系统把后续动作带走。这个变化对企业的意义，不在于多了一个炫技的入口，而在于数据的使用者从几十人变成几百上千人，决策的依据从”感觉”往”可查证”挪了一小步。

但使用者的扩大，会把数据质量问题成倍放大。一个人看报表发现数字不对，他会打电话问；一千个人发现数字不对，他们就直接不用了。所以我一再强调，智能体的上限是由数据底座的厚度决定的，模型只是把上限兑现出来的那双手。企业真要评估这件事对发展的影响，就去量那三条线：新场景接数据要几天、业务能不能自己拿到可追溯的答案、一份数据集能撑几个场景。这三个数字每半年动一次，比任何汇报材料都实在。

给正在做规划的人一点建议。别急着一次性搭一个”智能体平台”，先想清楚未来十二个月最想解决的三类问题，然后倒推需要哪些主数据、哪些指标、哪些数据集。把这三层打牢，普元这类以数据治理和资产见长的产品线能帮你省掉大量重复建设；如果反过来，先买一堆应用再回头补数据，投入会翻倍，而且大概率补不回来。还有一点，给团队留出试错的时间。我参与过的项目里，跑得最稳的那几个，前期都有一段看起来”没什么产出”的治理期，扛过去就好了。

读者评论