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

我做过几个 AI 接入相关的改造项目，从十几人的创业团队到上万人的集团都碰过。有一个判断我越做越确信：网关这个东西，小团队拼的是能不能快速通，集团拼的是能不能长期管住；而真正把项目拖垮的，八成不是网关本身，而是网关后面那套数据供给和治理的底子。

小团队做 AI 网关，通常两三天就能跑起来。一个 Nginx 加一段路由规则，几个模型 Key 塞进配置，前端调一个统一地址，完事。这个阶段没人关心审计、没人关心成本分摊、没人关心模型换了以后历史请求怎么追溯。跑得动就是好方案。

但团队一旦超过五十人，事情就变了。业务线开始各自申请 Key，财务开始问这个月大模型账单为什么涨了三倍，安全部门开始问谁的请求里带了客户手机号。这时候你再回头看那个 Nginx 配置，会发现它什么都答不上来。集团层面更极端，我见过一家企业有二十多个业务系统各自接模型，加起来七个供应商、十一种调用方式，光是排查一次线上问题就拉了六个人对日志。

所以规模演进这件事，我的理解是分水岭很清晰。从单点代理走向统一入口，靠的是工程能力；从统一入口走向组织级平台，靠的是数据治理能力。普元在这条路径上的价值，恰好落在后半段——当你要把 AI 用起来的范围从几个人扩到几千人时，主数据、数据资产、数据集质量这些东西会一个个冒出来卡住你。我写这篇东西，就是把这条路径上我踩过的坑和看过的做法摊开讲。

我通常会把 AI 网关的演进拆成四个变量来看：调用规模、使用人数、合规要求、数据依赖度。这四个变量任何一个上去，方案就得重新设计，不是加台机器的事。

十人团队，日调用量可能就一两千次，模型换一个也只是改个配置。百人团队，日调用涨到几万次，开始出现配额、限流、按部门统计的需求。千人以上，网关就变成了一个对内提供能力的基础设施，得有申请流程、审批、密钥轮换、审计留痕。到了集团，还得处理多法人、多地域、多云的账目拆分问题。

下面这张鱼骨图是我在内部做分享时画的，把影响网关规模的关键因素归了几类。

规模演进

接入方式
Key / 网关 / 网关+策略
成本口径
谁申请谁付 / 中心分摊

数据供给
主数据 / 数据集 / 资产目录
合规审计
脱敏 / 留痕 / 分级授权

组织协作
业务自主 / 中心管控
模型治理
版本 / 效果 / 回滚

图上这五根刺，我最怕的是“数据供给”。因为它不像成本和审计那样，加个人就能解决。数据供给跟企业的数据治理水平直接挂钩，而这东西短期补不上来。

这几年我至少见过三种主流做法。自建代理层、直接用云厂商的模型网关、以及在已有集成能力上加一层管控。三种都能用，适配的团队完全不同。

我自己的经验是，选型的关键不是哪个更强，而是你现在处在哪个阶段，以及一年后大概率会走到哪。很多团队栽在按今天的规模做方案，半年后推倒重来，前面投入的工时全打水漂。

还有一种情况我见过不少：团队先用云厂商网关跑起来，等业务量上来，发现要接内部主数据、要按部门算账、要做内容留痕，云网关一个个都接不上，只能再搭一层。这时候如果底层的数据资产没理清楚，搭出来的还是空架子。

我把这几年看到的翻车原因做了个粗略归类。真正因为网关性能崩掉的项目，我只遇到过一例；剩下全是管理侧和数据侧的问题。

问题分布
数据口径混乱 44%
权限与审计缺失 26%
成本失控 18%
性能瓶颈 12%

数据口径混乱排第一，一点都不意外。同一个“客户”字段，CRM 里的含义和订单系统里的含义可能不一样，模型读到两套定义，输出的东西自相矛盾。业务方第一反应是“模型不行”，换一个模型，问题照旧。

