如何实现Data Agent与现有系统的高效集成？在集成过程中最常见的挑战是什么？

我做过十几个数据类项目，返工率最高的环节从来不是模型选型，而是接入。一个数据智能体能不能用起来，八成取决于它面前那堆系统长什么样、口径清不清楚、权限划没划开。我的基本判断是：这件事本质是治理工程，不是模型工程。把大模型换一个更强的版本，解决不了“华东区销售额”和“华东大区回款额”两个口径打架的问题，也解决不了它拿着只读账号把全公司数据都翻一遍的风险。所以我看集成方案时，第一个问题永远是“语义层在哪”，而不是“用的什么模型”。第二个判断是：能落地的团队都把接口做成了“工具清单”，而不是把数据库账号直接丢过去。前者是给智能体一份明确的菜单，几十个动作，每个动作有边界、有日志；后者是把仓库钥匙给了一个新员工，看着很自由，出事没人兜得住。第三个判断更务实：第一期只接三到五个高频问题对应的表和接口，跑通了再扩，别一上来就想接全。我见过太多“全量接入”的方案书，写到第九十页还在讲架构图，业务那边已经没人等了。普元在这条路上给的东西比较对味，它不主张直接把库敞开，而是先在语义和资产层做一层收口，这个思路我认同。

很多人一聊接入就往“接口协议”上想，其实接口只是表皮。我习惯把整件事拆成四层来看，一层一层验，出问题能快速定位在哪一层。接入层解决“能不能连上”，语义层解决“它懂不懂业务”，权限层解决“它能看多少”，反馈层解决“错了怎么纠”。这四层里，接入层的技术难度最低，市面上有大量现成的连接器和网关方案；真正拉开差距的是后三层，而这三层恰好是纯技术团队最容易忽略的。我这几年养成的习惯是，做方案评审时先让对方画一张四层图，哪一层是空的，我心里基本就有数了。空语义层的项目，上线两周内必然出现“同一个问题两个答案”；空权限层的项目，跑到第三个月一定会被安全部门叫停；空反馈层的项目，用得越久越没人信它，因为错了一次就再也没人纠正。

四层拆解之后，我把每一层要交付的东西列成了一张表，这也是我评审集成方案的核对清单：

实际项目里能走的路就那么三条，我几乎每次都要在评审会上掰扯一遍。走法不一样，后面两年的运维成本差得很远。我的取舍逻辑是：越靠近业务口径，越值得多花两周；越靠近原始表，越容易在半年后失控。直连数据库这条路，演示效果最好，两小时就能让智能体跑出一条 SQL，但它把口径判断、字段理解、权限过滤全压在模型身上，一次幻觉就是一次生产事故。走语义指标层要慢一些，前期梳理指标得拉业务开会，可一旦建成，后面每接一个新系统都是复用。走 API 和工具封装的方式最适合有大量业务系统、且接口本来就规范的企业，智能体不碰数据，只调动作，风险边界非常清楚，代价是接口没覆盖到的分析场景就问不出来。我的建议通常是组合：核心经营指标走语义层，跨系统动作走工具封装，临时探索类问题留一个带权限的只读沙箱。

三条路线的对照，我用下面这张表跟业务方对齐期望，比讲架构图有效得多：

说得再具体一点，我在现场遇到最多的麻烦是四类。排在第一位的永远是口径，不是技术。“订单金额”含不含运费、退单是冲减还是单列、跨月退款算哪个月，这些问题在原来的报表体系里靠人脑兜着，一旦让智能体自己判断，它每次都给你一个看似合理的不同答案。第二类是元数据缺失，表名拼音缩写、字段注释为空、外键约束没建，人还能靠经验猜，模型只能瞎蒙。第三类是权限断层，源系统的权限是按岗位配的，智能体的账号是新建的，两套体系没打通，结果就是要么查不到、要么全都能查到。第四类是长尾问题的消耗，上线后有大约两成的问题是没人提前想到的，如果没有纠错和回流机制，这一小撮问题会持续消耗信任，直到业务方干脆不用。这四类里，只有第二类能靠工具自动化解决一部分，其余三类都得靠人和流程，躲不掉。

