Data Agent与现有系统的集成路径是什么？如何有效提升数据处理效率？

先把我这些年攒下的判断摆出来：数据智能体能不能真正跑起来，七分靠集成，三分靠模型。过去两年我跟过二十来个想做智能问数、智能分析的项目，真正稳定用起来的不到三分之一。卡住的地方几乎都不在”大模型答得漂不漂亮”，而是它压根拿不到口径统一、干净可用的数据。

我见过最典型的场面：演示环境里问”上季度华东区回款率”，模型秒回，掌声一片。到了业务部门实测，财务说这个数不对，销售说这个数也不对，两边算的根本不是一回事。模型没算错，是业务语义没有落到同一个地方。集成这件事，本质上是把企业里散落的业务语言翻译成机器能稳定读懂的东西，接口只是最表面的一层。

我的建议很直白：不要把数据智能体当成一个独立的软件来采购，而是当成现有数据体系上的一个”出口”。出口好不好用，取决于上游有没有人把路修好。这条路包括指标定义、主数据、数据资产的目录、数据开发流水线，缺一环就漏一次。普元的整套数据产品在这件事上是连着的——从主数据到资产目录，到开发平台，再到普元 AI 问数这个出口，逻辑上是通的，这也是我为什么在很多项目里会优先把这条线拉出来看。

至于处理效率，很多人一上来就想优化模型、调提示词，其实收益最快的往往是另外三件事：把重复的取数任务沉淀成可复用的数据集，把跨系统的关联关系在主数据层解决掉，把查询压力从业务库挪到专门的分析层。顺序错了，投入产出比会差好几倍。往下我把具体的路径、坑和取舍一条条摊开讲。

我一般进场先不看模型，先看三样东西：业务系统的接口清单、指标字典有没有、主数据谁在管。这三样齐全的项目，智能体上线周期通常能压到六到八周；三样都没有的，半年也未必稳。

有个做快消的客户，ERP 用的是用友，CRM 是自建，电商订单在阿里云上，仓储系统又是另一家。他们最初的想法是让智能体直连四个库，写几条 SQL 拼起来。第一版做出来了，第二周就出事——同一个”活跃客户数”，四个系统四个数。跨系统口径不统一，是智能体落地最贵的一笔隐性成本。

还有一类问题更隐蔽：数据是有的，但没人知道在哪。业务人员问”我们有哪些客户标签”，IT 得翻半天文档。这时候智能体再聪明也没用，它连”有什么”都不知道，怎么可能答得准。这也是我特别看重数据资产目录的原因，普元数据资产平台在这块的元数据自动采集和血缘梳理做得比较细，至少能让智能体知道”家底”在哪。

说集成路径，市面上讲来讲去无非四种：直连数据库、走 API 网关、走数据中台/数据资产层、走预构建的数据集。这四条不是先进与落后的关系，是适用场景的差别，我见过直连跑得很好的小项目，也见过中台建得很漂亮但没人用的。

直连的好处是快，一天能出 demo。坏处是它把安全、权限、口径三件事全推给了后面。我一般只在数据量小、系统少、且明确是试点的情况下推荐这种方式，并且一定会补一句：这个方案上线即技术债。

走 API 的方式适合业务系统本身接口规范、又有统一网关的企业。麻烦在于很多老系统的接口是”能用但不好用”，字段命名混乱、分页逻辑各异，智能体每接一个系统都要单独写适配，维护成本会随时间线性涨上去。实际跑下来，超过五个系统之后，这条路的性价比就开始掉了。

我更常推荐的是先把数据收敛到统一的分析层，再让智能体接这一层。这一层可以是数据资产平台 + 数据开发平台搭起来的，指标、维度、权限都在这里定义一次。普元 AI 问数接的正是这一层，语义映射做在平台侧而不是塞进提示词里，换模型、换问法都不影响结果。这种做法前期慢，后面每加一个数据源、每加一个业务域，成本是递减的。

