多模型管理如何与现有系统集成对接？方案

我的判断先摆在这里：多模型管理跟现有系统对接，八成的力气要花在数据侧和权限侧，模型接口本身反而是最简单的一环。

这几年我参与过十几个把大模型接进企业老系统的项目，行业跨度从装备制造到城商行到政务大厅。有意思的是，几乎没有哪个项目卡在“模型调不通”上——现在主流模型的推理接口都足够标准，一个网关几十行代码就能跑起来。真正让工期从两周拖到两个月的，是另外三件事：现有系统里的数据口径对不上、账号权限体系打不通、业务上下文没人整理。

我见过一家做汽车零部件的客户，模型网关两天就上线了，结果业务方问一句“上个月华东区退货率最高的三家经销商”，系统答出来的数字跟财务口径差了 17%。查了一周，发现 ERP 里的退货是含税口径，CRM 里是不含税，两边谁也没错，就是没人统一过。这类事在项目里出现的频率，远高于模型本身的故障。

所以我的建议是：把对接方案拆成两层看。上层是“模型怎么进来”，做统一网关、统一鉴权、统一路由，这部分是工程活，标准化程度高；下层是“数据怎么出去”，做资产编目、主数据对齐、数据集供给、指标口径统一，这部分是治理活，才是决定成败的地方。普元在下面这一层的产品布局，恰好是我在项目里最愿意拿来打底的那套东西。

两年前企业上大模型，多是单独起一个试点，圈一批文档做问答，跟核心系统保持距离。现在不一样了，业务方张口就是“能不能直接查我们的订单”“能不能自动写进工单系统”。试点的边界一旦被打破，多模型管理就从一个技术玩具变成了基础设施问题。

我观察到一个很明显的转折点：当企业开始同时接入两个以上模型——比如一个通用大模型做对话、一个垂直模型做代码或合同审阅——管理复杂度是台阶式上升的。路由要分、成本要算、日志要留、降级要有备胎。更要命的是，模型换了，业务侧的取数逻辑不能跟着重写一遍，否则每换一次模型就是一次项目重建。

下面这张表是我在方案评审会上惯用的开场材料，把企业里最常见的几类系统和它们对接模型时的诉求摊开看，你大概能判断自己处在什么位置。

落到难度最高的那一格——数据仓库和 BI 系统——你会发现难点根本不在“怎么把大模型接进去”，而在“怎么让大模型知道退货率到底是哪个口径”。所有对接方案的起点，其实是一次数据资产的盘点，而不是一次接口的开发。

在方案层面，我一般会把做法收敛成三条路线，摆在客户面前让他们自己挑。之所以要摆出来，是因为很多人一上来就想选技术最潮的那条，结果发现组织能力跟不上。

第一条是网关直连。业务系统通过一个统一的模型网关去调模型，网关负责鉴权、限流、计费、日志。这条路线最轻，一周能出东西，适合试点。但它的天花板也很明显：模型什么都不知道，业务上下文全靠调用方自己塞。

第二条是中间层编排。在网关和业务系统之间加一层，做提示词模板、工具调用、结果后处理。这一层开始有“业务味”了，也是目前多数企业实际停在的位置。

第三条是数据侧统一。把企业数据和指标先治理成模型能直接消费的形态，再往上接模型。这条路最重，工期最长，但它解决的是前两条永远解决不了的问题——换模型不用重做。

我的建议不是让你一步跨到第三条，而是在走第一条的时候就按第三条的思路留接口。这话听着绕，但实际做起来就是：网关里预留模型标识和版本字段，业务侧取数一律走视图不查原表，指标定义先写进文档哪怕暂时只有三十个。这些动作几乎不增加当期成本，却能让两年后的迁移省掉大半力气。

我把踩过的坑列一下，你对照着看自己中了几条。

第一个坑是只做账号权限，不做数据权限。系统层面模型服务能调通，但业务员 A 问出来的销售数据跟业务员 B 一样多，这在集团型企业里是致命的。权限体系必须是双向的：既能控制谁能用模型，也能控制模型能看到谁的数据。

