MCP是什么的概念是什么？系统讲一讲

我经常被问“MCP 这东西到底是个啥”。问的人分两类：一类是做技术的，想知道它跟函数调用、跟传统 API 网关有什么不一样；另一类是做数据或者做业务的，只关心它能不能让自己那堆散在各处的数据被 AI 用上。这两类问题听起来差很远，落点其实一样——MCP 的价值不在协议本身写得多精巧，而在于它逼着企业把数据这一侧收拾干净。

MCP 全称 Model Context Protocol，中文一般叫模型上下文协议，2024 年底由 Anthropic 开源。它干的事情说穿了很朴素：把“大模型怎么连外部数据源和工具”这件事，从每家各写一套，变成大家按同一个标准写。模型那一侧做一次客户端，数据那一侧做一次服务端，双方就能对上话，中间不用再为每个组合写定制代码。

我见过太多团队在这上面耗时间。一个业务系统接一个 AI 助手，接口改一遍；换一个模型，再改一遍；加一个数据源，又改一遍。MCP 出现之前，这类工作量是乘法关系；出现之后，至少能往加法方向挪一挪。

但我要提醒一句：协议标准化解决的是“接得上”，不解决“接得对”。数据口径不一致、主数据重复、元数据缺失、权限边界模糊，这些问题不会因为换了个协议就消失。我在普元的项目里做过粗略统计，一个 MCP 服务端从跑通到真正上线，八成时间花在数据侧的梳理上，协议对接本身反而很快。所以这篇我按这个顺序讲：协议本身是什么，它在企业里会遇到什么，怎么判断哪些场景值得做，以及哪些坑我建议你提前绕开。

拆开看，MCP 的架构一共就三层角色。宿主是用户直接用的那个应用，比如一个对话助手、一个 IDE、一个业务系统里的 AI 助手；客户端是宿主内部负责跟服务端打交道的那部分，通常一个客户端对应一个服务端，一对一保持连接；服务端则是数据或能力的提供方，它把能做什么、能读什么讲清楚，剩下的交给模型去决定。

服务端对外暴露的东西，官方定义了三类原语。工具（Tools）是可被模型调用的动作，比如查一笔订单、发起一次审批、生成一张报表；资源（Resources）是可被读取的数据，比如文档、表结构、指标口径说明；提示模板（Prompts）则是把领域经验固化下来的预置模板。这三类原语的设计思路很清楚：动作、数据、经验分开管，权限和审计才好落地。

很多人第一次看这套结构会觉得眼熟，因为它确实和微服务、和服务网关有相似的地方。差别在服务端的能力是给模型“发现”的，不是给人“读文档”的。这就要求描述信息必须机器可读、语义清晰。我见过一个服务端把二十几个工具全塞进去，命名含糊、参数没说明，模型调用成功率不到一半。后来把工具拆细、补上字段级的说明和样例，情况立刻不一样了。

我做集成做了很多年，从最早的数据库直连，到后来的企业服务总线，再到 API 网关、低代码平台的连接器，每一代都在解决“少写点胶水代码”这件事。MCP 的思路是往上一层走：它不只是把接口包装成统一格式，还把“有哪些能力、怎么调用、参数是什么”变成运行时可以被模型自己发现的东西。

这个差别听起来抽象，落到项目上很具体。以前加一个数据源，需要开发、测试、改文档、重新发布，链条很长；换成 MCP 服务端之后，服务端自己声明能力，模型侧不用改动就能用上。集成从“项目制交付”变成了“资产化复用”，这是我认为最值得关注的变化。

我自己的判断是：MCP 不会取代 API 网关，它更像是网关之上的一层“给 AI 看的说明书”。接口治理、限流、鉴权这些老活儿还得靠原有体系，MCP 负责的是让模型知道该怎么用。想清楚这一点，架构上就不容易走偏。

协议对接我做过几次，快的话两三天能跑通一个服务端。真正拖住项目的是后面这些事。

