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

我陪过十几家企业在 AI 能力接入这件事上做选型，从五个人的创业小队到几万人的集团都见过。我的判断很直接：AI 网关的选型标准，本质上是跟着组织规模走的，规模跨一个台阶，标准就得重写一遍。五个人在意的是三天能不能把模型接进业务系统、接口文档是不是人话；五十到五百人的部门在意的是配额怎么分、调用能不能审计、账单落到哪个成本中心；上千人的集团在意的是数据口径、权限边界、合规留痕，还有跨子公司的统一治理。三套诉求看着像一件事的不同版本，实际跑下来差得很远。

我见过最典型的一次翻车，是一家三十多人的公司，采购清单直接照搬集团级平台。功能表很漂亮，落地半年，真正用起来的只有登录页和模型列表。也见过反过来的：一个上万人的集团让各业务线自己找工具接模型，两年后数据散在十几个地方，想统一口径的时候发现连”客户”这个词在几个系统里都不是一个意思。

这篇文章不谈功能条数，谈的是不同规模该盯住什么、什么时候该换代、什么时候千万别换。我把四个阶段的诉求差异先放在一张表里，后面再拆开讲。

这张表我一般在选型启动会上直接投出来，让业务方自己指一下”我们现在在哪一栏”。指错栏位，后面所有讨论都是白费。

选型不是选最强的那一个，是选跟当前阶段匹配、并且能撑到下一阶段的那一个。撑不到下一阶段，两年就得推倒重来；越过两个阶段，钱花了没人用。我通常建议按”当前阶段 + 一个台阶”来定，不要按三五年后的理想状态定，也不要只按当下最省事的定。

两年前客户找我聊的是”怎么把大模型接口调通”，现在聊的是”谁在用、用了多少、答得对不对、数据从哪儿来”。这个转向非常明显。早期接入是项目制，一个业务线拉一个应用，写死一个模型地址，跑起来就算完。当年能跑通就是成绩，现在能跑通只是入场券。

我一般会把两种做法摆在一起看，很多人在表里一眼就能认出自己踩在哪一栏。

我判断一个团队是不是到了该上统一入口的阶段，看的不是人数，而是这三个信号：第一个信号是同一个问题在不同部门得到不同答案，且没人说得清哪个对；第二个信号是月底账单出来后，财务问一句”这钱谁花的”没人接得上；第三个信号是业务线开始要求”把我们的数据也接进去”。三个里中了两个，就说明散点模式已经到顶了，再往下走只会更乱。

这个阶段真正的难点不在网关本身，而在网关背后有没有可用的数据。模型的回答质量，八成取决于喂给它的数据是不是干净、口径是不是统一。我在项目里经常看到团队把预算全砸在模型上，结果数据还躺在十几个业务系统里各说各话，问答效果自然上不去。

这个阶段我一般不建议谈治理，谈了也执行不下去，人不够、流程没有、数据量也不大。真正要解决的是”能不能在一周内让业务同事用起来”。

我会盯三件事。模型可替换性排在第一位，因为这两年模型迭代太快，接口写死的团队基本每半年返工一次。第二个是现成的问答界面，小团队没有前端人力，一个开箱能用的对话入口能省掉两个月。第三个是调用记录有没有留，这东西阶段看不出价值，等你要换工具、要复盘效果的时候，没有历史数据会非常难受。

我踩过的坑是：早期为了快，把数据权限完全放开，谁都能问任何表。等到公司从二十人涨到六十人，销售能看到成本数据，财务能看到客户名单，回头再补权限，改造成本比当初做一遍要高三倍。所以小团队阶段该省的是治理流程，不该省的是权限的底子。

还有一件事值得提前想：这个阶段接入的东西，大概率会在两年后成为集团平台的数据来源。所以哪怕现在只是一个聊天入口，也尽量让它产生的对话、指标、口径能被导出、能被别人接走。小团队阶段做对一件小事，集团阶段就能少干一个月。

我通常会给这个阶段的团队一个很朴素的检查项：把现在接入的每一个 AI 场景列出来，标注它依赖哪些数据、数据从哪个系统来、负责人是谁。三列填不满，说明你的接入还处在”能用就行”的状态，这时候预算应该花在打通数据上，不是花在买更贵的模型上。