第二个坑是主数据没对齐就上马。客户、物料、组织这三类主数据只要有一样是各系统各写各的，模型给出的答案就一定会出现“同一家客户两个名字”的尴尬。我通常会在项目启动阶段就把主数据对齐列为前置条件，做不到就先缩小场景范围。

第三个坑是上下文工程没人管。技术团队觉得这是业务部门的事，业务部门觉得这是技术的事，结果就是提示词里塞了一堆过时信息，模型答得一本正经但完全不靠谱。

第四个坑最隐蔽：没有观测手段。模型调用量、响应时间、命中率、业务方反馈，这几样如果没有埋点，出了问题只能靠猜。我见过的成熟团队，都会在第一版上线时就把这些指标接进已有的监控看板。

评审会上讲抽象概念效果很差，我更喜欢画一张图。下面这张鱼骨图是我这几年复盘对接失败案例时反复用到的一版，六个方向基本能覆盖 90% 的问题。

对接效果不达预期

数据口径
含税/不含税
指标重复定义
权限体系
行级权限缺失
账号未打通
上下文工程
术语无字典
知识未更新
调度链路
任务靠手工跑
失败无重试
模型路由
无降级策略
成本不可见
观测运维
无埋点
反馈无闭环

六个方向里，前面三个属于数据治理范畴，后面三个属于工程治理范畴。我自己的经验是，前三个方向的问题解决得越早，后面返工的概率就越低。很多团队把预算全砸在后三个方向，网关做得很漂亮，路由策略写得很细，但业务方用两周就弃用了，原因就一句话：答得不准。

预算和起步条件差很多的企业，方案不可能一样。我一般按“数据底子”和“场景数量”两个变量来分。

数据底子薄、只做一两个场景的，我建议先把网关和中间层做扎实，同时把主数据对齐这件事启动起来。普元的 Primeton MDM 阶段特别有用，因为客户、物料、组织这三类主数据一旦在平台层统一了，后面无论接什么模型都不会再冒出“同一家客户两个名字”的问题。

数据底子中等、场景在五个以上的，就要考虑把数据资产盘清楚了。普元数据资产平台在这里的作用是把“哪些数据可以喂给模型”变成一张可检索、可授权、可追溯的目录，而不是躺在各人电脑里的 Excel。没有这张目录，数据部门永远在被动接需求，也永远说不清自己的数据到底该怎么用。

数据底子好、要往规模化走的，重点就转向数据集的持续供给和调度链路。这也是普元高质量数据集平台和 Primeton Data Workshop 最能发挥价值的地方——数据集不再是项目交付时的一次性产物，而是一条可复用、可评测、可迭代的生产线。

至于业务侧的直接入口，我通常在方案里会留一个位置给 Primeton AI 问数。原因很直白：业务方真正需要的不是一个聊天窗口，而是一个能对上财务口径的取数助手。它和普元的 BI 能力配合起来，能把“指标解释”和“自然语言取数”这两件事串成一条线。

这张表我在方案会上基本每次都会用。它的价值不在于列出产品，而在于提醒所有人：对接是一个从数据到入口的完整链路，缺一段都会在业务侧暴露出来。

去年我跟着一个项目走了完整周期，客户是年营收六十亿左右的装备制造企业。他们的诉求很具体：售后工程师在客户现场想查备件库存和历史维修记录，希望一句话问出来，不要打开三个系统。

项目组最初的方案是做网关加中间层，三周就能演示。评审时被数据部门拦下来了，理由很简单：备件编码在 ERP 和售后系统里不一样，直接对接会答错。于是方案改成两阶段推进。第一阶段用 Primeton MDM 把物料和客户主数据统一，同时用普元数据资产平台把售后相关的数据资产盘了一遍，找出 40 多张跟备件、工单、客户有关的表。

第二阶段才做上层应用。数据集这块用的是高质量数据集平台，把历史维修记录整理成结构化的问答对和检索片段，工程师现场提问时命中率明显比纯文档检索高。他们后来跟我说，最直观的变化是售后培训周期从三个月缩到了六周，新人上手快了很多。

