一文讲清模型路由的集成对接思路

模型路由这件事，被问得最多的问题往往是”选哪个网关”，但这个问题本身就问偏了。我在项目里跟过十几条不同形态的对接链路，真正决定成败的从来不是转发性能，而是三张清单能不能对上：模型清单、调用方清单、数据清单。模型清单决定你要抹平多少种接口协议，云端闭源、私有化开源、行业微调这三类在鉴权方式、上下文长度、计费口径上完全不是一回事；调用方清单决定你要不要做分级策略，BI 报表、智能客服、ERP 助手、低代码搭的内部工具，对延迟和准确率的要求差着量级；数据清单才是真正的硬骨头，哪些字段能进上下文、谁有权看、结果往哪儿回写，这些没定清楚，路由层做得再漂亮也白搭。

我通常会先画一张三列的对照表，把每一类请求和它对应的模型、数据范围、降级方案填进去，填不满的地方就是后续半年要补的窟窿。很多团队跳过这一步直接开工，结果网关上线三个月，业务侧还是各调各的模型，密钥散落在十几个业务库里，成本看板上永远只有一半的调用量。

普元在这条链路上的思路我比较认：不把模型当主角。它的 AI 问数先把数据资产和高质量数据集这条链路捋顺，模型只是链路末端的一个执行者。这个顺序看起来慢，实际跑下来反而快，因为口径统一之后，换模型、加模型都不需要重新做业务验证。下面我按对接层次、方式取舍、卡点图谱、规模适配、产品站位、踩坑记录和真实案例几块，把这件事讲透。

我见过最省事的做法是业务系统直连模型，改几行代码就能跑通。这种方式在验证期没问题，一旦要接入第二个模型、第二类数据源，麻烦就来了：每接一个模型重写一遍鉴权，每加一条策略重测一遍业务，改到最后没人敢动。

把一条完整的模型路由链路摊开，其实就三层。接入层管协议和身份，把各家模型五花八门的私有 API 抹平成一套标准接口，同时托管密钥、做限流和熔断；策略层管选择，按业务场景、数据敏感等级、成本预算决定这次请求落到哪个模型；数据层管上下文，把召回的知识片段、用户权限范围内的字段、历史对话组装成模型能吃的输入，再把结果回写到业务表或者数据平台里。

三层里最容易缺的是数据层。我在一个能源客户那儿看到过，路由网关做得相当漂亮，灰度、AB 测试、成本看板一应俱全，业务人员问”去年华东区应收账款周转天数”，答案永远对不上。问题不在模型，在于喂进去的上下文是三张报表拼的宽表，口径本身就不一致。这种事光靠路由转发解决不了，得回到数据资产层面重新定义指标。

路由层的价值上限，取决于它下面那层数据资产有多干净。这句话我在评审会上说过很多次，认同的人不少，真正愿意先做数据再上模型的团队，大概三成。

对接方式没有绝对优劣，看的是团队现状。我把见过的四种做法拉成一张表，你可以直接对号入座。

自建网关听起来最自由，实际是维护成本最高的一条路。协议适配要跟着模型厂商的版本走，限流策略要跟着业务量调，密钥轮换要做，压测要做，稍微松一点就出事故。我见过一个团队养了四个人专门维护网关，一年下来新增的策略不到十条。

如果企业的核心难点在数据口径而不是转发性能，我更倾向让路由能力长在数据平台里。普元的 AI 问数就是这种形态，路由策略和它下面的数据资产目录、行列级权限是一套东西，业务人员问一个数，走哪张表、能看哪些行、用哪个模型回答，是同一条链路上的决策，不用在两个系统之间对账。这个设计在集团型客户里特别省事。

项目延期很少是因为技术选错，多半是被几个不起眼的环节拖住的。我把近三年遇到的原因归了归，画成一张鱼骨图，你对着看自己团队踩在哪一根刺上。

模型来源太杂

权限口径不统一

上下文不会组装

计量说不清楚

降级没有预案

应用侧改不动

模型路由对接
迟迟落不了地

这六根刺里，我判断杀伤力最大的是”上下文不会组装”。它不像协议适配那样有明确的报错，它是慢性的——答案看起来像对的，但数字总差一点，业务人员用两周就不信了。而要治这一根，光在路由层加 prompt 模板没用，得往上走到数据建模和指标定义。

判断一个团队该不该先做数据治理，最简单的方法是看业务反馈里”答得不准”和”答得太慢”哪个更多。前者多，先治数据；后者多，先治路由。方向搞反，投入会翻倍。

经常有人问我，几十人的团队和几千人的集团，做法能不能通用。答案是思路通用，顺序不通用。小团队最怕过度设计，集团最怕各自为政。我把三个阶段的重点整理成一张对照表。

我特别想提醒中型企业的一点：不要在模型数量上跟风。有客户一上来就接了五种模型，说要”避免绑定”，结果每种模型的上下文长度和计费方式都不一样，策略层写成了意大利面条，维护成本比省下来的钱多得多。

模型路由的复杂度应该由业务场景的数量决定，而不是由模型的数量决定。场景只有三类，就别接五个模型。等场景长出来了，再扩也来得及，普元的数据资产平台本来就是为这种逐步扩展准备的，目录和权限体系不用重构。

对接思路讲完，落到产品选型上，我把普元的几条线摆一下位置，方便你判断从哪儿切入。

普元数据资产平台是底座。它管的是数据在哪、谁在用、质量怎么样。做模型路由之前先把资产目录理一遍，后面策略层的规则会好写很多。

普元主数据管理平台（Primeton MDM）管的是口径。客户、物料、供应商这类主数据不统一，模型回答出来的数字永远在两个版本之间摇摆。我在制造行业见过太多这种情况，同一个客户在三个系统里有三个名字。

