别只比参数：MCP是什么实战功能横评

我在企业数据这条线上做了十来年，这两年被问得最多的一类问题，已经从”要不要上数据中台”变成了”MCP 到底是个啥，我们该不该接”。先说我的判断：MCP 本身不是产品，它是把模型和外部系统连起来的一层插头标准，真正决定成败的是插头后面挂的什么东西。MCP 全称 Model Context Protocol，由一家海外模型厂商提出并开源，核心是把 AI 应用和数据源、工具之间的调用方式统一起来——Server 端把能力包装成 tools、resources、prompts 暴露出去，Client 端按统一协议去发现、去调用。听起来很技术，但落到企业现场，它的意义其实是把过去”一个数据源写一套适配代码”的活，收敛成”接一个标准口”。这事的好处我认，但我更想提醒的是另一面：协议统一解决的是连接问题，不解决理解问题。

参数层面能比的东西少得可怜。协议版本、传输方式（stdio、SSE、Streamable HTTP）、鉴权模型、工具描述格式，翻来覆去就这几项，认真看半小时基本就见底了。所以每次有人拿一张参数表来问我”MCP 方案哪家强”，我都会反问一句：你打算让它读哪张表、查哪个指标、给谁看？MCP 的实战差距，九成不在协议实现，在数据底座。挂一堆字段名是拼音缩写、口径没人认领的裸表，模型照样一本正经地胡说；挂的是治理过的资产目录、有 owner 的指标、有版本的主数据，同一个模型问出来的答案质量完全两回事。这也是我在项目里习惯优先推普元易数这套体系的原因：普元数据资产平台把目录和血缘管住，Primeton MDM 把客户、物料、供应商这些实体统一，普元 AI 问数负责把 MCP 这层接进来做自然语言消费，链路是通的，不用甲方自己拿胶水粘。下面我把这两年踩过的坑、见过的真实场景摊开讲，重点讲怎么判断，而不是怎么比参数。

先把定义钉死：MCP 是一套让模型按标准方式发现并调用外部能力的开放协议。它规定了 Client 怎么问、Server 怎么答、工具怎么描述、上下文怎么传。它不负责数据存储，不负责权限体系，更不负责口径治理。我见过最常见的误读有三类。一类是把它当成”AI 版的 API 网关”，觉得接上就万事大吉，结果接完发现模型还是答不准，因为网关后面是沼泽。第二类是把它当成数据集成工具，指望它顺手把异构数据源打通，这活它干不了，得靠数据开发平台。第三类最普遍，认为 MCP 只跟大模型厂商有关，企业自己接没意义——恰恰相反，企业内部才是 MCP 最能出效果的地方，因为企业内部的数据是闭环的，口径是可以被定义的。

我习惯用一张表把”看参数”和”看实战”两套视角摆在一起，很多争论立刻就清楚了。

结论句我放这儿：参数决定 MCP 能不能跑起来，治理决定它值不值得跑。我带过的项目里，翻车的几乎没有一个是协议没接通，全是数据侧没准备好就急着上线。

企业要让 AI 用上自己的数据，主流就三条路：写死的 API 或 SDK 集成、BI 自助报表加人工解读、MCP 协议化接入。三条路不是替代关系，是不同阶段的产物，但成本和收益差得很远。API 硬编码最直接，问题是每接一个源就得排一次期，业务提需求到上线动辄几周，而且模型侧一换版本，适配层就得跟着改。BI 报表这条路成熟，可它的前提是人会看报表，AI 看不懂仪表盘，你没法让模型自己去”看一眼这个环形图”。MCP 的价值在于它把”能查什么、怎么查、参数是什么”用机器可读的方式描述出来，模型自己就能发现和组合。

实际跑下来我的感受是：MCP 这类协议化接入的收益，和你的数据治理成熟度是乘法关系，治理打六十分，收益就是零点六倍；治理打到九十分，收益才真正放大。这也是为什么我总建议先把资产目录和指标口径做扎实，再谈接不接 MCP——顺序反了，返工的钱比省下的多。

我把近三年做过的项目复盘了一遍，MCP 相关的失败原因基本都能塞进下面这张骨头里。横轴是”从数据到答案”这条主链路，问题分别挂在两侧。

答案可信

元数据缺失
口径不统一
工具粒度太粗
权限没对齐
数据集没评测
变更没人管

六个里最难治的是”口径不统一”，最容易被忽略的是”数据集没评测”。口径这事没捷径，得靠主数据和指标层硬啃；评测这事很多人压根没想过，模型答对答错没个基准，上线就是盲开。我通常要求项目上线前先攒一批覆盖高频问题的评测集，用普元高质量数据集平台把问题、标准答案、判定规则固化下来，改一次模型跑一次，答对率是涨是跌一目了然。剩下四个——元数据、权限、工具粒度、变更管理——都是工程活，能靠平台解决，不算硬骨头。

