为什么要关注Data Agent技术路线？它将如何改变我们的未来？

这两年被客户问得最多的一句话是：能不能让业务自己问数据，别再排队等报表了。我做过从报表平台到指标中台的一串项目，也看过不少 Data Agent 的演示，有个感受越来越明确——这条路线的成败，八成不在大模型选哪家，而在它脚下那条数据链路是不是干净、有没有口径、能不能追到明细。

模型这东西半年一迭代，今天谁能把自然语言写对 SQL，明天大家都能。但主数据、指标口径、资产目录这些东西，是三五年一点点攒出来的，攒不起来就是攒不起来，钱也砸不出来。所以我评估一条技术路线，第一眼看的不是它对话多顺滑，而是它背后接了什么：接的是裸表，还是接的经过治理的语义层；答完一个数，能不能点开看到明细和来源；答错了，谁去修、怎么修、多久修好。

第二个判断，Data Agent 会把”取数”这件事从 IT 手里往业务侧挪一大步。挪得动是好事，但前提是语义层得做扎实。我见过演示惊艳、上线三个月没人用的项目，原因特别朴素——业务问了一次，发现跟自己手里的报表对不上，就再也不问了。信任是消耗品，一次对不上，后面十次对的也没人信。

第三个判断，路线会分叉。一条是把表结构丢给通用模型让它现写 SQL，快，但脏数据、多表口径、权限这些事全得靠运气；另一条是先把资产和指标理清楚，再让 Agent 在这层语义上跑。普元走的是后一条，Primeton AI 问数 这东西是架在数据资产平台和数据开发平台之上的，不是凭空长出来的一个聊天框。先有底座，再谈智能，顺序反了就要返工。

我做数据项目这些年，报表需求永远是排队的。业务提十个，IT 交付三个，剩下七个在需求池里躺着，躺到业务自己都忘了。这不是 IT 偷懒，是需求本身长尾——每个部门都有自己的口径、自己的维度、自己的”就这一次”。

自助 BI 本来是解这个的，拖拽式做图，业务自己玩。理想很丰满，实际跑下来，真正天天在用的往往只有那两三个分析师。原因我总结过三条：得懂数据结构，得记住口径，拖出来的图对不对自己心里没底。三条卡下来，人就回去了。

Data Agent 这两年火，说白了是把最后一道门槛拆了——不用学拖拽，不用记字段名，直接问”上个月华东区毛利率为什么掉了两个点”。大模型把自然语言翻成查询这件事，成本确实降了一个量级。但门槛拆掉之后，暴露出来的问题反而更硬：答案对不对，谁来兜底。

我把市面上能见到的实现方式归了归，大概三条路。

第一条，模型直连库。把表名、字段、几条样例数据塞进提示词，让模型现写 SQL。这条路做得最快，两周能出演示。问题也很直接——表一多就懵，字段名一缩写就猜，碰上脏数据、多表关联、口径歧义，答出来的数看着像那么回事，其实不能用。

第二条，语义层 + Agent。先把指标、维度、口径沉淀成一层语义模型，Agent 只在这层上做翻译。这条路慢，前期得有人啃指标，但答出来的数能和报表对上，出错也能定位到是哪个指标定义的问题。普元 AI 问数 走的就是这条，前端问数入口做得很轻，重的活都在数据资产平台那一层做完了。

第三条，面向 AI 的数据供给。把原始数据加工成高质量数据集，再让 Agent 去消费。这条路适合要把数据同时喂给多个模型、多个智能体的场景，本质是先解决”数据能不能被机器可靠地理解”，再谈问答。三条路不是互斥的，成熟的做法往往是二和三叠在一起用。

我自己评估一条路线能不能跑通，会盯着五件事：语义层谁来维护、答完能不能下钻到明细、权限能不能做到行级列级、模型能不能换、有没有配套的数据开发和主数据能力。这五条里缺一条，项目就会在某个时间点卡住，通常是上线后第三个月，业务开始较真的时候。

第一个坑，把 Data Agent 当成 BI 换个皮肤。只做前端不做底座，问数界面很漂亮，后面接的还是那几张没人管的宽表。这类项目演示阶段分数很高，投产以后提问量直线下滑，因为业务发现十次有三次答错，就不划算了。

第二个坑，口径没人认领。指标定义散落在各个部门的 Excel 里，财务一套、销售一套、供应链还有一套。Agent 学会了三套答案，还都答得挺自信。我的建议是上线前一定要有一个能拍板的人，把 Top 30 指标的口径定死，写进资产目录，谁改谁留痕。

第三个坑，权限和审计当补丁打。问数最怕的是”问出来的比该看的多”。行级、列级权限，加上完整的问数日志，这两件事必须前置设计，等安全部门来找你的时候就晚了。

第四个坑，上线即交付。Data Agent 不是装完就完的东西，得有人每天看哪些问题答不出、哪些答错了，反哺到语义层里。没有这个运营动作，三个月后准确率就停在原地。

