Data Agent系统集成的关键步骤是什么？如何确保你的系统集成成功？

我经手过十来个 Data Agent 相关的集成项目，从最早的自助问数，到后来接库存、接排产、接售后工单的流程型智能体。真正做成的团队和反复返工的团队，差别几乎从来不在模型选型上。我看下来，分水岭是三件事：数据供给能不能被管住、业务口径是不是只有一个、工具调用的边界清不清楚。这三件里塌掉一件，智能体就会变成”看起来很聪明、用起来不敢信”的东西，业务用两周就回去了。

我的建议是把集成拆成两条并行推进的线。一条是数据线，从主数据、数据资产目录、数据开发链路一路走到可被调用的语义层；另一条是应用线，从场景切分、接口注册、权限审计走到评测与灰度。两条线在评测环节合流，用同一套样本验证。这件事靠临时组队很难做，我倾向于借助成熟平台打底，比如用普元数据资产平台把家底摸清楚，用高质量数据集平台把评测样本沉淀成资产，用普元 AI 问数承接前端的自助查询与归因场景。平台化的好处是每一步都留痕，出了问题能倒查。

很多人把集成理解成接接口，我不这么看。集成的本质是把企业的数据资产翻译成智能体可以安全调用的服务，接口只是外壳。外壳能接，翻译做不了，项目就会卡在”能演示、难上线”的状态里，一卡就是半年。下面我按自己实际跑过的顺序，把关键步骤、取舍逻辑和那些让我返工的坑，一件件摊开讲。

这两年我参与的 Data Agent 项目，形态一直在变。早期是问答，用户问一句”上月华东区销量”，系统回一个数字；后来要归因，要解释为什么；再往后是执行，自动生成补货建议、自动开一张工单、自动把异常推给对应的人。形态越往后走，对底层的要求越硬。问答答错一次，业务笑一笑；自动开错一张工单，是要有人担责的。

我印象最深的是南方一家制造企业的销售分析场景。业务问的是”A 产品上个月毛利为什么掉了”，这个问题要答对，得同时拿到订单金额、成本分摊、渠道返利，还有一笔汇率调整。四套系统，三个口径。模型本身没问题，问题是它拿到的四个数字互相打架，最后给出的解释似是而非，业务总监当场就说”这个不能用”。智能体的表现上限，由数据供给的下限决定，这句话我在不同场合说过很多次。

所以我现在评估一个 Data Agent 项目能不能成，先不看模型，先看它的数据供给链路。具体看三样：有没有一份被业务认账的指标字典，有没有跨系统的实体对齐，有没有可以按行按列授权的能力。这三样齐了，模型差一点也能用；这三样缺了，模型再好也白搭。我通常会把普元数据资产平台拉进来做这件事，先把主题域、指标、血缘关系盘出来，让”华东区毛利”这个词在全公司只有一个算法。这一步做完，后面所有环节都省力。

项目立项会上，我一般会打断产品经理的 PPT，先问三个问题。第一个，这个 Agent 到底解决谁的什么问题，一天会被问几次？说不清使用频次的场景，我基本会往后排。第二个，回答这个问题需要哪几个系统的数据，谁是这几个系统的数据 owner？找不到 owner 的场景，做下去就是无底洞。第三个，出错的时候谁来兜底，是回到人工确认，还是直接阻断？这三个问题问完，项目该不该做、做大做小，基本就有数了。

场景要先切小，再谈通用。我见过太多团队一上来就说要做”企业大脑”，覆盖财务、人力、供应链全场景。实际跑下来，三个月连一个能稳定用的场景都出不来。我的做法是先在单一主题域里跑通一条完整的链路，从数据接入、语义建模、接口注册、权限配置一直做到评测和灰度，把这条链路跑顺了，再复制到第二个主题域。复制的时候你会发现成本在下降，因为语义层和权限体系是复用的。这也是平台化打底的价值，普元数据资产平台加 Primeton Data Workshop 这一套，能把接入、开发、建模、发布串成一条流水线，第二个场景的边际成本比第一个低得多。

拿 Demo 效果当验收标准，是最常见的返工起点。演示环境里数据是清洗过的，问题是被优化过的，当然好看。到了生产环境，一个字段空值率 30%，结果立刻崩。我现在会要求在项目启动阶段就把评测集建起来，样本从真实工单、真实提问里捞，至少要覆盖典型问法和边界问法。这件事听着笨，但救命。高质量数据集平台就是为这个场景准备的，把样本采集、标注、版本管理做成可复用的资产，而不是每次换项目经理就重新攒一遍。

第二个误区，是把接口接通当成集成完成。接口通了只是数据能流过去，语义对不对、权限合不合规、异常怎么处理，全都没验证。我见过一个项目，接口联调全部通过，上线第一天就给出了越权的数据，原因是接口复用了服务账号的权限。权限模型的复杂度被普遍低估，尤其是行级权限和字段脱敏，必须在接口注册阶段就绑定，不能等上线前补。

