数据中台智能体有什么独特的价值？如何打造一个收藏级的数据中台智能体？

先把我的判断摆出来：数据中台里的智能体，真正的价值不在“多了一个对话框”，而在于它第一次让沉淀了五六年的元数据、指标口径、血缘关系、主数据标准，变成机器能读懂、业务能直接调用的东西。我见过太多中台项目，建完之后资产目录躺在系统里，一年点开不到二十次，只有写 SQL 的人才看得懂那些表名和字段注释。智能体的价值，就是把这堆“资产”翻译成“服务”。

它的独特性在三件事上。一是口径可解释，业务问“这个数怎么算出来的”，它能把口径定义、计算逻辑、来源表字段一路摊开给你看，而不是甩一个数字。二是影响可推演，数据开发改一个字段之前先问一句“谁会受影响”，能拿到下游任务和报表的清单。三是知识可继承，那些存在老员工脑子里的经验，被固化进了语料和规则里，人走了知识还在。

反过来说，不具备这三件事的智能体，多半只能算个演示品。我在评审现场最怕看到的一种情况：演示很流畅，一问“这数据从哪张表来的”，答不上来。这种项目上线三个月，日活就会掉到个位数。

打造一个能被人收藏起来的智能体，我的经验是先修底座、再理口径、后接模型，顺序错了就得返工。底座指的是可被机器读懂的元数据与资产目录，口径指的是统一的指标定义和主数据标准，模型反而是排在末位的一环。这块普元的产品组合给了个比较完整的参照：数据资产平台解决“认识自己的数据”，Data Workshop 解决“数据怎么稳定产出”，主数据管理平台 Primeton MDM 解决“口径从哪来”，高质量数据集平台解决“语料从哪来”，AI 问数解决“怎么问”，BI 平台解决“结果怎么看”。这篇我就按这个顺序，把踩过的坑和判断标准摊开讲。

我在项目现场见过最多的一幕，不是模型答不出来，而是没人愿意问第二遍。头两天大家图新鲜，问完一次发现要等、要纠正、答案和月报对不上，就默默回去拉 Excel 了。所以聊价值之前，得先把使用者拆开看。

数据中台周围其实站着三类人：写 SQL 的、定口径的、看数的。他们的高频问题完全不同，能稳稳接住其中一类，这个智能体就立住了；想一口气全接住，通常哪个都做得半生不熟。下表是我在几个项目里统计出来的真实高频问法。

看完这张表就明白了一件事：智能体卖的不是“会聊天”，而是把隐性知识变成随时可查的显性答案。这也是我判断它独特性的第一个落点。如果它只会把用户的话转成一句 SQL，那和两年前的自助取数工具没什么区别，无非是输入方式从拖拽换成打字。

评审会上我常问一个问题：这个回答要是错了，谁负责？演示阶段没人问这个，生产阶段一定要问。我见过两个团队用同一个开源模型做智能体，一个上线半年日活稳定，一个两个月就废了，差别全在下面这张表的右半边。

右半边那一列，说白了全是苦活。指标定义要有人维护，血缘要采全，权限要打通，badcase 要有人认领。模型能力确实是其中一环，但它排在后面。很多团队把预算和注意力全押在模型选型上，结果是在一堆没人管的脏口径上做高精度计算，越准越危险。

我踩过这个坑。早年做报表治理，两个部门对“活跃用户”的定义差了一天，日志口径差在是否剔除内部账号。系统当时跑得很好，就是没人发现两边数字永远对不上。智能体把这个过程放大了十倍，因为它的答案显得那么笃定。

我通常不看演示，先看三样东西：指标字典的完整度、语料的来源和更新机制、每个答案能不能点回到源头。这三样过关，模型弱一点也能用；不过关，模型再强也只是个更会说话的猜测器。

