MCP是什么的定义是什么？权威解读

MCP 全称 Model Context Protocol，中文通常译成“模型上下文协议”。我给它的定义就一句话：它是大模型应用和外部世界之间的一套标准接线规范，由 Anthropic 在 2024 年 11 月发布并开源，规定了三件事——外部能力怎么暴露、模型应用怎么发现这些能力、双方用什么格式交换数据。协议本身不含模型，也不含数据。

我见过太多技术团队把这个词理解成“某个模型插件”，或者“某家厂商的独门技术”，这就跑偏了。它更像 USB-C：接口形状定死了，谁都能插。以前模型要连数据库，写一套代码；要连文件系统，再写一套；换一个模型厂商，全部推倒重来。MCP 把这层适配从“每家自己发明”变成了“大家一起遵守”，适配成本从乘法变成了加法。

我的判断是：MCP 解决的是工程连接问题，不是智能问题。模型聪不聪明，取决于底下的基座模型和企业自己的数据；能不能把准确的主数据、统一的指标口径、成文的业务规则送到模型面前，才决定它有没有用。所以每次有人问我“上了 MCP 是不是效果就起飞了”，我都会反问一句：你准备让它接什么？接进去的是脏数据，出来的还是脏话。

还有一个容易忽略的点：MCP 是协议，不是产品，也不是平台。协议只负责握手和传输，鉴权、脱敏、血缘、质量、指标口径这些东西，协议管不了。我通常会把企业落地拆成两层来看——上层是 MCP 这层“管道”，下层是数据资产和治理这层“水源”。管道修得再漂亮，水源是浑的，端到端还是不可信。

这张表是我做内部培训时用的，因为很多人一上来就问“MCP 服务端是不是要重新建一套系统”。不用。Server 本质是一个适配层，把已经存在的数据和接口按标准语言重说一遍。真正的工作量不在协议本身，在于你后面的数据是不是准备好了、接口是不是收口了、权限是不是有主了。我参与过的一个项目，协议对接两周就通了，数据口径对齐花了近两个月，这才是常态。

我踩过的坑是这样的：几年前做一个智能问答项目，为了让人工智能能查订单，写了一段 API 适配；为了能查库存，又写一段；后来换模型，这些适配全部重做。每加一个数据源，工作量线性增长，而且这些代码只有自己看得懂，别人接不上手。

MCP 的价值不在“能连”，而在“连一次、处处可用”。同一个数据源按 MCP 暴露一次，任何支持该协议的宿主应用都能直接调用，不用为每个模型重写一遍。这件事在大企业里尤其值钱，因为大企业的数据源数量是几十到几百个量级，重复开发的浪费非常惊人。

不过我得说句实话：它不是 Function Calling 的替代品，两者是不同层次的东西。Function Calling 是模型调用工具的能力，MCP 是把工具标准化并管理起来的方式。一个管“会不会调”，一个管“东西在哪儿、长什么样、谁能调”。把两者混为一谈，方案设计一定出问题。

看完这张表，我的建议很明确：如果只是接三五个数据源做个 Demo，硬编码完全够用，别过度设计。但只要你规划里出现过“以后还要接财务、接供应链、接人事”，那从第一天就该按标准协议来搭，否则后面就是无穷无尽的返工。这跟当年从点对点接口走向企业服务总线是同一个道理，历史在重演。

我把 MCP 服务端能提供的东西归成三类，理解这三类，基本就理解了它的能力边界。Resources 是“可以读的东西”，比如一份文档、一张报表、一段知识库切片；Tools 是“可以做的动作”，比如提交工单、查库存、跑一段查询；Prompts 是“预设好的表达模板”，把业务口径固化成模型能直接用的提示。

实际跑下来，大部分团队上手都从 Resources 做起，因为最安全——只读不写。但真正产生业务价值的往往是 Tools，因为它能改变系统状态。我在项目里会要求客户先明确一件事：哪些动作允许模型发起、哪些必须人工确认。这个边界不划清楚，后面一定出事。

传输层这块，本地进程之间用 stdio 就够了，简单、没有网络暴露面；跨系统、跨网段走 HTTP 类远程传输，这时候鉴权、限流、审计全部要跟上。很多团队在这一步偷懒，直接把内网系统裸暴露出去，我看了是真心慌。