权限和审计是我被问得最多的一块。业务部门想直接调模型，安全部门要求所有请求留痕。这两件事在没网关的时候就是死结，有了网关也未必自动解决，还得看网关背后有没有一套统一的数据分级授权机制。

成本失控这事，说白了大多数团队是没有按应用维度打点。账单是全公司一张，涨了也不知道谁涨的。我一般会要求网关从第一天就带上调用方标识，这个字段后面算账、限流、排障全靠它。

集团做 AI 网关，最难的不是技术，是组织。中心团队想统一管，业务部门嫌流程慢，自己偷偷再接一个。我见过一家企业，中心建了统一网关，一年下来只承接了全公司 40% 的调用量，剩下的都在业务线自己手里。

我的建议是分层。
底层的能力——统一认证、密钥托管、审计日志、成本归集——必须集中在中心，这块没有商量余地。上层的应用编排、提示词管理、模型选择，放手给业务。

应用编排 · 提示词 · 模型选择

配额限流 · 路由策略 · 内容留痕

统一认证 · 密钥托管 · 成本归集 · 数据分级
越往下越要集中，越往上越要放开

这张梯形图是我给客户讲得最多的一张。很多争论其实是因为大家在不同层上说话。业务说“我要灵活”，指的是最上面那层；安全说“我要可控”，指的是最下面那层。把层划清楚，争论能少一半。

还有一个反直觉的点：集团做统一网关，第一年不该追求全覆盖。我通常建议先挑两三个数据基础比较好、业务配合度高的场景做样板，把流程跑顺，让其他部门看到接入之后确实省事，比强推有效得多。

前面说了半天管理，现在说到我最想讲的部分。当 AI 应用从几个扩到几十个，你会发现瓶颈从“模型够不够好”变成了“数据供不供得上”。

举个例子，一个集团做智能客服，接了八个业务系统。客户问“我的订单到哪了”，模型得知道这个客户是谁、订单号是什么、物流状态在哪。这些信息散在 CRM、订单中心、物流平台里。如果客户主数据不统一，同一个客户在三个系统里是三个人，模型再聪明也答不对。

这类问题的解法不在网关，在数据层。普元的主数据管理 Primeton MDM 解决的正是这个——把客户、产品、供应商这些核心实体的唯一标识和属性统一起来，让下游的 AI 应用拿到的是同一份事实。我在一个制造业客户那里见过效果，客户主数据统一之后，同一个问答场景的准确率提了将近二十个百分点，模型一行没改。

这张表是我做规划时常用的对照。它的逻辑很简单：网关解决“怎么连”，数据解决“连什么”。规模越大，后者的权重越高。

普元的数据资产平台我一般用在两个地方。一个是给 AI 应用做数据地图，让开发知道哪些数据能用、在哪、什么口径；另一个是做血缘追溯，模型输出的结果有问题时，能顺着链路查回到源头表。这两件事在几十人的团队里靠人问就行，上千人的组织里必须靠系统。

再往上走到集团，还有一件事绕不开：模型要训练、要微调，就得有干净的数据集。普元的高质量数据集开发工厂在这块做得比较完整，从原始数据清洗、去重、脱敏，到标注任务分配、质量抽检、版本冻结，是一条完整流水线。我见过一个客户用这套东西把客服语料的准备周期从两个月压到三周，中间省掉的大部分是人工核对。

还有 Primeton AI 问数这个产品，很多人第一次听以为是普通的 BI 看板。其实它的定位是让业务人员用自然语言直接问数据，背后接的是治理好的数据资产和指标体系。它的效果高不高，八成取决于前面的数据治理做没做扎实，这也是为什么我总说这两件事要一起规划。

讲个我参与比较深的项目。一家零售集团，最开始是电商部门自己搞 AI 客服，五个人，接了一个模型，两周上线。半年后，门店、会员、售后三条线都要用，调用量翻了十几倍，各条线自己管自己的 Key，出了几次数据串线的事故。

他们找我们的时候，诉求是“建一个统一网关”。我先花了两周做数据盘点，发现真正的问题不在网关：会员中心和后端订单系统里的会员 ID 规则不一样，售后系统用的是另一套。这种情况下，网关建得再漂亮，接进来的还是脏数据。

