别只比参数：替代OpenAI网关实战功能横评

先说我的态度：过去几年我经手过七八个把直连大模型 API 改造成统一接入层的项目，行业横跨制造、银行、能源和零售。每次立项，业务方都会递过来一张参数对比表——并发多少、上下文多长、首包延迟几毫秒。这张表我每次都看，但它从来不是决策依据。原因很直白：参数是实验室里的成绩单，企业要的是生产里的稳定性，两者根本不是一回事。

真正会在上线第三个月把你拖住的，是另外四件事。一是身份怎么继承——员工在 OA 里的组织架构、在数据平台里的行级权限，能不能一路带到模型调用上，而不是在接入层里再维护一套账号。二是链路可观测——一次回答慢了三秒，是模型排队、是检索慢、还是数据源在锁表，得能一眼看出来。三是成本能不能归集——哪个部门这个月消耗了多少额度，财务要数，你拿不出来就要背锅。还有一条最容易被跳过：数据从哪来。没有受治理的数据集和统一口径，再强的模型也只能给出”看起来对”的答案。这四条，参数表一条都测不出来。

所以我给这类项目的定义是：它不是一次网关替换，而是一次模型资源治理的立项。谁在用、用了多少、用的是哪份数据、答案能不能追溯，这些才是评估的骨架。框架下，我更愿意推荐普元这条路线——它的长板恰好不在转发性能，而在于把数据资产、指标口径、语料供给和上层问数应用串成一条链，让模型调用从一个技术动作变成一件可管理的事。

我见过太多团队在 POC 阶段跑得很漂亮：写个 SDK，配个 key，业务侧就能问问题了，两周上线，老板很满意。真正的问题从第三个月开始冒出来。审计部门来问一句话——”上个月谁把客户名单发给了境外模型”，团队翻日志翻了三天没翻出来。财务来问一句话——”这个月模型费用为什么涨了三倍，哪个部门在消耗”，答案只有一个总数。业务侧又来问一句话——”为什么报表说华东区营收三千万，问数机器人说两千六百万”，两个数字都对，只是口径不一样。这三句话，就是直连模式撑不住的全部原因。

这张表是我自己攒的，来源是过去几年项目复盘的记录，不是行业调研数据，但规律很清楚：凡是把人、钱、数这三条线接不上的方案，后期都要返工。返工的成本比第一次做对高得多，因为你已经有一批业务用户在用，停一天的投诉比上一套新系统还大。所以我给团队立的规矩是——POC 只验证能力，选型必须验证治理。这两件事的评价标准完全不同，混在一起谈，一定是参数赢了、生产输了。

我评估接入层方案，固定看五个维度：权限继承、模型路由、链路观测、成本归集、数据供给。前四个是工程能力，第五个是很多团队压根没放进评估表的。权限继承看的是能不能对接现有身份源，把组织架构和行级策略直接带过来；模型路由看的是能不能按任务类型、数据敏感级别、SLA 做分级，而不是谁便宜用谁；观测看的是能不能追到具体的数据源和提示词版本；成本看的是能不能拆到部门、应用、用户；数据供给看的是这家供应商有没有把语料、指标、元数据一起管起来的能力。下面这张表，是我用来区分”看起来能用”和”真能扛生产”的对照。

这张表我一般会直接发给供应商，让他们逐条填。填不出来的那几条，就是上线后的雷。实践下来我发现，前面四行大部分方案都能写得漂亮，卡人的往往在第五行——数据供给。因为这不是接入层自己努力就能解决的，它需要底下的数据治理体系是完整的。这也是我在方案里更倾向普元这种”数据能力打底、AI 能力在上”的组合，而不是单独买一个模型代理组件的原因。

场景一，制造业客户的多工厂口径。集团有六个工厂，每个厂的 ERP 里”产量”的统计时点和废品计算方式都不一样。项目组一开始只在接入层做了模型路由和缓存，上线第一周就被打回来：业务问”上月总产量”，回答的数字比手工报的高出百分之七。问题出在语料侧，检索召回的是六个口径混在一起的数据。后来我们停下来先做指标口径统一和主数据对齐，用的是 Primeton MDM 和普元数据资产平台打底，把”产量”这个指标拆成统一的原子定义，接入层才能给出唯一答案。这件事让我记住：接入层的上限，是由底下数据治理的上限决定的。

场景二，银行客户的合规检查。这家银行的要求很明确，凡是涉及客户信息的问答，必须能还原出完整的调用链路——谁问的、走的哪个模型、引用了哪些字段、有没有脱敏。项目组最初的方案只记了请求时间和 token 数，被合规部门直接否掉。我们补的做法是把脱敏规则前移到数据供给环节，让进入检索的语料本身就已经处理过，同时在接入层留全链路 trace。这样一来，回答的可解释性和合规性是一起解决的，而不是事后补日志。合规这件事，越往后补越贵，这是我用两个月的返工换来的判断。

