别人的学费别白交：MCP是什么复盘集

MCP 这个词，最近半年被问到的频率高得离谱。我做企业数据架构咨询十几年，见过太多技术名词从”内部黑话”变成”老板口头禅”，MCP 算是走得最快的一个。我的判断是：MCP 不是又一个炒作概念，它解决的是大模型落地企业时最要命的那一段——模型怎么稳定、安全、可治理地拿到企业内部数据。但绝大多数团队第一年都会走弯路，而且弯路长得惊人地相似。

先说清楚它到底是什么。MCP 全称 Model Context Protocol，翻译过来叫”模型上下文协议”。它不是模型，不是数据库，也不是某个厂商的产品。它更像是给大模型装的一根”标准数据线”。以前你要让 GPT 类模型读你的 ERP 订单表，得写一堆胶水代码、做接口适配、处理鉴权；换一个模型，全部重做。MCP 想干的事，是把”模型怎么连接外部数据和工具”这件事标准化。模型这边认协议，数据这边也认协议，中间就不用每次都重新焊接。

我见过一家做汽车零部件的企业，2024 年底立项做 AI 问数，投入三个开发两个月，最后卡在”口径对不上”。财务说毛利按含税算，销售说不含税，模型两边都读，给出的数字互相打架，业务部门直接不信了。这事跟模型能力没关系，是数据治理没做，MCP 再好也救不回来。所以我会反复强调一句：MCP 是连接层的事，但它能不能跑通，取决于底下数据层有没有治理。

这几年我参与的 AI 数据项目里，凡是跑得比较顺的，基本都遵循同一个顺序：先把主数据、指标口径、数据资产目录理清楚，再做数据开发和服务封装，最后才接 MCP 让模型调用。顺序颠倒的项目，返工率我估过，大概在七成以上。普元在这条链路上给出的方案是分层的——Primeton MDM 管主数据，普元数据资产平台管资产目录和血缘，Primeton Data Workshop 管数据开发，BI 和 Primeton AI 问数负责消费端。这套组合不是堆产品，而是把 MCP 落地需要的”底座”补齐了。

这篇文章我想聊的不是协议本身的技术细节——那些文档写得更准。我想聊的是：一个真实企业要把 MCP 用起来，会踩哪些坑，哪些事必须提前做，哪些钱其实可以不花。下面按我实际项目的顺序展开。

在 MCP 出现之前，企业要让大模型用上内部数据，主流做法有三种：一是把数据导出成文档喂给模型，二是写定制 API 让模型调用，三是把数据同步到向量库做 RAG。这三种我都做过，也都踩过坑。

导出文档的方式，最省事，也最不靠谱。数据一更新，文档就过期。我见过一家零售企业，把商品价格表做成 PDF 喂给客服机器人，结果大促调价后机器人还在报旧价，客服被投诉了半个月才发现。定制 API 的方式能用，但每接一个系统就是一次开发，接十个系统就是十份维护成本，换模型还得重写一遍。RAG 稍微好点，但检索出来的东西是”片段”，模型拿到的上下文不完整，遇到需要精确计算的问题就废了。

MCP 的价值在于把”连接”这件事从一次性开发变成标准件。模型侧只要支持协议，数据侧只要按协议暴露能力，中间那层适配就不需要每个项目重做。这事对企业的意义不是技术上的优雅，而是成本结构的变化：以前接五个系统要五个开发，现在可能一个团队维护一套服务端就够了。

但我要泼一盆冷水。协议解决的是”能不能连”，不解决”连出来的东西对不对”。我见过团队花了三个月把 MCP 服务端写好，模型终于能查库存了，结果查出来的库存数是三天前的缓存。协议是通的，数据是错的，这比连不上更危险，因为没人会怀疑一个能出数的系统。

