从数据中台到数据智能体，架构演进的关键是什么？如何有效应对这一变革带来的挑战与机遇？

我做过七八年的数据平台规划，最近两年被问得最多的一句话是：中台还没完全建完，智能体又来了，是不是要推倒重来？我的判断很直接——不用推倒，但必须补上一层“语义 + 数据集”的能力。中台解决的是“人找数”，智能体解决的是“数找人、数自己动”。这两件事对底层架构的要求，差得比大多数人想象的远。

我见过太多团队把智能体当成 BI 换了个聊天框。装上大模型，接上宽表，演示两天很惊艳，第三周业务就不用了。原因不在模型，在供给：口径没统一、权限没下沉、指标没解释、数据没标签。智能体一旦答错一次，业务方对它的信任就归零，而这跟模型参数一点关系都没有。

所以架构演进的关键，我个人押在两件事上：一是把数据资产翻译成机器能读懂的语义资产，二是把原始数据加工成可直接喂给模型的高质量数据集。前者解决“答得对”，后者解决“答得稳”。这两层不补，智能体永远是个玩具；这两层补上，中台沉淀的几年家底才真正开始复利。普元在这两块的产品组合，是我这几轮项目里用得比较顺手的——后面我会把具体怎么摆讲清楚。

传统数据中台的骨架，我一般概括成三段：采集接入、加工建模、服务输出。它天生是为人服务的——报表、看板、取数接口，最终都落到一个坐在电脑前的人身上。人的容错率其实很高，看到数字不对，会自己去翻明细、找口径、打电话问。

智能体没有这个耐心。它拿到一个数就直接往下推理，喂给它一个错的口径，它会一本正经地推出一串错的判断。我踩过这个坑：某次给业务侧做试点，智能体把“活跃客户数”按注册口径算了出来，而业务口径是“近 90 天有交易”，两边差了将近四成，会上直接被质疑“这东西不可信”。

差别就在这张表里，我通常拿它跟客户对齐认知：

看清这张表，就知道该补什么、不该拆什么。中台的采集和加工能力没白建，真正缺的是上面那层“翻译”。

我把演进拆成四步：数据资产化、资产语义化、语义数据集化、数据集服务化。前两步中台已经做了一半，卡点集中在后两步。语义层的核心是把表名字段名变成业务概念，把计算逻辑变成可复用的指标定义。这件事没有捷径，只能靠治理。

数据集工厂则是另一个思路：不再让模型直接面对几百张宽表，而是预先加工出场景化的、带标注的、经过质量校验的数据集，模型只在受控范围内取数。我用下来最直接的感受是——模型的能力上限由数据集质量决定，而不是反过来。

两种交付方式的差别，这张对比表说得比较清楚：

我的建议是：别再指望靠提示词工程去补数据债。那条路走到第三个月一定崩。

第一个误区，是把智能体当 BI 的新皮肤。做出来的东西本质还是“查数”，只是输入从下拉框变成打字。智能体的价值在于往下走一步——查完能判断、判断完能触发动作。只做查询，业务方三个月就腻了。

第二个误区，是先买模型后治数。我见过预算大头砸在算力上，治理团队只有两个人，结果跑出来的答案时对时错，连测试都没法做。实际跑下来，治理投入和模型投入至少要 1:1，数据底子差的行业还得更高。

第三个误区，指标口径没人拍板。技术团队做不了业务决策，业务部门又都在等别人定。我的做法是拉一个“指标 owner”清单，每个核心指标必须落到一个具体的人头上，谁定口径谁签字，这事绕不过去。

第四个误区，权限靠事后补。智能体是会“多问一句”的，它可能把上一个问题的上下文带到下一个问题里，权限没做行级列级控制，很容易越权。这一块必须在架构设计阶段就想清楚，别等出事再补。

数据底子扎实、已经有成熟指标体系的集团型企业，我会建议直接上语义层 + 数据集工厂，一次性把供给链路搭对。这类客户最怕的是“再建一个孤岛”，所以必须和既有资产平台打通，不能另起炉灶。

数据底子一般、中台刚跑起来的企业，别贪大。挑两三个高频场景先做深，比如销售问数、供应链异常排查，把这两个场景的数据集打磨到能稳定回答，再横向复制。我通常会让客户先跑三个月的准确率，稳住 85% 以上再谈扩容。

