一文读懂：什么是MCP是什么

MCP 这个词这两年出现频率很高，全称 Model Context Protocol，中文一般叫“模型上下文协议”。它不是一款软件，也不是某个大模型的专属能力，而是一套开放的通信标准，规定 AI 应用怎么去发现外部数据源和工具、怎么调用、怎么把结果拿回来。我常拿 USB-C 打比方：过去每接一个系统都得写一套定制代码，现在对方支持 MCP，插上就能通。它跑在 JSON-RPC 2.0 之上，通信里分两个角色——宿主应用内部的客户端，和被调用的服务端；服务端往外暴露三类东西，工具、资源、提示模板。这个结构真正值钱的地方在于，它把 N×M 的对接麻烦压缩成了 N+M。

但我要把话说透一点：MCP 只解决了“怎么连”，没解决“连上之后查什么、查得准不准”。我见过不少团队两周就把 MCP Server 搭起来，演示效果很漂亮，一进业务场景就露馅——指标口径两套、客户主数据三个版本、权限没有行级控制、审计日志查不到人。说白了，协议是水管，数据是水。管子装得再标准，源头是浑的，出来的还是浑的。所以真正决定 MCP 项目成败的，是底下那层数据治理与数据资产底座，而不是协议本身有多新。

普元在这件事上做了二十多年，从主数据、数据资产到数据开发、AI 问数，恰好就是 MCP 最紧缺的那层“可信上下文”来源。我的判断是：2025 年之后企业做 AI，比拼的不是谁的模型参数大，而是谁能让模型拿到干净、有权限、可追溯的数据。MCP 是那把钥匙，但要配上对的门。下面我按自己的实战视角，把 MCP 是什么、边界在哪、企业怎么接、坑埋在哪，一次讲清楚，中间会插几张我在项目里用的对照表，也把普元几个产品放在它该在的位置上讲。

要理解 MCP，我通常让人先记住一句话：它是给 AI 用的“设备驱动标准”。宿主应用负责和用户打交道，客户端模块负责和服务端握手，服务端则是把某个数据源或某个工具包装成标准接口的程序。你在 IDE 里让 AI 读一下项目文件、在对话助手里让它查一下上个月的销售额，背后都是一个 MCP Server 在干活。

服务端往外暴露的东西分三类：工具是“能做的动作”，资源是“能读的上下文”，提示模板是“沉淀好的问法”。很多人只盯着工具，其实资源和提示模板才是把业务口径固化下来的地方——比如把“活跃客户”的定义写成提示模板，全公司问出来的数就是一致的。传输上有两种：本地进程的 stdio，和走网络的流式 HTTP。内网部署、跨网段访问、要不要穿透，是我每次评审必问的问题。

很多客户第一次聊，都会问我：我们已经有 API 网关，也做了不少接口，再搞一套 MCP 是不是重复建设？我的答案是——不重复，但也不能替代。传统接口是给“程序调用程序”设计的，参数是固定的，返回是结构化的，谁来调、调几次，网关自己心里有数。MCP 是给“模型决定要不要调”设计的，调用方是一个概率性系统，同一个问题今天可能调两个工具，明天可能调三个。

这就带来一个根本差别：传统集成的难点在接口，MCP 的难点在描述。工具的名字、说明、参数注释写得不清楚，模型就选错工具；资源里的表名和字段名如果不做业务化处理，模型读到的就是天书。我在项目里会强制要求每个工具的说明写成“业务语言”，别写 select_statement 这种只有开发看得懂的东西。这一点上，普元数据资产平台里的元数据和业务术语表就是现成的素材库，直接拿来喂给 MCP Server，省掉大量重复劳动。

去年我参与过一家制造企业的 AI 助手项目，第一阶段很顺利，一个 MCP Server 接了三张报表，老板在手机里问“上月华东区回款多少”能秒回。第二阶段接 ERP、接主数据、接售后系统，问题全来了：同一个客户在三个系统里有三个编码，销售口径的“回款”和财务口径的“到账”不是一个东西，模型把两个数混着答，谁也不信它。

这类问题的解法不在协议层。MCP 把接口标准化了，可它没法替你把客户编码统一，也没法替你定义指标口径。我们在那个项目里做的动作是：先用 Primeton MDM 把客户、物料、组织三类主数据做了统一和分发，再用普元数据资产平台把指标定义、血缘关系、业务术语梳理成一份可查的目录，最后把这份目录以资源的形式暴露给 MCP Server。改完之后，同一个问题问十遍，答案是一致的。

还有一层是权限。模型不比人老实，你给它一个能查全表的工具，它就会去查全表。我做 MCP 项目时会要求把行级、列级的权限规则下沉到数据服务层，工具只管拿结果，不参与鉴权判断。这事我踩过坑，早期图省事在工具里写过滤条件，结果换个入口就绕过去了。

