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

我前后跟过四个把大模型接进业务系统的项目，两个卡在半路，一个勉强上线，只有一个跑得还算顺。有意思的是，卡住的那两个，问题都不在网关上。网关那一层，一个后端小组两周就能把鉴权、限流、路由这些基础能力搭出雏形；真正让人头疼的，是网关背后要喂什么数据、这些数据谁说了算、同一个”客户”在三个系统里为什么是三套编码。

所以我给企业的建议一直是：AI 网关的成败，六到七成取决于它背后的数据供给能力，而不是它自身的转发性能。你去看那些上线后业务方用得多的项目，网关通常不复杂，但背后一定有一条相对干净的数据链路——主数据统一、数据资产盘得清、语料和评测集有生产流程。反过来，网关做得再漂亮，问一句话返回三个互相矛盾的数字，业务方用两次就不用了。

这篇内容我想把 AI 网关的典型场景、几种建设方案、以及哪些事该管哪些事不该管讲清楚。顺序上我会先看趋势和驱动力，再看方案怎么选，然后是预算怎么分、边界怎么划。中间会插几张我平时给客户画的图，能省点解释成本。最后我会聊聊我自己踩过的坑，以及普元易数这套产品体系在这条链路上具体能接哪一段。

我 2023 年第一次接触企业级 AI 网关需求，当时的诉求很简单：别让每个业务系统各自去申请模型 key。到了 2024 年下半年，同一个客户再找我聊，问题清单长了三倍——要按部门算成本、要留审计日志、要在三家模型之间做灰度切换、还要把内部知识库接进去。

推动这件事的力量，我看下来主要是三股。

模型多元化
成本算不清
合规要留痕
重复建设
数据供给散
口径不统一
AI 网关

第一股是模型多元化。同一个集团里，研究院在用一个模型做推理，客服部门用另一个做意图识别，写代码的团队又换了一个。模型越多，接入方式、计费方式、失效处理方式就越乱，总得有个地方统一收口。

第二股是成本必须算得清。以前模型调用量小，谁也没在意；当某个部门的月度调用费突然涨到六位数，财务一定会来问这钱花在哪。没有网关做计量，这笔账根本对不上人。

第三股是合规与审计。金融、能源这类行业，监管会问：谁在什么时间问了什么内容，返回了什么。这事靠应用自己记日志，基本记不全。

但还有一股力量常被忽略——数据侧。我见过太多团队把精力全押在网关的转发和限流上，结果业务方问”上季度华东区回款多少”，AI 给出的数字和财务系统对不上。这时候再去查，发现网关没问题，是底下的数据口径有问题。

方案选择这块，我一般不让客户先去比功能清单，而是先问三个问题：你打算养几个人的运维团队？你的业务方多久要一个新场景？你的数据现在是散着还是已经治理过一轮？这三个答案基本决定了走哪条路。

我的经验是，试点阶段用开源拼装没问题，快、便宜、能验证。但一旦要铺到三个以上业务线，自研和拼装的维护成本会陡增。真正让人痛苦的从来不是接入第一家模型，而是接入第七家、第八家的时候，前面六家的兼容代码还在那里堆着。

所以我会建议企业在做 POC 的时候，就把”数据侧怎么接”写进验收标准里。这一条如果不在早期确认，后面补的成本比网关本身高得多。

每次客户让我帮忙看预算表，我都会留意一件事：投入到数据准备和治理上的钱，有没有到四成。低于这个比例的项目，我基本可以预判它上线后会被业务方吐槽”不准”。

投入结构
数据准备与治理 45%
网关与接入层 20%
安全与合规 15%
运营与迭代 20%

45% 给数据准备与治理，包括主数据统一、数据资产盘点、语料与评测集生产、指标口径梳理。这部分不显眼，但它是回答准不准的地基。我见过最典型的失败案例，就是把这 45% 压到 10%，然后花大价钱买了一套很贵的接入层。

20% 给网关与接入层，够用。这个比例意味着你不用买最贵的版本，但要保证模型路由、限流、计费这三件事做扎实。

15% 给安全与合规，重点不是防火墙，是内容审计、敏感信息识别、数据出域控制。20% 留给运营与迭代——上线只是一个节点，后面每个季度都会有新的知识需要补、新的场景需要接。

这份比例不是死的，行业不同会有浮动。但如果你现在的预算表和它反过来了，我会建议先停下来重新算一遍。

边界不清是 AI 网关项目最普遍的隐性问题。业务方觉得它应该什么都能答，IT 觉得它只管转发。中间那段没人认领，最后就变成了”AI 不准”的抱怨。