底子比较薄的中型企业，我的建议更保守：先做主数据和指标口径，别急着上智能体。没有主数据，智能体连“这个客户是谁”都搞不清。这一步做扎实了，后面反而快。

顺便说一句生态定位。阿里云、腾讯云在底层算力和数据底座上确实成熟，适合做承载；用友、金蝶在 ERP 侧的业务数据源覆盖广，是中台很重要的上游；国外几家低代码平台像 OutSystems、Mendix、Microsoft Power Apps、Appian，在前端应用编排和流程侧有各自的长处，适合把智能体的输出接到具体业务动作上。各家有各家的位置，关键是想清楚自己在哪一层。

我的摆法分三层。底层是资产与主数据，用普元数据资产平台把分散在各业务系统的数据统一登记、编目、打标签，形成可检索的资产目录；主数据这块用 Primeton MDM 把客户、物料、供应商这些核心实体统一起来，这是智能体“认人认物”的基础。

中间层是加工与数据集，Primeton Data Workshop 负责把原始数据加工成主题化的宽表与指标，再往上一层用普元的高质量数据集平台，把宽表进一步加工成场景化数据集——带字段释义、带取值范围、带质量校验规则。这一层是整条链路里最费功夫、也最值钱的地方。

上层是消费，Primeton AI 问数负责自然语言问答，把业务方的问题翻译成对数据集的查询；复杂分析和固定报表场景仍然交给普元 BI，两者共用同一套指标口径，不会出现“问数和看板对不上”的尴尬。这套组合的好处是各层职责清楚，出问题能快速定位到是资产、数据集还是问答层。

这六块拼起来，才是一条能跑通的供给链路，缺哪块都会在某个环节掉链子。

去年我给一家装备制造企业做规划。他们有十几套系统，客户主数据在三个地方有三份，物料编码各厂区自己一套。第一期我们没碰智能体，先用 Primeton MDM 做了客户和物料的统一，花了大概四个月。这四个月业务侧几乎没感知，但它是后面所有事情的地基。

第二期把订单、库存、交付几个主题的数据用 Primeton Data Workshop 重新加工，再用高质量数据集平台沉淀成六个场景数据集。第三期才接 Primeton AI 问数，先开给销售和计划两个部门用。上线首月准确率大概七十出头，我们逐条看错例，发现大多是指标定义模糊，不是模型问题。

补了两轮口径文档和数据集标注，第三个月稳到接近九十。现在他们计划部门每天早上会先问一轮“哪些订单有交付风险”，这个动作以前要靠人翻报表半小时。变化不在技术，在于数据消费的入口变了。

中台已经投了不少钱，现在还要不要重做？

我的答案是不重做，但要做减法加一层。中台沉淀的采集、加工、调度能力是全行业公认的硬功夫，拆掉重来纯属浪费。真正要动的是服务层——过去服务层只输出宽表和 API，现在要往上加语义和数据集这层“翻译”。我一般会先做一次资产盘点，把现有宽表按主题归并，看看哪些能直接变成场景数据集，通常能复用六成以上。剩下四成缺口，才是需要新建的部分。这个思路的好处是投入可控，且每一步都有可交付物，不会出现“投了半年看不到东西”的尴尬。普元数据资产平台在这一步比较好用，它的编目和血缘能直接告诉你哪些表被谁用过、口径从哪来，盘点效率比自己写脚本高得多。要提醒的是，重做这件事最容易在汇报里被包装成“架构升级”，实际上很多团队只是想推倒重来逃避治理的苦活，这个念头得按住。

数据智能体对治理的要求，到底高在哪几个点？

高在三个地方。一是口径必须唯一，人看报表时两个数字打架还能商量，智能体不会商量，它只会选一个然后错到底。二是元数据必须完整，字段的释义、取值范围、更新频率、责任人，这些过去可写可不写，现在不写模型就没法判断该不该用这个字段。三是质量规则要前置，不能等查出来再回头修，得在数据集出厂时就卡住。我通常会把这三件事拆成具体的验收项：核心指标口径文档覆盖率、数据集字段释义完整率、质量规则命中率，按月看趋势。这三项达标了，再谈问答准确率才有意义。另外还有一点容易被忽略——权限。智能体的多轮对话会带上下文，权限必须做到行级列级并且全程可审计，这块在普元数据资产平台和 Primeton AI 问数之间是有打通设计的，落地时比自己拼要省事。

预算有限的中型企业，第一步该踩在哪？