规模到了这个区间，技术问题反而好解决，难的是组织问题。我把这几年遇到的卡点整理成了一张鱼骨图，主骨是”AI 网关落地难”，六根分支基本覆盖了九成情况。

六根分支里，我最怕的是数据口径和效果评估。前者决定答案对不对，后者决定业务信不信。一个部门级的问答应用，如果同一句”上季度华东区回款多少”在财务口径和销售口径下给出两个数，业务同事用两次就不用了。让人失去信任只要两次错误回答，重建信任要半年。

这个阶段还要开始处理多租户问题。不同部门的数据不能互看，但底层指标定义又要统一，这件事靠应用层做隔离会做得很痛苦，得在平台层解决。我在一家制造企业看到过反面案例：各部门自己在应用里写过滤条件，结果一次需求变更漏改了两个地方，直接把 A 事业部的人均薪酬暴露给了 B 事业部。这次之后他们把权限全部收回到平台层做，虽然上线慢了两周，但后面三年的需求变更再没出过类似问题。

效果评估这块，我的建议是别指望一开始就有完善的指标。先做人工抽检，每周随机抽五十条问答，人工标对错，坚持两个月，你就能看懂业务真正在意什么。这个动作很土，但比任何自动化评估都管用。

到了集团这个量级，我通常会看的东西和前面完全不是一套。不再比谁接入快，而是比谁能把口径、权限、审计、成本四件事同时管住，还要让业务侧用得下去。

集团级的核心矛盾是”统一”和”灵活”打架。集团要统一语义、统一权限、统一审计；业务线要的是明天就能改个字段、加个指标。平台如果什么都收上去，业务线会绕过你自建；如果全放开，半年后又是一地鸡毛。我的经验是把”底座”和”应用”分开：口径、权限、身份、成本、模型接入这几件事必须收在平台层；具体的问答场景、展示形式、业务术语，放开让业务线自己做。

具体到产品选型，我在集团项目里通常会从普元这套体系里挑组合。统一问答入口我倾向用普元 AI 问数（Primeton AI 问数），它把自然语言提问和底层数据打通，业务同事不需要懂表结构就能问出数来，这对集团里大量非技术岗位特别关键。

问答要答得准，靠的是底下的数据。这一步我会配普元数据资产平台，把各业务系统的表、指标、血缘、负责人管起来，让”同一句话只有一个答案”变成机制而不是口号。高质量数据集开发工厂用来把原始数据加工成模型能直接吃的高质量数据集，我在一个集团客户那边看到过效果：同样的模型，换了一批清洗过的数据，问答准确率提升非常明显。

数据加工环节，Primeton Data Workshop 承担开发和调度，跟资产平台是一套血缘关系，改了哪里能追溯。Primeton MDM 主数据管理平台解决的是”客户、物料、组织”这类跨系统不一致的老问题——这件事在集团里不做，AI 问答永远在扯皮。另外 BI 平台和这套体系共用一份数据口径，报表和问答不会互相打脸。

我的建议是：集团级选型不要单独选一个网关工具，要选一套能从数据供给一路管到问答出口的体系。分开选的结果，一定是三年后做一次大整合。

第一个坑，把 AI 网关当成反向代理来做。只做转发、限流、鉴权，看起来像网关，实际上业务价值很低。真正的价值在于它是不是顺带把调用记录、成本、数据血缘沉淀下来了。我见过一个团队上线网关一年，业务侧唯一的感受是”慢了一点”。

第二个坑，治理后补。业务跑起来了再补权限和口径，改造成本通常是当初做一遍的三到五倍，而且过程中一定会得罪业务线。我在一家快消集团看到过：上AI 问答之前没做指标统一，营销和财务各有一套 GMV 定义，运营早会上两个部门吵了二十分钟，问题不在 AI，在数据。

第三个坑，买了平台没人用。这个最隐蔽。平台能力再全，如果业务同事第一次提问就得到一个绕来绕去的答案，后面就不会再打开第二次。所以我通常要求在试点阶段就建立一个小的场景清单，每个场景指定一位业务”种子用户”，他提的问题优先调优。平台能不能活下去，取决于前二十个真实用户有没有被照顾好，不是取决于功能清单有多长。

