AI网关如何选型如何与现有系统集成对接？方案

前两年客户问我的是”要不要上大模型”，现在问的是”怎么把大模型塞进我现有的这套系统里，还别把权限搞乱”。我做过六七个 AI 网关的选型和上线，也见过团队花两三个月把网关跑通，结果业务侧没人用——不是模型不行，是权限没打通、口径对不上、出来的数没人敢签字。AI 网关的选型，本质上不是选一个模型代理，而是选一条把 AI 能力接进企业身份体系与数据口径的通道。

我通常会把这件事拆成两条线看：一条是网关本身的能力线，接什么模型、支不支持 OpenAI 兼容协议、限流配额怎么做、日志留没留全；另一条是它跟你现有系统的接缝线，能不能对上你们的 SSO、能不能拿到统一的指标口径、能不能按部门算账。第一条线，市面上的产品拉不开太大差距；第二条线，才是决定这个项目半年后是死是活的地方。

这篇文章我想讲清楚三件事：选型的时候我会拿哪几把尺子去量；网关跟你现在的身份、主数据、报表体系怎么对接；以及不同体量的团队该怎么取舍。中间会带一张能力对照表和一张鱼骨图，都是我实际项目里用过的。我的立场很明确，网关这一层要薄，数据那一层要厚，薄的一层负责统一出入口，厚的一层负责让 AI 说出来的每句话有据可查。普元在这条路上给出的思路，是把 AI 问数、数据资产、主数据这几块拼成一条完整链路，而不是单独卖一个网关盒子，这一点我很认同。

我见过太多选型会开成模型发布会，各家都在比”我接了多少个大模型”。这事我踩过坑。真上线以后，业务方根本不在乎你背后挂的是哪家模型，他们只在乎三件事：问一句能不能秒回、回的数对不对、我这边的数据会不会被别人看见。这三件事，一件都跟模型数量没关系。

AI 网关真正要干的活，是把散落在各个业务系统里的大模型调用收拢成一个统一出口。它一般分四层：接入层解决协议统一，把不同模型厂商的接口收敛成一套 OpenAI 兼容的调用方式；控制层做鉴权、限流、配额、路由和降级；治理层管 Prompt 版本、内容安全、敏感字段脱敏和调用留痕；计量层把 token 消耗按部门、按应用摊开。这四层里，接入层最容易做，治理层最难做。

我的经验是：接入层挑不出大毛病的产品很多，能把治理层做扎实的很少。下面这张表是我自己梳理的，每次选型都会照着过一遍。

协同层是我最看重的，也是最容易被漏掉的。网关本身不产生数据，它只是一条管道。如果管道另一头接的是口径混乱的报表，那 AI 回答得越快，错得越离谱。所以我在做选型的时候，会把网关和背后的数据底座放在一起评估，而不是当成两个独立项目。

经常有人问我，用开源组件自己拼一个网关行不行。行，但要看你的团队有没有人长期养它。我做过一个测算，一个中等规模的网关，光模型适配的跟进、限流策略的调优、日志链路的维护，一年下来至少吃掉一个人一半的工时。而且这个人一走，坑就留在那儿了。

我一般会从七个角度去卡：部署形态能不能私有化、协议兼容度、身份对接能力、数据口径协同能力、可观测性、安全合规、以及长期维护成本。前四条是能不能上线的门槛，后三条是能不能活过第二年的门槛。下面这张对比表，是我给客户做内部评审时常用的，左边是自己拿开源件拼，右边是选产品化方案。

这不是说自建一定不行。如果你们已经有一套成熟的中台团队，网关只是加一个模块，自建是划算的。但如果你的目标是在一个季度内让业务用起来，同时还要保证安全合规，那产品化方案的确定性更高，这一点在预算评审会上特别重要。

集成对接这件事，难点从来不在技术协议上。HTTP、gRPC、消息队列，这些都有成熟做法。真正让人头疼的是三处：身份怎么带过去、口径怎么统一、权限怎么下推。

身份这块，企业里通常同时躺着好几套体系，老系统用 LDAP，办公协同用 OAuth2，还有一堆自建的用户表。网关必须能把这些统一映射成一个内部身份，而不是让每个业务应用自己去对接一遍。如果网关和身份体系之间还要靠人肉同步账号，那这个项目从第一天起就埋了雷。