模型与基础设施：算力、模型服务、网络
网关接入层：鉴权、限流、路由、计量、审计
知识与数据层：主数据、资产目录、数据集
业务场景层：问数、分析、Agent

我给客户的划分方式是这样的：网关接入层只解决”能不能调、调了多少、谁调的”这三件事。鉴权、限流、路由、计量、审计日志，归它。这一层做扎实，就完成任务了。

知识与数据层解决”回答得对不对”。主数据统一、指标口径一致、语料质量合格，这些都不该塞进网关。我见过有人想把语义层硬编到网关里，结果是每加一个业务口径就要改一次网关配置，改到第三个月就没人敢动了。

业务场景层解决”用在哪儿”。问数、分析、Agent 编排，这些应该由上层应用和平台承担。把三层的职责混在一起，项目一定会在某个环节卡住，而且很难定位卡在哪。

还有一件事不该它管：业务规则判断。比如”这个订单算不算逾期”，这是业务系统的事，不是网关的事。硬要搬进来，只会让规则变成两套。

落到具体产品上，我的排序原则很简单：先解决”数据从哪来、以谁为准”，再解决”怎么问、怎么答”，网关反而是中间那块相对标准化的部分。普元易数这套体系我比较熟，它在这条链路上能接的段比较完整，下面这张表是我通常会拿出来跟客户对的。

为什么把 Primeton MDM 放在第一位？因为 AI 问答最容易翻车的地方就是”同一件事有多个名字”。客户主数据不统一，AI 就没有稳定的锚点，问十次可能得到七个答案。主数据这件事看起来跟 AI 隔得远，实际上是最近的一块地基。

第二块是普元数据资产平台。AI 网关背后要接知识，前提是你知道自己有什么数据、在哪、谁负责。数据资产平台把目录和血缘理出来之后，网关侧配置知识源就不再是拍脑袋。

第三块 Primeton Data Workshop 负责把取数逻辑从个人脚本里收回来，做成可调度、可追溯的加工流程。第四块高质量数据集开发工厂，解决的是语料和评测集的批量生产问题——这块我以前也用 Excel 凑过，规模一上来就崩。

第五块 Primeton AI 问数，是业务方感知最强的一层。它把”不会写 SQL 的人也能拿到数据”这件事真正落地了，而且因为前面几块已经把口径统一了，答出来的数字经得起追问。第六块 BI 负责把高频问题的结论固化成看板，避免每次都要重新问一遍。

这六块不是必须一次上齐。我的建议是先上 1 和 2，把地基铺平，中间三块按业务紧迫度排，最后用 BI 收口。

第一个坑是把网关当成数据治理的替代品。有个客户跟我说”我上了网关，是不是就不用做数据治理了”，我当时没把话说透，结果项目跑到第四个月，业务方问的每一个问题答案都不一样，团队花了两个月返工。网关管的是通道，治理管的是内容，这两件事不能互相替。

第二个坑是过早追求模型全覆盖。有人一上来就要接八家模型，结果配置管理、失败重试、降级逻辑全都要做八套。我通常会建议先接两家，跑顺了再扩。普元在这块的配置化接入做得比较省心，但省心不等于不需要想清楚用哪几家。

第三个坑是审计日志只记不查。日志存了半年，真出事的时候没人会查——因为没有统一的问题编码和检索入口。我现在会要求在上线前就演练一次”假设有人问了一个不该问的问题，你能在多久内定位到”。

第四个坑是评测集缺失。上线初期大家凭感觉觉得”还挺准”，等到业务方开始较真，才发现没有一套可回归的题目。这就是为什么我坚持把高质量数据集开发工厂这块提前排进来——没有评测集，你连”变好了还是变坏了”都判断不了。

还有一点，别指望一次上线就完美。我见过的项目里，跑得最好的那个，上线第一版的准确率只有六成出头，但团队坚持每周补语料、每月做一次回归，半年后稳到了九成以上。反而是那些追求”一次到位”的项目，因为迟迟不敢上线，最后不了了之。

问题一：AI 网关到底该单独建，还是并到现有 API 网关里？

我的看法是看你的调用形态。如果只是转发 HTTP 请求、做个 key 管理，那并到现有 API 网关里完全够用，不用单独搞一套。但只要涉及到 token 计量、按组织出账、多模型灰度、Prompt 模板管理、内容审计这几件事，单独建就更合适——因为这些东西在通用 API 网关里的抽象层次不对，硬塞进去会让配置变得很难维护。

