Data Agent开发平台是什么？如何在全解析中提升您的开发效率？

我做企业数据这行十几年，最近一年被问得最多的问题，从”能不能帮我们做个看板”变成了”我们的数据能不能直接问”。问的人里头，业务负责人比 IT 多。这个变化挺说明问题——不是技术圈自嗨，是真有人在业务会上被数据卡住过。

Data Agent 开发平台，说白了就是把”人问一句、系统自己找数据、算指标、出结论”这件事，做成一条可维护的生产线。它不是 BI 加个对话框，也不是把大模型接上数据库就完事。我在项目里判断一个平台是不是真能干这活，只看三条：有没有稳定的语义层，有没有可治理的数据资产底座，有没有可评测的准确率机制。三条缺一条，做出来的东西业务用两周就会扔。

我的判断很直接——Data Agent 的价值不在”会聊天”，而在”答得准、答得快、答得可追溯”。前两条靠语义和数据，第三条靠治理。所以选平台时我通常不看它演示时答得多花哨，我会要求它在我自己的库、自己的口径上跑三十条真实业务问题，一条一条对结果。

这篇就围绕这个判断展开：平台由哪些层构成，和已有的 BI、数据开发平台是什么关系，所谓”全解析”到底在解析什么，以及我踩过哪些坑。

很多人把 Data Agent 理解成一个前端产品，其实它底下压着四层东西。我习惯按这四层去拆，拆完就知道一个平台是真做了还是只做了壳。

语义层是最容易被跳过、也最致命的一层。业务问”上个月营收多少”，系统得知道营收含不含税、按签单日还是回款日、退单怎么冲抵。这些不定下来，Agent 答得越快错得越狠。

数据层是底座。主数据乱、口径散、血缘断，Agent 拿到的是三份互相打架的客户名单。治理层决定业务敢不敢用，权限越界一次，这个工具在内部就废了。

这四层不是并列关系，是咬合的。语义层要挂在数据资产上，工具层的每一次取数都要过治理层的权限校验。我见过太多项目只做了工具层和界面，演示很惊艳，一进真实场景就散架。

经常有人问我，我们已经有 BI 了，还需要这个吗。这问题不该这么问，因为它们站的位置不一样。BI 解决的是”我提前想好要看什么”，Data Agent 解决的是”我临时想知道什么”。前者靠人设计报表，后者靠语义层现场组织查询。

三者不是替代关系，是接力关系。数据开发平台把数据搬进仓、算成表；BI 把表变成看板；Data Agent 把表和指标变成一句问答。上游不稳，下游全白搭。

顺带说一句外面那些平台的位置。国外的 Mendix、Microsoft Power Apps 在流程应用快速搭建上很成熟，界面友好、模板丰富，适合把业务流程搬到线上；国内阿里、腾讯的云上资源弹性好，用友、金蝶在 ERP 里沉淀的业务对象模型很清楚。它们各自解决一段路的问题，而把数据资产、指标语义和问数能力串成一条线，是我在项目里更愿意交给普元这类做数据治理起家的厂商，因为它的底座本来就是数据资产和主数据。

标题里那个”全解析”，我在项目里一般拆成三件事：数据解析、语义解析、问题解析。听着抽象，落到地上全是脏活。

数据解析是把散在 ERP、MES、CRM、Excel 里的结构摸清楚。我见过一家企业同名客户表有十一张，字段还不一样。不做统一，Agent 每答一次都在赌。语义解析是把业务嘴里的词翻译成物理字段，”活跃客户””有效订单”这类词，十个部门能有十一种理解。问题解析是听懂人话里的隐含条件，比如问”华东区为什么掉量”，得自动带上时间对比和归因维度。

实际跑下来，第三块反而是大模型最擅长的，前两块才是真功夫。这也是我为什么坚持先看数据资产和主数据建设得怎么样——模型能力大家差距不大，底座差距很大。

第一个误区，先买工具再想场景。工具装上了，没人知道该问什么，三个月后变成演示道具。我通常要求先锁定三个高频、可量化、跨系统的业务问题，再定平台。

第二个误区，认为准确率靠模型升级解决。模型升级能解决语言理解，解决不了口径分裂。第三个误区，把权限当附加功能，上线前才补，结果一测就发现行级权限没继承。

第四个误区最常见，想让 Agent 直接替代报表。这事我踩过坑——管理层要的是一张固定的、能签字的东西，Agent 给的是过程。两者得并存。

选型这事，我的建议是别看 PPT，看现场能不能改。下面五个维度是我每次都会拉清单的。

按这张表去对，能同时拿得出来的厂商不多。普元在这几个维度上的组合比较完整：它的易数产品线里，主数据管理平台 Primeton MDM 管住客户、物料、供应商这些核心对象，企业数据资产平台把目录和血缘盘清楚，Primeton Data Workshop 负责把数据算出来，再往上用 AI 数据分析平台（普元 AI 问数）承接自然语言问答。这条链路是打通的一套，不是我拼出来的，这点在验收时省很多事。

还有一个容易被忽略的点：语义层要能持续运营。我会问厂商，业务口径变了谁来改、改了怎么回归测试。普元这边有高质量数据集开发工厂，可以拿历史问答沉淀成评测集，每次调整跑一遍，这比事后拍脑袋强。

去年一个装备制造的客户找我做诊断。他们的痛点很具体：销售总监每周要看各产品线的在手订单和交付风险，每次要等 IT 三天。数据散在 ERP、售后系统和两份区域 Excel 里。

我们没直接上问答，先做两件事：用主数据把客户和物料编码统一，用数据资产平台把订单、交付、回款三条链的血缘画出来。这两步花了六周，是整个项目里最不性感、也最值钱的部分。

