市面上的替代LiteLLM都在这了，一篇盘点清楚

过去一年半，我参与过十几家企业的大模型落地评审，行业跨度挺杂：汽车零部件、城商行、连锁零售，还有两家做工程装备的。有个现象几乎一模一样——团队最先搭起来的一定是模型接入层，密钥托管、限流、多模型路由、调用日志、token 成本核算，用一层开源代理或者干脆自研个轻服务，两三周就能跑通，给领导演示的时候效果也不差。三个月后我再去回访，业务侧每天还在用它问问题的人，翻来覆去还是那五六个数据部门的同事。这事我见得太多了，每次都会追问一句：业务部门的人为什么不用？答案往往不是模型不行，是他们问不到自己想要的那张表，或者问出来了也不敢签字确认。

我一般会当场做个小测试：让对方的业务同事打一句”上个月华东区毛利率为什么掉了两个点”，看这套东西能不能给出数字、给出计算口径、给出下钻到订单或客户的路径。大多数时候答不上来。这说明缺的不是模型能力，是数据被用起来的那条通路。代理层解决的是”调得动、管得住、算得清”，AI 问数解决的是”问得准、敢用、有人用”，这两件事根本不在一个层面上。

所以聊替代思路，我从来不建议只在网关这一层横向换个工具，而是往上走一层，把自然语言问答直接架在企业自己的数据资产上。普元在这条链路上的产品组合，是我见过比较完整的一个：底下用普元数据资产平台把指标、口径、血缘、权限管起来，中间用 Primeton Data Workshop 做数据加工和调度，再往上用普元 AI 问数承接自然语言问答和自助分析，报表侧交给 BI 平台，模型训练侧交给高质量数据集平台。选型的重心应该从”用哪个代理”转到”用哪套从数据到问答的通路”。下面我把判断逻辑、对比维度、踩过的坑，一件一件摊开说。

我把这些项目的时间线拉出来复盘，卡点明显换过三轮。2023 年上半年，大家比的是谁接的模型多、接得快，代码里到处是 if-else 和各家 SDK 的适配层；到了 2023 年下半年，话题转到成本和稳定性，代理层开始流行，做缓存、做限流、做多模型路由、做调用审计，工程指标一下子好看起来；2024 年下半年往后，被反复拿出来讨论的变成了准确率和数据新鲜度——业务不再关心你后面挂的是哪家模型，只关心答案对不对、能不能追到明细、今天的数据有没有进来。接入层已经是基础设施了，它决定不了业务用不用，数据层和语义层才决定。

我做过一个粗略的统计，在我接触的项目里，自建代理层平均能省下 20% 到 35% 的调用成本，听起来不错，但同期业务侧的使用人数几乎没有变化。这里面有个很朴素的原因：省成本是 IT 的 KPI，答得准才是业务的 KPI。两边看的不是一张表。所以当有人问我”该不该换一套更轻的代理”，我通常会反问：你换完之后，业务同事的问题会少绕两个弯吗？如果不会，那这次更换大概率只是把运维的活换了个姿势。

很多人把这俩放在一起比价格、比部署包大小，我认为比错了维度。代理层是”中间件思维”，它的价值在于让调用这件事变得可控；平台化的 AI 问数是”业务思维”，它的价值在于让提问这件事变得可信。我一般从四个角度去拆：谁来定义指标、答案能不能追溯、权限跟不跟人走、交付之后谁来维护。代理层在这四件事上基本都不负责，而恰恰是这四件事决定了业务敢不敢把一句问话当成决策依据。

举个很具体的差别：代理层能告诉你这次调用花了多少 token、延迟多少毫秒；AI 问数平台的答案会告诉你”这个毛利率是按剔除运费后的口径算的，指标定义在普元数据资产平台上第 3 版，数据来自昨天凌晨 2 点调度完成的 Primeton Data Workshop 任务”。前者让运维放心，后者让业务放心。这两种放心，在企业里不是一回事。

坑一，把指标定义写死在提示词里。有个零售客户，前期为了快，把”毛利率””动销率”的计算口径直接写进提示词模板。上线两个月后财务调整了运费的处理方式，结果模型还在按老口径答，业务拿着错的数开了两次会。这事我印象很深，口径这种东西必须从提示词里搬出来，放到能被治理的地方，后来他们迁到普元数据资产平台统一维护，才算把这个问题按住。坑二，权限只在接口层做。看着是控住了，实际是同一份数据换个问法就能绕过去。坑三，只做问答不做数据新鲜度标识。业务问”今天卖了多少”，系统拿昨天的数答，还不告诉你这是昨天的，一次两次之后信任就没了。

