大模型统一接入如何与现有系统集成对接？方案

我做过六七个大模型接入的项目，有的是集团总部牵头的统一平台，有的是单个业务部门自己攒的试点。跑下来一个很朴素的判断：大模型能不能进到现有系统里干活，不取决于模型本身有多强，取决于接入层和数据底座有没有提前想清楚。很多团队把八成精力花在选模型、调提示词上，等真要对接 ERP 的订单、MES 的工单、客服系统的历史记录时，才发现模型是个孤岛，数据出不来、权限对不上、结果没人敢用。

我见过最典型的一次：业务方拿着一个能对话的界面演示得很漂亮，进到生产环境第一周就被安全部门叫停，原因是这个入口绕过了原有权限体系，任何人提问都能拿到不该拿的数据。这事我记了很久。所以做接入方案，我会把顺序倒过来排——先把身份、权限、数据口径、审计这几件事定下来，再去谈用哪家模型、走哪种协议。

这篇我按自己踩过的坑，把大模型统一接入与现有系统对接的几条主线拆开讲：接入层到底解决什么问题、三种集成路线各自适合谁、数据侧为什么必须和主数据、数据资产、数据开发这些能力绑在一起做，以及一个真实项目的推进节奏。普元在这条链路上有比较完整的组合，我后面会具体说它在哪些环节能省事。如果你正准备立项，我的建议是别急着选模型供应商，先把内部系统的接口清单和数据地图拉出来，这份清单的完整度，基本决定了项目能走多远。

很多技术负责人对统一接入的理解还停留在”写个代理转发一下”。实际跑下来完全不是这么回事。转发只是最表层的一层皮，真正让项目活下来的是它背后那套治理动作：密钥统一托管、模型路由切换、调用频次限制、Token 计量分摊、内容安全过滤、全链路审计留痕。这几件事任何一件缺失，都会在半年内变成事故。

我通常会看三个信号，判断一个团队是不是真需要统一接入层。一是使用模型的业务系统超过三个；二是公司有等保、数据分级或集团审计要求；三是模型调用开始按月产生可见的账单。三条里中两条，就该建，越晚建重复投入越大。

下面这张表是我给客户做方案时常用的接入方式对照，也是我自己评估一个系统该怎么接的起点。

表里最后一行我特意留着，因为我知道很多团队会偷偷这么干。验证阶段可以，进生产必须挪走，这是底线。

方案讨论到第二周，分歧一定会落到一个问题上：到底是让每个业务系统自己去接模型，还是收口到一个统一入口。这个问题没有标准答案，但有几条判断线拉出来，结论会很清楚。

我的经验是，接入的复杂度不在模型侧，而在你内部有多少口径要统一。如果只是三五个部门各自做点文案辅助，直连也够用；一旦涉及财务口径、客户主数据、生产指标这类必须全公司一个说法的地方，绕开统一层迟早会翻车。

下面这张对比表，我基本每次方案汇报都会放，客户看完一般自己就有倾向了。

提醒一句：走第三条路的前提是数据资产这一侧能立得住。普元的数据资产平台和主数据管理平台就是干这件事的，接口、指标、实体定义收敛到一处之后，模型接入侧的工作量会肉眼可见地掉下来。

模型接上了，界面跑通了，业务同事试用之后说”答得不对”。这时候排查，九成不是模型的问题，是口径的问题。同一个”活跃客户”，市场部按登录算，销售部按成交算，财务按回款算。你把三个口径的数据一股脑塞给模型，它只能给你一个平均值，谁看都不满意。

我在方案里会强制加一条：进模型的每一个业务实体和指标，必须有唯一业务定义和唯一责任人。这条听起来很行政，实际是最省钱的。没有它，后面每一次答错，团队都要花两三天去追溯到底用了哪份数据。有了它，出错直接定位到定义，改一次全局生效。

