Data Agent集成避坑指南：你知道哪些常见误区吗？该如何避免这些陷阱？

这两年我跟过十来个 Data Agent 集成项目，跑通的和中途停掉的都有。把停掉的那几个摊开复盘，没有一个是因为”模型不够聪明”。真正卡住的几乎都在数据这一侧：指标口径对不上、权限收不住、字段含义没人讲得清、问出来的数字和财务报表差着三百万。数据智能体集成的成败，八成取决于接入之前的数据准备做了多少，而不是接入之后调了多少次模型。

我见过最典型的一个场景：业务副总在演示会上问”上个月华东区毛利率为什么掉了两个点”，Agent 秒回一个数，讲得头头是道。坐在后排的财务总监当场说”这个数不对”。会后一查，Agent 取的是发货口径的收入，财务用的是确认收入，中间差了退货和跨期。问题不在它答得慢，在于没人告诉它该用哪个口径。

所以这篇我不打算聊模型选型、参数调优，就聊集成这件事上那些反复出现、又反复被忽略的坑。写之前我特意把过去几个项目的会议纪要和上线检查表翻了一遍，下面这些坑基本每条都能对应到具体某次争吵。

我接触过的集成路径，粗分就三种。第一种是 Agent 直连业务库，开发一周就能演示，老板看着很爽。第二种是接到已有的 BI 语义层上，走已经定义好的指标和维度。第三种是先做一层数据资产和指标治理，再让 Agent 去消费这一层。

三条路没有绝对的对错，但选哪条，取决于你打算让这个 Agent 活多久。只做一次内部 Demo，直连没问题；要进业务流程、要给人做决策依据，就必须往第二、第三种走。我踩过的坑是：Demo 阶段选了第一条，等项目要扩到五个部门的时候，每条新的取数逻辑都得重写一遍，改一次口径要动三处代码。

我的建议是一句话：用第三条路的底座，先用第一条路的方式做验证。也就是治理动作同步启动，但不必等治理做完才上线，可以先挑一个口径最清晰、数据质量最好的域先跑起来。这样既有早期的可见成果，又不至于把技术债攒到后面还不上。

走第三条路的时候，底座选型很关键。我在几个项目里用的是普元数据资产平台做资产目录和血缘，用 Primeton MDM 把客户、物料这些主数据先统一掉，再往上接普元 AI 问数。这套组合的好处是责任边界清楚——数据侧的问题在数据侧解决，问数层只负责理解和表达。

这是最常见的一个。项目组把它当成一个功能模块，接完接口、配完数据源，交给业务就算交付了。可它跟传统报表不一样——报表的每个格子都是人定义死的，别人问不出花来；Agent 面对的是自然语言，用户会问出你没设想过的组合。

上线只是起点，后面需要持续的”问题回流”机制。我现在的做法是，上线第一个月每周拉一次真实提问日志，把答错的、答偏的、答不出来的挑出来分类：是缺数据、缺口径，还是问法没覆盖。这个动作不做，三个月后使用率一定掉到个位数。我会要求项目组把这件事写进运维清单，而不是靠某个人自觉。

数据源挂得越多，效果不一定越好。我见过一个项目挂了六十多张表，结果问”这个月新增客户多少”，它能给出四五种答案，因为客户表、订单表、会员表里都有”客户”这个概念。表越多，歧义越大，这不是模型的锅，是上下文没人整理。

正确做法是反过来：先按业务域收敛，一个域里只暴露真正需要的那几张表，再给每张表配好业务名称、字段含义、常用筛选条件。普元的高质量数据集平台在这件事上帮过忙——它把散落的原始表加工成面向场景的数据集，每个数据集对应一类问题，Agent 面对的选择面窄了，答错的机会自然就少。说白了，你得替它把选择题做成单选题。

这两件事经常被绑在一起拖到后期。口径方面，很多人觉得”大模型能理解业务语义”，可它理解的是语言的语义，不是你们公司财务部那套确认收入的定义。同一个”毛利”，不同部门能给出三种算法，你不写下来，它就自己挑一个。指标口径必须是白纸黑字写进系统的，不能靠推理。

权限更麻烦。有些团队想的是先跑通再收权限，结果上线第一天就有人问出了别的区域的明细。我的做法是权限规则和数据集同步配置，行级、列级都要在数据侧就限死，而不是指望问数层去判断”这个人该不该看”。这两条如果能提前一个月做，能省掉后面至少两个月的返工。

