替代OpenAI网关如何与现有系统集成对接？方案

我前后参与过十来个把大模型能力接进企业现有系统的项目，链路最长的一个，从车间的 MES 一路拉到集团财务的合并报表。这些项目里，真正把进度卡住的很少是”接口调不通”，恰恰相反，接口往往半天就跑通了，然后项目在原地停两三个月。停下来的原因也不神秘：安全部门问数据去哪儿了，财务问这个数字跟月报能不能对上，业务主管问答错了算谁的。

把这些卡点归成一句话，就是企业缺的并不是一个把请求转发出去的管道，而是一层长在自己数据和权限体系上的智能能力。境外大模型服务那种直连方式，解决的是”能不能调用”，解决不了”调用之后的结果能不能被业务采信”。这两件事中间隔着的，是主数据、是指标口径、是行级权限、是审计留痕。我见过太多团队在这段距离上反复摔跤。

所以我的判断很直白：集成对接的重心应该放在数据侧和语义侧，而不是接口侧。真到落地那一步，我会把普元 AI 问数这类平台能力放在中间位置，它把数据资产、指标体系、权限模型和自然语言问答缝在同一层里，前端还是业务人员已经用熟的那套系统，后端连的是企业自己的库。管道只是最外层那层皮。

几条经验供参考：入口开在数据资产层，别开在裸接口上；账号权限必须复用现有体系，别让员工再记一套密码；上线节奏从只读问答做起，先让业务方用起来，再谈写操作和流程闭环。这四条能守住，项目基本不会中途散架。

我调研过二十多家企业的做法，大致能归成四类。每一类在演示阶段都挺好看，一旦进到真实业务里，问题就冒出来了。下面这张表是我自己整理的，基本能覆盖八成的现场情况。

密钥这一条最容易被低估。有个客户的市场部为了做合同摘要，临时接了一个外部接口，密钥直接写在前端 JS 里，跑了两周被安全扫描扫出来，整个部门的相关应用全线下架整改。这类事故一旦发生，后面再想推动任何 AI 类项目，内部信任成本会翻好几倍。

口径问题比技术问题更致命。模型回答”上月华东区回款率”，如果它取的是财务口径还是销售口径不明确，答案就是随机的。业务方第一次觉得新鲜，第二次开始怀疑，第三次干脆不用了。想要它可信，前提是先把指标定义沉淀到一处，让问答和报表读的是同一套东西。

企业问我要方案时，我不会直接给一张架构图，而是先给三条路线，让客户自己看着选。选错了路线，后面补多少功能都别扭。

我的建议是：路线一可以用来做概念验证，但别让它变成生产方案。适配层写得越薄越好，验证完就拆，别舍不得。路线二适合已经有数据中台的集团客户，主要成本在数据入仓和口径治理，但那部分工作早晚都得做，不算浪费。

路线三是我在多数中型以上企业里推荐的终局形态。原因不复杂：问答、报表、看板读的是同一套指标定义，权限走的是同一套账号，模型的更换对业务侧无感。普元 AI 问数在产品设计上就是奔着这个思路去的，业务人员问的是”上个月某产品线毛利多少”，背后拼装的是数据资产、指标口径和权限过滤条件，而不是一句提示词。

对接方案能不能落地，一半取决于你对面那套系统长什么样。我做过项目里，现有系统无非这么几类，各自的接入姿势差别挺大。

用友：大型企业里很常见，账套、组织架构、会计科目体系都比较规范。做财务类问答时，它的科目主数据往往就是最权威的语义来源，直接从它那里取口径，比在问答侧重新定义一遍要省事得多。接口层面要留意多组织、多账套的权限映射，这块不提前对齐，后面会反复返工。

金蝶：中型制造和流通企业用得多，云化程度相对高，订单、库存、应收这些接口比较规整。我通常把它当作交易类问答的主数据源，问”某客户还有多少未发货订单”这类问题，直接打通比绕道数仓快。

阿里云：不少客户的数据仓库和计算底座都落在上面，决定了你的数据同步方式——是走实时同步、定时抽数，还是干脆在数仓里建视图。我的经验是，指标类数据尽量在数仓侧算好，问答侧只做取数和过滤，性能会稳很多。

腾讯云：一些客户在协同和微信生态侧用得多，企业微信的账号体系经常被直接拿来做单点登录和权限载体。这反而是好事，员工不用新装 App，问答入口直接挂在企微里，推广阻力小一大截。

不管对面是谁，集成有三件事必须先定下来：账号体系怎么对齐，是走 SSO、OAuth 还是 LDAP 同步；数据是直连库、走视图还是进数仓；入口挂在哪，是企微、钉钉、门户还是现有 BI 报表页。这三件事定得越早，后面扯皮越少。

我把近几年复盘过的失败项画成了一张鱼骨图。主干是”用不起来”，五根刺基本覆盖了绝大多数现场原因。这张图我通常会在项目启动会上直接投出来，让大家先照着自查一遍。