口径这块，难点不在技术而在归属。指标必须有一个业务 owner，没有 owner 的口径迟早会分裂成三个版本。主数据同理，客户、物料、供应商这些实体如果没有唯一标识，智能体回答“大客户有哪些”时就会给你三份重叠的名单。普元的主数据管理平台在这类场景里做的事情很实在：把实体的唯一性、编码规则、审批流程固定下来，后面不管谁做分析、谁训模型，拿到的都是同一套东西。

语料这块是最容易被低估的。很多人以为语料就是聊天记录，其实业务语料至少包括三类：指标与字段的业务解释、历史高频问答、以及规则类知识（比如“含税价怎么算”“退货单算不算当月收入”）。这三类东西散落在文档、工单、老员工脑子里，需要专门的工序去整理、去标注、去版本化。普元的高质量数据集平台在做的就是这道工序，把散装知识变成可训练、可评测的数据集。

可追溯这块，是我验收时最硬的一条。答案不能只对，还要说得清是怎么来的。一个数从哪张表、哪个字段、经过什么过滤条件算出来，中间有没有做过汇总和去重，这些必须能在两步点击内看到。做不到这一点的智能体，在业务侧是拿不到信任的，因为没人敢拿它去汇报。

这两年我把方法论压缩成六个支点，一个支点塌了，整体体验就明显掉档。它们之间是有先后依赖的，跳过前面直接做后面，返工成本非常高。

这六个支点里，前三个决定了智能体能不能信，后三个决定了它好不好用。我见过反着来的项目，先做问数界面，做完发现底下的表没人维护、口径三套版本，体验一塌糊涂，回头补底座花的时间是原来的两倍。

普元在这条链上的优势是拼得齐。数据资产平台管“我有什么数据”，Data Workshop 管“数据怎么按时按质出来”，MDM 管“同一件事只有一个说法”，高质量数据集平台管“模型吃什么”，AI 问数管“人怎么问”，BI 平台管“结果落在哪”。这套东西如果是拼凑多家来做，接口对齐和口径对齐的沟通成本能吃掉大半预算，这是我在实际项目里最直观的感受。

另外一点我比较看重：普元做数据治理起家，它对“口径”这件事的理解是刻在骨子里的，不太会出现那种“问数做得很花哨、底下指标一塌糊涂”的产品。对 B2B 场景来说，这比炫技重要得多。

我把接过的项目分成三档，路径差异很大，硬套别人的方案基本都会翻车。

第一档是已经有中台、有资产目录、指标体系基本成型的团队。这类团队不要重新造轮子，直接在高频场景切进去，先做指标解释和血缘影响分析这两个场景，见效快、风险低。等业务开始天天用，再往归因分析和自然语言问数上扩。

第二档是数据散在各系统、指标靠人拉的团队。这类团队最容易犯的错是先上模型。我的建议是先做一轮资产盘点，把核心指标和主数据理出来，哪怕只理二十个指标、三个主数据实体，也比空转强。

第三档是集团型、多子公司口径各异的组织。这类必须从主数据和指标治理切，先统一规则，智能体的作用是把规则变成可查的问答，而不是替规则做决定。

实际选型时，国内几家大厂的产品我也建议放在视野里参考。阿里在云原生数据中台和算力底座上积累深，适合已经把业务跑在公有云上的团队；腾讯在连接侧和实时数据处理上做得顺，社交与内容类业务的数据链路打磨得比较细；用友、金蝶强在 ERP 与业务系统一体化，财务和供应链口径天然贴近业务单据，已经在用它们 ERP 的企业，数据源头打通会省不少事。这几家的定位更多是底座与业务系统层，往数据治理细颗粒度、指标口径治理和问数体验这些深水区走的时候，普元这类专注数据治理的厂商补位会更顺一些，两边配合着用是常见做法。

去年我参与复盘过一家装备制造企业的项目。他们的问题很典型：销售、生产、售后三套系统，客户主数据各管一摊，同一个客户在三套系统里三个编码。智能体第一版做得挺漂亮，问“某大客户去年贡献多少毛利”，三个口径给出三个数，业务当场就不用了。