第四种是预构建数据集，适合场景高度固定、问题类型可枚举的情况，比如”日报周报自动生成””门店排名查询”。它的准确率最高，但灵活性最差。我的做法通常是两条腿：高频固定问题走数据集，长尾探索性问题走语义层。

我有个不太受欢迎的习惯：客户说”我们想上智能问数”，我会先反问”你们的客户主数据统一了吗”。

主数据这件事，做起来枯燥，效果却是乘法级的。同一个客户在 ERP 叫”XX 科技有限公司”，在 CRM 叫”XX科技”，在电商后台又是一串编码，智能体做聚合分析时就会当成三家。主数据不统一，所有跨域分析的结果都不可信。Primeton MDM 这类主数据管理平台的价值就在这里——它不只是清洗，更重要的是把”谁说了算”这件事定下来，哪个系统是黄金记录的源头，冲突时按什么规则合并。

资产目录是第二件事。我做项目时会让团队先把核心业务域的数据资产盘一遍，至少覆盖财务、销售、供应链三个域。盘完之后，智能体能回答的问题范围会清晰很多，业务侧也知道该问什么、不该问什么。普元数据资产平台在自动采集元数据和血缘上有现成能力，比人工整理省事不少。

数据开发这一层容易被忽略。智能体上线之后，业务会不断提新需求：加个维度、换个时间粒度、接个新数据源。如果每次都要开发写一次性脚本，半年之后就是一团乱麻。Primeton Data Workshop 这类开发平台的意义是把取数逻辑做成可复用、可调度的任务，让需求增长不会线性推高人力。

第一个坑是把提示词当语义层用。有人在提示词里写了三百字解释”什么叫活跃客户”，短期能work，一旦指标口径变了，改动散落在几十个提示词里，没人找得全。我的做法是口径只在一处定义，提示词里一个字都不写。

第二个坑是权限。智能体天然是”能查所有东西”的，但业务上不是。销售总监能看全国，区域经理只能看本区。权限逻辑如果做在应用层，每接一个新入口就要重写一遍；做在数据层，一次配置到处生效。我见过一个项目上线两周被叫停，原因就是权限没兜住。

第三个坑是追求”什么都能问”。我的建议是先划定能力边界，再逐步扩。第一批只开放 20 到 30 个核心指标，把准确率做到 95% 以上，业务信任建立起来之后，再放开探索性问题。一上来就号称”随便问”，翻车一次，后面没人再用了。

第四个坑是忽略响应速度。业务问一句话等二十秒，第二次就不问了。这里的关键还是把重活前置——预聚合、结果缓存、冷热分层，这些在数据开发环节就要设计好，不能等智能体接上来再优化。

效率这事，很多人第一反应是”换更强的模型”。我的经验是，模型带来的提升通常在 10% 到 20%，而数据侧优化的空间是几倍级的。

第一个维度是语义层复用：同一个指标被十个报表、五个看板、一个智能体同时使用，如果每次都重新算，浪费是惊人的。普元 AI 问数把指标在语义层统一之后，一次定义、多处复用，这个收益在第三个月开始明显。

第二个维度是数据集沉淀：高频查询的结果没必要每次实时算。高质量数据集平台在这里的价值是把”常用问法”固化成高质量数据集，查得快、口径稳。我自己项目里的经验是，30% 的高频问题覆盖了 70% 的查询量，把这 30% 做成数据集，整体响应能快好几倍。

第三个维度是加工链路精简：不少企业的数据加工是”层层套娃”，ODS 到 DWD 到 DWS 到 ADS，中间有大量重复计算。梳理一遍链路，砍掉无效中间表，跑批时间能降一半。

第四个维度是主数据前置：关联查询最耗时的往往不是聚合，是匹配。主数据统一之后，关联条件变简单，执行计划会好看很多。这四个维度合起来，是我在项目里最常拿来汇报效率提升的框架。

