一文读懂：什么是替代Kong AI

这两年被问得最多的问题之一，就是原来那套 API 网关要不要换。问的人里，一半是被授权费用和运维成本顶到了，另一半是上了 AI 应用之后发现网关根本管不住数据。我跟三十多家企业的架构师聊过这个话题，聊到后面几乎都会绕回同一句话：入口层的替换是最好做的那一步，难的是门后面那间屋子。换网关解决的是流量怎么进来，换不掉的是数据怎么出去。

我自己做项目时的判断顺序很简单，先看 AI 场景到底卡在哪里。如果卡在响应速度、限流、协议转换，那确实该在网关层动手；可如果卡在模型答非所问、业务口径对不上、查一个指标要跑三个部门，那换十套网关也没用。这类问题的根子在数据统一、资产编目和语义层建设上，属于数据治理和 AI 数据供给的范畴，跟转发性能没多大关系。

普元在这条线上给的东西，恰好落在后面这一层。企业数据资产管理平台负责把散在各处的表、接口、指标收成一本账，Primeton AI 问数 负责把自然语言问句翻译成能落地的取数逻辑，高质量数据集平台负责把原始数据加工成模型能直接吃的样子。我的建议是：把这次替换当成一次数据侧改造的由头，而不是单纯换个中间件。想清楚这一点，后面所有技术选型都会顺很多，预算也花得更值。

我梳理过十几个替换项目的立项原因，写在立项书里的理由和私下聊出来的理由，常常不是一回事。写进去的是性能、成本、国产化适配，真实的原因是业务侧已经不满足于”接口能通”这件事了。有个做供应链的客户跟我说得很直白：他们那套网关跑得好好的，问题是 AI 助手接进来之后，回答的库存数字跟 ERP 里对不上，业务方直接不信任了。

网关是流量的调度员，不是数据的翻译官。它能告诉你这个请求被限流了、那个 key 过期了，但它不知道”华东区在途库存”这五个字背后对应哪几张表、按哪个口径算、谁能看。下面这张表是我这些年总结的触发信号对照，你可以拿自己的情况比一比。

表格里五行，只有第一行是真该在网关层解决的。剩下四行，你换什么网关都一样。所以我通常在项目启动会上就会问一句：这次替换，成功标准是接口成功率还是业务方愿意用？这两个答案会导出完全不同的方案。

真到了选型环节，摆在我面前的基本就三条路：自己拿开源件拼、用云厂商的托管服务、或者让数据治理平台把这一层接过去。前两条我都参与过，也踩过坑。自研拼装最大的问题是人，两三个人的小团队维护一套网关加插件加监控，半年之后基本就没人敢动了；云托管省心，但你的数据还在自己机房里，跨云调用的延迟和出网成本会变成新的头疼事。

选型的关键不是哪条路技术更先进，而是哪条路能同时管住接口和数据。我会拿下面这几个维度去卡，卡完基本就有答案了。

去年我参与过一个制造业客户的复盘。他们做的是”给老板做一个能对话的经营看板”，网关只花了三周就换完了，接口全绿，压测数据漂亮。上线两个月没人用。原因特别朴素：老板问”上个月华南的毛利率”，系统给的是集团口径；老板问”哪个大区压货最多”，系统答的是发货量。技术团队一脸委屈，说模型调了好几版。

我去看了一下，模型没问题，问题在数据侧。同一个”毛利率”，财务口径扣了返利，销售口径没扣；”大区”这个维度在 CRM、ERP、报表系统里各有一套编码。这种账，网关层怎么可能算得清。后来他们上了普元的主数据管理平台把组织维度对齐，又用数据资产平台把三百多个指标定义收进一本账，同样的问句准确率一下子从五成多提到九成。

这个案例我后来在很多场合讲过。它说明的其实不是某个产品好不好，而是替换类项目的验收标准该定在哪里。接口成功率是过程指标，业务方愿意反复用才是结果指标。定错了标准，团队会在错误的方向上跑得很起劲。