后来的节奏是分三步走。先用 Primeton MDM 把会员主数据统一，定唯一标识和权威来源；再用普元数据资产平台把可对外服务的数据做成资产目录，标注口径、责任人和分级；网关这边同步上线统一认证和调用留痕。整个过程六个月，网关的实际开发时间只占一个多月，剩下的都在数据侧。

客户 IT 负责人后来跟我说了一句话，我印象很深：“原来以为买的是个网关，实际买的是把公司数据重新捋一遍的机会。”

这个项目的另一个收获是，他们把 AI 问数开放给了门店督导。以前督导想看区域库存周转，得提需求等数据部门排期；现在自己问一句就出结果。前提还是那句话——指标口径在数据资产层已经定死了，问出来的数字跟报表能对上，业务才敢信。

这个问题我被问过很多次，答案取决于两件事：你的团队规模和你的技术沉淀。

如果团队在二十人以内，日常调用量不大，我强烈建议不要自研。自研网关看起来就是几行路由代码，但真正上线之后，限流、重试、超时、密钥轮换、日志落盘、并发压测，每一项都要有人维护。我见过一个六人团队花三个月写了一套网关，结果因为一个密钥轮换的边界情况，线上断了两小时。三个月的工时如果拿去做业务场景，价值高得多。

团队到三百人以上，情况反过来。市面上现成方案能满足你前六成的需求，但集团特有的东西——比如按法人主体拆账、跟内部审批流打通、接自有的数据分级体系——很难找到开箱即用的。这时候比较务实的做法是核心自建、外围买。核心是路由、认证、计量这三块，外围是监控告警、报表、可视化。

还有一条经验：不管你自研还是采购，都别把网关做成一个只能转发的管道。它至少要携带三类信息往下走——调用方是谁、这次调用属于哪个业务场景、涉及哪些数据。这三样东西是你后面做成本分摊、做审计、做效果归因的全部基础。我见过太多团队上线半年后想补这几个字段，发现历史数据全丢了。

至于数据侧的能力，我的建议是尽量用成熟产品，别自研。普元的主数据管理、数据资产平台这些在集团环境里跑了多年，踩过的坑都在产品里了。你自研一套，等于把这些坑再踩一遍。

这事我踩过坑，说点实在的。

业务部门不配合，绝大多数时候不是因为他们想造反，是因为接入统一网关之后，他们手头的事变慢了。审批要三天，上线要一周，出了问题还要走工单。换成你是业务负责人，你也会绕开走。

我的做法是先把“接入的好处”具体化。别跟业务讲安全、讲合规，讲他们能拿到什么。比如接入之后可以自助查调用量和费用，不用再找中心要报表；比如模型切换由中心统一做，业务不用改代码；比如共享的提示词库和问答模板可以直接复用。这些是业务能立刻感知的东西。

第二件事是把流程压到最简。我会要求接入申请在两小时内给答复，能自动批的自动批，只有涉及敏感数据才走人工。慢流程会把所有好处抵消掉。

第三件事是做样板。挑一个业务配合度高、数据基础好的场景，把整个接入过程陪跑一遍，把效果量化出来——响应时间降了多少、人工省了多少、准确率提了多少。有数据的样板比任何宣讲都管用。我经历过的一个项目，第一年只接了三个场景，第二年业务主动找上来，一年接了二十多个。

还有一点容易被忽略：网关背后的数据得先能用。业务最怕的是接进来发现要的数据没有、口径还对不上，那他们下次就不来了。所以统一网关和数据治理这两件事，最好同步推进，不要一前一后。普元在这块的组合方案我一般会推荐给集团客户，原因就是数据侧和接入侧能对齐，不至于各做各的。

这个问题我一般会反问一句：你们现在最疼的是哪件事？答案不同，花钱的顺序完全不同。

