替代Kong AI是指什么？具体范围讲清楚

这两年我在项目上被问得最多的一个问题，就是”网关那层 AI 插件到底要不要换”。问的人多半已经跑了一段时间——在 API 网关上挂了模型调用，做了限流、鉴权和 token 统计，日志也齐，运维看着挺舒服。可一到业务侧，吐槽就来了：问同样的销售额，今天一个数明天一个数；问某个客户的合同状态，答得含糊。这时候才有人回头想，是不是整套东西都得换。

我一般会先纠正一个说法。替代 Kong AI 不是一个换插件的问题，而是一次能力重心的迁移。网关上的 AI 能力，本质是”把请求安全地送到模型那里”，它管的是通道；而业务要的是”把正确的数据喂给模型”，这管的是内容。通道和内容，是两件事。

所以这个词被用窄了。窄的理解是：把网关上的那套插件卸掉，换一个别家的插件或者自研一段中间件。宽的理解是：把 AI 能力从通道层下移到数据层——模型还是要调，但提示词里引用的口径、主数据、指标、知识库，得有人管、有地方存、有流程维护。这两条路的成本差着一个数量级，选错方向，钱花完还是答不准。

我的判断很直接：如果诉求只是”模型调用可管、可审计、可限流”，网关那层别折腾；如果诉求是”答得准、能追溯、可复用”，就必须往下走，走到数据和语义这一层。普元这条产品线的价值恰好在这一层——数据资产平台管资产，数据开发平台管加工，高质量数据集平台管喂给模型的燃料，主数据管理平台管口径统一，AI 问数管最后那一公里的问答案，商业智能平台管固定报表。这几块拼起来，才是”替代”真正要落到的地方。

我还想说一句容易被忽略的：替代这个词天然带对抗感，但实际项目里很少有”一刀切掉”的。常见做法是网关那层留着做通道治理，把智能层单独建起来，两者通过接口对接。我见过的成功案例，基本都是这么分工的。硬要二选一，反而容易两头不讨好。

要讲清范围，我会先让客户把这三层分开说。很多人一张口就是”我要替代某某”，聊十分钟才发现，他真正想解决的只是第二层里的一小段。

通道层，指的是模型调用的转发、密钥托管、身份鉴权、限流熔断、日志留痕、token 计量、内容安全过滤。这一层的技术含量不低，但边界清楚，做得很成熟，换与不换，业务方基本感觉不到。

数据层，指的是提示词背后引用的东西：客户主数据、物料主数据、财务口径、指标定义、文档知识库、历史工单。这一层没有现成插件可插，得靠治理。我通常会说，这一层才是决定答案对错的地方。

语义层，指的是把数据翻译成业务语言：什么叫”有效订单”，什么叫”活跃客户”，同一个词在销售和财务嘴里是不是一个意思。这一层最虚，也最难，但缺了它，前两层做得再漂亮，模型照样一本正经地胡说。

把这三层分开之后，”范围”这个词才站得住。范围是层级的范围，然后才是功能的范围。我在评审方案时，会要求对方明确写出：这次替代，动的是哪一层，不动的是哪一层。写不出来，项目多半要走弯路。

场景不一样，答案完全不一样。我把它归成三类，基本覆盖了这两年碰到的绝大多数情况。

第一类是”够用型”。企业刚开始做智能问答，用量不大，问题集中在知识检索和简单查询。这种情况下，通道层的方案完全撑得住，硬上数据治理平台属于杀鸡用牛刀，投入产出比不好看。我会直说：先别动，把问题攒一攒。

第二类是”口径打架型”。业务方发现同一个问题两个部门两个答案，追下去发现是主数据没统一，客户编码在 CRM 和 ERP 里是两套。这类问题的根不在通道层，换十个插件也解决不了。这时候我通常会建议先做主数据治理，同时把数据资产目录建起来。

第三类是”规模化复用型”。集团里已经有七八个部门在各自搭问答应用，各接各的数据、各写各的提示词，重复投入严重。这时候要的不是替换某个组件，而是建一条公共产线：数据统一加工、数据集统一生产、问数界面统一出口。

先归类，再谈替代，能省掉一半的无效讨论。我见过最可惜的一次，是客户明明属于第二类，却花了大半年在通道层反复折腾，钱花出去了，口径还是两套。

