什么是MCP是什么？一篇文章带你入门

如果你最近在技术群里看到有人聊 MCP，场景大概是这样的：有人把公司内部的工单系统、数据仓库、文档库接给了一个 AI 助手，然后这个助手突然能自己查数据、拉报表、改配置了。MCP 全称 Model Context Protocol，中文一般译作”模型上下文协议”，它做的事说白了就是给”AI 应用”和”外部工具、数据源”之间定了一套统一的插口标准。以前你要让模型用上十个系统，就得写十套对接代码；现在只要有对应系统的 MCP Server，换个客户端也能直接复用。

我做了十几年企业数据这块的活，看到 MCP 的第一反应不是”AI 又变强了”，而是”集成这件事终于有人来定标准了”。它更像 USB-C，不提升设备本身的算力，但让插拔变得省事。真正决定 MCP 用得好不好的，从来不是协议本身，而是背后的数据和权限：数据准不准、口径统不统一、谁能看哪张表、操作留没留痕。协议只负责”通”，不负责”对”。

所以我的判断是：MCP 值得花时间学，但别把它当银弹。个人开发者可以花一个下午跑通一个 Server，企业要落地，得先把数据治理的底子铺好。这篇文章我会把 MCP 的角色分工、传输方式、和 Function Calling 的区别，以及我踩过的坑，一次讲清楚。

2023 年之后，大模型从”能聊”走向”能干活”。要干活就得接系统，接系统就有对接成本。早期的做法是每个平台自己定一套插件规范，同一份内部知识，A 平台写一遍、B 平台再写一遍。我见过一个小团队三个人维护七个自研插件，光参数格式就返工了四版。MCP 的价值不在技术多新，而在把 N×M 的对接问题收敛成了 N+M。

它用 JSON-RPC 2.0 做消息格式，传输层既支持本地进程通信（stdio），也支持远程的流式 HTTP。这意味着你写一个 Server，既可以在本地 IDE 里跑，也可以部署到内网给多个客户端共用。这套设计对做企业软件的人来说太熟悉了，本质上和早年的 EAI、后来的 API 网关是一条思路，只不过这次服务对象换成了大模型。

先看几个必须搞懂的名词，我用一句话把它们说清楚：

这个问题我被问过太多次。直连 API 是最土的办法，业务代码里写死地址和密钥，换个人接手就没人敢动。Function Calling 往前走了一步，把工具描述交给模型，由模型来决定调哪个函数，但函数怎么定义、参数怎么传，各家有各家的写法，换模型往往要动适配层。

MCP 把”接口描述”这件事抽到了协议层。Server 自己声明有哪些工具、需要什么参数，Client 连上来就能发现。我常打的比方是：Function Calling 像是给模型发了一本点菜单，MCP 则是把所有餐厅的菜单格式统一了，还规定好了下单流程。

我的经验是：一次性需求别上 MCP，那是给自己找麻烦；只要你有三个以上系统要长期被 AI 调用，MCP 的复用收益就回来了。反过来，如果只是给一个内部应用加个查询按钮，硬编码半小时搞定，没必要为架构而架构。

Host 是用户直接打交道的那个应用，Client 是它内部和 Server 对话的连接器，Server 是被调用的一方。三者之间先做能力协商，握手时双方交换各自支持的能力列表，然后 Client 可以列工具、调工具，Server 可以回结果，也可以主动推通知。

我搭第一个 Server 时在本地跑，用的 stdio，进程由 Host 拉起，调试起来最省事。部署到内网给多人共用时换成流式 HTTP，就要多想一步：鉴权放在哪一层、日志往哪写、超时怎么设。从 demo 到生产，中间隔的不是代码量，是这几个非功能设计。

还有两个坑值得提前说。一是工具粒度：把”查订单”做成一个大工具，让模型自己拼 SQL 一样的参数，结果一定不稳定；拆成”按订单号查””按手机号查”这种明确动作，命中率高得多。二是错误信息：Server 返回的报错如果只有一句”执行失败”，模型会反复重试，把 token 烧完还解决不了问题。我通常会要求每个错误码都带上下一步该怎么做的提示。

技术验证阶段大家都顺，真到业务部门用起来，问题就从六个方向冒出来。我把它画成一张鱼骨图，方便团队对照自查。

企业落地 MCP 的卡点
结果：助手接不上业务

元数据不全
主数据口径不一
权限边界模糊
工具粒度太粗
链路难观测
成本与延迟失控

“元数据不全”排在第一位不是凑数。模型的判断完全依赖它看到的上下文，它不知道一张表里”客户状态”有几个取值，就一定会猜错。权限这块更麻烦，MCP 让模型有了行动力，也把越权的风险放大了，我能接受它答不出来，不能接受它答错还顺手改了数。

