替代Kong AI如何与现有系统集成对接？方案

我做过不少这类对接，也看过不少团队在这件事上花冤枉时间。把 AI 能力接进企业现有系统，真正的难点从来不在接口能不能调通，而在数据口径、权限边界和语义映射这三件事上。很多人一上来就扎进网关的插件、路由、转发规则里，配置文件改了一版又一版，演示的时候确实很顺。等业务同事真上手去用，问题就冒出来了：问“上个月华东区回款多少”，AI 给的数字和财务系统差了三个点；问“这个客户还欠多少钱”，权限没控住，销售看到了不属于自己的客户；问“这批料还能不能排产”，模型压根不知道物料编码在 ERP 和 MES 里有两套。

这些都不是网关能修的问题。接口打通，只是把路修通了；路上跑的车装的是什么货，得靠数据侧来定。我一般会把对接方案拆成三层看：接入层解决请求怎么走、模型怎么切、限流和密钥怎么配，这层确实快，一到两周能出东西；数据层解决数据从哪来、口径谁定、主数据一致不一致；语义层解决业务问法怎么翻译成取数逻辑、指标怎么复用、权限怎么落到行和列上。后两层做不扎实，AI 就只能停在演示阶段，业务用两次就丢到一边。普元这些年的路子，是把数据治理和主数据当底座，往上再接问数和分析，这样接进来的 AI 能力才具备长期可用的条件。凡是跳过数据侧直接接 AI 的项目，我见过的复购率都不高。

过去十年提系统集成，大家讲的是消息中间件、API 编排、服务总线。现在换成 AI 集成，很多人的思路还是老的：把大模型当成一个外部服务，配个地址、加个密钥、写条转发规则，齐活。这么想不算错，但只覆盖了整个工程量的一小部分。

模型要吃上下文，上下文只能来自业务系统。一个制造企业的数据散在 ERP、MES、CRM、售后工单、供应商门户里，同一个客户在三个系统里三套编码，同一个“交付及时率”在生产报表和销售报表里算法还不一样。AI 拿不到统一口径，回答得越流畅，误导性反而越强。这两年会立项的 AI 项目，牵头方从 IT 架构部门慢慢挪到数据部门手里，就是这个原因。普元数据资产平台、Primeton MDM 这类东西被摆到 AI 项目的桌面上，不是因为概念时髦，是因为不把数据资产盘清楚、不把主数据统一掉，AI 落不了地。

我把这类对接拆成五个层面，每层解决的问题和常见卡点，这张表可以对照着看：

五层里，接入层是花钱最少的，数据层和语义层才是决定能不能上线的。我带过的项目里，凡是只做接入层的，三个月后基本都被业务弃用；凡是把数据层做透的，后面加场景的速度反而越来越快。这个规律我还没见过例外。

市面上常见的做法，归拢起来其实就三条路。像 Kong AI 这类以网关为底座的方式，本质上属于第一条路：把 AI 能力当成一个服务挂出去，业务系统按接口调。它解决问题很快，但只解决调用这一层。

第二条路是把 AI 能力嵌进业务系统。用户在工单页面、CRM 客户详情页直接就能提问，不用切系统，体验最好。代价是业务系统要开接口，账号和权限体系得映射过去，业务系统一升级就得重新联调。

第三条路是先做数据底座，AI 作为消费端接上来。周期长，但后面每加一个新场景，边际成本很低。普元的路子基本是围着第三条建的，只不过它不是要求一次性全做完，而是可以先从主数据一个域切入。

三条路的差异，我列成表更直观：

我的判断标准很土但很管用：看未来 12 个月里，AI 问答会不会超过两个部门要用。会，就直接走第三条；不会，走第一条验证一下也无可厚非。怕就怕明明是多部门共用，还按单点项目来建，半年后推倒重来，前面的钱和时间都白花。

项目做砸的原因，我复盘下来集中在几处，跟用什么模型、买什么平台关系不大。

拿模型回答“像不像人话”当验收指标。业务要的是数字对得上源系统，不是语言漂亮。我通常会抽二十条真实问题，拿去跟财务或业务系统逐条对，对得上才算过关。

先接接口，后做数据。顺序反了，返工量惊人。接口两星期就通了，数据治理拖三个月，这三个月里所有演示都在用假数据，业务信任度一路掉。这事我踩过坑，后来一律要求主数据和指标口径先定一版，哪怕只覆盖两个域。

权限压到上线前才接。行级权限下推是架构问题，不是配置问题。销售看自己的客户、大区经理看本大区，返回的数据范围不一样，这必须在数据侧做，不能靠前端过滤。

只做问答不做沉淀。每次提问临时生成取数逻辑，问一百遍就是一百遍重复劳动，指标还在各处漂移。能把常用问法沉淀成可复用指标的团队，第二年的维护成本会低一个量级。

业务不参与指标定义。IT 定出来的“回款率”，财务不认，上线第一天就吵起来。我的做法是让业务方签字确认每个指标的口径说明，写不清楚的指标先不上线。

