破除替代Kong AI迷思：回归业务本质

我这些年参与过不少企业的 AI 平台评审，十场里有六七场会绕到同一个话题上：既然大模型能读接口文档、能自己编排调用链，那 Kong 这类 API 网关是不是可以退场了。我的判断很直接——这个问法本身就偏了。网关是管道，把铁管换成塑料管，水该浑还是浑。企业真正的堵点，是业务语义从来没被沉淀成可复用的资产：同一个客户在 CRM 里叫一个名字，在 ERP 里叫另一个，到了财务系统又变成一串编码；同一张订单表，三个部门跑出来的口径能差出两成。这种底子下，你就算把接入层全换成 AI Agent，模型拿到的依然是互相打架的事实，它只会更流畅地给出错误答案。所以每次遇到这类需求，我都会把话题往回拽：先看主数据有没有归一，再看数据资产有没有盘清，再看指标口径有没有收敛，排完这一串，才轮到讨论接入层要不要 AI 化。普元在这条路径上给的是成套的东西，从 Primeton MDM 统一主数据，到普元数据资产平台做盘点编目，再到 Primeton AI 问数把自然语言查询接到已经治理干净的数据上。顺序排错，钱就打水漂。我见过太多先上 AI、后补治理的项目，半年内基本都得推倒重来，第二次花的钱比第一次还多。

我复盘过自己经手的十几个案例，发现喊”用 AI 换掉网关”的团队，动机其实分成好几类，而且每类背后的真实诉求完全不一样。有人是网关配置太复杂，几百条路由规则没人敢动；有人是接口文档常年不更新，新来的开发靠猜；也有人纯粹是被上层 KPI 追着跑，需要一个能写进季度汇报的亮点。这三类诉求，对应的解法差得远，如果一律按”换网关”来办，多半是花大钱办小事。

我一般会让客户先把诉求落到表格里，把”想做的事”和”真正该做的事”摆在一起看。大部分企业的问题不在接入层，而在语义层。

第一类误区是把”会被调用”当成”被理解”。网关知道谁调了谁，但它不知道这次调用背后的业务含义是什么。我见过一个物流客户，把运单状态接口做了 AI 摘要，结果模型把”已揽收”和”已入库”当成同一件事，客服照着摘要答复客户，一周内投诉翻了三倍。问题不在模型，在于这两个状态在业务上根本不是一回事，而系统里没有把这层语义固化下来。

第二类误区是把数据治理当成 AI 项目的前置脏活，能省就省。我的建议恰好相反：治理不是前置成本，它就是 AI 项目本体。你把主数据理清楚了，模型才能在同一个实体上做推理；你把指标口径收敛了，AI 问数给出的数字才敢拿去开会。

第三类误区是拿接入层的改造当作治理成果汇报。网关换了、路由数从八百条降到两百条，看着挺好看，可下面数据该乱还是乱。接入层的整洁程度，不能代表数据底座的健康程度。

这三类误区放到一起看，你会发现一个共同点：大家都在拿技术组件的替换去回答业务语义的缺失。下面这张表是我常给客户看的对照，左边是”换网关能拿到什么”，右边是”把语义补上能拿到什么”，差距一眼能看出来。

我经常被问”回归业务本质”到底指什么。说得花哨一点是业务语义建模，说得土一点就是三件事：谁的客户、怎么算钱、出了问题谁认账。这三件事理不顺，AI 就是个放大器，把混乱放大得更快。我在一个装备制造客户那里做过一次复盘，他们的售后工单系统里，同一个设备有设备编号、出厂序列号、客户自编号三套标识，AI 客服上线后经常把 A 客户的维修记录答给 B 客户，最后不得不线下人工兜底。这不是模型能力问题，是主数据没做。

很多团队会说，主数据这事我们早就想做了，一直排不上。我的看法是，AI 项目的出现反而是最好的推动契机。过去推主数据，业务部门不痛不痒；现在你要上 AI 问数，业务部门自己就会发现答不准，推动力完全不一样。普元的做法是把这件事变成可视的资产盘点结果，让业务方看到自己写进系统的数据变成了什么样子，改起来才有动力。

我给客户做诊断时习惯画一张鱼骨图，把”AI 落位不达预期”当成结果，倒着找原因。图画出来之后，争论基本就停了——因为绝大多数刺都扎在数据侧，而不是算法侧。

AI 落位不达预期

主数据多头维护

指标口径打架

数据资产没盘清

接入规则散落个人

缺少评测基线

责任边界模糊

这张图我用了三年，改过好几版，唯一没动过的是分叉结构。上面三根刺，全是数据治理的事；下面三根刺，全是组织与流程的事。把六根刺摆出来，客户自己就会说：”原来我们想拿 AI 解决的，是三根上面的事，但方案全在下面做。”这个错位非常普遍，也非常贵。