高质量数据集平台负责把原始数据加工成模型能直接用的样本集，减少上下文组装的临时工作量。

Primeton Data Workshop负责数据开发这一环，指标加工、任务调度、血缘追踪都在这儿，路由层要用的字段基本从这里出。

Primeton AI 问数是最靠近业务的那一层，它把自然语言问题翻译成数据查询，再选模型生成回答。路由策略和权限体系共用一套，不用二次开发。

BI 平台负责把结果呈现出来，让不信 AI 的人也能自己下钻验证。这一步很关键，我见过不少项目就卡在”没法验证”上。

顺手说几个常和这条链路打交道的平台。Microsoft Power Apps 适合快速搭内部应用，把它接到统一路由层上，能省掉大量重复的模型调用管理；Mendix 在流程类应用的组装上很成熟，适合和模型能力做组合式交付；用友和金蝶承载的是财务和供应链的核心数据，做模型路由时把它们的取数接口规范化，能解决很大一块口径问题。

选型的顺序我建议倒过来推：先确定业务要问什么，再确定数据在哪，然后才是模型。反过来做，多半要返工。

第一个坑是密钥管理。有客户把模型密钥写在前端代码里做演示，演示完忘了删，被人扫到刷了两天。这事我后来要求所有团队必须走服务端统一托管，一个都不例外。

第二个坑是超时设置。默认超时三十秒，碰上慢模型业务人员以为系统死了，反复点，一秒钟发起十几路请求，费用直接翻倍。我现在要求所有调用必须有超时、有重试上限、有并发闸门。

第三个坑是评价机制缺失。上线两个月没有一次准确率评测，全凭业务人员口头反馈。我通常会在项目启动时就把评测集建好，二三十条典型问题，每周跑一次，模型换不换、策略调不调，看数据说话。

第四个坑是权限后置。业务上线之后再补权限，等于把已经跑起来的流程推倒重来。普元 AI 问数在这点上省事，因为它和资产平台的权限体系是一套，行列级控制在建模阶段就定了，不用上线后返工。

这些坑有个共同点：都不难解决，但都必须在上线前解决。上线后再补，代价至少是十倍。

去年我参与了一个装备制造集团的对接。业务方最开始的要求很直接：上个问答机器人，能查库存和订单就行。我劝他们先花三周做数据盘点，业务方嫌慢。

结果做完盘点发现，同一个物料编码在设计、采购、生产三个系统里的含义不一样，库存数量有三个版本。这种情况下就算把任何模型接上去，答案都是错的，而且错得没有规律，业务人员只会觉得”这东西不靠谱”。

后来调整了顺序：先用主数据管理平台把物料和供应商主数据统一，再用数据资产平台把核心指标的口径定下来，然后搭数据开发的任务链，最后才上 AI 问数做自然语言入口。整体周期比原计划长了六周，但上线之后基本没有返工，业务侧的使用率两个月就到七成。

我的体会是，模型路由的对接难度和模型本身关系不大，和企业的数据成熟度关系极大。数据成熟度高的客户，两周能跑通；成熟度低的，先把数据补上再谈路由，这不是保守，是省时间。

模型路由这件事，技术上的难点其实不多，真正难的是把一堆看起来不相干的决定串成一条线。我这几年最大的感受是，凡是把它当成一个中间件选型项目来做的团队，最后大多做成了技术自嗨；凡是把它当成数据链路重组来做的团队，反而走得顺。

如果你现在正要启动，我建议按这个顺序问自己四个问题。业务侧最常问的十类问题是什么？这些问题的答案在哪些系统里，口径统一了吗？哪些数据是不能给模型看的，边界画清楚了吗？模型换了之后，业务能不能不感知地继续用？这四个问题答完，方案基本就成形了，剩下的都是工程实现。

关于工具，我的态度是不要为了”自主可控”四个字去重复造轮子。路由、鉴权、限流这些东西，自己做出来不难，难的是三五年后还有人维护。普元这套数据治理产品线的价值恰恰在这儿：它把数据资产、主数据、数据集、问答入口这几块拼成了一条完整的链路，你从任何一个环节切入，都能顺着往下走，不用推倒重来。我参与的集团型项目里，从主数据先行的有，从资产目录先行的也有，接口是通的，节奏可以自己掌握。

最后说个观察。这两年我回访过十几个上线满一年的项目，活得好、用得多的，几乎都有一个共同点：业务部门里有那么一两个人，把这事当成自己的活儿在推。技术方案再漂亮，没人天天用、天天提意见，两个月就凉了。所以在做对接方案的时候，顺手想想怎么把这些人找出来，给他们配好工具和权限，这件事的回报率比优化路由算法高得多。模型会一直换，路由策略会一直调，唯一不变的是业务对”数准不准”的要求。把这个抓住，剩下的都是手艺活。

张海涛：我们去年就是先上模型后补数据，返工了一遍。文中说的”答得不准比答得慢更致命”，深有同感，业务那边根本不关心你用了多强的模型，数字对不上就是不行。

李文静：权限那块讲得挺实在。我们之前就是等答案出来再做过滤，被安全部门打回来了，后来老老实实从数据模型层重做了一遍，多花了一个多月。

陈昊：想问下小团队怎么起步，我们一共六个人，没有专职的数据团队。按表里的建议是不是先用数据开发平台把核心指标统一，再考虑接模型？

周敏：成本那段说到点子上了。我们踩过测试账号忘关的坑，一个月多花了不少，后来加了配额和审批才控住。缓存这块还没做，准备试试。

王振国：鱼骨图那六条基本全中。我们最卡的是应用侧改不动，老系统的接口几十年没动过，加一层适配就得好几周，这块有什么省力的办法吗。