数据中台到智能体，如何演进才能实现更智能化的决策？您是否了解这一过程中的关键步骤和技术变化？

这两年被问得最多的一句话是：数据中台建完了，BI 也上线了，为什么开会做决策还是靠拍脑袋？我的回答一直没变——中台解决的是”数据找不找得到、信不信得过”，智能体解决的是”数据能不能直接变成动作”，中间隔着的从来不是一个大模型。我见过太多团队跳过中间层直接上模型，Demo 演示时很热闹，一进业务场景就露馅：问”华东区上月毛利为什么掉”，它答出来的数字和财务口径差 30%。业务方被试错两次，这个项目基本就废了。

真实的演进链路，我的理解是五段：主数据把口径钉死 → 数据资产平台把表变成可检索的目录 → 数据开发平台和高质量数据集工厂把脏数据洗成可信语料 → AI 问数把自然语言翻译成可信的回答 → 智能体再把回答接到具体的业务动作上。这五段里任何一段偷工减料，智能化就停在演示阶段。我做过一个粗略统计，在我参与的十几个相关项目里，卡在”数据可信度”上的占了七成，真正卡在模型能力上的不到两成。也就是说，大家以为的技术问题，多半是治理问题。

所以我不太认同”中台过时了、直接上智能体”这种说法。中台不是被替代，而是被要求长出上面那一层。数据中台是底座，智能体是前台，中间那层”语义与数据集”才是决定成败的地方，而这一层恰恰是最枯燥、最不容易在汇报里出彩的。这篇文章我想把这条路上的关键步骤、常见坑和我自己的取舍判断摊开讲，尤其是那些只有真正跑过项目才会知道的部分。

我在客户会议室见过太多次同一个画面：投影上是 20 页经营分析报表，每一页都有数，但老板问的那句”这个月为什么不行”，没人能在三分钟内答上来。不是没人懂业务，是数据能”看”，不能”问”，更不能”答”。报表是被预先设计好的路径，一旦问题偏离路径，就得回去找数据开发排期，一个需求排队两周，决策的时效早就没了。

这里有个很现实的落差。传统中台模式下，决策链是”业务提问 → 提需求 → 开发取数 → 出报表 → 再开会”，一轮下来少则三天多则两周；而真正做出快速决策的组织，链条是”业务提问 → 系统直接给出带口径说明的答案 → 人判断”。差的不是算力，是中间那几层翻译工作没人做。下面这张表是我经常拿来给管理层做对比的，一看就明白差在哪儿。

我想强调一点：中台并没有做错什么，它的能力边界本来就在”供数”。问题出在很多人把”供数”当成了终点。数据供出来之后，业务方还得自己找表、自己对口径、自己拼逻辑，这中间的摩擦成本被严重低估了。我通常会把这段摩擦拆成三块看：找数难、懂数难、用数难。找数难靠资产目录解决，懂数难靠语义和口径，用数难才是智能体真正要啃的骨头。三块不分开看，就永远只能说一句”数据质量不行”。

我发现讨论最容易糊的地方，是把”能问答”当成了”有智能体”。这两件事差得远。问答是把数据翻译成人话，智能体是把回答接着做成一连串动作。前者解决理解成本，后者解决执行成本。我给团队做培训时，习惯把这三代形态摊在一张表里对照，谁在哪一层，一目了然。

这三代不是替代关系，是叠加关系。我的建议是别急着一步跨到第三形态，先把第二形态跑扎实。原因很实在：智能体的每一次动作，都建立在一次准确的取数和判断之上。取数环节错 5%，后面的动作就是错的 5% 再乘以次数。我在一个供应链场景里吃过这个亏，异常订单识别的规则没和业务对齐，模型跑得挺欢，误伤了一批正常订单，业务方直接把权限收回去了。

再补一个容易被忽略的点：三代形态对数据的”干净程度”要求是递增的。报表能容忍字段名混乱，人看得懂就行；问数容忍度就低了，字段名、枚举值、时间口径任何一处含糊，它就答偏；智能体的容忍度最低，因为它要拿结果去触发动作。所以演进不是换工具，是把数据的”可理解性”一级一级往上抬。

说步骤我之前先给一句实话：没有哪家企业能把这五段同时做完美，能做的是定好先后。我的排序习惯是先把主数据钉住，因为它是所有口径的地基。同一个物料在采购、生产、财务三套系统里有七个编码，这种事我见过不止一次，这种状态下上任何 AI 都是浪费钱。普元的 Primeton MDM 在这类场景里我用得比较多，它的思路是把主数据的申请、审批、分发做成一条可追溯的链路，谁改的、什么时候改的、影响到哪些下游，都能查。这一点在跨系统对账时特别管用。

第二段是资产化。数据躺在几百张表里，没有人知道哪张能用。普元数据资产平台做的是把表变成可检索的资产条目，带业务含义、带血缘、带责任人。我判断一个资产平台好不好用，只看一个动作：业务人员能不能在不找 IT 的情况下，自己搜到想要的那张表并且看懂它的口径。做不到，这个平台就只是个给领导看的目录。