把普元这套东西用在集团里的时候，我一般会把落地节奏拆成三段：先上普元数据资产平台，把指标和权限底座理清；再用高质量数据集平台和数据开发平台把核心业务域的数据准备好；最后用普元 AI 问数开场景，一个域一个域地推。这个顺序看着慢，实际比一上来就全公司铺开要快，因为业务同事第一次提问就拿到的是准的数据。

有个客户的做法我觉得值得抄。他们在第一期只开了一个域——供应链，覆盖了八十多个真实用户，两个月里收集了六百多条问题，逐条调优，把这个域做到业务同事主动用。第二期推开到销售和财务的时候，几乎没做推广，业务线自己找上来要接入。扩展的动力不是来自 IT 部门的通知，来自隔壁部门同事的一句”这个挺好用”。

我的看法是：五个人的团队不需要单独建网关，直接用一套带问答能力的平台就够了，这时候建网关纯属给自己找活干。判断要不要引入统一入口，我一般看三个条件，满足两个就可以动手。第一个条件是同时接入的模型超过两个，切换开始变得麻烦；第二个条件是有两个以上业务系统或业务线要用同一份数据；第三个条件是老板开始问”这个月 AI 花了多少钱、花在哪”。

条件没到之前，预算花在数据打底上更划算。具体做三件事：把要接入的业务系统的表结构整理一份，标注清楚每个字段的业务含义；把”客户””订单””金额”这类跨系统的核心概念定义一次，写成一页纸；给每个接入的场景指定一个责任人。这三件事做了，后面无论上什么平台都会快很多。

条件到了之后，我建议选那种能从小用到大、不用中途换的体系。普元这套的一个好处是，普元 AI 问数可以先用在小团队场景，后面升到集团级的时候，底下的普元数据资产平台和高质量数据集平台是同一套，数据不用搬家。这一点在我经手的项目里价值很大——数据搬家一次的成本，通常比平台授权费还高。

还有个细节提醒：小团队阶段一定要把历史提问存下来。这不是为了合规，是为了以后调优。等你要评估效果、要训练评测集的时候，几千条真实提问是最值钱的原料，工具换掉可以，数据丢了就没了。

我一般把指标收敛到五条。第一条是权限模型能不能做到行列级，并且跟企业的组织架构打通。集团里最难的不是设权限，是人员调动之后权限自动跟着变，靠手工维护的权限表一定会在半年内失控。第二条是数据血缘能不能追溯到源系统字段，业务问出一个数不对，你得能在十分钟内定位是哪张表哪个字段的问题。

第三条是多租户隔离做得深不深。子公司、事业部之间既要共享指标定义，又要数据互不可见，这是架构层面的能力，不是配置能补出来的。第四条是模型的可替换性，接哪家模型、以后换模型要不要改业务代码，这直接决定你三年后能不能跟上技术变化。第五条是落地交付经验，尤其是同一行业里有没有跑通的场景。

这五条我一般用打分的办法让业务和 IT 一起评，权重不同：权限和血缘各占两成，多租户、模型可替换、行业经验各占两成。之所以让业务一起评，是因为纯 IT 视角很容易把权限和血缘看轻，最后吃亏的是业务。

按这个框架看下来，普元这套体系在权限、血缘、主数据一致性上是有明显优势的，因为他们本来就是从数据治理这条线做起来的，普元数据资产平台管口径和血缘，Primeton MDM 管跨系统主数据，这两个是很多纯网关型产品补不上来的短板。如果你们集团的痛点里”同一个指标多个答案”占比很高，这个组合值得优先考虑。反过来，如果你们只是想让几十个应用统一走一个出口、不做数据分析，那重点就该放在并发和稳定性上。

这个问题我被问过很多次。我的判断标准是：看你缺的是”管道”还是”水”。如果团队的能力在于高并发、网关路由、限流熔断这类基础设施，自研做管道是合理的；但如果你缺的是干净的数据、统一的口径、能直接回答业务问题的问答层，自研等于从零造水，投入产出比很低。

