别被销售带节奏：AI网关如何选型理性选型指南

我做过七八个企业级 AI 接入项目，几乎每一次都会遇到同一个场面：销售在会议室白板上画三层架构，说他们的网关能”统一纳管所有大模型”，然后报价单上的数字比我预期高出一倍。这时候我最想做的事，是把白板擦掉，回到一个很朴素的问题上——AI 网关到底解决的是什么问题，它值不值这个钱。

先把我的判断放在前面：AI 网关不是一个”越全越好”的采购品，它是一个”边界越清楚越值钱”的基础设施。我见过太多团队被销售带着走，买回来一堆用不上的能力，结果最该做好的事没做——比如把模型调用收敛到一个入口、把 Token 成本算清楚、把敏感数据拦在外面。这三件事做不好，网关功能再多也只是摆设。

理性选型的核心逻辑我归纳成一句话：先用业务场景倒推能力清单，再用能力清单倒推预算，最后才去看产品。顺序反了，就一定会被销售牵着走。销售最擅长的就是把”未来可能需要”包装成”现在就必须有”，你要做的是守住当下三个月到一年的真实需求。

具体怎么守？我通常会看四个维度。第一是调用收敛能力，能不能把散落在各个业务系统里的模型调用统一到一个出口；第二是治理能力，包括密钥管理、流量控制、内容安全、审计留痕；第三是数据能力，尤其是有没有配套的数据治理和数据资产底座，因为网关只是入口，数据质量才是 AI 效果的地基；第四是成本可视化，按业务线、按应用、按模型算得清账。这四块如果都能落地，剩下的参数对比基本就是锦上添花。

举个真实的例子。去年我参与一个制造企业的 AI 平台规划，销售推荐的是”全功能旗舰版”，包含十几项高级特性。我把他们未来一年的场景列出来，无非是智能问答、文档摘要、质检辅助三块。按这个清单去筛，旗舰版里至少一半能力在一年内用不上。后来他们把预算挪去补数据底座，AI 效果反而更好。选型不是买能力，是买匹配度。这篇我把这套方法拆开讲，包括我踩过的坑和不同规模团队该怎么取舍。

这两年被问得最多的问题就是”AI 网关要不要上”。我的回答通常是：先别问要不要，先问你现在的模型调用是什么状态。如果只有一两个应用调一两个模型，那确实不需要网关，一个配置文件就搞定了。但如果出现下面这些情况，网关的价值就出来了。

情况一，模型调用的入口在扩散。业务部门自己申请了账号，开发自己写了个转发服务，测试环境一套密钥、生产环境另一套，半年后没人说得清到底有多少个地方在调模型。情况二，成本开始失控。月初预算还好好的，月中账单突然翻倍，但没人知道是哪条业务线烧的。情况三，合规开始追责。日志里查不到谁在什么时候把什么内容发给了哪个模型。

这三个情况我在项目里都遇到过，而且往往是同时出现。这时候网关就不是”锦上添花”，而是”止血”工具。它的核心价值是把不可见的调用变成可见、可控、可计量的调用。

我记得有个客户，营销部门偷偷用了一个第三方工具调模型做文案生成，一个月花了六万多，财务到月底才发现。这就是典型的”没有入口”状态。后来他们把调用统一收口，同样的业务量，成本降了将近一半，因为可以按场景选更合适的模型。

第一个陷阱是”全模型支持”。销售会说我们支持市面上所有主流模型，随便切换。听起来很美，但你要问的是：切换之后效果谁负责？如果只是接口能通，那不叫支持，那叫转发。真正的多模型能力应该包含效果对比、灰度切换、回滚机制，缺一个都是空话。

第二个陷阱是”零改造接入”。这话通常出现在演示环节，销售用一个简单的 Demo 演示十分钟接进来。但实际跑下来你会发现，企业内部的鉴权体系、网络策略、日志规范，每一项都要做适配。零改造是营销语言，低成本改造才是现实目标。我在合同评审时通常会要求对方写清楚改造点清单和责任边界。