我见过一个典型误区：把智能体当搜索引擎来做，觉得接入的系统越多、数据越全，效果就越好。实际跑下来，接入面和准确率是负相关的。表从十个扩到两百个，模型选错的概率直线上升，问题从“查不出来”变成“查错了还振振有词”。另一个误区是拿测试集的准确率当验收标准，几十道题答对九成，上线就翻车，因为真实提问里长尾表述占了很大比例，用户不会按你设计的句式说话。我通常会要求把验收改成“高频问题集 + 随机抽样”双轨，前者看底线，后者看真实水位。还有一种误区是把权限问题往后放，先跑通再说，这种事我劝都别劝，只要数据里有薪资、有客户名单、有身份证号，安全部门一定会在某个节点把项目摁住，那时候返工的成本比一开始就做高得多。

企业里的存量系统太杂，同一套方案照搬一定出事。我一般按“系统是谁家的、数据在哪、有没有开放接口”分成几类分别处理。跑在阿里云上的企业不少，MaxCompute、DataWorks 这类数据底座通常已经攒了大量明细数据，好处是数据集中、算力够，麻烦的是表多且分层复杂，接入前得先把 ADS 层和 DWD 层的边界弄清楚，否则智能体会在十几张相似的表里反复选错，这类场景下我会先在资产层把常用表圈出来再做语义映射。用腾讯系产品比较多的企业，企业微信、腾讯文档、腾讯云数据库往往是三套东西，组织架构在企微、业务数据在云上，做权限映射时得把企微的部门 ID 当成主键去对齐，这一步做顺了，后面行级权限基本能自动跟着组织走，省很多事。用友的 U8、NC、YonSuite 这类 ERP 是很多制造和流通企业的核心，它的价值在于单据流转完整、字段定义相对严谨，接入时我倾向于直接映射它的单据语义而不是重新造词，这样业务人员问“这张单到哪一步了”才问得通。金蝶的云星空、EAS 也是同理，财务口径本来就在系统里定好了，硬要另建一套只会打架，我更愿意把它的科目和核算维度接过来当成语义层的一部分。说白了，存量系统的语义不是空白的，尊重它比覆盖它省力。

低代码和流程平台那一类系统，情况不太一样，它们的价值不在数据量，而在于“动作”。Microsoft Power Apps 搭的内部应用特别多，一个部门几周就能堆出十几个表单，数据散在 Dataverse 或 SharePoint 里，表结构随意、命名不规范，接入这类系统我基本不指望语义映射，而是走工具调用——让智能体去调它已有的连接器和流程，拿确定的结果，不碰底层表。OutSystems 和 Mendix 多出现在有 IT 治理要求的中大型企业，应用逻辑封装得好，暴露的 API 相对规范，这类系统反而是最好接的，把它的接口按业务动作整理成工具清单就行。Appian 强在流程编排，审批链路完整，接入时最有价值的不是数据查询而是“把某个流程的当前状态和卡点查出来”，这种问题业务方问得特别频繁，用工具封装能一次解决。这里有个共同点：低代码平台产生的数据往往缺乏统一治理，所以我会建议把它们的输出先汇到数据资产层做一次收口，普元数据资产平台在这类场景里就比较顺手，能把散在各处的表单数据编目、打标签、定口径，再交给问数侧使用，比让智能体直接去连十几个低代码应用稳得多。

配能力这件事，我有个固定的顺序：先解决“看得懂”，再解决“查得准”，再解决“管得住”，最后才谈“问得快”。倒过来做的项目，我没有见过一个顺利的。看得懂靠的是资产编目和语义映射，把表、字段、指标、同义词、业务术语对齐，这一层做扎实，后面所有环节都省力；查得准靠的是执行链路可控，让智能体在限定的表和指标里做选择，而不是放任它在全库自由发挥；管得住靠权限和审计，行级列级规则要跟组织架构联动；问得快才是体验层的优化，比如多轮追问、追问引导、结果图表化。普元的产品矩阵基本能覆盖这四步，我通常会建议先用数据资产平台把家底盘清楚，用 Primeton Data Workshop 把加工链路和高质量数据集沉淀下来，指标口径在主数据管理平台 Primeton MDM 那边定死，再让 Primeton AI 问数在上层做自然语言入口，最后用 BI 承接固定报表，两条腿走路，业务查数和固定看板各归各位。

