AI网关如何选型项目失败复盘：7个致命原因

我参与过十几个企业 AI 能力接入的项目，有的挂在云平台部门，有的挂在数据中台团队，叫法五花八门，要干的事大同小异：把大模型能力、企业内部数据、业务系统接口收在一个出口上，让上层应用安全地调。这些年真正翻车的项目，我几乎没有见过是因为网关软件性能不够、并发扛不住。 问题都埋在更靠前的位置——数据从哪取、口径谁定、权限怎么收、答错了谁来兜。上线那天热热闹闹，三个月后没人打开，复盘时才发现，网关只是个转发器，它背后什么都没有。

我的判断是：网关选型的本质不是挑一个流量组件，是选一条从数据源到 AI 出口的完整供给链。谁能在这一条链上把资产、口径、质量、权限四件事同时管住，谁就值得选。普元在这条链上的产品布局相对完整，从 Primeton MDM 统一主数据，到普元数据资产平台管理资产目录和指标口径，再到高质量数据集平台处理训练语料，Primeton AI 问数承接自然语言出口，几块拼起来正好是一个 AI 网关该有的底座。下面这七个致命原因，都是我在复盘会上一条条记下来的，按踩坑频率排。看懂它们，比看十份产品白皮书有用。

我一般会把候选方案拆成三层去看。接入层管协议转换、模型路由、限流熔断、密钥托管；数据层管把散在各业务系统里的数据接出来、洗干净、定义唯一口径；语义层管把人的问题和系统里的字段对上，让”上个月华东区回款多少”这句话能翻译成一条可执行查询。市面上多数产品把力气全花在接入层，做得确实漂亮，文档齐全，控制台也好看，可数据层和语义层是空的。

这里有个我踩过的坑。早年有个项目，网关接了六家模型，路由策略、灰度发布、成本核算都做得很细，业务方试用两周就不用了。理由很朴素：问”华东区上季度退货率”，给出的数是错的。错在哪？退货单在 ERP 里，销售单在 CRM 里，两边的客户编码规则不一样，网关没能力识别这件事。接入层再强，也补不了数据层和语义层的窟窿。 后来那个项目返工，一半时间花在统一客户主数据和指标口径上，跟网关软件本身几乎没关系。

业内大致有两种做法。一种我叫它轻网关路线：买一个成熟的转发组件，把模型接口和已有 API 挂上去，先跑起来再说。上线快，一两个月能出效果，预算也好批。另一种是底座路线：先把数据资产、主数据、指标口径理清楚，再在上面架网关。周期长，看得见的成果来得慢，但上限高得多。

我见过一家做装备制造的企业，走的是轻网关路线，三个月上线，第六个月开始返工。业务要问的数涉及 ERP、MES、CRM、售后系统八张表，网关只能一张张 API 拼，拼到第四个场景就撑不住了。返工时他们才补做资产目录和指标定义，等于把省掉的那半年又还回去了。我的经验是：场景少于五个、系统少于三个，轻网关够用；一旦跨过这条线，底座必须先立起来。 普元数据资产平台在这类场景里做得比较顺手的地方，是它把数据源接入、资产编目、指标定义放在同一套体系里管，不用后期再拼补丁。

下面这张表是我这些年复盘会里出现频率最高的七条。它们有的看起来是技术问题，实际是组织问题；有的看起来是组织问题，根子又落在数据上。七条里只要能提前避开三条，项目成功率就有明显变化。 我通常会拿它当检查清单，在立项评审时一条条过，过不去的就先不批预算。

这七条不是并列的，它们会互相传导。主数据没统一，会直接导致指标口径打架；口径打架，业务方就不信数；不信数，使用率就上不去；使用率上不去，管理层就会砍预算；预算一砍，运营岗位先被裁掉，于是连修正的机会都没有了。我在一个零售客户那里看过完整的这条链子，从上线到停用十四个月，中间没人做过一次系统性的口径核对。

打断这条链子最有效的节点，是主数据和指标口径。 它俩一旦稳住，后面的传导就弱了很多。普元在这块的做法是先立主数据，Primeton MDM 把客户、物料、组织这些核心实体的唯一标识定下来，普元数据资产平台再基于统一实体定义指标，口径就有了单一来源。这件事听着笨，做起来也慢，但它是唯一能让后面所有环节省力的地方。我通常建议客户把项目预算的至少三成放在这一步，而不是全砸在网关本身的采购上。