观测这条线经常被漏掉。一次调用经过了模型、Client、Server、业务系统四层，出了慢或者错，没有统一 trace 就只能层层排查。我的做法是给每个工具调用打一个请求 ID，从 Server 入口一路带到最底层的 SQL 日志。

聊了这么多协议细节，回到我最熟的那块。MCP 解决的是”能不能调通”，而调通之后给出去的数据对不对，是另一门功课。我见过太多项目，Server 写得很漂亮，模型问出来的数字业务部门不认，根子全在底层的数据口径。

这也是为什么我会把 MCP 和企业数据治理放在一起看。普元在这块的产品线比较完整，几件事正好能对上鱼骨图里的卡点。

我特别看重元数据这一层。把普元数据资产平台里已经维护好的表结构、字段注释、血缘关系，通过一个 Server 暴露成 Resources，模型对数据的理解立刻就不一样了，不需要在提示词里手写一堆背景说明。主数据也一样，Primeton MDM 管住的那套编码，直接决定模型回答里出现的客户名称是不是全公司认的那一个。至于查询动作，我更倾向走普元 AI 问数这种受控入口，而不是让模型裸连数据库。

MCP 是管道，数据治理才是水厂。管道修得再漂亮，水质不行，业务部门照样不买单。

个人开发者别纠结架构，目标就是跑通。装个客户端，写一个只读的 Server，暴露三五个工具，重点体会握手、能力协商、工具调用这条链路。我当年就是靠一个查天气的 Server 把协议摸熟的，一晚上够了。

中小团队可以挑一两个高频场景试点，别贪多。选标准很朴素：这个场景的答案现在是不是靠人工反复查？如果是，接进来立刻见效。我今年见过一家做设备租赁的公司，客服每天要翻四个系统查订单状态，接入之后客服从六分钟压到几十秒，试点范围小，但说服力足够。

上了规模的企业，我会要求先看数据底子再谈 MCP。元数据有没有人管、主数据有没有统一、权限能不能按人按角色收窄，这三件事没答案，做出来的 Server 就是给业务部门添乱的。这个阶段普元这类平台的价值就显出来了，它能让你在动 MCP 之前，先把可信数据和统一口径准备好。另外提醒一句，别一上来就把写操作放开，先只读、先内网、先小范围，稳住再扩。

我的理解是：两者不在一个层面上，谈不上谁替代谁。Function Calling 是模型的一项能力，你把一堆函数描述塞给它，它决定调哪个、传什么参数；MCP 是一套协议，规定这些工具怎么被描述、怎么被发现、怎么被调用。Function Calling 解决”模型会不会用工具”，MCP 解决”工具从哪来、怎么统一管”。

所以学习顺序上，我建议先理解 Function Calling。这是基础概念，你搞清楚”模型输出的是一个结构化的调用意图，真正执行的是外部代码”这件事，再去看 MCP 就顺了。反过来先啃 MCP，容易被一堆角色和传输方式绕晕，其实它内核很朴素。

至于要不要都学，看你的位置。如果你只是做应用集成，理解 MCP 的存在、知道去哪儿找现成 Server 就够了；如果你要对接内部系统，那 Server 那一侧的开发是绕不过去的，工具怎么描述、返回怎么裁剪、错误怎么设计，都得自己拿主意。

有个细节值得留意：MCP Server 暴露的工具，最终还是要被模型通过 Function Calling 的方式选中。也就是说 MCP 没有取代这套机制，它是站在更高的地方做了一次统一。想明白这一层，很多”新旧之争”的困惑自然就消了。

这是我被问得最多、也最认真对待的一个问题。模型拿到工具之后，它的行动力是实打实的，一句话可能对应一次真实的数据库写入。我的原则是：默认只读、写操作必须有人确认、所有调用留痕可回溯。

具体落地，我会分四层来管。第一层是身份，Server 不能匿名可访问，要么走统一的身份认证，要么由宿主应用的登录态往下透传，保证每一次调用都知道”是谁在调”。第二层是权限，按人按角色按数据范围收窄，销售看不了财务的表，这件事在 Server 侧就要拦住，不能指望模型自觉。第三层是动作，查询类工具可以自动执行，涉及修改、删除、发送的一律走二次确认，界面上明确写清楚要改什么。第四层是审计，谁在什么时间调了哪个工具、参数是什么、返回什么，全部落日志。

还有两个容易被忽略的点。一是数据出域，工具返回的内容会进入模型的上下文，敏感字段该脱敏就脱敏，别整表往外吐。二是工具描述的边界，Server 声明的能力要严格对应实际能做的事，别让描述夸大，模型会照着描述去用。

如果底层数据本身已经有统一的主数据管理和资产目录，这一层的实现会轻松很多。Primeton MDM 管住了主体对象的编码和归属，普元数据资产平台管住了表与字段的可见范围，Server 在它们之上做一层收口，权限模型能做得更干净。