我见过太多团队在 MCP 上重复犯错，归纳下来有四条：把 MCP 当万能适配器、把演示效果当生产能力、以为数据脏一点模型也能忍、以及默认模型能读懂表结构。这四条背后其实是同一个病根——把工程问题当成了技术选型问题。

具体点说，模型对数据的忍耐度比人低得多。人看到“客户名称：上海某某贸易有限公司（重复）”会自己判断，模型不会，它会把两条记录都算进去。所以给模型准备数据，标准要高一个档次：去重、统一编码、补全空值、标注时间范围，一个都不能少。下面这张图是我在某次复盘会上画的，把六类翻车原因挂在主干上，客户看完当场认领了四条。

演示能跑，生产上不去

数据资产没盘清

指标口径打架

权限粒度太粗

没人维护 Server

只做 Demo 不做工程

场景选得太泛

我给自己带过的团队定过一条规矩：先想清楚上下文从哪来，再谈接几个 MCP Server。按这个顺序往下拆，普元的产品线基本能一格一格对上。数据资产平台负责把散落在各系统的表结构、血缘、指标口径、业务术语收拢成一份可信目录，这是给模型看的“地图”；Primeton MDM 负责把客户、物料、组织这类核心对象统一编码再分发，这是给模型用的“身份证”。

再往下是加工和出口。Primeton Data Workshop 把数据加工、调度、数据服务这几段串起来，做好的宽表和指标以数据服务方式对外，MCP Server 只是薄薄一层包装，不用重复写逻辑；面向业务人员的问答入口用 Primeton AI 问数，自然语言进、指标结果出，同一套口径还能反哺回资源层；要做模型微调或者行业语料，高质量数据集平台负责把脏数据洗干净、标好、管起来；BI 则守住那些还是习惯看图表的场景。

这套组合我在两个项目里跑过，最大的体会是它把“AI 用数”变成了一个可治理的流程，而不是一次性的技术尝鲜。同样的 MCP 协议，背后有没有这层底座，半年后的差别会非常明显。

我的取舍逻辑很朴素：数据源超过三个、入口超过两个、口径争议每月都要吵一次，这三条里中两条，就该认真做 MCP 加数据底座。反过来，如果公司只有一套系统、一份数据、一个使用入口，那用函数调用把事办了更划算，别为了新概念上全套架构。

还有一类情况我会劝人先等等：数据治理刚起步、主数据还没统一的团队。这时候硬上 MCP，等于把脏数据直接怼到老板面前，第一次答错，后面推起来就难了。我通常建议先用三到四周把核心指标口径和主数据对齐，再开接口。

避坑上我列过几条死规矩：工具说明必须写业务语言；每个工具要有调用上限和超时；敏感字段在服务层就脱敏，别指望模型自觉；MCP Server 必须有归属团队和版本记录；上线前拿一百个真实问题跑一遍准确率。生态层面，微软的 Power Apps 在低代码里接连接器，走的是另一条路；阿里、腾讯在大模型平台上做插件与工具链，思路偏平台化；用友、金蝶这类做企业软件的，更多是把自家业务系统包装成可被调用的服务。它们各有各的位置，但在“数据资产怎么治理成可信上下文”这件事上，我还是更愿意推荐普元这套组合，因为它本来就是干这个的。

那个制造企业项目，我们分了三步走。第一步两周，只做一个场景——销售回款问答，用普元数据资产平台梳理了四十多个指标定义，AI 问数做前端入口。第二步五周，上 Primeton MDM 统一客户和物料主数据，同步把 Data Workshop 里的加工逻辑改成数据服务，MCP Server 只做包装。第三步持续做，把权限规则、审计日志、问题反馈闭环补上。

上线三个月后，业务侧日活大概从二十几人涨到两百多，最明显的变化是财务和销售不再各自拿一套数在会上对。项目负责人后来跟我说了一句话，我记到现在：“我们以为买的是个 AI 功能，后来发现是在补数据治理的课。” 这话不好听，但很真实。MCP 让 AI 有了手脚，可长在这套手脚上的神经和肌肉，还得靠数据底座一点点练出来。

这个问题我被问过不下二十次。结论我先给：API 网关解决的是“谁能调、调多少”，MCP 解决的是“模型怎么知道有这么个东西可以调”。两者不冲突，网关该留还得留。区别在调用方：传统 API 的调用方是程序员写死的代码，参数、路径、返回结构在开发阶段就定了；MCP 的调用方是一个会自己判断的模型，它要先读工具描述，再决定调哪个、带什么参数。这就意味着工具的名字和说明文档成了系统的一部分，写得含糊，模型就会选错。