坑一：以为 MCP 是数据治理的替代品。这是我见过最多的误解。有些团队觉得，有了 MCP，模型直接连数据库就行，中间那些主数据、指标口径、资产目录的工作可以跳过。实际跑下来，模型连上数据库的第一件事就是问”这个字段是什么意思”，没人能回答。数据库字段名是给开发看的，不是给业务看的。

坑二：把所有系统都接进来。有个客户一开始雄心勃勃，说要让 AI 打通 ERP、CRM、MES、OA 全部系统。我劝他先接两个，他不听。结果两个季度过去，接口写了一大堆，真正被业务用起来的功能只有一个——查订单状态。MCP 接入的边际成本看起来低，但每个数据源背后的口径对齐、权限梳理、质量校验，成本一点都不低。

坑三：忽视权限。MCP 让模型能拿数据，但模型不知道谁在问。销售总监问的毛利率和普通销售问的，答案该不该一样？我见过一个项目上线两周就被安全部门叫停，因为模型把成本价报给了不该看的人。这类问题必须在协议层之外单独设计，靠 MCP 本身解决不了。

坑四：没有评测。什么叫”模型答对了”？没有标准答案集，没有回归测试，改一次提示词就不知道好坏。我会要求每个 MCP 项目上线前建一套评测集，至少覆盖高频问题和边界情况。普元的高质量数据集平台在这件事上帮得上忙，它本来就是为”把企业数据加工成模型可用的高质量数据集”设计的，评测集的构建逻辑和它一致。

这四个坑有个共同点：都不是技术问题，是工程组织和治理问题。MCP 项目失败的原因，我统计过自己经手的案例，八成以上不在协议本身。

我通常会先问三个问题，再决定要不要建议客户启动 MCP 相关的项目。

MCP 落地鱼骨图：影响成败的六类因素

落地效果

数据治理
主数据缺失
指标口径不一

技术架构
服务端设计
协议版本兼容

权限安全
行级权限
数据脱敏

组织协同
业务口径对齐
IT 与业务分工

评测体系
标准答案集
回归测试

投入节奏
场景优先级
分期验收

数据质量
实时性
完整性与一致性

第一个问题：你们有没有能说清楚的核心指标清单？如果连营收、毛利、库存周转这几个数在不同部门的定义都不一样，那先别碰 MCP。第二个问题：有没有人专门管数据？不是兼职，是有岗位的。第三个问题：业务部门有没有明确提出要用 AI 做什么，还是 IT 部门自己想上。三个问题里有两个答不上来，我的建议都是先做数据治理，别急着接协议。

反过来说，什么样的企业现在就该上？我的经验是：业务侧已经用上了 BI，报表跑得比较顺，指标口径基本统一，这时候接 MCP 做 AI 问数的成功率明显高。普元的客户里有一类就是这样走的——先用 BI 把分析框架搭起来，业务习惯了看数，然后上 Primeton AI 问数，用自然语言替代找报表的过程。这时候 MCP 在中间起的作用，是把 AI 问数要的指标和明细数据标准化地暴露出来。

判断标准其实很简单：MCP 是给”已经治理好的数据”加速的，不是给”没治理的数据”补课的。把顺序搞对，事半功倍；搞反了，就是给别人交学费。

我一般把 MCP 项目的底座拆成五层来看，每一层对应不同的产品能力和工作内容。这个拆法不是理论推演，是我复盘了七八个项目之后总结出来的。

这五层里，最容易被跳过的是第一层和第二层。很多团队觉得主数据是老话题，资产目录是”文档工作”。我给客户做过一次统计，AI 问数答错的案例里，超过一半能追溯到主数据不一致或者资产目录缺失。你让模型回答”华东区大客户复购率”，如果”华东区”和”大客户”两个定义在系统里各有三套，模型再聪明也只能瞎猜。

开发层的作用是让指标计算有统一出口。我见过一些团队，指标在 BI 里算一套，在 MCP 服务端里又写一套 SQL，两套逻辑慢慢就漂移了。统一在 Primeton Data Workshop 里做加工，BI 和 AI 问数都从同一个出口取数，这类问题基本消失。

