为什么需要大模型网关项目失败复盘：5个致命原因

这几年我参与过的大模型网关项目，加起来有十几个。形态变化很快，从最早只是一层 API 转发，到后来要管模型路由、密钥、配额、审计、提示词模板、工具调用编排，甚至要接 MCP 这类协议。我的判断是：大模型网关不是”要不要有”的问题，而是”你到底把它当成什么”的问题。当成一根网线，它就只值一根网线的价钱，业务侧随便哪个团队半个月能搭一个出来；当成企业 AI 能力的统一出入口，它就是基础设施，要按基础设施的方式立项、选型、留预算、定责任人。我复盘过的失败项目里，真正死在技术选型上的不到两成，八成死在另外五件事上：目标一开始就定小了、网关背后没有可用的数据底座、成本只有账单没有业务视角、责任边界模糊没人真正负责、上线之后没有度量闭环。说白了，网关是个放大器，你的数据治理做得好，它让好数据被更多场景用到；你的口径一塌糊涂，它只是把混乱更快地分发出去。我见过最离谱的一个项目，网关做得挺漂亮，接进来八个业务，结果三个月后业务全部回流到自己的直连方案，原因很简单——通过网关拿到的答案，和他们自己手里的报表对不上。这篇文章我按复盘的方式写，把五个致命原因一个个拆开，再讲清楚什么阶段该自研、什么阶段该用平台化方案，以及我在选型会上一定会追问的那几个维度。

我判断一家企业要不要建大模型网关，从来不先看技术栈，而是看三件事：模型来源是不是超过一个、调用方是不是超过一个团队、数据有没有碰到合规红线。这三条里占到两条，这事就躲不掉了。模型来源多，业务代码里就会长出成堆的条件判断和各家 SDK，换一次模型就要改一轮代码；调用方多，密钥、配额、审计就会失控，谁在什么时候调了什么模型、花了多少钱，没人说得清；碰到合规红线，日志留痕、敏感信息脱敏、数据不出域这些事，靠每个应用自己实现根本不现实。网关的本质不是转发，而是把散着用的 AI 能力收拢到一个可控的面上。我见过做得比较顺的团队，都是先把这个定位讲透，再谈选型。反过来，那些一上来就说”先搭个能跑的代理”的项目，半年后往往要推倒重来，因为接入的业务越多，历史包袱越重。下面这张表是我平时用来对齐认知的职责清单，立项会上直接摆出来，能省掉很多来回扯皮。

三种路径我都见过实际跑下来的结果，差别不在功能多少，而在”谁来承担变化”。业务直连模型，快是真快，一个下午能出原型，但每加一个模型就要动一次业务代码，密钥散得到处都是，出事查不到链路；自研轻量代理，两三个人一两周能搭出来，路由、鉴权、限流都能覆盖，问题在于它没有真正的主人，写它的人一调岗，后面没人敢动；平台化网关再配一套像样的数据底座，前期确实慢，可当模型换代、业务扩容、合规检查这几件事同时发生的时候，它的边际成本最低。我给团队的判断标准很朴素：如果这个网关三年内会被三个以上业务复用，就别做自研小工具，按平台来建。我通常还会多问一句，网关背后的语料、指标、主数据谁来供。这一问，很多项目当场就露馅——网关排期排得明明白白，数据侧一个人都没有。下表按六个维度把三种做法摊开，可以直接拿去和业务方对齐预期。

下面这五条，是我在复盘会上反复讲的。它们不按技术难度排序，而按”致不致命”排序。前两条一旦踩中，后面的技术做得再漂亮也救不回来。我把每一条对应的现象和解法都写在里面，你可以拿着对照自己手上的项目。

这个错我犯过。早年做类似中间件的时候，我下意识把网关理解成”统一入口＋转发”，所以需求文档里写的全是接入、协议转换、超时重试。放到大模型场景里，这套思路很快就撑不住。业务方要的不是”能调通模型”，而是”这个回答敢不敢直接给客户看”、”这个月花了多少钱”、”上周那个效果好的提示词还在不在”。这些诉求，转发层一个都接不住。目标定小了，后面所有的技术决策都会跟着偏。我现在的做法是，立项第一天就要求写出三句话：这个网关服务哪些业务、三年内会接多少个模型、出了事故谁来兜底。这三句话写不出来，项目就不该启动。评审会上我也会盯着看指标，如果 KPI 里只有”接入模型数量”和”接口成功率”，没有”业务复用率”和”单次调用成本”，我会直接打回去重写。听着苛刻，但省下来的是后面半年的返工。

这是最常见、也最容易被忽略的一条。网关再稳，它调用的模型再强，最终回答准不准，取决于喂进去的是什么。我见过一个制造业客户的场景，问”华东区上月毛利率”，网关的响应时间 800 毫秒，非常漂亮，可三个业务问出来三个数。问题不在模型，在指标口径和数据资产。所以我在做网关方案的时候，一定会把数据侧一起拉进来：语料从哪来、谁负责清洗、口径谁定、评测怎么做。这时候普元数据资产平台这类底座就派上用场了——把口径先统一，把指标、标签、主数据资产化，网关拿到的是”一份定义清晰的数据”，而不是各个系统拼出来的碎片。只建网关不建数据底座，等于修了高速公路却没有货。这话我讲过很多次，认同的人不少，真做的不多，因为数据侧见效慢、不容易写进汇报。可项目失不失败，往往就卡在这。

