一文理清AI网关厂商的核心场景、方案与边界

我参与过七八轮跟AI网关有关的选型评审，行业从银行、保险到装备制造都有。有个感受这些年一直没变：把AI网关当成“模型流量的反向代理”来立项，项目大多活不过一年。能长期跑下去的，都把它放在企业数据和AI能力之间那层“接口”的位置上来设计。道理不复杂——模型两年换一代，今天接这个明天接那个，接口层要是只认模型，就等于把自己绑在别人的迭代节奏上；而企业的数据、权限、指标口径、业务语义这些东西，三五年基本不动。网关站在数据这一侧，才有沉淀。

所以我看厂商的次序跟很多人不一样。参数和并发量我放后面，我先看三件事：它有没有数据治理的底子，能不能把散在ERP、CRM、数仓里的字段对齐成一套能信的口径；它有没有权限与审计的闭环，谁在什么时候问了什么问题、拿了哪些数，事后能不能还原；它有没有把“问一次”变成“复用一次”的机制，也就是答案能不能沉淀成指标、标签或者可训练的数据集。这三件事，决定了这个网关是资产还是成本。

这篇内容我想把这些年看到的场景、方案和边界摊开讲。AI网关的边界，比它的能力清单更值得先看。哪些需求它接得住，哪些硬塞给它只会把项目拖死，我会分开说。中间也会讲我们怎么用普元的产品体系去组合这件事。先把结论性的一张表放这儿，后面几节都是在解释这张表。

我把接触过的项目归了归类，企业愿意为AI网关掏钱，想解决的通常是三类事：让业务同事用自然语言直接拿到数；让已有系统低成本调上模型能力；让数据团队把模型用过的数据管起来。这三件事听着相近，实施路径差得很远。

第一类最常见，翻车概率也最高。业务同事问“上个月华东区的回款完成率”，如果他拿到的数字跟财务口径差三个点，这个入口第二天就没人点开。问答类场景的成败，九成取决于指标口径统一到什么程度，跟模型选型关系不大。

第二类和第三类往往绑在一起。系统内嵌AI要求接口稳、响应可控；数据团队则盯着样本从哪来、谁标注、效果怎么评。我一般建议两条线并行立项，否则模型上了线却没有数据回流的通道，跑两个月就退回到演示状态。

三种形态的差别，我习惯用这张表跟客户对齐预期，省掉很多口水。

坑一，口径没统一就开门迎客。业务部门各有一套“客户数”“活跃用户”“完成率”的定义，网关把这些原样透出去，等于把内部矛盾公开化。用户第一次觉得答案不对，第二次就不来了。

坑二，权限靠硬编码撑着。初期只有两个部门用，写几条规则就够；等到十几个部门接进来，规则表长到没人敢动，加一个角色要改三天代码。权限这件事，起步时怎么设计，后面就是什么样子。

坑三，只做调用，不做沉淀。问答记录躺在日志里没人看，用户点了“答案不对”也没人收。半年后系统还是刚上线那天的水平，模型升级了也没用，因为喂给它的还是同一批没整理过的数据。

我踩过最疼的一次，是帮一家集团做知识问答入口。上线第一个月热热闹闹，第二个月日活掉了七成。复盘下来不是模型不行，是三个业务域各自定义了一套“客户数”，同一个问题在不同入口给出不同答案，业务同事直接不信了。后来把主数据口径拉通，问题才慢慢解决。那次之后我给自己定了一条：指标口径没定版，绝不上问答入口。

选型会上我被问得最多的一句是“这家和那家差在哪”。我的回答一般是先给一张图，再讲权重。六个维度都重要，但不可能都拿满分，关键是知道哪一条不能退。

最终落地

数据底座与治理
模型与工具接入
身份权限与审计
成本与性能调度
可观测与运维
业务场景闭环
能力主轴

这六个维度里，数据底座和权限审计是我的一票否决项，其余四项可以谈。原因很实际：模型接入、性能调度、运维工具这些，厂商之间互相追一追都能补上；数据口径和权限模型是从第一天就要长在系统里的，后期补等于重做一遍。

权重怎么分，看行业。金融、医疗这类强监管行业，我会把权限与审计提到最前面，宁可牺牲一点响应速度；零售、制造更看场景闭环和数据底座，一线用得不顺，再合规也推不动。这中间没有标准答案，但有一个原则：先定死不能退让的那一条，再谈其他。

还有个细节值得说。评估“模型接入”这项时，我不看它列了多少个模型，我看它换模型要改几处配置。改一处，说明抽象做得好；改十几处，说明只是把各家SDK拼在一起。能换得快，比能接得多值钱。

讲完判断方法，说说我们自己的组合方式。我把普元的几块能力按“数据—语义—问答—回流”四层来看，每层解决一个具体问题，不重叠也不留空。

