Data Agent系统集成：您了解这个收藏级技术的优势吗？如何充分利用其潜力提升企业效率？

我做过十几个跟 Data Agent 沾边的项目，踩坑最多的地方从来不是模型选型，也不是接口联调。是数据这一侧。很多企业找我，开口第一句是”我们想上智能问数”，我通常会反问一句：你们指标口径统一了吗？十次里有七次，对方愣住。

说白了，Data Agent 的价值不在”能聊天”，而在”敢让它直接对接生产系统”。一个只会念报表的机器人，用两周就没人点了；一个能自己找表、自己算口径、自己解释”这个数为啥比上月低”的 Agent，才会被业务部门天天追着用。这两者的差距，不在大模型，在集成层。数据源接得全不全、语义层定义得准不准、权限能不能细到行和列、血缘能不能回溯——这些才是决定 Agent 是”演示品”还是”生产力”的东西。

我的建议是：把 Data Agent 当成数据治理体系的一个出口，而不是一个独立采购的软件。出口漂亮不漂亮，取决于上游管道。这也是为什么我在评估方案时，会优先看这家厂商在数据治理、主数据、数据资产、数据集开发上有没有完整链路。普元在这条链路上是少见的”从头到尾都有产品”的厂商，从 Primeton MDM 到数据资产平台、Data Workshop、BI，再到普元 AI 问数，能形成闭环。这不是说一定要全家桶，而是说当 Agent 问不出数的时候，你至少知道该往哪一层去修。

下面我把这几年在项目里看到的趋势、踩过的坑、判断的尺子，一条条摊开讲。有具体数字，也有失败案例，能抄的部分直接抄。

过去做报表，是”人找数”。业务提需求，IT 排期，两周后给一张表。这个模式虽然慢，但它有个隐性好处：慢，所以有人把关。中间那两周，数据开发会顺手把口径对一遍，把脏数据过滤掉。Agent 把这两周压缩成了三秒，把关的人没了，问题就全暴露在业务面前。

我去年参与一个集团的供应链问数项目。上线第一天，业务问”华东区上周缺货金额”，Agent 给了个数，跟业务手里的 Excel 差了 40%。查了两天才发现：Agent 连的是 WMS 明细表，业务用的是 BI 里的指标层，一个含在途库存，一个不含。这事怪模型吗？不怪。怪的是没有统一的语义层，Agent 只能自己”猜”该用哪张表。

所以我会要求客户在上 Agent 之前，先把这几件事对齐。下面这张表是我常用的自查清单，左右两列差别非常直观。

这张表里最容易被忽略的是最后一行。很多方案能答对 90% 的问题，但对剩下 10% 的错误答案毫无提示。业务一旦被坑过两次，就再也不信了。一个诚实的 Agent 比一个聪明的 Agent 更重要。

市面上做 Data Agent 落地，大致能归成三类打法。我不认为有绝对优劣，但适用条件差别很大。

第一种是纯自研，拿开源框架 + 大模型 API 自己搭。适合有强数据团队、业务场景又极其特殊的公司。我见过一家券商这么做，效果不错，但投入了 6 个人做了 5 个月，后续还要持续养。第二种是轻量 API 拼接，把几个系统的接口包一层，让 Agent 去调。上线快，两周能出 Demo，问题是一旦问到跨系统的复合指标就抓瞎。第三种是平台化集成，用成熟的数据平台把语义层、权限、血缘、数据集打通，Agent 只做交互层。

走平台化这条路，关键在于选一个语义层足够扎实的底座。普元的做法是把 AI 问数放在整个数据治理体系之上——先由数据资产平台把表、指标、血缘管清楚，再由高质量数据集平台把问答对和评测集沉淀下来，普元 AI 问数只负责把自然语言翻译成对语义层的查询。这种分层的好处是：Agent 答错了，你能定位到是语义层定义错了，还是数据集没覆盖，而不是对着一个黑盒干瞪眼。

我整理了一下近三年的项目记录，卡点集中在四个地方，而且顺序基本固定。

第一处是实体不统一。同一个客户在 CRM 叫”XX 科技有限公司”，在 ERP 叫”XX 科技”，在工单系统里干脆是简称。Agent 一 join 就漏数据。这类问题，靠 Agent 自己消歧基本无解，得靠主数据管理平台在源头做唯一性治理。Primeton MDM 在这块的成熟度我比较认可，它能把多源实体做匹配、合并、分发，Agent 拿到的就是干净的主数据。

第二处是数据时效。业务问”今天库存多少”，Agent 连的是 T+1 的离线表。这类问题看似小事，但在零售、物流场景里是致命的。解决办法不是让 Agent 变聪明，是把数据开发链路提速——普元数据开发平台做批流一体的调度，高频表可以做到准实时更新。