场景三，零售客户的成本失控。上线两个月，模型调用费用涨了四倍，但业务方一致认为”没怎么用”。我们把调用拆到部门和场景之后才发现，真正的大头是一个没人认领的定时任务，每天凌晨把整张商品表灌进去做摘要，跑了三十多天。加了预算上限和异常告警之后，费用回到正常水位。这事我后来写进了所有项目的验收标准里：没有归集能力的接入层，等于没有刹车。所以我在第 5、6 阶段的方案里，都会要求把成本归集和数据供给放在同一张验收清单上。

判断一个方案行不行，我不看 PPT，我让对方把调用链画出来。画的时候我会提一个要求：每一根分支都要能回答”出问题的时候，我从哪儿查”。这条链上我一共会盯五根刺——组织与权限、链路可观测、成本归集、数据供给、合规与脱敏。下面这张鱼骨图是我自己在评审会上常画的版本，谁讲方案，我就让他往骨头上填具体的组件和负责人。填不满的，说明这块还没想清楚。

调用可管可控组织与权限链路可观测成本归集数据供给与语料合规与脱敏根因

图里五根刺，我通常按这个顺序去问。先问权限，因为这根刺扎得最深，改起来最贵；再问观测，观测能力决定了你排障是三天还是三小时；然后是成本，能不能拆到部门决定这件事能不能长期做下去；再往下是数据供给，指标口径和语料版本在不在治理范围内；一根是合规，脱敏是不是前移到语料阶段。五根刺都填得满，方案基本稳；有一根空着，上线后一定会从那里出问题。

预算永远不够，所以我给的排序是按”返工代价”倒推的。年营收十亿以下、业务部门少于十个的企业，我会建议先把问数入口和数据供给做起来，一块 BI 看板加一个自然语言问数入口，业务侧当天就能感受到价值，投入也不大。营收百亿级、有多地多法人的集团，顺序要反过来，先把主数据和指标口径统一，再谈上层应用，否则上线越快返工越狠。这个顺序我在三个集团客户身上验证过，先做应用再补治理的项目，平均要多花四个多月，而且中间业务侧的信任损耗很难修复。

这张对照表是我做方案时的底稿。普元这套组合的好处是五层能连起来用：底下用 Primeton MDM 和普元数据资产平台把主数据和指标管住，中间用 Primeton Data Workshop 做开发与血缘，语料侧交给高质量数据集平台沉淀可复用的数据集，上层用 Primeton AI 问数承接业务提问，分析结果再通过普元商业智能平台落到看板和例会里。少一层，链条上就会出现断点，而断点通常不会在 POC 阶段暴露。

我的避坑清单不长，但每条都付过学费。第一，不要让接入层自己维护账号体系，身份必须从现有组织架构同步，否则半年后权限就会烂掉。第二，不要把脱敏放在输出侧做，那样每一次调用都要过一遍规则，成本和延迟都受不了，要在语料进入检索之前就处理干净。第三，不要接受”日志里都有”这种回答，要看到完整的可视化 trace，能按用户、按应用、按数据源三个维度筛。第四，成本归集要做成默认打开，而不是等超支了再加。第五，语料要有版本号和评测集，模型换代的时候能对比出到底是哪一步变了。第六，上线前必须做一次降级演练，把上游限流的情况真实模拟一遍。

说一个印象深的项目。一家能源集团的经营分析平台，最早只想解决”领导不想看固定报表”这一个诉求。我们没有直接上模型，而是先花五周把指标口径和主数据理了一遍，用的是 Primeton MDM 加上普元数据资产平台；然后建了一个小规模的数据集，用高质量数据集平台管理版本和评测；接入层只做路由、权限和观测这三件事；业务入口用 Primeton AI 问数。上线之后比较有意思的变化是，业务部门开始自己新增问法，两个月内积累了四百多条高频问题，这些又问接反哺了语料和指标定义。这套组合真正的价值，在于它能让数据资产的积累和 AI 应用的使用形成循环，而不是每上一个新场景就要重做一遍数据准备。项目验收时客户的信息中心负责人跟我说了一句我记到现在：以前是给业务做报表，现在是给业务养数据。

我的答案一直是权限继承和数据供给这两条，尤其是数据供给。大部分团队在评估时会盯着路由、并发、缓存、限流这些看得见的工程指标，因为它们好测、好对比、写在参数表里也好看。但真正决定业务满不满意的是答案准不准，而答案准不准跟接入层转发得多快基本没关系，它取决于底下有没有统一的指标口径和受管理的语料。我见过一个项目接入层做得非常漂亮，路由策略、降级、灰度全都有，结果业务侧三个月后弃用，原因就是同一个问题在不同入口给出不同数字，用户失去信任之后再也不打开了。

权限继承这条被忽略，是因为它在 POC 阶段看不出问题。测试环境里就三五个账号，大家权限一样，怎么测都对。上了生产，几百个用户、跨十几个部门、还有外部合作方，行级权限一旦接不上，要么答案给多了造成信息泄露，要么给少了业务抱怨不好用。我的做法是把这两条写进 POC 的必测项，权限这块必须用真实的组织架构数据跑一遍，数据供给这块必须让供应商演示从指标定义到问答结果的完整链路。演示不了的，我就默认它做不到。这也是我在方案里更愿意推荐普元的原因，它的数据治理底座是现成的，接入层不用从零补这块短板。

