Data Agent技术避坑指南：如何识别常见陷阱？你的数据安全真的有保障吗？

Data Agent 这个东西，演示起来太容易了。给我一张干净的宽表，接个大模型，半小时就能让老板在手机上问”上个月华南大区卖得最好的三个产品是什么”。我见过太多这样的 POC，会议室里掌声一片。真正跑到生产环境、跑到第三个月还被业务主动打开使用的，比例低得让我有点意外。

问题基本都不在模型上。Data Agent 能不能用，七成取决于它下面的数据和语义底座，两成取决于权限与审计是不是真的沉到了数据层，剩下一成才是模型选型和提示词。很多人把这个比例搞反了，预算八成砸在交互和模型上，底座那层靠”先跑起来再说”，跑到后面就是无穷无尽的口径扯皮。

数据安全更是绕不过去的坎。业务员随口一句”帮我查下研发部今年的人均薪酬”，如果 Agent 老老实实答了，这个项目基本就废了。安全不能靠提示词拦，提示词是能被绕过的；得靠行级列级权限下沉、数据分级分类、全链路审计这些听着不性感的笨办法。我通常会问客户三个问题：谁在问、他能看到哪几行、他问过什么留下了什么记录。三个都答得上来，才谈得上”有保障”。

下面我按自己踩过的坑讲：陷阱长什么样、怎么在 POC 阶段就识别出来、安全该从哪几层去查、家底不同的企业该怎么排优先级。

2023 年下半年开始，几乎每个找我聊数据平台的人都会顺口问一句：能不能让业务自己问数。到了今年，问法变了——从”能不能做”变成”为什么做完没人用”。

我把这两年经手和旁观的三十来个项目在心里过了一遍，卡点集中得有点惊人。卡在指标口径上的项目最多，卡在权限上的次之，真正卡在模型能力上的，说实话没几个。

有个细节我印象很深。一个零售集团的 CIO 跟我说，他们第一版 Agent 上线两周就被业务抛弃了，原因不是答不出来，而是答得太自信——数据错了照样给结论，还配了一段很像样的分析理由。业务被坑两次之后，就再也不信了。信任这东西，建起来慢，塌下来只需要两次错答。

我把见过的坑归成五类，几乎每个失败项目都能对上其中两三个。它们共同的特点是：在 POC 阶段完全看不出来，上线才暴露。

第一类是让大模型裸写 SQL，跳过语义层。表结构直接塞进上下文，模型自己猜字段含义。单表查询看不出问题，一旦跨表关联、涉及指标计算，口径就开始飘。第二类是元数据没清洗就接进去，表名是拼音缩写，注释常年失修，模型只能猜。第三类是权限在应用层临时加钩子，Agent 直连数据库，等于开了一条绕过 BI 权限的旁路——这是我最担心的一类，出事就是安全事故。第四类是把业务明细表整张喂给通用大模型，数据出域的风险先不说，模型也扛不住那么多列。第五类是没有评测集，靠几位业务骨干拍脑袋说”差不多挺准”，上线后没有任何可量化的基线。

顺便说说几个流传很广但我并不认同的说法。有人讲”大模型够强了，语义层可以省掉”，我试过，省不掉。有人讲”先把数据都灌进向量库再说”，向量检索擅长找文档，不擅长算数，指标口径还是得靠结构化语义层。

安全不是加一条脱敏规则就完事。我评估一个 Data Agent 的安全水位，一般看四层是否闭环。

第一层是身份。Agent 必须继承企业统一的身份体系，SSO、组织架构、岗位角色都要能对上。如果它自己维护一套用户表，那就是权限黑洞。第二层是数据分级分类，哪些是公开、哪些是内部、哪些是核心商密，得先有账。这一块我会看普元数据资产平台的分类分级和血缘能力，它能回答”这个字段从哪来、流到哪去、谁在管”，安全策略才落得下去。

