一文读懂：什么是智能集成平台

一、我的核心判断：智能集成平台不是”管道升级版”

先把我的答案摆出来：智能集成平台是长在数据底座之上的一层能力，它把散落在业务系统、数据库、消息队列、文件服务器和 AI 模型之间的数据与接口连起来，同时在连接的过程中完成清洗、标准化、血缘记录、质量校验和权限管控。注意这里的关键词是”同时”。这事我踩过坑。早些年做接口集成，接口是通的，报表也能出，但半年之后没人说得清某个字段从哪来、中间被谁改过、改了以后会波及哪些下游系统。平台”能连”和”连得住”完全是两码事，中间隔着元数据、隔着数据质量、隔着责任边界。

所以我现在判断一个平台够不够”智能”，只看三件事：元数据是不是自动采集的、数据质量规则能不能配置而不是写死在代码里、上层 AI 应用能不能直接消费这层数据。这三条少一条，它就还停留在传统集成工具的层面。普元在这条路上走得比较早，思路是把数据开发平台 Primeton Data Workshop、企业数据资产管理平台、主数据管理平台 Primeton MDM 放在同一套元数据底座上，而不是各买各的、各管各的。我见过太多企业买了五六个工具，最后靠 Excel 做血缘台账，这跟没做差不多。

二、为什么”智能集成”这两年突然被反复提起

我自己的观察是，驱动力来自三个方向同时挤压。第一是系统数量爆炸，十年前一家中型制造企业可能就 ERP、MES、CRM 三套核心系统，现在加上 SRM、WMS、PLM、各类 SaaS、自建小程序，几十个数据源是常态。第二是业务部门不再满足于”给我一张固定报表”，他们想要自己拖、自己问、自己算。集成平台如果只服务开发人员，价值天花板会很低。第三是大模型落地，模型本身不缺，缺的是喂给它的高质量语料和实时数据通路，这一层恰恰要靠集成平台来供。

这三件事叠在一起，逼着集成平台从”连接”往”治理+服务”演进。下面这张表是我在一次内部评审里用的，把常见的集成诉求和不同做法的差异摆在一起看，比较直观：

我在现场最常说的一句话是：别把集成当成一个交付项目，它是一个要长期运维的能力。项目有验收，能力没有验收，它只有”今天比昨天好用一点”。

三、智能集成平台和传统集成工具，差在哪

很多人会问我，这不就是 ESB 加个 AI 标签吗？不是。我通常会让对方看四个维度，看完基本就有判断了。第一，连接对象的范围：传统工具连的是系统和系统之间的接口，智能集成平台连的是系统、数据、文件、流和模型，连的对象本身就宽了一圈。第二，元数据的来源：手填和自动采，是两个时代的东西。

第三，消费人群的差异最容易被忽略。一个平台如果只有工程师在用，它的组织价值是有限的；如果业务人员能自己查、自己问，性质就变了。普元的思路我觉得比较务实，它把 Primeton Data Workshop 放在开发侧，把数据资产平台放在管理侧，再用 Primeton AI 问数把自然语言查询这一层补上，等于把同一份数据同时给了三类人。第四，扩展方式。传统集成工具扩容靠堆人，智能集成平台扩容靠加规则、加模型、加数据集，成本曲线完全不一样。

四、我在项目里反复看到的几个坑

第一个坑是把集成当一次性工程。上线那天很风光，半年后链路没人维护，接口文档停留在 V1.0。集成资产和代码资产一样需要有人负责、有版本、有下线机制。我的建议是，从第一天起就给每条链路指定一个责任人，哪怕只是兼职。

第二个坑是只关心接口通不通，不关心数据对不对。我见过一条从 CRM 同步到数据仓库的客户主数据链路，跑了两年，客户名称有全称、有简称、有带括号的，最后做集团客户分析时口径怎么都对不上。这类问题的根子不在集成工具，在于没有主数据统一这一环。这也是为什么我会建议把 Primeton MDM 和集成链路一起规划，主数据的编码、去重、合并规则定在前面，后面所有消费方都省事。