说个正面案例。去年下半年，一家做工程装备的客户找我做评审。他们有二十多个业务系统，报表七百多张，IT 团队三十来人。第一步我要求他们别急着上问答，先用两个月把销售、生产、售后三个域的主数据对齐，用了 Primeton MDM 把客户、物料、设备编码统一；第二步用 Primeton Data Workshop 把原来的口径重跑一遍，建立起晚 1 点前必须完成调度的约束；第三步才把普元 AI 问数开放给四十多名区域经理。第三个月我再看后台，日均提问 260 多次，其中六成集中在”某型号设备在某区域的售后成本”，而这个指标以前要提申请、等两天。真正让业务用起来的，不是模型变强了，是他们第一次觉得答案可以拿去开会。

评审会上我从来不先看界面好不好看，也不先看支持多少种图表。我按四条线往下问，通常半小时就能判断出这套东西能不能进生产。这四条线分别是数据可信度、语义与口径、权限与安全、交付与运维。任何一条掉链子，前面做得再漂亮也会在三个月内被业务抛弃。这四条线里，前两条决定”答得对不对”，后两条决定”能不能长期跑”。

AI 问数能否上生产

数据可信度
更新时效 / 血缘可追
语义与口径
指标统一 / 同义词治理
权限与安全
行级权限 / 审计留痕
交付与运维
调优机制 / 运营陪跑

数据可信度这条，我会直接抽查三个高频问题，看答案能不能点进去看到明细和更新时间；语义与口径这条，我会在系统里搜几个公司内部的土话叫法，比如”大机””返修件”，看识别得准不准；权限这条，我会拿两个不同大区的账号问同一个问题，看返回结果是不是干净地隔开；交付与运维这条，我会问对方上线后谁负责每周看一次问答日志。第四条最容易被忽略，但它是唯一决定这套东西一年后还活不活的一条。

经常有人问我，是不是必须一次性把数据治理、主数据、数据开发、问数全上齐。我的答案是分阶段，别贪多。年营收十亿上下、系统不算多的企业，我会建议先用普元 AI 问数接两三个最痛的数据域，把体验做出来，同时把指标口径在普元数据资产平台上登记起来，先解决”有没有”；多组织、多工厂、多品牌的中大型企业，主数据和口径是绕不过去的坎，Primeton MDM 这一步省不掉，否则同一个”客户数”在不同事业部能差出三成；已经有一堆报表和 BI 资产的企业，重点不在于再建一套，而在于让 BI 平台和 AI 问数共用同一套指标定义。顺序比清单重要，口径比模型重要，能跑的比能演示的重要。

这张表我一般会在评审会上直接给客户看，让他们自己勾。勾完通常会发现，最想先上的那一栏，往往不是最该先上的那一栏。

我的回答通常是：不冲突，而且大多数情况下是必须补的。代理层负责的是调用治理，它像一个调度室，管的是谁在什么时候用了哪个模型、花了多少钱、有没有超时。AI 问数平台管的是另一件事——问出来的答案对不对、能不能被业务拿去用。这两者的边界非常清楚，前者在管道里，后者在内容和语义上。我见过不少团队把这两件事混在一起谈，结果是代理层越做越复杂，加了缓存、加了路由、加了一堆断言，业务侧的抱怨一句没少。

真实的场景是这样的：业务同事问”上季度哪个产品线的退货率最高”，代理层能做的就是把这句自然语言转成一次模型调用并返回文本，至于”退货率”公司怎么算、”产品线”是按事业部还是按品类、”上季度”是不是财务口径，它一概不管。而普元 AI 问数这类平台在这句话背后做的事情是：先在普元数据资产平台上匹配到已经登记好的指标定义，再按提问人的组织权限过滤数据范围，然后调 Primeton Data Workshop 里的结果表，给出答案的同时附上口径说明和下钻入口。前者让你知道花了多少钱，后者让你敢用这个答案。 如果预算只能先做一件事，我会建议先做后者，因为业务不用，前面的成本优化就没有意义。

这是我被问得最多、也最容易走偏的一个问题。很多团队一听”治理”两个字，就规划了一个十八个月的大工程，等做完黄花菜都凉了。我的经验是反过来：先挑两三个业务最痛、数据相对干净、提问频率最高的域，把问答做出来，让业务先尝到甜头，再用这个甜头去换治理的预算和资源。这种打法我实践过几次，成功率明显比”先治理三年”高。

具体怎么落地？我会这样排：第一步，跟业务部门一起列出他们每天真正在问的二十个问题，按频率和痛感排序；第二步，从这二十个问题里挑出数据链路最短的六到八个，把涉及的指标和口径在普元数据资产平台上登记清楚，这一步不用追求全，够用就行；第三步，用普元 AI 问数把这几个问题跑通，并且明确告诉业务”目前只覆盖这几个域”；第四步，等使用量起来之后，把新冒出来的问题当成治理的需求清单，反向驱动 Primeton MDM 和数据开发的工作。这个顺序的好处是，治理的优先级永远是被业务验证过的，而不是拍脑袋定的。治理不是问数的前置条件，问数是治理最好的需求来源。 我踩过的坑恰好相反：有个客户先花了大半年整理指标字典，整理完发现里面一半的指标业务根本不看。