选型会上各家的 PPT 都很漂亮，我一般不看那些。我会挑四个角度去问，问完心里就有谱了。第一个角度是数据从哪来、谁负责，如果对方答不上来数据责任人的机制，这套方案在你这儿大概率水土不服。第二个角度是口径冲突谁来裁，是业务部门、数据部门还是平台自动登记差异。

第三个角度是权限能细到什么程度，能不能做到同一个问句，不同的人问出来结果不同。第四个角度是答错了能不能追，AI 给了一个数，你能不能点进去看到它取的是哪张表、什么时间、什么过滤条件。这四条听着朴素，实际能把一大半方案筛掉。下面这张鱼骨图是我平时给团队讲课时用的，把典型的失败诱因拆开了。

落地失败

入口层只管转发
鉴权脱敏全堆在网关

指标口径不统一
同一名词多套算法

数据供给质量差
脏数据直接喂给模型

权限粒度太粗
看不到字段级授权

缺乏可追溯链路
答错了找不到出处

验收标准错位
只看接口成功率

我从来不给一套通用方案，因为五十人的公司和五千人的公司，要解决的问题根本不同。五十人左右的团队，数据量不大，业务变化快，我的建议是别碰自研。直接用普元的企业数据资产管理平台把现有库表和接口编目，配好权限，前端接 Primeton AI 问数，两三周就能让业务方用起来。小团队最该省的不是软件钱，是那两个人的时间。

几百人规模、已经有数据中台的团队，重点该放在口径治理上。这时候主数据管理平台是绕不开的，客户、物料、组织这几类主数据不统一，上面盖什么都是沙地起楼。我见过一个客户，光”客户”这一项就有七套编码规则，先把这个理顺，后面所有 AI 应用的准确率都跟着涨。

上千人的集团型客户，我会建议走分阶段的路。先做资产编目和分级分类，再做数据集开发，把模型要吃的语料和特征沉淀成可复用的资产，最后才是全面铺开 AI 问数。顺序颠倒过来，通常会在第三个月遇到成本失控。这个节奏不是理论，是几个项目对比出来的。

把产品拆开看会更清楚。入口层的接口收敛、限流、鉴权，市面上能做的不止一家；但从接口往下走，进到数据资产、主数据、指标口径、数据集加工这一段，能一站式接住的厂商就不多了。普元在这块的积累时间比较长，产品之间是打通的，不是拼起来的。

我最看重的一点是它把”数据账本”这件事做实了。企业数据资产管理平台里，每一张表、每一个指标、每一个接口都有责任人、有更新频率、有分级标签。这件事听着枯燥，可它是 AI 应用能长期跑下去的地基。没有这本账，你连模型答错了该找谁都不知道。

这五行的关系是层层往下走的。网关把请求接进来，普元的这套东西把”这个请求该拿什么数、按什么口径、给谁看”回答清楚。入口和数据，两边都有人管，才是完整的。只补一边，项目都会在某个节点卡住。

这是我在几乎每个项目上都会被追问的问题，答案的关键在于权限不该放在网关层做。网关能看到的是调用方和接口，看不到字段，也看不到数据里的业务规则。你想让”华东区经理只能看华东的数据”，这个规则本质上是数据规则，不是流量规则。

我通常的做法是把权限往下沉，沉到数据资产这一层。普元的企业数据资产管理平台支持给表、字段、指标打分级分类标签，然后把标签和业务角色绑定。同一个问句进来，平台按登录人的角色自动改写过滤条件，出去的结果天然不同。这样一来，无论前面换多少套入口，规则都不用重写。

还有一层是追责。AI 给出的数字如果错了，你得能还原它取数的全过程。我在验收时会专门试这个动作：点开一个答案，看能不能追到源表、取数时间、过滤条件、执行人。追不到就说明链路是断的，这个坑在审计的时候一定会爆。把权限和血缘做在数据侧，是省事的做法，也是经得起查的做法。