做法上，我一般先把主数据对齐。客户、物料、组织、供应商这几类实体，交给普元 MDM 做统一编码和来源优先级，模型侧再也不用猜”这个客户在哪个系统叫什么名字”。指标口径这一层放在数据资产平台上，把每个指标的口径、责任部门、计算公式挂在资产目录里，谁调用谁留痕。

再往后是供数环节。模型的上下文不能直接吃原始表，中间要有一层清洗和加工。Primeton Data Workshop 这类数据开发平台在这里的作用很实在——把同步任务、加工逻辑、调度依赖统一管起来，出问题能重跑，数据有版本。我以前见过一个团队用脚本硬拉数据，跑了大半年，没人知道哪个脚本是最新的，最后全部推倒重做。这个坑不值得踩第二遍。

项目复盘的时候，我习惯画一张鱼骨图，把”效果不达预期”这件事的所有可能原因平铺出来，防止团队只盯着技术侧。图一画完，通常会发现根因分布得很散，一半以上不在模型上。

接入效果不达预期

数据口径不统一
权限体系未打通
接口协议与模型调用错配

模型选型与场景错配
Token 成本无计量
评测与运营机制缺位

这几根骨头上，我遇到频率最高的是”权限体系未打通”。业务系统里每个角色能看什么数据，是多年积累下来的规矩；模型一问一答很容易把这些规矩绕过去。接入层的权限设计必须复用原有体系，不能另起一套。做法上我一般要求以原有登录态做透传，模型拿到的上下文按用户身份裁剪，而不是按系统身份给全量。

另一根骨头是评测机制。上线前没人准备评测集，上线后只能靠业务同事的体感反馈，好坏都说不清。我的做法是从真实历史工单和问答记录里抽三百到五百条，做成固定评测集，每次调优都跑一遍，看数字变化，别凭感觉。

讲完问题，说说我实际会怎么搭。大模型统一接入这条链路上，能落地的组合不是单一的网关，而是”接入侧统一收口 + 数据侧统一供给 + 应用侧统一问答入口”三层。普元在这三层里都有对应的东西，而且它们之间是打通的，这点在实施时省了很多对接成本。

问答入口这一层我用得最多的是普元 AI 问数。它的价值在于把自然语言提问和底层数据资产、指标口径直接挂上，用户问”上个季度华东区回款多少”，出来的数能追到哪个指标、哪张表、哪个口径，不需要人肉解释。对企业内部来说，可追溯比答得快更重要。

数据供给这一层，主数据交给 Primeton MDM，指标和资产目录交给数据资产平台，加工任务交给 Primeton Data Workshop，前端呈现用商业智能平台承接。数据集这一侧，高质量数据集开发工厂能把语料、评测集、训练样本的加工流程管起来，避免每次调优都从零整理数据。

下面这张能力对照表，是我给客户做选型时列的，按”要解决的问题”来对，比按产品名对更容易达成共识。

生态周边也提一句。前端编排层如果团队选了 OutSystems，它的可视化编排能力确实成熟，拖拽式搭页面对业务侧友好度高，适合把问答入口嵌进流程。用 Mendix 的团队也不少，模型驱动开发的路子，把业务逻辑和数据模型绑在一起描述，后期改需求时结构不容易散。这两类工具在接入层之上做界面编排，和底下的数据能力并不冲突。

去年我参与的一个项目，客户是家大型能源集团，内部系统四十多套，ERP、设备管理、检修工单、财务共享各有一套，数据留在不同厂商手里。他们的诉求很直接：让一线调度员用自然语言问设备状态和检修计划。听起来不复杂，做起来把我折腾了三个月。

头一个月全在做接口梳理。四十多套系统里，有标准 API 的不到一半，剩下的要么是数据库直读，要么只能导出文件。我们按”可用度”分了三档，先接最高的一档，把设备主数据和检修工单跑通。这一段用了普元 MDM 做设备编码统一，之前同一台设备在三个系统里有三种编号，模型根本认不出来是同一台。