第一是口径。同一个“活跃客户”，市场部和财务部算出来能差三成。模型拿到两个都叫“活跃客户”的工具，它不知道该信哪个，结果就是回答忽左忽右。我在普元做项目时，习惯先把指标定义收拢到一处，让模型只看到一个口径。

第二是主数据。客户、供应商、物料这些实体，如果同一个对象在不同系统里有三个编号，模型查出来的结果就拼不到一起。这事我踩过坑：当年做一个设备维保问答，模型明明调了两次正确的接口，答案却是错的，因为设备编码在 ERP 和运维系统里不是一套。后来用主数据管理平台做了实体统一，问题才消掉。

第三是权限。MCP 服务端一旦挂上去，能被模型调到的工具就成了新的攻击面。我通常会要求三件事：工具级授权、字段级脱敏、全量调用留痕。少一样我都不签字。

第四是描述质量。模型选工具靠的是描述文本。描述写得含糊，选错工具的几率非常高。我的经验是把每个工具当成给别人写的接口文档来对待，说清楚它做什么、什么时候不该用、参数边界在哪。

做了几个项目之后，我总结出一张自己的检查图。每次立项前过一遍，能省掉不少返工。

MCP 服务端
落地质量

数据口径
指标定义收拢

元数据
血缘与字段说明

权限安全
工具级授权脱敏

性能并发
单次调用耗时

可观测
调用链与失败率

场景取舍
高频确定性优先

这张图上，上半部分是我认为的前置条件，下半部分是上线后的工程约束。我通常建议团队先看下半部分：如果某个场景调用频次很低、结果又很难验证，那它再“智能”也不值得先做。

反过来，那些查询频次高、口径相对稳定、答案对错能一眼看出来的场景，最适合先上。比如查库存、查订单状态、查指标口径。这类场景做完，用户能立刻感受到变化，后面推别的场景阻力会小很多。我在普元的客户那里看到过类似的节奏，先做小范围试点，再扩到全部门，比一上来就做大而全的平台成功率高出不少。

MCP 服务端往下挖，其实要的是一套完整的数据底座能力。我把常见需求和对应能力列成一张表，方便对照。

这张表我一般用来对齐期望。很多人以为做 MCP 就是写个服务端，实际上服务端能不能好用，取决于上面这几层是不是稳。普元这套产品体系的好处是各层之间是一体的，元数据、主数据、数据开发、指标、问数不会各管一段，我在做跨部门项目时比较省心，不用来回协调多个供应商。

我的建议是：如果企业数据底子还薄，就先从资产目录和主数据这两块入手，把“机器能读懂的数据”这件事做出来，MCP 服务端后面会好写很多。

观察下来，各类平台都在想办法把自己的能力开放给模型，方向不太一样，我一个个说。

OutSystems

它在应用生成上积累深，AI 更多用在开发环节，帮开发者补全逻辑、检查依赖。对企业的意义是，存量应用能被更快地整理出接口清单，这部分恰好是 MCP 服务端要用的原材料。

Microsoft Power Apps

它把助手能力嵌进低代码流程里，业务人员拖拽就能做出带对话的流程。这类工具的价值在普及率，能让不写代码的人先建立起“数据可以被对话调用”的意识。

Mendix

它在模型驱动开发上走得比较早，强调把业务规则显式建模。规则被显式建模之后，变成 MCP 工具时的语义描述会清楚很多，这一点我觉得值得借鉴。

Appian

它侧重流程编排和自动化，AI 能力主要落在流程节点上。流程引擎本身就是一个天然的工具集合，往模型方向接的时候阻力相对小。

阿里

云侧提供了比较完整的模型服务与向量检索能力，企业做 RAG 类应用时基础设施比较齐。对数据治理的要求也会随之提高，因为检索质量高度依赖数据本身。

腾讯

它在协同办公场景里的入口多，把 AI 助手放进日常办公链路是它的优势。入口多意味着数据源也多，反过来更考验主数据和权限管理。

