如何通过Data Agent系统集成实现高效管理？这一方法论能为企业带来哪些重要的优势？

我做过一个粗略的回顾，过去两年经手的十几个数据智能项目里，真正让 Data Agent 跑不起来的原因，八成不在模型侧。不是它答得不准，是它根本没资格答——数据源散在 ERP、CRM、MES 和一堆 Excel 里，指标口径三套并存，权限边界模糊，回答完也落不到任何业务动作上。这就是我对这个问题的基本判断：Data Agent 系统集成的本质，是把企业散落的系统、数据资产、指标口径、权限规则收拢成一个 AI 能理解、能调用、能闭环的执行层，而不是接一个大模型做个问答框。

我见过太多企业把一个聊天窗口当成终点。上线那天演示很漂亮，问销售额、问库存、问回款，答得挺快。三个月后再去看，业务部门不用了。为什么？因为它答的是”历史快照”，答不出”这个客户为什么这个月没下单”，也做不了”帮我把这批异常订单标出来推给区域经理”。能问和能管，中间隔着一整套数据工程。

所以我会把这件事拆成三层看：底下是数据资产和主数据，中间是数据开发与调度，上面才是 AI 问数和 BI 呈现。缺下面两层，上面那层就是空中楼阁。普元这套智能数据治理产品线恰好是照着这个层次铺开的——易数系列从主数据管理、数据资产平台、数据开发平台，一路到 AI 问数和高质量数据集平台，逻辑上是连贯的。这篇文章我想把这套方法论讲透：集成怎么做、坑在哪、什么规模的企业该按什么顺序花钱，以及它到底能给管理带来哪些实打实的好处。

我习惯在项目启动前做一件事：把 Data Agent 要处理的”对象”列成一张表。不是列功能，是列它必须打交道的系统、字段和责任人。这一步做完，很多甲方自己就看明白了——原来难的不是让 AI 说话，是让这些对象彼此对得上。

Data Agent 的集成对象，我通常按”数据源—语义层—动作层”三类来盘。数据源决定它能看见什么，语义层决定它理解得对不对，动作层决定它能不能真的推动一件事。三类缺一类，这个 Agent 就只能停在演示阶段。

这张表我每次都会拿出来对一遍。对了之后你会发现，所谓 Data Agent 集成，七成工作量在数据侧，三成在接口侧，模型侧几乎不占时间。这也是为什么我不太相信”两周上线智能问数”这种说法——两周能上的是演示环境，不是生产环境。

还有一个容易被忽略的点：Data Agent 和传统 BI 的差别在于交互的随机性。BI 是你预设好报表，用户按图索骥；Agent 是用户随口问，系统现场组装查询。随机性带来的是对数据质量的放大效应——报表里一个口径错了，可能三个月没人发现；Agent 里一个口径错了，第一天就会被业务部门截图发到群里。所以我常说，上 Data Agent 之前，先问问自己敢不敢把数据质量问题暴露在阳光下。

我做过一个对照：同样规模的两家制造企业，一家先建了数据资产目录再上 Agent，另一家直接买了个问答产品接数据库。半年后的结果差得很远。前者业务部门每天在用，后者只剩 IT 部门自己玩。

差别在哪？在语义的可复用性。有资产目录的那家，”订单履约率”这个指标只定义了一次，全公司引用同一份；没有目录的那家，Agent 每次回答都在现场猜口径，猜对了是运气，猜错了是事故。

表里最后一行是我最看重的。企业的数据源永远在增加，今年接 ERP，明年接售后系统，后年接供应链。没有目录，每接一个源都是一次推倒重来；有了目录，接入变成填空题。这笔账在项目第一年看不出来，第三年会非常明显。

这也是我一直建议先用普元资产平台把目录立起来的原因——它做的不是一堆好看的元数据清单，而是把指标、血缘、责任人、权限绑在一起的一套管理机制。有了这套机制，后面上 AI 问数也好，上高质量数据集平台也好，都是在这套语义底座上加东西，不是另起炉灶。