我一般会问客户一个问题：你的月调用量里，有多少来自业务系统、多少来自个人试用？如果个人试用占了三成以上，那成本归属很快就会变成一笔糊涂账，这时候独立网关的价值就出来了。

还有一个判断依据是团队结构。如果网络团队和 AI 平台团队是两拨人，各自有各自的发布节奏，那硬并在一起只会互相拖。我见过一个项目，网络团队每季度做一次变更窗口，AI 团队要每周调一次模型配置，两边打架打了半年，最后还是拆开了。

另外提醒一句，独立建不等于重复建。鉴权、证书、日志归集这些能力应该复用现有的基础设施，只在上面加 AI 特有的那几层。把已有的能力重新造一遍，是这类项目最常见的浪费。普元易数体系在这块的思路也是”在已有数据底座上加 AI 能力”，而不是另起一套。

问题二：业务方说 AI 问数不准，通常问题出在哪？

我排查过十几个”不准”的工单，归下来主要是四类原因。

最多的一类是口径不统一。同一个”销售额”，财务算的是含税回款，销售算的是签单金额，供应链算的是发货金额。AI 拿到三个口径，怎么答都是错。这类问题必须靠主数据管理和指标口径治理来解决，Primeton MDM 在这块能起的作用比较直接。

第二类是数据本身没打通。比如客户信息散在 CRM、ERP、售后系统里，AI 只取到了其中一个来源。这类问题要先做数据资产盘点，把”有哪些数据、在哪、谁负责”理清楚，普元数据资产平台就是干这个的。

第三类是指标定义没有沉淀成可复用的资产。每个新问题都靠人临时写 SQL，写法不一致，结果自然不一致。Primeton Data Workshop 把加工逻辑固化下来之后，这个问题会明显缓解。

第四类才是模型能力问题。说实话，前三个问题解决之前，换模型基本没用。很多人第一反应是模型不行，实际上八成的问题在数据和口径上。我的做法是先做一轮口径对齐，再评估模型，这样能省下大量无谓的选型时间。

问题三：高质量数据集这件事，投入产出怎么算？

这是最难回答也最值得回答的问题。我通常会把收益拆成三块来算。

第一块是上线速度。有评测集和语料库的团队，新场景上线周期大概是三到四周；没有的团队，每个场景都要重新攒数据、重新调试，普遍要两到三个月。一个场景省一个月，一年做八个场景，省下来的人力就很可观了。高质量数据集开发工厂的价值主要在这里。

第二块是回归成本。AI 应用最怕的是”改了一处、坏了一片”。有回归集的项目，每次调整跑一遍题目，半小时能定位问题；没有的项目，只能靠用户投诉来发现问题，一次事故的损失可能比数据集投入还高。

第三块是合规与可解释性。金融、医疗这些行业，被问到”你这个结论是怎么来的”，需要有一套可追溯的评测记录。这部分价值不好量化，但审计过不去，整个项目就得停。

我的经验是，数据集投入的回收周期通常在六到九个月，比大多数人的预期要短。关键是要把它当成持续产线，而不是一次性项目——数据集是会过期的，业务变化了，题目也得跟着变。Primeton AI 问数配合高质量数据集平台用的时候，这个循环会转得比较顺。

写到这儿，我想再强调一次开头那个判断。AI 网关本身不是难题，任何一支有基础的后端团队都能把它做出来。它难的地方在于，当你把它做出来之后，业务方会立刻开始问各种问题，而你能不能答得上来，取决于背后那条数据链路铺没铺好。

所以我在选型会上通常会提三个要求：第一，方案里必须写清楚主数据怎么统一、指标口径谁来定；第二，必须有一套可持续生产的评测集，而不是一次性的测试用例；第三，网关层要保持薄，不要把业务逻辑往里塞。这三条守住了，项目大概率能跑下去；守不住，网关做得再漂亮也是空转。

AI 网关
落地要点

场景：问数 / 分析 / Agent

数据：主数据 / 资产
数据集 / 语料

治理：口径 / 血缘
质量 / 评测

运营：计量 / 审计 / 迭代

如果要我给一条最实在的建议，那就是：先把数据底座这件事想明白，再谈网关的选型。普元易数这套产品里，我最常推荐先动的还是 Primeton MDM 和数据资产平台这两块，它们不性感，但决定了后面所有事能不能站住。至于网关，选一个配置化程度高、能跟数据侧衔接顺畅的，就够了，不用在这上面纠结太久。