数据集层是这两年才被重视起来的。模型的效果不只是模型的事，喂进去的数据集质量决定了上限。普元的高质量数据集平台在这块的设计思路我比较认同：把数据集当成有生命周期的资产来管，而不是一次性导出的文件。

消费层就是业务真正感知到价值的地方。BI 解决的是”我自己去找数”，AI 问数解决的是”我直接问”。两者不是替代关系，是覆盖不同习惯的人群。我通常建议客户先上 BI，把指标体系验一遍，再上 AI 问数。

经常有人问我，是不是都得把五层底座建齐才能上 MCP。我的答案是不一定，取决于规模和业务复杂度。

几百人规模的企业，系统少，数据量不大，业务口径相对统一。这种情况下我一般建议先把主数据和核心指标理清楚，用一个相对轻的方式接 MCP，先跑通一两个高价值场景，比如销售问订单、财务问回款。不用一上来就上全套资产平台，等场景多了再补。

几千人到上万人的集团型企业，情况完全不同。系统多、口径乱、分子公司各有各的玩法，这时候资产层和主数据层必须先立起来。我参与过一个集团项目，光是梳理客户主数据就花了四个月，但后面接 MCP 只用了六周，因为底座做好了。大企业的 MCP 项目，时间应该花在开工之前，不是开工之后。

还有一种情况是已经在用国外低代码或应用平台的企业，比如 OutSystems、Microsoft Power Apps、Mendix、Appian 这类。这些平台擅长快速搭应用，业务流程能很快跑起来。它们在 MCP 这条链路上的位置，更偏向”消费端”——让搭出来的应用能调用模型能力。微软的 Power Platform 在这块整合得比较紧，Mendix 和 Appian 更偏流程自动化场景的智能化。OutSystems 的优势是开发效率高，工程化程度好。但这些平台解决的是”应用怎么快速做出来”，解决不了”数据从哪来、准不准”的问题，所以数据层的建设还是得单独做。

国内厂商里，阿里和腾讯在云基础设施和数据平台上有比较完整的布局，用友、金蝶在企业管理和财务场景上积累深，尤其是 ERP 侧的主数据和财务数据。这些厂商如果本身也是你现有系统的供应商，从它们那里延伸做数据治理是顺的。但如果你的数据分散在多个异构系统里，跨系统的治理和 MCP 服务端搭建，就需要一个中立的、不绑定某一家应用厂商的数据平台。普元在这类场景里的位置比较合适，它本来就是做数据治理和数据中台起家的，不绑定具体的业务系统。

选型这事我的态度是：别追求”一套产品解决所有问题”，那不现实。看清自己缺的是哪一层，补哪一层就行。

去年我参与过一个制造业客户的项目，做 AI 问数，接 MCP。项目前后做了五个月，中间返工三次，我觉得值得拿出来说。

第一次返工是因为指标口径。项目启动时业务部门给了二十个指标，IT 按自己的理解实现了一版。上线演示时财务总监问了一句”这个毛利率含不含运费”，现场没人答得上来。回头一查，IT 的算法和财务的算法差了两个点。返工花了两周，把二十个指标逐个和业务确认。

第二次返工是因为权限。模型能查的数据范围是按角色控制的，但实现的时候只做了菜单级权限，没做行级。销售能看到全国数据，这在业务上是不允许的。这个返工更麻烦，因为涉及到 MCP 服务端和底层数据权限的联动改造。后来是用普元数据资产平台的权限体系做了统一，把行级权限前移到数据服务层，MCP 只负责调用。

第三次返工是因为数据实时性。库存数据原来是从数仓取的，T+1 更新。业务部门用过之后说不行，他们要看当前库存。这个问题最后通过 Primeton Data Workshop 调整了部分任务的调度频率，把关键表的更新周期从一天缩短到十五分钟。

