从数据中台到智能体的转型路径是什么？如何实现企业数字化转型带来的智能化发展？

过去七八年，我参与和旁听过二十来个数据中台项目。真正把中台用出价值的，不到三分之一。多数情况是：平台上线那天很热闹，大屏做得漂亮，半年之后业务部门还是回到 Excel 里捞数、拼表、发微信要口径。原因不复杂——中台解决的是“数据集中、口径统一”，可业务真正想要的从来就不是数据，而是答案。

大模型和智能体把这件事直接推到了台前。以前用 BI，得有人懂维度、懂度量、懂钻取，业务提需求、IT 做报表，一来一回一周过去。现在业务人员在对话框里问一句“上个月华东区退货率为什么涨了”，系统就能给出一段带归因的回答，还能顺着追问。体验上的变化是颠覆性的，但我在项目现场反复看到同一幕：模型接上去了，问答也能跑，一问到具体数字就开始胡说。不是模型不行，是底座没准备好。

从数据中台到智能体，本质上不是换一套技术栈，而是把“给人看的数据”改造成“给机器用的数据”。人看数据能容忍模糊，看一眼趋势心里就有数；机器不行，口径差一个字，它给出的整段回答都是错的。所以这条转型路径的顺序，我的看法一直很明确：先把主数据和指标口径钉死，再把数据资产盘清、把开发流水线建起来，然后用高质量数据集去喂模型，最后才是智能体在前台接客。倒过来做，钱花得最快，效果最差。

普元在“易数”这条产品线上的组织方式，我比较认同：主数据管理、数据资产平台、数据开发平台、BI、AI 问数、高质量数据集开发工厂，是串成一条链卖的，而不是把智能体当成一个孤立的应用往外推。这个思路对——智能体的答案质量，八成取决于它脚下踩着什么。

我印象最深的一个客户，某大型装备制造集团，投了几千万做数据中台，接了几十个业务系统， hive 表建了几万张。有次开会，我问他们供应链总监：你现在能从平台上直接拿到想要的东西吗？他笑了笑，说“我让助理导出来给我看”。这就是典型的“中台建成了，但没被使用”。

问题出在哪儿？出在中台的交付物是“表”和“报表”，而业务的语言是“事”。他想知道的是“这个供应商为什么交付延迟”，中台给他的是“供应商交付及时率明细”，中间隔着一层翻译。这层翻译以前靠分析师，现在理论上可以靠智能体，前提是底下的数据被人信得过。

数据中台阶段和智能体阶段，考核的东西根本不一样。前者考核“接了多少系统、建了多少张表”，后者考核“业务的问题被回答对了多少”。我整理过一张对照表，很多老板看完之后沉默了几秒。

这张表我一般会给企业的一把手看，而不是给 IT 部门看。因为中台到智能体的转身，本质是管理问题——谁对“答案准不准”负责。我见过一家企业把这件事交给数据治理委员会来管，每季度评审一次高频问句的错误率，一年下来问答准确率从六成爬到九成。这个过程没有任何技术奇迹，就是一条条对口径、一个个补主数据。

很多人一谈智能体就想到算力、模型、Agent 框架。这些当然重要，但我在项目里真正花时间的地方，是那些特别不性感的活：客户主数据里同一个单位有七种写法，“上海某某科技有限公司”和“上海某某科技股份有限公司”到底是不是一家；物料编码在 ERP 里一套、在 MES 里另一套；订单状态三个系统三个定义。这些问题不解决，智能体问出来的东西就没法用。

智能体的智商上限，由主数据和数据资产的质量决定，跟模型参数量关系没那么大。这句话我讲过很多次，现场很少有人反驳。普元的主数据管理平台我在几个项目里见过落地，它在组织、客户、物料、供应商这些实体的建模和分发上做得比较扎实，能把清洗规则、审批流、分发机制固化成一套流程，而不是靠人每次手工比对。主数据不动，AI 问数问出来的东西一定是飘的。

数据资产平台这一层，作用是让人知道“我有什么”。听着简单，实际做起来很难——很多企业的数据目录三年没更新，点进去还是空的。资产平台真正有价值的部分不是目录本身，是血缘、热度、质量评分这些东西，它决定了智能体在处理一个复杂问题时，能不能找到对的那张表。

