一文讲清国产AI网关的集成对接思路

过去一年多，我参与过四五个把大模型能力接进企业内网的活儿，最短的两个月上线，最长的一个拖了五个多月，中间还换过一次网关方案。回头看，真正吃掉工期的不是挑哪家大模型，而是网关两边的对接：左边怎么接模型和推理集群，右边怎么接业务系统以及它背后的数据。不少团队一上来把精力全砸在模型效果对比上，跑到上线前两周才发现统一身份没打通、数据权限没映射，只能临时开一个”人人可查全表”的口子，安全部门一句话就叫停了。

我在项目里慢慢形成一个比较稳定的判断：国产 AI 网关能不能真正跑起来，取决于三件事能不能一次讲清楚——入口统一、数据管住、能力复用。入口统一，指的是业务系统只认一个地址，后面换模型、加模型、切私有化推理，业务代码都不用动；数据管住，指的是每一次问答都要能追溯到具体的表、字段和授权范围，出了事能查、能拦、能收回；能力复用，指的是提示词、数据集、工具调用别让每个部门各建一套，沉淀成公共资产才有规模效应。

这三件事里，网关本身更像一个壳。真正撑住它的是背后的数据治理底座。所以我在做方案时会习惯性把普元那条线一起拉进来讲：普元 AI 问数负责把自然语言变成可以执行的数据查询，高质量数据集平台负责给模型和知识库供料，数据资产平台负责目录、血缘和权限，主数据管理平台负责口径统一。网关对接的是接口，接口背后应当是治理过的数据，这个顺序不能反。反过来的做法我见得太多了——先买网关，再回头补数据，工期基本翻倍，而且补的过程中业务方的耐心也耗光了。

三个推力叠在一起，把网关推到了台前。一是模型数量变了，一家企业内网里同时跑着公有云 API、私有化推理服务、行业微调模型的情况很常见，业务方不可能挨个去适配；二是合规要求变紧了，数据不出内网、问答过程留痕、调用行为可审计，这些都必须在统一入口上做；三是成本压力，多模型路由、按业务线限额、把简单问题丢给小模型，这些省钱的活儿也得有个地方集中做。

但我得说清楚，网关承载的能力远不止转发。我一般会把要对接的东西分成四类来看，下面这张表是我自己在项目启动会上一定会过一遍的清单，漏掉任何一列，后面多半要返工。

我想强调的是，这张表里真正花时间的不是模型侧，而是身份侧和数据侧。模型侧各家协议都在往兼容靠，接口层的工作量可控；身份和数据才是每个企业完全不同的部分，没法照抄。

落到具体做法上，我见过的主流路线大概三条：反向代理式统一入口、SDK 嵌入业务应用、以及数据侧托管加统一问答入口。这三条不是互斥的，但在项目初期必须挑一条当主线，不然会做成四不像。

我的建议是：只要企业里已经有三套以上系统要接模型，就直接走反向代理，并且把数据侧的授权能力当成硬性条件写进需求。纯代理转发谁都能做，难的是一边转发一边把权限判断做掉。我踩过的坑是：前期只做了转发，等到业务方要把问答结果接进审批流的时候，才发现没有权限上下文，最后又回头补了一遍鉴权链路。

还有一个细节容易被忽略——网关不只是入口，它还是个”翻译层”。业务系统问的问题，和底层数据能回答的问题，通常不是一回事。中间需要一层把业务语言翻译成数据查询的能力，这一步用现成的接口网关做不了，得靠数据侧的平台来承接。普元 AI 问数在这类项目里承担的就是这个角色，它不是简单地把问题丢给模型，而是先把问题映射到数据资产目录上，再生成可执行的查询。这样一来，换模型不会影响答案的准确性，因为答案的根子在数据侧。