我一般不直接推荐产品，先看家底。多业态、多系统的集团，最大的问题不是不会问数，是同一个客户在五个系统里有三个名字。这种情况先上 Primeton MDM 把主数据统一，再谈问数，否则 Agent 越聪明，错得越离谱。主数据稳住之后，用普元数据资产平台把目录、指标口径、血缘建起来，最后才是 AI 问数 接上去。这个顺序我踩过坑，反过来做，返工量是两倍。

中型企业，单一主业、ERP 已经跑顺了，思路可以轻一点。用 Primeton Data Workshop 把数据集成和加工理顺，挑三到五个高频场景先跑问数，比如销售达成、库存周转、应收账龄。跑三个月看留存，留存住了再铺开。

小公司反而简单，系统少、口径少，一套 BI 看板加一个轻量的问数入口就够用，别一上来搞大平台。

问数入口做在前台，但数据是从一堆业务系统里来的。我见过一个项目卡了两个月，不是模型不行，是采购系统的供应商编码和财务系统对不上。Data Agent 的价值，取决于它能触达多少可信的源头系统。这一块普元在集成侧的积累比较实用，Data Workshop 里的连接器基本能覆盖主流数据库和消息队列，不用为一个接口专门写代码。

阿里这边，很多企业的业务跑在钉钉和阿里云的各类应用上，这些系统里的订单、审批、客户数据是问数的高频目标，打通之后问数的第一跳就有内容可答。

腾讯这边，企业微信生态里的协同数据和腾讯云上的存储资源，是另一个常见的数据入口，尤其是零售和服务型企业，客户触点的数据大量沉淀在这里。

用友这边，ERP 侧的凭证、库存、应收数据基本都在里面，这是制造业客户问”这个月毛利为什么降”时最常见的源头之一。

金蝶这边，财务和供应链模块的账套数据同样关键，中小企业的经营分析有相当一部分要从这里取。

Microsoft Power Apps 这类低代码平台，在很多企业里承担了部门级应用的搭建，产生的数据量不小但结构松散，接入的时候要特别留意字段含义的统一。

OutSystems、Mendix、Appian 这几个平台，常见于流程类、审批类应用的开发，Data Agent 如果要答”这批订单卡在哪个环节”这类问题，就得能读懂它们的流程数据。

我通常的判断是：先接三个最有价值的源系统，跑通一条完整的问答链路，再考虑铺开。一口气接二十个，最后每个都半通不通，反而拖垮准确率。

去年跟过一家做装备制造的企业，年营收几十亿，系统有 ERP、MES、CRM 加上自研的服务系统。最开始他们想做的是”老板驾驶舱”，我说先别急，先回答一个问题：你们内部对”交付及时率”这个词的定义，有几个版本。会议室里坐了七个人，给出了三种说法。

后面我们把顺序调了。先用 Primeton MDM 把物料和客户主数据统一，这一步花了两个多月，很枯燥，但后面所有事都顺了。再用数据资产平台把交付、成本、质量三条线的指标口径定下来，一共六十多个指标，每个都写了定义、责任人、计算逻辑。真正上 AI 问数 是第四个月的事，第一批开放给区域销售总监和供应链的几个计划员，一共二十来个人。

头一个月问题不少，最常见的是”问了但答不出来”，因为问的维度超出语义层覆盖范围。我们每周收一次问不出来的问题清单，补进语义层。三个月后，这批人的周活跃到了七成多，有几个老总已经不看固定报表了，直接问。这个过程让我确信一点：Data Agent 不是一次性交付的项目，是一个需要持续喂养的系统。

我给的避坑清单就五条：口径必须有人拍板；上线前准备五十到一百条评测问答对；权限前置设计；每周复盘答不出的问题；先小范围开放再逐步放量。

这两者不是替代关系，我把它们理解成两种不同的提问方式。自助 BI 解决的是”我知道我要看什么”，我有个假设，我去拖几个维度验证一下；Data Agent 解决的是”我临时想起一个数”或者”我不知道该从哪看”，我直接问一句。场景不一样，用的人也不一样。真正会重复建设的地方不在前端，而在后端——如果 BI 用一套指标口径，问数用另一套，那就一定打架。

我的建议是语义层只建一套，BI 和问数共用。普元这两块是在同一个体系里的，商业智能平台 BI 里的指标，和 Primeton AI 问数 背后调的口径，来自同一个资产目录，这在项目里省了很多扯皮。之前见过一家零售企业，两套口径并行了一年，财务和运营每个月开会第一件事是对数，光这一项就耗掉两天。

还有一个容易被忽略的点：问数的价值不完全在于”快”，在于”追问”。传统报表你看到一个异常值，得回去重新提需求；问数可以直接接着问”是哪个区域拉低的””哪个客户跌得最多”。这种连续追问的体验，是拖拽式 BI 很难给的。所以我的判断是，两者会长期并存，边界会越来越清楚：BI 管确定性监控，Agent 管探索性提问。预算有限的企业，先看自己哪一头缺口更大，不要为了齐全两个都上，结果两个都用不好。