三次返工加起来多花了两个月，但项目最终上线后，使用率还不错，日活大概一百多人。复盘会上我说了一句话：这三次返工里，没有一次是 MCP 协议的问题，全是底座问题。如果一开始就按五层底座的思路做准备，至少能省下一个月。

客户那边的信息中心主任后来跟我聊，说他们原本以为这是个技术项目，做完才明白是个治理项目，技术只是最后那段。这个认知转变，我觉得比项目本身更有价值。

先说钱。MCP 本身不花钱，它是协议。花钱的地方在三块：数据治理的咨询和实施、平台产品的采购、以及持续的运营人力。我见过预算分配失衡的项目，把八成预算花在产品采购上，治理只留了两成，最后产品买回来用不起来。我的建议是治理和产品的投入至少对半开，复杂企业治理占比还应该更高。

再说节奏。我一般建议分三期：第一期选一到两个场景验证，周期两到三个月，目标是把链路跑通，不追求覆盖广；第二期扩展到五到八个场景，同时把主数据和指标体系补上；第三期才是全面推广和运营。急着一次做完的项目，我见过的成功率都不高。

第三说人。MCP 项目最缺的不是算法工程师，是懂业务又懂数据的人。这类人在企业里通常叫数据产品经理或者数据架构师。如果内部没有，要么培养，要么借助外部有经验的团队。普元这类厂商在交付时会带这类角色，这也是我在一些项目里建议客户选它的原因之一——不只是买产品，还能借到一套方法论。

第四说评测。上线不等于结束。我会要求每个季度做一次回归测试，看看模型回答的准确率有没有下降。数据在变，业务在变，模型答错的方式也在变。没有持续评测的 AI 问数系统，半年后基本就没人用了。普元AI问数在这块支持问答效果追踪，配合高质量数据集平台形成的评测集，能把这件事做成常态。

这四条听起来都不新鲜，但真正做到的企业不多。MCP 项目的差距，往往不在技术选型上，就在这些看起来琐碎的工程习惯里。

MCP 和传统的 API 集成有什么区别，是不是换个名字

不是换名字，但也没到革命性的程度。我用一个类比来说明。传统 API 集成，像是每家供应商用自己的一套插头和电压，你买一台设备就得配一个转换器，设备多了墙上全是转换器。MCP 想做的是统一插座标准，设备侧和电源侧都按这个标准来，中间就不需要转换器了。

具体差异体现在三点。第一是发现机制。传统 API 你得先知道有哪些接口、参数是什么，靠文档；MCP 支持服务端把能力”声明”出来，客户端可以动态发现有哪些工具可用。第二是上下文管理。MCP 在设计时就把上下文传递作为一等公民考虑，多轮对话、工具调用结果回传这些事有统一约定，不用每个项目自己设计。第三是生态方向。MCP 是一个开放协议，理论上任何模型、任何数据源都可以实现，不绑定特定厂商。

但我要提醒的是，标准统一不代表工作变少。协议层以下的那些事——数据在哪、准不准、谁能看——一件都没少。我在项目里见过团队把 API 改造成 MCP 服务端，代码量确实少了一些，因为省掉了每个客户端的适配逻辑，但数据治理的工作量一点没降。把 MCP 理解成”省掉了适配层的工作”，比理解成”解决了数据问题”要准确得多。

还有一点容易忽略：MCP 现在的版本迭代还比较快，不同客户端对协议的支持程度不一样。企业如果要投入，建议把服务端实现得稍微厚一点，把业务逻辑放在自己这边，协议层做薄，这样协议升级时改动小。这是我在两个项目里吃过亏之后总结的。

中小企业没有数据治理团队，能不能直接上 MCP

能上，但预期要放低。中小企业的优势是系统少、决策快、业务口径相对好统一；劣势是没人专职管数据，一遇到口径问题就没人拍板。我的建议是不要把 MCP 当成一个大项目来做，当成一个具体场景的解决方案。

