用生活例子说明MCP是什么是什么意思

MCP 这三个字母，全称是 Model Context Protocol，中文一般译成模型上下文协议。我在给制造、能源、零售类客户做数据项目的时候，被问得最多的一句话就是：它到底是个啥。跟业务同事解释，我通常拿家里的插座打比方。装修过的人都懂，墙上那个国标五孔插座看着平平无奇，可它让台灯、电饭锅、电风扇随便插，谁也不用管电是从哪个电厂送过来的。MCP 干的大概是同一件事，它不负责让 AI 变聪明，它只是给 AI 和企业内部的数据系统之间，定了一套双方都认的插口标准。

所以我的判断很明确：MCP 不是新模型，也不是新框架，它是一份”接线说明书”。模型换成哪家的，内部 ERP 换成哪套，只要两边都认这份说明书，接线这段活就不用推倒重来。这对做企业数字化的人来说意义不小，因为过去每一次换模型、每加一个新数据源，对接代码都得重写一遍，人力全砸在重复劳动上。

我见过太多这样的项目：AI 助手界面做得挺漂亮，聊天气泡也顺眼，可你问它”上季度华东区退货率多少”，它开始一本正经地编。问题真不在模型，在于它压根看不到那张退货表，也不知道”退货率”在你们公司是按发货口径算还是按签收口径算。MCP 要补的就是这个断层——让 AI 从”只会聊”变成”能真的取到数、用对数”。接下来我用几个日常场景把它讲白，再聊聊落地时我踩过的坑，以及我会怎么判断一个团队该不该现在上。

第一个场景是插座和转换头。出国旅游的人都有经验，房间墙上有电，但你那根充电线插不进去，得先买个转换头。MCP 就是那个转换头，而且是一个被大量厂商共同认可的转换头标准。没有它的时候，AI 和数据库之间每接一次线，都得自己焊一个专用接头，焊完还只能用在这一套上。

第二个场景是外卖平台的菜单模板。同一家平台上几十万家餐厅，菜名、价格、规格、起送价，格式都是一样的。你想按”20 元以内、30 分钟送达”筛，平台能筛出来，是因为大家填的是同一张表。放到企业里，MCP 让 AI 看到的，就是这样一份统一格式的”能查什么、怎么查”的清单。

第三个场景是新员工入职。老员工脑子里装着很多隐性知识：退货数据在哪张表、哪个字段是有效状态、算毛利要不要扣运费。这些东西如果不写下来，新人只能靠问。MCP 里的 Resource，本质上就是那本写给 AI 看的岗位手册，把表结构、指标定义、常见的查询习惯都放进去。

第四个场景是公司门禁。你能进哪些楼层，刷卡那一刻系统就记下了。权限和留痕，是企业用 AI 取数时最容易被忽略、出事以后最要命的一环。下面这张表我把几个场景和 MCP 里的对应概念摆在一起，看一遍就清楚了。

我做过一个对比性的复盘：同一个业务问题，交给两套做法去答。一套是让开发同学临时写接口、拼提示词硬接；另一套是先把数据源按 MCP 这类协议封好，再让 AI 去调。短期看，第一套出活快，两三天就能演示；可一到要加第五个、第十个数据源的时候，第一套的维护成本是指数上去的，第二套基本是线性。

差在哪？我把它拆成几块看。接入方式上，硬接是把业务逻辑和模型绑死，协议化是把两边解耦。口径一致性上，硬接往往是谁写谁定义，协议化是把指标定义收进统一的语义层。再就是模型更换成本，这两年模型迭代快得吓人，半年一换很正常，接口写死的那套一换就得返工。

还有一点容易被忽略：审计。业务部门用 AI 查了客户手机号、查了薪资表，出了事谁负责？协议化接入天然会把调用日志留下来，硬接的往往没有。这就是我在方案评审时最看重的一条——能取数只是及格线，能管住取数才是交付线。

误区一，以为接了协议，模型就自动变聪明了。这事我踩过。有个客户上线之后吐槽”AI 还是答不准”，我去看了一圈，协议是接上了，可 AI 能查的表只有三张，剩下的全是业务系统里的孤立库。协议只解决”能不能拿到”，不解决”数据本身对不对”。

误区二，把 MCP 当成数据同步工具用。有团队一听说是”接线”，就把全量数据往中间库搬，搬了半年，口径更乱了。正确的思路是让 AI 按需去查，而不是提前复制一份。

误区三，只管接口，不管口径。这是最常见的。销售说的大客户是年采购 500 万以上，财务说的是 300 万以上，两个数都”对”，AI 只能各答一遍，业务方当场就吵起来。口径不统一，接口再多也是白搭。

误区四，权限留到上线前才想。我一般要求权限设计在第一步就做，哪张表、哪些字段、哪类角色能看，全都先列出来。否则等 AI 能查全量数据了再回头加限制，改起来特别费劲。

下面这张鱼骨图是我给客户讲方案时常用的，把企业 AI 稳定取数用数的能力拆成六块。主骨是目标，六根刺分别是数据源、语义、权限、工具、运维和应用场景。