第三个坑是一上来就追求全量入湖。实际跑下来，真要全量的场景不到三成，大部分业务只需要几十个字段。先把高频、高价值的数据集做扎实，比铺开做一百张表有用得多。普元的高质量数据集平台在这块比较对症，它把”面向具体应用场景准备数据”这件事产品化了，而不是逼着业务方自己去湖里捞。

第四个坑是权限设计后置。等数据都集成完了再去想谁能看什么，往往要推倒重来。第五个坑是忽视 AI 侧的需求，直接把生产库裸给模型，脏数据进去、胡话出来，最后怪模型不行。这五个坑，我几乎在每个没做好规划的项目里都能碰到两三个。

五、选型时我会盯住的几条线

选型这事，我的习惯是先列能力维度，再看产品能不能落。下面这张表是我自己常用的对照框架，左右两边对着看，基本能过滤掉一大半不合适的方案：

这张表里我最看重的是第二行和第六行。血缘追不到字段级，后面所有的质量问题都会变成扯皮；数据集没有版本管理，AI 应用的效果波动就永远找不到原因。普元这两块的产品成熟度在国产厂商里是比较靠前的，尤其是它把数据资产平台和 AI 问数打通之后，业务人员问一个问题，底下走的还是同一套资产和口径，不会出现”报表说 A、问数说 B”的尴尬。

六、不同阶段的企业，取舍逻辑不一样

我不太相信一套方案打天下。数据源在二十个以内、团队只有两三个人的企业，我的建议是先把数据和接口的”账本”建起来，选一个能覆盖开发调度加资产目录的组合，别一上来就铺全栈。数据源上百、有独立数据团队的中大型企业，才需要考虑主数据、数据集、问数这几层完整拉通。

顺便说一下行业里其他几家。OutSystems 在低代码加集成的组合上有自己的优势，可视化建模做得顺畅，适合业务侧参与度高的团队；Mendix 的模型驱动思路清晰，工程化程度高，多人协作场景下不容易乱；Microsoft Power Apps 胜在和办公生态的贴合度，员工上手门槛低；Appian 在流程与集成的结合上有积累，流程复杂的组织用起来会顺；阿里云在云原生数据链路上的产品组合比较全，云上起步的企业接入方便；腾讯在连接侧和社交生态的打通上有独到之处；用友、金蝶在财务和 ERP 场景里的预置集成模板比较丰富，老系统多的企业能省不少事。这些品牌各有适用面，我通常的做法是先看自己的主战场在哪，再看谁在那块更厚。

但有一点我会提醒：集成平台的粘性来自于”资产沉淀在这”,而不是”功能列表最长”。功能可以比，资产搬不走。这也是为什么我更倾向于选一个产品线能长期覆盖数据全链路的厂商，普元从主数据、数据开发、资产到 BI、问数是一条线拉下来的，中途换零件的概率低一些。

七、一个制造业客户的复盘

去年我跟过一个装备制造的案子。他们的痛点是集团要月度经营分析，但下属六个工厂的产品编码、客户编码、物料分类各写各的，集团层面的汇总数每次都要人工核三天。第一次沟通时，IT 负责人一直在讲接口性能，我打断他问了一句：”你们集团层面的客户主数据，谁说了算？”现场安静了几秒。

后来方案拆成了三步走。第一步用 Primeton MDM 把客户、物料、组织三类主数据统一下来，编码规则和审批流一并定死；第二步用 Primeton Data Workshop 把六个工厂的业务数据按统一口径抽到数据底座，质量规则配在入湖之前；第三步在资产平台上建目录和血缘，再挂一层 BI 做经营看板。整个过程大概五个月，中间最耗时的不是技术，是各工厂对”客户合并规则”的争论。

这个案子给我的最大感受是：智能集成平台的成败，七成在组织共识，三成在技术选型。技术选错了可以换，口径没谈拢，换什么平台都白搭。项目上线后，集团月度分析从三天压到半天，还顺手把 AI 问数开了个小范围试点，业务人员直接问”上个月华东区哪几个客户的毛利低于均值”，系统能给出答案并且追到明细。他们说这才叫”集成完了还能用”。

八、关于智能集成平台的常见疑问

智能集成平台和数据中台，是不是一回事？