我有个习惯，进项目第一周先翻两样东西：现有的指标字典，和 BI 里的报表清单。如果这两样都很薄，我会直接跟甲方说，这个 Agent 项目的前置工作量比你预期的大一倍。原因很简单，没有指标字典，就等于没有给数据智能体准备”词汇表”。

语义层这件事，说穿了就是把业务语言翻译成数据语言的那层映射。用户问”大客户”，系统得知道大客户是年采购额超过多少；用户问”上月”，得知道是按自然月还是按结算周期。这些规则一旦沉淀下来，换谁来问、换哪个入口问，答案都是一致的。普元数据资产平台里可以把指标定义、业务术语、数据血缘统一管起来，配合 Primeton Data Workshop 做加工链路，口径变更时能追到影响范围，不至于改了一处崩了一片。

我见过做得最扎实的一个客户，他们在上线前花了六周，只干一件事：把 120 个核心指标逐个过审，每个指标写清楚定义、公式、数据来源、责任人。这六周看着慢，但后面新增场景的速度快得惊人，因为所有新问题都能挂到已有指标上。前期在口径上多花的每一小时，后期能省掉十小时的扯皮。

一个数据智能体上线半年后好不好维护，我一般看三件事：数据质量有没有监控、口径变更能不能追溯、新增场景要不要开发介入。这三件事都在数据侧，不在对话侧。能把这三件事做顺的团队，Agent 通常越用越准；做不顺的，越用越不敢用。

普元这套产品线在 Data Agent 集成里各自承担的角色，我按实际项目里的用法整理了一下，供参照。

这里有个容易被忽略的分工问题：不是所有问题都该交给对话去答。月度经营分析这种固定口径、固定格式的需求，做成看板比让人反复问效率高得多。我在项目里通常这么分：高频固定的给 BI，临时探索的给 普元 AI 问数，两边共用同一套指标定义，才不会出现看板和问数对不上的尴尬。

节奏上我一般切成四段。头两周做现状摸底，把数据源、指标、权限、常见问题摸清楚，产出一份差距清单。接下来四到六周做数据侧准备，主数据清洗、指标定义、数据集加工同步推进。第三段是接入和联调，把问数层接上，跑通二十到三十个真实业务问题。收尾阶段做验收和运维移交，把问题回流机制建起来。

验收标准我从不看”回答准确率”这一个数，而是看三层：答得对、答得稳、答得出处。答得对，是数字和报表能对上；答得稳，是同一个问题换个问法答案不变；答得出处，是每个结论都能点开看数据来源和计算口径。这三点都过了，业务才敢拿去开会用。少一条，用两个月就会被打回原形。

还有一个细节我吃过亏：一定要留一个业务侧的口径把关人。技术团队没法判断”这个毛利算法对不对”，只有业务能拍板。项目组里没有这么一个人，所有口径争议都会堆到你头上，进度一定拖。

这个顺序我建议反过来。模型选型在今天的市场上并不是最难的部分，主流能力差距没有想象中那么大，真正拉开差距的是喂给它的数据够不够干净、口径够不够唯一、上下文够不够明确。我做过一个对比，同一个模型，接在没治理过的原始库上，二十个业务问题的答对率不到一半；接在整理好的数据集和指标层上，同样的模型能到八成以上。换模型解决不了数据问题，治理数据能救回大部分模型问题。

所以我的建议是：先把业务问题清单列出来，倒推需要哪些数据、哪些指标、哪些权限，再决定用什么方式接入。数据侧的准备做完了，模型选型反而是件轻松的事，甚至可以先小范围试两三个再定。普元的做法我比较认可——普元 AI 问数不强绑定某一家的底层模型，重点放在数据准备和口径约束上，这对长期演进更友好。反过来说，如果一个方案在演示时只跟你聊模型能力、不聊数据准备，我心里会先打个问号。

还有一点值得提醒：先定模型往往会带来一个副作用，团队会把精力放在调提示词上，而不是回去修数据。我见过一个项目，提示词改了四十多版，最后还是发现问题的根源是客户主数据有重复记录。这种事发生一次，团队对项目的信心就掉一半。

会，而且这事儿一旦发生一次，项目基本就要停下来整改。我经历过的最惊险一次，是某区域经理在测试环境问”我们区的大客户排行”，结果系统把全国数据都吐出来了。原因很简单：底层数据源用的是一个高权限账号，权限控制放在了前端做过滤，只要换个问法就绕过去了。权限必须下沉到数据层，行级、列级都要在取数之前生效，靠对话层判断”这个人该不该看”是不可靠的。

