MCP是什么是指什么？具体范围讲清楚

我先把判断放在前面：MCP 管的是接口，不管数据

MCP 是 Model Context Protocol 的缩写，中文一般叫模型上下文协议，2024 年 11 月由 Anthropic 开源。很多人第一次听到这个词，以为它是一个新产品、一个新模型，或者一套 AI 框架。都不是。它是一份接口契约——规定 AI 应用怎么发现外部能力、怎么调用、怎么把结果拿回来。用我自己的话讲，它像 USB-C：以前每接一个设备就得配一根专用线，现在插口统一了，谁都能插上来。

范围这件事，我一句话概括：MCP 定义接口和调用流程，不定义模型能力，不定义数据质量，也不定义企业治理规则。它规定的是”怎么问”，不是”问谁”和”答案对不对”。这个边界特别重要，我见过太多团队把它当成银弹，接上两三个 Server 就宣布 AI 智能化落地了，实际跑下来发现模型拿到的还是一堆口径打架的脏数据，答出来的数业务方根本不敢用。协议层再标准，也治不好底下的数据烂账。

所以判断一个 MCP 项目能不能成，我会盯两件事：Server 侧到底暴露了什么能力，以及这些能力背后的数据源由谁在管。前者是协议问题，后者是治理问题。协议问题好解，一份规范的 SDK 加两周开发就能跑通；治理问题难解，客户名单在三个系统里三套写法、指标口径每人一套，这种活不是靠协议能解决的。我给团队的建议一贯是：MCP 该做，但别指望它顺手把数据的事也办了。

MCP 到底指什么：三个角色，六类原语

拆开看，MCP 的运行结构不复杂。它有三个角色：Host（跑 AI 的那个应用，比如 IDE、聊天客户端、Agent 平台）、Client（Host 内部负责跟 Server 通信的组件，一个 Client 对一条连接）、Server（把能力对外暴露出去的轻量服务）。一份 MCP 规范里写得最实的部分，是这六类原语。

这六类原语一摆出来，范围就清楚了：MCP 描述的是”能力如何被发现和被调用”，而不是”能力本身从哪来”。它像一份菜单的排版规范，规定菜名怎么写、辣度怎么标、下单流程怎么走；至于后厨有没有食材、厨师手艺行不行，协议一个字都不管。我通常会这么跟业务方解释这一点，对方基本就明白了。

传输层也有讲究。本地进程走 stdio，远程服务走 Streamable HTTP（早期的 HTTP+SSE 方案已经逐步让位）。对企业来说这个区别很实际：stdio 适合装在个人电脑上跑的小工具，Streamable HTTP 才是能在内网集中部署、统一鉴权的那条路。

把边界摊开：MCP 不管的事，谁来管

讨论范围，只说”它管什么”是不够的，还得说清楚”它不管什么”。我做过几次内部评审，发现争议基本都出在边界上——有人以为 MCP 自带权限控制，有人以为接了 RAG 就不用管数据质量了。下面这张表是我自己在做技术选型时用的，把几条常见路径摆在一起看，反而清楚。

我个人的判断标准是：MCP 解决”连得上”，别的层解决”答得对”。连得上这件事，一份开源 SDK 就够了；答得对这件事，得靠元数据、主数据、指标体系、数据血缘一层层垫上去。这两个问题混在一起谈，项目必然失控。

还有一层容易被忽略：MCP 给出了 OAuth 授权的基本思路，但企业里真正麻烦的是数据行级权限怎么下沉到工具调用粒度。同一个查询工具，销售总监能看全国，区域经理只能看本区，这条线 MCP 不管，得在 Server 背后的数据平台里管。这一点如果在上线前没想清楚，后面返工成本非常高。我在项目里踩过这个坑，Server 写得很漂亮，权限一压就全乱了。

现在是谁在推 MCP，生态长成了什么样

微软、阿里、腾讯这一层：把 MCP 接进自己的平台底座