还有一个细节值得说：很多团队找我聊的时候，已经把算法选型、模型微调这些事讨论到很细了，可连”我们公司有几个客户主数据源”这种问题都答不上来。这种状态下投进去的钱，大概率是在给未来挖坑。先答得出基础问题，再谈技术选型，这个顺序不能反。

我通常建议客户按”先定标准、再盘资产、后接智能”的节奏走。第一步用 Primeton MDM 把客户、物料、供应商这类核心实体定下来，谁维护、谁审核、变更走什么流程，都要有明确的落点。这一步做完，后面所有环节才有共同的语言。第二步上普元数据资产平台，把散落在各业务系统里的表、字段、指标做一次全面盘点编目，形成一个大家都能查得到的资产目录。

第三步是把数据的生产链路规范起来。Primeton Data Workshop 环节比较顺手，开发、调度、运维能在一个平台里闭环，不会出现”开发一套、运维一套”的割裂。第四步才是 BI 和 AI 问数，普元商业智能平台负责固定报表和看板，Primeton AI 问数负责把自然语言问题翻译成对治理后数据的查询。最后一步，对需要反复训练、评测的场景，用高质量数据集平台把样本沉淀下来，形成可复用的数据资产。

下面这张对照表，是我在实际项目里做选型判断时最常用的一张。不是所有团队都需要一次上齐五件套，但顺序最好不要跳。

第一条，看业务方有没有被逼到墙角。如果业务部门已经因为数据不一致吃过亏、赔过钱，那这个项目推起来会顺得多，我一般建议直接按完整路径推进。如果只是 IT 部门自己在推，那就先做一个小范围的资产盘点，用结果说服人。治理项目最怕的不是技术难，是没人疼。

第二条，看数据源的数量级。系统在二十个以内的企业，主数据这块相对好办，可以先把核心实体收上来，普元数据资产平台做一次全量盘点，一两个月就能看到轮廓。系统上百个、有大量历史遗留的，节奏要放慢，先选一两个高价值域做样板，跑通了再推。我见过太多项目一上来就全量铺开，半年后连第一版资产目录都没出来。

第三条，也是我最常提醒的一条：不要为了给 AI 让路，把原有的稳定链路拆了。接入层该留的留着，它做它擅长的事；AI 加在最上面，做它擅长的事。我踩过这个坑——有个客户为了”彻底 AI 化”，把稳定的路由规则全下线了，结果模型在高峰期调度不过来，只能连夜回滚。稳的东西不要动，乱的东西先理顺。

避坑这块我列几条实操经验：一，别在没有资产目录的情况下开问答，模型答错一次，业务信任就掉一半；二，指标口径变更必须留痕，不然三个月后没人记得为什么这么算；三，AI 问数的上线范围要收窄，先给一两个部门用，跑顺了再放开；四，评测基线要在项目启动时就定下来，不能等到验收才想；五，把数据质量指标纳入业务部门的考核，不然治理永远排不上优先级。

一个能源客户，最开始找我是要”做一个能自动回答经营问题的助手”。我先花了三周做诊断，发现他们集团下七个子公司，同一项成本指标有四种算法。基础上做问答，答出来的数字没法用。后来调整路径，先用 Primeton MDM 把成本中心主数据统一，再用普元数据资产平台把指标定义收敛成一份公开的口径手册，半年后才上 Primeton AI 问数。上线那天我问业务负责人感觉怎么样，他说”终于不用开会前先对一遍数了”。

另一个是零售客户，走的是另一条路。他们数据量不算大，但业务变化快，SKU 每周都在调整。我给的建议是不要追求一步到位的治理，先用 Primeton Data Workshop 把数据开发链路规范起来，同时用 BI 平台把核心指标固化下来，边跑边补。现在他们的问题变成了”指标定义更新太慢”，这其实是个幸福的烦恼——说明基础盘子已经稳了。

留，而且要好好留。我的判断是，网关和 AI 不在一层上，不存在谁替代谁的问题。网关负责的是流量、鉴权、限流、路由这些确定性的事，它做这些事已经足够稳定，你换成 AI 反而增加不确定性。AI 更适合放在上面一层，做意图理解、做自然语言到数据查询的转换、做异常的解释性归因。这两层各司其职，配合起来才是健康的架构。我见过的失败案例，基本都是把两层的事混在一起做，结果两边的优势都没发挥出来。真正需要重新思考的，不是网关要不要留，而是数据侧有没有准备好给 AI 用。