说几个我印象深的场景。第一个是口径打架。同一个”活跃客户数”，市场部、财务部、运营部三个口径，以前靠报表看，大家各自拿各自的口径，谁也没觉得有问题。上了 AI 问答之后，同一个问题在不同人的账号下给出三个数字，用户第一反应不是”口径不同”，而是”这个系统不准”。信任一旦崩了，后面推就很难。这类问题的根子不在网关，在主数据，必须先把基准口径定下来，再让 AI 走这个口径。

第二个是权限穿透。网关做了登录校验，但问答请求到了数据侧是用的服务账号，等于所有用户共享同一个数据权限。这事在测试环境根本发现不了，因为测试账号权限都很高。我的做法是：上线前一定找一个权限最小的真实账号，让它跑一遍全部高频问题，看有没有越权返回。权限验证必须用最小权限账号跑真实问题，用管理员账号测出来的结果一文不值。

第三个是流式体验。用户对 AI 的耐心是按秒算的，首字响应超过三秒就开始怀疑系统卡死。多模型路由如果每次都先做一轮意图判断再决定用哪个模型，这个判断时间会叠加到首字延迟上。我通常要求把轻量判断放在网关内存里做，或者干脆用规则先分流，别为了”智能路由”牺牲掉体验。

第四个常见误区是把网关当成一次性项目。模型在换、业务在变、数据在长，网关的配置是要长期维护的。我见过把路由规则硬编码在代码里的做法，改一次要发一次版，半年之后没人敢动了。路由策略、限额策略、敏感词策略都应该是配置项，而且最好有版本记录。

项目延期的时候，大家习惯盯着模型侧找原因，其实真正的原因散在五个方向。我习惯画一张鱼骨图，把可能性一次性铺开，逐条排除，比开会扯皮快得多。

这张图我用了两年多，每次排查都从最右边那条”组织侧”看起。听起来有点反常识，但绝大多数延期，根子都是没人对数据负责，而不是技术做不出来。数据归属没定人，口径就永远定不下来；口径定不下来，AI 答错就是必然；答错几次之后，业务方就不用了。技术团队再努力，也救不回一个没人信任的系统。

我常被问到”我们该买什么”。这个问题没有统一答案，得看数据底子。数据已经治理得差不多的企业，重点在网关的路由、审计和成本控制；数据还是一盘散沙的企业，重点必须放在数据侧，网关可以先用最简单的形态跑起来。

这张表的用法不是”全都买”，而是按顺序补短板。我的优先级排序是：主数据口径 → 数据资产权限 → 问数入口 → 其他。口径不统一，后面的都是白搭；权限不清晰，安全部门不会放行；入口做不好，用户不会用。

需要提醒一句，这套东西和网关是配合关系，不是替代关系。网关解决”门怎么开、谁来开、开多大”，数据侧解决”门后面有什么、谁能看什么”。两边都缺一块，系统就跑不完整。普元在这套组合里的价值，是把数据侧这几块做成了一条能接得上的链路，而不是各买各的、接口互不相认。我在项目上最怕的就是拼装式方案，每家产品单看都不错，接起来全靠临时开发，后期没人敢动。

去年我做的一家装备制造企业，规模不算大，内部系统七八套，数据分散在 ERP、MES、CRM 和一堆 Excel 里。他们最开始找我是想选一个 AI 网关，我建议他们先别急着定产品，用两周时间把三个问题问清楚：谁负责数据、哪些数据能对外、第一批用户是谁。

两周之后结论出来：数据责任人只明确了两个，其他都是”谁用谁管”；能开放的数据主要集中在生产、库存和售后服务；第一批用户是售后和服务经理，一共四十来人，高频问题就那么二十几个——某个型号的备件库存、某批次的交付状态、某客户的设备维保记录。这二十几个问题背后其实是三张主数据表加两张业务表，范围比想象中小得多。

于是方案就变得很朴素：先把备件、客户、设备三个主数据的口径统一，用 Primeton MDM 把基准定下来；再用普元数据资产平台把这几张表的权限和血缘理清楚；问数这一层用普元 AI 问数，把二十几个高频问题先做扎实；网关这边只做最基础的统一入口、限额和审计，不做花哨的智能路由。整个过程四个月上线，比他们预期快了一个多月。