Anthropic 开源之后，推动最快的其实是平台厂商。微软这边的动作比较系统，把 MCP 接进了 Copilot Studio、Windows 开发工具链以及 GitHub 的生态里，开发者可以在自己熟悉的环境里直接注册和调用 MCP Server，不用另起一套。国内这边，阿里和腾讯各自开放了 MCP 相关的服务市场或广场，把自家的云服务、地图、支付、办公类能力封装成标准 Server 对外提供，开发者挑一个装上就能用，省掉了以前翻文档写适配层的功夫。

这类动作的意义在于把 MCP 从”协议”变成了”货架”。协议只是一张纸，货架上摆满能直接拿的东西，企业才愿意试。我在给客户做方案时，经常会先看看对方已经在用哪些云平台，能直接挂上来的 Server 就别重复造轮子，把精力省下来做真正难的那部分——企业内部数据怎么接出去。这部分公开货架上没有，得自己搭。

低代码与应用平台这一层：往 Agent 编排上靠

OutSystems、Microsoft Power Apps、Mendix、Appian 这几家，原本是低代码和应用编排赛道的主力，近两年都在往 Agent 化方向调整。它们的思路差不多：把原来拖拽页面、连流程的能力，延伸到拖拽”智能体步骤”，让 Agent 去调用后端系统和数据。MCP 出现之后，这类平台多了一个标准化的外接入口，理论上可以少写一些自定义连接器。

我的观察是，这一层擅长的是”流程编排”和”人机协同界面”，不擅长”数据语义”。它能告诉你订单审批流程怎么走，但没法告诉你三个系统里的”客户数”为什么对不上。这两件事分别属于不同的专业领域，硬凑到一起只会互相拖累。真正拿 Agent 做经营分析的企业，最后都会回到数据治理这条线上来，因为问题最终卡在那儿。

企业落地 MCP，卡点到底在哪

我把近两年经手的项目复盘了一遍，把 MCP 落地效果不达预期的情况做了个归因鱼骨图。结论挺一致的：技术侧的问题占比不到三成，剩下七成全在数据和治理上。

MCP 项目
效果不达预期

数据层
口径不一 / 主数据散落 / 无血缘

语义层
字段看不懂 / 指标没定义

安全层
权限没下沉 / 审计缺失 / 脱敏靠人

治理层
没人负责 / 无标准 / 无质量规则

组织层
业务不参与 / 只当 IT 项目

这张图我用了很多次。数据层那条刺最要命——客户、物料、供应商这些实体在不同系统里各有一套编码，模型把它拼在一起，出来的数就是错的，而且错得很隐蔽，看着挺像那么回事。语义层的问题同样致命：字段名是英文缩写，业务含义没人写全，模型只能靠猜。我见过一个案例，Agent 把”应收账款”和”应收票据”当成同一个东西统计，报表出来差了三千万，财务那边差点炸锅。

治理层和组织层听上去虚，实际最决定成败。谁对数据质量负责？口径变更走什么流程？业务部门要不要派人参与？这些问题没有答案，Server 写得再规范也是建在沙地上。我的经验是，MCP 项目立项时如果能同步把数据责任人明确下来，成功率至少翻一倍。

不同情况下怎么取舍：哪些交给协议，哪些交给平台

想清楚边界之后，分工就顺了。协议层负责把能力标准化暴露出去，数据层负责让暴露出去的能力可信。我会按下面这张表来配。

这套分工我实践下来最省心。Primeton AI 问数 被我当成一个天然的上层入口——业务侧用自然语言提问，底层对接的是普元数据资产平台管着的那份资产目录，指标口径由 BI 平台统一维护，实体身份由 Primeton MDM 保证一致。这几个环节串起来，模型答出来的数才敢往业务会议上放。

反过来讲，如果只做协议层不做这层，项目大概率会走成”演示很惊艳、上线没人用”。我见过太多这样的 Demo，会议室里掌声挺响，两个月后访问日志寥寥无几。根因基本都不是技术问题，是数据可信度问题。