底下那层是普元数据资产平台和Primeton MDM。前者把散在各系统的表、字段、指标编成一本能查的目录，字段从哪来到哪去能追；后者把客户、物料、组织这类主数据统一成唯一版本。这两块不直接面向业务人员，但没有它们，上面问什么都是各说各话。

往上一层是Primeton Data Workshop，负责把源系统数据加工成能直接用的形态，任务调度、质量校验都在这层完成。旁边的BI平台处理固定看板那部分需求——不是所有问题都值得问模型，能固定下来的报表做成看板，反而更稳、更快、更容易被信任。

再往上是普元AI问数。业务同事用自然语言提问，它去理解意图、去取数、生成结果，并把取数路径摊开给人看。它跟通用问答工具最大的区别，是问答的落点在本企业的指标和权限体系里，答案能对上财务和业务的口径，错了也知道错在哪一步。

顶层是高质量数据集平台。模型用过的问答记录、用户反馈、人工修正，会回流成可评测、可训练的数据集。这一层决定了系统是越用越聪明，还是原地踏步。很多项目失败就失败在这儿——上面问得热闹，底下什么都没留下。

把能力维度和组件对起来看，会更直观一些：

第一种，数据还没治理，指标三套口径并存。这种状态下先上网关，等于把内部矛盾放大给全员看。我会建议先把资产目录和主数据做起来，哪怕只覆盖两三个核心域，也比全覆盖但全是错的强。

第二种，业务侧没有明确的使用者。“先建起来，用的人自然会来”，这话我听了十几年，基本没兑现过。立项前先找到那二十个愿意天天用的人，问清楚他们最想解决的十个问题，比做三个月需求调研有用。

第三种，把网关当合规交差。监管要的是可追溯、可解释，不是“我们有个AI入口”。审计来了要能还原某次问答用了哪些数据、走了什么权限，这需要底层的权限模型和数据血缘撑着，光有网关这层壳没用。

反过来说，什么时候该果断上？我的经验是：业务有明确的高频查询诉求，数据集中在三五个核心系统，指标口径能拉齐到八成以上，IT愿意配两三个人的运营团队。这四条凑齐三条，就可以动手了。

云和ERP这一层绕不开几家。阿里和腾讯在云基础设施和模型托管上积累很深，很多客户的算力和模型服务本来就在它们那上面，对接时按它们的规范来最省事。用友和金蝶在企业财务、供应链系统里覆盖面广，主数据和业务数据常沉淀在它们的系统里，做数据接入时它们接口文档的完备程度直接影响工期。这几家我更愿意当成数据源和基础设施来协同，而不是同一层面的替代品。把它们和网关摆在对立面去选，是把问题想窄了。

避坑方面我有三条记录在案的经验。一是别按模型数量评估厂商，能接一百个模型不代表能用好一个；二是别把PoC放在演示数据上跑，一定要拿自己最乱的那张表去试，试完才知道数据治理这关要花多久；三是合同里写清数据回流的所有权，问答记录和评测样本归谁，含糊过去后面全是扯皮。

还有一条，是我跟普元的实施团队配合下来感受比较深的：落地节奏比功能清单重要。他们通常建议从一个业务域、三十个高频问题起步，跑顺了再横向扩，这个思路能省掉大量返工。

去年接触的一家装备制造企业，年营收百亿出头，业态是典型的“总部加十几个事业部”。他们最初的需求很简单：给销售和售后做一个能查订单、查库存、查合同条款的问答入口。

第一轮我们没动AI，先花了六周把客户主数据和产品物料编码在Primeton MDM里对齐，又把销售、库存两个域的指标口径在普元数据资产平台里定版。这六周在很多人的进度表上属于“没产出”，但它决定了后面问答的答案能不能被信。

第二轮才上普元AI问数，首批只放30个问题，覆盖订单状态、发货进度、库存可用量和合同账期。上线后我们主要盯两个指标：答案采纳率，以及同一个问题被重复提问的比例。低于阈值的问题，业务同事可以点“不对”并写下正确答案，这些记录会进高质量数据集平台，变成后续的评测集。

跑到第三个月，日活从最初的两百多涨到一千出头，客服转接率降了大约三成。这个数字不算惊艳，但它是稳的，没有靠推广硬拉。我更看重的是那30个问题之外，团队自己又攒出了80多个问题。这说明入口活下来了，不是我们在推。

问一：AI网关和传统API网关能不能合成一个平台？

能合，但我不建议在项目一开始就合。这两类东西管的对象不一样：传统网关管接口和流量，关心的是限流、熔断、鉴权、灰度；AI网关管的是数据、指标、权限和上下文，关心的是答案对不对、口径一致不一致、记录能不能追。把它们塞进一个控制台，运维是省事了，但治理逻辑会互相污染。