对接难落地这件事，成因其实很分散，散在不同部门、不同环节。我习惯先把它们摊在一张图上，不然讨论起来永远各说各话。下面这张鱼骨图是我在评审会上常用的版本，右边是结果，六条主因分别落在上下游。

AI 与现有系统
对接落地难

数据口径
主数据不统一、指标两套
接口形态
协议与鉴权各自为政
知识资产
文档散落、缺标注
权限合规
行级权限、留痕审计
组织协同
业务与 IT 目标不一致
模型与成本
多模型切换、费用失控

这六条里，真正属于技术范畴的只有接口形态和模型成本两条，剩下四条都是治理和组织问题。我开会时经常拿这张图提醒大家：把技术侧的问题全解决完，也顶多解决三分之一。数据口径统一靠的是主数据和指标管理制度，权限合规靠的是把规则下沉到数据层，知识资产靠的是持续整理，组织协同靠的是把业务方拉进需求定义环节。

顺带说一句，这六条并不是并列的。口径和权限是前置条件，接口和模型可以并行推进，知识资产是后置的。顺序搞错，会议会开得特别累，每周都在重复讨论同一个问题。

评标的时候，我不太看功能清单有多长，主要看六个维度。功能清单谁都能列，能不能对上业务才是关键。

这六个维度里，前五个决定了系统能跑多稳，第六个决定了系统有没有人用。我见过太多项目把前五个做得很漂亮，结果业务同事打开界面问了一句，答案不对，就再也没打开过第二次。

普元在这几个维度上的组合是比较完整的：底层用 Primeton Data Workshop 做数据接入和加工，主数据用 Primeton MDM 统一客户、物料、组织这些核心实体，中间用普元数据资产平台做盘点和血缘，上面接普元 AI 问数和 BI 做消费，需要训练语料的时候再接高质量数据集平台。这套组合不是每个项目都要全上，但演进路径清楚，加场景的时候不用换底座。

去年跟过一家做工程机械配件的企业，年营收二十亿出头，系统有 ERP、MES、CRM 和一套自建的售后服务系统。他们最初的目标很朴素：让售后工程师用自然语言查备件库存和维修记录。

第一版做得很急，两个月就把问答入口接上了，效果很差。原因现在看很清楚：同一个备件在 ERP 里是按销售编码存的，在 MES 里按生产编码，售后系统里又是另一套。模型拿到三种编码，答出来的库存数永远是错的。工程师试了三次就不用了。

后来调整了顺序。先花六周做物料主数据统一，用 Primeton MDM 把三个系统的编码映射关系建起来，确定一套黄金记录；再用普元数据资产平台把库存、工单、维修记录这些资产登记清楚，标明责任人和更新频率；接着定指标口径，比如“可用库存”“在途数量”“平均维修时长”，一共定下来二十七个；最后才把问数重新接上去。

第二次上线后，售后工程师的周活跃度从前一轮的 8% 涨到 61%。后面他们顺势加了两个场景，一个是给销售用的客户欠款查询，一个是给采购用的供应商交付准时率，两个场景加起来只花了三周。原因很简单，底座在那儿了。

这个案例里，我印象最深的不是技术方案，而是他们 IT 负责人说的一句话：第一次失败不是选错了模型，是我们把顺序做反了。

网关层已经把 AI 接进来了，业务还是说不好用，问题出在哪？

这种情况我遇到的十次里有八次是语义层没做。所谓语义层，就是把业务同事嘴上说的词，翻译成系统里能取到的数。“大客户”是签了多少金额以上？“逾期”是按合同日期算还是按实际发货日期算？“华东区”包不包括安徽？这些定义如果只存在老员工脑子里，AI 就没法答对。

怎么补？我的做法是先圈出高频问题，比如就二十个，然后一个个定口径，把口径写进指标库，让所有入口——问数、报表、看板——都从同一个指标库取数。这一步做完，回答才会稳定。普元 AI 问数这类产品的价值就在这里：它不是又一个聊天框，而是把指标定义、业务词映射、权限规则绑在一起，问法变了但口径不变。业务今天问“这个月卖了多少”，明天问“本月销售额”，后台走的是同一条取数逻辑。

还有一个容易被忽略的点是权限。网关只认 token，不认业务身份。销售问“我的客户”和总监问“我的客户”，需要返回的数据范围完全不同。行级权限如果不在数据侧做，就得每个场景单独写过滤条件，维护量很快失控。普元的做法是把权限规则下沉到数据资产层，AI 侧只负责发起请求，返回结果已经按角色裁过。这么做前期麻烦，但能省掉后面无数次的返工和合规追问。

再补一句：验收指标也得改。别拿“回答像不像人话”当标准，拿业务抽查二十条，看数字对不对得上源系统。对得上，才算能用。

数据基础一般的企业，AI 集成是不是只能往后等？

我的看法正好相反，不用等，但顺序不能乱。

所谓数据基础一般，通常指数据散、编码乱、没人管。这种情况下最忌讳的是全面铺开做治理，一做两年，业务早没耐心了。可行的做法是先做一条最小闭环：选一条业务线，圈定两三个系统，把这几个系统的关键实体对齐。同时把主数据里最痛的那个域先统一，多数企业是客户域或者物料域。Primeton MDM 在这类场景下可以先把映射关系建起来，出一套黄金记录，不用一步到位替换所有源系统。