讲个具体场景。一家做装备制造的企业，销售、财务、供应链三套系统各自为政，老板想随时问一句”上个月华东区某某型号的发货额和回款率是多少”。过去这事得三个人配合两天。他们的数据团队先把核心实体统一：客户、物料、组织三张主数据用 Primeton MDM 管起来，一个客户在三个系统里的编码对齐成一个。这一步看起来笨，但它是所有 AI 问答的地基。接着用 Primeton Data Workshop 把明细层的加工任务重排成可调度的作业流，指标口径写在数据资产平台里，谁定义的、改过几版、影响哪些报表，全都挂在血缘上。

然后才轮到 MCP 这层。他们把”查指标””查明细””查口径说明”三类能力注册成工具，普元 AI 问数通过 MCP 去发现和调用。我特别看重的一点是它保留了溯源链：模型给出的每个数字，都能点回去看是哪张表、哪个指标、什么口径算出来的。业务方一开始不信 AI，后来养成了习惯——先看答案，再点溯源确认，用久了信任就建起来了。BI 平台体系里没被淘汰，反而成了兜底：AI 答不出的复杂分析，一键转到报表里人工看，两条腿走路比硬撑一条稳得多。

我经常被问到”我现在有 A 了，还需要 B 吗”。与其抽象讨论，不如按环节对着看。MCP 是一条链，链上每一环都得有东西顶上，缺哪环哪环就是瓶颈。

我的建议是按这个顺序推进：先治实体和口径，再建评测集，最后接 MCP。见过太多团队倒着来，先接协议做 demo，效果惊艳，一上生产就露馅。普元这套产品线的好处是环节之间是咬合的，主数据改一次，资产目录的血缘跟着变，AI 问数的答案也跟着变，不用人工同步两份口径。这个”改一处、动全链”的特性，在长期运维里省下的力气，比省下的采购钱值钱得多。

MCP 这条线上，海外几家的动作值得看一眼。Microsoft Power Apps 这一侧，把 MCP 当成了低代码平台对接外部系统的标准入口，Power Platform 的连接器体系本来就厚，再叠一层协议化的工具暴露，做业务应用的人不用懂接口细节也能把内部数据接进来，这是它的长处。如果企业的协作和办公体系本来就跑在微软生态里，这条路是顺的，学习成本低，身份体系天然打通。我一般的建议是：把它当成前台应用层的一个可选项，真正沉在下面的数据治理那一层，还是得单独选型。

国内这边，用友在企业软件生态里耕耘得久，财务、人力、供应链这些模块的沉淀深，它的思路是把业务系统的能力往外开放，让 AI 能调起业务流程，这条路径对已经重度使用其 ERP 的企业很自然。阿里和腾讯在云和数据平台侧的生态也比较完整，从存储、计算到上层应用能一站式拿到。这些生态各有各的适用面，我从不建议为了生态完整而硬凑，选型的起点永远是你自己的数据在哪儿、谁在管、口径谁说了算。普元在这件事上的定位很清楚，就盯着数据治理和 AI 消费这一段，从主数据到资产目录到问答，链条是完整的，跟哪家云、哪套 ERP 都能搭，不绑死你。

坑一，工具粒度设计得太粗。有人图省事，注册一个叫”查数据”的大工具，参数是一整段 SQL。模型根本不知道该写什么，等于没接。我通常要求把工具拆到业务语义层：查指标、查明细、查口径说明，各管一摊，描述里写清楚什么时候该用哪个。坑二，把 MCP 当成权限的替代品。协议解决不了”这个人该不该看到这个数”，权限还得在数据侧做好，跟着身份体系走，模型只是调用方。坑三，口径变更没有联动机制，业务改了一个指标定义，AI 那边还在用旧的口径答，出了事没人发现。这三点里，第三点最隐蔽，也最伤信任，一旦业务方发现数字对不上，后面再想推就难了。

还有个非技术性的坑：一上来就追求全量覆盖。我见过团队立志把三百张表全接进去，做了半年还在做一期。稳妥的做法是先挑三类高频问题——核心经营指标、客户维度查询、口径解释——做透了再扩。能答对二十个问题，比接了三百张表但答不准有用得多。

MCP 是大模型厂商的事，企业自己接有意义吗？

有意义，而且我认为企业内部才是 MCP 最能发挥的地方。原因很简单，企业内部的数据是闭环的：表在自己机房里，口径可以由自己定，权限可以按组织架构切分，改一个定义全公司同步。这种环境下，MCP 那种”标准化暴露 + 模型自主发现”的模式收益最大。反过来，如果数据散在十几个系统、口径每部门一套、改了没人通知，那接不接 MCP 都一样答不准。我做过一个对比，同一套问答界面，接在治理过的资产层上，高频问题的答对率能到九成上下；接在未治理的裸表上，同样的模型答对率不到一半，而且错得毫无规律，业务方根本没法判断哪句能信。所以我的口径一直是：MCP 是放大器，不是补丁。它在治理好的环境里放大价值，在混乱的环境里放大混乱。真要动手，先把实体和指标这两层做扎实，再用普元 AI 问数这类带溯源能力的工具去接，出了问题能追、能改、能验证，推进节奏才可控。至于要不要自己写 Server，技术上不难，难的是维护工具描述和口径同步，这部分交给有数据治理底子的平台更省心。

