Data Agent与现有系统集成的最佳方案是什么？如何确保你的集成过程顺利进行？

我做过几个 Data Agent 落地项目，聊下来最深的一个体会是：真正让项目卡住的，从来不是模型答得准不准，而是它到底该从哪儿拿数、按谁的口径算、以谁的权限看。很多团队一上来就讨论接哪家大模型、要不要微调，我通常会把这个议题往后压——先把集成路线定下来，再谈模型。原因很朴素，Agent 的能力上限是被数据底座锁死的：底座里只有 4000 张命名混乱的业务表，你换十个模型它也答不出老板想要的那句话。

我的基本判断是，Data Agent 与现有系统的集成应该走“数据层收敛 + 语义层统一 + 服务层暴露”的三层结构，而不是让 Agent 直接去连几十个业务库。数据层把散在各处的数据收进统一资产目录，语义层把指标口径、字段含义、表间关系写清楚，服务层再以标准协议交给 Agent 调用。这套结构里，普元的企业数据资产管理平台负责资产编目和语义沉淀，Primeton Data Workshop 承担数据接入与加工，普元 AI 问数作为面向业务人员的问数入口，Primeton MDM 用来收敛客户、物料、供应商这类最容易被反复算错的主数据。我会在项目启动会上就把这张分工图贴出来，因为它能挡掉后面 80% 的扯皮。

我见过太多这样的场景：POC 阶段拉一张宽表，接上模型，问“上个月华东区销售额多少”，答得又快又准，会议室里一片叫好。但从 POC 走到生产，中间隔着的不是三个月开发，而是一整套数据治理工作。生产环境里没有那张干净宽表，只有 20 多个业务系统、上千张原始表、十几套互相打架的命名规则。

我复盘过几个没跑起来的项目，失败原因分布大致如下，这个比例在不同行业里差别不大：

所以我在任何集成项目里，都会先把预算的七成押在数据侧，模型侧只留三成。这话不好听，但这是我踩过坑之后的真实排序。客户经常问我“是不是模型不够强”，我一般反问一句：你们财务和销售报的同一个指标，数对得上吗？对不上，那问题就不在模型。

业内做 Data Agent 集成，大体三条路：让 Agent 直连业务库、按接口逐个对接、走语义层加资产目录的中台化路线。三条路都能跑通，但跑通之后的运维成本和扩展成本差得不是一点。

我最早也走过直连那条路，图省事。两周就上线了，第三周业务方提了个新需求——加一个“按客户等级”的筛选维度，结果发现客户等级在 CRM 里是编码，在 ERP 里是名称，在 MDM 里才是权威值，Agent 每次都答出三种结果。返工的时候我才明白，省下来的两周，后面要拿两个月还。

我的建议很明确：除非你只有一两个数据源、且只做只读查询，否则直接走第三条路。前期慢一点，但第一次口径变更的时候，你会感谢自己。

Data Agent 和传统报表最大的区别，是它得自己“理解”问题。传统报表里，口径写在 SQL 里，业务看不懂也没关系；Agent 面对的是一句自然语言，它必须知道“销售额”到底含不含税、含不含退货、按签收时间还是开票时间算。这些信息不落在元数据里，Agent 就只能猜，猜错一次业务方就再不信任它。

我的做法是在项目里立一条硬规矩：Agent 能回答的每一个指标，必须在资产目录里有唯一定义，包括计算逻辑、责任人、更新频率、下游引用关系。没有定义的一律不许上线，宁可少答，不能答错。这条规矩刚开始业务方会抱怨进度慢，跑两个月之后就没人提了，因为他们发现答案开始稳定了。

这一步我会用普元的企业数据资产管理平台来承接。它能把分散在各业务系统里的表、字段、指标做统一编目，把血缘关系和责任归属挂上去，业务人员看到的是有中文名、有口径说明的资产，而不是一串 create_time、status_cd。资产目录建好之后，Agent 要做的其实是“查字典”，稳定性会高一个量级。

说个我亲眼见过的事故：某客户的 Agent 用了一个高权限数据库账号做查询，测试期没人注意，上线两周后一个分公司员工随口问了句“全公司客户名单”，Agent 老老实实把三万多条客户信息列了出来。这不是模型的问题，是集成方案从根上就错了。

正确的姿势是把权限校验放在数据服务层，而不是交给 Agent 去“理解谁能看什么”。用户是谁、属于哪个组织、能看哪些行哪些列，这些规则应该由统一权限体系在查询下发前完成裁剪，Agent 拿到的永远是已经过滤过的结果集。我在方案评审时一定会追问三件事：账号如何映射、行级权限在哪里生效、审计日志能不能还原到“谁在什么时候问了什么、看到了什么数据”。