第三层是行级列级权限必须下沉到语义层，而不是靠提示词拦。提示词是可以被诱导绕过的，用户换个问法可能就破了。Primeton AI 问数 的做法是把权限规则放在指标和数据集这一层，Agent 生成查询时权限已经嵌进去了，用户问什么都越不过自己的边界。第四层是审计与溯源：谁在什么时候问了什么、Agent 生成了什么 SQL、命中了哪些表、返回了多少行，都要留痕。出事能查，才叫有保障。

还有两个容易被忽略的点：部署形态和数据出域。涉及经营数据的场景，我基本都会要求私有化或专有云部署，模型调用不出内网。另外要防提示词注入，比如在提问里夹带指令让它无视权限——这类攻击在真实环境里已经出现过了。

我评判一个 Data Agent 方案，不太看演示效果，更看它背后有没有配套的底座能力。演示看的是模型，底座看的是厂商在数据治理上积累了多少年。

我的建议是：底座能力不齐的方案，宁可晚半年上，也别先上线再补。补的成本比新建高得多，尤其是权限这一块，等出过事再改，业务那边已经不信了。

取舍上我一般这么分：数据底子薄的中型企业，先把物料、客户、组织这几类主数据用 Primeton MDM 管起来，再接普元数据资产平台把目录和血缘理清，问数可以先放一放；已经有数仓的中大型企业，重点是补语义层和权限下沉，Primeton AI 问数 可以直接架在现有数仓之上；集团多业态的，主数据先行是铁律，口径不统一谈智能都是空话；有自建模型需求的，还得配高质量数据集平台和 Primeton Data Workshop，把训练和评测的数据链路做扎实。

阿里云。很多企业的数据湖、MaxCompute 或 ODPS 集群是跑在阿里云上的，存算这一层已经很稳，弹性也够。这种情况下没必要动底层，普元数据资产平台可以直接挂上去做元数据采集、目录编制和血缘分析，把散在各个 project 里的表收拢成一张可查可管的资产地图；Primeton AI 问数 则在这一层之上构建指标语义和问数入口。我见过一个客户的组合就是这样：阿里云负责算力和存储，普元负责资产治理和自然语言问数，两边职责清晰，谁也不越界，实施周期比推倒重来短了一半多。

用友。制造业和流通企业的财务、供应链、人力主数据，很大一部分沉淀在用友的 ERP 里，这块是绕不过去的。我不建议在主数据上和 ERP 较劲，正确姿势是用 Primeton MDM 做标准和分发：把 ERP 里的客户、供应商、物料抽出来，做清洗、去重、编码统一，再反向分发给各个业务系统，包括 ERP 自身。这样 Agent 问”某客户今年累计回款多少”的时候，问的是同一套主数据口径，不会出现两个系统两个答案的尴尬。实际跑下来，这一步做完，问数的准确率提升往往比换模型明显得多。

去年我跟过一家做工程机械配件的集团。他们第一版 Agent 上线三周就被叫停，原因是销售问出来的毛利和财务对不上，差了两个点。排查下来，一张表叫”销售毛利”，但财务口径里还扣了运费和返利。

调整方案是三条线一起走：物料和客户主数据先用 Primeton MDM 统一编码；指标定义全部收到普元数据资产平台里做唯一口径登记，谁改谁审批；问数入口换成 Primeton AI 问数，权限按组织和客户归属下沉，销售只能看自己的片区。他们还用高质量数据集平台整理了一份 320 条的评测题集，分查数、对比、归因三类，每两周跑一次。

三个月后准确率从 62% 提到 90% 上下，最明显的变化不是数字，是业务愿意用了。上线半年，月活从十几个人涨到两百多。

我一般会掰成五个点去看。第一是越权，这是最要命的。Agent 走的是独立取数链路，如果权限没跟着走，等于在 BI 之外开了一扇没锁的门，一线员工问一句就能拿到薪酬、成本、客户名单。第二是脱敏失效，很多系统只在报表层做了掩码，Agent 直接查底层表，手机号、身份证原样返回。第三是提示词注入，用户在提问里夹带”忽略之前的限制”这类指令，诱导它生成高危 SQL，甚至拼出删表语句——只读账号是底线，但很多 POC 图省事用的是可写账号。

