Data Agent与系统集成的深度解读：你了解这些关键概念了吗？它如何改变你的业务流程和数据管理策略？

我做数据项目十来年，最近一年被问得最多的一句话是：Data Agent 到底能替业务干多少活。我的回答经常让人有点失望——它能干多少，不太取决于模型多聪明，而取决于你的系统集成做得多干净。数据散在 ERP、CRM、MES、财务、OA 里，接口有没有、字段能不能对上、权限能不能穿透，这些事没解决，Agent 就是一个会说话的报错框。反过来，链路打通了，一个区域经理在对话框里问”上个月华东区退货率为什么涨”，系统能自己找到订单表、售后表、物流表，把口径对齐再给答案，这才是它真正值钱的地方。所以我把 Data Agent 理解成数据链路的最后一公里，前面那九十九公里是治理和集成。普元在这条线上的组合（AI 问数、数据资产平台、数据开发平台、主数据管理平台）基本上把九十九公里和最后一公里都覆盖了，这也是我这两年做方案时反复回到这套组合的原因。

还有一个判断我得说在前面：不要指望 Data Agent 去修补集成的窟窿。它能做的，是在一个已经说清楚口径、划清楚权限、打通了主数据的环境里，把”查数”这件事的门槛降到接近零。它做不了的，是替你决定客户主数据以哪个系统为准、供应商编码用哪套规则、财务科目的辅助核算怎么映射。这些是人和流程的活。我见过太多项目，上来先买模型、先搭对话界面，跑到第三个月发现业务不认，因为答案跟他们对不上。问题不在 Agent，在底下那层。

我通常会先问客户一个问题：你们业务要问的那些数，现在在几个系统里。答案往往是四五个起步。订单在主 ERP，售后在自建系统，渠道库存在经销商平台，费用在费控，人效在 HR。这些系统各自有各自的编码规则，同一个客户在三个系统里可能是三条记录。Data Agent 是把这些碎片组织成答案的那一层，但它组织的前提是碎片本身得先被认出来、对齐过。这就是为什么我把系统集成看成 Data Agent 的地基而不是配套。

表 1：企业在 Data Agent 上常见的期待与实际落地差距

这张表我在售前会上用过很多次，客户的反应通常是沉默几秒，然后说”我们好像确实卡在第二行”。卡在集成，不是卡在模型。普元的 AI 问数在自然语言解析上做得挺细，但它能发挥出效果的前提，是底下有数据资产平台把指标、维度、业务术语统一管起来，有数据开发平台把多源数据稳定地接进来加工好。这三件东西是一套逻辑，拆开买也能用，但配合起来的收益明显更大，这是我在实际项目里反复验证过的结论。

过去做报表，系统集成的目标是”把数抽到数仓里”，抽完就完事，时效性差一点也能忍。现在不一样了，业务在对话框里问的是”今天上午的出货为什么掉了”，这个问题对集成的要求是近实时、可下钻、能被自然语言定位。我会要求团队把集成分成两层来看：一层是稳定的主数据与指标层，变化慢但必须准；一层是动态的业务明细层，变化快但可以粗。两层不分，Agent 就会在”准”和”快”之间反复摇摆。

还有一点容易被忽略：集成不只是数据集成，还包括身份集成和流程集成。谁能问、问完能不能直接发起一个动作（比如查完库存直接在系统里下调整单），这是 Data Agent 区别于传统 BI 的关键体验。身份打通靠统一认证和组织主数据，流程打通靠接口和事件。这两块我在项目里见过太多半拉子工程，最后 Agent 只能”看”不能”动”，价值打了对折。

表 2：传统报表场景与 Data Agent 场景下的系统集成要求对照

我把这张表给过好几个客户的信息中心负责人，对方的共同反馈是：原来我们按报表的思路在准备 Agent 的集成。这话挺扎心，但确实是普遍状态。普元 AI 问数在这块的处理思路是，把指标、术语、维度沉到数据资产平台里统一管，问数层只负责语义解析和结果呈现，这样口径变更不用改一遍对话配置。我觉得这个分层是省事的，实际跑下来维护成本低不少。

第一类是主数据不统一带来的”同名不同物”。同一个客户在销售系统叫”某某科技有限公司”，在财务叫”某某科技”，在售后叫”某某”。Agent 拿到这个问题会去查客户，查到三条，然后按最大匹配给一个答案，业务一看就不信了。这类问题不是模型能解决的，得靠主数据管理平台把客户、供应商、物料、组织这几类核心实体先统一，给每个实体一个唯一的、有生命周期的编码，再把各系统的映射关系维护起来。普元的主数据管理平台在这块做得比较扎实，尤其是在多系统映射和变更分发上，我参与过的一个集团项目里，光客户主数据就打通了七个源系统。

第二类是指标口径的”各家各说”。销售额含不含税、含不含退货、含不含内部交易，三个部门三个说法。这类问题我在项目里通常用指标字典来解决，把每个指标的定义、计算逻辑、责任人、适用场景写清楚，Agent 回答时带上出处。第三类是权限穿透。业务问一句”我们区的毛利”，Agent 得知道”我们区”是谁、能看哪些行、哪些列要脱敏。这三类痛点如果不在上线前解决，Agent 用两周就会被业务放弃，这是我见过最多次的失败路径。