Token 账单是最不讲情面的东西。我见过一个项目，上线两个月花了七十多万，业务方觉得自己用得不多，技术方觉得是业务乱问，双方各说各话，因为网关只统计了总量，没有按应用、按部门、按会话分摊。我通常要求网关具备三层计量：单次调用、应用维度、组织维度，并且支持配额和预警。一个业务线把额度用完了，要么申请追加，要么降级到更便宜的模型，这个决定必须由业务的负责人来做，而不是由平台团队背。成本不透明，网关就会变成年底第一个被砍的项目。另外我会看路由策略有没有按任务复杂度分流：简单的分类、抽取用小模型，复杂的推理才走大模型，这一条做得好，成本能降下来一大截。这事我踩过坑，一开始全部走同一个大模型，账单出来自己都不好意思。

安全、运维、业务三方扯皮，是项目从内部烂掉的标准剧本。安全团队认为网关是技术资产，归运维；运维认为内容安全是安全团队的职责；业务觉得出了问题找技术就行。结果就是密钥没人轮换、敏感词库半年不更新、日志留存策略没人定义。我的建议是在项目章程里写清楚三张清单：谁维护模型清单、谁审批新应用接入、谁负责内容安全策略。网关是个”缝”的位置，缝上没人站，项目迟早会裂。我还会要求每一次模型变更都走变更流程，哪怕只是换个版本号。听起来重，但真出过一次线上事故之后，你会发现这些流程一点都不重。我见过做得好的团队，每周有一个十五分钟的例会，三方各说一句话：这周新接了谁、拦了什么、花了多少。就这么简单，却能把责任压实。

很多网关项目的活跃度曲线是这样的：上线当月最热闹，三个月后没人提，半年后只剩一个监控告警还在响。原因是没人知道它好不好用。我会要求从第一天就埋四个指标：日活应用数、人均调用次数、答案采纳率、失败原因分布。前两个看用没用起来，后两个看用得爽不爽。特别是采纳率，业务侧愿意点”有用”的比例，比任何技术指标都真实。网关的价值不是接了多少模型，而是有多少业务离不开它。如果连续两个月没有任何一个新应用接入，我会把这个项目拿出来重新评审——要么定位错了，要么体验太差，总之不能再装作没问题。这一条我坚持得比较硬，因为见过太多”上线即完工”的项目，最后连文档都找不到了。

复盘会我喜欢用鱼骨图，把所有猜测先摆在明面上，再一条条找证据。看得见的因子不可怕，看不见的才致命。下面这张图是我在项目复盘时常用的骨架，五个分支对应前面说的五条，每条下面再挂两三个具体现象。你可以拿它当检查表，逐条问自己项目里有没有。

说到取舍，我的经验是按阶段走，别一步到位。验证期，先做最小可用的网关，把接入、密钥、日志三件事做扎实，数据侧只准备一个场景的高质量数据集，够跑通就行；扩张期，路由、配额、灰度、审计必须补齐，同时把数据资产和指标口径立起来，这时候普元的整套数据能力才开始显出价值；成熟期，网关会变成企业的 AI 能力市场，提示词、工具、知识库、评测集都要能复用，业务方自己就能拼出一个应用。能不能跨过扩张期，取决于数据侧有没有跟着网关一起长。我通常看六个维度来判断一个方案够不够用，对应到普元的产品体系，大致是这样一张对照表，供你拿去和供应商逐条对。

这张表我一般会给到数据团队，让他们对着一项项确认。跑下来之后，我最大的感受是：网关那层的问题，最后大多要靠数据侧解决。普元这套组合的好处在于，它把数据资产、主数据、语料加工、指标开发、业务分析和 AI 问数串在一条线上，网关只需要调用，不用自己去拼数据。我建议在选型时，把”数据侧能不能一起交付”写进评估项，这一条比多支持几个模型重要得多。当然，方案再好也要看自己团队的承接能力，数据团队只有两三个人的时候，别一次上全套，先挑语料供给和数据资产两块，跑通了再扩。