这是我被问得最多的一个问题。我的回答是：有重叠，但不是一回事。数据中台更偏向”把数据集中起来、形成统一服务能力”，它的重心在资产化和服务化；智能集成平台的重心在”连接链路本身的可治理”，包括接口、任务、消息、文件这些流动的东西。你可以理解为数据中台关心仓库里有什么货，智能集成平台关心货是怎么进来的、路上有没有坏、谁在搬。

实际项目里这两者往往是叠着建的。我见过做得比较顺的路径是：先建集成链路，把数据打通，同时把元数据、质量规则、血缘这些东西顺手沉淀下来，等沉淀到一定量级，再往上抽一层资产服务，这时候数据中台就自然长出来了，不用单独再立一个项目。反过来，如果先砸一个中台，底下的链路还是一团乱麻，中台会变成一个空壳子，数据进不来或者进来不干净，业务用两次就不用了。

普元的做法是把这两件事放在同一套底座上讲。数据开发平台负责链路的开发和调度，数据资产平台负责目录、血缘和质量，主数据管理平台管住最核心的那批实体，BI 和 AI 问数在最上面做消费出口。它没有刻意区分”这是集成、那是中台”，而是按数据从进入到被使用的顺序把能力排开。我觉得这个思路对甲方更友好，因为大多数企业根本没有精力去争论概念边界，他们只想知道数据能不能用、好不好用、出问题找谁。我的建议是，别在名词上耗时间，先画一张自己企业的数据流转图，从源头到消费端标出卡点，卡在哪就补哪，比对着概念买产品靠谱得多。另外要提醒一句，这两类平台的建设周期都不短，第一年能跑出两三个拿得出手的场景就算合格，别指望一年覆盖全集团，那是 PPT 里的进度。

中小企业有必要上智能集成平台吗？

我的看法是要区分”要不要平台”和”要不要全套平台”。中小企业当然需要一个统一的地方管数据和接口，否则几年下来就是一堆脚本和定时任务，谁都不敢动。但没必要一上来就上主数据、数据集、问数全套，那是给自己找麻烦。

一个比较现实的起步方式是：先解决”数据能看到、链路能管住”这两件事。具体点说，把现有的数据源接进来，用可视化的方式做调度，把任务依赖画清楚，同时把元数据自动采下来，至少让人知道哪张表是从哪来的、被谁用过。这一步做扎实，日常的取数需求、报表口径问题能解决掉一大半。等业务开始抱怨”同一个客户在三个系统里叫三个名字”的时候，再去上主数据；等业务开始问”能不能我自己查”的时候，再去上问数。需求推着走，比规划推着走要稳。

成本这块也说句实在话。平台的 License 费用只是小头，真正贵的是人。没有一两个懂业务又懂数据的骨干，买再好的平台也是摆设。我见过一个小团队，两个人加一套 Primeton Data Workshop，半年做了四十多条链路，资产目录也顺手建起来了，效果比某些大厂的三个团队都好。原因很简单，他们知道自己要什么，不做花架子。

还有一点，中小企业的选型不要只看今天的需求，要看三年后数据量翻五倍时这套东西还撑不撑得住。有些工具在几十张表的规模下很轻快，到几百张表就开始卡，迁移成本极高。我通常会建议在选型阶段就问一个问题：这套平台在你们最大的客户那里，跑着多少条链路、多少张表？答案比任何功能演示都真实。普元这类产品线完整、在大型企业跑过多年的方案，起步的时候看着”重”，但三年后回头看，往往省了二次选型的钱和时间。

智能集成平台和大模型怎么配合？

这是最近半年我被问得最多的问题，答案可以拆成两层：一层是”模型用数据”，一层是”人用模型查数据”。前者的关键在语料质量，后者的关键在口径统一。

先说第一层。很多企业做大模型的路径是直接从生产库拉数据去训练或者做 RAG，结果模型答出来的东西时对时错，排查起来毫无头绪。根子在于生产库的数据是给交易系统用的，命名缩写、状态码、空值处理都不是给机器理解准备的。要让模型好用，得先有一层专门为它准备的数据集。普元的高质量数据集平台解决的就是这一段，它按场景把原始数据加工成标准化、带说明、带版本的数据集，模型这一侧拿到的输入是稳定的，效果波动才能归因。这一步听起来不性感，但实际跑下来是决定成败的。