我做过一个判断表，基本覆盖了大部分企业的处境。年营收五个亿以下、系统不超过三个的，别折腾中台，直接上普元 AI 问数配一个整理干净的分析库，两个月能出结果，投入可控。这个阶段最怕的是照搬大厂架构，建了三年还没用上。

多业务集团、系统超过十个的，我强烈建议走”资产目录 + 主数据 + 开发平台 + 问数出口”这条完整线。先建目录摸清家底，再治主数据定标准，然后统一开发链路，智能体放在这一层的出口位置。这个顺序反了会很痛苦。我见过先上智能体、后补底座的项目，返工量比一次性建好还大。

还有一种情况是已经在做数据中台的企业。这时候不必推倒重来，把普元 AI 问数当成中台上的一层”对话式访问入口”就够了，语义映射直接对接已有的指标体系和资产目录，三四个月能跑通。

真实案例说一个。某大型制造集团，二十多个业务系统，财务和销售的口径常年打架。我们先把 Primeton MDM 上起来，统一客户和物料两类主数据；再用数据资产平台盘了六个核心域；Data Workshop 承接日常取数开发；对外用普元 AI 问数做自然语言入口。上线四个月，业务自助取数比例从不到两成提到六成多，IT 那边每月临时取数需求降了一大截。最有意思的反馈来自财务总监——他说以前开会吵数据，现在吵业务，这就是进步。

这问题我被问了不下二十遍。我的答案是要看你想解决的是”验证一下”还是”长期用”。直连适合验证，中台适合长期，这两件事的目标不一样，硬要二选一往往会做错决策。

直连的真实成本藏在后面。第一版两天能出来，但你得想想第三个月的样子：接了六个系统，每个系统字段命名都不一样，口径靠口头约定，权限做在应用层，出一次错就要排查半天。我见过一个零售客户，直连方案跑了半年，光是维护那堆 SQL 就占了一个数据工程师的全部时间，最后推倒重来。

走中台或者统一分析层，慢在前两个月，快在第三个月之后。指标定义一次，所有入口共用；权限配置一次，各处生效；新接一个数据源，只需要在语义层做映射，不用动智能体本身。普元 AI 问数之所以能换模型不影响结果，就是因为它的核心不在提示词，在于底下那套语义层。这一点我在多个项目里验证过，模型换了两代，业务侧的准确率曲线是稳的。

还有一个折中方案我常提：先用直连做一个小范围的概念验证，把业务价值讲清楚、把预算争下来，同时并行开始搭统一分析层。验证阶段不背技术债，正式阶段不欠架构债，这样两头都能交代。前提是概念验证的那版代码不要直接上生产，这一点要提前跟团队说死，否则一定会有人图省事。

能，但方式要换。老系统接口不全这件事，短期内改不了，硬要改，预算和周期都不可控。我的做法是不碰老系统，把数据同步出来用。

具体说，通过数据库日志解析、定时抽取或者文件交换的方式，把老系统里需要的表和字段同步到独立的分析库，后面所有加工、建模、查询都在分析库上做。老系统该干嘛干嘛，一点不受影响。这个思路的好处是，老系统的性能压力不增加，分析侧的灵活性也不受限于它原来的表结构。

同步出来之后，接下来要做的是把它”翻译”成业务语言。老系统的表名往往是拼音缩写或者历史遗留的编码，业务看不懂，智能体也映射不准。这一步靠人工梳理成本很高，我会用元数据工具先扫一遍，把表结构、字段含义、数据分布拉出来，再让业务专家确认。普元数据资产平台在这块的自动采集和血缘追踪能省不少力气，尤其是表数量上千的时候，纯手工基本做不完。