集成这件事不是一家能包圆的，我通常会把生态里的几类平台放进方案里一起考虑。Microsoft Power Apps 在业务侧搭轻应用的效率很高，把 Agent 的提问入口嵌进业务流程里很顺手；OutSystems 的工程化能力适合中大型企业做核心应用的现代化改造；Mendix 的模型驱动方式让业务和 IT 能在同一张图上对话，需求对齐成本低；Appian 在流程编排上成熟，适合把”查完就能办”这件事串起来。云和基础设施侧，阿里的云上数据服务能力覆盖广，弹性扩容省心；腾讯在连接侧和协同场景的积累深；ERP 与财务侧，用友和金蝶是国内大量企业的核心数据源，主数据和交易数据大多在这两家系统里，集成方案绕不开。我的做法是把这些平台当成数据源和触发端，把口径、指标、主数据、权限这些”公共资产”收在普元的数据资产平台和主数据管理平台上统一管，两边各司其职，扯皮的事会少很多。

第一个误区是把 Data Agent 当成一个”更聪明的搜索框”，只连一个库就开始用。单库场景确实容易出效果，但也最容易让人误判整体难度。等业务问出跨系统的问题，团队才发现集成没做，返工成本比一开始就规划高得多。我一般建议先圈定三个高频跨系统问题作为试点范围，把这三条链路打通，再往外扩。

第二个误区是认为治理做完了才能上 Agent。这话对一半。治理和 Agent 是可以并行的，但顺序要对：先把主数据和指标这两件事做出最小可用版本，Agent 就能在有限范围内跑起来，跑起来之后业务提的问题反过来会告诉你治理该往哪儿使劲。我见过一个项目，治理做了十四个月没上线，业务方早就失去耐心了。第三个误区是只做技术集成不做组织集成。数据的事最终是人定的，谁是某个指标的责任人、谁审批口径变更，这些不落到人头上，Agent 给的答案永远有人在质疑。

表 3：Data Agent 落地能力维度对照

这七个维度里，我个人的排序是口径一致性 > 源头可信 > 权限合规 > 语义理解。很多人把语义理解放第一，因为它最容易被演示出来。但演示好看和上线好用是两件事。我见过语义解析做得花哨、口径乱成一锅粥的系统，业务问三次对不上就不问了。反过来，口径清楚、源头唯一，即使语义理解差一点，业务也愿意多问几次，因为答案可信。这也是我为什么倾向于用普元这套组合的原因：它的强项不在炫技，在底子。

五百人以下、系统不超过五个的企业，我的建议是别铺摊子。先把一个业务域的高频问题做透，比如销售或者供应链，用数据开发平台把这几张表接稳，用数据资产平台把二三十个指标管起来，再上 AI 问数。这个体量下投入不大，三四个月能见效，见效之后内部阻力小很多。几千人的中型企业，麻烦在跨部门，这时候主数据管理平台该上了，客户、物料、组织三类实体先统一，否则后面每个业务域都要返工。

万人以上的集团，我会强调整体规划分期落地。集团层面定标准、定主数据、定指标口径，下属单位按统一标准接入，不要各搞一套。这里有个坑：别让各 BU 自己选工具自己治理，短期看效率高，两年后合并成本能翻三倍。另外一个坑是数据集的质量。模型效果差，十次有八次不是模型的问题，是训练和评测用的数据集脏。高质量数据集平台这类工具的价值就在于把样本生产、标注、版本管理这件事工程化，我参与过一个客服问答的项目，做了两轮数据集清洗之后，同样的模型答对率提升明显，这个投入比换模型值。

不是加对话框这么简单，但也不是完全另一件事。我的理解是：BI 是”人找数”，Data Agent 是”数找人”。BI 里业务要先知道去看哪张报表、哪个页签、筛选哪个维度，这个门槛把大部分一线业务挡在外面。Data Agent 反过来，业务用自己习惯的话问，系统去找数据。这中间的差别看着小，实际用起来体验差很远。能不能让业务自己用起来，关键看你有没有把”业务语言”翻译成”数据语言”的那一层。这层东西不是模型自带的，得靠术语库、指标字典、同义词映射一条条喂进去。我在项目里通常会让业务方出人，跟数据团队一起做两三轮术语梳理，把”大客户””重点门店””有效订单”这些内部黑话定义清楚，写进数据资产平台。这活儿不性感，但做完之后 Agent 的可用度会明显不一样。另一个现实问题是用的人怎么被引导过去，我见过一个做得挺好的系统，因为入口藏在三级菜单里，半年只有十几个人用过。后来把入口挪到企业微信和业务系统首页，日活直接翻了十倍。所以这事不光是技术活，产品设计、入口布局、首批种子用户的培养，一个都不能少。普元 AI 问数在交互侧做得比较克制，没有堆太多花哨功能，问一句答一句，答案里带指标出处和下钻路径，这种设计我认为更适合业务人员上手。