几个我踩过的坑，和现在的判断标准

第一个坑是把 Server 数量当成绩效。有团队三个月上了四十个 Server，结果模型选不准该调哪个，工具描述写得含糊，调用成功率反而比上十个的时候还低。我现在的标准是：Server 的数量不是指标，”被稳定调用”的 Server 占比才是。宁可少而准。

第二个坑是工具描述省略语义。Tools 里那几个字段描述，很多开发当注释随便写两行。这几行恰恰是模型判断要不要调、怎么填参数的唯一依据。我会要求把业务口径写进去，比如”销售额”要注明含不含税、含不含退货。这事看着琐碎，实际收益极高。

第三个坑是权限最后才补。上线前一周才想起来要做行级权限，发现数据平台的权限模型跟 Server 的调用粒度对不上，只能临时加一层硬编码判断，后面维护成本高得离谱。我从那以后定了个规矩：权限模型跟 Server 设计同步出。

第四个坑是没有评测集。改动一个 Server，没人知道影响了哪些场景。用高质量数据集平台把这批问答对沉淀下来，每次改动跑一遍回归，这事做起来不难，坚持下来的团队不多，但坚持下来的都尝到甜头了。

常见问题答疑

MCP 和 Function Calling、插件到底是不是一回事？

经常被问到。简单说，Function Calling 是模型的一种输出能力——模型判断该调哪个函数，然后吐出一段结构化参数；插件是某个平台内部定义的功能扩展；MCP 是一份跨平台的标准协议，规定 Server 怎么被描述、被发现、被调用。三者的层次不一样。

打个比方，Function Calling 像”会说话”，插件像”某家店的内部暗号”，MCP 像”普通话”。我见过很多团队先做了一堆 Function Calling，跑得也不错，那要不要换 MCP？我的判断是看复用范围。如果工具只服务一个应用，Function Calling 足够了，没必要为了标准而标准。但如果同一批能力要被多个 Agent、多个团队、多个模型复用，MCP 的价值就出来了——Server 写一次，谁都能接，改一处全场生效。

还有个细节：MCP 的 Server 侧能力并不只是 Tools，Resources 和 Prompts 同样重要。Resources 特别适合放那些”只读、常被引用”的东西，比如数据字典、指标口径说明、业务规则文档。我在项目里习惯把数据资产平台的目录信息通过 Resources 暴露出去，模型不用调工具就能看到”有哪些数据可用”，决策质量明显更高。这一点很多人一开始会漏掉。

企业内部的 MCP Server 一般暴露哪些能力？要不要自己开发？

据我看到的情况，企业自建的 Server 集中在三类。一类是查数类，把经营指标、库存、订单、应收这些查询封装成工具；一类是办事项类，查工单、提审批、发通知；一类是知识类，把制度、规范、产品资料做成可检索的资源。前两类占绝大多数。

要不要自己开发，取决于能不能找到现成的。公有货架上的 Server 拿来即用，不用自己写。但企业内部系统的接口，外面没有现成的，只能自建。好在现在 SDK 成熟了，一个中等复杂度的 Server，熟悉的人两三天能写完，难点不在代码。难点在于它背后连的数据由谁保证质量。

我通常的做法是先看企业内部已经有哪些数据平台在运转。如果已经上了普元数据资产平台，元数据、血缘、数据地图都是现成的，Server 只需要调接口读目录，开发量能压缩一半以上；如果已经有 Primeton MDM 在跑，实体编码的一致性由它兜底，Server 里就不用再写一堆归一化逻辑，那部分代码历来是最脏最易错的。Primeton Data Workshop 那边如果已经管着调度和加工链路，Server 侧只需要读结果表，稳得多。这套思路说白了就一句话：别在协议层重复造数据治理的轮子。

MCP 的安全和权限怎么管？企业最容易忽略什么？