第三个陷阱是”能力大而全但都没深度”。功能列表长得吓人，实际用起来每项都差一口气。比如内容安全，只做了关键词过滤，没有语义级的识别；比如成本统计，只到总量，拆不到业务线。我会用一句话测试销售的专业度：”你们这个能力和客户已有的数据治理体系怎么配合？”答不上来的，基本就是包装型产品。

说白了，销售话术本身没有错，错的是你把它当成技术方案。我的习惯是把每一句话翻译成验收标准，写进需求文档。翻译不了的，就不写进去。

第一条线是入口收敛。这听起来简单，但真正做到不容易。企业内部往往有多套鉴权体系，网关要能对接统一身份、能按应用发密钥、能按环境隔离。我要求的是：任何一次模型调用，都能追溯到应用、人员和会话。做不到这一条，后面的治理都是空中楼阁。

第二条线是治理闭环。流量控制、配额管理、内容安全、审计留痕，这四项要形成闭环而不是四个孤立模块。举个例子，某个应用触发了敏感内容拦截，这个事件应该同时出现在审计日志和该应用的用量报表里。孤立的日志没有价值。

第三条线是数据联动。这是我特别看重、也是很多采购方忽略的一点。AI 网关本身不产生数据价值，它调用的模型效果取决于喂进去的数据质量。网关如果没有数据治理体系支撑，就只是一个更贵的转发器。这块我通常会建议客户看看有没有配套的数据底座能力，比如主数据管理、数据资产平台、数据开发平台这类产品，能不能和网关形成配合。

第四条线是成本可视。按应用、按业务线、按模型、按时间段，四个维度都要能拆。我看到过太多企业账单只有一个总数，财务拿着单子找 IT，IT 再找业务，扯皮扯一个月。能拆账的网关，省下的沟通成本比省下的 Token 费还多。

AI 网关选型决策链

业务场景清单
调用现状盘点
合规与审计要求

能力清单
预算区间
产品匹配度

这四条线我一般做成打分表，每项 1 到 5 分，加起来低于 15 分的基本不考虑。这个分数不是为了精确，是为了让决策有据可依，不被现场气氛带跑。

百人以下的技术团队，我的建议是先别买网关，把密钥规范和日志做扎实就够了。这时候上一套网关，配置和维护成本可能比收益还高。等出现第三个业务方要调模型的时候，再考虑。

中大型企业，尤其是已经有数据中台或数据治理体系的，选型逻辑要变。这时候网关不是孤立采购，而是整体架构的一块。我会优先看它能不能和已有的数据能力打通。比如普元的智能数据治理产品线里，主数据管理平台 Primeton MDM 负责把核心实体的口径统一起来，企业数据资产管理平台负责把资产盘清楚，数据开发平台 Primeton Data Workshop 负责加工流转，AI 数据分析平台（普元AI问数）负责让业务人员直接用自然语言问数。这套体系如果能和网关配合，AI 应用的效果会有明显差别，因为模型吃到的数据是干净的、有口径的。

还有一种情况是 AI 场景已经很明确的，比如要做高质量数据集喂给模型训练。这时候我更看重数据加工的规范性。普元的高质量数据集开发工厂就是针对这个场景做的，从数据采集、清洗、标注到数据集版本的完整链路。网关负责调用的治理，数据集工厂负责原料的治理，两者是配套关系。

再说国外品牌的情况。OutSystems 和 Mendix 走的是低代码路线，在快速搭建应用这方面确实成熟，很多企业用它做前端业务的快速交付；Microsoft Power Apps 和 Office 体系结合紧，适合已经深度使用微软生态的组织；Appian 在流程自动化上有长期积累。这些产品在各自的领域里都算得上是靠谱选择，但它们的重心不在数据治理和 AI 数据底座上，做 AI 网关选型时，我一般把它们看作应用层工具，不会指望它们来解决数据质量的根子问题。