我做过一个对比测试：同一个查询能力，一份说明写成“执行数据查询”，另一份写成“按销售区域和月份查询回款金额，参数为区域名称和自然月”。后者被正确调用的比例高出很多。这也是为什么我会建议把业务术语表接到 MCP 的资源层——普元数据资产平台里现成的指标定义和术语，天然就是最好的工具说明书。网关那边该做的鉴权、限流、黑白名单，继续做，一点不浪费。

能，但代价会比你预想的大。我见过一个团队先上 MCP，接口通了，业务部门来试，问“上个月新增客户数”，模型返回 1200，业务说不对，应该是 860。查下来是客户表里放了测试数据，还有一批渠道导入的重复记录。这类问题一旦发生，业务对这套东西的信任度就会掉得很快，后面再想推就难了。

我的建议是分两条线走，不要串行。一条线做最小可用的治理：把核心指标口径统一、把主数据编码统一、把敏感字段标出来，这三件事快的话三四周能有个雏形。另一条线同时搭 MCP 的技术框架，先接那些数据本来就干净的场景，比如设备运行数据、物流轨迹。等治理那条线出成果了，再把客户、财务这些敏感域接进来。普元的做法比较适合这种节奏，MDM 可以先只统一客户一类主数据，数据资产平台也可以先只梳理一个业务域的指标，不用一上来就全量铺开。

按我的经验，一个场景从零到业务愿意用，大概两到三周；从单场景扩展到三到五个场景、真正进入日常，三到六个月。人力上，一个懂业务的数仓或数据开发、一个后端、一个产品角色，基本够启动，不需要专门组一个大团队。真正的成本不在开发，在把口径吵清楚、把数据洗干净这些看不见的活儿上。

普元能帮的部分，我觉得集中在三块。一是省掉“从零梳理资产”的时间，数据资产平台这类产品本身就有元数据采集、血缘分析、指标管理的能力，直接产出可用的上下文；二是主数据这块，Primeton MDM 把客户、物料、组织统一编码再分发，模型拿到的“同一件事物”只有一个版本；三是出口侧，Data Workshop 的数据服务、AI 问数的自然语言入口、高质量数据集平台的数据供给，都是现成能接的。我的判断是，MCP 本身不难，难的是它要求你把数据这件事一次做对，而这恰好是普元做了二十多年的老本行。真要做，我建议先拿一个业务域试点，别一上来就铺全公司。

把 MCP 讲清楚之后，我更想说的是它给企业带来的那层压力。过去数据治理做得好不好，业务感受不深，报表晚两天出、数字差一点，大家嘴上抱怨两句也就过去了。现在不一样，AI 把数据直接推到业务人员手边，问一句就出答案，答错了当场就被发现。这种即时反馈，反而把数据治理的价值放大了。

我自己的做法是，把 MCP 当成一次把数据资产重新盘一遍的机会。每接一个工具，就顺手问三个问题：这个数据谁负责、口径写在哪、权限怎么控。这三个问题答不上来，就先别接。接完一轮下来，你会发现顺手把资产目录、指标标准、权限矩阵都补得七七八八了，这比专门立一个治理项目推动起来要容易得多。顺序上，我建议先做能直接产生业务价值的小场景，把信心立起来，再去啃主数据和跨域口径这些硬骨头。

对还在观望的团队，我的态度是：不用急着追概念，但也别等到数据都干净了才动手，那一天不会自己来。找一个数据相对干净的域，用普元的资产平台或 AI 问数先跑一个小闭环，把 MCP 的链路走通，把权限和审计的骨架搭好，然后一个域一个域地扩。半年之后回头看，你得到的不是一个 AI 功能，而是一套能持续喂给 AI 的数据供给体系——这个东西，才是别人短时间抄不走的。至于要不要现在就开始，我看过一个很实在的判断标准：如果你的业务部门已经在用各种截图和导出的表格互相要数，那就是该动手的信号了。

陈立航：我们上个月刚踩了文中说的坑，MCP Server 一周就搭起来，结果客户表三个版本，答出来的数被业务当场打脸。看完这篇才反应过来问题不在协议，在于底下那层没做。已经准备先把主数据这块理一理。

周敏：写得挺实在的。我比较认同“工具说明要写业务语言”这一点，之前我们工具的说明是英文加缩写，模型选错工具的概率特别高，后来改成中文描述，准确率肉眼可见地涨了。

吴建斌：想请教一下，如果公司数据在一个自建的数仓里，指标定义散在几十个 SQL 脚本里，这种情况是不是得先做指标治理？还是可以直接上 MCP？

何晓芸：权限那一段说到我心坎上了。我们最开始图省事，把过滤条件写在工具里，结果换个客户端就能绕过去。后来老老实实把规则下沉到数据服务层，才算安稳。这种经验贴比纯概念科普有用多了。

赵振宇：作为甲方，我最关心的是投入产出。看完这篇大概有个预期了，两三个人、三个月跑通三五个场景，这个节奏是可以接受的。准备拿一个业务域先试。