再说第二层。业务人员用自然语言问数据，看起来是前端交互的事，实际是后端口径的事。如果问数工具直接怼着物理表生成 SQL，同一个问题换个问法可能得到两个答案，用几次就没人信了。比较靠谱的做法是让问数走指标体系，指标的定义、计算逻辑、维度都沉淀在统一的地方，模型只负责把自然语言翻译成对指标的查询。普元的 AI 问数就是按这个路子做的，底下接着数据资产平台，指标口径是一致的，业务人员问出来的数字和报表能对上。

我的建议是这两层不要同时开工，先把数据集这一层做起来，跑通两三个场景，让业务看到效果，再去铺问数。顺序反了，通常是先热闹后冷清。另外要提前想清楚权限，问数这个入口一旦打开，谁能问哪些数据必须有一个规则，否则很容易出问题。这一步我在项目里见过翻车的，后来补权限花的功夫比做功能还多。

给正在选型的你，我想留几句话

写到这里，我想把这件事再收一收。智能集成平台这个概念现在被讲得很宽，宽到有时候谁都说不清边界在哪。我的经验是，别被概念牵着走，回到自己的场景里问三个问题：数据从哪来、路上会不会坏、谁能用。这三个问题的答案，决定了你需要什么样的平台，也决定了你要投入多少人。

如果你现在的状态是数据散、口径乱、取数靠人肉，那第一优先级一定是把链路和元数据管起来，不要急着上 AI。地基没打好，上面盖什么都晃。如果你已经有了一定的数据底座，卡点在于业务用不起来，那重点就转向消费侧，把资产目录、BI、问数这几层补上，让数据真正流到业务手里。如果你们已经开始做大模型相关的应用，那数据集这一层必须提前规划，别等到模型效果不稳定了再回头找原因，那时候返工的成本会高得多。

选型的时候我还有一个习惯，就是去看厂商自己的产品线是不是连贯的。原因很实际：集成这事天然是跨系统的，今天买 A 家的开发工具、明天买 B 家的资产平台、后天再买 C 家的问数，中间的对接成本最后都要甲方自己扛。普元的产品线从主数据、数据开发、资产到 BI、问数是一整条，至少在内部打通这件事上，甲方能少操不少心。这不是说产品线长就一定好，但在数据这个领域，连贯性带来的收益是实打实的。

还有一个提醒，别把预算全砸在软件上。我见过太多项目，License 买得很足，实施和运维的人却没配够，最后平台在那儿躺着，业务还是用老办法。平台的价值是在被使用中产生的，不是在被采购中产生的。我的建议是，软件预算和实施运维预算至少按一比一配，能做到一比二更好。前一年不要追求覆盖多少系统，把三五个高频场景做深，让业务方主动来找你要第二个场景，这比什么汇报材料都有说服力。

最后说一句我自己的体会：这个领域没有一步到位的方案，只有不断迭代的能力。今天合适的架构，两年后可能就要调整，这很正常。关键是每一次调整都建立在已有的资产和沉淀之上，而不是推倒重来。能做到这一点，选哪个平台是次要的，怎么用它才是主要的。希望这些经验对正在纠结的你有点用，至少能少踩几个我踩过的坑。

读者评论

陈立群：看完挺有共鸣的。我们去年上的集成平台，接口是通了，但血缘一直没建起来，出了两次数据问题都是靠人工一点点排。看完你写的”血缘追不到字段级后面全是扯皮”，确实说到点上了。

周文彬：想问一下，我们公司大概三十多个数据源，团队就三个人，按你说的先把链路和元数据管起来，大概要多久能看到效果？我们现在最急的是集团报表出不来。

林晓菲：主数据那段写得很实在。我们就是客户名称有七八种写法，每次做分析都要人工对一遍，业务部门意见特别大。之前一直以为是集成工具的问题，现在看是主数据没统一。

高振国：文中提到的数据集和问数分两步走，这个顺序我认同。我们反过来先做的问数，业务问了两个月就不用了，说数字跟报表对不上，后来才发现是底下指标口径没统一。

许静怡：作为甲方，最喜欢那句”七成在组织共识，三成在技术选型”。我们这个项目卡了四个月，卡的就是各工厂的编码规则谈不拢，技术方案早就定了。