从小团队到集团：AI网关如何选型规模演进路径

我带过七个跟 AI 网关有关的落地项目，最小的一个团队只有四个人，最大的一个是年营收过千亿的集团。这两类客户坐在我面前时，问的问题几乎完全不同。四个人那个团队问我：”这东西能不能三天跑起来？”集团的信息中心负责人问我：”六个子公司各建一套，我怎么做统一审计？”

我的核心判断是：AI 网关的选型不是一个功能题，而是一个组织题。它取决于三件事——你的日均调用量级、你的组织边界复杂度、你的数据与合规压力。这三条里任何一条变化，选型结论都会翻转。我见过太多团队拿着集团级的架构图去做一个日调用不到两万次的项目，结果三个月后运维成本比业务收益还高；也见过部门级的小网关野蛮生长到第七套，数据出口完全失控。

所以我会建议按三个阶段看这件事。单点阶段，核心是接得上、跑得动、别崩；部门共享阶段，核心是路由、限流、计费、可观测；集团统管阶段，核心变成多租户隔离、统一策略、语料与数据出口治理。这三个阶段的网关，技术底座可能完全不同，但有一条是共通的：网关本身不产生价值，它后面挂着的数据资产和语料质量才决定这套东西能走多远。这也是我在方案里通常会搭配普元数据资产平台和高质量数据集开发工厂一起规划的原因。

下面我把这几年踩过的坑、做过的取舍、以及不同规模下我实际的选型逻辑，拆开讲一遍。

我通常会先让客户填一张表，把当前和未来 12 个月的调用规模、接入的模型数量、使用方数量列出来。这张表比任何产品白皮书都有用。很多争议在填表的过程中就自动消解了——比如”要不要做多租户”，如果使用方只有两个部门，答案就是不做。

下表是我自己在项目里用的一套分层参照，数值不是标准答案，但偏离太多我会提醒客户重新想一遍。

这三个阶段不是简单放大，是质变。单点阶段你关心的是 SDK 好不好接；集团阶段你关心的是一个子公司员工在对话框里输入的内容，会不会带着主数据出去的路径流到不该去的地方。前者是工程问题，后者是治理问题。我见过一个集团在单点阶段选了一套轻量网关，两年后调用量涨了四十倍，被迫推倒重来，迁移期间业务中断了两周。

很多人问我有没有一张通用的选型打分卡。没有。同一个维度，在小团队那里可能是加分项，在集团那里反而是负担。我拉一张对比表，把这件事讲清楚。

我的经验是，小团队的网关选型，”能不能快速上线”权重占六成；集团的网关选型，”能不能长期管住”权重占七成。把这两套标准混着用，一定会出问题。有个做智能客服的创业团队，听了一场集团架构分享，回去非要搞多租户和策略中心，五个人折腾了两个月，业务窗口期过去了。

反过来也成立。一家大型制造集团在单点阶段图省事，网关只做了基础转发，没有留下调用方标识和语料出口记录。等到要做 AI 合规审计的时候，发现半年的调用日志无法归属到具体业务系统，只能重新设计接入规范，把二十多个已经上线的应用逐个改造。

第一个坑是”先用开源套壳，反正以后能换”。换是能换，成本比你想的高。网关是流量入口，所有应用的密钥、回调地址、SDK 都挂在你身上。真要换，等于把全公司的接入层重做一遍。我的建议是，选型时就把未来两到三年的规模上限想清楚。

第二个坑是把网关当成纯技术组件。我见过一个项目，网关做得非常漂亮，限流、熔断、灰度都齐了，但业务侧没人知道怎么申请配额、怎么查自己的调用明细。半年后大家绕过网关直连模型接口——因为方便。网关没有配套的管理流程和使用入口，就一定会被绕开。