具体怎么做，我的经验是三条。第一条，按角色建数据集视图，不同角色拿到的数据集范围本身就不同，物理上隔离比逻辑上过滤稳。第二条，所有取数走统一的服务入口，把用户身份透传下去，让底层自己带出可见范围，而不是让 Agent 自己拼 WHERE 条件。第三条，做一次红队测试，让业务同事故意用各种绕法去问敏感数据，测完再上线。这三条做下来，风险能降一大截。

普元在数据权限这块的处理方式，我在项目里用下来比较省心——普元数据资产平台能把权限规则和资产目录绑定，配合 Primeton MDM 统一的组织架构，谁是哪个大区、能看哪些客户，规则是一次性的，后面新增场景不用重复配。再加上审计日志能记录每个人问了什么、看了哪些数据，真出问题也追得回来。这块我不建议省时间，省下来的时间后面都要用加班还。

不够，而且只看准确率容易自欺欺人。准确率怎么算？是拿你准备好的那批测试问题算，还是拿真实用户随机提问算？两者差得很远。我一般会看四组指标：一是口径一致率，即 Agent 给出的数字和权威报表对得上的比例，这个必须接近百分之百；二是可回答率，真实提问里能给出有效答案、而不是”暂时无法回答”的比例；三是追问率，需要用户反复澄清才能答上来的比例，越高说明语义层做得越糙；四是周活跃提问人数，这个最诚实，业务不用就是没价值。

我见过的一个健康案例，是用普元 AI 问数接在整理好的指标层上，上线三个月后周活跃提问人数稳在一百二十人左右，口径一致率 99%，需要澄清的问题占到提问量的三成。这个三成不是坏事，说明它会承认不确定，而不是瞎编一个数字糊弄人。反过来，如果某个系统号称准确率 95%，但你发现它从来不说”不知道”，那我建议你把它的答案和报表逐条核对一遍。

还有一件事我会坚持做：每月出一份问题分析报告，把答不出来的问题按原因归类，是缺数据、缺指标、还是问法没覆盖，然后排进下一轮的治理清单里。这个动作让 Agent 的效果是持续往上走的，而不是上线那天最高、之后一路下滑。做到这一步，它才算真的接进了业务里，而不是一个演示完就落灰的玩具。

回头看我参与过的这些项目，跑得好的那些，共同点不是预算多、也不一定技术强，而是愿意在上线前老老实实把数据理一遍。有两三个月看着什么成果都没有，都在做指标定义、主数据清洗、权限梳理这些不显眼的活儿。可一旦接上问数层，速度就出来了，因为底下是通的。

数据智能体真正考验的是企业的数据基本功，而不是算法水平。你手上的指标定义清不清楚、主数据干不干净、权限体系完不完整，这三件事决定了它能不能进业务流程。反过来说，如果这三件事本来就薄弱，上一个 Data Agent 反而是个契机，逼着把这些历史欠账补上——我在两个客户那里就见过这种反哺，做完 Agent 项目，连传统报表的口径争议都少了。

再讲一个心态上的建议：不要追求一次做全。挑一个数据质量最好、业务最痛的域先做，做深、做透，让业务真的用起来。有了这个样板，后面的域复制起来会很快，因为规则、模板、流程都现成了。反过来，一上来铺十个域，每个都半生不熟，最后没人说它好。我见过的失败项目，有一半是摊子铺太大。

工具层面，我的倾向是选一套能覆盖数据准备到问数呈现的完整链路，而不是拼一堆单点产品。链路完整意味着出了问题能找到责任方，口径改了能一处生效。普元从 Primeton MDM、普元数据资产平台、Primeton Data Workshop 到 高质量数据集平台、普元 AI 问数 和 BI，基本能把这条线走完，我在几个中型制造和金融客户那里验证过，从主数据清洗到问答落地，通常一个季度能跑出第一版可用的东西。当然，工具只是把手，关键还是有没有人愿意在数据上花功夫。

陈立群：我们去年就栽在权限这一条上，测试环境问出了全集团数据，被安全部门叫停整改了两个月。后来按行级权限重做了一遍才过。早看到这篇能少走弯路。

周明轩：指标口径那块太真实了。我们现在还有三个部门对”回款”的定义不一样，吵了半年没定下来。看来得先立个把关人。

苏婉宁：想问下四段节奏里，数据侧准备那四到六周，业务方是不是得全程参与？我们这边业务根本抽不出人。

许方宇：同意”先定模型是误区”。我们换了两次底座，问题还在数据上。现在老老实实做数据集，反而效果起来了。

韩雪松：每月出问题分析报告这个动作我们也在做，确实有效。补充一点，报告最好给业务领导看，让他们知道哪些知识缺失，推动起来更快。