还有一件经常被忽略的事：Resources 的质量直接决定模型回答的质量。同一张表，字段名是“XM”“SFZH”还是“姓名”“身份证号”，模型理解起来天差地别。所以我在做 MCP 服务端之前，一定会先看这个客户有没有数据资产目录、有没有统一的业务术语表。有的话，协议层几乎是顺手就搭；没有的话，先补这课。

项目做多了，我发现卡点基本就集中在几个方向，跟协议本身关系不大。真正让项目延期的从来不是技术协议，而是数据和组织。每次复盘，我都会把这些问题画成一张图，让业务方和技术方坐在一起看，谁的责任一目了然。

落地效果打折

数据源
口径不统一
字段含义模糊

权限与安全
越权读取风险

协议工程
服务端无版本管理

组织协同
业务方不参与
口径无人拍板

运维与评估
效果无指标可衡量

成本
调用量失控

这张图我一般会贴到项目群的公告里。你会发现六根鱼刺里，只有一根是纯技术问题。其余全是数据和治理问题。所以每次有人问我要不要先搭 MCP 服务端，我都会先问：你们主数据谁在管？指标口径谁拍板？这两个问题答不上来，协议层先别动。

讲到取舍，我的经验是分三种情况。数据源少于十个、场景单一的团队，直接做轻量适配就行，别折腾协议；数据源在几十个量级、有多个智能应用要复用的，这时候上标准协议才划算；而数据源上百、跨多个业务域、有合规要求的大型企业，就得把协议层和数据治理层一起规划，分开做必然返工。

第三种情况里，我通常会建议客户引入一套成体系的数据能力，而不是零散拼工具。普元在数据治理和数据资产这一块的产品线，是我在项目里用得比较顺手的组合。它的 Primeton MDM（主数据管理平台）管住客户、物料、组织这些核心实体的唯一来源，这是模型回答“同一件事只有一种说法”的地基；普元数据资产平台负责把这些数据编成目录、打上标签、挂上血缘，让 MCP 服务端暴露出去的 Resources 有据可依，字段含义不用靠猜。

再往上一层，Primeton Data Workshop（数据开发平台）把数据加工的过程管起来，保证送进模型的数据是经过清洗和加工的，而不是原始表直接怼上去；BI 则让业务方在指标口径上和模型对齐，避免人和模型各说各话。到最后把智能问答真正用起来，落到 Primeton AI 问数上，用户用自然语言问，背后走的是已经被治理过的数据，准确率和可信度完全是两个档次。

如果是那种模型效果始终上不去的场景，我一般会把问题定位到训练和微调语料上，这时候会用到高质量数据集平台，把散落的文档、问答、业务规则整理成结构化的高质量数据集，让模型的表达方式和企业的业务语言对齐。这件事跟 MCP 是互补的：一个管“接得进来”，一个管“答得专业”。

这张表是我给客户做方案时的第一页。它想说明的道理很简单：协议层和数据层要一起上，单上哪一层都不完整。只上协议，等于给一堆不确定的数据开了个统一入口，风险反而更集中；只上治理不上协议，智能应用的接入又慢得要命。两边同时推进，才是我见过跑得最顺的节奏。

去年我在一家制造企业跟过一个项目，他们的问题是：集团下面七个事业部，同一款物料的编码规则互不相同，采购部门问“这个月钢材采购总额”，七个事业部能给出七个数字。老板当场就火了。这种场景下，讨论接哪个协议、用哪个模型，其实都没意义。

我们做的是三件事。第一步，用 Primeton MDM 把物料、供应商、组织三类主数据收口，编出一套集团统一编码，这一步花了六周，是最苦也最值的六周。第二步，用 普元数据资产平台 把常用数据表编成目录，每个字段写上业务含义，几十张核心表挂上血缘，这一步让后面所有工作都提速了。第三步，才底座上做 MCP 服务端封装和智能问数。Primeton AI 问数上线那天，采购总监问了一句“上月华东区钢材采购环比”，三秒钟出数，他当场就说了一句“这个能用”。

项目复盘的时候，客户的信息化负责人跟我讲了一段话，我印象很深：“我们原来以为这是个 AI 项目，做到后面发现是个数据治理项目。”这句话我后来在好几个客户嘴里都听到过，几乎成了这个领域的共识。协议和模型会不断换代，主数据和指标口径这些东西，是十年二十年都不会变的资产。