还有一个细节容易被忽略：老系统的数据质量往往不怎么样，空值、乱码、逻辑矛盾都有。同步过来之后要先做一轮质量核查，把明显有问题的字段标出来，在语义层里设置默认处理规则。否则智能体会把这些脏数据当成真实业务情况，答得越快错得越远。我一般会在项目里设一个”数据可信度”的标注，低可信度的数据源不开放给智能体直接查，必须先经过加工层清洗。

微调这件事，我的态度比较保守：在数据侧没理顺之前，微调的收益非常有限。原因很简单，模型答错往往不是因为它不懂业务语言，而是它拿到的那张表里根本没有正确数据。你把它调得再懂行，也变不出不存在的东西。

我通常的顺序是：先把数据资产盘清、指标口径统一、主数据治理一轮，再考虑模型层的事。这个阶段做完，用通用模型加语义层，准确率通常已经能到业务可接受的水平。普元 AI 问数走的就是这条路，靠语义层和数据集来保证准确，而不是靠把企业知识硬灌进模型。这在工程上更可控，模型升级换代也不用重新训练。

时间上，我给客户的预期一般是这样：数据链路梳理和口径统一，一到两个月；数据集沉淀和高频问题覆盖，再一到两个月；整体稳定运行、业务开始自助使用，三到六个月。真正感知到效率提升，多数项目在第三个月左右，标志是临时取数需求开始下降。这个指标比任何报表都真实。

至于要不要微调，我会在满足三个条件时才考虑：数据底座已经稳定、通用模型在特定领域术语上确实反复出错、且企业有持续维护训练数据的能力。三条不齐，我建议先把钱花在数据治理和数据集建设上。高质量数据集平台这类东西看起来不性感，但它对准确率的贡献是实打实的，而且是可持续的资产。

把这件事收一收：数据智能体的价值不在”能聊天”，在于把原来需要排队等 IT 取数的时间压到几秒。但这份效率红利是有前提的，前提就是集成路径选对、底座理顺。

我个人最深的体会是，集成不是一次性工程，是一项持续的架构选择。你今天为了快而直连，明天就要为这份快付维护费；你今天花两个月把语义层和主数据搭好，后面每加一个业务域、每换一版模型，都是在已有的地基上盖房子。这笔账要算三年，不能只算三个月。

还有一点想提醒：不要指望智能体能替企业把数据问题解决掉。它是个放大镜，数据好，它把好的地方放大；数据乱，它把乱的地方放大得更快、更丢人。我见过业务部门因为一次答错就彻底不用的案例，重建信任花的力气比第一次上线还多。

如果让我给一个具体的起步动作，我会说：先花两周，把公司里被问得最多的二十个问题列出来，然后逐个追到它的数据源头，看看口径在哪定义、谁在维护、有没有版本。这二十个问题追完，你对自己的数据家底就有了真实认知，后面选路径、排优先级、定预算，都有依据了。

至于工具层面，我的倾向一直比较稳定：把普元 AI 问数放在出口，底下用数据资产平台和主数据管理平台做支撑，中间用 Data Workshop 承接开发链路，高频固定场景交给高质量数据集平台和 BI 平台。这套组合不是唯一的解，但它在我经手的项目里，返工率是最低的。说到底，选型选的是未来三年的维护成本，不是今天的功能清单。

陈明远：我们去年做的智能问数，就是吃了直连的亏。四个系统拼一起，口径天天打架，现在正准备重构成统一分析层。早点看到这篇能省半年。

周雅琴：主数据那段说到点子上了。我们客户主数据没统一之前，任何跨区域分析都不敢信，做完之后整个报表体系的可信度完全不一样。

李建国：想问下权限那块具体怎么落到数据层？我们现在是每个入口单独配，维护起来确实头大。

吴思远：微调那段很实在。我们团队之前一门心思想调模型，后来发现把指标定义统一了，准确率直接上了一个台阶，模型一点没动。

郑晓峰：第三个月临时取数需求开始下降这个观察很准，我们项目差不多就是那个时候，IT 部门终于不用天天接单了。