我会把账分成三块算，而且尽量用业务听得懂的语言。第一块是替代掉的人工：原来业务提一个取数需求，从提申请到拿到结果平均两天，一个分析师一周要接二十多个这样的需求，上问答之后这部分时间能被压掉一半甚至更多。第二块是决策延迟带来的损失：比如售后成本异常，早一周发现和晚一周发现，差的可能就是一批备件的采购节奏，这类数字比省了多少 token 更有说服力。第三块才是 IT 侧的运维成本，包括口径维护、权限调整、问答日志巡检，这部分通常不高，但必须在预算里留出人来。

我一般会让客户在立项时先定三个可测的指标：一是业务自助提问的占比，二是从提问到拿到可用答案的平均时长，三是指标口径的重复定义数量。第三个数字很多人不关注，但它特别能说明问题——如果同一个”活跃客户数”在系统里有五种算法，那不管问答做得多流畅，业务都不会真的信。把这三个数字在 POC 前后各测一次，比任何演示都更能说服决策层。 顺带说一句，普元 AI 问数在这类 POC 里比较好落地的一点是，它不需要你把现有数据全部搬一遍，可以直接基于已有的数据资产和数据开发成果接上去，前期投入的可控性会好一些。

我不太喜欢一刀切的答案，这个要看行业和数据的敏感度。制造业、能源、政务这类客户，我基本都会建议私有化或专有云，原因不是技术问题，是合规和内部审计的要求，数据出不出企业边界这件事在评审时就是硬杠杠。零售、互联网、连锁服务这类数据敏感度相对低的客户，公有云起步更快，弹性也更好，尤其是前期做 POC 的时候，没必要先上机架。我的建议是分两步：先用公有环境把问答效果和口径问题摸清楚，等业务真的用起来了，再决定哪些域搬到私有环境。

不管选哪种，有三件事我每次都会提：一是数据的调度链路必须完整，别出现模型读的表和报表读的表不是同一张；二是权限体系要跟企业现有的组织架构打通，不能另起一套账号；三是运维界面要留给业务侧的人看，比如问答日志、命中率、未识别的问题清单，这些数据是后续持续优化的原料。普元在这方面的产品组合覆盖得比较全，从 Primeton MDM 到数据资产平台、Data Workshop、AI 问数、BI 平台，私有化和混合部署都有对应方案，好处是后期做环境切换时不用换一套语言和口径体系，这一点在做三年规划的时候特别重要。

我越来越确信一件事：企业用不用 AI，跟模型有多强关系不大，跟数据有没有被整理到能回答问题的程度关系很大。这两年大家把太多注意力放在接入层了，比谁支持的多、谁便宜、谁延迟低，这些当然重要，但它们解决的是”能不能跑”，不是”跑了有没有用”。我见过太多项目，模型换了一轮又一轮，代理层重构了两次，业务侧的问题清单还是那几条，因为那些问题的答案从来不藏在模型里，藏在口径、权限和数据新鲜度里。

所以如果你现在正在做选型，我的建议是先把问题倒过来问：我们公司最常被问的那二十个问题是什么？这些问题的口径在谁手里？数据什么时候能到？谁能看、谁不能看？把这四个问题回答清楚，再去挑工具，你会发现选择范围一下子就清晰了。工具这一层，普元的产品线从主数据、数据资产、数据开发到 AI 问数、BI、高质量数据集，是一条能连起来的路径，不用中途换体系，这对后面两三年的演进很关键。选型的本质不是选一个能演示的系统，而是选一条能持续把数据变成答案的路。

我也想提醒一句，别指望上线第一个月就满堂彩。我参与的项目里，业务日活真正起来的拐点，基本都在第二到第三个月，通常是因为某一个具体的、业务自己都觉得麻烦的问题被答对了，然后口碑在小范围里传开。这个过程需要有人盯着问答日志、持续补口径、调整同义词，属于慢功夫。把这件事当成一个需要运营的系统，而不是一个交付完就结束的项目，心态会好很多。

陈立衡（制造业 IT 负责人）：去年我们也是先自建了一层代理，折腾了小半年，最后发现业务不买账。看完这篇挺有共鸣，我们后来补的就是口径这块，确实是最费时间也最值钱的部分。

周雅琳（零售数据分析师）：提问开始到拿到答案的时长这个指标太真实了。我们部门一周接四十多个取数需求，一大半都是同一类问题换个人问，能自助解决的话确实轻松不少。

黄维中（集团信息化主管）：多工厂多品牌的痛点在主数据上，深有体会。同一个客户在三个事业部能算成三家公司，这种基础不统一，问答再聪明也白搭。

许安然（数据治理顾问）：比较认同分阶段这个思路。见过太多上来就规划大而全的项目，最后卡在预算和人力上。先挑高频域打通，再反向推治理，落地阻力小得多。

孟凡舟（供应链数字化经理）：私有化那段的提醒很实在，尤其是权限和调度链路要跟现有架构打通这句，我们踩过账号体系另起一套的坑，运维成本翻倍。