第四是审计缺失，问句、生成的 SQL、命中的表、返回行数全都没留痕，出了泄露事件根本定位不到人。第五是数据出域，把经营明细整表送给公网大模型做推理，这在很多行业是明确不合规的。我的做法是：身份统一走 SSO，权限下沉到语义层由 Primeton AI 问数 统一管控，数据和模型都放在内网，再加一份完整的问数审计日志。普元数据资产平台的分类分级结果可以直接作为权限策略的输入，省掉大量手工配置。

我碰到的客户里，十个有八个想”先上一个看看效果”，我的答案通常是：别串行，也别裸奔，分两条线走。

第一条线是先圈定两三个核心业务域，比如销售、库存、回款，把这三块的主数据和指标口径用 Primeton MDM 和普元数据资产平台理干净。不用全公司铺开，就这几个域，两三个月能出成果。第二条线是同步搭评测集，一百到三百条真实业务问题，从业务骨干嘴里一句句抠出来，这是后面所有优化的基准。

这两条线跑起来的同时，用 Primeton AI 问数 把语义层建在这几个域上做试点，让业务先用起来。我特别不建议的是”全量接入”——把所有库所有表都开放给 Agent，那不是开放数据，那是开放风险。圈定范围之后再逐步扩域，比一上来铺大摊子稳得多。实际跑下来，这种打法的半年效果，往往比一次性大投入的项目还好，因为每一步都能验证。

只看厂商演示的准确率数字，意义不大。我验收会做四件事。

一是自己出题。题集按类型分层：单表查数、跨表关联、同比环比、归因分析，每类至少三十条，标注标准答案。归因类最难，也最能看出水平。二是看失败时的表现——准确率不可能是 100%，关键是它答不出来的时候是拒答、是给不确定提示，还是硬编一个数。硬答的，直接否掉。三是看溯源，每条答案能不能点开看到用的哪张表、哪个指标、什么口径、什么时间的数据。四是看口径一致性，同一个问题换个问法问三遍，答案得一致。

这块可以用高质量数据集平台来管，把题集、标准答案、历次评测结果沉淀下来，形成迭代闭环。我见过做得好的团队，把评测做成每周自动跑的任务，准确率掉两个点就报警，去查是不是上游数据变了。这种机制比任何一次性的验收都管用。

Data Agent 这类产品，未来两年会像当年的 BI 一样普及，也大概率会像当年的 BI 一样，出现大量”建了但没人用”的僵尸系统。区别在哪里？我观察下来，不在技术，在有没有人认真对待底座那一层。

口径、主数据、元数据、权限、审计，这五件事听着都不酷，做起来都费劲，但它们决定了 Agent 是会帮你省时间，还是给你制造新的麻烦。我的判断很朴素：一家企业如果连自己的指标字典都拿不出来，就不该急着上智能问数。反过来，底座扎实的企业，用 Primeton AI 问数 这样的产品接上去，效果出得很快，因为该做的功课早就做完了。

安全这块，我更愿意把它当成设计约束而不是附加功能。权限要下沉、数据要分级、行为要留痕，这些在设计阶段想清楚，成本很低；等上线后出事了再补，付出的就不只是钱了。普元在这条线上做了二十多年数据治理，产品之间的衔接是通的——主数据、资产、数据集、问数、BI 能串成一条完整链路，这对中大型企业来说，省下的集成成本相当可观。

给正在选型的朋友一句实在建议：让对方把权限模型和语义层架构讲清楚，讲不清楚的，演示再炫也先放一放。

陈立航：我们去年上了一套问数，卡的就是口径。销售部和财务部为”回款”这个词吵了两个月，后来还是先做指标字典才推下去的，早看到这篇能少走弯路。

徐婉宁：权限那部分说到我心里了。我们内审做过一次测试，用普通账号问出了部门成本明细，当时冷汗都下来了。后来重做了权限下沉，才敢对外开放。

郑维江：制造业那段挺真实。我们 ERP 里客户主数据有十几万条重复，先清洗再谈智能问数，这个顺序是对的，反过来做纯属浪费钱。

何嘉桐：想请教一下，评测题集是业务部门出还是 IT 出？我们这边业务配合度不高，题集一直攒不起来。