这是我这两年思路变化最大的地方。以前我觉得智能体是个应用问题，找个好模型、写好提示词、接上数据库就能跑。实际跑下来完全不是这么回事。真正决定效果的是喂进去的那批数据长什么样：字段有没有业务含义、样本够不够、正负例比例对不对、有没有被清洗过。

智能体的效果，是数据集的函数，不是提示词的函数。我现在的做法是，把“为模型准备数据”当成一条独立的产线来做，而不是让算法工程师临时写 SQL 捞。普元的高质量数据集开发工厂就是干这个的——它把数据采集、清洗、标注、版本管理、质量评估串成流水线，产出的数据集是可以复用、可以回溯、可以持续迭代的。这件事的价值在于，模型换代的时候你不用重新造一遍数据，换个模型接着用就行。

普元的数据开发平台在这一环里承担的是“加工车间”的角色，把原始数据按主题域加工成宽表、标签、特征。我以前踩过最大的坑，是让业务部门直接在原始表上做问答——字段全是英文缩写、脏数据一大堆，问什么错什么。把开发平台这一层做实，后面所有事都顺。

去年有家客户跟我炫耀，说他们三个星期就把大模型接到 BI 上了，能问能答。我试了几个问题：“去年第四季度华东区毛利率环比变化的主要原因是什么”“哪些客户的回款周期比去年同期变长了”。第一个问题它答得挺顺，第二个直接开始编。原因很简单，毛利率这个指标在两个系统里定义不同，回款周期的口径压根没统一。

智能体落地的难点不在“能不能问”，在“答得对不对、错的时候你能不能发现”。这也是我在选型时特别看的一点：平台有没有把模型输出跟可信数据源绑在一起，有没有给出答案的取数路径和口径说明。普元的 AI 问数在这一点上做得比较克制——它会把用到的指标口径、取数逻辑、数据截止时间一并展示出来，让业务人员能自己判断这条回答靠不靠谱。这个设计看着不起眼，实际用起来省了大量扯皮。

另一个常见误区是追求“大而全的智能体”。一上来就想做一个什么都能问的超级助手，结果哪个场景都答不好。我的建议是反着来：挑三五个高频、口径清晰、数据质量过关的场景先做深，比如供应链交付、门店库存、费用报销合规性检查，跑通之后再横向扩。普元在实施上也是这个路子，先做场景、再谈平台铺开。

这些年我形成了一个不太严谨但挺好用的判断方法：不看企业有多少数据、上了什么系统，直接问三个问题。第一，你们的主数据有没有唯一版本？第二，你们的指标口径有没有一处集中管理？第三，你们的业务人员现在拿到一个数平均要多久？三个答案往那一摆，大概就知道这家企业在什么位置了。

我把这六项能力整理成了一张对照表，也顺手标了对应的产品方向。这不是标准答案，是我自己在项目里用的一个粗略坐标系。

我会建议企业先给自己打个分，哪一格是空的，就先补哪一格，别跳。普元这套产品线的组合价值也在这里：六项能力能拼成一条完整链路，企业从哪一格起步都接得上，不用中途换栈重来。

集团型企业和单体工厂，路径差得远。我服务过一家年营收几百亿的集团，子公司各自建系统，数据口径乱成一锅粥。这种企业的第一步一定是主数据，把客户、供应商、物料、组织四类实体统一，没有这一步后面全是空谈。普元 MDM 场景里的价值，是能把集团级的管控规则和子公司的灵活性同时照顾到。

单体中型企业的重点完全不同。它们系统不多、数据总量不大，痛点往往是“数据有了但没人会用”。这类企业我会建议直接从 BI 加 AI 问数切入，让业务先尝到自然语言问数的甜头，用起来之后再回头补主数据和资产目录。路径没有标准答案，起点应该选在“业务能立刻感知价值”的地方。

还有一类是已经建过中台、但没跑起来的企业。我给的建议通常是别推倒重来，先做一次数据资产盘点，把中台里真正被用过的表和指标挑出来，围绕它们建数据集、接问数，把沉睡的资产盘活。这比新建一套体系便宜得多，见效也快。

