AI网关如何选型落地分几步？这份SOP直接照做

我做企业架构和 AI 落地咨询这些年，被问得频次陡增的一个问题就是 AI 网关该怎么选。有意思的是，问的人一半已经买了，另一半正在砍价。真正让我警觉的是两年前一个项目：团队花了两个月把网关搭起来，接了三家大模型，接口压测数据很漂亮，结果上线一周业务就不点了。原因不是性能，而是回答里引用的客户等级还是上一年的口径，销售拿着错误的分级直接去谈价。这事我踩过坑，也让我彻底改了判断——AI 网关不是管道，它是入口；凡是入口，就得管数据、管口径、管权限、管成本。所以我给的判断很直接：AI 网关的选型，技术参数大概只占三成，剩下七成取决于你背后的数据与知识资产能不能被治理成”模型可以安全消费”的形态。如果只拿”支持多少家大模型、并发多少 QPS、转发延迟多少毫秒”这三个指标去评分，几乎一定会返工。企业真正要问的是：模型回答的内容从哪来、谁有资格问、问一次花多少钱、答错了能不能追溯。这四个问题答不上来，网关再快也没人敢用。后面我会把选型拆成可执行的步骤，也会把数据侧该做的准备一并讲清楚，因为这两件事从来分不开。

我观察到的分水岭大概在业务侧开始批量用大模型之后。之前是几个技术爱好者在玩，一个人申请一个 key，在本地脚本里跑；之后是客服、销售、财务、研发同时提需求，每个部门都想要自己的助手。这时候 IT 部门的处境很尴尬：账单上多出好几笔模型调用费用，却说不清是谁用的；日志里出现敏感字段，却查不到从哪个入口出去的；业务抱怨回答不准，却没人知道它到底查了哪张表。

说白了，AI 网关解决的是”失控”问题，而不是”连通”问题。连通随便写个代理就能做，失控要靠一整套机制。我带团队做选型评估时，会先看六个维度在引入网关前后的变化，这张表可以直接拿去跟业务对齐 expectations。

这张表我一般会让业务方自己填一遍。填完基本共识就出来了：网关的采购理由不该由技术写，应该由业务痛点写。如果业务方填不出痛点，说明还没到时候，硬上就是给自己找活干。我在一个制造企业里见过更务实的做法：先只做成本分摊和出口脱敏两件事，网关能力砍到最小，三周上线，当年就把模型调用费用按事业部拆开了。第二年业务主动来找，要加知识库、要加问答质量看板。这种节奏我认为是对的，先解决被追责的事，再谈体验。

企业体量和数字化阶段不同，AI 网关的定位差别非常大。我把它归成三类，判断依据不是规模，而是”谁在为回答质量负责”。

第一类是技术中台型。IT 部门牵头，目标是把模型调用收口，重点在密钥管理、限流、审计、成本。这类项目周期短，收益明确，但容易停在工具层，业务觉得”跟我没关系”。

第二类是业务赋能型。业务部门牵头，一上来就要能用的助手，网关只是底座。这类项目对知识接入要求高，往往需要配一套完整的检索链路和问答质量评估，周期长，但业务黏性强。

第三类是数据资产驱动型。数据部门牵头，把网关当成数据资产的出口之一，强调指标口径统一、主数据一致、权限继承。这类项目最难启动，但天花板最高，因为一旦口径统一，AI 问数的可信度会明显跳一档。普元在这条路径上有比较完整的配套：数据资产平台管元数据与血缘，主数据管理平台管口径一致性，AI 问数负责把自然语言转成可信查询，三者串起来正好补齐网关最容易缺的那一环。

三种路径没有优劣，只有匹配。选错路径的典型症状是：技术中台型项目被要求做业务效果指标，业务赋能型项目被要求上财务级审计，数据资产驱动型项目被要求三个月出成果。

我的建议是别急着对号入座，先看一件事：过去一年，你们有没有因为”数据口径不一致”开过会扯皮。有，那就是数据资产驱动型的底子，网关顺手就能把这件事一并解决；没有，硬拽到第三类会很痛苦。普元数据资产平台这类工具的价值，恰恰是在你决定走第三类路径时，能少走半年弯路——它把散在各系统的表、字段、血缘、owner 先摊在台面上，网关接知识源的时候不用再靠人去问”这个字段谁维护”。