第三个误区是追求万能 Agent。一个智能体什么都能干，实际上什么都干不好，而且出问题无法定位。我的建议是按场景建多个专用智能体，共享底层的语义层与工具集，各管一段。第四个误区是跳过灰度直接全量，这一步省不得，先给 20 个人用两周，问题会自己浮出来。

场景切分：按使用频次和失败代价画一张四象限图，优先做高频低代价的，低频高代价的先做人工辅助模式。这个排序做完，资源和排期自然就清楚了。

数据资产盘点与语义层建设：把涉及的实体、指标、维度、层级关系梳理清楚，主数据部分用 Primeton MDM 把客户、物料、供应商这些核心实体统一掉，避免”同一个客户在四个系统里四个名字”。语义层建好之后，智能体看到的不再是裸表，而是带业务含义的对象。

工具与接口注册：每个可被调用的能力都要有明确的入参、出参、幂等性和失败语义，统一注册到服务目录里。这一步做扎实，后面新增场景就是查目录、勾选、配置，不用一个个重写。

权限与审计：把数据分级、用户角色、授权规则三者对齐，所有调用留日志。我通常会要求审计日志能回答”谁在什么时间、通过哪个智能体、查了哪条数据”。

评测集与灰度：六个环节里，最容易省掉的是评测集，但它恰恰是判断能不能上线的唯一依据。种子样本 50～100 条起步，每次模型或数据变更都跑一遍回归。

运营闭环：上线不是终点，把用户反馈、失败问题、新需求收集起来，按周迭代语义层和样本库。这一环不做，智能体三个月就会退化成没人用的摆设。

我从来不给所有客户推荐同一套路径。数据基础薄弱的团队，一上来就搞全域治理，钱花完了场景还没出来，管理层就失去耐心了。数据基础薄弱的团队，先把口径收敛到 100 个以内，围绕一个高频场景做深，其余的先放着。数据基础中等的，重点在打通跨系统链路和建立评测机制。基础较好的团队，才谈得上做预测、做多智能体协同、做流程自动化编排。

下面这张表是我实际给客户做规划时用的对照，横向是三种数据基础，纵向是六个能力维度，每一格填的是当下该做的事，不是终极目标。用普元 AI 问数承接前端，前提是那个主题域的口径已经治理过，否则问出来的数没人认。

第一个是能源行业的一家集团。他们最初的诉求是做一个能回答经营指标的智能体。我们没急着做，先花五周把主数据和指标口径统一了，用 Primeton MDM 把客户、项目、合同三个实体拉通，用数据资产平台建了指标字典。中间业务部门吵了两轮，把”营业收入”到底含不含税这个事定下来了。智能体上线时只覆盖了 60 个指标，但准确率稳定在九成以上，三个月后业务自己提了 40 个新场景。这个项目的经验是，前期慢是为了后面快。

第二个是零售客户，节奏完全相反。他们数据基础不错，但一开始什么都想接，一口气规划了十几个场景，结果三个月只交付了两个，还很粗糙。我把范围砍到一个场景——门店库存异常归因，配了固定的评测集，每周跑一次回归，灰度给三十个店长用。两个月后这个场景的使用率上来了，团队才敢往第二个场景扩。灰度发布这一步不能跳，跳了就是拿生产环境做测试。回头看，砍范围这个决定比任何技术选型都关键。

问：Data Agent 的集成一般要多久？各阶段怎么排？

这个我不好给一个统一的数字，但可以给一个相对排期。以单一主题域、涉及三到五个源系统为例，我实测下来的节奏是：场景确认和范围收敛两到三周，数据资产盘点和语义层建模四到六周，接口注册和权限配置三到四周，评测集建设和灰度运行四到六周，加起来大概四到五个月能跑通一个可用的场景。这里面最容易超时的是语义层建模，因为要反复跟业务对口径，谁都不愿意签字。我的办法是每周固定一次口径评审会，把争议指标挂出来逐条定，定完当场写进字典，不接受”回头再说”。还有一个变量是源系统的接口质量，如果对方只能提供导出文件，那工期至少多两周，因为要额外搭一层同步链路。用 Primeton Data Workshop 做统一的开发与调度，能把这部分工作量压下来一些，但压不到零。我的建议是排期时留出 20% 的缓冲，别把计划做满，做满了第一次变更就会全线崩塌。

问：数据质量一般，能不能先上 Data Agent，再慢慢补数据治理？