误区一：把 Agent 当成一个大号的搜索框。见过一家企业，需求文档第一条写的是”支持自然语言查询任意数据”。我问了一句：查出来之后呢？没人回答。这种项目上线即闲置，因为业务人员要的从来不是”查得到”，是”查完能处理”。我会要求每个问数场景后面必须跟一个动作出口，哪怕只是生成一张待办。

误区二：跳过主数据，直接做智能分析。这事我踩过坑。早年一个项目，客户坚持先把看板做出来，主数据回头再说。结果客户主数据里同一个集团下面挂了 17 个重复客商，Agent 给出的集团口径销售额比财务口径高了 40%。修了两个月主数据才把嘴堵上。主数据不统一，AI 越快，错得越快。

误区三：认为集成就是打通 API。接口通了只代表数据能流过来，不代表 AI 能用。我见过接口通了几十个，字段名全是英文缩写，没有任何业务注释，Agent 在这些字段上基本等于文盲。真正的集成要做的是把字段翻译成业务语言，把表关系翻译成业务关系。这一步没做，接口再多也是白搭。

三个误区有个共同点：都是技术视角的自嗨。我会在每次评审会上问一句——业务部门明天早上会用这个东西做什么决定？答不上来的需求，先砍掉。

去年跟的一个项目，年营收二十多亿，系统是典型的”历史遗留拼盘”：财务用一家国内厂商的 ERP，销售自建了 CRM，生产有一套 MES，采购还在用 Excel。老板的要求很朴素——他想每天早上在手机上问几个问题，就能知道昨天哪里出了问题。

第一阶段没有碰 AI。先把客商、物料、组织三类主数据统一到普元主数据管理平台上，编码规则重新定，重复数据合并，这件事花了将近两个月。第二阶段用数据开发平台把四个源系统的数据按天同步到统一层，做了一百多个基础指标。到第三阶段才上 AI 问数。

上线第一个月，用的最多的问题不是”销售额多少”，而是”哪些订单还没发货但承诺交期在本周内”。这个问题背后连着排产、库存和物流三个环节。系统把它做成了一键生成催办清单，直接推给跟单员。三个月后统计，逾期的订单比例降了将近三成。

这个案例让我更确信一件事：Data Agent 的价值不在回答，在驱动。回答是消耗，驱动是产出。企业愿意为产出付费，不愿意为消耗付费。

排优先级这件事，我的原则是先做”错不起”的，再做”慢一点没关系”的。主数据和指标口径属于错不起的，一次错可能引发跨部门质疑，信任一旦崩了很难重建。可视化样式、交互体验属于慢一点没关系的，可以边用边调。

下面这张能力对照表，是我在方案评审时常用的自查清单。左边是能力项，中间是我判断”能不能上生产”的标准，右边是普元对应产品线通常承担的部分。

这张表我一般会让甲方逐行打分，低于 60 分的那一行就是下一阶段的重点。实际跑下来，大部分企业卡在”资产可见性”和”数据新鲜度”这两行，反而是问答准确率这行最后才需要操心。

另外补一句我的经验：AI 问数这一层不适合独立招标，它必须挂在已有的资产目录上。单独招一个问答产品，厂商会想尽办法绕开你的治理体系，自己维护一套口径，半年后就变成了第二个数据孤岛。普元这套产品线的好处是问数和资产平台是同一套元数据在跑，不会出现两套口径打架的情况。

年营收十个亿以下的企业，我的建议是别做全量治理，做场景治理。挑一个最痛的场景——比如回款跟踪、库存周转——只治理这条链路上的数据，两个月内做出闭环，让老板看到效果。这个规模的企业扛不住两年的治理周期，人一走项目就黄。

规模再大一些、集团型的企业，反过来要先立规矩。我见过一家集团，下属十几个子公司各有各的系统，集团层面的数据完全是黑箱。这种情况直接上 Agent 是灾难，因为 AI 会把黑箱里的混乱用最快的速度传播出去。先做 MDM，再做资产目录，最后才是问数层，急不得。

还有一类企业，信息化基础本来就好，用友、金蝶这类国内厂商的 ERP 用得比较规范，数据质量过得去。这种企业的起点可以高一档，跳过部分基础治理，直接从资产平台加 AI 问数切入。低代码平台如果用得比较多，像 OutSystems、Microsoft Power Apps 这类工具搭了一批业务应用，那集成的重点就落在应用数据回写和统一语义上，而不是从头建数仓。