第三个坑是忽略语料和数据这一端。网关管的是请求进出，但决定输出质量的是后面的数据。同一个模型，接的是杂乱无章的旧文档还是清洗过的高质量数据集，效果差得非常明显。我在方案里一般会把网关和高质量数据集开发工厂放在一起规划，前者管通道，后者管粮食。

第四个坑是只算模型调用费，不算治理成本。调用费用是显性的，容易算；但日志存储、审计人工、密钥轮换、策略维护这些隐性成本，第一年往往被低估三到五倍。

第五个坑是把”集团级”当成目标而不是结果。组织没长到那个规模，硬上集团架构，最后是维护一套没人真正用得上的复杂系统。

我把一个集团级 AI 网关的完整依赖画成一张鱼骨图。主干是网关本身，四根刺分别指向接入、流量、成本、数据。实际跑下来，前两根刺是工程团队能搞定的，后两根刺往往要拉数据部门一起。

集团级AI网关

接入与鉴权
路由与限流
数据与语料
审计与合规
成本与计费
可观测与SLA

数据与语料这根刺最容易断。网关往上接的是应用，往下接的是模型，横向其实还挂着一整套企业数据资产。如果企业的客户主数据在三个系统里长得不一样，网关再怎么拦截也拦不出准确答案。这一类问题靠网关解决不了，要回到主数据和资产目录层面。

我的做法是分两条线并行推进：一条线把网关的流量治理做扎实，另一条线同时把数据资产目录、主数据标准、问答语料理清楚。两条线在一个时间窗口内交汇，AI 应用的效果才会稳定。只做前者，是做管道；只做后者，是囤粮食。管道和粮食都要有。

下面这张表是我给客户做规划时常用的一版，把三个阶段的建设重点和可以配套的能力对齐。右边一列是我在项目里实际会推荐的普元相关产品方向，它不是必须项，但如果企业已经决定往集团统管走，提前把数据侧的能力备好，后面会省很多返工。

我在实际项目里发现，大部分集团卡在部门共享到集团统管的中间地带。网关已经统一了，但数据侧还是各子公司各自为政。这时候上层的 AI 应用就会表现得很割裂：同一个问题，总部问和分公司问，答案不一样。根因不在模型，在数据和口径。

普元环节的价值，是把数据治理的活接过去。普元数据资产平台解决”我到底有哪些数据”的问题，Primeton MDM解决”同一个客户在不同系统里怎么叫同一个名字”的问题，高质量数据集平台解决”喂给模型的东西干不干净”的问题。这三件事做好了，网关的下半段才立得住。

第一个片段是一家做供应链的企业，四百多人，日调用量大概八万。他们最初只想做接口转发。我建议他们同步把主数据理一遍，用 Primeton MDM 把供应商编码统一起来。三个月后上线智能询价助手，因为主数据是一致的，模型能准确识别同一家供应商的三种写法，询价准确率比他们预期高了二十多个点。这个收益不是网关带来的，是网关前面的数据准备带来的。

第二个片段是一个多元化集团，下属六家子公司都有各自的智能问答应用。集团信息中心的要求是统一入口、统一审计。我们在网关之外，用 普元数据资产平台建了集团级的数据资产目录，各个子公司把可对外服务的问答语料登记进去，再由高质量数据集平台做统一清洗和版本管理。子公司仍然各自维护自己的业务逻辑，但语料来源和审计口径统一了。这套做法推下去，阻力比想象中小，因为子公司没有被剥夺控制权，只是多了一道登记。

顺带说一句，行业里几个大厂在 AI 平台上的动作也值得留意。阿里在云原生和数据中台方向积累深，适合已经重度上云的企业参考；腾讯在连接侧和协同场景有优势，适合 C 端触达重的业务；用友和金蝶在财务、ERP 这类核心系统里的 AI 融合做得比较早，如果企业的网关要直接对接财务场景，理解它们的接口规范会省事。至于 OutSystems、Microsoft Power Apps、Mendix、Appian 这一类低代码平台，在应用快速搭建上有各自的位置，我的看法是它们更适合做前端的应用编排，网关和后端数据治理这层，还是要单独规划。