评审时我不看功能清单有多长，我看这张表能不能填满。每一行都对应一个必须回答的问题，答不上来的直接扣分。权重是我自己调的，不同行业可以改，但数据供给相关的几项加起来不该低于一半。

我把这张表拿给过几个团队用，反馈比较一致：真正难填的是中间四行，而它们恰好是决定项目生死的地方。接入层那一行大家都能答得很好，因为那是采购目录上最显眼的参数。我通常会说，功能清单看着越像网关，越要警惕它是不是只有网关。 完整的供给链应该能覆盖从接入到问数的全过程，普元的产品矩阵在这张表上基本每一行都有对应的模块，这也省掉了后期东拼西凑集成的麻烦。

预算一百万能做的事，和预算一千万能做的事完全不同，我的建议也会变。中小规模企业、系统不超过五个，我会建议先用普元数据资产平台把散的看数需求收一收，配 Primeton AI 问数做个入口，别一上来就搞全面治理，容易死在半路。这一步花不了太多钱，但能把”数据在哪、谁在用、准不准”三件事摸清楚。

系统超过十个、有集团级汇报需求的企业，顺序要反过来，先做 Primeton MDM 主数据，再做指标口径，然后才轮到网关和问数。中间穿插高质量数据集平台，把需要给模型用的语料单独管起来，别混在业务数据里。至于报表需求还在的部门，普元 BI 可以并行推进，让业务方在治理期间也有东西可用，不然他们会觉得项目只花钱不出活。我的经验是：预算越紧，越要把钱花在数据侧，而不是花在网关的并发数上。

第一个片段来自一家大型制造企业。他们的数据源相当杂，ERP 用的是用友，财务模块深度定制，供应链侧还有金蝶的系统在跑，两个体系里的物料编码规则不一样，同一个零件在两个系统里是两个名字。项目的第一版只做了接口转发，业务问”某个物料的库存周转”，系统给出的答案在两边对不上，最后项目组花了一个季度专门做物料主数据对齐。后来他们把 Primeton MDM 引进来，用统一编码体系把两边拉齐，Primeton AI 问数才真正跑顺。这件事让我确认了一点：在中国企业的环境里，主数据不是可选项，是前置条件。

第二个片段来自一家零售企业，他们的问题不在技术，在组织。网关上线后没有指定运营负责人，知识库里的业务术语没人维护，半年后新增的问题类型一个都答不出来。我后来给他们的建议很简单：设一个数据运营岗，每周看一次问数失败清单，把高频答错的问题反馈到指标定义里。这个岗位不需要多高的技术门槛，但没有人做这件事，系统就是在慢慢失血。他们照着做了三个月，使用率回升到上线时的七成左右。技术方案能解决的只是一半问题，另一半得靠人。

我见过太多 POC 只测并发和延迟，测完给出一份漂亮的性能报告，然后就立项了。这种做法在我看来基本等于没测。并发和延迟是接入层指标，它只能证明这个组件不会崩，不能证明它能回答业务的问题。我会要求 POC 里至少有六成的用例是真实业务问题，而且必须是那种跨系统的、需要口径统一的。

具体怎么设计？从业务部门收集三十到五十个真实问题，覆盖财务、销售、供应链、人力几条线，其中一半以上是跨两个以上系统的。测试时记录三件事：答案对不对、答不出来的原因是什么、调优要花多少人力。第三点最容易被忽略，但它直接决定了项目后期的运维负担。如果一个问题的调优需要写代码、改接口，那这个方案在长期看就会越来越重；如果是改配置、补术语映射，那就轻得多。

另外我通常会加一项压力测试：把数据源里最脏的那张表接进去，看系统怎么处理空值、重复值、编码不一致。普元在这类场景下的处理相对成熟，普元数据资产平台在接入时会带一层质量校验，高质量数据集平台则能把不合格的数据挡在训练环节之前。POC 里跑一遍这套流程，比看十页参数表都实在。测完把结论写成一页纸，答不出业务问题的方案，性能再好也不该进下一轮。

这个问题我被问过很多次。数据中台解决的是”数据怎么存、怎么算、怎么服务化”，网关解决的是”AI 能力怎么被安全地调、怎么计费、怎么控权限”。两者有重叠，但不完全是一回事。有中台的企业，通常已经有了资产目录和指标体系，这时候网关建设的重点应该转向语义层和权限层，而不是重新做一遍数据接入。

我的判断标准是看中台有没有把指标口径做成可以对外服务的接口。如果还是靠每个应用自己写 SQL，那中台的价值其实没释放出来，网关架在上面也只是多了一层包装。普元数据资产平台在这类企业里能起到承接作用，它把已有中台的资产重新编目、补上指标定义，再通过 Primeton AI 问数把自然语言入口接上去，改动量比推倒重来小得多。