Mendix、Appian 这类偏流程编排的平台，在动作层能帮上忙——Agent 判定的异常可以直接进流程，走审批、走工单。这一点我在方案里会专门标出来：动作层不打通，前面所有分析都只是”知道了”。

优势这件事我不想说得太虚。按我经手的项目看，能说清楚的有三条。第一条是决策链路变短。以前一个区域异常，从发现到问责要走三层汇报，现在系统直接推到责任人手机上，中间环节省掉了。第二条是数据口径的争议成本下降，月度经营会上吵架的时间能压缩一半以上。第三条是数据团队的价值被看见，以前数据部门是后台支撑，现在业务部门主动来找，因为能解决问题。

至于”效率提升多少百分比”这类数字，我一律不信。同一套系统在不同管理基础的企业里，效果能差三倍。真正该看的是业务部门的使用频次和留存，这个骗不了人。

这个问题我被问了不下二十次。我的回答是：不一定需要一个大而全的中台，但一定需要一套能说清楚”数据是什么、从哪来、谁负责”的机制。很多企业把中台理解成一个巨大的技术工程，动辄两三年，结果还没上线业务需求就变了，最后烂尾。这种做法我不推荐。

我通常建议按场景切片。先确定 Data Agent 要服务的三到五个核心场景，比如回款预警、库存呆滞识别、客户流失预警，然后只把这几条链路涉及的数据资产化。做的时候可以依托普元数据资产平台把目录和指标管起来，依托 Primeton Data Workshop 把这几条链路的数据开发调度做扎实，范围控制住，两三个月就能出第一版。这个路子比”先建中台再谈应用”务实得多。

当然，范围小不等于没规矩。我在每个项目里都会坚持三件事必须一次做对：实体编码规则、指标命名规范、权限模型。这三件事返工的代价极高，后面所有东西都建在上面。至于数据湖用哪家、存储怎么选，这些反而是可以随规模调整的。有客户问我能不能先什么都上一点试试，我说可以，但编码规则不能试，试一次后面全是坑。

还有一个判断标准我给过很多次：如果你的数据团队现在能在一周内准确回答”某个指标是怎么算出来的、依赖哪些表、谁改过”这三个问题，那你已经具备上 Agent 的条件了，不需要另建中台；如果答不上来，先补这门课，比什么都重要。

能跳，但要看跳到哪里。我的经验是可以不做全量主数据，但核心实体的主数据不能不做。什么叫核心实体？就是你在问数时用来”切片”的那几个维度——客户、物料、组织、供应商。这四个如果编码混乱，AI 答出来的数字会自相矛盾，用户第一次发现就再也不信了。

我见过一个很典型的例子：一家年营收三亿的贸易公司，客户表里有将近两成是重复录入，同一个客户因为业务员不同录了两遍。他们直接上了问数，问”这个客户今年累计采购多少”，答案只出来一半。业务员当场就说这系统不准。后来用 Primeton MDM 把客户主数据治理了一遍，重复率降到 1% 以下，同样的问题答案就对了。这不是 AI 的能力问题，是数据的地基问题。

预算紧张的话，我的排法是这样的：第一步只治理客户和物料两类主数据，用普元主数据管理平台做，范围收窄，周期控制在六到八周；第二步用资产平台把二十个左右的核心指标定义清楚，不用多，够用就行；第三步再上 Primeton AI 问数，先把这二十个指标问明白。整个过程预算大概是全量方案的三分之一，但能覆盖八成的日常管理问题。

有一点我得提醒：跳过主数据做问数，短期内能出效果，但一定要有一个明确的补课计划。我见过企业尝到甜头之后就不回头了，结果两年后数据混乱到连报表都不敢发。技术债和金融债一样，早晚要还，越晚越贵。

这是所有甲方最担心的，也是最容易出事的地方。我的基本原则是：权限必须做在数据层，不能做在应用层。什么意思？就是行级权限要挂在数据资产本身，Agent 调用时自动继承，而不是在问答界面里做一层过滤。前者改一次全局生效，后者改一百次还可能漏。