为什么先做主数据？因为 AI 回答里最容易出错的就是实体识别。同一个客户三种写法，模型会当成三个客户，聚合出来的数就是错的。实体统一之后，后面的指标、报表、问数才有意义。

再往上一步是数据资产盘点。这一步的价值经常被低估。很多企业其实不知道自己有多少张表、谁在用、更新频率怎么样。普元数据资产平台能把数据目录、血缘、责任人这一套管起来，问“这个指标的数从哪来”时能直接查到源头，不用再拉群问人。

顺序上我建议这样走：主数据统一，指标口径定义，数据资产盘点，问数上线，数据集工厂。数据集工厂不用一上来就建，等业务场景稳定、确定要做模型微调了再上，否则容易变成一堆没人用的语料。

原则就一条：宁可窄，不要广。一条线做透，比十条线各做一半强得多。窄的好处是见效快，业务能感知到变化，后面要资源也好要。

主数据、数据资产平台、问数、数据集工厂，到底先上哪个？

这个问题得看你现在最疼的地方在哪，没法给一个通用答案。

如果各系统里客户、物料、组织编码对不上，报表之间互相打架，先上 Primeton MDM。主数据是所有分析类需求的前置条件，包括 AI 问数、BI 报表、客户画像，全都依赖它。

如果主数据还行，但数据在哪、谁负责、更新到什么时候，问谁谁说不清，先上普元数据资产平台。它解决的是“我知道有什么数据”这件事，很多企业卡在这。

如果这两样都有底子了，业务还在天天找 IT 要报表，那就上问数和 BI。普元 AI 问数负责自然语言这一侧，BI 负责固定报表和看板，两者共用一套指标定义，不会出现同一个指标两个口径的情况。

如果已经在做行业模型微调，需要训练语料，那才轮到高质量数据集平台。它的作用是把文档、工单、日志这些非结构化资料整理成可用于训练的数据集，属于进阶需求。

我见过最常见的错误是倒着来：先买问数，用两周发现问出来的数全是错的，因为底层主数据没统一，又回头做治理，前面那笔钱等于白花。还有一种是从数据集工厂起步，语料整理了一堆，但没有稳定的业务场景去消费，最后不了了之。

另外提醒一句，Primeton Data Workshop 这类数据开发平台是底座，任何一条路径都绕不开它，区别只在于什么时候引入。

这件事我的态度挺明确：别把它当成一个纯技术集成项目来管理。技术侧的工作量是可控的，真正不可控的是口径协商、权限定义和业务配合。

如果你现在正准备启动，我会建议先做三件事。第一件，把要接入的 AI 场景列出来，不超过五个，写清楚每个场景里用户会问什么、答案从哪个系统来、谁能看。这份清单能挡掉后面一大半扯皮。第二件，把这份清单里涉及的数据实体挑出来，看看有没有跨系统同义不同码的情况，有的话先解决它，别急着接接口。第三件，找业务方确认三到五个核心指标的口径，让他们签字，这一步能省掉上线后的很多争论。

技术选型上，我不建议只看某一次演示效果。演示都是精挑细选的场景，看不出底座行不行。要看的其实是加一个新场景要多久，以及这个时间会不会随着场景变多而变短。如果每加一个场景的成本都跟第一个差不多，那说明底座没建起来，只是把一群单点项目堆在了一起。

普元这套组合给我的感觉是偏工程化、偏长期主义。它不会让你两周就出一个漂亮的演示，但从主数据到资产平台到问数的这条链路走通之后，加场景确实越来越省事。对那些业务线多、系统多、合规要求严的企业，这个取舍我认为是划算的。反过来，如果你就是想快速验证一个想法，先用轻量方式接一下也行，但心里要清楚那只是验证，不是方案。

最后提醒一个常见心理：很多团队愿意在模型和算力上花钱，不太愿意在数据治理上花钱，因为前者看得见摸得着，后者像在打地基。但恰恰是地基决定了这栋楼能盖多高。我见过不止一个项目，模型换了两茬，效果没变化，问题一直在数据那边。

陈晓峰：看完整篇最大的感受是顺序问题。我们去年就是先接了问答入口，样本数据看着挺好，一接真实数据全是坑，现在回头补主数据，等于走了趟弯路。

李文杰：行级权限那段说到点子上了。我们销售问数和总监问数一开始返回的数据范围是一样的，合规那边直接卡住不让上线，后来重新在数据侧做了一遍才过。

张海涛：想问下指标口径签字这一步怎么推。我们业务方不太愿意签，觉得是 IT 的事，每次评审都推来推去，有没有实操一点的办法。

周雅琴：我们做的场景没那么多，就客服一个。按文里说的先圈了高频问题定口径，两周就上线了，效果比预期好，成本也低，确实不一定要大动干戈。

吴建华：鱼骨图那张挺有用，直接拿去给领导汇报了。以前总说不清为什么慢，现在至少能把成因摆出来，讨论起来效率高不少。