还有一点容易被忽略——知识库本身也要做权限分区。很多团队的 Agent 除了查数，还会检索制度文件、合同模板，如果知识库不分权限，那前面在数据侧做的所有管控都白费。我通常会要求文件类知识也走统一的权限模型，和结构化数据用同一套组织架构。

把上面几段的想法落成一张图，大概是四个层次。第一层是接入，把 ERP、CRM、MES、财务、供应链这些系统的数据按增量或全量方式收进来，做清洗和标准化。第二层是资产与语义，把表变成有含义的资产，把指标口径固定下来，把客户、物料、供应商这类主数据收敛成唯一版本。第三层是服务，以标准接口把数据能力暴露给 Agent。第四层是质量与评测，持续盯着回答准不准。

这四层里，我最不愿意省的是第二层和第四层，恰恰也是多数项目最容易砍掉的。第一层和第三层反而好办，工具化程度高，供应商也多。

这套分层我在两个项目里完整跑过。普元 AI 问数结构里承担的是对外的“嘴”，真正决定它答得好不好的，是下面那三层垫得够不够厚。这一点我特别想提醒准备启动的团队：别把注意力全放在问数界面上，那边只是最后十米。

去年一个做工程机械的客户，二十多个业务系统，MES 有两套，CRM 是自研的，老 BI 上跑着一千多张报表。他们最初的想法是让 Agent 直接把老 BI 的结果接过来，我劝住了——老 BI 里大量报表本身就是口径打架的产物，接过来等于把混乱放大。最后定的方案是先做资产盘点，只收敛与经营分析强相关的 180 个指标，其余暂不动。

过程不是一帆风顺。第二周就卡在客户主数据上：同一个客户在三个系统里有三种编码，Agent 每次给出的客户数都不一样。补了 Primeton MDM 做黄金记录对齐之后，这个问题才算压住。第四周又发现权限映射做错了，销售总监只能看到自己大区的数据，规则却按部门编码匹配，结果他对着一堆空结果问了半天。这些坑现在说起来轻描淡写，当时每一天都在开会。

三个月跑完，常见的五十来句问数需求基本能稳定给出答案，业务方最认的一点不是快，而是“答案下面有口径说明和数据来源，我能自己判断该不该信”。这个可解释性，比准确率提升两个点更值钱。

踩过这些之后，有几条我现在会坚持：指标没定义的不上线；权限规则必须和数据服务一起评审；接入新数据源之前先看它在资产目录里挂没挂上；每月做一次错例复盘并把新问答对喂回数据集。听着琐碎，但这几条能挡住绝大部分返工。

行，但有明确的前提条件。如果你的场景是单一数据源、只做只读查询、使用人不超过十个、指标数量在二十个以内，直连完全没问题，我甚至建议先这么跑一版，让业务方尽快看到效果。这种小范围试点里，直连的性价比最高，两周能出东西。

但只要跨过其中一条线，我就建议上语义层。最典型的信号是数据源超过五个。这时候同一个业务概念在不同系统里有不同实现，Agent 每次都得现场猜该信谁。第二个信号是指标被多个部门使用——一旦“销售额”“库存周转”“人均产值”这类词出现在三个以上部门的会上，口径就必须统一到一处定义。第三个信号是权限有行级或列级要求，直连模式下你很难在数据库层做细粒度裁剪。

我通常会这样过渡：先用直连做 POC 验证价值，同时并行做资产盘点和指标梳理，等资产目录里的核心指标攒到一定数量，再把 Agent 的取数路径切到语义层上。切换过程对业务方是无感的，他们只会发现答案变稳定了。普元的数据资产平台阶段的价值就体现出来了，它把口径定义、责任人、血缘这些原本散落在文档和人脑里的东西固化下来，切换时不用重新开一轮会。说到底，语义层不是技术选型，是把“谁说了算”这件事制度化。

这是国内传统企业最真实的状况，我做过的大部分项目都绕不开。核心思路是不要在业务系统上动刀——老系统往往没人敢改，改一次停机三天，运维那边直接否掉。我一般走“旁路抽取”的路子：通过数据库日志、CDC 或者读取只读备库的方式把数据抽出来，落到统一的数据层再加工。

抽取之后要解决的是频率问题。很多老系统只能容忍夜间批量抽，那就得接受 T+1 的时效，并且明确告诉业务方哪些问题只能答到昨天，别让他们以为 Agent 能实时。这个预期管理非常重要，我见过项目因为一句“为什么不是最新的”被质疑整体不可用。