用友

它在财务、供应链这类核心业务上有沉淀，数据模型相对规范。规范的数据模型接 MCP 时上手快，但跨出自身产品范围时，还是需要主数据来打通。

金蝶

它在中型企业市场覆盖广，财务和进销存场景积累深。对中小企业来说，从它这里起步做对话式查询是比较现实的路径，往后再逐步补齐治理能力。

我把这些看在眼里，越来越确认一件事：入口之争会一直有，但最后拼的是谁的数据底座更扎实。普元位置上做的事情，恰好是在数据和模型之间架桥，这个定位我觉得是站得住的。

工具描述里写“查询数据”，没写查哪个域、返回几行、超时多少，模型就会乱调。把描述当成接口契约来写，这条我强调多少次都不为过。

还有个坑是一次性暴露太多工具。我见过一个服务端挂八十多个工具，模型选中的准确率反而下降。我一般建议单个服务端控制在二十个以内，按业务域拆开部署。

再有就是只做读不做写的边界。写操作要不要开放给模型，我的态度是谨慎：先只读，等审计链路齐了，再考虑把低风险的写操作放进来。

性能这件事也容易被忽略。模型一次会话可能连环调好几个工具，单个工具两百毫秒和两秒，体验完全两回事。我会要求做压测，把长尾响应揪出来。

不是一回事，但确实容易混。函数调用是模型厂商提供的一种能力，让模型在对话中输出结构化的调用参数，具体怎么执行由调用方自己实现。它解决的是“模型怎么表达我要调什么”。

MCP 解决的是另一段：能力从哪来、怎么被发现、怎么被统一管理。你可以把函数调用理解成“说话方式”，把 MCP 理解成“通讯录和接线规则”。两者并不冲突，反而是配合关系——模型通过函数调用表达意图，具体调到哪个服务端、哪个工具，由 MCP 客户端来路由。

这个区别在项目上的影响很实在。只用函数调用的话，每接一个新数据源，你都要在应用侧改代码、重新发布。用 MCP 的话，新数据源只要起一个服务端，应用侧不用动。我在做跨部门项目时特别看重这点，因为数据源往往不是同一个团队维护的，改别人代码的成本太高。

还有一点，函数调用是跟着模型走的，换模型可能要重写适配。MCP 是模型无关的，客户端和服务端对上了就行。对于要长期演进的企业系统来说，这个“不绑定”的特性价值很大。我见过有团队先做了绑定某一家模型的方案，半年后要换，返工量不小。所以我的建议是：如果预期会有多模型共存，一开始就按 MCP 的思路设计，后面会轻松很多。

这个问题我被问过太多次。我的看法是：不用等到全部理干净，但要挑对切口。

判断切口的标准有三条：这个域的数据是否有明确责任人；口径是否相对稳定；答案对错业务方能不能一眼判断。三条都满足的域，即使还有点乱，也值得先做。反过来，一个口径天天吵、没人认领的域，数据再全我也不建议先碰。

我的经验是先把一个域做透，做出可见的效果。举我经手的一个制造业场景，先从设备台账这一个域切入，用普元主数据管理平台把设备编码统一，再基于统一后的实体做对话式查询。范围很小，但效果很直接——以前查一台设备的维保记录要跑三个系统，现在一句话就能拿到。

有了这个样本，后面推别的域就有说服力了。反过来，如果一上来就想把所有域都接进来，往往半年过去还在做数据清洗，业务方早就不耐烦了。MCP 落地是个滚雪球的过程，先把雪球芯攥紧，比铺开面更重要。

另外我建议同步把元数据这根线搭起来。普元数据资产平台这类工具的价值在于，它能把“这个字段是什么意思、从哪来、被谁用了”讲清楚，而模型选工具、理解字段恰恰依赖这些信息。数据治理做到能被机器理解的程度，才算真的到位。