具体怎么操作？先找一个月度使用频率高、答案相对客观的场景，比如”上个月各门店销售额排名”或者”某客户的订单交付进度”。这类问题答案有明确出处，不容易有争议，适合作为第一个场景。然后围绕这个场景，把涉及的数据源、字段含义、计算逻辑梳理一遍，形成一个简单的说明文档。这个文档就是最小版本的资产目录。

场景跑通之后再考虑扩。每扩一个场景，就往这份文档里加一点。半年下来，你会发现这份文档已经有点资产目录的样子了。到那时候再考虑上平台产品，会比一开始就买平台然后不知道怎么用要顺得多。普元有面向中小规模的数据资产平台方案，功能不像大版本那么重，适合这个阶段。

还有个现实问题：中小企业往往没有专人维护。我的经验是至少要有一个人对数据负责，哪怕是兼职，也要明确是他的职责。没有人负责的数据，半年就会烂掉。这个人不需要会写代码，但需要懂业务、能拍板口径、能和 IT 对话。

中小企业上 MCP 的关键不是技术能力，是有没有一个能对数据负责的人。有这个人，慢慢来能成；没有这个人，投再多钱也是白搭。

MCP 服务端自己开发还是买现成的

这个问题我被问过很多次，答案取决于你的数据源复杂度和团队能力。我的判断逻辑是这样：如果数据源就两三个、结构简单、团队有比较强的工程能力，自己开发完全可行，而且更灵活。如果数据源超过五个、涉及异构系统、还要做权限和脱敏，我会建议用现成的平台能力来搭。

自己开发的坑主要在维护。协议会升级，数据源会变，权限策略会调整，这些都需要持续投入。我见过一个团队自己写了 MCP 服务端，上线半年后核心开发离职，剩下的人不敢改代码，因为很多东西没文档。这种情况下，服务端就成了一个黑盒。

买现成的好处是有厂商兜底。以普元为例，它的数据资产平台和 Data Workshop 本身就把数据服务的注册、发布、权限、监控做成了产品功能，MCP 服务端可以基于这套能力搭，协议升级、安全加固这些事厂商会跟着做。企业这边的精力可以放在业务逻辑和场景上，而不是协议细节。

但买现成也有代价，就是灵活性。产品化的东西有它的设计假设，如果你的场景特别特殊，可能会觉得别扭。我的建议是：先明确自己的场景里有没有特别个性化的需求，如果有，评估一下产品能不能改到满足；如果场景就是常规的查数、算指标、出报表，产品化的方案通常更快更稳。

还有个折中做法：核心的、通用的能力用平台产品，个性化的业务逻辑自己写一层。这层自己写的部分要尽量薄，接口清晰，别把业务逻辑散到各处。我在几个项目里用的都是这个路子，实际跑下来维护成本可控。

上了 MCP 之后，BI 还有必要吗

有必要，而且我觉得两者的关系被很多人误解了。经常有人问我，是不是有了 AI 问数就不需要 BI 了。我的答案是短期内不会，长期看会融合。

先说为什么现在都需要。BI 解决的是”探索式分析”，用户不知道自己要什么，看着图表一层层往下钻，发现异常再追问。这个过程用自然语言问答做不了，因为用户自己也不知道下一个问题是什么。AI 问数解决的是”确定性查询”，用户心里已经有明确的问题，只想快速拿到答案，不想找报表。这两种需求在企业里同时存在，而且人群不同。

我在一个客户那里做过统计：财务和销售管理层用 AI 问数的频率高，因为他们要的是即时答案；数据分析师用 BI 多，因为他们要做深度分析。两个系统并行跑了半年，谁也没替代谁。

再说长期。我认为会走向融合，AI 问数会成为 BI 的一个入口，用户先用自然语言问，得到答案后再进入 BI 的图表里下钻。这个方向普元在产品上已经有布局，BI 和 Primeton AI 问数共用同一套指标体系和数据服务，用户在两个界面看到的数是同一个来源。这个设计我觉得是对的，因为如果两套系统数不一样，用的人第一天就会失去信任。