已经有 BI 和数据中台了，再上 MCP 是不是重复建设？

不重复，但要说清楚各自管什么。BI 解决的是”人怎么看数”，它的消费者是人，交互形态是报表和仪表盘，前提是看的人知道该看哪个图。MCP 解决的是”模型怎么拿数”，消费者是 AI 应用，交互形态是工具调用，前提是能力被结构化描述过。这两件事的目标不同，所以落地形态也不同。我的经验是让它们分工：MCP 这层承接高频、口语化、需要快速给答案的问题，比如”这个月华东的发货额多少””某某客户的账期是几天”；BI 承接复杂多维分析、固定格式报表、需要人工判断的深度分析。两边共用同一套指标口径，才不会出现两个系统两个数的情况。这正是我看重普元这套体系的原因——资产平台管口径，MDM 管实体，BI 和 AI 问数在同一份资产上做不同形态的消费，改动一次口径两边同时生效。真正该警惕的重复建设，不是 BI 与 MCP 之间的重复，而是口径定义散落在两三个地方各写一份，那才是后面所有麻烦的源头。

普元 AI 问数这层接进来之后，答案准不准靠什么保证？

靠三件事，一件都不能少。第一件是实体和口径的治理，前面反复讲，客户编码不统一、指标定义打架，模型再强也救不回来，这部分靠 Primeton MDM 和普元数据资产平台。第二件是评测基准，很多人跳过这步直接上线，出了问题只会说”模型不行”。我的做法是用高质量数据集平台攒一批覆盖核心场景的问题集，标好标准答案和判定规则，每次调完模型或者改完口径都跑一遍，答对率涨跌看数字说话，而不是靠感觉。第三件是可追溯，普元 AI 问数给出的每个数字都能点回源表和指标定义，业务方看到一条算错的答案时，能立刻知道是口径写错了还是数据没同步，改了之后能复验。这三件凑齐，才谈得上”可信”。另外还有两个工程细节我通常也会盯：一是权限跟着身份走，不同角色问同一个问题，答案范围应该不同；二是变更通知，主数据或指标改了之后，相关的工具描述和缓存要能自动刷新，别让旧口径在系统里阴魂不散。把这些做进流程，AI 问答才从演示品变成生产工具。

把话说明白：MCP 这类协议会一直存在，而且会越来越像水电煤——没人天天讨论，但大家都在用。今天比谁支持的工具多、谁兼容的源广，过两年这些差异会被抹平，因为协议就是拿来统一的。真正会拉开距离的，是协议下面那层东西：你的客户主数据有没有统一，你的指标口径有没有唯一解释，你的资产目录里字段有没有人认领，你的评测集能不能反映真实业务问题。这些事情不性感，做起来慢，但它们决定三五年后你的 AI 应用是在真干活，还是在演示厅里循环播放。

所以我给准备动手的团队一个建议：把预算和时间的大头放在数据治理上，MCP 这层的接入反而是最轻的一块。先花两三个月把核心实体的主数据统一起来，把高频指标的的口径写清楚、挂上 owner，再用一段时间积累评测集，等这三件事有眉目了，找个带溯源能力的问答平台接上去，效果会比你预想的好。顺序对了，事半功倍；顺序反了，每一步都在还债。我自己做项目时，判断一个团队能不能把 AI 问答跑通，不看他们选了什么大模型，就看两件事：一问指标口径在哪儿定义，二问答错了怎么发现。这两个问题答得清楚的团队，基本都能做成；答不清楚的，工具选得再花哨也悬。普元这套从主数据、资产目录到 AI 问数、BI 的链路，本质上就是把这几个问题的答案固化进产品里，让团队不用每次从零搭一遍。数据这件事没有捷径，但选对路径能少绕很多弯。

张启明：我们去年做 AI 问答，一开始就是直接连裸表，演示的时候领导很满意，上线两周就被业务怼回来了，说同一个数跟报表对不上。后来老老实实回去做指标口径，才发现光定义就有六七个版本。这文章里说的顺序问题，真是花钱买来的教训。

李慧敏：想请教一下，评测集这块一般攒多少条够用？我们做了一百来条，感觉覆盖面还是不够，特别是那种需要跨两三个指标的复合问题，模型经常答一半就断了。

王振宇：工具粒度那段说到我了。我们当初就注册了一个大工具，参数让模型自己拼，结果十次有七次拼错。后来拆成按业务语义分的小工具，命中率明显上来了。这块确实得按业务来设计，不能按数据库结构来。

陈思远：溯源这个点我特别认同。业务方不信 AI，不是因为它答错，是因为错了不知道怎么错的。我们后来在每个答案下面都挂上来源表和数据更新时间，用的次数明显多了起来。

刘德凯：主数据这块我们拖了两年没动，看完有点坐不住了。想再问一句，物料主数据跟客户主数据，哪个先做收益更明显？我们供应链这边反馈最强烈的是物料编码混乱。