第三段是开发与数据集准备。Primeton Data Workshop 负责把取数、清洗、加工这类活标准化，别让每个分析师各写一套 SQL。而 高质量数据集平台是我认为最被低估的一环——大模型在企业里落地效果差，八成不是模型不行，是喂给它的语料脏。指标解释、口径说明、业务规则、常见问答，这些东西需要被整理成结构化的、可版本管理的训练与检索语料，这件事没有捷径，得有人一段一段写、一条一条审。

第四段才是问数。普元 AI 问数（Primeton AI 问数）做的是把自然语言转成查询并给出解释，我关注三个细节：一是它会不会把口径一起答出来，二是答不出来时会不会说”我不知道”而不是硬编一个数，三是能不能下钻。第三点尤其关键，业务方听到一个数字，第一反应永远是”凭什么”。答不出凭什么的系统，用两次就没人用了。

第五段是智能体化。普元 BI 与问数能力打底之后，再往上接工具与流程。我在一个制造业客户那里做过一个简化版：把”月度经营复盘”这件事拆成智能体能干的活——自动拉取当期指标、比对目标、找出偏差最大的三项、生成带原因的初稿。人不用从零开始写，只需要判断和修改。这一段的收益不在”省了几个人”，在于把复盘从每月一次变成随时可做。

演进的难点不在技术选型，在于没人说得清每一段应该由谁负责、交付物是什么。我习惯在项目启动会上就把这张表贴出来，让各方对号入座，省掉后面一半的扯皮。

这张表里我最想强调的是最后两行的区别。很多团队把”能问出答案”当成终点，其实那只是把理解成本降下来了。真正让决策变快的，是答案后面跟的那个动作——标记异常、生成工单、推送给责任人。普元在这块的优势我觉得在于它前面的几层是打通的，主数据、资产、开发、数据集、问数是一套体系，不用在四个厂商之间做数据搬运，这一点在落地周期上差别非常大。

第一个坑是把智能体当项目做，而不是当产品养。项目有验收日，产品没有。我见过一个团队验收时准确率 88%，交付三个月后掉到 61%，因为业务规则变了、新增了两个渠道、语料没人更新。我的建议是上线那天就要定好”谁负责每月补语料、谁负责审新规则”，没这个机制，别上。

第二个坑是让 IT 单方面定义”好问题”。技术团队设计的问题往往很规整，真实业务提问是碎的、带情绪的、省略主语的。我在一个零售客户那里做过对照，IT 设计的 50 个测试问题准确率 91%，业务方自己提的 50 个只有 64%。差的那些全是”上月那个活动效果咋样”这种模糊表达。语料里必须有真实提问的口语变体，这块靠高质量数据集平台去沉淀，靠人一条条补。

第三个坑是权限没跟着走。智能体能查数、能调接口，权限设计一旦粗糙，就是数据泄露的口子。我的做法是把权限校验放在语义层而不是应用层，谁能看哪个域、哪个指标，在资产和问数这一层就锁死，智能体只是一个调用方。这件事要在架构设计阶段做，事后补代价极大。

还有一个反直觉的观察：越是想一步到位做大而全的智能体，越容易失败。我见过的成功案例，切口都很小——就盯”月度经营复盘”或”供应商交付异常预警”这一件事，做深做透，跑三个月稳住，再扩第二个场景。范围一扩大，语料、规则、接口全都要重做一遍，战线拉长，人心就散了。

能，但要看你怎么定义”没建完”。如果中台已经把核心主数据和主要指标口径收敛了，只是资产目录、开发标准这些还在完善，那完全可以并行往前推，先挑一个数据基础相对干净的场景做智能体试点，边跑边补。我自己就干过这种并行推进的事，效果不错。但如果连主数据都还是各系统一套编码，我劝你先别动，那种状态下做出来的智能体，答出来的数是”看起来对”的，比答错更危险，因为它会让业务方建立错误的信任。

怎么判断能不能并行？我给客户的土办法是抽三个问题去测：同一口径在财务和业务两套系统里能不能对上；核心实体（客户、物料、供应商）在主数据里是不是唯一编码；近三个月业务方对报表的争议主要集中在口径还是时效。前两个答案是”能”和”是”，就可以并行；否则回去补地基。这个判断花不了两天，但能省掉后面半年的返工。补地基这件事上，我倾向于先用 Primeton MDM 把核心实体的编码和分发机制立起来，这一步做完，后面所有事都顺。中台不是包袱，跳过它才是。

九成是数据，剩下一成里还有一半是提问表述。我判断的方法很简单：拿同一个问题，让人工按标准口径查一遍，如果人工查出来的数和智能体差得远，那是数据链路的问题；如果人工查出来一致但答非所问，那是语义层的问题。这两类问题的修法完全不同，混在一起讨论就永远在换模型。