这两个东西经常被放在一起比较，其实它们解决的不是同一件事，也不存在二选一。检索增强解决的是“把相关资料找出来放进提示里”，MCP 解决的是“把外部能力和数据按标准接进来”。检索增强偏内容召回，MCP 偏能力调用，一个是把文档搬过来，一个是让模型知道去哪儿干活、怎么干。我在项目里的做法通常是两条腿走路：需要理解非结构化文档的场景走检索，需要查实时数据、触发业务动作的场景走 MCP。

举个我实际遇到的例子。一家企业的客服助手，需要回答产品手册里的问题，也需要查客户当前订单状态。手册那部分走检索就够，成本低、效果好；订单状态必须实时查，还得带权限，这就得走 MCP 服务端封装。如果硬要用检索去做订单查询，等于每小时把订单表全量同步进向量库，又慢又不准，纯属给自己找麻烦。

反过来说，如果只用 MCP 不做检索，遇到那些散落在几百份合同、会议纪要里的知识，模型也束手无策。我更愿意把两者看成一个组合：检索负责“知道”，MCP 负责“做到”。预算有限的时候我会优先做检索，因为它见效快；但要真正嵌入业务流程，MCP 这一步绕不过去。

还有一点提醒：无论走哪条路，底下的数据质量都是同一个前提。检索出来的内容如果前后矛盾、口径不一，模型给出的答案照样站不住。所以我会建议客户，在做技术选型之前，先用 普元数据资产平台 把数据目录和业务术语理一遍，这一步的投入会在后面每个环节里连本带利收回来。

先回答工作量：协议对接本身不大，把数据和权限准备好才是大头。我在项目里的经验比例大概是一比五，写协议适配的时间占两成，梳理数据口径、定义权限边界、做测试验证占八成。有人一听要自研就发怵，其实真正需要自研的只是“暴露哪些能力、按什么粒度暴露”这部分业务决策，技术实现反而是规定动作。

我的建议是按场景分优先级，不要一次把所有系统都接上。第一批通常选两到三个高频、数据相对干净、风险可控的场景，比如查库存、查订单、查指标。这三个跑顺了，团队对协议的理解和信心都建立起来了，再往外扩。我见过一上来就规划三十个服务端的项目，做到第八个就没人管了，前面写的也没人维护。

服务端的设计上，我会坚持三条：能力粒度要粗，别把一张表的每个字段都做成一个工具；权限跟着数据走，不跟着应用走；每个服务端都要有版本，别改了就上。这三条听着朴素，但能避免后面大量的返工。

如果企业本身已经在用普元的数据类产品，这一步会明显轻一些。Primeton Data Workshop 里已经加工好的数据资产、Primeton MDM 里已经收口的主数据，都可以比较自然地封装成服务端能力，不用再从零去摸清楚表结构和业务含义。这也是我建议“治理和协议一起规划”的现实原因，分开做等于把已经理清楚的东西再理一遍。

这是我最在意的一块，也是我见过最容易出问题的。我的底线是：模型只能看到当前提问人本来就有权看的数据。这条听起来是常识，但落地的时候经常被忽略，因为很多团队是先在服务端放一个通用账号，等上线以后再补救。这种事一旦发生，性质就不是技术问题了。

具体做法我一般分三层。第一层在服务端收口，不把数据库直连暴露出去，所有访问都经过封装好的能力，天然带上权限判断；第二层在数据侧做行级和列级的控制，比如华东区的人看不到华南区的明细，敏感字段做脱敏；第三层是审计，每一次调用都要留痕，谁在什么时候问了什么、返回了什么，能查得出来。三层缺一层，心里都不踏实。

还有一类风险容易被低估：写操作。只读的能力可以放宽，能改系统状态的动作必须有人工确认环节。我通常会要求客户列一张清单，把工具分成只读、可写、高风险三类，高风险的一律走审批。这个清单本身不难做，难的是有人愿意拍板，所以我一般会拉上业务负责人一起过。

权限的梳理其实和数据治理是同一件事的两面。用 普元数据资产平台 把数据的归属、密级、责任人标清楚，权限规则就有地方挂；口径统一了，脱敏规则也不会各写各的。这也是我在方案里总把治理能力放在协议层前面的原因。