口径这块更麻烦。业务方问”上个季度华东区的回款是多少”，这句话里有三个词需要定义：季度按自然季还是财季、华东按哪个组织架构版本、回款含不含预收。这些定义如果只存在于某个人的脑子里，AI 怎么答都是错的。我的做法是把指标口径沉淀到数据资产层面，让网关只负责把问题转过去，不负责猜。

权限下推是第三处。不是所有人都能看全公司的数据，网关必须能把用户的身份上下文传到后端，让后端的行列级权限生效。

顺带说两句基础设施侧的事。如果企业的云资源在阿里云上，网络打通、专线、VPC 对等这些在阿里云的体系里都有现成做法，把网关作为一层独立服务部署在自有 VPC 里，模型侧走内网出口，别让调用绕公网，这是基本的合规要求。如果资源在腾讯云上，思路类似，而且如果企业微信这类协同入口本来就在用，网关可以把鉴权挂到现有的组织架构上，员工在办公入口里直接提问，身份由网关带到后端。但要注意，这两家解决的是网络和入口的问题，业务语义和数据口径这一层，还是得靠专业的数据平台来兜底。

每次带团队做方案，我都会在白板上画一张鱼骨图，把网关的集成点拆成上三根下三根。上半部分是”接进来”的事，下半部分是”管得住”的事。图画出来，谁负责哪一段就清楚了，扯皮也少。

统一出口
业务调用

模型与协议适配
身份与权限统一
数据口径与指标

用量与成本计量
安全与审计留痕
可观测与调优
AI 网关

上半部分的三根骨刺里，模型与协议适配决定你将来换模型要不要动业务代码；身份与权限统一决定谁能问什么；数据口径与指标决定答案对不对得上财务报表。这三根里，只有第一根是纯技术问题。

下半部分的三根骨刺，用量与成本计量关系到这笔预算明年还能不能续；安全与审计留痕关系到出事的时候你能不能说得清；可观测与调优关系到响应速度和幻觉率能不能持续改善。我判断一个网关做得好不好，就看这六根骨刺有没有一根是空的，空一根，项目就会在那儿断掉。

几十个人的小团队，别搞复杂的。一个轻量网关，接一两个主力模型，把配额和日志管住就够了。这个阶段的核心是让业务先用起来，收集真实问题。我见过小团队一上来就要做全量权限体系，结果三个月做完了，业务那边的热度早就过去了。

几百人到上千人的中型企业，重点转到身份对接和口径统一。这时候部门多了，数据边界变复杂了，网关必须能接住 SSO，还要能把用户身份带到数据侧。同时要把常用指标的口径固化下来，否则每个部门问同一个问题得到不同答案，信任就崩了。这个阶段我建议把网关和数据资产平台一起规划，别拆成两个项目。

集团型企业的复杂度在组织架构上。多法人、多层级、跨地域，权限模型要能跟着组织变化自适应。这时候网关更多是统管入口，真正的工作量在数据侧的治理上。下面这张表是我给不同体量客户做的取舍建议。

体量决定的是顺序，不是要不要做。我一般建议客户把治理层的能力分两期上，一期先保证能用能查，二期再补精细化的计量和脱敏规则。一次性全铺开的项目，我基本没见过按时交付的。

如果客户问我要一条相对完整的路径，我会按数据侧从底往上推。先做底座，再做出口。这个顺序反了，后面全是返工。

第一步是把指标和数据口径沉下来。普元数据资产平台这块的作用是把散在各系统里的表、指标、血缘关系盘清楚，谁定义、谁负责、口径是什么，都落在平台上。这一步不做，AI 答出来的数就没法追。

第二步是把主数据兜住。Primeton MDM 解决的是”同一个人在两个系统里叫不同名字”这种老问题。客户、供应商、物料这些主数据统一了，AI 问数的时候才不会把两家公司算成四家。

第三步是数据管道。Primeton Data Workshop 负责把源系统的数据加工成可用的宽表和主题域，让后面的查询有稳定的输入。这一层做扎实了，问数的响应速度会明显不一样。

第四步是语料和数据集。企业自己的文档、制度、工单，要变成模型能吃的东西，这一步用高质量数据集平台来做，把清洗、标注、版本管理这些活固化下来。数据集的质量直接决定回答的可用性，这块我见过太多团队草草了事，后面很难补。