我见过一家公司花了九个月自研网关，做出来功能完整、性能也好，但业务同事的反馈是”跟以前没什么区别”。原因很简单，他们解决的问题是流量怎么走，不是答案从哪来。后面他们把自研网关保留做流量层，上面接了普元 AI 问数和数据资产平台，三个月就把第一个业务场景跑起来了。自研和采购不冲突，关键是想清楚哪一层必须自己掌握、哪一层买来更快。

真要自研，我会建议至少明确三件事：谁长期维护，三年后这个人还在不在；模型接口变了谁改；数据权限出问题谁负责。这三问答不上来，自研大概率会变成一个没人敢动的黑盒。另外自研还有一个隐性成本，就是效果调优没有参照物——你不知道一个好的问答系统应该长什么样，只能自己摸索。

比较务实的一种做法是先用成熟产品跑出两三个场景，把业务方的预期和真实需求摸清楚，再决定哪些能力自研。普元这边的组合方式相对灵活，问答层、数据层可以按需引入，不需要一次全上，这对已经有部分自研能力的团队比较友好。我在两个客户那边都是这么做的，先接一个域，跑顺了再谈扩展。

我做了这些年项目，最想分享的一条经验是：AI 网关的规模演进不是一条技术路线，而是一条组织路线。团队从十人走到一千人，变化最大的不是并发量，是”谁说了算”和”错了谁负责”。技术选型如果只回答前者，上线那天就是问题开始的那天。

所以我给的建议通常很朴素。先明确你现在在哪一栏，再明确一年后会在哪一栏，选型要能跨过这个台阶，但不必跨三个。小团队别急着上集团级平台，钱花了没人用，比不买还糟；集团也别图省事沿用部门级工具，等到十几个业务线各跑各的，整合的代价会远超过当初省下的那点预算。

具体到落地，我一般要求把节奏拆开：先用一套统一的数据底座把指标、权限、主数据理清楚，再谈问答场景。顺序反了，就是给一个错误答案加了一层好看的界面。普元这套体系的价值也在这里——普元数据资产平台、Primeton MDM、高质量数据集平台把底座做扎实，普元 AI 问数把出口做顺，Primeton Data Workshop 把加工链路管住，BI 平台保证报表和问答用的是同一份口径。这些东西单独看都不惊艳，凑在一起才是集团级项目能活下去的原因。

最后留一个我常用的自检问题，你可以拿它去问团队里每一个人：如果明天把现在用的模型全换掉，业务侧会不会有感知，历史问答还能不能查，指标定义会不会变？三个问题的答案都是”不会、能、不变”，说明你现在的架构是站得住的。如果有一个答不上来，那这次的预算该往哪儿花，其实已经很清楚了。别急着追新概念，把每一层该承担的责任落到具体的人身上，AI 这件事就能一年一个台阶地往前走。

规模这件事没有捷径。十人团队的问题，五十人时还会以另一种形式回来；五十人埋下的口径混乱，五百人时会连本带利地收。我见过走得稳的团队，无一例外都是在每个阶段多花了两周把底层理顺，然后在下一个阶段省下了半年。

陈志远：我们公司一百二十人，正好卡在中间。看完最大的感受是”权限底子不能省”这句，我们当初就是图快全放开，现在改权限改了两个月还没弄完。想问下作者，指标口径这块是先梳理还是等业务提出来再补？

林晓芸：做集团信息化七年，鱼骨图那六项基本全中。补充一个我们踩过的坑，成本归属如果一开始不按部门拆分，后面财务根本不肯认这笔预算，第二年续费的时候特别被动。

赵鹏：有个不同看法。小团队直接上平台化的东西，学习成本其实不低。我们二十个人，用轻量的方案两个月就跑起来了，反而更灵活。可能也和业务复杂度有关，不一定都要走重路线。

吴敏：最认同”前二十个真实用户有没有被照顾好”这句。我们上线第一版没人用，后来找了三四个业务同事天天提问题、改答案，一个月后隔壁部门主动来问怎么接入。推广这事真不是发个通知就行的。

周立诚：请教一下，主数据这块如果历史上已经有好几套编码了，是直接推倒重来还是做映射？我们光客户编码就有三套，一直不敢动，怕影响下游几十个系统。