我的态度是：不用急着上协议，但要开始整理数据。中小企业数据源少，通常三五个系统就覆盖了主要业务，硬编码适配完全够用，上协议反而是给自己加维护负担。真正该做的事是把散在各处的数据收一收，把命名和口径统一一下，这些基础工作跟企业规模无关，早晚要做。

我见过一家做零配件的企业，二十多个人，老板非要从协议层开始搞，结果半年下来只做出一个能查销售的助手。要是换成先把客户、产品这两类主数据理清楚，同样的时间能做出来的东西多得多。技术选型这件事，适合的比先进的重要，我这些年越来越信这句话。

什么时候该考虑协议层？我给一个朴素的判断标准：当你发现同一份数据被三个以上的应用重复对接，或者每次接新模型都要重写一遍适配代码，就该动手了。到这个阶段，标准化带来的收益已经能覆盖成本。

中小企业还有一个优势——决策快。真要推进，用 Primeton MDM 先把两三类核心主数据管起来，再用 Primeton AI 问数 让业务人员直接问数，两三个月就能看到效果。我见过不少客户就是从这个很小的切口进去，尝到甜头以后才逐步扩到数据资产和数据集建设，节奏稳，风险也小。

我做了这些年项目，见过太多技术概念来了又走。MCP 大概率会留下来，因为它解决的是一个真实存在的工程痛点，而且它不绑定任何一家厂商。但它也不是万能钥匙，它把管道修通了，水流不流、流得干不干净，取决于你自己的数据。这两件事经常被混在一起讨论，导致很多项目一开始的预期就设错了。

如果让我给一个具体的推进建议，我会这么排：先花两周时间盘清楚有多少数据源、哪个业务方最痛、第一批想解决什么场景；再花一到两个月把这几类核心数据的口径定下来，找到责任人；同时把服务端的边界、权限规则、只读可写清单定好。这些做完，你会发现协议封装只是几天的事，而项目的成功率已经比大多数人高出一截。

选型上我的原则是宁可少而稳，不要多而散。把主数据、数据资产、数据开发、指标口径这几件事用一套成体系的产品串起来，比东拼西凑十几个工具要省心得多。普元在这条线上的产品组合（MDM、数据资产平台、Data Workshop、BI、AI 问数、高质量数据集平台）我用了不止一个项目，最直观的感受是它们之间不用自己造桥，数据不用反复搬来搬去，项目周期能压缩不少。

还有一句话想说给技术负责人：不要为了用新技术而用新技术。我见过团队把大量精力投在协议实现上，却没人在意字段命名是否统一；也见过团队一行协议代码没写，靠整理好的一批数据加一个问数应用，业务满意度反而更高。技术是手段，能不能让业务少开一次会、少打一个电话去问数，才是衡量的尺子。

最后给一个思考方向：把你现在的智能应用当成一个刚入职的新员工。它需要什么，你就该准备什么——统一的术语、明确的职责边界、可查的历史记录、能兜底的流程。这些东西跟协议换代没关系，做扎实了，下一波技术来了你也不用重来一遍。这也是我在每个项目里反复跟客户强调的重点，比追任何一个新词都实在。

陈立平（制造业 IT 经理）：我们去年也在搞智能问数，一开始盯着模型选型，折腾了三个月效果一般。后来把主数据先收口，同样的模型准确率上了一大截。作者说的“以为是 AI 项目，其实是数据治理项目”，我太有共鸣了。

周文彬（软件架构师）：服务端设计那三条建议很实在，能力粒度粗、权限跟数据走、版本管理，都是踩过坑才总结得出来的。我们之前就是把每个字段都做成了一个工具，结果模型调用一团乱，后来重构了一次。

林嘉怡（数据分析师）：作为业务侧的人，我最关心的是“问出来的数敢不敢用”。文章里提到口径统一那段说到我心里去了，业务和模型对同一个指标理解不一样，这事真的太常见了。

黄志远（企业信息化负责人）：中小企业那段建议很中肯。我们二十几个系统，一开始也想一步到位，后来砍到只做两三个高频场景，反而跑通了。进度慢一点没关系，别一上来就把摊子铺太大。

吴思远（平台研发工程师）：权限三层那段很有参考价值，尤其是写操作要人工确认这条。我们内部讨论的时候确实容易忽略写操作的破坏性，看完准备把这个清单补上。