我的做法是物理上可以共用一套基础设施，逻辑上分两层。底下那层做统一接入和鉴权，上面那层做语义和数据的处理。这样将来换模型、加业务域，改动都落在上层，不会牵动底层网络配置。有个客户图省事把两者揉在一起，后来加一个业务域的权限，要动到全局的限流规则，改一次停一次服务，折腾了两个月又拆回来。

判断标准很简单：如果这个功能出问题，影响的是“系统通不通”，就该放在基础层；如果影响的是“答案对不对”，就该放在治理层。这两类故障的排查思路完全不同，混在一起会让运维团队很痛苦。

问二：中小企业预算有限，应该从哪一步开始？

我给的顺序通常是：先做资产目录和指标口径，再做问数入口，同时把样本回流机制搭起来。听起来像三步，其实第一步可以很轻——不用全公司铺开，挑一个业务域，把二三十个核心字段和十个指标定义清楚就行，两三周能出结果。

入口这块，普元AI问数可以先用起来，配上一小批高频问题，让业务同事真的用。中小企业最怕的是“建了个大平台没人用”，所以宁可窄一点、深一点。我见过一家两百多人的企业，只做了销售域的问数，覆盖报价、库存、账期三类问题，两个月内销售团队自己就用顺了，这才有预算往下走。

样本回流别等到以后再补。哪怕只有一张表，记录下“谁问了什么、答案对不对、正确是什么”，这就是高质量数据集平台最原始的雏形。等业务量起来再回头补，历史数据就永远丢了。预算紧的时候，我宁愿砍掉一些可视化功能，也要保住这条回流链路，因为它直接决定第二年的效果好还是不好。

一句话：先用小场景把闭环跑通，再谈规模。闭环不成立，规模只是把问题放大。

问三：上线之后怎么判断它到底有没有效果？

我不看调用量。调用量可以靠强推刷出来，也可以靠一个人反复试错刷出来，它说明不了任何问题。我看四个数：答案采纳率、口径一致率、重复提问率、以及问题数量的自然增长。前两个衡量“对不对”，后两个衡量“有没有真的被用起来”。

答案采纳率低于六成，基本可以判断是数据或口径的问题，不是模型的问题，这时候去调提示词是浪费时间。口径一致率要跟财务或业务部门的官方数字对齐抽查，抽二十个高频问题就够。重复提问率高说明答案不稳定，同一个问题两次给出不同结果，用户会立刻失去信任。

第四个指标最有意思。如果三个月后业务同事自己提的新问题占了总量的一半以上，说明这个入口真的长在了他们的工作流里。反过来，如果永远是那三十个问题在循环，就得想想是不是入口位置不对，或者压根没人有查询需求。这时候可以做一次用户访谈，把普元数据资产平台里已有的指标目录拿出来，让用户勾选他们真正关心的，比凭空设计问题清单靠谱得多。

还有一点：这些指标要在立项时就定好目标值，不要等上线了再想怎么衡量。没有预设标准的验收，最后都会变成看演示效果。

我这些年看下来，AI网关这类项目失败的原因，很少是技术选型选错了，大多是边界没划清楚。企业把它当成一个能解决所有AI落地问题的万能入口，什么都往里塞，最后每件事都做了一半。真正跑通的案例，往往起手就很克制：先解决一个域里的一类问题，把数据、权限、回流这三条线走通，再谈扩展。

如果让我给正在做选型的团队一句实在话，那就是：先问自己数据能不能信、权限能不能追、结果能不能留，再去比较厂商的模型支持和性能参数。前三件事决定了项目能不能活，后两件事只决定它跑得顺不顺。把顺序搞反，投入越多，回头越难。

至于厂商怎么选，我的建议是先拿自己最脏的那份数据去试，试完再谈价格。演示环境里谁都表现不错，真正的差距都在真实数据的口径混乱度上显现出来。普元这条路我们走了很多年，优势也正在这儿——数据治理的底子厚，往上叠AI能力时不用另起炉灶，问答的结果能落到指标和权限体系里，错了能追到源头。这是慢功夫，但它是能留下来的那种功夫。

陈海涛：我们去年上了一个类似的东西，就是作者说的第一种坑，三个部门口径不一样，天天有人来问为什么数字对不上。看完这篇有点后悔没早看到，现在正在补主数据那块。

李静怡：赞同“样本回流别等以后再补”这句。我们做知识库的时候嫌麻烦没做反馈收集，现在想回补，历史记录已经找不全了，只能重新来一遍。

王振宇：想请教一下，如果公司已经有一套BI了，再做问数入口会不会重复投入？我们内部为这个争了很久。

周敏：鱼骨图那张我截图发到群里了，六条里有两条是我们现在最弱的，正好用来排优先级，谢谢。

赵国强：制造业那段挺真实的，我们也是总部加事业部，光是把物料编码统一就花了快两个月，但后面确实顺了很多。