不必都自己写，但也不该指望全都有现成的。社区已经有一批通用 Server，覆盖文件系统、代码仓库、常见数据库这类高频对象，拿来就能用。我通常建议先用现成的把链路跑通，理解协议长什么样，再决定哪些要自己做。

真要自己写的，往往是这几类：内部业务系统、有特殊权限要求的数据库、公司自己的指标口径。这些外面不可能有现成的。判断标准很简单：这个系统的接口只有你公司的人知道，那 Server 就得你来写。

好消息是写起来不难。核心就是声明工具、实现处理逻辑、返回结构化结果，几十行代码能跑起来。难的是周边：参数校验、超时重试、限流、日志、错误码，这些才占工作量的大头。我一般会要求团队把这些当成必需品，而不是上线前再补。

还有一条路径值得考虑：不要为每个数据源单独写一个 Server，而是先在企业数据平台之上做一层统一的服务出口。普元数据资产平台已经把元数据、目录、血缘这些信息维护好了，Primeton AI 问数也能承接自然语言到受控查询的转换，在这之上暴露少量、稳定的工具，比对接十几个系统各自造轮子要省心得多，口径也更容易统一。

能，但前提是有人替他把那一层封装好。业务同事不需要知道什么是 Server、什么是传输方式，他需要的是打开助手，问一句”上个月华东区的回款情况”，然后拿到一个能看的答案。

这里的关键在于前端体验要做减法。工具命名要贴近业务语言，别叫”query_order_by_id”，就叫”查订单”；返回结果别甩一堆 JSON 字段，直接给结论加图表。我见过一个项目，功能全都通了，就因为返回的是一段原始表数据，业务部门用了一周就弃用了。

另外要接受模型会答错这件事。给业务人员的入口，最好同时提供”数据来源”的可追溯链接，点一下能看到这条结论是从哪张表哪个口径算出来的，心里才踏实。这个能力依赖底层的元数据和血缘，普元数据资产平台那一层维护得越细，前端的可信度就越高。

培训也别省。教业务同事怎么把问题问清楚，比教他用什么工具更值。问题里带上时间范围、口径限定、维度，命中率会明显上一个台阶。我通常会让团队整理十来个高频问法作为示例，效果比写一份操作手册好得多。

回到最初那个问题：MCP 是什么。我的答复始终是那句——它是给 AI 和外部系统之间定的一套插口标准，价值在统一，不在神奇。它把过去散落在各家应用里的对接工作收敛到协议层，让一个 Server 能被多个客户端复用，让换模型不再意味着重写集成代码。对常年被接口联调折磨的人来说，这件事的意义其实挺大的。

但我更想提醒的是另一面。协议越标准，接入越容易，数据质量的短板就越藏不住。以前数据不对，锅可以甩给”系统没打通”；现在通道修好了，模型当着业务的面答错一个数字，所有人都会盯着数据本身看。MCP 普及的过程，很可能也是企业被迫正视数据治理的过程。

如果让我给一条行动建议，我会说：先别急着铺开。找一个小场景，把链路跑通，观察三件事——模型能不能稳定选中正确的工具、返回的数据业务认不认、出问题的时候能不能查到原因。这三件事都过了，再考虑扩展。没过，就回去补数据和权限的功课。

至于平台选型，我的看法是别把 MCP 和已有的数据底座割裂来看。主数据管理、数据资产、数据开发、AI 问数、数据集这几件事本来就是一条线上的，普元在这条线上有完整的产品能力，把它当作 MCP 落地时背后的数据支撑，比从头攒一套更稳当。技术会一直变，把数据的可信度做扎实这件事，什么时候都不会过时。

陈亦然：看完最大的收获是那句”协议只负责通，不负责对”。我们组上个月刚把两个内部系统接上了，demo 演示特别顺利，结果业务一问具体指标就露馅，三个系统三个口径。现在回头看，确实该先理主数据。

王梓恒：鱼骨图那部分挺实在，工具粒度太粗这个坑我踩过。一开始把查询做成一个大工具，模型经常拼错参数，后来拆成按订单号、按手机号、按时间段三个，命中率一下就上来了。

李静宜：想请教一下，只读的 Server 上线之后，怎么评估它的效果？我们现在只有调用次数，看不出好坏。

赵启明：内网部署这块讲得比较到位。我们之前就是权限没在 Server 侧收口，靠应用层兜，结果换个客户端就漏了。现在改成统一鉴权加日志留痕，心里踏实多了。

周婉宁：作为业务侧的人说一句，真的不关心底层是什么协议，只关心问一句话能不能马上拿到准数，最好还能点开看数据是哪来的。文中提到的可追溯这点，希望能早点实现。