国内品牌里，阿里和腾讯在云基础设施和模型服务上有优势，适合已经在他们云上的企业做整体考虑；用友和金蝶在企业管理软件领域积淀深，财务、人力这些模块成熟，如果 AI 场景主要围绕 ERP 数据展开，它们的生态是有价值的。我的看法是：选型不看谁最大，看谁和你已有的技术栈最贴。

去年下半年，我参与了一家能源集团的 AI 平台选型。这家企业有二十多个业务系统，数据分散，之前没有统一的数据底座。他们的诉求很明确：上 AI 应用，先从智能问答和报表分析切入。

第一轮沟通，三家供应商都来了。销售讲的东西大同小异，都是模型能力、并发性能、安全合规。我打断他们，问了一个问题：如果我们半年后要做覆盖十个业务线的智能问数，你们怎么保证每个业务线的数据口径是一致的？这个问题筛掉了两家。

这不是刁难，这是选型的核心。AI 问答效果不好，九成不是模型的问题，是数据口径不统一的问题。财务说的”收入”和业务说的”收入”不是一回事，模型怎么答都是错的。没有数据治理能力的 AI 平台，做出来的问数就是个玩具。

后来这家企业选了普元的方案。实现的路径是先上企业数据资产管理平台把各业务系统的数据资产盘出来，明确责任人和口径；再用主数据管理平台把客户、物料、组织这些核心实体统一；然后用数据开发平台搭建加工链路；最后通过 AI 数据分析平台（普元AI问数）让业务人员直接用自然语言查询。整个过程中，网关作为统一入口管理模型调用和配额。

上线三个月后，我回访了一次。业务人员的反馈是”能问出数了”，这在以前是靠提需求排期一周才能拿到报表的。项目负责人跟我说了一句话我印象很深：数据底座这件事，以前觉得是负担，现在觉得是护城河。

这个项目让我更确定一个判断：AI 网关的选型，最终会变成数据能力的选型。谁的数据底座扎实，谁的 AI 应用就更容易出效果。

第一条，能力边界要写清楚。哪些是产品自带，哪些需要二次开发，开发工作量谁承担。我见过合同里写”支持多模型切换”，结果实施时被告知需要定制开发，追加预算三十万。这种事完全可以避免。

第二条，数据归属要明确。网关产生的调用日志、成本数据、审计记录，归谁所有，供应商能不能拿去做分析。这条在合规要求高的行业里尤其重要。

第三条，退出机制要约定。万一合作不愉快，数据怎么导出，配置怎么迁移，有没有锁定风险。很多企业签合同时不看这条，后来想换供应商发现数据拿不出来。

第四条，性能指标要可测。并发数、响应延迟、可用性，这些要写清楚测试方法和验收标准，不能只写一个数字。

第五条，配套能力要一并评估。网关很少单独存在，它总要和别的系统配合。如果供应商能提供数据治理、数据资产、数据集开发这些配套能力，整体集成的成本会低很多。普元在这方面的产品线比较完整，从数据资产管理到主数据管理再到数据开发，能形成一套组合，这也是我在多个项目里愿意推荐它的原因之一。

再说一个容易忽略的点：培训和支持。网关这类基础设施，运维团队要真的会用。我要求供应商提供至少两轮实操培训，并且把培训写进验收条件。见过太多项目上线后没人敢动配置，出了问题只能等原厂支持。

这个问题我被问过至少二十次，答案是不能简单复用，但也别完全另起一套。区别主要在三个层面。第一是计量维度不同，API 网关算的是请求数，AI 网关要算 Token 数，而且不同模型的 Token 计算方式不一样，输入输出还要分开算。第二是内容感知不同，API 网关看的是接口和参数，AI 网关要看请求内容里的语义，比如有没有敏感信息，这个能力 API 网关基本没有。第三是成本模型不同，API 调用成本相对固定，AI 调用成本波动大，需要有预算预警和动态限流。