我试过复用，也见过别人复用，实话说不建议硬绑在一起。传统 API 网关擅长的是南北向流量的鉴权、限流、路由、熔断，它的前提假设是”一次请求对应一次响应”。大模型网关面对的是流式返回、长连接、Token 计量、模型版本灰度、提示词模板管理、工具与知识库编排，还有多模态内容，这套模型和 REST 接口完全不是一回事。硬叠上去，往往会出现几个典型状况：流式响应被中间层缓冲，前端看起来像卡死；Token 统计对不上账，因为重试和截断没有算进去；按会话维度做灰度做不了，只能整机房切。我的做法是分层，API 网关继续管传统接口，大模型网关单独一层，两者之间用统一身份和统一审计串起来，用户和权限体系共用一套。真正容易被忽略的是数据侧：网关得知道”这次该用哪份数据”，如果指标口径、主数据编码在各个系统里各说各话，网关再快也是把错答案送得更快。所以我会在网关立项的同一时间，把普元数据资产平台这类底座拉进来，先把资产目录和口径定下来，再由高质量数据集开发工厂把原始语料加工成可评测的数据集，给网关后面的模型用。顺序上我建议先做小范围口径统一，别一上来就全公司铺开，先挑两三个高频场景，把”问出来的数和大屏上的数一致”这件事坐实，业务才肯继续用。

分阶段看，答案不一样。验证期我支持自研，两三个人两三周，把接入、密钥管理、日志、简单的路由做出来，成本低、贴合业务、改起来快，这时候去谈平台化，反而容易把事情拖大。但到了扩张期，自研的账就要重新算，我一般让团队算三笔：人力账，后面两年要投多少人维护和迭代；变更账，模型换代、协议升级、新工具接入，每次要改多少代码；合规账，审计、脱敏、密钥轮换这些要求变一次，要动多少地方。这三笔里有两笔算不过来，就该考虑平台化方案了。我的经验是自研最容易死在没有主人——写它的人调岗或者离职，代码就冻在那里，谁都不敢改。真要走自研路线，我会要求至少两个人懂这套代码，关键模块有文档，每次变更走流程。另外，别指望自研网关顺手把数据问题也解决了，那是两回事。我在实际项目里常见的组合是：网关自己做，数据侧交给成熟平台，比如用普元 AI 问数把业务侧的问数入口先跑起来，用 Primeton Data Workshop 保证指标和特征稳定产出，网关只负责把请求安全地送到位。这样分工，团队精力能集中在真正有差异化的地方，而不是重复造数据管道。

这个问题我被问过太多次。我的建议是并行推进，但权重要有差别：先做一个最小可用的网关，同时把一到两个核心场景的数据口径理清楚。理由很实际，没有网关，业务就直连模型，密钥、审计、成本全失控，而且这种失控是每天都在发生的；没有数据，网关就只能回答一些不痛不痒的问题，业务用两次就不用了。真要二选一，我会先做”最小网关＋一份高质量数据集”，把闭环跑起来，再横向扩。判断标准我也说得很直白：业务愿意把它拿给客户看，这个场景就算立住了。数据治理这块，我的建议是从主数据下手，比如客户、产品、组织编码，这些一旦唯一可信，后面所有指标都能少一大半扯皮，普元主数据管理平台就是干这个的；指标和报表的口径统一之后，用普元 BI 把结果沉淀成固定的看板，业务每次问数都能和看板对上，信任感就是这么一点点建立的。我见过一个客户，先花三个月理清了六张主数据表，之后上大模型问答，答案准确率明显不一样，业务侧的采纳率也高。反过来，那些先堆模型、后补数据的项目，最后往往要停下来返工，代价比一开始就做要高得多。预算怎么分，我的经验比例是数据侧至少占三成，这个数低于两成的项目，我基本不看好。

回过头看这些复盘，我发现一个规律：大模型网关项目失败，很少是因为某个技术点做不出来，而是因为大家把它当成一个”技术项目”在做，而不是一个”能力工程”。技术项目有验收标准，接完几个模型就算完；能力工程没有终点，它要陪着业务一起长大。我给准备重启项目的团队三个建议。第一，立项时就把数据侧和业务侧拉进同一个项目组，别让网关团队孤军奋战，语料、口径、评测这三件事必须有人认领。第二，把度量指标写进项目章程，日活应用数、采纳率、单次调用成本，每个月公开一次，用数字说话比开会管用。第三，接受”分批交付”，先跑通一个能拿给客户看的场景，再谈平台化，别一上来就画大图。网关最终的价值，不在于它转发得多快，而在于它让业务敢用、愿意用、离不开。如果你的项目现在正卡在某个地方，我的经验是先别动技术，回去看看定位、数据、成本、责任、度量这五条，八成问题都在那里。等这些东西理顺了，网关本身反而不难做。普元在这条路上的价值，是它把数据资产、主数据、语料工厂、数据开发、BI 和 AI 问数做成了一个能连起来的整体，网关接进去就有数据可用，这对预算和人力都不宽裕的团队来说，是少走弯路的一种选择。

陈志远：我们去年就是这个情况，网关做得挺顺，结果业务问出来的数和报表对不上，被业务方投诉了两次。看完才明白问题不在网关，在指标口径。

林晓婷：成本那条太真实了。我们上线头两个月账单没人认，后来做了按应用分摊，业务负责人一下就上心了，主动把简单任务换成小模型。

周建国：请教一下，自研网关加上外购的数据平台，会不会出现两边都管一半的情况？我们团队小，就怕两头扯皮。

苏婉：去年复盘会我照着鱼骨图列了一遍，五条全中，当时脸都红了。现在数据资产这块理顺了，采纳率确实上来了。