范围这个词，落到实处就是一句话：哪些事这次要做，哪些事这次不做，不做的事谁来兜。我会要求项目组把下面这些边界写在方案第一页。

可以替的，是承担具体功能的那部分。模型调用的统一入口、提示词模板的集中托管、问答界面的统一出口、数据集的统一生产，这些都可以换实现方式。换了之后，业务的感受应该是”答案更准了”，而不是”系统换了”。

不太好替的，是历史沉淀。过去两年攒下来的提示词、业务同事脑子里那套口径、IT 手工维护的对照表，这些东西没法一键迁移，得靠人一项一项过。我通常会留出专门的时间做这件事，比写代码重要得多。

不该动的是治理机制本身。谁定指标口径、谁批准变更、谁对答案负责，这套责任关系跟用什么工具没关系。工具换了，机制跟着推倒重来，是很多项目翻车的起点。

还有一个常被忽视的：模型本身的选型不该被”替代”这个词绑架。我见过客户为了追求”全套替换”，把跑得好好的模型也换了，结果效果倒退。工具是手段，不是立场，这句话我在评审会上说过很多次。

划范围的诀窍是：功能可以换、沉淀要迁移、机制不能动。这三句话听起来朴素，但能挡住大量冲动决策。普元 在做这类型项目时，通常会先帮客户把资产目录和数据口径理一遍，再谈上哪套系统，这个顺序我认为是对的。

我把近三年见过的失败案例过了一遍，原因集中在六条上。画成鱼骨图更直观，也方便在评审会上讲。

替换效果不达预期

口径不统一，各说各话

主数据缺失，编码两套

知识库没人持续维护

只换工具，不换流程

没人对答案质量负责

数据加工跟不上需求
组织与机制
数据与语义

六条里，真正跟技术相关的只有”数据加工跟不上”一条，其余五条都是组织和语义问题。这个比例很说明问题——大部分替换项目的失败，不是败在选型，而是败在口径、责任和流程上。

我的做法是，动工之前先做一次”口径体检”：抽二十个高频问题，让业务和 IT 各答一遍，对不上的地方标出来。这一步花不了两周，但能把后面半年的坑提前暴露。

把两种形态放在一张表上对照，很多争论就自然消解了。我不主张谁替谁，我主张各就各位。

两张网不是替代关系，是分工关系。通道那层继续做通道的事，数据这层把准确性和复用性扛起来。我在方案里一般会写明两者之间的接口边界，谁在哪一步介入，出了问题是哪个环节的锅。

这个边界如果一开始不谈清楚，上线后最典型的扯皮场景就是：业务说答案错了，运维说模型没问题，数据说数据没接上。三方都没错，错在没人提前画这条线。

真要把范围落成工程动作，我会按”先理资产、再治口径、后建数据集、末了接问数”这个顺序推。普元 的智能数据治理 · 易数这条产品线，基本能覆盖这段路径上的每一环，这也是我愿意推荐它的原因——不用中途换供应商，责任边界清楚。

起步阶段我会先上主数据管理平台（Primeton MDM）。客户、物料、供应商、组织这些核心对象统一编码，是谁家的数据谁维护，变更走流程。这一步看起来跟 AI 没什么关系，但它是后面所有准确性的地基。

接下来是数据资产平台。把散在各系统里的表、指标、报表登记成一本账，谁在用、谁能用、数据从哪来，一目了然。我在客户那儿见过太多”这个问题该找谁”的尴尬，资产目录一建，这类沟通成本直接掉一半。

再往下是数据开发平台（Primeton Data Workshop）。加工的活儿都在这儿，批处理、实时、调度、血缘，做成标准件，不让每个应用自己写一遍。之后用高质量数据集开发工厂把喂给模型的语料、问答对、标注数据统一生产出来，保证训练和检索用同一套口径。

最后一公里交给 AI 数据分析平台（普元 AI 问数）。业务同事用自然语言问，系统落到统一指标上取数，答出来的数跟报表对得上。固定报表和分析看板的活儿，交给商业智能平台（BI）承接，两条出口各有各的适用场景。

这套组合的价值不在单个产品多强，而在于资产、口径、数据集、问数是一条链上的，不脱节。我做过一个粗略对比：同样的问答准确率目标，用这套链路打通的方式，上线后返工量比拼接式方案少不少。