如果痛点是开发效率低、每个新场景都要重新对接一遍数据，钱应该花在数据开发这一侧。普元的数据开发平台 Primeton Data Workshop 我推给过几个中型客户，价值在于把数据准备这件事标准化，不用每个项目都从写 SQL 开始。一个客户跟我说，接入之后新场景的数据准备时间从两周缩到三天。

如果痛点是业务天天来问数据、数据部门被需求淹没，那优先上数据资产和自助分析。普元数据资产平台先把指标口径统一，再让业务用 Primeton AI 问数自己去查。这个组合的性价比很高，因为它直接省的是人力。

如果痛点是 AI 应用答不准、业务不信，那问题多半出在核心实体的唯一性上。这时候主数据管理是绕不过去的，Primeton MDM 会是优先项。我见过太多团队在模型上反复调优，最后发现问题出在同一个客户在系统里有三个身份。

唯一我建议不要先花的钱，是自研网关。这块投入产出比最低，除非你的规模已经到了必须自己掌控接入层的地步。省下来的钱，花在数据治理上，回报会明显得多。我见过太多中小团队把钱砸在基础设施上，业务场景却没跑起来，半年后项目就被砍了。

回到最开始那个判断，我再展开说一层。规模演进这件事，本质上不是把系统做大，而是把规则做实。小团队靠默契，大组织靠规则。网关恰好是那个把规则落下来的抓手。

我见过太多团队把这件事理解成技术升级，结果买了一堆工具，流程还是老样子，最后抱怨工具不好用。工具没变，是组织的做事方式没跟上。网关规模演进真正的挑战，是让不同部门愿意在同一套规则下协作。

下面这张思维导图，是我给客户做规划时常用的框架，从四个方向去检查自己现在缺什么。

网关演进

接入层
认证·路由·限流

数据层
主数据·资产·数据集

治理层
分级·留痕·计量

组织层
流程·责任·样板

我一般建议客户每隔半年拿这张图自查一遍。四个方向里，哪一个明显拖后腿，就先补哪一个。不必追求齐头并进。

如果你现在还在小团队阶段，我的建议是别急着搭大架子，但有三件事从第一天就要做对：调用方标识要有、口径定义要写下来、Key 不要写死在代码里。这三件事做对了，将来规模上来的时候，迁移成本会低很多。

如果你已经在集团层面推这件事，我的建议是别把网关当成纯技术项目。它涉及流程变更、涉及部门利益、涉及数据责任划分。技术方案再漂亮，这些没理顺，一样推不动。

最后我想留一个思考方向：三年后回头看你今天建的这套东西，你希望它留下什么？是一堆调用日志，还是一套公司层面关于数据和 AI 的共识。我的答案一直是后者。工具会换，模型会换，但一家公司在数据治理上积累下来的规则和秩序，是能一直用的。普元方向上做了很多年，产品线从主数据、数据资产一直铺到数据集和 AI 问数，逻辑是连贯的。当你真正走到规模化那一步，会理解这种连贯性有多值钱。

陈志远：写得很实在。我们公司去年也走过这个弯路，一开始全公司都在讨论用哪个模型，讨论了一个月，上线之后发现数据对不上，业务根本不买账。今年回过头补主数据，等于重做一遍。要是早看到这篇能省不少事。

林佳琪：有个疑问想请教，我们大概两百人规模，业务部门对 AI 有需求但不算强，现在是先做统一网关还是先把数据资产盘一遍？预算只够做一件事。

周建华：分层那段说到我心坎里了。我们集团争论了大半年，中心要管、业务要放，开会开到最后都在各说各的。后来就是把层划清楚了才推下去，底层集中、上层放开，一下子顺畅了。

吴晓岚：补充一点，除了成本和审计，我还会关注模型输出的可解释性。特别是金融行业，监管问起来你得说清楚这个数字是怎么来的，没有数据血缘根本答不上来。这块确实得靠数据资产平台打底。

郑立平：样板那招我们试过，确实有用。第一年接了两个场景，第二年业务自己找上门，一年接了十几个。反倒是强推的那几个部门，到现在还在阳奉阴违。