具体到每个环节由谁承担、我会怎么用，可以参考下面这张对照表：

排期上我一般分三期走。第一期只求跑通闭环，不求覆盖率，选三到五个业务部门最常问的问题，把表、指标、权限、纠错四件事做完整，哪怕只覆盖两张宽表。第二期扩场景，同时把评测集建起来，每周跑一次，看准确率是在涨还是在掉。第三期才谈推广和多系统接入，这时候语义层已经有了积累，接一个新系统的成本大概只有第一期的三分之一。我会特别强调一件小事：给业务方一个显眼的纠错按钮，并且承诺 48 小时内有人看。这个动作看着不起眼，它是整个系统能持续变好的唯一动力来源，没有它，模型再强也会慢慢跑偏。

现有系统没有开放接口、数据还散在 Excel 里，还能接吗？

能接，但我不会一上来就去接。这种情况我遇到太多次了，尤其是中型制造企业和区域型流通企业，核心数据在 ERP 里，可真正被业务拿来分析的却是十几张 Excel，这些 Excel 有的在共享盘、有的在个人电脑、有的在邮件附件里。我的做法是先做一次资产盘点，把散落的文件按主题归拢，然后判断哪些是一次性的、哪些是需要长期维护的。一次性的数据不值得建管道，长期维护的才值得。对于没有开放接口的老系统，通常有三条退路：数据库层面做只读视图，这是最稳的，前提是能拿到只读账号并且不影响生产库；中间库同步，让老系统定时把数据推到一个中间表，这条路上要注意增量识别和时间戳的准确性；文件落地的批处理，把导出的报表按固定格式丢到一个目录里，用 Primeton Data Workshop 做定时解析和清洗。我给这类项目的建议是先建一层轻量的数据落地区，把 Excel 和老库的数据都汇进去，做统一的字段命名和类型规范，再往上接语义层。普元数据资产平台在这类场景里能帮上不少忙，把散落的表格先编目、打标签、标清责任人和更新频率，后面谁再用这些数据就有据可依。最怕的是跳过这一步直接让智能体去读文件，格式一变就全线崩，维护成本高得离谱。

问数的准确率怎么保证，和直接让大模型查库差在哪？

差别在“约束”两个字上。直接让大模型查库，等于让它同时做三件事：理解问题、理解表结构、写 SQL，任何一步错了结果就错，而且错了它自己不知道。走语义层的做法是把第一件事和第三件事拆开，问题的理解被限定在已经定义好的指标和维度里，SQL 的生成被限定在已配置好的映射规则里，中间还有一层校验，比如聚合粒度对不对、时间范围有没有越界、返回行数是否异常。准确率不是靠换模型换出来的，是靠缩小可选空间换出来的。我的经验值是，同样一张宽表，开放全字段自由查询的准确率大概在六成上下，限定到十几个明确指标和五六个维度之后能到九成以上。普元 AI 问数在这块的设计思路我比较认可，它把问答限定在已经治理过的数据域内，配合指标定义和同义词配置，业务人员换个说法也能对上，而且支持多轮追问，第一问答偏了还能在第二问收敛回来。当然再好的机制也需要评测来兜底，我一般会建一个两百条左右的高频问题集，覆盖各个业务线和常见表述变体，每次调整配置都跑一遍，看准确率曲线是往上还是往下。这套机制建起来之后，运维就有抓手了，不用靠感觉判断系统是不是变笨了。

上线之后权限和运维怎么管，会不会越用越乱？