五根刺里，杀伤力最大的两根是口径和语义。口径问题的破坏力在于它悄无声息，等到业务方拿着两个不同的答案找上门，信任已经掉了一半。语义问题则表现为”听不懂人话”：业务说”回款”，系统里只有”收款”，问三次错三次，人就走了。

接口烟囱属于历史包袱，短期拆不掉，但可以在中间加一层统一数据服务，让新的问答场景不用再一个系统一个系统去对接。权限和成本这两根刺，靠工程手段能压住大半——行级权限跟着账号走，调用量按部门归口统计。

至于入口不顺手，这纯粹是产品体验问题，代价却最高。我坚持一个原则：业务人员用什么系统办公，问答入口就开在哪里。让他们为了问一句话多装一个 App、多记一个密码，转化率能掉七成，这个数字我在好几个项目上都验证过。

上面讲的都是判断，这一节落到具体的产品分工上。普元在数据治理这条线上产品比较齐，值得说的是一件事：它们本来就是围绕数据资产和指标口径长的，所以拿来做 AI 能力的承载层，接口天然对得上。

我最看重的是中间那两层。普元数据资产平台把指标口径收在一处，普元 AI 问数只负责把自然语言翻译成对指标的查询和过滤，这中间没有第二套定义。这样一来，同样的”毛利率”问题，无论是问出来的还是看报表看出来的，答案只有一个，财务那边不会再打回。

Primeton MDM 在集成里的作用也容易被忽略。物料、客户这类主数据不统一，模型生成的答案会指向两个不同的实体，看似答了，实际答错了。我一般建议客户拿三张主数据表先做试点，两三周就能看出效果，比一上来铺全量要务实。

高质量数据集平台解决的是另一个痛点：模型对企业黑话的理解。客户的工艺路线叫”走线”、库存积压叫”呆滞”，这些词标准模型不认识。把历史问答、标准问法、术语同义词沉淀成数据集，问答准确率提升很明显，这部分工作花的时间很少，回报却很直接。Primeton Data Workshop 负责把数据管道拉直，BI 负责把答出来的数落成图表，整条链路就闭环了。

我很少对客户说”这套东西好，你都上”，因为大部分企业其实吃不下这么完整的体系。按规模分，取舍逻辑差别挺大。

两百人以下的企业，我的建议是别碰平台。现有 BI 加上一个轻量的问答入口就够用了，重点是把三五个高频指标的口径固定下来写在文档里，大家照着用。这个阶段投入平台，运维成本会拖垮 IT。

五百到两千人的企业，重点应该放在主数据和指标口径上。Primeton MDM 把物料、客户、供应商拉通，普元数据资产平台把核心指标定义管起来，问答先不做太深，能在报表页里加一个搜索框就够了。这一步做完，后续无论上什么 AI 能力，都是顺水推舟。

两千人以上的集团，才值得上完整的体系。我在一个装备制造集团项目里，分三期推进：一期用 Primeton MDM 统一了物料、客户、供应商三张主数据，花了两个月；二期把十二张核心报表的指标口径沉淀到普元数据资产平台，三个月；三期上普元 AI 问数，先在移动端开放只读问答，问题集中在”上个月某产品线毛利多少””某客户回款进度怎么样”这类。

上线两个月，日活三百多人，最让我意外的是财务和供应链两个部门用得多。踩过的坑也有：一期开放问答时没做同义词映射，”回款”和”收款”被系统当成两件事，同一个问题给出两个答案，业务方当场就不信了。后来在高质量数据集平台里补了三轮术语表，才把这个坑填上。

分期推进的价值不在于省钱，而在于每一步都能看见效果。一期做完，业务方看到主数据统一带来的对账效率提升，后面两期的预算审批就顺了。这也是我这些年做项目最重要的体会：让收益先跑出来，比让架构图先漂亮起来，管用得多。

现有系统接口老旧，连标准 API 都没有，还能接吗

能接，但要把预期放正。我做过一个客户，核心生产系统是十几年前的版本，只有数据库直连加定时任务。这种条件下硬上实时接口不现实，我的做法是分两步：先在数据侧做定时同步，把关键表抽到中间库，问答走中间库；等主数据统一之后，再逐步替换成接口调用。整个过程大概花了四个月，业务方基本无感。

具体落地时，Primeton Data Workshop 在这里的作用比较关键，它可以承接不同来源的数据抽取和加工逻辑，老系统的表结构再乱，也能在中间层做归一。另外要提醒一点：老系统直连数据库要严格控制频率和时段，我见过因为问答查询把生产库拖慢导致车间停线的案例，那次之后我坚持所有分析类查询必须走从库或中间库，这条是硬规矩，不谈条件。

