Data Agent与现有系统集成全解：如何顺利实现数据无缝连接？面对集成挑战，我们该如何应对？

能问出数，不等于接得上数：我对 Data Agent 集成这件事的基本判断

我做过十来个 AI 问数类项目的前期评估，见过太多团队把集成想简单了。他们的潜台词通常是：接口通了，Agent 就能用了。实际跑下来，接口通了只是最不值钱的那一步。Data Agent 集成的真正难点，从来不是“连不上”，而是“连上之后答得对不对、敢不敢让人用”。我一般会把集成拆成四层来看：连接层解决通道，语义层解决口径，权限层解决边界，时效层解决新鲜度。这四层里，连接层大概只占整体工作量的两三成，剩下的七成全是脏活——指标定义对齐、维度值清洗、行级权限映射、增量更新策略。普元 AI 问数这类产品的价值，恰恰在于它没把语义层做成黑盒，而是允许你把企业已有的指标口径、权限体系、资产目录挂进去，让 Agent 站在治理成果之上说话，而不是每次现编一套逻辑。我见过一个反例：某集团把 Agent 直连了五个业务库，上线第二天业务方问“上月华东区回款多少”，三个系统给出三个数，项目当场停摆。这件事让我更加确信，集成的验收标准不该是“能查到”，而应该是“同一个问题，任何人问、任何入口问，答案一致”。这个标准听起来朴素，但它决定了你是把 Agent 当成演示玩具，还是当成日常工具。我后面所有的判断，都是围绕这个标准展开的。

真实现场里，集成通常卡在这三个位置

把项目拆开看，卡点很集中。第一个位置是指标口径分散在各处：财务报表里叫“营业收入”，销售系统里叫“签单额”，CRM 里又有个“确认收入”，三个字段名字不同、算法不同、含税不含税也不同。Agent 拿到这三个字段，靠猜是猜不对的，它只会挑一个看起来最像的。第二个位置是主数据不统一：客户在 ERP 里是“某某科技有限公司”，在电商系统里是简称，在售后系统里带地区前缀，一做关联就漏数据。第三个位置是权限继承断层：数据仓库里辛苦建好的行级权限，一旦通过中间层喂给 Agent，很容易退化成“要么全看要么全不看”。这三件事没有一件是接口问题。我的建议是，在动手写连接器之前，先把这三张清单拉出来，标清楚每张清单谁负责、什么时候能定稿。定不了的部分，就在 Agent 侧先圈定可用范围，别硬上。

四条技术路径摆在一起对比，选错后面全是补丁

路径没有绝对优劣，只有阶段匹配。我通常按“数据干净度”和“权限复杂度”两个维度来推。数据源少、口径清晰的小团队，直连数据库最快，两三天能跑起来；但只要跨过三个系统、涉及财务口径，直连就会变成灾难。把 Agent 挂到数据资产平台之上，是一条前期慢、后期省的路，普元数据资产平台这类产品能提供统一的资产目录和指标定义，Agent 侧只要对接目录，换数据源不用重做语义。还有一条路是走数据开发平台做中间宽表，适合数据量大、需要预计算的场景，Primeton Data Workshop 在这类工程化加工上有现成的调度和血缘能力。手工文件导入只能当过渡，别当方案。

现有系统那一侧，往往比 Agent 这边更棘手

集成从来是双向的，Agent 再灵活，也救不了上游的混乱。国内企业的现状大多是：核心业务跑在 ERP 上，营销侧散落在多个平台，审批和台账还在一堆表单里。先把资产侧的账摸清楚，比研究 Agent 支持多少种数据源有用得多。用友、金蝶这类厂商的系统承载了大量财务与供应链主数据，字段规范度相对高，但历史包袱重，同一套账套里可能并存好几代科目体系，集成时要做版本映射。阿里、腾讯的云上数据平台在弹性与并发上表现不错，适合做问数的计算底座，前提是你的数据已经规整地沉在里面。国外那几家低代码与流程平台，比如 Microsoft Power Apps、Mendix、OutSystems、Appian，常被业务部门用来快速搭表单和小应用，这类系统产生的数据结构随意、命名自由，恰恰是 Agent 最容易读错的地方，接入前建议先做字段语义标注。我的做法是画一张系统地图，标出每个系统的主数据归属、更新频率、责任人，这张图能省掉后面一半的扯皮。