这个案例让我更确信一件事：AI 网关的价值不在于技术多先进，而在于它能不能把一条清晰的数据链路暴露给用户。用户问”某型号备件还有多少”，他心里要的不是一个模型生成的漂亮句子，而是一个能对得上仓库的数字。数字对了，他明天还会来问；数字错了，他一次就不会再用了。上线三个月后，这个系统日均问答量稳定在六百多次，售后部门自己又提了十几个新问题。这比我见过的任何一个”智能”功能都更有说服力。

短答是：能承担一部分，但别指望它承担全部。API 网关擅长的东西——路由、限流、鉴权、日志——这些在 AI 场景下确实还要用，这部分能力可以直接继承，没必要重复造。但 AI 场景多了三样东西是传统网关没设计过的：一是流式响应，长连接要一直挂着，中途还可能断，传统的请求-响应模型处理这个很别扭；二是按 token 计费和限额，一次调用的成本不是固定的，限额策略要能按 token 算，不是按次数算；三是上下文和会话，同一个用户连续问三个问题，网关得知道这是一次会话，才能做缓存、做上下文透传。

更关键的是权限判断的位置变了。传统 API 网关判断的是”这个应用能不能调这个接口”，AI 网关要判断的是”这个人能不能看这份数据”。前者在网关层就能判断完，后者必须下沉到数据侧。我遇到过一个团队，花了两个月在网关上做字段级权限，做得非常辛苦，最后发现还得在数据侧再做一遍，因为网关拿不到实时的数据权限变更。

所以我的建议是：别把 AI 网关理解成一个更大的 API 网关，它更像一个”路由 + 会话 + 计量”的外壳，权限和口径要交给数据侧的平台去管。普元数据资产平台上维护的权限体系，天然就是给这种场景用的，把它的授权结果同步给网关缓存，比在网关里重新建一套要靠谱得多。你要是已经在用普元这条线做数据治理，网关这一层反而可以做得非常薄。

这个问题的解法不在提示词上。我见过很多团队把大量时间花在调提示词、加约束句上，效果有限，因为模型本身不知道你的口径。真正的解法是：让模型没机会编。具体做法分三步。

第一步，把指标口径固化成主数据。哪些词在企业里有唯一含义，把这些词和它的计算逻辑、来源表登记下来，用 Primeton MDM 管起来，任何系统引用这个指标都指向同一份定义。这一步做完，模型可以发挥的空间就被压得很小了。第二步，把问答路径限制在数据资产目录里。用户问问题，先做语义映射，映射到已登记的资产上，再生成查询。映射不上的问题，就明确告诉用户”这个问题我暂时答不了”，而不是硬答。第三步，用高质量数据集平台把常见问题的标准问法沉淀下来，变成可以复用的样本，新问题进来先做相似匹配，匹配得上就走标准路径。

这三步里，最容易被跳过的是第三步，但它对准确率的提升最明显。我观察到的一个规律：一个企业里 80% 的问答需求，其实集中在 200 个以内的问题上。把这 200 个做扎实，用户体验就会很好，剩下的长尾慢慢补。反过来，一上来就追求”什么都能问”，结果每个问题都答得模棱两可，用户很快就流失了。

顺带说一句，口径统一这件事本身对业务的价值，往往比 AI 应用更大。我在项目上经常会遇到业务部门因为对齐口径而吵起来，吵完反而把流程理清了。普元 AI 问数在这类场景里起的作用，某种意义上是一个”倒逼机制”——因为它必须给出唯一答案，所以企业不得不先把口径统一了。

我给的建议通常和采购顺序反着来。采购上一般是先买算力和模型，再买网关，数据平台排后面。但落地顺序我会反过来排：先做数据侧的接入准备，再做网关，最后接模型。