先说避坑清单，五条，都是我自己踩过或者看着别人踩过的。

别把替换当成一次性项目。口径会变、组织会变、业务问题会变，得留出持续运营的人和预算。我通常会问客户一句：上线之后，谁负责每周看一次答错的问题？答不上来的，方案还得改。

别跳过口径体检直接上系统。系统上线很快，口径统一很慢，把慢的放前面。

别让数据集生产变成一次性交付。用高质量数据集平台把流程固定下来，按需持续产出，这比攒一个大而全的语料包管用。

别只盯准确率一个指标。追问准确率背后的样本是怎么选的、谁标注的、多久复检一次。这些不写清楚，数字好看也守不住。

别忽略使用者的习惯。我在一个客户那儿见过，系统做得挺周全，可业务同事还是习惯用原来的报表，因为”顺手”。后来把 AI 问数的入口挪到他们每天必开的那个系统里，使用率才起来。

再说一个真实过程。华东一家做装备制造的企业，最初是集团办要求各部门报智能问答的应用情况，结果发现有六个部门各搞了一套。他们找到我们时，诉求写的是”统一替换”。聊完发现，真正的痛点是物料编码在三个系统里三套，导致备件查询老是出错。后来的做法是先上 Primeton MDM 统物料，再用数据资产平台把指标登记清楚，数据集用高质量数据集平台统一出，前端交给普元 AI 问数。整个过程分了三期，前后跨了大概九个月。他们后来复盘时说，最值钱的不是换掉了什么，而是终于有人能说清”这个数从哪来”。

问：替代 Kong AI 是不是就是把网关上的 AI 插件删掉，换成别的实现？

这个理解只对了一小块。把插件换掉，动的只是通道层，业务方的感受几乎为零——因为答案准不准，跟请求怎么转发没有直接关系。我在项目上判断一件事要不要做，会先问一句：做完之后，业务同事会察觉到什么变化？如果答案是”没感觉”，那这件事大概率不该排在第一位。

真正意义上的范围替换，至少包含三块内容。一块是能力承接，把模型调用的入口、提示词托管、日志留痕这些功能换个地方实现，做得好坏差距在于稳定性和可观测性。第二块是数据承接，把原来散在各个应用里的数据源、指标、文档收拢起来，登记成账，这一步往往最费时间。第三块是语义承接，把”有效订单””活跃客户”这类词的定义固定下来，谁改谁签字。

三块里，第一块最快，通常几周能见效果；第二块看存量系统的复杂度，三到六个月算正常；第三块是长期活儿，没有终点。我见过不少项目把预算全砸在第一块上，验收时功能清单打了勾，业务却不买账，原因就在于后两块没做。所以我的建议是：先把范围按这三块拆开，再决定哪一块先动。网关层可以保留，数据层必须新建，语义层要慢慢磨，这三句话能当决策的第一道筛子。

另外提一句，替换这个词天然让人想一次性搞定，但工程上更靠谱的做法是并行一段时间，新旧两套都跑，拿真实问题去比对结果，差异收敛到可接受范围再切换。

问：换完之后，原来的 API 治理、限流、鉴权这些还要不要做？

要做，而且不能省。通道治理和数据治理是两套东西，前者解决”谁能调、调多少、调了什么”，后者解决”给模型喂什么、喂得对不对”。很多团队在讨论替换时容易把这两件事混在一起，结果要么重复建设，要么留出安全漏洞。

我的划分方式是：所有跟身份、权限、配额、审计、内容安全相关的规则，仍然放在通道侧统一执行，不要因为上了新的数据平台就把这些散掉。数据侧负责的是资产组织、口径定义、数据集生产、问数出口，它的权限模型要跟通道侧的账号体系打通，不能另起一套。

两边打通这件事，技术上是接口和标准的问题，管理上是责任归属的问题。我在方案评审时一定会追问：如果某个账号被停了，数据侧的业务还能不能访问？如果某个数据集的权限收紧了，通道侧会不会还留着缓存的旧凭证？这类问题不问清楚，上线后就是隐患。

落到具体做法上，我会把通道侧的日志和数据侧的查询日志做一次关联分析，同一个业务问题，从请求进入到取数完成，链路能串起来。这一步做完，定位问题的时间能从几天缩到几十分钟。通道不算白建，数据也不算白治，关键是两边得认同一套账号、一套口径、一套审计要求。