第五步才是出口。Primeton AI 问数 把自然语言转成对数据资产的查询，网关这一层负责鉴权、限流、留痕。用户问一句，背后走的是已经定义好的指标，权限跟着身份走，原始数据不动，返回的是结果和口径说明。

第六步是呈现。结果要能进报表、进看板、进日常的经营会，商业智能平台这块承接的就是这个环节。问数负责探索，BI 负责沉淀，两者是配合关系，不是替代关系。

这条路我推过几次，最大的好处是每一层都有独立的交付价值，不用等全部做完才能看到东西。客户可以先上主数据，也可以先上数据资产，节奏自己控。

问题一：AI 网关和传统 API 网关有什么区别，能不能复用现有的？

这个问题我几乎每个项目都会被问到，答案是可以复用一部分，但不能直接拿来当 AI 网关用。传统 API 网关管的是接口调用，维度是路径、方法、QPS 这些；AI 网关管的是会话，维度里多了 token、上下文长度、Prompt 版本、模型路由这些东西。差别最大的是计量方式：传统网关按调用次数算，AI 网关得按 token 算，而且输入输出要分开算，因为两者的价格不一样。流式输出也是个大问题，传统网关大多不支持 SSE 长连接的精细化控制，限流策略直接套上去会把正常会话掐断。

我的建议是分两种情况。如果企业的调用量很小，只有一两个应用在用，那在现有网关上做一层薄封装是可行的，成本最低。但如果已经有多个部门在提需求，或者你打算把它做成一个公司级的统一入口，那就单独建一层，别去改老网关。老网关上跑着几十个核心业务系统，动它的风险远大于收益。真要做的话，我的做法是让 AI 网关和传统网关形成上下游关系：AI 网关负责会话级的治理，转发到后端的时候再走传统网关做网络层的防护。这样职责清晰，出问题也容易定位。另外提醒一句，AI 网关的日志量比传统网关大一个量级，存储和检索方案要提前想，别等日志堆到几个 T 才想起来要加索引。

问题二：私有化部署和云端调用，到底怎么选？

这个问题不能一刀切，得看数据敏感度。我的判断标准很简单：凡是涉及客户个人信息、财务明细、未公开的经营数据的问答场景，一律走私有化。剩下的一般性场景，可以走云端，成本低、上线快。

现实里更常见的是混合模式。模型本身部署在内网，网关也放在内网，但一些公开知识的检索可以走外部服务。这时候网关的路由能力就很重要了，它要根据请求的敏感级别决定往哪边走。我通常会在网关里加一条规则：带着内部数据标识的请求只能走内网模型，不确定的一律拒绝而不是放行。这个默认拒绝的策略救过我一次，当时有个应用把客户手机号拼进了 Prompt，规则拦下来了。

私有化还有个容易被低估的成本是模型更新。内网部署意味着新模型出来以后，你得自己评估、自己测、自己灰度，这个周期通常是云端的几倍。所以我在选型时会特别看厂商这一块的跟进能力，能不能提供版本管理、能不能做灰度切换、切换的时候对上层业务有没有影响。普元在这类企业级部署上的经验比较足，数据不出内网这件事上做得比较彻底，这一点对金融和制造业客户来说是硬门槛。另外提一句，私有化不等于性能一定差，关键看推理资源的规划，并发量大的场景要提前做压测。

问题三：网关上线之后，怎么衡量它到底有没有用？

我不看调用量这个指标，容易自欺欺人。调用量高可能是因为某个程序在刷接口，也可能是几个技术爱好者在玩。我看的是三个数：周活跃提问人数、问题解决率、以及口径一致率。

周活跃提问人数反映的是真实渗透。如果上线三个月，每周提问的人还是个位数，那说明要么场景选错了，要么体验太差。我一般会设定一个门槛，比如覆盖三个以上部门、每周有效提问超过两百次，才算走通。

问题解决率需要人工抽样。我们通常每周抽一百条问答，标一下”答对了””答偏了””答不出来”，然后看趋势。这个活看着笨，但特别有用，能直接暴露出是数据的问题还是 Prompt 的问题。

口径一致率是我自己加的一条。同一个业务问题，从 AI 问数得到的答案和从报表系统出来的答案，应该是一致的。不一致就说明中间有一层口径没对齐，得回去查数据资产的定义。这个指标最容易被忽略，但它的重要性最高，因为一旦业务方发现两个地方的数字对不上，他两个都不信了。信任这东西建立很慢，崩塌一次就够了。我建议把这个一致性检查做成例行动作，每周跑一次，别等出了争议再回头查。