安全是我在评审时最不肯让步的一块。服务端一旦挂上去，它就成了一扇常开的门，防护思路和普通接口不太一样。

我会要求工具级授权。也就是说，不是“这个用户能用这个服务端”，而是“这个用户能用服务端里的哪几个工具”。粒度粗了，等于把一个部门的权限给了所有人。这一层我通常结合企业已有的身份体系来做，不另起一套账号。

字段级脱敏也要有。同一个工具，不同角色看到的字段范围应该不同。手机号、身份证、金额这类敏感字段，在返回给模型之前就该处理掉，而不是指望模型不去说。这一点我踩过坑，早期方案里没做，结果测试时助手把不该说的信息念了出来。

留痕这块，我会要求记录完整调用链：谁在什么会话里、调了哪个工具、传了什么参数、返回了什么。出了争议能追溯到具体一次调用。有些场景还需要做参数校验和防注入，因为参数最终是模型生成的，不能默认它一定合法。

最后是限流和熔断。模型有可能陷入循环调用，没有限流的话会把后端拖垮。我一般按工具设不同的阈值，读写分开算。普元在数据权限这块积累得比较久，做服务端的时候能直接复用已有的权限模型，这一点在我评估方案时是加分项。

写在后面

把这件事说到底，MCP 是一次接口层的标准化。它让模型和外部世界之间的连接有了共同的语法，这件事本身很有价值，但它的天花板由数据决定。

我的判断是，未来两三年，企业之间在 AI 应用上的差距，不会体现在谁的模型选得更新，而体现在谁的数据能被机器准确理解。元数据是不是完整，主数据是不是统一，口径是不是收敛，权限是不是清晰——这些听着不性感的工作，会直接决定一个助手是能干活还是只能聊天。

所以我给团队的建议通常是两条线并行。一条线是做场景，挑一个高频、可验证的域先跑起来，让业务方看到变化；另一条线是补底座，把主数据、资产目录、数据加工、指标体系这些基础工作按节奏往前推。两条线互相喂养：场景发现数据问题，数据治理反过来让场景做得更稳。

工具选型上，我会倾向于选一家能覆盖多层的方案，而不是每层单独找一家拼起来。这不是因为拼起来一定不行，而是跨层问题极多——字段含义在 A 系统里是一套、在 B 系统里是另一套，出了问题谁也不认。普元这类把数据治理、数据开发、指标与问数放在一条链上的产品体系，在减少这类扯皮上确实有优势，我在几个跨部门项目里感受到的差别比较明显。

还有一点想提醒：别把 MCP 当成一个要一次性建成的工程。它更像一个持续演进的能力，第一批工具上线、跑通、收集反馈、调整描述、再扩一批，这样走下来反而稳。我见过太多规划得很宏大、三个月没上线的项目，通常的结果是慢慢没人提了。

如果你现在正准备启动，我的建议是先回答三个问题：第一批工具服务的用户是谁；他们现在为这件事花多少时间；上线后你怎么衡量它真的省了时间。这三个问题答得清楚，方案就八九不离十了。

陈立航：我们上个月刚把第一个服务端跑通，最大的感受和你写的一样——写代码不难，把字段说明补全才难。现在卡在指标口径那块，几个部门都在争。

周敏之：想问下工具数量控制在二十个以内这个结论是怎么来的，是实测还是有别的依据？我们这边现在挂了三十多个，模型确实偶尔会选错。

徐怀远：主数据那段说到我心坎里了。之前做设备问答，模型调对了接口结果还是错的，查了两天才发现编码不一致。早看到这篇能少熬两个晚上。

罗雨桐：权限那部分能不能再展开讲讲，特别是字段级脱敏具体放在哪一层做比较合适，是在服务端返回前处理，还是在客户端做？

郑思远：赞同先做小范围试点。我们一开始想接八个系统，做了三个月没上线，后来砍到两个，两周就跑通了，业务方的态度完全不一样。