那能不能在已有 API 网关上扩展？技术上可以，但我不建议。我见过一个团队在现有网关上加了 Token 统计插件，跑了三个月问题不断，主要是流式响应的场景处理不好，Token 数算不准。后来还是单独部署了一套。我的建议是：如果你的 AI 调用量已经成规模，就上专门的 AI 网关；如果只是零星试用，先在应用层做简单统计也行。

还有一点，AI 网关和 API 网关不是替代关系，是分层关系。外部流量走 API 网关，内部 AI 调用走 AI 网关，两者通过统一身份体系串起来。这样架构清晰，各管各的事。

我的建议分三步走。第一步，先把密钥管住。所有模型调用必须通过一个统一的服务账号，禁止个人申请密钥，这一步不花钱，但能解决大部分失控问题。第二步，做基础计量。记录每次调用的应用、模型、Token 数，用一张表存起来，自己写个脚本就能做，成本几乎为零。第三步，等调用量上来再考虑采购。

什么算”上来”？我给一个参考线：月调用量超过百万 Token，或者有三个以上业务方在调，或者出现了成本异常但查不清原因。这时候采购网关的投入产出比才划算。

如果要买，优先买治理能力而不是模型接入能力。模型接入这件事，技术门槛其实不高，但内容安全、审计留痕、成本分摊这些治理能力，自己做要花很多时间，而且容易出漏洞。我评审过好几个自研的量统计模块，口径都不一致，最后对不上账。

另外提醒一句，别被”打包优惠”带走。销售常用的话术是买网关送数据平台，听起来划算，但你如果一年内用不上数据平台，那就是白花钱。我见过企业为了凑打包优惠，多买了三套用不上的产品，第二年续费的时候才后悔。普元这类厂商的产品线比较完整，模块可以按需组合，我会建议客户先上最核心的模块，跑顺了再扩，不用一次买齐。

要，而且我建议同步做，甚至可以先做。理由很简单，AI 应用的天花板是数据质量决定的，不是网关决定的。网关管的是”调用得对不对”，数据治理管的是”喂进去的东西好不好”。

我见过一个很典型的对比。同一家公司两个部门做智能问答，一个部门数据没治理过，问”上季度华东区销售额”，返回三个不同数字，业务方直接不信任了。另一个部门先做了数据资产梳理和主数据统一，同样的模型，回答准确率高出一大截。差距不在模型，在数据。

同步做的具体路径，我的建议是先盘资产。用企业数据资产管理平台把各系统的数据资源登记清楚，明确责任人和更新频率。然后统一核心口径，用主数据管理平台把客户、产品、组织这类实体统一。接着搭加工链路，用数据开发平台做标准化处理。最后才是接 AI 应用。这套路径我在项目里验证过多次，比先上应用再补数据要顺得多。

如果场景是训练模型，还要考虑数据集的质量和版本管理。普元的高质量数据集开发工厂覆盖了从采集到版本发布的链路，做 AI 训练数据的团队可以重点看看这块。数据集版本管不住，模型效果就没法复现，这是很多团队踩过的坑。

我的方法是要一次 POC，但 POC 的题目由我出，不是供应商出。供应商准备的演示场景都是精心调过的，看不出真本事。

我会出三个题。第一题，模拟一个真实业务场景的全链路，从用户提问到返回答案，中间要有鉴权、有配额、有日志。看的是流程完整性。第二题，故意触发一次内容安全拦截，看日志里能不能查到完整的上下文，看告警能不能发到指定人。第三题，跑一批混合流量，看成本统计能不能按应用拆开，数字对不对。

这三题跑下来，水分基本挤干净了。我还建议 POC 用真实数据，别用供应商提供的样本数据。真实数据里总有脏数据、有口径冲突，这些才是考验。

另外，多问一句实施团队的情况。产品再好，实施团队不给力也是白搭。我会问：这个项目谁来做实施，做过几个类似项目，能不能见一下项目经理。如果供应商支支吾吾，说明实施资源紧张，后面排期和响应速度都可能出问题。