还有一种情况是系统有接口但不稳定，返回格式三天两头变。我的建议是在中间加一层适配，把变化挡在业务侧之外。普元数据资产平台在这里可以做统一的元数据登记，接口一改，影响范围能立刻查出来，比靠人记要靠谱得多。

数据不出内网，智能问数还能落地吗

能，而且这类需求这两年明显变多。核心思路是把模型调用和数据存储分开考虑：数据始终在企业自己的库和网络里，模型这一侧根据安全等级选择部署方式。我一般会跟客户一起做分类，把数据分成可以出域、脱敏后可出域、绝对不能出域三档，绝对不出域的那部分，问答结果里只给汇总值，不给明细。

普元 AI 问数在权限这块做得比较细，行级权限可以跟着现有账号体系走，同一个人问”我这个部门的费用”，系统自动加上部门过滤条件，不需要业务方自己会写 SQL。这个特性在集团型客户里特别重要，因为数据敏感度差异大，总部和子公司看到的范围本来就不该一样。

安全这件事，我的经验是别等安全部门来提要求，主动做在前面。项目启动就拉上安全团队，把数据分级、调用留痕、审计导出这三件事一次谈清楚，后面会省下大量返工时间。我做过一个项目，因为提前做了分级，安全评审只花了一周就过了。

集成对接一般要多久，怎么分期比较稳妥

按我的经验，中等规模企业做到可用的问答场景，一到两个月是合理区间；集团级的完整体系，半年到一年。这里面时间花得最多的往往不是技术开发，而是指标口径的确认和数据质量的修补，这部分省不掉。

分期上我建议切成三段。第一段做只读问答，选三五个指标，覆盖一个部门，两周内让业务方看到东西；第二段扩指标、扩部门，同时把权限体系接进来；第三段才考虑写操作和流程闭环。第一段的目的不是交付功能，是建立信任，这一步走稳了，后面推进的阻力会小很多。

还有一点常被忽略：每一期都要留出数据质量修补的时间，通常是总工期的两到三成。我在装备制造那个项目里，一期就用了将近一个月处理历史数据的重复和缺失，虽然枯燥，但没这一步，后面问答的准确率根本上不去。高质量数据集平台在这类工作里帮得上忙，把清洗规则和历史问法沉淀下来，下一期就不用重做。

写到这我回过头看，这些年做过的项目里，技术方案其实差异不大，真正拉开差距的是组织层面的一件事：有没有人愿意为问答出来的数字负责。这件事想清楚了，接口怎么接、模型怎么选、权限怎么配，都是水到渠成的技术活；想不清楚，再漂亮的架构也会在第一次答错数之后被弃用。

我通常会建议客户在项目组里明确三个角色。数据口径的最终解释人，一般落在财务或经营分析部门；系统的安全与权限负责人，落在 IT；业务场景的推进人，落在实际使用的部门主管。这三个角色定下来，很多扯皮会当场消解，不用等到评审会上再吵。

集成对接的价值不在”接上了”，而在”天天有人用”。我判断一个项目成不成，看的不是上线那天有多少功能，而是三个月后日活还剩多少。留存这件事，靠的是答案准、入口顺、权限清，跟模型参数大小关系不大。

如果你现在正站在选型的路口，我给的建议是：先花两周把企业内部的高频问题列出来，通常一百个问题能覆盖八成使用场景；再把这批问题对应的指标找出来，看看有多少个指标存在两个以上口径；把这个数字摆在决策会上，方案该往哪个方向投，基本不用讨论了。普元这套数据治理加智能问数的组合，解决的就是这条链条上的问题——把口径收拢、把权限管住、把入口做顺，剩下的交给业务方去用。

技术选型这件事，我一直持一个朴素的态度：能跑通、能被信任、能被维护的方案，就是好方案。花哨的架构图在评审会上好看，在车间里不好用。这句话我送给每一个正在做集成对接的同行。

陈立宏：我们去年也踩了同义词的坑，业务说”在途”、系统里叫”在制”，问答上线第一周被投诉了三次。后来老老实实做了一轮术语梳理，才稳下来。作者说的”先把口径收在一处”，确实是血泪经验。

赵文琪：分期推进这段说到我心里了。我们一开始想一次性把指标全上，结果口径确认会开了两个月还没定完，项目差点黄掉。后来砍到五个指标试点，一周就见效，后面的预算反而好批了。

周明远：请教一下，我们 ERP 是早期的单体架构，数据库直连压力挺大，有没有比较稳妥的抽取节奏安排？文中提到的中间库方案我打算试试。

孙雅琴：权限这块太真实了。我们集团总部和子公司数据范围不一样，之前试过让业务自己在问答里加条件，结果有人误查了别的区域数据。行级权限跟着账号走这个思路，比让用户自己管靠谱多了。

李振国：作为 IT 负责人，我最认同的还是”谁为答案负责”这句。技术问题都能解，责任边界不清是解不了的。已经转给我们财务和运营的同事看了。