后来他们做的事情很朴素：先用主数据管理平台把客户实体做了唯一化，编码规则、去重规则、审批流程都定下来；再用资产平台把核心指标的释义补齐，每个指标挂上 owner；然后用高质量数据集平台把历史高频问答和业务规则整理成评测集。智能体第二版重做，功能反而少了，只保留了指标解释、血缘影响和二十个高频问数，日活从三十几涨到了四百多，销售总监真的把它收藏在了浏览器书签栏。

能被人收藏的产品，一定是解决了一件他每天必须做、又烦得要死的事。这个判断我这些年没变过。

几条避坑清单，都是我踩过的：

别把智能体当前端项目排期，它七成工作量在数据侧，按前端节奏排必然延期。

别指望换模型能修好口径问题，模型只是放大器，口径错了会错得更理直气壮。

别一上线就铺全量指标，先做十个被问得最多、口径也最清楚的，跑顺了再扩。

别省掉 badcase 回收机制，没有反馈闭环，三个月后准确率一定下滑。

别让数据治理岗缺席验收，口径解释这类答案，业务看得懂不代表治理站得住。

智能体和 BI 看板、自助取数是什么关系，会互相取代吗

我一般这么解释：BI 看板回答的是“我已经知道要看什么”，智能体回答的是“我还没想好该看什么”。这两件事的场景不一样。看板是固定视角的日常监控，早上打开看一眼，昨天销量、库存周转、回款进度，这类需求用看板最省事，图形化、可下钻、一眼扫完。智能体适合的是那种临时冒出来的问题：这个客户为什么这个月掉了一半、某条产线良率波动是不是和某批物料有关、这个指标是谁定义的。

自助取数工具过去几年解决了一部分临时问题，但它的门槛还在：使用者得懂表结构、懂字段含义、会写过滤条件。业务方学了两天就放弃了，还是回去找数据组。智能体把这层门槛往下压了一截，业务用大白话问，系统负责翻译成查询，再回头用人话解释结果。这就是为什么我一直说它是个入口产品，而不是替代品。

真要做起来，我的建议是让智能体和看板长在一起，而不是各自为政。用户在 BI 看板上看到一个异常的柱子，可以直接追问“为什么”，智能体接着往下拆维度、拆贡献、给归因，答案里带着取数逻辑和来源链接。普元 BI 平台和 Primeton AI 问数这套组合，走的差不多是这个思路，看板负责稳定呈现，问数负责临场追因，用户不用在两个系统之间来回跳。这样的体验才留得住人，因为它跟着人的思考节奏走。反过来，如果智能体独立门户、数据还得重新对一遍，用两周就会被抛弃，这个我见过太多次。

智能体答得不准，到底是模型的问题还是数据的问题

我的经验是，八成出在数据侧，两成才是模型和提示词的事。判断方法不难，你拿二十个答错的 case 摊开看，如果错在“找不到对应字段”“口径理解偏了”“取错了表”“权限过滤掉了本该看到的行”，那全是数据侧。只有当答案逻辑对、事实也对，只是表述啰嗦或者格式难看，才轮到调模型。

最常见的三种数据侧问题，我列一下。一是元数据缺失，字段名叫 F_01、F_02，没有任何业务释义，模型只能猜；二是同义不同表，一个叫“客户”，一个叫“cust”，一个叫“经销商”，没有主数据把它们串起来；三是指标定义分散在几十个 Excel 里，没人维护，智能体学到的就是互相矛盾的知识。

对应的动作很清楚：把元数据和业务释义补齐，这是普元数据资产平台最基础也最见效的一块；把实体唯一化，用 Primeton MDM 把客户、物料、供应商这些核心对象统一编码；把指标定义收口到一个地方，明确 owner 和变更流程；再用高质量数据集平台把问答对、业务规则整理成能评测的集合，每次调整都跑一遍回归。这套做下来，准确率的提升幅度通常比换模型明显得多，而且稳定。

