Data Agent集成：如何通过成功企业案例参考提升你的业务效率与竞争力？

我把这件事压缩成一句判断：Data Agent 集成成败的分水岭在数据层，不在模型层。过去两年我参与过十来个把对话式分析接进业务系统的项目，凡是上线三个月后还被业务同事主动打开的，底层几乎都把主数据、指标口径、权限边界提前收拾干净了；反过来，演示时惊艳、上线后没人用的，问题十有八九出在数据这一头。我见过一个快消客户，把问数接进了经销商系统，界面做得漂亮，可业务问“这个客户今年累计退了多少”，Agent 给出的数和财务系统差了两成——因为它读的是业务库原始表，没走加工后的口径层。这种事一旦发生两次，用户就不会再信任任何一次回答。我的建议是先治理再集成、先场景再平台，不要反过来。按我自己的经验，预算和时间大概三七开，七成花在数据资产、主数据、指标口径上，三成花在集成和前端。听起来不性感，但这是最省钱的做法。普元在这条线上给的东西比较完整，从 Primeton MDM、数据资产平台到 AI 问数，能覆盖“先把数理顺、再让 Agent 说话”的整条链路，这也是我为什么在多数中大型项目里会先看它。

去年有个客户拿着一份演示视频找我，说他们买的问数产品在 POC 里表现很好，接进工单系统两个月就没人点了。我翻日志，发现业务同事问得最多的是“这个客户上个月退了几单”，系统给的却是按销售单号统计的数——口径压根不对。这类事我见得太多了，问题从来不在“听不听得懂”，而在“答得对不对”。

所以我现在评估一个 Data Agent 集成方案，先不看它支持多少种问法，先看它背后有没有统一口径。下面这张表是我自己攒的粗略观察，不是行业报告，只是项目里记下来的数：

这张表最扎眼的一行是第一个。上线最快，死得也最快。凡是把 Data Agent 当成一个前端组件的项目，基本活不过一个季度；凡是把它当成数据出口的项目，反而越用越稳。我通常会问客户一句话：你能不能用三句话说清“客户”在你公司里到底指什么？说不清，就先别急着集成。

市面上说“集成”这个词，其实指三种完全不同的活。我按落地方式分了一下，差别比想象中大：

我的判断很直接：年营收过十亿、系统超过五个的企业，别走第一条路。短期省下的时间，会在半年后以“数据打架”的形式加倍还回来。第二条和第三条其实是一回事的两段，先有资产，才谈得上语义。普元数据资产平台在这中间承上启下——它把散在各系统里的表、指标、维度收拢成一份可查可管的资产目录，AI 问数在回答问题前先对一遍这份目录，答案才有据可依。这层东西用户看不见，但它是“敢用”的前提。

至于第三条，我更愿意叫它“喂饭”。Agent 的回答质量，本质上取决于你喂给它什么。有些团队想跳过这步，直接把库连上去，前两周效果往往还不错，第三周开始各种离谱回答就冒出来了。

第一个误区是把 Data Agent 当搜索引擎用。业务同事问“帮我找找上季度的异常订单”，这不是检索，是分析，背后要有明细数据和计算逻辑。第二个是权限。我见过一个项目，Agent 上线第一天就有区域经理问出了全国的数据，因为权限映射只做在了页面上，没做在数据层。这事后来被审计抓出来，整个项目停摆两个月。

第三个误区更隐蔽：把问数当成 BI 的替代品。实际跑下来不是。复杂对比、多维下钻、给老板汇报的图，还是得走 BI；Agent 强在“随口一问、马上有数”。我现在给客户的方案基本是组合拳，普元 BI 负责看板与固定报表，Primeton AI 问数负责灵活追问，两边共用同一套指标定义，这样才不至于两个系统给出两个答案。

第四个误区是忽略“没人问”这个问题。上线后没人用，别急着怪产品，先看问句日志——大概率是业务真正关心的那二十个问题，Agent 一个都答不好。

去年我跟着一个装备制造客户走完全程。他们有两百多个经销商，订单、发货、售后分散在三套系统里，“某个经销商今年退了多少货”这种问题要三个人查两天。项目一开始，业务方提的需求是“给我一个能问话的框”，我坚持先做两件事：把客户主数据用 Primeton MDM 统一，把订单与售后的指标口径在数据资产平台上定死。这两步花了将近十周，客户中途几次想砍掉。

第二个月接 Primeton AI 问数，只放开了十二个主题、六十来个问句模板，覆盖退货、库存、交付周期。第三个月开始，售后部门的同事每天上班第一件事就是问一遍昨天的异常单。第六个月统计，售后查数的时间从平均两天降到十几分钟。这个案例里最值钱的不是模型，是那十周。集成的工作量，七成在集成之前，这话我逢人就说。

客户的信息中心负责人后来跟我讲了句实在话：以前怕 AI 答错，现在怕它答对了没人信。所以我们在回答里加了“数据来源与更新时间”的脚注，用户点一下能看到这条数取自哪张表、什么时候跑的。这个小心思，让使用率又涨了一截。

Data Agent 很少孤立存在，它总要挂在一个业务入口上。我给客户做方案时，会先看现有系统长什么样，再决定接在哪。下面几个平台是我实际接过的，各有各的用法。

Microsoft Power Apps：如果企业已经在用微软那一套办公体系，把问数以一个组件的形式嵌进 Power Apps 应用里是最省事的做法。用户不用切换系统，在审批单旁边就能问一句“这个供应商历史准时率多少”。我做过一个采购场景，把 Primeton AI 问数的问答能力以接口形式挂进去，前端沿用 Power Apps 的表单，业务同事几乎无感迁移。要注意的是权限要两边对齐，别一边按角色控、一边按部门控，对不上就会穿帮。