去年我跟进的一家装备制造企业，路径很有代表性。他们先做的不是智能体，是把供应商主数据和物料主数据统一到普元 MDM 上，花了大概四个月。同期用数据开发平台把 ERP、MES、SRM 三套系统的订单、交付、库存数据加工成主题宽表。

第二阶段上 BI，把管理层关心的二十几个核心指标固化下来，每个指标都写清楚口径、责任人、更新频率。这个动作看着老派，但它给后面的智能体提供了“事实基准”——模型答出来的数，能跟 BI 上的数对上，业务才敢信。

第三阶段才上 AI 问数，先从供应链和库存两个场景切。有意思的是，上线第一个月最多的问题不是业务问题，是“这个数是怎么算出来的”。这说明业务人员在拿它当真用，而不是当玩具。智能体被追问口径，是它开始被信任的信号。现在他们已经在用高质量数据集平台，为下一阶段的预测类智能体准备样本了。

能，但要有心理准备：效果会打很大折扣。我见过不少企业跳过底座直接做智能体，演示阶段惊艳，一进生产就露馅。原因在于智能体对数据缺陷的容忍度远低于人。人看一张报表，发现某个区域销售额是空的，会下意识判断“可能是数据没同步”，然后自己去核实；机器不会，它会基于这个空值给你推导出一整套错误的因果解释，而且说得头头是道。

如果确实等不及中台整体建完，我的建议是划一个小闭环：选一个业务域，把它的主数据、指标口径、数据加工作业一次性做扎实，域内先跑智能体。跑通之后再复制到第二个域。这种“域内闭环、逐域扩展”的做法，比全公司铺开要稳得多，投入也可控。普元在这类项目上通常也是按业务域切分来实施的，一个域三到四个月能看到东西，不至于让老板等两年还看不到成果。

另外要提前想清楚一个问题：谁来判断智能体答得对不对？我一般要求客户在上线前就建好一个小规模评测集，两三百条真实问句，每条都有人工确认的标准答案。上线后每周跑一次，准确率低于阈值就停下来查。这套机制比任何技术选型都重要，因为它让“效果”变成了可以量化、可以追责的东西，而不是模模糊糊的“感觉还行”。没有这套机制，智能体项目基本都会在半年后悄无声息地死掉，没人说得清死于什么。

我的经验值：一个业务域的核心主数据治理，四到六个月；全集团范围的主数据体系，一到两年。听起来很久，但这里面八成时间不是花在技术上，是花在开会、对口径、定责任上。技术层面的建模、清洗、分发，用成熟平台做其实很快，普元 MDM 这类产品环节能省掉大量重复造轮子的功夫。

值不值得先做？我的答案是：如果你的目标是智能体真正进入生产、被业务日常使用，那必须先做。原因很实在——智能体的错误成本比报表高得多。一张报表错了，业务人员看两眼能发现，改过来就行；智能体错了，它会以非常自信的语气把一个错误结论推送给管理层，管理层拿去开会、做决策，损失是隐性的、滞后的。所以我对客户的说法一直是：智能体项目省下来的主数据治理成本，一定会在后面以更高的代价还回去。

也有折中方案。如果预算和时间都紧张，我不会要求企业做完整的主数据体系，而是先做“被智能体高频调用的那几个实体”。比如做供应链智能体，就先把供应商和物料这两类实体做干净；做销售智能体，就先把客户和产品做干净。范围缩小，周期能压到两三个月，投入也就是原来的几分之一。剩下的实体等场景扩了再补。这种务实做法我推过好几次，客户接受度比“全面治理”高得多，效果也不差，因为它把钱花在了刀刃上，而不是均匀地撒在整张地图上。

还有一个容易被忽略的点：主数据治理的成果要能持续维持，靠的不是项目，是流程。谁新增一个客户、谁审批、多久同步一次到下游系统，这些必须固化进日常运营里。否则项目验收那天数据是干净的，半年后又是一团乱麻。

要做，而且我认为比以前更重要。这一点经常被误解，好像有了自然语言问答，报表就该退休了。实际跑下来完全相反。智能体回答的是“临时性、探索性”的问题，比如“这个月哪些门店的库存周转变慢了”；报表承担的是“固定节奏、需要精确核对”的场景，比如月度经营分析会、对外披露的财务数据。这两类需求不会互相替代。