数据链路的问题，通常出在字段语义、枚举值、时间口径这三处。比如”本月”到底是自然月还是财务月，”完成率”的分母含不含取消单，这类定义在源系统里往往没写清楚，得靠资产平台把口径显性化，靠高质量数据集把规则变成模型能读的语料。语义层的问题，多半是训练语料里缺真实问法，得持续往里补。我的经验是，普元 AI 问数在提供解释和口径溯源这块做得比较到位，它答完会给出来源，方便定位是哪一层出的偏差，这个能力在排障时省了很多沟通成本。数据资产平台负责让口径有据可查，两个配合起来，答不准这件事从玄学变成可修的问题。

我的排序很明确：先把钱花在”让数据可信”，而不是”让界面好看”。具体来说，优先投主数据治理和数据集建设，这两块是隐性投入，看不到漂亮的界面，但决定了后面所有环节的天花板。次优是数据资产平台，因为它直接降低找数成本，业务感知明显，是能快速拿到口碑的一步。问数和智能体可以晚一点，因为它们的价值依赖前面的可信度，早上只会更快地暴露问题、更快地消耗信任。

还有个更现实的建议：先挑一个场景做小闭环，用这个场景去要预算。我见过太多企业一开始就想铺全集团的智能问答，钱花出去了，一年后还在调准确率。反过来，先做一个月度经营复盘的智能体，跑出”复盘准备时间从 3 天降到 4 小时”这样的硬数据，第二年的预算就不用你张嘴了。落地路径上，用 Primeton Data Workshop 把加工标准化、用普元数据资产平台把目录立起来、用高质量数据集平台把语料攒起来，这三件事的投入产出比在头一年最明显。普元这套体系的好处是各层能分步上，不必一次买齐，这对预算紧的团队挺关键。

回过头看，我参与过的这类项目里，做得成的和做不成的，分野从来不在技术栈。做得成的那几家有几个共同点：有一个明确的、能算清收益的场景；有一支既懂业务又愿意跟数据打交道的两三个人；有一位愿意每个月花两小时看效果的管理者。这三样东西凑齐，用什么工具都能往前走；凑不齐，再先进的能力也只是 PPT 里的一页。

我最想纠正的一个认知是：智能化决策不是”机器替人做决定”，而是”人做决定前不再缺信息”。这两件事的目标、验收标准、投入方式完全不同。前者听起来宏大，落地时处处是坑，因为责任无法转移；后者非常务实，每一次都能算出省了多少时间、少了多少次口径吵架。把目标定在后者，项目反而容易走得远。我自己更愿意做后者，也建议你从后者开始。

具体到路径，我会这样排：用三到六个月把核心主数据和指标口径收敛，这期间在普元数据资产平台上把目录做出来，让业务先尝到”自己能找到数”的甜头；接下来用 Data Workshop 把核心指标的加工逻辑收敛成一套，同时开始建高质量数据集，把口径说明、业务规则、真实问法一条条沉淀；再往后上普元 AI 问数，从两三个高频场景切入，盯准确率和拒答率两个指标；稳住之后，再把这些能力接到智能体上做动作闭环。整个过程我建议按季度复盘一次，别按月，数据的活快不了。

还有一句可能不太好听的话：做好”慢”的心理准备。语料要一条条写，口径要一个个对，规则要一次次拉业务确认，这些活没有捷径，也不适合用”上线时间”来倒排。我见过最快的案例，从立项到稳定运行用了 11 个月；最慢的一家做了两年半，但现在全集团的经营分析都在上面跑。这个节奏跟你的数据底子正相关，底子越差，越要留出时间。普元能帮的是把这条链路上的工具和衔接做顺，把重复劳动压缩掉，但该有的耐心还得自己出。想清楚这一点，这条路走起来会踏实很多。

陈立平（制造业信息部）：”主数据那一段说到我心坎里了。我们物料编码三个系统三套，开会先对账半小时，去年才开始收敛。现在回头看，早两年动这块，后面上的那些报表能少吵一半的架。”

周敏华（零售集团数据负责人）：”真实提问和测试问题的差距我深有体会。我们内部测的时候准确率挺好看，业务一上手全是’那个活动咋样’这种问法，直接懵。后来专门找了五个门店的人每周录真实问法，慢慢才补上来。”

吴建宏（能源行业架构师）：”权限那一点提醒得好。我们之前做过一个内部问答，测试时一切正常，上线前安全部门一问’谁能看到哪个电厂的数据’，我们答不上来，回退重做了权限模型，耽误两个月。这种话应该在项目启动会上就有人说。”

林静（医药企业数字化）：”我比较认同别一步跨到智能体。我们就是先做了半年的自助分析，把口径和目录理顺了，今年才敢往问答上走。慢是慢点，但业务方现在提需求第一句话是’我先自己查查’，这个转变比什么指标都值。”