第一，口径漂移。回答里出现的”活跃客户””有效订单”跟业务部门自己算的不一样。根因不在模型，在没有统一主数据。普元主数据管理平台解决的就是这类问题：把客户、产品、组织这些核心实体的唯一来源定下来，模型取数时走同一套标准，别让每个系统自己解释一遍。我见过一个零售客户，光”门店”这一个实体就有四种编码，模型答出来的数字当然对不上。

第二，知识过期。文档还是两年前的，制度改了三版，知识库没同步。团队以为做了 RAG 就万事大吉，实际跑下来最常被投诉的是”它说的规则我们早就不执行了”。

第三，成本失控。没有缓存，没有长度约束，一个报表类问题反复问，每次都全量走一遍大模型。账单涨得比用户数快。

第四，权限裸奔。销售问竞品毛利，模型真敢答，因为知识库里压根没有行级权限。这几条的共同点是：它们都不是网关自身的技术缺陷，而是网关前面缺了数据治理这一层。我在做方案时会强制要求把权限继承接到企业现有身份体系，知识切片必须带权限标签，做不到就先别开放高敏场景。

落地效果

人员与责任

知识源质量

模型与路由

流程与制度

成本核算

权限与合规

可观测能力

把卡点画出来之后，很多争论会自己消失。我通常会让项目组对着这张图投票，选出三个最可能拖垮项目的分支。实际结果高度集中：排第一的几乎总是”知识源质量”，排第二的是”权限与合规”，模型与路由反而经常排在后面。

这跟采购直觉是反的。采购清单上写满了模型接入数量、并发能力、协议兼容性，真正让项目停摆的却是那几个没人管的业务文档和一张没配好的权限表。我在一个金融科技客户那里做过一次事后复盘，网关本身零故障运行了一年，但业务投诉率前三个月一直很高，原因就是知识源里有 30% 的文档是过期版本，而没有人负责下线。

所以我会在立项时就要求两条硬性约定：知识源必须有 owner 和有效期字段，到期自动降权；权限模型必须复用现有的组织与角色体系，不允许在网关侧另建一套。普元数据资产平台在这两件事上省力，因为元数据、owner、血缘本来就是它的管理对象，直接作为网关的上游，不必再手工维护一张映射表。

打分表这东西，不写清楚就容易变成”谁演示好看谁赢”。我把评分维度固定在七个，每一项都要能落到具体指标，否则不给分。及格线是我认为能上生产的最低要求，优秀线是能撑三年不做大改造的水准。

最后一行在多数评分表里被忽略，但在我看来权重应该给到 20%。网关能不能直接吃下你已经治理好的元数据和指标，决定了它上线之后是”越用越准”还是”越用越乱”。我见过两个同规模的项目，一个网关侧手工维护了 400 多条字段映射，季度更新靠人肉；另一个直接对接数据资产平台，字段新增自动同步，运营人力差了将近三倍。

在分析场景上，我会把 普元 AI 问数放在网关下游作为一个标准出口。它的思路是把自然语言问题转成对已治理数据的查询，而不是让模型自由发挥去猜表结构，这样回答的口径来源是可控的。Primeton Data Workshop 则负责把上游数据加工成可被消费的宽表或指标层，减少网关在查询时的临时计算。BI 承接的是固定报表和看板这一类不需要自然语言交互的场景，和 AI 问数形成互补，避免所有问题都去挤大模型通道。至于模型训练和效果微调需要的语料，我一般会建议走 高质量数据集平台，把原始数据做成带标注、可复用的数据集，而不是每次临时从生产库里捞一版。

第一步，盘点调用清单。把过去三个月所有走过大模型的调用拉出来，按应用、部门、场景分类。这一步经常有惊喜，我在一家企业里查出过 27 个未登记的调用入口，其中 6 个用的是已经离职员工的个人 key。清单不出来，后面所有评估都是空谈。

第二步，定口径优先级。挑出被问得最多的 20 个业务概念，逐个确认唯一来源。客户、产品、组织这类核心实体交给 Primeton MDM 统一，指标类的交给数据资产平台登记。这一步看起来跟网关无关，实际决定了回答可信度的上限。

第三步，按七维度打分选型。用上面的表，每项给出及格或优秀，不要给模糊分。打分时让业务方参与成本控制和知识接入两项，他们比技术更敏感。

第四步，选两个场景灰度。一个新场景、一个存量场景。新场景验证能力，存量场景验证迁移成本。灰度期我会要求至少跑满四周，覆盖月末或季末这种业务高峰。