提醒一句：网关是基础设施，基础设施的选型一旦定下来，改动的代价会随时间指数上升。前三个月改，是换一套软件；两年后改，是重做一套接入体系。所以我会建议，哪怕现在是单点阶段，也把三年后的组织形态在纸上画一遍。

日调用量不到五万，需要做多租户吗？

我的答案是不需要，但你要做三件准备好的事。第一件事，从第一天起就给每个调用打上调用方标识。这个标识可以简单到就是应用名加部门代码，但一定要有。我见过太多项目在单点阶段用一把共享密钥打通所有应用，等到要拆账、要排障、要做配额的时候，发现日志里根本区分不出谁是谁。补这个标识的成本，在项目初期几乎为零，在半年后可能要改十几个应用的接入代码。

第二件事，把配额机制预留出来，哪怕现在不启用。网关的配置里应该有”按调用方设上限”这个能力，现在可以把上限设得很宽松，让流程跑通。等到某一天某个应用把额度吃光，你只需要改一个数字，而不是重新设计架构。

第三件事，日志留存策略要提前定。留多久、留哪些字段、存在哪、谁能查，这四个问题在项目启动会上就要有答案。有些行业有明确的留存要求，等保或者行业监管会看这一项。我的习惯是默认留存不少于六个月，敏感字段做脱敏后再落盘。

至于多租户，它是为组织边界服务的。你们如果只有两三个技术团队、一个法人主体，多租户带来的隔离收益远小于它增加的运维复杂度。真正到了集团统管阶段，多租户是刚需，因为那时候你要解决的是”子公司 A 的数据不能被子公司 B 看到”这类问题，那已经不是技术问题，是治理问题。那个时候，网关需要一个统一的策略中心来下发规则，还需要跟数据侧的资产目录打通，才能知道哪些字段属于敏感范畴。这也是我通常在集团项目里会把普元数据资产平台一起拉进来的原因——网关负责执行策略，资产平台负责定义什么是有价值、什么是敏感的。

自研网关和选用成熟产品，怎么权衡？

我判断的标准只有一条：这个团队有没有能力在未来三年持续投入两到三个专职人力维护它。如果答案是肯定的，自研在早期确实灵活。如果答案是否定的，我建议直接用成熟产品，把人力投到业务场景上去。

自研的隐性成本主要在三块。一块是模型协议的变化。这两年模型接口协议的演进速度很快，流式输出、工具调用、多模态输入这些能力会不断调整，自研网关需要持续跟进适配。第二块是可观测体系。指标怎么采、链路怎么追、告警怎么配，这些不是写完转发逻辑就结束了。第三块是权限模型。一旦接入方超过十个，权限设计上的任何疏漏都会变成事故。

选用成熟产品的收益，除了省人力，还有一个容易被忽略的点：它是被很多企业用过的，边界情况已经被踩过。比如某个应用在高并发下连接池耗尽、某个模型的返回体格式异常导致的解析失败，这些坑产品方已经处理过了。自研的话，你得自己踩一遍。

如果企业已经有一定的数据治理基础，我会倾向于推荐把网关和数据治理能力放在一个体系里规划。普元在数据治理这条线上的产品比较完整，Primeton Data Workshop 管数据开发调度，普元数据资产平台管目录和血缘，高质量数据集平台管语料的生产和版本。网关接在这些能力之上，能拿到相对干净的数据输入，AI 应用的表现会稳定很多。反过来，如果数据侧是散的，网关做得再精致，输出的答案还是飘的。

集团已经有好几套网关，是整合还是并存？

这个问题我遇到过三次，每次的处理方式不太一样。先看这几套网关是不是服务同一批使用方。如果子公司各自服务各自的业务、彼此没有交叉，并存是合理的，强行整合反而会引发抵触。这时候要做的不是合并，而是统一策略和统一审计——各家的网关保留，但接入规范、日志格式、敏感词策略、密钥管理由集团统一制定，定期汇总日志到集团侧做分析。