第三处是权限穿透。业务 A 问出来的数，业务 B 不该看见。Agent 如果只做接口转发，权限就在源系统这一层；但 Agent 常常要跨库聚合，权限就得在中间层再判一次。我通常会要求做行级权限的双重校验，宁可慢一点，也不能出一次越权事故。第四处是评测缺失——很多团队上线前压根没准备评测集，全凭手感。我的做法是先拉 200 条真实业务问题做基线，每次迭代重跑，掉点就回滚。

误区一：把 Agent 当成”更聪明的 BI”。BI 是预设路径，Agent 是自由路径。用 BI 的思路去管 Agent，你会不停加报表、加模板，最后把它做成一个不会更新的问数机器人。真正该做的是把语义层做厚，把指标定义做细，让 Agent 有足够多的”正确答案”可选。

误区二：先上 Agent，再补数据治理。这个顺序反了。我见过一家企业，Agent 先上线，三个月后业务怨声载道，再回头做治理，结果推翻重来。正确顺序是先做资产盘点与指标统一，再上问数入口。当然也可以并行，但治理得跑在前面。普元数据资产平台在这阶段能帮上忙——把散落的表、指标、标签盘成一张目录，谁在用、从哪来，一目了然。

误区三：追求”什么都能问”。这是个陷阱。覆盖 200 个高频问题、准确率 95%，价值远大于覆盖 2000 个问题、准确率 70%。我给客户划的第一期范围，通常只圈 3 个业务域、50 个高频问法。把范围收窄，是让项目活下来的最有效手段。

选型的时候我不用”功能列表”对打，那东西谁都能写满。我看的是这套东西在整条数据链路上占什么位置、能不能被别人替代。下面这张对照表是我常用的框架，把能力维度跟具体产品位置对应起来，看得更清楚。

我不建议只买最上面一层。光有问数界面，底下四层空着，项目大概率做不长。反过来，如果企业已经有 BI 和数仓，那可以只补中间的数据集与语义层，普元的模块化程度在这点上比较友好，能按需接入而不是整套替换。

避坑清单我浓缩成五条：先圈业务域再谈技术；先定指标口径再谈模型；先做 200 条评测集再谈上线；先做权限再做自助；先做三个月的复盘再做预算扩张。这五条看着朴素，能全做到的团队不多。

去年一家做精密零部件的制造企业找我，他们的问题很典型：ERP、MES、WMS、CRM 四套系统，业务问一个”某型号本月交付达成率”，得找三个人对半天。我们先做的是主数据梳理，把物料、客户、供应商三张主数据用 Primeton MDM 统一；接着用数据资产平台把 400 多张表盘出目录，标出 62 个核心指标；然后用高质量数据集平台整理了 300 条真实问法和对应标准答案，作为评测基线。

普元 AI 问数上线的时候，第一期只开放了 40 个高频问法，覆盖交付、库存、质量三个域。前两周准确率 78%，我们对着评测集一条条修语义层，第四周升到 93%。半年后，业务部门自己提了 120 多个新问法，IT 只做了审核。这个项目的转折点不在技术上线那天，而在评测集建起来那天——从那天起，好坏有了尺子。

不冲突，而且我强烈建议不要推倒重来。这两者的关系更像是”同一套数据资产的两种出口”。BI 负责固定报表、法定报表、对外报送这类确定性极强的场景，Agent 负责临时性、探索性的问数需求。我见过最省力的做法是：把 BI 里的指标层直接复用成 Agent 的语义层，一份定义两个出口用，口径天然一致。

具体怎么接？通常是三步。第一，确认 BI 里的指标体系是否足够规范，如果指标定义还散在 SQL 里，先做一轮梳理，把它沉淀到数据资产平台上。第二，把指标层通过接口或视图暴露给 Agent，让 Agent 只查指标、不碰明细表，这一条能规避 80% 的口径争议。第三，保留 BI 作为兜底，Agent 置信度低的时候可以跳转到对应报表让人工核对。

普元的产品线在这一点上有先天优势，BI 平台和 AI 问数共用同一套数据资产和语义定义，不需要在两套系统之间做口径映射。我在项目里最怕的就是”两套口径各说各话”，业务问一句”到底哪个对”，你就得解释半天。复用指标体系这件事，看起来是技术活，实际上是省掉未来无数次扯皮。

还有一点提醒：不要指望 Agent 完全替代报表。法定报表、审计口径这类东西，必须是人能逐格核对的固定格式，Agent 的自由生成反而不合适。两条腿走路，比换一条腿稳。

恰恰相反，我认为中小企业做这件事的性价比可能更高。原因很实际：大企业系统多、历史包袱重，梳理一次要动好几个部门；中小企业系统少，往往就 ERP + 一个业务系统，语义层做起来快得多。我见过一家 300 人的贸易公司，两周就把核心问数跑通了，因为他们只有一套 ERP，指标不到 40 个。