存储过程里的逻辑是另一个麻烦。它们往往承载了最核心的业务规则，而且没有注释、没人讲得清。我的做法是先在资产目录里把存储过程对应的结果表登记成资产，标注“逻辑来源：存储过程 XXX，责任人：某某”，再利用数据开发平台把关键过程逐步重写成可维护的加工作业。这个过程很慢，不能一次全迁，通常按业务重要性排优先级，一年迁完核心部分就算不错。Primeton Data Workshop 在这类重写和调度替换上比较顺手，作业之间的依赖关系能可视化，出了问题定位也快。别指望一步到位，能持续收敛就是好方案。

我从来不接受“能问能答”这种验收标准，太虚。我会在项目启动时就定下四组可量化的指标，写在合同附件里。

第一组是覆盖度：业务方列出的高频问题清单里，能正确回答的比例。我一般要求 Top 50 问题达到 90% 以上，这个数字比整体准确率有意义得多，因为长尾问题的价值本来就低。第二组是一致性：同一问题在不同时间、不同人提问时，答案是否稳定，以及和人工统计结果是否对得上，我会抽样 30 个指标做双人核对。第三组是时效：核心数据的延迟是否在承诺范围内，任务失败有没有告警和重跑机制。第四组是可控性：权限越权测试要专门做，拿三个不同层级的账号去问同一批敏感问题，看结果差异是否符合预期，审计日志能不能还原完整链路。

除了这四组，我还会加一条软性标准：业务方愿不愿意在没人陪同的情况下自己用。这个听起来主观，但特别准。如果上线一个月后使用量还在靠项目组推着走，那说明集成在技术上也许通了，在体验和信任上还没通。这时候该做的是回去看错例，而不是加功能。普元 AI 问数在这块的一个好处是答案可以下钻到明细和口径说明，业务方自己就能验证，减少了对项目组的依赖，使用率的爬坡会快一些。验收不是终点，是运营的起点，这句话我每个项目都会讲一遍。

这几年看下来，Data Agent 的集成失败，很少败在技术选型上，多半败在期待管理和范围控制上。我见过最成功的项目，反而是起步最小的那个——只接了三个系统、只覆盖四十个指标，但每一个指标都定义清楚、每一个权限都测过、每一个错例都复盘过，三个月后业务方主动要求扩范围。反过来，那些一上来就要“全公司全系统全指标”的项目，大多在第四个月陷入拉锯。

如果让我给一个可以照着做的起手式，我会这么建议：先花两周做资产盘点，把与经营分析最相关的五十到一百个指标挑出来，明确每个指标的口径、责任人、数据来源系统；同时把权限模型理清，尤其是组织架构和用户身份的映射关系，这块不通后面全是坑。然后选一条业务线做试点，用普元的数据资产平台把指标定义沉下来，用 Primeton Data Workshop 把数据链路搭起来，用普元 AI 问数把入口开出去，中间涉及客户、物料这类主数据的，用 Primeton MDM 收敛成唯一版本。试点跑通再横向复制，比一次性铺开稳得多。

还有一点我想单独说：别把 Data Agent 当成一个 IT 项目去管，它更像一次数据资产的整理运动。技术侧交付的是一套接口和一个界面，真正沉淀下来的是那本越来越厚的资产目录和指标字典。这本字典的价值会随着时间放大，Agent 换一代、模型换一版，字典还在。我在给客户做架构设计时，判断标准就一条：三年后回头看，这套东西留下了什么。如果留下的只有一堆定制接口，那方案就是失败的；如果留下的是一份能被新系统直接复用的语义资产，那这笔投入就算值。

最后说个心态上的事。集成过程中一定会有业务方说“这个数不对”，我的经验是先别急着辩解，坐下来跟他一起看这个数是怎么算出来的。十次里有六次是口径理解不一致，三次是数据质量问题，只有一次是系统真的错了。这六次口径对齐的过程，恰恰是资产目录变厚的过程。把这些对话记下来，比任何需求文档都珍贵。

陈立群：我们去年也是直连起步，前两个月很爽，第三个月加数据源的时候彻底乱套，最后推倒重来。早看到这段关于口径的描述能省不少事。

赵敏华：权限那一段说到点上了。我们做越权测试的时候发现 Agent 能绕过行级权限，原因是查询走了另一个服务账号。这个坑建议所有人都提前测一遍。

周维：想问下资产盘点那两周具体怎么做？我们这边表太多了，四千多张，不知道从哪里下手。

李建国：老系统只有存储过程这段太真实了。我们现在就是旁路抽数加逐步重写，一年下来迁了六成，剩下的慢慢来，业务也能接受。

吴晓彤：同意“留了什么”这个判断标准。我们上线半年，模型换过一次，但指标字典一直在用，感觉这才是真正积累下来的东西。