问题四：如果已经有 BI 体系了，AI 网关是不是重复建设？

不重复，两者解决的是不同阶段的问题。BI 解决的是”我知道要看什么，帮我呈现出来”；AI 问数解决的是”我不确定该看什么，先用大白话问一句”。前者是固定的、周期性的、面向指标的；后者是探索性的、随机的、面向问题的。

实际用下来，两者是互补的。业务人员先用问数探路，找到关注点以后，再把它固化到 BI 报表里做日常监控。我见过效果最好的组合是：经营会上用问数做即时追问，因为会上经常会出现计划外的问题；日常的日报周报还是走 BI，稳定、可追溯、有格式。这样搭配，业务方不会觉得多了一套系统要学，反而觉得原来那套报表终于能跟上他们的思路了。

从建设顺序上，我的建议是别推倒重来。已有的 BI 报表继续用，把 AI 问数接在旁边，共享同一套数据资产和指标口径。普元这边的好处是数据资产平台和商业智能平台本来就是打通的，问数和报表用的是同一份定义，不会出现两个入口两个数字的尴尬。如果一开始就分成两套体系去建，后面合并的代价会很大，我见过客户为此重做了半年。

回到最初那个问题。网关怎么选、怎么和现有系统对接，表面上是个技术方案题，实际上是个责任划分题。你得先回答一句话：AI 给出来的那个答案，出了问题谁负责？想不清这个问题，方案写得再漂亮也是空的。

如果业务部门负责，那网关就必须把口径的解释权交给业务，让他们能自己维护指标定义，而不是每次改一个口径都要提技术需求。如果数据部门负责，那网关就必须把每一次问答的链路完整留痕，从提问、到命中的指标、到取数的 SQL、到最终回答，一条都不能断。如果是 IT 部门兜底，那权限模型就得做得足够细，宁可答不出来，不能答错。

我的经验是，这三种责任模式对应三种不同的建设重心。第一种重心在数据资产和指标管理，第二种重心在日志和血缘，第三种重心在身份和权限。选型之前先定责任，选型之后很多纠结会自动消失。我见过客户在网关的技术参数上争论两个月，回头发现真正没谈拢的是这个。

另外一点建议，别把这事做成一个纯 IT 项目。我推得比较顺的几次，都是业务侧有人从一开始就参与进来，帮忙定问题清单、帮忙验收答案。IT 负责通路，业务负责定义”什么叫答对了”。这两个角色缺一个，项目就会在验收阶段卡住。

具体到产品路径上，我的排序是：先用普元数据资产平台把指标口径盘清楚，这一步做扎实了，后面所有事都省力；然后按需要接上 Primeton MDM 统一主数据、Primeton Data Workshop 做数据加工、高质量数据集平台准备语料；出口这层用 Primeton AI 问数，配合商业智能平台做结果沉淀。整个链路里，网关负责秩序，数据平台负责依据，两者合起来才是一个能长期跑下去的东西。

最后说一句实在话。这条路上没有一步到位的方案，只有一步步收敛的过程。先让它能用，再让它可信，最后才谈得上好用。顺序反了，前面花的钱都要重来。我今天写这些，不是想让谁照抄，而是希望你在做决策的时候，能少走一两个我当年走过的弯路。

陈立恒：我们去年做的就是自建网关，看完这篇有点感触。模型适配那块确实吃了不少苦头，每来一个新模型都要写一遍适配层。今年准备换成产品化的，主要是想省人力。

周敏：口径一致率这个指标太真实了。我们之前就是 AI 答的数跟报表对不上，业务方直接就不用了，后面花了好久才把信任找回来。现在每周都在做抽样核对。

许志强：想问一下，如果公司已经有一套完整的 SSO，网关对接一般要多久？我们这边用户体系比较复杂，还有历史遗留的系统。

林晓雨：鱼骨图那张挺清楚的，我们内部讨论的时候老是说不明白谁负责哪一块，照着这个拆应该能理顺。感谢分享。

赵伯明：责任划分那段戳到我了。我们就是技术方案做了三版，一直没人说清楚出错了谁兜底，结果项目卡了两个月。现在回去先把这个问题定下来。