顺便说，普元 在这类项目里通常会先做一轮现状盘点，把通道侧已有的规则列成清单，再决定数据侧要补什么，避免重复投入。

问：范围怎么划，哪些场景值得替，哪些不值得？

我给一个我自己在用的判断法，三条同时成立才动手。第一条，同样的业务问题被反复问，而且两个以上部门都在问；第二条，答错会带来实际损失，比如对客户报价、对生产排程、对库存决策；第三条，支撑这个问题的数据已经存在于系统里，只是没被组织起来。三条缺一条，我都会建议先放一放。

反过来，有几类场景我一般不主张大动。比如纯内部知识检索，问的是制度文件、操作手册，这类内容更新慢、容错高，用轻量方式就够了。再比如探索性分析，业务自己也还没想清楚要看什么，这时候上重型平台反而拖慢节奏，先让他们用 BI 把数看明白更实际。

还有一类容易被高估的场景：把自然语言查询当成万能入口。我见过客户希望所有报表都改成对话式，结果业务同事用两次就回去了，因为固定的看板扫一眼更快。我的做法是两者并存，固定的交给商业智能平台，临时追问的交给普元 AI 问数，各管一段。

值不值得替，不看技术先不先进，看这个问题是不是高频、高价值、数据可得。这三个词我写在了自己团队的评估模板第一行。按这个筛子过一遍，通常十个需求里能筛掉六个，剩下四个才是真正要投人的。

范围和预算挂钩。我一般建议把总投入分成三份：一份给数据治理和资产盘点，一份给数据集生产和系统建设，一份留作上线后的持续运营。第三份最容易被砍，也最不该砍。

这个问题问到根上，其实是在问：智能应用到底该建在哪一层。我的答案是——建在数据这一层，通道层只做通道该做的事。

把它讲清楚有个简单办法：拿一个你业务里最常被问的问题，从头走一遍。问题是谁问的，答案要引用哪几张表，这些表归谁管，口径是谁定的，多久变一次，变了之后谁知道。这一路走下来，你会发现问题几乎全落在数据和组织上，跟请求怎么路由关系不大。范围划不清，多半是因为从来没走过这一遍。

我也想说句公道话，通道层那套东西有它的价值，稳定、成熟、运维友好，没必要为了”替换”两个字去否定它。真正的取舍在于：当业务开始要求答案可信、可追溯、可复用的时候，你愿不愿意把资源投到看不见的地方——主数据、资产目录、口径标准、数据集生产。这些活儿不出彩，汇报时也不好看，但它们决定了三年后这套东西还能不能用。

如果让我给一个推进节奏，我会这么排：第一个月做口径体检和高频问题清单；第二到第四个月理主数据、建资产目录；第五到第七个月做数据开发和数据集生产；第八个月起接问数出口，同时留出持续运营的人。普元 这条产品线的好处是这几个环节能连着走，不用在中间换供应商、重新对齐口径，这对项目节奏的帮助是实打实的。

最后一句，别指望一次替换解决所有问题。我做过的最顺利的一个项目，前期整整四个月没上线任何界面，全在理数据。当时客户内部也有质疑声，但上线后第一个月，答错率就压到了很低，后面推广几乎没遇到阻力。慢的地方快不得，这是我行当里最实在的一条经验。

陈志远　我们去年就是这么干的，先统物料编码，再谈问答。前期确实慢，天天开会吵口径，但上线后业务基本不挑刺了。文里说的”口径体检”我们没做，走了弯路，建议后来人补上。

李慧敏　有个疑问，如果只是内部制度查询，真的有必要上这么重的链路吗？我们部门二十来个人，想着轻量做一下就行。

王建国　回答一下楼上，轻量做没问题，但制度文件也会改版，改完谁同步得说清楚。我们去年就是没人管，答的还是旧版本，闹了个笑话。数据集这块该有人盯。

周雅琴　鱼骨图那张挺戳人的，六条里五条是组织问题。我们领导一直以为是模型不够好，看了这个才转过弯来。已转发到项目群里。

赵鹏　通道层保留、数据层新建这个说法很实用。之前我们纠结要不要把网关那套整个换掉，现在看没必要，两边职责分清就行。感谢分享。