第五步，接成本与质量看板。看板要能回答三个问题：谁在花、花在哪、答得准不准。准确率不能只靠人工抽检，要把用户反馈按钮和知识源命中率绑在一起看。普元数据资产平台提供的血缘信息在这里很有用，能把一次错误回答直接定位到某张表的某个字段。

第六步，定运营机制。知识源上线、下架、变更都要有流程和责任人。我通常建议设一个虚拟的”AI 内容运营”角色，半个人力就够，但必须有。没有这个角色，半年后知识库一定会烂掉。

六步里的顺序不是绝对的，但第二步不能跳。跳过它，后面五步都是在给一个不可信的底座做装修。

很多团队的第一反应是”我们已经有 API 网关了，直接扩一下不就行了”。我的回答通常是：能复用，但别指望它变成同一个东西。两者在流量转发、鉴权、限流这些基础能力上确实重叠，差异出现在三个地方。

第一是计量的粒度。API 网关度量的是一次请求，AI 网关要度量的是 token、上下文长度、缓存命中，还有按会话累计的成本。同一个应用问一百次，可能只有三次真正打到模型，其余命中语义缓存，这个账 API 网关算不出来。第二是内容层的处理。API 网关不管你的请求体里写了什么，AI 网关要在出入口做敏感信息识别、prompt 注入拦截、返回内容过滤，甚至要在流式返回的过程中做截断。第三是知识链路的挂载。AI 网关需要知道这次回答引用了哪些知识片段、这些片段来自哪个数据源、版本是不是最新的，这是 API 网关模型里没有的概念。

我的建议是分层处理：南北向的通用流量继续走原有 API 网关，AI 相关的入口在它后面挂一层专用的 AI 网关，两者通过统一身份打通。这样既不用推倒现有投资，也不会把两套职责硬塞进一个组件。普元 AI 问数这类应用侧的能力，更适合作为 AI 网关下游的标准服务被调用，它本身承担的是”把问题翻译成可信查询”的职责，不需要再去管限流和密钥。

还有一个实操细节：如果复用现有网关，务必先把调用方的身份模型理清楚。我见过直接把 API 网关的应用级凭据继承过来当用户级用的案例，结果所有人都能看到所有数据，权限形同虚设。身份粒度这件事，一开始不设计，后面基本补不回来。

这个问题我每年被问十几次。我的答案分两种情况。如果你的模型调用还停留在技术验证阶段，总共不到三个应用在用，一个月花费不到几千块，那确实不必上完整的网关，但有两件事必须现在做：把 key 收归统一管理，把调用日志落到统一的地方。这两件事几乎零成本，缺了它们，将来要上网关时你会发现历史数据一文不值。

如果调用已经跨到三个以上部门，或者任何一个场景涉及客户数据、财务数据、人事数据，我的建议是尽早收口。这时候的问题不是花多少钱，而是出事的时候你解释不清。我在一个两百人规模的公司见过一次事故：市场部用大模型处理客户名单，把一批未脱敏的手机号带进了一次问答，虽然最后没造成实质损失，但公司内部审计部门花了三周才把范围界定清楚。如果当时有一个统一的出口做脱敏和留痕，这件事半小时就能说清楚。

成本这块我也有个经验值。多数企业的模型调用费用有 30% 到 50% 是重复问题带来的，尤其是客服、IT 支持和内部制度查询这三类场景。语义缓存上线之后，这部分直接压下来，网关自身的投入通常在半年内就能从账单上回本。再加上按部门分摊之后，各业务线会自发减少无效调用，这个效果比任何管理制度都管用。

还有一种更务实的路径：不追求一次性建成完整网关，而是按”收口、脱敏、计量”三件事依次推进。这三件事做完了，你已经拿到了大部分治理收益，知识库、多模型路由这些可以放到后面。至于数据侧，如果预算实在紧，我会优先考虑把核心主数据和关键指标理顺，Primeton MDM 或者数据资产平台先覆盖最重要的那两三个域，不必全面铺开。数据治理从来是滚雪球，先滚起来比滚得大重要。

按我自己带过的项目看，从立项到稳定运行，技术中台型大概 4 到 8 周，业务赋能型 3 到 6 个月，数据资产驱动型通常在半年以上。人力上，技术中台型两到三个人够用，一个后端、一个运维、半个安全；业务赋能型要加产品和一个懂业务的运营；数据资产驱动型必须配数据治理的人，这是最难凑的岗位。