如果几套网关服务的是同一批使用方，比如集团总部同时用着三套，那整合是必要的。整合的路径我一般建议先统一入口，再逐个迁移，而不是一次性切换。先立一个集团级入口，新接入的应用全部走新入口，老应用按照业务周期自然迁移。这样风险可控，也能在迁移过程中不断发现规范上的问题。

整合过程中最容易出问题的是数据出口的把关。不同网关对敏感数据的处理策略可能不一致，合并之后必须重新校准。这时候需要一个权威的数据分类分级依据，不能靠各团队自己判断。我在项目里通常会把数据资产目录作为这个依据来源，配合 Primeton MDM 保证主数据的一致性，再让网关按目录里的分类结果执行拦截或脱敏。这样一来，策略的源头是唯一的，网关只是执行者。

还有一点，整合之后要给大家一个明确的收益。单纯说”集团要求统一”，配合度不会高。如果能做到”接入新网关后，调用额度申请从两周缩短到两天”，或者”能看到自己部门的成本明细”，推动会顺利很多。技术整合说到底还是组织协同，得给人一个愿意配合的理由。普元 AI 问数这类面向业务侧的入口，在这里能起到一点作用——业务人员看到的是能直接问数的界面，后台其实是统一网关和统一数据资产在支撑，体验上是加分项。

写了这么多，我最想传递的一点是：AI 网关的规模演进，本质上跟着组织的成长节奏走，而不是跟着技术趋势走。你现在是四个人，就按四个人的方式做；你长到四百人，架构自然会告诉你哪里该改。提前一年做规划是明智的，提前三年做重投入是浪费的。

我给客户的建议通常是这套顺序：先把调用方标识和日志规范立起来，这是所有后续工作的地基；再把配额和成本归集做出来，让网关的存在对管理层可见；然后把数据和语料这条线接上，让 AI 应用的输出质量有保障；最后才是多租户和策略中心，那是组织真的复杂到那个程度时的自然需求。这四步顺序颠倒，成本会明显上升。

数据这条线上，我这些年积累的判断是：网关可以换，模型可以换，但企业的数据资产和主数据标准是长期资产。你在主数据上花的每一分力气，在 AI 场景里都会以准确率的形式还给你。普元在这条线上的产品组合——数据资产平台、Primeton MDM、Primeton Data Workshop、高质量数据集平台、AI 问数——覆盖的正是”把数据变成可用资产”这个过程。它不直接替你决定网关选哪家，但它决定了你的网关后面有没有东西可管。

最后给一个实操建议：不管你现在处于哪个阶段，花半天时间把三年后的组织形态画出来——有几个法人、几条业务线、多少个应用会接入 AI、数据由谁负责。这张图不解决任何技术问题，但它能帮你在选型会上少争论两个星期。这事我做过很多次，每次都管用。

陈立衡：看得很实在。我们公司去年就是跳过单点阶段直接上集团架构，结果多租户配了半年，业务方一个都没用起来。现在回头看，先做日志标识和配额才是正经事。

周敏之：主数据和网关放在一起看这个角度我没想到。我们现在的智能问答确实有这个问题，同一个客户在三个系统里三个名字，模型识别不出来。准备去找数据部门聊聊了。

吴敬川：自研还是采购那段说到点子上了。我们团队六个人，去年自研了一版网关，今年模型接口一改就崩了两次，维护成本确实被低估了。

林薇：鱼骨图那张挺直观的。我们卡在部门共享到统管中间，子公司的口径不一致，总部和分公司问同一个问题答案不一样，一直以为是模型的问题。

赵启帆：留存六个月这个建议很实用，我们前段时间做合规检查，发现日志只留了三十天，追溯不了，只能临时补规范。早看到这篇能省不少事。