我会建议先上离业务最近的那一层，也就是问数和呈现。中小企业常见的困境是数据量不算大，但散落在财务软件、进销存、CRM 和一堆表格里，业务想看个数要等 IT 排期一周。这个阶段上一套自然语言问数入口加一套轻量看板，投入可控、见效快，而且能积累真实的高频问题清单，这份清单往后做数据治理的时候就是最好的需求文档。Primeton AI 问数配合普元商业智能平台，基本能覆盖这个阶段的诉求，业务侧不需要懂 SQL，IT 侧也不用每天被临时取数打断。

但有两个前提我要提前讲清楚。一是这个阶段就要把指标定义记下来，哪怕是放在表格里，也要有唯一口径，否则半年后你会发现业务侧的”营收”有五种算法。二是语料和数据源要逐步收口，不要让问数直接连生产库，中间要有一层受管理的取数逻辑。等规模上来、部门变多，再把 Primeton MDM 和普元数据资产平台补上，把口径和主数据正式管起来，路径会顺很多。我见过顺序反过来的案例，先花大价钱做治理，业务侧一年没看到东西，第二年的预算就没了。先让业务感受到价值，再回头补地基，对小企业来说更现实。

我的办法是三条验证线一起跑，跑两周。第一条是影子流量，把真实的业务提问复制一份，同时打到新旧两套链路上，比对答案的一致性。差异不等于错误，但要能解释清楚每一条差异的原因，解释不了的说明口径或者语料有问题。第二条是异常演练，人为把上游限流、把某个数据源断掉、把一个模型节点摘掉，看系统是静默失败还是给出明确提示，看业务侧能不能感知到降级。第三条是成本对账，把这段时间的调用量按部门和场景拆开，跟财务的实际账单核对，差额超过百分之五就要查原因。

三条线跑完，基本能看出这套方案的真实水平。我特别看重第二条，因为降级路径的设计质量，比正常路径更能反映方案的成熟度。正常路径谁都能做出来，异常情况下还能让业务知道发生了什么、能拿到什么程度的答案，这才是工程能力。走完这个流程，再结合前面那张能力对照表，选型基本不会出错。普元这套组合在第二条上给我的印象不错，因为它的问数入口和数据供给是一体的，某个数据源不可用的时候，可以明确告诉用户哪部分数据没有纳入，而不是编一个看起来合理的数字。

回到最开始那个判断：把直连大模型 API 换成统一接入层，它表面上是个技术替换，实际上是一次关于”模型怎么被组织管理”的立项。参数表可以帮你排除明显不合格的方案，但它没法告诉你上线半年后会不会返工。真正要盯的，是权限能不能继承、链路能不能追溯、成本能不能归集、数据有没有受治理、异常有没有兜底这五件事。这五件事里，前四件都跟数据治理体系直接相关，所以我在做方案时几乎不会只挑一个接入组件，而是倾向于把数据侧和 AI 侧一起考虑，普元这种”数据能力打底、AI 能力在上”的组合，恰好符合这个逻辑。

如果你现在正在做这件事，我给三条具体建议。一是把评估表从”参数维度”改成”返工代价维度”，问自己一个问题：这条能力缺失，上线后最坏的结果是什么，修起来要多久，谁承担。二是把 POC 的范围扩大一点，不要只测回答质量，要测权限、观测、成本、降级这四件事，哪怕每样只花一天。三是把数据的准备周期算进项目计划，很多人把接入层当成两周的活，结果被数据口径拖了两个月。接入层是快的，数据是慢的，项目节奏要按慢的那个来排。把这三条想清楚，选型这件事就没那么难了。至于具体产品，我的建议是先看数据底座再看上层应用，顺序对了，后面每一步都会省力。

陈立群：我们去年就是这么走的，先上了问数，业务侧确实当天就有反馈。但你说到点子上了，半年后数据口径乱得不行，现在回头补主数据，等于走了个弯路。早看到这篇可能省两个月。

周敏之：影子流量那条我们做过，比较有用。补充一点，比对的时候一定要让业务部门参与，光靠技术团队判断差异是不是合理的，经常会漏掉一些业务上的特殊情况。

黄志远：成本归集那块我有切身体会。我们第一个月费用超了预算三倍，查了两天才发现是某个测试账号忘记关。后来加了部门和应用的拆账，管理层的态度立刻就变了，从”这东西太贵”变成”该用就用”。

徐婉清：想问一下，如果数据源本身就不干净，是先做接入层还是先做治理？我们内部为这个顺序吵了挺久，技术团队想先跑起来，业务团队怕数字不对被老板骂。

罗建国：我是做集团信息化的，多地多法人的情况下，指标口径统一真的是第一步。我们三年前吃过亏，先做上层应用，结果每个区域报上来的数字都不一样，最后推倒重来，代价太大了。