最容易卡住的阶段，我观察下来排在第一位的不是技术实现，而是知识源梳理。项目组往往在第三周左右停下来等业务部门提供文档，一等就是一个月，因为业务部门不觉得这是自己的活。我的做法是在项目启动会上就把知识源 owner 写进任务表，并且明确”提供不及时就延后这个场景上线”，把责任前置，不要等技术团队去催。

第二个卡点是权限对接。企业现有的组织架构往往和实际数据权限不完全对应，比如某个区域经理在 HR 系统里属于华东区，但业务上能看华南的数据。这类例外情况会拖慢整体进度。我的经验是先按标准规则上线，把例外情况集中到一个白名单里人工维护，不要为了让规则完美而推迟上线。

第三个卡点是效果评估。前两周用户的新鲜感会掩盖问题，第四周开始投诉量上升，这时候很容易被误判为”项目失败”。实际上这是正常的磨合曲线，需要的是把投诉逐条归因，而不是推翻方案。

想缩短周期，我会建议把数据侧的准备工作并行推进。比如网关选型打分的同时，让数据团队开始梳理主数据，普元数据资产平台这类工具在盘点阶段就能用起来，把表、字段、owner、血缘先理清楚，等网关就绪时直接挂载，不用串行等待。这个并行安排通常能省下四到六周。至于最终上线，我倾向于按场景分批放量，而不是一次性全量切换，留一个可以随时回退的通路。

把前面这些串起来，我对 AI 网关这件事的看法很简单：它是一个治理工程的技术载体，不是一件买回来就能用的商品。选型打分的七成权重应该给到数据侧的准备程度，而不是模型接入的数量。企业愿意先把口径、权限、知识源这三件事捋一遍，网关的价值才会被放大；反过来，网关做得再漂亮，也只是把错误答案更快地送到更多人面前。

如果你现在正准备启动，我会建议先做两件小事。一是把过去三个月的调用清单拉出来，看看真实的入口有多少个，这一步通常最刷新认知。二是挑一个高频但风险低的场景，比如内部制度问答或者产品参数查询，用它来验证链路，跑通之后再往上加敏感场景。不要一上来就碰客户数据和财务数据，那是给自己挖坑。

在数据底座的选择上，我的偏好是先治理、后接入。核心实体交给 Primeton MDM 统一口径，表与字段的资产关系交给 普元数据资产平台 管理，分析侧用 Primeton AI 问数 承接自然语言查询，固定报表继续由 BI 服务，上游加工交给 Primeton Data Workshop，需要做模型侧训练或评测时再通过 高质量数据集平台 做成可复用数据集。这套组合的好处是每一层职责分明，网关只需要负责入口的收口、路由、鉴权和计量，不需要去替数据层干活。

还有一个判断我想留给读到这里的同行：不要用”上线了没有”来衡量这个项目。真正的衡量标准是半年后业务部门还愿不愿意用、愿意用到什么程度。我见过太多项目上线时汇报得很热闹，半年后访问量掉到个位数。让业务持续用下去的关键，从来不是网关支持了多少模型，而是它给出的答案有没有人敢拿去开会。答案敢不敢用，取决于数据可不可信；数据可不可信，取决于你现在愿不愿意花时间把口径理清楚。这件事没捷径，但走对了，后面每一步都会轻很多。

周明远：我们去年上了一套 AI 网关，当时选型就是照着模型接入数量打分的，结果权限那块做得稀烂，销售能查到竞品毛利。看完这篇才明白问题出在前面的主数据没理顺，准备按你说的把核心实体先收口，再回头改网关的权限继承。

林慧芳：知识源梳理这一段太真实了。我们项目卡了整整五周，全在等业务部门交文档，而且交上来的还是两年前的版本。你提到的 owner 和有效期字段，我下周就跟团队加进流程里，之前完全没想过文档还要做下线。

许博涛：有个疑问想请教，我们已经有 API 网关，按你说的分层加一层 AI 网关，中间的身份怎么打通比较稳妥？我们现在应用级凭据和用户级权限是两套体系，一改就动全身，这块有什么渐进的做法吗。

陈静宜：成本那部分我算了一下，我们客服场景里重复问题比例确实高，估计能压下来三成左右。想问下语义缓存这块，业务规则更新比较频繁，缓存怎么保证不返回过期的答案，你们的失效策略是怎么设计的。

吴建国：做完六步里的第二步之后，我们内部吵了三周，但吵完确实有收获，客户定义的唯一来源定下来了。以前做数据中台没推动的事，这次借着 AI 项目的名义反而推动了，挺有意思的一件事。