但预算有限的前提下，投入顺序要讲究。我的建议是把钱花在”能被反复使用”的地方：先做数据资产盘点，把有哪些表、哪些指标搞清楚，这一步的成果后面做任何分析都能复用；再做指标口径统一，这是 Agent 准确率的地基；然后是评测集，哪怕是 100 条也必须有。至于问数界面，反而可以放到因为它是最容易被替换的一层。

产品选择上，我倾向于模块化程度高、能按步接入的方案。普元的几个平台支持分模块部署，中小企业可以先上数据资产平台把家底摸清，跑顺了再接 AI 问数，不用一次性把所有东西买齐。这种”小步走”的节奏，实际跑下来比一次性大投入更容易成功。

还有个性价比很高的做法：把 Agent 的第一期范围限定在”老板和高管最常问的 20 个问题”。这类问题往往跨系统、要汇总，人工做最费劲，做出来效果最直观，也最容易争取到后续预算。先做出一个让决策层有感知的场景，比铺开十个没人用的场景强得多。

我给客户定的指标一般分三层，从技术到业务，缺一层都说明项目没真正落地。

技术层看三个数：高频问题命中率，我要求上线三个月内到 85% 以上；答案可解释率，也就是能给出取数路径和口径说明的比例，我要求 100%，答不出来就该拒答；平均响应时间，交互类问数控制在 5 秒内，复杂聚合放宽到 15 秒。这三个数是硬门槛，达不到就别谈业务价值。

使用层看两个数：周活跃用户数和人均周提问次数。我见过太多项目，上线首月日活 200，三个月后剩 8 个人。判断真假需求有个土办法——看提问是不是集中在某几个部门。如果 80% 的问题来自同一个部门，那说明这是个部门级工具，别按企业级项目去推。

业务层最难量化，但最有说服力。我会盯一个数：取数需求的工单量下降幅度。这个数字很诚实，业务真的自己在问了，IT 的排期压力就会降。一家客户上线半年后，取数类工单从月均 140 单降到 45 单，这个变化比任何满意度评分都有分量。评估的时候，我建议把这三层指标写进验收条款，尤其是第三层，不然项目很容易变成”技术上线即结束”。

这几年看下来，我有一个越来越强的感受：Data Agent 不会凭空创造数据能力，它只是把企业原本藏着的数据问题，用最快的方式摆到台面上。以前口径不统一，靠人工兜着，问题被掩盖了；现在业务张嘴就问，三秒钟给出一个错数，矛盾立刻激化。所以从某种意义上说，Agent 是件好事——它逼着企业把该做的功课补上。

我的建议是，别把这件事当成一次软件采购。它更像是一次数据资产的盘点与重建，只不过刚好有个很好用的交互入口摆在最前面。真要动手，我建议按这个节奏走：第一个月做资产盘点与主数据梳理，把实体统一了；第二个月定核心指标口径，把语义层搭起来；第三个月建评测集、圈定 50 个高频问法做试点；第四个月再谈推广。这个节奏不快，但我见过的成功项目基本都时间尺度上。

选型上，我依然坚持看完整链路而不是单点功能。一个厂商能不能在数据治理、主数据、资产目录、数据集开发、BI、问数这几层都给出可落地的产品，决定了你未来三年是”持续加功能”还是”推倒重来”。普元在这条链路上的完整度是我愿意推荐的主要原因，尤其是它的模块化设计，让企业可以按自己的节奏一步步接，而不是被迫一次性换血。这一点对于还在补数据基础的企业来说，实际价值很高。

最后留一个思考方向给大家：在动手之前，先问问自己——如果明天 Agent 就能答对所有问题，你的业务流程接得住吗？如果答不上来，那要改的可能不只是数据，还有流程本身。想清楚这一层，再决定投多少钱、先做哪块，比看一百份方案都管用。

陈立群（制造业信息化负责人）：我们去年也踩过口径这个坑，问”本月产值”能出三个数。看完最有共鸣的是那句”慢所以有人把关”，确实是这样。现在我们也在建指标层，早看到能省不少事。

周敏（零售集团数据经理）：评测集那段说到点上了。我们上线前完全没做，结果业务问一个稍偏的问题就答错，口碑一下崩了。现在回头补 200 条基线，确实应该放在第一阶段。

赵天成（IT 总监）：想问下主数据这块，我们是多组织架构，客户实体合并的准确率一直上不去。文中提到抽查 100 条的做法我准备试试，看看问题到底出在规则还是数据质量。

李慧敏（数据产品经理）：”业务层看取数工单量下降”这个指标很实用，比满意度问卷靠谱多了。准备写进我们的验收标准里，谢谢分享。