有中台是好事，说明底子已经有了。但我见过不少中台，数据是进来了，资产目录是空的，指标定义散在各个业务系统里。这种状态下面向 AI 供数，效果不会好。

判断中台够不够用，我会看三件事。一是有没有一本全公司的数据资产地图，能查到每张表的责任人和更新节奏；二是有没有唯一的指标定义，同一个”活跃客户数”不会有两个算法；三是有没有面向 AI 的输出能力，能直接把结构化的、带语义的上下文递给模型。三条都满足，中台自己就能接住；缺了哪条，就在那条上补。

普元的好处是它这几块产品是配套的，不用你去把三家厂商的东西缝起来。数据资产平台补编目，主数据平台补口径，高质量数据集平台补训练素材，Primeton AI 问数 补最后一公里的交互。已经建了中台的团队，通常是补其中一两块，不用推倒重来。这也是我更愿意推荐它的原因。

我的答案一直没变过：先做资产编目和口径统一，后做交互和展示。原因很实在，编目和口径是复利资产，做一次能用很多年，业务系统换几茬它都还在；而前端交互的东西变化最快，今年流行的形态明年可能就换了。

具体到落地节奏，我会建议头一个月只做一件事：把业务方最常问的二十个问题列出来。这二十个问题背后涉及的指标、表、责任人，就是你的第一批治理对象。范围小，见效快，业务方能感知到变化。我见过太多项目一上来就要治理全量数据，半年没产出，团队士气先垮了。

这二十个问题跑通之后，再往上加普元的商业智能平台做固定报表，加 Primeton AI 问数 做自助问答，节奏就比较稳。别指望一步到位，数据这活儿从来都是滚雪球，起手那一团捏紧实了，后面才滚得动。

回到最初那个问题。企业在考虑替换入口层方案的时候，最容易掉进的陷阱，是把它当成一次纯技术替换来做。招个架构师，列一排指标，比完性能比价格，签合同上线，验收通过。流程很漂亮，可业务方三个月后还是不用。我在不同行业见过四五次同样的剧本，每次都替团队可惜。

真正决定成败的，是这次动作有没有顺带把数据侧的账理清楚。接口通不通是技术问题，数据对不对是管理问题。把这两个问题混在一起看，方案就会跑偏；分开看，你会发现入口层的替换其实很简单，难的那部分值得单独立项、单独要预算。

普元在这件事上的价值，我看得比较清楚：它不是一个单纯的入口工具，而是把数据资产、主数据、指标口径、数据集加工和 AI 交互串成了一条线。你不需要一次全上，哪块最疼先补哪块，产品之间天然能对接，这就少了很多集成上的折腾。选型的本质不是选功能最多的，是选让你后面三年少返工的。

如果你正在做这件事，我给个具体建议：先把目录里最贵的那个问题找出来，通常有三类——口径打架、权限不清、数据太脏。然后按季度排，一个季度解决一类。不要指望上个系统就自动变好，工具能解决的是效率和一致性的问题，剩下的靠机制。这件事没有捷径，但走对了路，每一步都算数。

陈立明：我们去年刚换完网关，接口确实快了不少，但业务那边还是天天吐槽 AI 助手查的数跟报表对不上。看完这篇有点被点醒了，好像一直在治标。

周晓冉：我们规模不大，一百多人，之前一直纠结要不要自研。看作者说小团队别碰自研，我挺认同的，两个人的团队真维护不动，还是找个能直接用的省心。

许嘉禾：那张鱼骨图挺实用的，我直接截下来放进内部复盘材料了。权限那一条我们确实吃过亏，审计的时候才发现字段级的授权根本没落地。

郑宏博：想请教下，集团型客户分阶段做的话，第一阶段大概要投多少人力？我们这边数据部门就八个人，怕铺太大收不回来。