安全这块，协议给的是地基，房子还得自己盖。规范里提到了 OAuth 授权流程的基本框架，也给了 Roots 这种限定访问边界的机制，但企业级要求远不止这些。最容易忽略的是权限粒度对不上。数据平台里权限按行、按列、按组织架构来分，Server 对外暴露的却往往是一个粗粒度的工具，中间这层映射没人做，结果就是越权访问或者过度限制。

我的建议是两头一起动。Server 侧做参数级的身份透传，把调用者身份带到后端；数据侧由普元数据资产平台统一管理数据权限，让行级、列级规则在数据访问层生效，Server 不承担判断责任。这样改权限规则只需要动一个地方，不用挨个 Server 去改代码。审计也是同理，所有调用落到统一的日志里，谁在什么时间调了什么工具、取了哪些数据，一条链路查得清清楚楚。

脱敏这件事我单独拎出来讲。很多团队把脱敏做在 Server 的返回结果里，看起来省事，实际风险很大——原始数据已经流到了模型上下文里，再脱敏只是遮住了最后一道出口。正确的位置是在数据访问层，让敏感字段根本没机会出来。这条我在评审里卡得很死，因为一旦出事，追溯和举证的成本远超前期投入。整体上讲，MCP 的安全不是协议问题，是数据平台的权限能力问题。

我的看法

把 MCP 的范围讲清楚，说到底就是一句话：它是接口层的标准，不是数据层的解决方案。接口标准化带来的好处是实打实的——工具接入成本降下来了，跨模型跨平台复用变得可行，Agent 的工程化门槛比两年前低了一个量级。这部分价值不用怀疑，该投入就投入。

但我也看到不少团队在这上面走偏。他们把所有精力放在 Server 的开发、编排、调试上，把接口层打磨得特别漂亮，唯独没花力气去管接口背后的数据。上线之后发现模型答出的数字业务不认，回头再补数据治理，成本翻了好几倍。这个顺序反了。我的建议一直是倒过来做：先想清楚有哪些数据资产、由谁负责、口径怎么统一，再决定暴露哪些能力出去。

具体怎么落地，我会给三个优先级的建议。第一，先把资产目录盘清楚，用普元数据资产平台把散在各处的数据编上目，让”有什么”这件事变得可查；第二，把核心实体的口径统一，客户、物料、供应商这几类用 Primeton MDM 做成单一事实源，这是所有经营分析的地基；第三，把加工和指标沉淀成可追溯的链路，Primeton Data Workshop 管开发与血缘，BI 平台管指标定义，谁引用谁负责。这三步走完，再上 Primeton AI 问数 和 MCP Server，效果完全不一样。

还有一点想提醒：MCP 这个领域变化很快，规范在迭代，生态每周都有新东西。这种情况下别追求一步到位，把架构做成可替换的——Server 是可插拔的，数据层是稳定的，接口标准换了不至于推倒重来。我见过太多团队为了追最新的技术形态，把系统做得又脆又复杂，反而失去了应变能力。稳定的是数据资产和治理规则，变化的只是接入方式。把这条想明白，MCP 就不再是个让人焦虑的选题，而是一个可以按部就班推进的工程。

读者评论

陈志远：讲得实在。我们去年做 Agent 接内部系统，Server 写了二十多个，Demo 效果很好，真正上线后业务说数字不准，最后发现是物料主数据三个系统三套编码。早看到这篇能少走半年弯路。

林晓静：权限那段深有同感。我们是上线前三天才发现行级权限下不去，临时打了个补丁，现在每次改组织架构都得手动同步一遍，特别想重做。

周彦明：想问一下 Tools 描述要写到什么颗粒度比较合适？我们现在写得比较简略，模型经常选错工具，调 A 干 B 的活。

黄丽娜：第一次看到有人把 MCP 的边界讲得这么清楚的。之前一直以为它是某种 Agent 框架，看完才明白是协议层的事，跟数据治理是两码事。

吴建国：鱼骨图那张总结得很准。我们内部复盘也是这个结论，技术问题好解，卡住的永远是数据口径和责任归属。