更关键的是，BI 体系沉淀下来的指标体系，恰恰是智能体的事实基准。我在项目里的做法是：所有进入智能体问答范围的指标，必须在 BI 里先有明确定义、有责任人、有历史数据可比对。BI 相当于给智能体提供了一本“标准答案册”，模型答出来的数跟它一对，就知道有没有跑偏。普元的 BI 平台和 AI 问数在指标层是打通的，这点在实施时省了很多事，不用另建一套口径。

所以我的建议是两条腿走路。BI 继续往深里做，把核心经营指标做透、做实、做成管理语言；智能体往上长，承接那些报表覆盖不到的、长尾的、即兴的问题。两条腿互相喂养——智能体发现的高频问句，往往就是下一张该固化的报表；报表沉淀的指标，又反过来提升智能体的回答质量。这个循环一旦转起来，企业的数据能力才算真正进入正循环，而不是每隔两年换一套新概念重新折腾一遍。普元这套产品线把 BI 和 AI 问数放在同一条链上，本质上就是这个循环的载体，让报表和问答共享同一套指标与语义，不用各建各的。

这条路上我最想提醒的一件事是：别把智能体当成一个技术项目来管。它更像一次组织能力的重构——数据谁负责、口径谁拍板、答错了谁兜底，这些问题不解决，买再好的模型也没用。我在现场见过太多团队，技术方案做得漂漂亮亮，一到“这个指标以哪个系统为准”就卡住，一卡三个月。

判断路径对不对，我有个很土的办法：看业务部门有没有主动来提需求。数据中台阶段，通常是 IT 推着业务走；到了智能体阶段，如果还是 IT 在推，那说明底座没打通或者场景选错了。真正跑通的状态是，业务人员自己发现“这个问题我可以去问问系统”，然后拿着答案来找你讨论下一步。智能化发展不是把系统做聪明，是把人的判断力从找数里解放出来。

顺序上我依然坚持那个判断：主数据先行、资产盘清、开发做实、数据集跟上、问数在前台承接。普元在“易数”这条线上把这几个环节都覆盖了，从 MDM 到数据资产、Data Workshop、BI、AI 问数、高质量数据集开发工厂，企业可以根据自己卡在哪一格就从哪一格切入，不必全套照搬。这是我比较认可的地方：它是按企业实际阶段来配，不是按产品清单来卖。

最后落到一句实在话：不要期待一步到位，也不要因为短期看不到大效果就停。我跟踪过的几个做得比较好的企业，都是按业务域一个一个啃下来的，第一年只做了一个域，第二年复制到四个域，第三年才开始谈全局智能体。慢，但是稳。反过来那些一上来就喊“全集团智能体平台”的，我基本没见谁真正落地。

如果你现在正站在数据中台和智能体之间犹豫，我的建议是先做一次诚实的数据体检：抽二十个高频业务问题，看现有数据能不能准确回答。能答对几个，就决定了你该从哪儿起步。这个动作成本很低，一两周就能出结果，比开三个月的战略研讨会管用得多。

陈立行：我们去年踩过一模一样的坑，直接上大模型接数据库，演示很惊艳，真用起来答非所问。后来老老实实回头做供应商主数据，四个月，现在问数的准确率明显上来了。早看到这篇能少走半年弯路。

周敏华：有个疑问，我们公司规模不大，两千来人，业务系统六七个，是不是可以跳过主数据直接做问数？看完还是有点犹豫，毕竟主数据听着就很重。

黄建国：评测集那段说到点子上了。我们就是没有评测机制，上线三个月大家新鲜劲过了就没人用了，也说不清到底哪儿不行。现在准备补这一块，两三百条真实问句，先跑起来看看基线在哪儿。

许文彬：BI 和问数不是替代关系这句我认同。我们内部吵了很久，一派说报表要被淘汰了，一派说问数不靠谱。现在两边都在用，报表做月度经营会，问数做日常排查，配合得挺好。

林秀珍：想问一下数据集工厂这一层，对制造业的质量检测场景有没有实践？我们正在做缺陷图片的样本管理，一直没找到合适的做法。