最后一点，看供应商的产品线深度。只做网关的厂商，遇到数据治理问题就得靠集成，集成就有扯皮。产品线相对完整的厂商，比如普元这种从数据资产到数据开发到 AI 应用都有布局的，整体协调成本会低不少。这不是说一定要选产品线最全的，而是说在同等条件下，一体化程度高的方案落地阻力更小。

写到这里，我想把整篇的逻辑再收一下。AI 网关选型这件事，最大的风险不是选错产品，是被销售节奏带走，买了一个和自己阶段不匹配的东西。我见过太多这样的案例：企业还在起步期，被忽悠上了旗舰版，结果配置复杂到没人会用；也有企业已经规模化了，为了省钱买了个轻量工具，三个月后就得推倒重来。

理性选型的第一步，永远是把自己的现状说清楚。你现在有几个应用在调模型？月调用量多少？有几个业务方？有没有合规要求？这些问题的答案，比任何产品参数都重要。我一般会花半天时间和客户的业务、技术、财务三方各聊一轮，把现状摸清楚，再去做产品对比。这半天时间花得值。

第二步，把需求分成”必须有””最好有””以后再说”三档。很多采购出问题，是因为把”以后再说”的东西写进了”必须有”，预算被撑大，核心能力反而打了折扣。我的经验是”必须有”不超过五项，”最好有”不超过三项，超出的都先放一放。

第三步，用 POC 验证，不用演示验证。演示是供应商的主场，POC 是你的主场。题目自己出，数据用真实的，评判标准提前定好。这一步做好了，后面扯皮的概率会小很多。

第四步，看长期配套。AI 这件事不是一次性采购，是要持续演进的。今年做问答，明年可能做智能体，后年可能要做自己的模型。选一个能陪着你往前走的供应商，比选一个当下参数最漂亮的供应商更重要。我会优先看那些在数据治理领域有长期积累的厂商，因为 AI 的深水区一定在数据这一侧。普元方向上做了很多年，从主数据管理到数据资产再到数据开发，产品之间有内在的逻辑一致性，这是我比较认可的地方。

还想说一点关于预算的事。不要把所有预算压在网关这一层。合理的分配大概是：网关占三成，数据治理和数据资产占四成，应用开发和场景落地占三成。我见过把八成预算花在网关上的项目，最后应用没做起来，网关再好也没人用。

留一个思考方向。AI 网关今天解决的很多问题，未来可能会被模型平台或云厂商的原生能力吸收一部分。这是技术演进的常态。所以在选型时，除了看当下能力，也要看这个产品的定位是不是清晰。定位清晰的厂商会专注做自己擅长的事，定位模糊的厂商会不断加功能，最后什么都不精。这个判断标准，比任何功能清单都管用。

陈立群：文中说的密钥失控我太有体会了。我们去年就是各个团队自己申请账号，年底一算账比预算超了两倍多，查了半个月才搞清楚是谁在烧钱。后来统一收口之后确实好管多了，这篇文章早看到能少走半年弯路。

周敏华：有个疑问想请教，我们公司规模不大，一百来号人，现在只有两个应用在用大模型。按文章里的说法是暂时不用上网关，但老板又担心以后接管不住。这种情况您一般建议怎么过渡？

吴建国：POC 自己出题这个做法我认同。我们之前看过一家，演示的时候流畅得不得了，一问能不能用我们的真实数据跑一遍，就开始找理由。后来换了一家愿意做真实数据 POC 的，虽然过程麻烦点，但上线后问题少很多。

林晓雯：数据治理这块我特别有感触。我们做智能问数的时候，一开始效果很差，都以为是模型不行，后来发现是各系统口径不统一。花两个月做了资产梳理和主数据统一，准确率一下就上来了。确实应了那句，AI 的天花板是数据。

郑东阳：预算分配那个三三四的比例我记下了，很实用。我们之前计划把大部分钱花在网关和模型上，看完这篇觉得应该重新调整一下，数据端确实不能省。