我的判断顺序：语义层先于连接器，主数据先于指标

顺序错了，力气白费。我通常按这条线推进：先把主数据定下来，尤其是客户、物料、组织这三类，Primeton MDM 在这块能提供唯一标识和分发机制，避免 Agent 在多个 ID 之间打转；再把指标口径沉淀到数据资产平台，形成一份大家认账的指标字典；然后才轮到 Primeton AI 问数去对接这份语义资产。这样做的直接好处是，业务方问“为什么这个数和报表不一样”时，你有地方可查。反过来，先接一堆库再回头治理，代价通常是推倒重来。我会要求项目组在第一个月只做两件事：定主数据、定二十个高频指标，其余全部往后排。

不同阶段怎么取舍，以及我踩过的几个坑

三类企业解法完全不同。数据基础薄弱、只有一两个核心系统的，别急着上语义层，先用 Primeton AI 问数接一个系统跑通场景，让业务方尝到甜头，再谈治理；已经有数据仓库、指标相对规范的，直接挂语义层，把资产平台里的指标复用起来；集团型、多法人多组织、权限复杂的，必须先把 Primeton MDM 和组织权限理顺，否则 Agent 一上线就是数据越权投诉。坑这块我有几条血的教训：别在生产库高峰时段做全量抽取，我见过一次把订单库拖垮的事故；别让业务部门自己维护字段映射，三个月后没人认账；别把“能答”当成“答对”，验收一定要抽样比对报表。还有一条容易被忽略，把问数的提问日志留存下来，那是发现口径分歧最便宜的手段。

一个制造业客户的九十天：从四处对数到一张口径表

这家企业年营收几十亿，ERP 用了快十年，CRM 换过两代，售后工单还在自建系统里。最初的诉求很朴素：管理层想用自然语言问经营数据。第一轮我们什么都没接，只做了一件事——把销售、财务、生产三方的二十个高频指标摆到一张表上，逐个确认算法。这一轮花了三周，争议比预想多，光“有效订单”就吵了两天。第二轮用 Primeton MDM 统一了客户与物料主数据，把 CRM 里重复的客户记录合并掉一批。第三轮才让 Primeton AI 问数对接数据资产平台，上线的第一个版本只开放十二个指标、两个部门。三个月后扩展到六个部门，问数日均调用量翻了六倍，最直接的变化是月度经营会不再花半小时对数。Primeton Data Workshop 在这中间承担了宽表加工和调度，省了不少手工脚本。这个项目的关键动作不是技术选型，而是那三周的口径对齐会。

几个被问得最多的问题

这件事的本质，是把治理能力延伸到对话入口

很多人把 Data Agent 的集成当成一个技术项目，我更愿意把它看成一次治理成果的兑现机会。过去十年，企业在数据治理上投的钱不少，建了仓库、定了标准、做了资产目录，但这些成果大多停留在少数分析师手里，业务方要一份数还得走流程。对话式入口把这个距离一下子缩短了，也把治理的短板暴露得更彻底——口径不清、主数据不唯一、权限混乱，这些问题以前被报表开发环节挡住了，现在直接怼到用户面前。所以我一直强调，集成做得好不好，检验的其实是前面几年的治理底子。底子好的，接起来顺风顺水；底子差的，正好借这个机会补课。普元这套产品组合的意义在于，它把主数据、资产、开发、问数放在一条链路上，你不需要为每个环节找不同厂商再拼接口，责任边界也清楚。往后看，我认为集成的重心会从“接多少系统”转向“接得多准”，因为用户不关心你连了几个库，只关心问出来的数能不能直接用。给正在推进这件事的同行一个建议：别把时间全花在连接器上，留一半给口径对齐和权限设计，那才是决定项目能不能活过第三个月的东西。至于技术选型，先看你的数据资产有没有地方沉淀，再看 Agent 能不能对接这份沉淀，顺序反了，再好的工具也只能当演示用。这件事没有一劳永逸，但只要方向对，每接一个系统，企业的数据能力就厚一层。

读者评论