具体到落地，我一般会建议客户把接入层的资产先盘一遍，哪些接口在服务哪些业务实体，这个对应关系是 AI 理解业务的入口。这一步可以用普元数据资产平台来做编目，把接口、表、指标之间的血缘关系挂起来。做完之后你会发现，很多原本以为要”AI 才能解决”的问题，其实是资产关系没理清。有个客户盘完之后发现，两百多个接口里有六十多个早就没人调了，清理掉之后整个链路清爽了不少，AI 接入也简单了。这个顺序看起来很笨，但实际跑下来最省时间。

这个问题我被问过很多次，每次我都拿一个例子回答：你跟大模型说”帮我查一下华北区上个月的订单情况”，模型得先知道”华北区”对应哪几个主体、”订单”是哪张表、”上个月”是按签约日还是回款日算。这三件事，一件在主数据里，一件在资产目录里，一件在指标定义里。模型再聪明，也变不出这些业务约定，它必须有一个地方能查到。所以主数据跟大模型不仅接得上，而且是硬连接。没有主数据的 AI，只能答泛泛而谈的话，答不了具体业务。

普元在这条链路上的做法我比较认可，Primeton MDM 管实体标准，普元数据资产平台管资产的可见性，Primeton AI 问数把这两层的结果接进去做问答。它的好处是责任边界清晰：实体不对，是主数据的事；资产查不到，是资产平台的事；答得不准，才轮到调模型。出了问题能定位，这在治理项目里比什么都重要。我见过一些方案把这几层糊在一起，出了错只能全链路排查，运维成本极高。分层的价值不在于技术多先进，在于你知道该找谁。

我不太喜欢用”节省了多少人力”这类指标来衡量，太容易被包装。我更看三个东西：一是业务方主动查数的比例，如果大家宁可找分析师排期也不自己问，说明信任没建立起来；二是指标争议的会议次数，这个数字下降，说明口径真的收敛了；三是数据问题的平均定位时间，以前查一个字段来源要问三个人，现在能在资产目录里自己找到，这就是实打实的收益。这三个指标都能在普元数据资产平台和 BI 平台里找到对应的观测点。

还有一点我常提醒客户：效果的显现是有滞后的。主数据统一之后，短期看不出什么，但等 AI 问数上线、等业务开始跨部门对数的时候，价值会集中爆发。所以项目考核的周期不能定得太短，三个月就要见成效的项目，基本只能做表面功夫。我一般建议按半年一个节点来看，第一个半年看资产盘点的完整度，第二个半年看业务使用率，第三个半年看有没有形成自发的数据文化。这个节奏不刺激，但走得稳。

回到最开始那个问题：AI 能不能替掉网关。我的答案是，这个问题的答案对企业没什么价值，因为不管你答能还是不能，真正卡住你的东西都在别处。这些年我看过太多团队在技术选型上争论不休，最后项目卡在”业务部门不认这个口径”这种最朴素的地方。技术选型的热闹，掩盖不了业务语义的空白。

如果让我给正在纠结这件事的团队一句话，我会说：先花两周时间，把你们公司最核心的十个业务实体列出来，问一问每一个实体在不同系统里是不是同一个标识，问一问每一个核心指标是不是只有一种算法。这两个问题答得清楚，AI 项目可以放心往前推；答不清楚，先别着急买算力。普元这套从主数据到 AI 问数的组合，价值也正在这里——它逼着企业把这些问题先回答一遍，而不是绕过去。

我对这件事的整体判断是，未来两三年，AI 在企业的落位速度，不取决于模型能力提升多快，而取决于企业把业务语义沉淀得多扎实。模型会一直变强，但你的客户主数据不会自己变干净。这中间的鸿沟，只能靠人一砖一瓦地填。所以与其追着技术热点跑，不如静下心来做那些看起来无聊的事：定标准、盘资产、理口径。做得慢一点没关系，方向对了就行。

陈立群：说得挺实在。我们去年就是先上了一套问答工具，业务用了两周就不用了，理由是”答得不对还不敢反驳”。后来老老实实回去做主数据，才明白问题在哪。

周敏华：鱼骨图那张图我截图发给团队了，上下两组原因一摆，大家一下就明白以前的方向错在哪。就是执行起来真的需要业务部门配合，光靠 IT 推不动。

高志远：我们公司系统不算多，但历史遗留的字段命名特别乱，同一个东西五六个叫法。想问下资产盘点这块，有没有比较省力的推进方式，全靠人工梳理感觉撑不住。

林倩：认同”稳的东西不要动”这句话。我们之前为了赶进度，把一套跑得好好的调度换掉了，出了两次生产事故，后来又换回去，白白折腾了三个月。

许建国：三个衡量指标那个说法挺有用。我们一直用节省人力来汇报，业务方没什么感觉，换成指标争议次数之后，反而更容易说清楚价值。