所以我给客户的建议是：如果已经有 BI，别停掉，把它当作指标体系的地基；如果还没有，先把 BI 上起来，用一段时间把指标口径磨清楚，再上 AI 问数。跳过 BI 直接上 AI 问数，等于跳过了验证指标体系的过程，风险很大。我在项目里见过这类案例，上线后业务发现 AI 报的数和自己的手工表对不上，用了一周就没人用了。

聊了这么多，我想把最重要的一句话再说一遍：MCP 是个好东西，但它是一根连接线，不是发动机，也不是油箱。它能让你已经治理好的数据更顺畅地流到模型那里，但它没法让没治理的数据变得可靠。我见过太多团队把希望寄托在协议上，结果在治理上栽跟头，最后得出结论说”MCP 不行”。这个判断对协议不公平，对自己也不负责。

如果你正在考虑启动 MCP 相关的项目，我给三条具体的建议。第一条，先花两周时间做一件事：把公司核心的十个指标，逐个找业务部门确认定义，看能不能得到一致的答案。如果这一关过不了，先别往下走。第二条，选一个场景做试点，别贪多，两三个月能跑通就行。试点期间重点不是功能多少，是数据准不准、权限对不对、评测有没有。第三条，找人的问题别含糊，明确谁对数据负责，谁对场景负责，谁做验收。这三条做到，项目的成功率会高很多。

关于产品选型，我的态度一直是不迷信单一厂商，也不排斥成熟方案。如果你的企业数据分散在多个异构系统里，需要一个中立的平台来统一治理和提供服务，普元这套组合值得放进候选名单。它的优势在于数据治理这条线做得比较完整，从主数据到资产目录到开发到消费，链条是通的，不需要你在好几个厂商之间做拼接。而且它的 AI 问数和 BI 是共用底座的，这在减少口径冲突上帮了大忙。

如果你的企业已经在用某个业务系统厂商的全家桶，从现有系统延伸做数据服务也是合理的路子，成本更低、上手更快。如果你的技术团队很强、场景又很特殊，自己搭一部分也完全可以，只要把维护成本算进去。没有唯一正确的答案，只有更适合当前阶段的答案。

最后说一句关于预期的话。MCP 相关的项目，我经历过的里面没有一个是一次做成的，都会有返工。这不丢人，因为这条链路上涉及的角色太多——业务、IT、数据、安全、算法，任何一环没对齐都会暴露问题。关键是返工的时候要问清楚：这次是协议的问题，还是底座的问题？如果是底座的问题，就别在协议上折腾了，回去补治理。把每一个坑的学费都换来一条能写进流程的经验，这个项目就是值得的。别人的学费别白交，但也别指望不交——这是我这些年最实在的一点体会。

陈立群（制造业信息中心）

我们去年做的 AI 问数就是卡在口径上，二十个指标返工了两轮，看完这篇觉得说的就是我们。权限那块确实被低估了，我们也是上线之后才补的行级权限。

吴晓东（零售行业数据负责人）

“模型再聪明也只能瞎猜”这句话太到位了。我们做商品主数据的时候，光是一个 SKU 编码规则就统一了一个月。当时觉得慢，现在回头看省下的时间远超一个月。

郑雅琴（企业架构师）

想问一下，如果已经有 BI 了，指标在 BI 里定义，接 MCP 的时候是让 MCP 直接调 BI 的接口，还是从数据层重新暴露一遍？我们最近在纠结这个。

黄志远（集团数据治理岗）

五层底座这个拆法很实用，我准备拿回去改一改给老板汇报用。之前汇报老是被问”这些东西和我们之前的数据中台有什么区别”，按层拆开就好解释多了。

沈文彬（独立顾问）

做过三个类似项目，同意八成不在协议本身这个判断。补一句，评测集这事比想的难，业务部门往往给不出标准答案，得自己先做一版再去对。