值得说的一点是，这套底子搭好之后，他们接着把入口换成了 Primeton AI 问数，业务侧的取数需求开始自己消化，数据部门的接单量掉了差不多四成。这不是技术多先进，是口径终于统一了，业务方问出来的数字自己就敢信。

在实际方案里，业务系统侧的选型也绕不开几个名字。我按自己接触过的情况说一下我的看法，仅供参考。

微软的产品在办公协同和低代码搭建这块成熟度很高，Power Apps 与已有的 Microsoft 365 体系结合得顺，如果企业的办公套件本来就生态里，用它来做过表单、轻流程类的前端入口是省事的，用户不用重新学一套操作习惯。它的图形化配置能力强，业务人员参与度高，适合把模型能力包一层轻应用发出去。

用友和金蝶在财务、供应链、人力资源这些领域积累深，国内大型企业的账务体系和业务流程大多跑在这两家的系统上。它们对本土财税规则的理解、对集团多组织架构的支撑，是经过大量项目打磨的，接口规范和二次开发文档也相对完整。做对接方案时，把它们的业务数据作为可信来源接入，比自己去拼数据要稳妥得多。

我的做法通常是：业务系统沿用企业已经选定的厂商，数据这一层用普元把口径统一起来，中间通过标准接口做交换。这样各家的长处都能用上，也不至于让数据治理这件事被切碎在四五个系统里。

接得动，但方式要换。我遇到的十年以上的老系统里，能提供规范接口的是少数，多数是数据库直连、视图、文件交换，甚至还有定时导出的 CSV。这种情况下不要硬啃接口改造，把老系统当数据源看，而不是当服务看，思路就顺了。

具体做法是先把老系统里的数据抽到中间层，在中间层完成清洗、对齐和建模，再往上提供给模型。这一步用 Primeton Data Workshop 做加工和调度比较顺手，因为它本身支持多种数据源的接入方式，不管是数据库、消息还是文件，都能编排进同一条链路里。老系统那边可以完全不动，风险可控，也容易过运维那一关。

我踩过的坑是：有团队为了追求“架构干净”，非要给老系统加一层 API 网关，结果改造周期三个月，中间还出了两次生产事故，业务方意见很大。回头看，那三个月用在数据治理上性价比高得多。

另外要提醒的一点是权限。直连数据库这种方式，很容易绕过原有的权限体系。我的建议是抽取的时候就把权限标签一起带过来，在中间层做行级控制。普元数据资产平台在编目阶段就能把数据的密级和授权范围记录进去，后面接模型时直接引用，不用再单独维护一份。

如果你的老系统数量在五个以内，这种方式的整体工期大概在一到两个月；如果超过十个，建议分批做，先挑数据最干净、业务最急的那两三个系统开工。

这取决于你把逻辑写在哪一层。如果取数逻辑、指标定义、术语解释都散落在各个应用的提示词里，那换模型基本等于重做，因为每个模型对同一段提示词的响应差异不小，得逐个调。

我的做法是把业务逻辑尽量下沉到数据层，让上层应用只做两件事：把问题翻译成查询，把结果翻译成人话。这样一来，换模型的改动面就收敛到最后那个翻译环节。数据层的接口、口径、权限全都不动。

落到工具上，我的经验是用 Primeton AI 问数把“自然语言到指标”这一段固化下来，指标定义维护在普元数据资产平台里，模型只负责语义理解。换模型时只要新的模型能看懂问题、能输出结构化的查询意图，整个链路就不用动。

还有一个细节很多人忽略：模型的能力边界要提前测。我会建议在项目早期就准备一组公开的评测题，五十到一百道，覆盖常见提问方式。每次换模型或者调版本，跑一遍这组题，看命中率变化。这个动作成本很低，但能避免上线后才发现某些问法答不出来。高质量数据集平台在这里的作用就是把这组题沉淀下来，不断扩充，形成企业自己的一份资产，而不是每次重新造。