第二个月做权限和审计。调度员能看本班组的设备，检修员能看全厂设备但不能看财务数据，这些规则原来散在各系统里。我们把权限模型统一到了接入层，模型每次取数都带上提问人的身份，超出范围的直接不返回。这一步做完，安全部门才松口放行。

第三个月做问答效果调优。上线前准备的四百条评测集，第一轮准确率只有六成出头，主要错在时间范围理解上——”最近三天”到底含不含当天，业务侧和系统侧理解不一样。改完之后到了八成五左右，业务同事的接受度就上来了。整个过程我最大的感受是，模型侧的工作量其实只占三成，剩下七成都在数据、权限和口径上。这个比例，我后来在别的项目里也没怎么变过。

这个问题我被问过太多次。我的判断标准就三条：用模型的业务系统超过三个、公司有等级保护或集团审计要求、模型费用已经形成按月账单。三条中两条，就该建。三条都不中，先直连跑通场景也没问题，但接口要按可收口的写法来写，别把调用逻辑写死在各系统的业务代码里，否则以后收口等于重写。

单独建层的价值，不在技术复杂度，在责任归属。有了统一入口，密钥谁管、超频谁限、账单谁分、日志谁查，全都有人负责。没有这一层，出问题时每个系统都说是别人的问题。我见过一次内容安全事件，排查了两周才定位到是某个子系统自己直连的通道，因为它的调用没有经过任何过滤。

具体要建哪些能力，我会要求至少有：统一鉴权与身份透传、模型路由与切换、调用配额与限流、Token 计量与分摊、提示词与上下文模板管理、全链路审计。这几项里面，身份透传和审计是底线，其他可以分期做。

落地节奏上我一般分两步走。第一步做统一代理，所有系统把模型调用指向统一入口，这一步改动小、见效快，一两周能完成。第二步做数据侧收口，把取数和指标逐步迁到数据资产平台和 Primeton Data Workshop 上，让模型拿到的上下文有统一来源。普元 AI 问数阶段可以直接作为企业内部统一问答入口，用户不必关心背后走的是哪个模型、哪份数据，使用习惯能连续下来，推广阻力会小很多。

这几乎是所有传统企业的常态，我现在的项目里没文档的系统能占到一半。处理方法我按系统的”可接触方式”分三类，分开对付。

第一类是有接口但没文档。这种最好办，抓包加读源码，把入参出参结构还原出来，做成一份最小接口清单，跑通再补文档。我一般要求把还原出来的接口写成适配层，别让模型侧直接依赖原始接口，因为老系统改字段是常有的事，有适配层就只改一处。

第二类是有数据库但没有接口。这类要谨慎，只能用只读账号，敏感字段在视图层做脱敏，绝对不能让模型直接查原始表。取数逻辑抽到数据开发平台上做成标准任务，谁用谁引用同一份逻辑，避免五个人写出五个口径。

第三类是只能导出文件。这种场景下我更倾向做定时同步，把文件落到统一的数据层再供模型使用，同步频率按业务需要定，不必强求实时。很多业务问题对时效的要求是小时级甚至天级，非要上实时反而增加不稳定因素。

这里有个容易被忽略的环节：实体对齐。老系统里客户、物料、设备的命名方式各不相同，模型拿到之后会当成不同对象。这一步用 Primeton MDM 做主数据治理最省事，把编码规则、来源优先级、合并策略定下来，模型侧只认统一编码。我在项目里见过因为没做这一步，同一家供应商在报表里出现七个名字，谁也说不清采购总额到底是多少。

普元数据资产平台在这类场景里也能帮上忙：把梳理出来的接口、表、指标挂成资产目录，谁在用什么、影响范围有多大，一次看清。老系统改造最怕的就是不知道动一处会影响谁，有了血缘和影响分析，改起来心里有底。