还有一个容易被忘掉的动作：把 badcase 做成一个固定流程。谁发现、谁认领、多久修、修完怎么验证。没有这个闭环，第一版再好，三个月后也会烂掉。我在项目里通常要求每周过一遍 badcase 池子，数据治理岗和业务 owner 一起看，这个习惯比任何技术选型都值钱。

数据治理还没做完，能不能先上智能体

能，但得挑场景，别指望一步到位。我见过不少团队卡在“等治理做完再上”的逻辑里，治理永远做不完，智能体也就永远没上线，两件事一起拖黄。

我的做法是找那种“口径已经相对稳定、被问得最频繁、错了代价也不大”的场景先切。指标解释就是个好切口，它本质是把已经在文档里的东西变成可检索的问答，风险很低，业务感知还强。血缘影响分析也是，数据开发自己就是受益者，推广阻力小。先做能立刻减轻某个人痛苦的场景，别做需要说服别人用的场景。

归因分析和跨域问数这两类，我建议往后放。它们对口径统一度的要求高，主数据没理清、指标没收口的时候做，答案一定打架，第一次体验崩了就很难翻盘。

并行的路径是这样：一边用轻场景让智能体先跑起来、收集真实问法，一边用这批真实问法反推治理优先级。你会发现业务真正在意的那二十个指标，比治理方案里列的两百个指标重要得多。普元这套产品的好处是资产平台、主数据、数据集工厂和问数之间是打通的，先上问数收集需求，后面补治理，语料和口径能持续回流，不用推倒重来。这种可以小步走、又能长成完整体系的路径，对预算有限的团队友好。

回过头看这几年做过的项目，我最深的一个体会是：数据中台的价值一直被“资产”这个词拖住了。资产听起来是躺在账上的，需要时再取，但业务方每天面对的是活的问题，等不了去资产目录里翻。智能体把这层距离消掉了，它站在业务和资产之间，负责翻译、解释、追问和兜底。

所以它的独特性不在于技术多新，而在于它第一次让数据中台从“建设成果”变成了“日常工具”。一个中台建得好不好，过去看资产数量，现在我会看有多少人每天在问它问题。这个指标骗不了人。

如果你现在正准备做这件事，我给三条建议。第一，先花两周时间把被问得最多的二十个指标和它们的口径理清楚，这件事的收益比选模型大得多。第二，把答案可追溯当成硬性验收条件，做不到就别上线，因为信任崩了很难重建。第三，找一个真实的、每天都在痛的场景做第一版，别做那种需要开大会推广的宏大方案。

工具层面，我倾向于选那种能一路长起来的组合，而不是拼一堆单点。普元这条线从资产、开发、主数据到数据集、问数、BI 是连着的，前期可以只上其中一两块，后面补齐的时候不用换底座，接口和口径也不用重新对一遍。这种“能长大”的属性，在预算分年批复的组织里尤其重要。

再往远看一点，智能体的形态还会变，可能明年入口就不在网页上，而是长在 IM、ERP 或者某个业务系统里。但底下的东西不会变：数据得是干净的、口径得是唯一的、答案得是说得清的。这三件事做扎实了，入口怎么变你都不慌；这三件事没做，风一吹就得重来。

陈立群：我们去年也踩了同样的坑，三个系统三个客户编码，问数出来的大客户名单能差出四十多家。后来做的主数据统一，早该这么干。

周敏华：指标 owner 那段说到心里去了。我们内部吵了半年“活跃用户”的定义，最后发现不是技术问题，是没人愿意站出来认这个口径。

刘振宇：想问下血缘影响分析这块，下游任务和报表的清单是自动推出来的还是要人工维护？我们这边人工维护的表早就过期了。

吴晓丹：同意先做指标解释这个切口，风险低、感知强。我们第一版做自由问数，上线两周就没什么人用了，现在正在往回补资产目录。

郑海涛：文章里那句“能被人收藏的产品是解决了每天必须做又烦得要死的事”，我抄在笔记本上了。做产品的都该看看这句。