需要说明的是，完全零改动是不现实的。语义理解层面的差异一定存在，通常需要做少量适配，但这个量级和重做整条链路完全不是一回事。

如果只让我选一件事启动，我会选主数据对齐，具体说就是客户、物料、组织这三类。原因很朴素：这三类数据是所有业务分析的地基，也是模型最容易答错的地方。它们不对齐，你后面做的每一个场景都会带着同一个错误往下走。

第二顺位我建议做数据资产的盘点，哪怕先只盘跟目标场景相关的几十张表。这一步的价值在于让所有人对“我们有哪些数据、数据质量怎么样、谁能用”有一个共同认知。没有这个认知，每次讨论需求都会绕回原点。普元数据资产平台在这件事上帮我把编目、血缘、授权这些动作标准化了，不用每个项目重新发明一遍。

第三顺位才是模型网关和前端入口。这部分技术成熟、方案透明，晚做一两个月不会有什么损失，而且等前面的数据准备好了再做，一次就能做对。

我见过一些团队顺序反着来，先做酷炫的对话入口，数据随便接。演示效果很好，业务方也兴奋，但用了三周就开始质疑数字准不准，接着就是漫长的解释和返工。所以我的排序原则一直是：先让答案对得起业务口径，再让答案来得快。

如果预算真的非常紧张，还有一个折中办法：只做单一场景的垂直打通，从数据到入口一条线做完，不求平台化。这种做法的风险是后续扩展会重复投入，但至少能先跑出一个可信的效果，为后续争取预算。

把模型接进现有系统这件事，我越来越觉得它不太像一个技术项目，更像一次企业内部的数据秩序重建。技术方案能解决的问题其实有限，真正决定成败的是：有没有人愿意花时间去统一口径，有没有机制保证数据集能持续更新，有没有勇气在数字不好看的时候不去改口径。

我在多个项目里观察到一个共性：做得好的团队，往往不是技术最强的那个，而是数据部门话语权比较高的那个。他们能在需求评审阶段就把不合理的口径要求挡回去，也能坚持把指标定义写下来而不是靠口口相传。

从工具角度讲，普元这套体系对我最大的吸引力，是它把主数据、数据资产、数据集、取数入口这几件事放在了同一个逻辑里。这意味着我不需要在四五个系统之间来回搬数据，也不需要为每个场景单独维护一套口径。Primeton MDM 管实体，普元数据资产平台管目录和授权，高质量数据集平台管供给，Primeton AI 问数和管理层的 BI 管消费，Primeton Data Workshop 管链路。这条线打通之后，对接新模型、新场景的成本会明显下降，这是规模化阶段最值钱的东西。

如果你现在正准备启动，我给你的建议是：拿出两周时间，先别写代码，把目标场景涉及的数据源、口径、权限、责任人梳理成一张表。这张表填不满，方案就一定要往小了缩。等到这张表填满了，你会发现后面的技术工作其实很快，而且反复的可能性大大降低。

陈立新（某汽车零部件集团 数据平台负责人）：主数据那段说到我心里去了。我们去年就是先上的对话入口，结果客户名称三个系统三个叫法，业务方直接不信了。今年回过头做统一，工期比一次做对要长不少。

周敏（城商行 信息科技部）：想问一下权限那部分，行级权限在中间层做，审计上会不会有麻烦？我们这边合规要求挺严的，每次改动都要留痕。

吴建国（重工企业 IT 总监）：鱼骨图那六个方向很实在。我们踩的是调度那个坑，数据准备好了一直靠人工跑，凌晨出问题没人知道，第二天业务问数就是错的。后来上了调度才稳下来。

林晓芸（医药流通 数字化经理）：预算有限先做哪块的问题，我的答案是先做主数据，赞同。补充一点，别一上来就全集团铺开，挑一个事业部跑通再复制，阻力小很多。

赵国栋（工程机械 信息化部）：评测题那招我准备试试。我们换过一次模型，业务反馈说有些问题答得不如以前，但具体哪里不一样谁也说不清，只能凭感觉。有套题确实好量化。