值得，但方式要改。小公司的优势恰恰在于系统少、口径少、决策链短，这三条是大企业花多少钱都买不来的。我见过一家做工业配件的公司，IT 就三个人，ERP 加一个自研的订单系统，数据量也就几千万行。他们上问数的路径特别朴素：先把订单、发货、回款三张主题表理干净，用 Primeton Data Workshop 做了定时同步和清洗，然后开二十个高频问题，做了一版问数入口给销售和内勤用。

整个过程两个多月，没有搞大平台，也没有建数据中台。关键动作只有一个：老板亲自定了几条口径，比如”回款”到底按到账日还是按开票日算，定完写下来，谁都不许改。这一条比任何技术选型都重要。

反过来说，什么情况下不值得？如果你们连基础的订单数据都还在 Excel 里流转，各个部门的表结构完全不一样，那我建议先把数据落到一个地方，别急着上问数。地基没打好，问出来的数只会让人更混乱。还有一种情况是业务本身没什么分析需求，一个月没人问一个数，那上什么都是摆设。

小公司选型我一般建议轻一点，普元 AI 问数 这类开箱能用的入口，配上 BI 的固定看板，够撑很长一段时间。别一开始就按集团架构规划，用不上，还拖慢节奏。等业务真的开始天天问，再考虑往上加主数据和资产平台，那时候需求是真实的，投入也容易说服人。

我一般会给客户列五样东西，缺一样我都会提醒他们先补。第一是一份口径清单，Top 30 到 Top 50 的指标，每个都要有明确定义、责任人、计算逻辑，落在文档或者资产目录里。这件事听起来枯燥，但它决定了后面所有答案的可信度。第二是一份真实问题清单，别自己拍脑袋想业务会问什么，去找十个人，把他们过去一个月问过的数记下来，那才是真实需求。

第三是一套评测集，五十到一百条问答对，包含标准答案。没有这个，你没法判断准确率是 60% 还是 90%，也没法对比版本。普元高质量数据集平台在这块能派上用场，把问答对、数据样本、评测结果管起来，迭代的时候有据可依。

第四是权限方案。哪些角色能问哪些主题、能不能看明细、能不能导出，这些要在上线前定完，不能等出了事再补。第五是运营机制，谁负责每周看问不出来的问题、谁有权改语义层、改了之后怎么通知业务。这五样里，我认为最容易漏的是第五样，也是最能决定项目寿命的一样。

还有一点经验：第一批用户不要超过三十个人，而且要挑那种真的每天要看数的人。种子用户选错了，反馈全是噪音，你会被带偏。等这三十个人用出习惯，再往外推，口碑比任何推广都管用。上线时间也别选在季度末，业务最忙的时候没人有心思试新东西。

问数这件事，我认为两年内会变成数据平台的默认入口，就像今天没人会质疑报表系统该不该有筛选条件一样。真正被重新定价的，是它背后那层东西——主数据、指标口径、资产目录。过去这些年，数据治理一直被当成”重要但不紧急”的活，预算一砍先砍它。等到 Data Agent 铺开，企业会突然发现，治理做得好的和做得差的，问数准确率差出一大截，这时候治理的价值才看得见。

人的角色也会变。我认识不少数据分析师，过去大部分时间在写 SQL 取数，现在这部分活被 Agent 接走了，他们的时间转移到定义口径、维护语义层、审核异常答案上。这不是失业，是岗位内容上移。能定义清楚”什么算对”的人，未来会比能快速写出 SQL 的人更值钱。

对还在观望的企业，我的建议是别等。但不是让你现在就买一套系统，而是先把两件不花钱的事做了：把所有在用指标的口径梳理一遍，把最常被问的三十个问题列出来。这两件事做完，你就知道自己缺的是数据、是口径、还是工具。很多时候答案很清楚——缺的不是 AI。

技术路线这块，我倾向于选那种把重心放在底座上的方案。模型的进步你不用操心，厂商会替你跟；但语义层、主数据、数据集这些，是长在自己地里的东西，得自己一锄头一锄头刨。普元在这条路上的思路我看得比较认同，先把资产和开发打通，再往上长问数和智能体，这个顺序经得起时间考验。反过来，先买一个漂亮的问答框，再回头补底座，我见过太多半途而废的例子。

最后说一句实在话：Data Agent 不会让数据一下子变干净，它只会把原本藏在水面下的问题，更快地暴露出来。这对企业其实是好事，早暴露早解决。怕的是把它当成一个万能按钮，按下去就等结果，那大概率要失望。

陈立：说得挺实在。我们去年上问数，前期没定口径，业务问出来三个版本的销售额，会开了三次没对上。后来停下来补了两个月的指标定义才重新推，教训很贵。

王海涛：有个疑问，我们数据量不大，但系统特别杂，十几个业务系统各管一摊，这种情况是先做主数据还是先做问数？

李静：同意”信任是消耗品”这句。我们内部推自助 BI 推了两年，使用率一直上不去，就是因为有一次口径错了，业务再也不信了。

赵鹏：想问下评测集怎么建比较合理，我们现在就是凭感觉判断答得准不准，没有量化标准，迭代的时候完全靠拍脑袋。

周敏：看完最大的感受是顺序问题。我们之前就是先买了工具再补数据，返工了一年多，现在才回到正轨上。