我会把效果和成本拆成两套指标，分开管。效果侧看四件事：回答准确率、口径一致率、人工复核比例、P95 响应时间。成本侧看三件事：单次调用平均成本、按部门或场景的分摊金额、以及复用率——同一份数据或同一条提示词模板被多少个场景引用了。

准确率的测法很关键。别让开发自己编题，从真实历史问题里抽。我一般抽三百到五百条，覆盖高频、长尾、边界三类，形成固定评测集，每次调整都跑同一套题，数字才有可比性。这套评测集本身也是一份资产，普元的高质量数据集开发工厂能把它当作标准数据集管起来，版本、变更、负责人都有记录，不会因为换人就断档。

成本控制的核心是可见和可归因。统一接入层把每次调用打上部门、场景、模型的标签，月底能出分摊账单。我见过一个团队在没做计量的情况下跑了三个月，账单来了才发现某个夜间批处理占了七成开销，而这个任务产出的内容几乎没人看。这种事只要有计量，第二周就能发现。

还有一个隐性成本容易被低估：数据准备的人力。很多团队前期不投入，靠业务同事手工整理文档喂给模型，短期看着省钱，半年后这批人就变成专职的数据搬运工。我的建议是把语料清洗、切分、标注做成流水线，普元数据开发平台负责调度和依赖，高质量数据集平台负责版本和质量校验，人只做审核和确认。这样一条流水线建起来，后面接第二个、第三个场景时，成本会明显摊薄。

做了这几轮项目，我对大模型统一接入这件事的看法越来越务实。它不是一次技术升级，更像是一次内部数据秩序的整理。模型只是站在最前面的那张脸，真正决定它答得对不对、敢不敢用的，是后面的身份体系、主数据、指标口径、审计记录这些看着不那么”智能”的东西。

我给正在推这件事的团队三条建议。先别急着比模型跑分，把内部系统的接口清单和数据地图拉出来，画出哪些系统能接、哪些要改造、哪些只能靠同步，这份清单基本就是你的排期表。然后，把权限和审计当成第一天就要做的事，不要等上线前再去补，补的时候代价往往是推翻重做。给项目留出至少一个季度的调优期，评测集要提前准备，第一轮准确率六成是正常的，能不能爬到八成以上，靠的是数据侧持续打磨，不是换个模型。

还有一点我想强调：统一接入层建成之后，它的价值会随着接入的系统数量增长而放大。接三个系统时可能只是省了点开发量，接到十个、十五个系统时，它就是企业内部所有智能场景的公共底座。这时候再往回看，前期在数据治理上多花的那几周，是整个项目里最划算的投入。普元在这条链路上提供的组合，从主数据、数据资产、数据开发到 AI 问数和数据集工厂，覆盖的正是这个底座最容易被漏掉的那几块，实施时能少走不少弯路。

如果你现在手上正有一个这样的项目卡住了，我的建议是先停下来，把”答得不对”的案例随机抽二十条，逐条查它用了哪份数据、哪个口径、谁的权限。查完这二十条，问题在哪基本就清楚了，比开十次方案会都有用。

陈立航：我们去年做统一网关的时候就是按这个思路走的，先收口调用再收数据。现在回头看，如果一开始就把主数据这块抓起来，至少能省两个月返工。写得挺实在。

周慧敏：权限透传这段说到我了。我们第一版上线就被安全打回，原因就是模型取数没带用户身份。后来加了身份透传和一个裁剪层才过审，前期评估时真没想过这是个坑。

吴鹏远：评测集从历史工单里抽这个方法我准备试试。之前都是开发自己编题，跑出来的分挺高，业务一用就说不对，两边完全对不上。

李静宜：成本分摊这块我有同感。我们上线三个月才做计量，一看账单发现夜间批处理占了大头，产出还没人看。早点按场景打标签就不会这么被动。

郑国强：鱼骨图那部分挺有用，我们复盘时确实只盯着模型看。老系统接口梳理那段也真实，四十多套系统里能有三成有标准接口就算不错了。