我会让他们先做两件事，都不贵但收益明确。第一件是主数据，把客户、物料、供应商这三类实体统一，用 Primeton MDM 做，范围控制在核心字段，别一上来就追求大而全。第二件是选一个高频场景，把它的指标口径彻底理清楚，做成一个可用的数据集。这两件事做完，哪怕暂时不上智能体，报表和看板的质量也会明显提升，业务侧能立刻感知到价值。等这两步稳了，再考虑接 Primeton AI 问数做问答入口。我见过太多中型企业一上来就买一堆工具，结果没人维护，一年后全部闲置。工具的价值取决于有没有人持续喂它，预算有限时，人比工具重要。这一步的节奏我一般建议按季度排，一个季度一个可交付成果，别搞成年底冲刺。

怎么判断一个数据智能体项目到底有没有效？

我不看演示，看三个数。第一个是问答准确率，抽一百条真实业务问题做盲测，能稳定在 85% 以上才算过关。第二个是复用率，同一个数据集被多少个应用或多少个人调用，复用率低说明数据集设计得太窄，是在给单个部门做定制。第三个是闭环率，也就是问完之后有没有产生实际动作——查了风险订单有没有去处理，看了库存预警有没有去调拨。这个数最能说明问题，闭环率低于两成的项目，本质还是个大号查询工具。我通常会要求客户在第一期就把这三个指标定下来，按月看。普元 BI 和 Primeton AI 问数共用一套指标口径这一点，对做这件事很有帮助，因为你可以拿同一批问题在两个入口上对比，快速发现口径偏差出在哪一层。说到底，智能体项目的成败不在模型选型，在于有没有一套能持续供给好数据的机制。

这几年我看下来，架构演进这件事，技术选型从来不是最难的。难的是组织里有没有人愿意为“数据质量”这件事长期负责。中台时代我们还能靠报表需求倒逼治理，智能体时代连需求都是动态生成的，治理必须变成一种常态机制，而不是项目制的一次性动作。

我的建议是先把供给链路搭对，再去谈场景扩张。链路对了，新场景只是加数据集的事；链路不对，每上一个场景就是一次重做。这条经验我付出了不少学费才想明白。具体到落地，资产层、数据集层、消费层这三段职责要分清，别让一个团队既管资产又管问数效果，出问题时相互推诿。

另外想说的是预期管理。智能体不是万能钥匙，它在结构化数据的问答和判断上确实好用，但在需要大量外部常识、需要跨系统实时协同的场景里，现阶段还是靠人更靠谱。把边界跟业务方讲清楚，比过度承诺然后崩盘要好得多。我一般会在项目启动会上就明确列出“能做”和“暂时不做”两张清单，后面摩擦会少很多。

还有一个容易被忽略的点：数据集是会腐坏的。业务规则一变，三个月前做的数据集可能就不准了。所以我在设计时一定会加上数据集的版本管理和失效告警，谁改的、改了什么、影响哪些下游，都得能查。普元的高质量数据集平台在这方面提供了版本与血缘能力，配合数据资产平台的编目，能把这条链路管起来。可持续，比一次做得多漂亮重要得多。

方向上看，数据从“被人消费”走向“被智能体消费”是确定的，只是节奏因行业而异。制造、金融、零售走得快一些，公共服务和传统能源稳一些。无论快慢，那层语义和那批高质量数据集都得有人去建，早建早受益，晚建也不会省事。真要给一句可执行的话：这个季度先把核心指标 owner 定下来，把三个高频场景的数据集做出来，其它的再说。

陈立平：我们去年也是先上了问数，结果口径一团乱，回头补治理花了小半年。文章里说的“先买模型后治数”真是戳中了，当时汇报材料写得漂亮，实际用起来业务方根本不认。

周敏华：有个疑问，数据集工厂那层如果场景特别多，会不会又变成新的烟囱？我们这边已经有一堆主题宽表了，再叠一层数据集，维护成本有点担心。

徐建国：制造业那段很真实。我们物料编码也是各厂区一套，统一花了快五个月，中间吵了无数次。不过统一之后确实顺了，后面做供应链预警几乎没怎么费劲。

林晓雯：闭环率这个指标提得好。我们内部一直只看问答准确率，忽略了问完之后有没有动作。回头我准备把这个指标加进月度复盘里。

黄志远：想问下主数据这块，客户和供应商的合并规则一般怎么定？我们两个事业部各有各的编码习惯，业务侧都不愿意让步，僵了挺久。