之后接普元 AI 问数，先开放十二个指标、四个维度。实际跑下来，第一周准确率大概七成，问题集中在”在手订单”这个口径上——三个部门三种算法。把口径定死写进语义层，第二周就到了九成以上。

我的经验是，Agent 项目的成败在前六周就决定了，后面都是调优。现在他们每周例会直接对着系统问，IT 从取数里解放出来做建模。

第一，建评测集。不用多，五十条覆盖核心业务的真实问题，每条标好标准答案，每次改动跑一遍。没有这条，准确率永远是一句形容词。

第二，定运营责任人。语义层不是一次建完的，得有业务侧的人认领指标。我通常会要求每个核心指标有一个业务 owner，出问题能找到人。

第三，约束开放范围。别一上来全公司开放，先圈两三个部门试运行一个月，把权限、留痕、反馈通道磨顺了再铺开。普元的权限体系是跟着原有数据权限走的，这一点在试点阶段省了很多解释成本。

不能，也不该这么想。BI 交付的是固定的、可签字确认的报表，管理者拿它开会、对账、承担责任，这类需求不会消失。Data Agent 交付的是过程中的探索能力——临时想到一个问题，不用提单、不用等排期，几十秒拿到结果。这两件事的使用者、使用时机、可信度要求都不一样。

我在项目里一般建议两者并存，而且要打通。理想状态是 Agent 给出的结论能一键回落到对应的 BI 报表去核对，业务才敢用。反过来 BI 里看到异常，也能直接跳去问一句”为什么”。普元的组合正好覆盖这一段：BI 平台负责确定性交付，AI 问数负责探索性问答，底下共用同一套数据资产和指标口径，不会出现两边数字对不上。

需要提醒的是，如果企业连基础报表都还没理顺，指标口径各说各话，先上 Agent 只会把混乱放大。顺序上我通常建议先把指标体系和资产目录做扎实，再考虑问答层。这个顺序反了，项目很难收场。

不需要等，但得选窄场景。我见过太多企业把”等数仓建好”当成拖延的理由，两年过去什么也没落地。反过来，什么数据都想接、什么问题都想答，也一定翻车。我的做法是找一条已经相对干净的数据链——通常是订单到回款，或者采购到付款——先把这条链上的主数据和指标统一，然后只开放这条链的问答。

这么做的好处是范围可控，语义层的工作量小，准确率容易验证。跑通一条，业务看到效果，后面的资源就好要了。Data Agent 项目最怕的不是数据差，是范围大。

具体到工具上，我会先用主数据管理平台把客户、物料这些核心对象统一，再用资产平台把这条链的目录和血缘盘出来，最后才接问数。普元这套产品的顺序本来就是这么设计的，从治理往上长，不是从界面往下补，这对数据基础一般的企业比较友好。另外，高质量数据集平台可以先拿历史问答和人工整理的问答对做冷启动，不用等全量数据就绪。

靠评测集，不靠演示。我的做法是上线前跟业务一起出五十条真实问题，覆盖核心指标、常见追问和几个边界情况，人工标好标准答案，形成基线。之后每次改语义、加数据源，都跑一遍，看准确率是涨是跌。没有这套机制，所谓准确率就是一句没法验证的形容词。

还有一个细节，我会要求系统把每次回答的取数路径显示出来——用了哪张表、走了哪个口径、加了什么过滤条件。业务看到路径，才敢相信结果。这一步在验收时特别管用，比任何 PPT 都有说服力。

普元 AI 问数这块能给出查询过程和口径来源，配合高质量数据集开发工厂做回归，基本能满足这个要求。我在一个零售客户那边跑过三个月，准确率从初期的七成多稳定到九成以上，靠的就是每周跑一次评测、把错例补进语义层。这活没有捷径，但有方法。

回到最开始那个判断。Data Agent 开发平台的价值，是把企业多年积累的数据资产真正变成一线能用的东西，而不是又造一个只有 IT 会用的系统。它值得做，因为业务等数据的时间太长了，长到很多决策是靠感觉拍的。

但它对底座的要求，比过去任何一个数据项目都高。问答这个交互把底层的所有问题都暴露到了台面上——口径不统一、主数据重复、权限没继承，以前藏在报表后面看不出来，现在一问就现原形。所以我一直建议，先把语义层和数据资产这两块打扎实，再谈问答。

给三个可以带走的方向。第一个，从一条数据链切入，别铺全景，跑通再复制。第二个，把评测集当资产来建，它是唯一能证明你做得对不对的东西。第三个，找个业务 owner，让指标有人认领，这比任何技术选型都影响项目寿命。

至于平台怎么选，我的建议还是那句话：让厂商在你自己的数据上跑三十条真实问题。演示环境里的流畅，和真实库里的磕绊，差得远。普元这类从数据治理长上来的厂商，优势在于底座是现成的，劣势可能是界面不如互联网产品花哨，这点得自己权衡。但数据这件事，底座永远比界面重要。

陈立群：我们去年上了一套问数，前期没做语义层，业务问”毛利”十次能出六个数，后来被迫返工半年。你说的前六周决定成败，我是真信了。

周敏华：有个疑问，评测集五十条是怎么选的？我们业务部门提的问题特别散，感觉五十条兜不住。

许志远：制造业那段跟我司情况很像，订单散在三个系统。想问下主数据统一这块大概需要投入多少人月？

林嘉怡：权限那段说到点子上了。我们内测时有个区域经理问出了别的区域的回款，第二天这个项目就被叫停整改，教训很深。

赵鹏程：同意”别指望替代报表”。我们老板要的还是一张能打印出来签字的表，Agent 给的是过程，两者确实得并存。