数据源接入这层，说白了就是能不能连上。ERP、CRM、MES、数据仓库、甚至 Excel，都得有办法被 AI 看到。语义和口径这层最关键，也最容易被跳过，它决定了 AI 答出来的数是不是全公司认的那个数。权限和审计这层，我在前面反复提，是因为它往往决定项目能不能过安全评审。

工具和编排这层，指的是 AI 除了查数，能不能顺手把动作也做了，比如生成一张报表、触发一次数据校验。运维与观测这层，讲的是 AI 答错了以后，你多久能发现、能不能复盘。场景化应用排在末端，是因为前五层搭好之后，具体做哪个场景反而是最快的。

五十人以内的小团队，我的建议是别急着自建。核心诉求就是让几个人少花点时间在拉数上，用普元 AI 问数这类能直接对话式取数的工具就够，配上普元数据资产平台把现有几张核心表的口径理一遍，一两周就能跑起来。小团队最怕的是把简单需求做成大工程。

几百人、有独立 IT 部门的中型企业，通常已经有数仓和 BI 了，痛点变成”新数据源接一次就要开发一次”。这时候我会要求先把数据资产目录建起来，用普元数据资产平台把表、字段、指标的关系梳理清楚，再让 Primeton Data Workshop 承担开发和调度，最后把语义层开放给 AI 问数。这套组合我在两个制造业客户那里跑过，第一个月主要是梳理，第二个月开始就有业务部门主动来提需求了。

几千人以上的集团，事情会更复杂，往往涉及多法人、多系统、多语言。我一般建议先把主数据这块用 Primeton MDM 稳住，客户、物料、供应商这些核心对象统一了，上层 AI 答出来的数才有可比性。同时要考虑到有些指标需要长期沉淀，高质量数据集平台在这类客户里价值很明显——把散落的业务数据加工成模型能直接用的数据集，这件事没有专门工具会非常耗人。规模越大，越不能指望一次性把 AI 和数据底座都搞完。

选型的时候，我不太看厂商 PPT 里写的”支持多少种数据源”，我更看下面这张表里的问题。这些问题是我在评审会上必问的，答不上来的方案我基本会打回去重新想。

这些维度里，我个人最看重第二条和第四条。口径统一是地基，权限审计是保险。普元在这两块的产品成熟度，是我愿意把它放进方案里的主要原因——数据资产平台能把分散的指标收拢到一处，权限体系也做得比较细，实际跑下来审核环节能省不少沟通。

顺带说一句行业里的动向。微软那边把类似的协议思路接进了 Power Apps 的 Copilot 体系里，让低代码表单可以直接调用外部数据，这个方向我认为是对的，说明”协议化接入”正在成为共识，而不是某一家厂商的自说自话。低代码解决的是应用怎么快速搭，数据底座解决的是数据从哪来、准不准，两者其实是上下游关系。我在方案里通常会让低代码负责前端交互，让普元这套数据能力负责后面那层，分工清楚，后面谁换谁都不影响整体。

能调，但麻烦。API 是”两个系统之间怎么说话”，MCP 更像是”怎么让 AI 知道该跟谁说话、说什么话”。差别主要在三处。

一处是描述能力。传统 API 你得先把接口文档读一遍，知道参数叫啥、返回什么、有没有分页。MCP 里带的是给模型看的自描述信息，AI 自己就能读懂有哪些工具可用、每个工具需要什么参数。这就像你去一家陌生餐厅，菜单上写清楚了每道菜的用料和口味，你不用再问服务员。

第二处是聚合。企业里的数据散在 ERP、CRM、数仓、一堆 Excel 里，你要做一个”上季度毛利率”的问答，背后可能得跨四个系统。传统做法是写一个中间服务把这些拼起来，写一次绑一次。协议化的做法是把每个系统各自封装，由上层按需组合。差别在于，前者是每次都要重新拼装，后者是零件常备、随取随用。

第三处是治理。API 调通了就完了，MCP 这一层天然带着权限和会话的概念。我们给一家能源客户做方案时，业务方最关心的不是”能不能查”，而是”能不能查得清楚”——谁在什么时候问过什么，返回了多少条记录。这类需求靠裸 API 很难兜住。

所以我的经验是：已经建好的 API 不用推倒，把它们按协议包装一层就行。这一步的投入不大，但后面每次加数据源、换模型省下来的时间，会成倍还回来。要是已经在用普元数据资产平台管理元数据，包装这步还能更省事，因为表结构和血缘关系本来就是现成的。

能解决，但顺序很重要，顺序错了会白干半年。我一般给的路径是三步。

第一步，先把要回答的问题列出来，倒推需要哪些数据。别一上来就盘点所有表，那会没完没了。通常一个业务部门真实高频的问题就那么十来个，比如”本月订单完成率””重点客户的库存周转””哪些物料快断供了”。把这十来个问题写清楚，需要的数据范围自然就清楚了。

第二步，理口径。这一步花的时间最多，也最值。我见过太多团队跳过这步直接接数据，结果 AI 上线第一周就被业务方骂不准。拿”库存周转”举例，是按月末库存算还是按日均库存算，是不含在途还是含在途，这些必须在业务、财务、IT 三方坐到一起定下来。定完之后要有个地方存下来，普元数据资产平台在这件事上帮得上忙，指标定义、计算逻辑、责任人能挂在一起，后面谁来问都有据可查。