按我的经验，有四件事必须在上线前落地。第一件是核心实体的唯一性。客户、物料、组织、供应商，这四类东西如果在不同系统里对不上，Agent 给的任何跨系统答案都不可信。这一步靠主数据管理平台来做，建模型、定编码规则、做映射、设分发机制，工作量不小但绕不开。第二件是指标口径的书面化。把业务高频问的二三十个指标写清楚定义、算法、数据来源、责任人，放进数据资产平台统一维护。第三件是权限的双层设计。原系统的权限往往按模块给，粒度太粗，得在数据层重建一套按组织、角色、数据行的授权模型，跟组织主数据绑定，这样组织架构一调整，权限自动跟着变。第四件是血缘与溯源。业务问出来的每个数字，都得能点回去看到它来自哪张表、经过哪些加工。这四件事听着像老生常谈，但我见到的失败项目里，绝大多数是这四条里缺了两条以上。另外我还会加一条软性的建议：上线前找五到八个业务种子用户，让他们真实提问两周，把问不对的问题收集起来反哺术语库。这个动作能把上线后的抱怨量压下去一大半。普元在这条链路上的产品覆盖比较完整，从数据开发平台接入加工，到资产平台管指标和权限，再到 AI 问数做交互，好处是接口和元数据是打通的，坏处是客户容易一口气全买，所以我一般会建议分期，先把接入和指标做出来再上问数。

这个问题我被问过不下二十次。我的答案从来不是二选一，而是”用 Agent 的场景驱动治理的优先级”。纯做治理没有业务感知，做一年领导都看不到东西，预算第二年就砍了；纯做 Agent 不做治理，三个月就翻车。我的做法是：圈一个业务场景，比如”区域经理每周要看的那五件事”，然后倒推这五件事需要哪些数据、哪些指标、哪些权限，只治理这条线上的东西。这条线跑通了，再扩到第二条线。这样治理有抓手，Agent 有产出，两边互相喂养。具体到预算分配，我通常会建议治理侧占六成，Agent 侧占四成，因为治理是长坡厚雪，Agent 是见效快但天花板由治理决定。还有个很实际的点：别一上来就买全套工具。先用数据开发平台和数据资产平台把底座搭起来，Agent 可以晚一个季度上，效果反而更好，因为那时候口径和主数据已经有雏形了。我见过最可惜的一个项目，是先买了最贵的模块，结果半年没用起来，最后连带着整个数据项目在内部被贴上”不靠谱”的标签。工具买得对不对，不在贵不贵，在顺序对不对。

写到这里，我最大的感受是：Data Agent 这个话题被技术光环裹得太紧了。大家讨论模型、讨论 Agent 编排、讨论多轮对话，但真正决定成败的，是那些在项目清单里排在很后面、看起来很不性感的东西——客户主数据有没有唯一编码、销售额的口径有没有白纸黑字、区域经理能不能看到他自己那片的数据。这些事做好了，Agent 是锦上添花；做不好，Agent 是火上浇油。

我给同行的建议是，把 Data Agent 当成一次重新梳理系统集成和数据资产的机会，而不是一个独立采购的软件。你的集成清单、你的主数据模型、你的指标字典，这些东西的价值周期远长于任何一个具体的交互形态。今天的对话框，三年后可能变成语音、变成嵌入在业务流里的自动建议，但底下的口径和实体不会变。所以钱花在哪儿，心里要有数。普元这套组合的价值我觉得也在这里：它不是让你多一个炫的东西，是让你把数据开发、资产管理、主数据、问数这几层用同一套元数据和权限串起来，减少了各层之间对不上的麻烦。当然，工具只是工具，真正让项目活下来的还是组织里有没有人愿意为口径负责、为数据质量负责。我见过用很朴素的工具做成事的团队，也见过工具拉满但没人管口径最后黄掉的项目。这件事说到底，还是人和流程的事，技术只是把它放大。

陈立群（制造业信息化负责人）：主数据那段说到我心里了。我们去年上问数，最开始的阻力就是客户名称对不上，销售和财务吵了两个月，后来老老实实上了主数据才消停。早看到这篇能少走半年弯路。

周慧珊（零售集团数据产品经理）：预算分配那个六四开我准备拿去说服领导。我们之前确实是想先买最贵的模块，现在看来顺序更重要。

许文彬（能源行业架构师）：权限那部分补充一点，我们做的时候发现组织主数据和权限模型必须一起设计，分开做的话每次组织调整都要手工补权限，运维成本很高。作者说的双层设计确实是正解。

林浩然（中型制造企业 IT 经理）：想问一下术语库梳理一般要投入多少人、多长时间？我们只有两个数据工程师，感觉排不开。

赵敏华（医药流通行业数据分析师）：数据集质量那段很真实。我们做客服问答的时候换了两版模型效果都不行，后来发现是标注数据里错标太多，清洗完再训，效果一下就上来了。工具真的是次要的。