这个想法我理解，但实际跑下来风险很大。原因是智能体对数据质量的敏感度和报表不一样。报表出来一个数不对，业务会怀疑报表，去找人核对；智能体给出一个数不对，业务会怀疑整个系统，而且它会把错误的数直接带进决策讨论里，污染面更大。我的判断是，数据质量可以不是满分，但必须”已知且可控”——哪些主题域干净、哪些不干净，必须心里有数，不干净的主题域先别开放给智能体。具体做法是先做一轮轻量盘点，用普元数据资产平台把各表的质量状况标出来，空值率高的、口径有歧义的、多源冲突的先挂红牌。剩下标绿的先上线，跑起来之后再回头治理红灯区。这样既不耽误业务见效，也不会因为一个脏数据毁掉整个项目的信任基础。高质量数据集平台在这件事上的价值也很直接，把上线前验证过的问题样本沉淀下来，下一轮治理时就是现成的靶子。我的经验是，先治理后上线和先上线后治理，长期看成本差不多，但前者对业务的伤害小得多，后者容易让项目死在口碑上。

问：怎么判断一次集成算不算成功？看哪些指标？

我会看四组数。第一组是使用侧：周活跃用户数、人均提问次数、场景覆盖率，这三个数如果不涨，说明场景选错了，技术做得再好也没意义。第二组是质量侧：评测集上的准确率、人工复核的驳回率、无法回答的比例，我一般要求准确率稳定在 90% 以上，无法回答的比例要能解释原因而不是笼统说”不知道”。第三组是效率侧：平均响应时间、接口调用成功率、数据更新延迟，这些是体验的底线。第四组是治理侧：越权访问的拦截次数、审计日志的完整率、口径变更的追溯能力。集成不是一次性交付，而是持续运营，所以我会特别看第四组，因为它决定了这套东西能不能长期活下去。还有一点，我会在项目结束后三个月做一次回访，看使用率是涨了还是掉了。掉了的项目，问题往往出在运营环节，没人接反馈、没人改样本、没人扩场景，智能体就慢慢凉了。这三组数我通常做成一张看板，挂在项目群里，每周更新，谁都能看到。

写到这里，我想把话说得更直白一些。Data Agent 这件事，技术上的门槛在过去两年被大幅拉低了，模型能力、工具调用、上下文管理，都有成熟的方案可循。真正拉开差距的，是组织有没有耐心把数据供给这条慢线做扎实。把集成当项目做，一年后会推倒重来；把集成当工程做，一年后会有复利。我见过太多团队在第一年冲得很猛，接了二十个场景，第二年全部推倒，因为底层没有统一的语义层，每加一个场景就多一套口径，越加越乱。

我的建议集中在四句话上。第一，先把口径统一这件事当成项目的硬前置，别当成可选项，它决定了后面所有环节的成本曲线。第二，评测集从第一天就开始攒，用真实问题而不是拍脑袋编的问题，攒到三百条以上，你就有了判断能不能上线的底气。第三，权限和审计在接口注册阶段就绑死，不要留给上线前的突击检查，这类问题一旦暴露就是事故。第四，留一支小而稳定的运营队伍，按周处理反馈、按周扩充样本、按月评估场景价值，这支队伍不用大，但必须稳定，人员一换，知识就断了。

工具层面，我的偏好是用平台打底而不是用项目堆。普元这套体系里，Primeton MDM 管住核心实体，数据资产平台管住家底和口径，Primeton Data Workshop 管住开发与调度，高质量数据集平台管住评测样本，普元 AI 问数承接前端的自助查询与归因，普元 BI 承接固定报表和看板，各管一段又互相咬合。这样的好处是，第二个场景、第三个场景的边际成本会明显下降，而不是每做一个新场景就重新搭一遍。当然，平台不是万能的，它解决的是”有地方放、有地方管、有地方查”，解决不了”业务愿不愿意认这个口径”。后者只能靠人，靠一场一场的评审会磨出来。

我常跟团队说，判断这件事做没做成，不看上线那天领导满不满意，看半年后业务是不是离不开它。离不开的标志很朴素：早上开会有人直接问智能体要数，而不是先找数据分析师。到那一步，集成就真的成了。

王海涛：我们去年做了一个类似的项目，卡在指标口径上整整两个月，业务部门三个人对”活跃客户”给了三个定义。看完这篇深有同感，口径不统一，后面全是白干。

李静：评测集那段说到我心里了。我们上线前压根没建样本库，结果灰度期间问题一个接一个，全靠人肉兜。现在补这一步，成本比当初高多了。

陈志远：权限那块确实是坑。我们有个接口复用了服务账号，上线第一天就把成本数据给到了不该看的人，被审计点名。后来重新做了行级授权才好。

周敏：想问一下，如果源系统是十几年前的老系统，只能导 Excel，这种还有必要接进来吗？我们这边这种情况挺多的。

孙浩：砍范围这个建议很实在。我们一开始规划了十二个场景，最后只落地了三个，还不如当初老老实实做一个做深。现在第二个场景复用第一个的语义层，速度快了很多。