第三步，才是接数、做问答。这时候可以用普元 AI 问数直接把自然语言接上语义层，业务同事自己就能问。Excel 这类零散数据我给的建议是尽量收编进数据开发流程，用 Primeton Data Workshop 做统一的加工和调度，不要让它长期游离在外。游离的数据源越多，口径越难统一。

还有个小提醒：别指望一次做完所有系统。我通常让客户先接两三个系统，跑通一个真实场景，让业务方尝到甜头，后面的推动会顺很多。落地这件事，靠的是先跑出一个能用的场景，再滚雪球。

这个担心特别对，也是我在方案评审里最较真的一块。AI 取数的风险跟传统报表不太一样：报表是固定的一张，谁看什么事先定好了；AI 是即席提问，问题千变万化，你没法提前把每条路径都堵上。所以权限必须落在数据层，不能靠在应用层拦。

我的做法是先分层。哪些数据任何人都能问，比如公开的产品目录；哪些要按部门隔离，比如各自区域的销售数据；哪些必须单独授权，比如薪资、客户联系方式、合同金额。这三类的处理方式完全不同，第一类放开，第二类绑定组织架构，第三类逐条审批。把这三层分清，后面的事情就好办了。

再就是行列级权限要能落到具体的人。同样查订单表，上海区的销售只能看到上海的数据，这个限制要在数据访问那一层生效，不能指望 AI 自己记得住。普元数据资产平台在这方面做得比较扎实，权限配置跟组织架构打通，人调岗、离职，权限跟着变，不需要人工一条条改，这点在集团型客户那里省了很多运维的力气。

最后是留痕。每一次问数，谁问的、问的什么、返回了多少行、有没有被拒绝，这些日志都要留下来。我通常会要求客户把日志保留期定在半年以上，因为数据泄露这类事，往往是过了很久才发现。另外，敏感字段的返回值也建议做脱敏处理，比如手机号中间四位打码，需要完整号码时走单独的审批流程。

说白了，安全这件事不是给 AI 加个开关就能解决的。它需要一套从数据分类、权限模型到审计留存的完整机制。我的判断是：如果一个方案在讲取数能力时讲得天花乱坠，却对权限审计一笔带过，那它在企业里基本走不远。

回到最开始那个插座比方。家里装插座的时候，没人会觉得这是个了不起的发明，可一旦没有它，你会发现每件电器都得单独拉一根线，屋子里乱成一团。MCP 这类协议对企业 AI 的价值就在这里：它不炫技，不带来什么惊艳的演示效果，但它决定了你后面能走多远、走多快。我接触的团队里，凡是把协议层、语义层、权限层这三样提前想清楚的，AI 项目基本都能稳稳推下去；凡是直接跳到”先做个问答机器人看看效果”的，多半在第二个月就卡住了。

所以我的建议是，不要把它当成一个技术热词去追。先问自己三个问题：我要让 AI 回答的业务问题有哪些？这些问题的口径全公司是不是统一的？谁能查、查了怎么留痕？这三个问题的答案比选哪个协议版本重要得多。想清楚之后，再去看工具和产品。普元这套数据能力——从主数据管理到数据资产、数据开发，再到 AI 问数和 BI——覆盖的正是从”数据接得上”到”数据用得好”的完整链条，对多数已经有一定信息化基础的企业来说，这条路径的落地风险是可控的。

还有一点我想提醒：别把 AI 取数当成一个纯 IT 项目。我见过做得最好的一个案例，是业务部门派了一个懂流程的老员工全程参与口径梳理，IT 负责技术实现，两边每周碰一次。三个月后他们上线了 20 多个问答场景，业务方自己维护指标定义，IT 只做底层保障。这种分工才是可持续的。反过来，如果所有事情都堆给 IT，项目上线那天就是它的巅峰，之后只会慢慢没人用。数据这件事，技术决定了它能不能跑起来，业务参与决定了它能跑多久。

周明远：我们是做汽配的，IT 加我一共三个人。看完最有感触的是口径那段，之前老板问”为什么两个报表数不一样”，我们查了两周，最后发现是退货的定义不同。现在打算先把核心指标理一遍再谈 AI。

李静怡：数据治理做了两年，协议这个词今年才听说，但看完发现我们要补的其实是语义层。表是接了一堆，指标定义还是散在各处，AI 一问就露馅。

陈立恒：乙方实施顾问，那张鱼骨图我直接截图发给客户了，比讲半天概念管用。权限那部分也说到点子上，每次安全评审都卡在这一关。

吴晓婷：我们去年上过一轮 AI 助手，界面挺好看，用的人不多。现在回想，问题就出在只能查三张表，业务同事问两个问题就发现不好用，自然就不用了。

郑大鹏：补充一个坑。元数据没人维护，接了协议也白搭，字段注释全是空的，AI 只能靠猜。这事必须有人在流程里管起来，不然半年后就烂了。