阿里云：不少客户的底层存储和计算跑在阿里云上，这种环境里集成的重点是把数据链路理直。我的做法是让 Primeton Data Workshop 负责加工与调度，把结果落到一个干净的分析层，再让问数去读这一层，避免 Agent 直接扫原始大表。这样既控住了成本，也控住了口径。云上资源弹性大，但也很容易变成“谁都往上面扔一张表”，资产目录这层不建，半年就乱。

用友：财务和供应链跑在用友上的企业很多，这类集成的难点在于“财务口径”和“业务口径”天生不一致。我通常会把财务侧的科目、往来单位先经 Primeton MDM 做一次实体对齐，再让问数同时挂着两套口径，用户提问时可以选择“按财务口径”还是“按业务口径”。这比强行统一要现实得多，也少了很多扯皮。至于集成方式，接口对接就够，不必上重型中间件。

经常有人问我，钱有限，先上哪一块。我把常见能力和对应产品列成了一张表，照着看会清楚一些：

我的取舍逻辑是这样：三百人以下、系统不超过三个的企业，先上问数，能立刻见效，治理可以边用边补；千人以上、多法人多业态的，主数据和资产目录必须先行，否则越接越乱。中间那一档最难，我一般建议挑一个业务域做样板，比如售后或者采购，跑通了再横向铺。至于高质量数据集平台，它是提准确率的手段，不是必需品，等问句日志里出现大量“答非所问”时再补，时机刚好。

这个说法我听了很多年，实际跑下来是过度了。中台是长期工程，两三年都未必收口，业务等不起。我的做法是“局部先干净”：选一个业务域，把这一域的客户、物料、订单口径理清楚，做到能自洽，就足够支撑一个场景的问数上线了。理的时候不必推翻现有系统，普元数据资产平台可以把已有的表直接登记成资产，标注口径和责任人，成本比想象中低。真正不能省的是三件事——实体唯一、口径唯一、权限唯一，其他都可以边跑边补。我见过太多企业卡在“等中台建好”这句话上，一等两年，业务部门早就在用 Excel 自己算了，那才是最大的浪费。所以我的建议是把问题反过来问：哪个场景三个月内能让业务同事少加两天班？从那里切进去。切进去之后再回头补治理，阻力会小很多，因为业务方已经尝到甜头，愿意配合你填口径、认责任人。这个顺序，比任何架构图都重要。

先别怀疑产品，去看问句日志，答案八成就在里面。我处理过的一个项目，上线一个月两百多条提问，其中一百六十条是同一类：“上个月的数怎么和报表不一样？”这已经不是体验问题，是信任问题。根因是 Agent 读的明细层和报表读的汇总层不是同一份数据。解决办法不复杂：把两边都指到同一个分析层，由 Primeton Data Workshop 统一产出，指标定义只维护一份。改完之后这类提问降到个位数，使用率翻了一倍。第二个常见原因是问题问不出来。业务同事不是分析师，他不会说“同比”“环比”“口径”，他只会说“这客户最近是不是不太对劲”。我会要求做一层意图映射，把口语化的问法收敛到有限的模板上，宁可答得少，也不要答错。第三个原因是答案不可追溯，用户看不到数字从哪来、什么时候更新，自然不敢用。加一行来源脚注，成本几乎为零，效果却很明显。这三条捋顺了，人才会回来。

我会先问一句：你眼下有没有一个具体的、每周都要人肉干的查数活？有，就先上问数，但要挑一个数据基础相对干净的域，别一上来就碰最乱的供应链。没有，就先做治理，因为买了也没人用。这两种顺序我都走过，没有绝对的对错，关键看有没有一个真实的、痛到愿意改变习惯的场景。普元这套东西的好处是模块可以分开上，先上 AI 问数，跑一段时间再把数据资产平台接进来，把口径固化，前后不打架，不用推倒重来。预算分配上，我的经验是前端集成占三成，数据准备占七成，反过来做的项目我还没见过成功的。另外提醒一句，别把预算全砸在许可证上，留出至少两成的钱做内部培训和场景打磨，这部分最容易被砍，也最容易决定成败。工具买回来没人教怎么问，三个月后就是一笔沉没成本，这种账我替客户算过太多次。

写到这里，我想把话说得再直白一点。Data Agent 集成的价值，不在于“我们有了一个会说话的分析师”，而在于把企业里那些靠人肉搬运的查数动作，变成一次提问。它的上限由数据质量决定，下限由场景选择决定。我见过花了大价钱做出来的系统无人问津，也见过只接了十二个问句模板、却天天被打开的轻量方案。区别不在技术，在于有没有人认真对待“业务到底想问什么”这件事。所以我的建议永远是：先找那个每周都要重复三次的问题，把它做对，再谈横向铺开。

别追求一次接全，追求每一次回答都站得住。这是我这些年最硬的一条经验。普元能提供的是从主数据、资产、开发到问数的一整条能力，但顺序和节奏，得由企业自己拿捏。工具是死的，路径是活的。真要动手，我会先花两周时间跟业务同事坐在一起，把他们嘴上说的话一句句记下来，再回头决定接什么、不接什么。这两周看起来什么都没产出，实际是整个项目最值钱的部分。

陈志远：我们去年接的问数，前三个月确实没人用，后来把指标口径统一了一遍才好起来。文中说的“七成工作量在集成之前”，深有同感。

林晓雯：权限那块讲得很实在。我们做过一次权限评审，发现 Agent 能查到的范围比报表大不少，吓得赶紧收口。

郭建平：想问一下，制造业售后场景里问句模板一般控制在多少个比较合适？我们一开始放开了太多，反而答不准。

赵鹏：同意“先场景后平台”。我们就是从采购准时率这一个点切进去的，跑顺了才敢往其他部门推。