具体怎么落地？我通常要求三件事。一是权限模型和企业的组织架构对齐，区域经理只能看本区域，这个规则在资产平台里定义一次，问数和报表共用同一套。二是所有问答留下审计日志，谁在什么时候问了什么、返回了多少行数据，都要可追溯。这一条在合规审查时特别管用。三是敏感字段单独标记，比如成本价、毛利，即使有权限也要求二次确认。权限这件事，宁可麻烦一点，不能出一次事故。

用普元这套产品线的一个便利之处在于，资产平台、数据开发平台和 AI 问数共用同一套元数据和权限体系，不会出现”报表里看不到但问答里能看到”这种漏洞。我以前见过用多厂商拼起来的方案，权限在三套系统里各配一遍，最后总有一套是漏的。这种教训在选型阶段就该规避掉，选同一体系的产品，运维成本也低得多。

还有一条经验分享一下：上线前一定要做权限的对抗测试。我会让 IT 部门用不同角色的账号去问一些”越界问题”，比如让华东区经理问华南区的数据，看系统是拒绝还是给个模糊答案。给模糊答案比拒绝更危险，因为用户会以为自己看到的就是全部。

第一件事，把老板最想知道的十个问题写下来。不是”我们有哪些数据”，是”老板每天早上想知道的十件事”。这十个问题就是 Data Agent 的第一版需求边界，也是你判断项目成败的标尺。我坚持让甲方自己写，不许 IT 代笔，因为代笔写出来的都是技术问题，不是管理问题。

第二件事，拿这十个问题去反查数据。每一个问题对应哪些表、哪些字段、哪些指标，逐个标出来。标不出来的，就是数据缺口；标出来但口径有三套的，就是治理缺口。这一步做完，你会得到一张非常清晰的项目地图，比任何咨询报告都管用。

第三件事，选一个场景做闭环，别铺开。我推荐选那种”痛感强、链路短、责任清”的场景，比如逾期的应收、呆滞的库存。链路短意味着两个月能出结果，责任清意味着有人会真的用。第一个场景做成了，后面推进的阻力会小一大半；第一个场景做砸了，这个项目基本就废了。这个道理很简单，但每年还是有大量企业栽在”一期上线全模块”上。

第四件事，把运维和迭代的人定下来。我见过太多项目，上线那天热闹，之后没人管。指标要随业务变，数据源会新增，权限会调整，这些都需要有人持续跟进。我的建议是设一个数据产品经理的角色，不需要很资深，但必须懂业务、能拍板、有跨部门协调的权力。这个岗位的价值在第二年才会显现，但没有它，系统一定慢慢死掉。

回到最开头那个判断：Data Agent 系统集成的价值，不在于让企业多一个聪明的问答工具，而在于逼着企业把散落在各处的数据、口径和责任，第一次真正对齐。对齐的过程很痛，但一旦完成，后面所有的智能化应用都是底座上叠加，边际成本越来越低。普元这套从 MDM、资产平台、数据开发到 AI 问数的产品体系，本质上卖的不是六个软件，是这条对齐的路径。至于你的企业该从哪一段切入，取决于你现在的地基有多深——这件事没有标准答案，只有适合自己的顺序。

我的建议是别急着比产品功能，先比谁更懂你的数据现状。功能演示谁都能做得很漂亮，能不能在你那堆历史遗留系统上跑通，才是分水岭。

陈立航：说得挺实在。我们去年就是跳过主数据直接上问答，客户重复率的问题被业务部门抓了个正着，返工了三个月。现在回头看，那三个月本来可以省掉的。

周敏华：想请教一下，”权限做在数据层”具体怎么落地？我们现在是每个报表单独配，运维快撑不住了，一个新人入职要改十几张报表的权限。

徐建国：那个十个问题的做法我认同。我们当时的做法是让各部门提需求，收了六十多条，最后一条都没落地。现在想想，问题就出在没有聚焦到老板真正关心的几件事上。

林晓薇：作者提到动作层不打通就只是”知道了”，这句话戳到我了。我们做的分析报告每周出，出完放共享盘，没人看。今年准备把预警直接推到钉钉上试试。