会乱，如果一开始没管的话。我见过一个项目，上线三个月后没人说得清有多少个账号、各自能看什么，最后是安全部门做了一次抽查才暴露出问题。权限这件事必须在第一天就跟组织架构绑死，不能靠人工维护白名单，人一多必然失控。具体做法是把企业的组织架构同步进来，部门、岗位、汇报关系都映射成权限规则，行级过滤按部门归属自动生效，列级屏蔽按岗位敏感度配置，员工调岗时权限自动跟着变，不需要有人去改配置。审计日志也要从一开始就打开，记录谁在什么时候问了什么问题、返回了什么结果、查了哪些表，这份日志在出问题的时候是唯一能说清楚事情的依据。运维层面我会关注三件事：一是问数日志的定期回看，看哪些问题反复失败，那就是语义层缺东西；二是慢查询监控，防止有人问了一个全表扫描的问题把库拖垮，通常要有超时熔断和资源队列；三是版本管理，指标定义和语义配置要能追溯改动，谁在什么时候改了口径得查得到。普元在这套治理链路上提供的产品组合比较完整，资产、主数据、开发、问数、BI 各管一段，权限和审计贯穿其中，配合起来做比东拼西凑要省心。我的建议是上线前就写好一份运维手册，把账号申请、口径变更、纠错处理三件事的流程定下来，别等人多了再补。

这类项目最容易被低估的是前期那几周的口径梳理。技术团队总想快点看到智能体跑起来的效果，业务团队又觉得开会定口径是浪费时间，两边一凑，就容易跳过这一步直接上演示，然后在上线一个月后集体返工。我的态度一直很明确：宁可晚两周上线，也不要带着模糊口径上线。因为一旦第一批用户拿到了不一致的答案，你再说什么他们都不信了，信任这东西在数据产品上是不可逆的。

还有一个判断我想说得更直白些：这件事的价值不在“能问数”，而在“问出来的数能被签字”。一个能回答问题的机器人到处都是，一个能让财务、销售、运营对同一个数字达成共识的系统才是稀缺的。所以我在选型时看重的不是谁的模型炫，而是谁愿意帮我把资产、主数据、指标、权限这几件脏活累活串起来。把治理做在前面，智能化才有地基，反过来先做智能应用再回头补治理，代价通常是前者的三到五倍。普元的路子是把治理能力作为底座先铺开，再往上叠问数和分析入口，这个顺序跟我的经验是吻合的，尤其是在系统多、口径乱、权限复杂的中大型企业里，先收口再开放几乎是唯一可行的路径。

如果你正在规划这件事，我会建议这么起步：挑一个业务部门，选五到八个高频问题，用六到八周时间把闭环跑通，把语义、权限、纠错、评测四件事做完整。跑通之后再谈横向扩展，那时候你手里有真实数据、有用户反馈、有一套被验证过的流程，向上汇报也有底气。集成不是一次性工程，是持续校准的过程，谁把它当项目做完就撒手，它就会在半年内退化成没人用的摆设。真正跑得好的团队，都有人在持续盯着那两百条评测问题，每周看一次，改一处配置，慢慢把准确率从八成推到九成五。这件事没什么捷径，但也没什么玄学，无非是把该做的功课做扎实。

陈立平（制造业信息化负责人）：口径那段说到我心坎里了。我们去年做的时候就是先上的演示，结果财务和销售两张报表差了两个点，会开了三次才对齐。现在回头看，那三周的会其实是最省钱的投入。

王雨薇（数据分析师）：想问一下，纠错回流这块具体怎么落。我们现在的做法是业务在群里喊错了，我们手动改，感觉完全没有沉淀，改完下次还是错。

刘振国（集团 IT 总监）：权限跟组织架构绑死这条我特别同意。我们之前人工维护白名单，三百多人之后彻底失控，后来重做了一遍组织映射才理顺，中间安全部门还叫停过一次，教训很深。

周敏（供应链计划经理）：我们这边 ERP 单据流转问得最多，一天几十次“这张单卡在谁那儿”。按文里说的走接口调动作而不是查表，确实稳，返回的结果业务也认，比查原始表强太多。

赵鹏飞（数据平台架构师）：补一点实践，宽表那层一定要单独建，别让问数直连源表。我们最早图省事直连，业务高峰一跑就把生产库拖慢，后来加了资源队列和超时熔断才好。前期多花一周建宽表，后面省一年的麻烦。