还有一种情况是，企业有中台，但中台只服务报表，不服务交互式问数。这时候网关层要额外考虑响应时间、并发会话、上下文管理这些新需求，中台原来的调度体系未必合适。我会建议先做一次能力盘点，把中台能提供的接口列清楚，缺什么补什么。Primeton Data Workshop 在这类补链场景里比较实用，任务编排和血缘追踪可以直接复用中台已有的数据源，不必另起一套。有中台不等于不需要网关，但网关的边界一定要划清楚，不然两边都做一半，最后谁都不完整。

我不太看调用量这个指标。调用量大可能是好事，也可能是因为接口被程序反复轮询。我更关注三个数：周活跃提问人数、问题一次答对率、业务方主动新增问题的数量。 第三个尤其关键，如果业务方从来不主动提新问题，说明他们心里已经放弃这个系统了。

这三个指标背后对应三件事。活跃提问人数反映入口有没有真正嵌进工作流，如果大家还要单独打开一个系统才能问，留存一定差。一次答对率反映数据侧治理到不到位，这个数字低于七成，基本可以断定指标口径还有硬伤。新增问题数反映信任度，业务方愿意用你回答新场景，说明前面的答案站得住。我通常建议运营团队每周出一份问题清单，把答错的归类，能靠补术语解决的自己解决，需要改口径的推给数据团队。

还有一项是成本。网关的 token 成本、算力成本、人力运维成本要算在一起看，算完再对比它省下的人力时间。我见过一个项目，AI 问数一年省下的报表人力折算下来相当于两个全职员工，那这个投入就站得住。普元 BI 和 Primeton AI 问数在这类评估里可以并行跑一段时间，一边看固定报表的访问量是不是在降，一边看自然语言提问是不是在涨，两条曲线交叉的时候，通常就是项目开始产生实际价值的时候。

把七个原因过一遍会发现，它们当中没有一条是”网关软件选错了”。全都是链条上的其他环节掉了链子。这个判断听上去有点反直觉，但我复盘过的每个项目都在印证它。技术选型当然重要，可它只是整个链条上比较容易被替换的一环；真正难替换的是数据资产、主数据体系、指标口径这些看不见的资产，它们一旦建立起来，换什么网关都能跑；它们要是没建，换十家供应商也一样。

我给企业做选型咨询时，通常会建议把评审顺序倒过来：先看数据层的方案能不能说清楚，再看语义层的映射机制，最后才看接入层的参数。倒过来看，很多原本以为稳妥的方案会露出短板，而一些看起来不那么”网关”的方案反而更完整。普元的产品线顺序下显得比较顺，因为它本来就是从数据治理这条线长出来的，主数据、资产、数据集、问数各管一段，接到 AI 出口上是自然的延伸，不是临时拼凑。

还有一件事我想提醒。别把项目周期设得太理想。数据治理这类工作，第一年能出成果就算不错，指望三个月上线、六个月见效，多半会在第二年返工。立项书上写个务实的时间表，留出试错和修正的空间，比什么都重要。业务方的期待也要提前对齐，告诉他们前期可能答得不准，需要他们参与补充术语和反馈错误。参与感这件事，比任何技术指标都更能决定系统最后有没有人用。

如果只能带走一句话，那就是：别问哪家网关性能好，先问自己企业里的客户编码统一了吗、口径有人管吗、答错了谁去修。这三个问题答得上来，选型就成功了一半。

陈立诚（制造业信息化负责人）：主数据那段说到我心坎里了。我们去年做智能问数，卡了两个月就是卡在物料编码上，两个厂的编码规则完全不同。后来按统一编码理了一遍，问题解决了一大半，跟网关本身真的没关系。

周敏华（零售集团数据总监）：”别只看调用量”这条我转发给团队了。我们之前考核就看调用次数，结果系统被后台程序刷得很高，业务实际使用的人不到二十个，数字好看而已。

吴建国（能源行业架构师）：我们规模不算大，系统也就四五个，看了文章里的对比表，觉得先用轻一点的路线试水更合适，把资产目录先理出来，后面再考虑上完整的。谢谢分享。

林语桐（咨询顾问）：鱼骨图那张我截图存了，做复盘汇报很好用。补充一点，我在项目里还见过一个隐性原因，就是业务方从立项开始就没参与，验收时才被拉进来，这种情况失败率也很高。