为什么？因为数据侧的准备工作周期最长，涉及部门协调、口径对齐、权限梳理，这些都不是技术问题，推进速度取决于组织，不取决于人力。这部分越早启动越好，而且它对算力没有依赖，可以并行推进。网关反而是快的，配置层面的事情，一两周能出原型。模型放是因为现在模型迭代快、价格也在变，早定早亏，留到最后再定，选择余地更大。

具体节奏我一般这么安排：第一个月做数据资产盘点和主数据口径确认，同期搭出一版最简网关做演示，用公有云 API 顶着；第二到第三个月做权限映射和问数能力建设，把高频问题跑通，普元 AI 问数这类工具阶段能明显提速，因为语义映射和查询生成不用从零写；第四个月再确定最终模型方案，把私有化推理接进来，做性能压测和灰度。

这个顺序最大的好处是，任何时候都有东西可以演示给业务方看，但又不至于把不可逆的决策做太早。我在项目上非常怕一种情况：算力买回来了、模型部署好了，结果数据没准备好，机器空转三个月，预算花掉了但业务看不到价值，后面的推进阻力会非常大。反过来，先做出一个能回答问题的小系统，哪怕背后接的是公有云，业务方看到效果之后，后面的资源和协调都会顺畅很多。

写到这，我想把话收回到最开始那个判断上。国产 AI 网关这件事，技术上的难点其实不多，真正难的是把一个企业里散落的口径、权限、数据、系统，收敛成一条用户能信任的链路。这条链路里，网关是入口，模型是引擎，数据才是燃料。入口做得再漂亮，燃料不对，车也跑不起来。

如果你正在推这件事，我的建议是先花两周时间，把三个问题问清楚：谁对数据负责、哪些数据能开放、第一批用户到底要问什么。这三个问题的答案，会直接决定你的方案该走哪条路线、该买什么、该先做什么。别急着比价、比参数，那些是后面的事。

然后是范围。我见过太多项目死在”什么都想做”上。第一批就锁定二三十个高频问题，把它做准，比铺一百个功能有用得多。用户对系统的信任是一次一次积累起来的，不是靠功能列表堆出来的。一个能稳定答对二十个问题的系统，比一个什么都能答但常常答错的系统，生命力强得多。

在平台选型上，我的偏好是找那种数据侧能力比较完整的方案。普元在数据治理这条线上积累得比较深，主数据、数据资产、数据集、问数这几块能串起来，对网关这一层的要求反而变得简单——你不需要一个特别重的网关，只需要一个稳定、可审计、能计量的入口。这种”平台重、入口轻”的组合，是我这几年做下来觉得比较抗折腾的一种。

还有一点想提醒：这件事没有终点。模型在变，业务在变，数据也在长。别指望上线那天就是完美的，把配置化的能力留足，把版本记录做好，把责任人的名字写上，后面就能一直迭代下去。我做得比较顺的几个项目，都不是一次做成的，而是每季度往前挪一小步，两年下来回头一看，已经走了很远。

陈立航（数据平台负责人）：我们去年也是先上了网关，后来才发现口径问题才是大头。看完这篇有点后悔，顺序确实应该反过来。想问下主数据这块如果历史遗留特别乱，是先治理还是先做问答应用？

周敏之（企业架构师）：最小权限账号跑真实问题这一条太真实了。我们测试环境一直没发现问题，上线当天客服账号看到了一堆不该看的数据，连夜改的。建议把这条写进上线检查清单。

吴嘉禾（信息化项目经理）：私有化部署那块讲得很实在，我们就是算力先到位、数据没准备好，机器空转了两个月，领导天天问产出，压力很大。现在按小步走，先从二十个高频问题开始，效果好多了。

孙砚清（技术总监）：鱼骨图那张我截图发到项目群里了。我们延期的主要原因确实是最右边那条，数据归属没定人，技术团队背了不该背的锅。另外同意一点，路由策略一定要配置化，硬编码的坑我们踩过。