MCP 到底解决了个什么问题？

一个让人头秃的乘法题

故事是这样的。

前阵子我想给手头的 Claude 接一个数据库，让它能自己查我本地的笔记。我兴冲冲地翻文档，照着教程写了小两百行代码，跑通了。挺爽。

然后第二天我换到另一个模型上试，发现那套代码整个废了，人家用的接口格式完全不一样。我得重写一遍。

我当时就坐在那想，这不是扯呢吗。

就接一个数据库的事儿，我换个模型就得重来一次。那我以后要是再接个文件系统，接个搜索，接个内部 API，再乘上三五个模型，这得写多少遍？

这个事其实不是只有我一个人遇到。你但凡用过一段时间的 AI 工具，自己搭过点东西，就会被这个问题恶心到。

你手上有 3 个模型，Claude、GPT、Gemini，你想让它们都能读你的数据库、能查你的日历、能搜网页。听着不难对吧。

但你算一笔账。3 个模型，每个都要单独对接 3 个工具，那就是 9 套对接代码。你要是再多加 2 个模型，再多加 2 个工具，就是 5 乘 5，25 套。

这就是所谓的 N 乘 M 问题。N 个模型，M 个工具，两两之间都要单独架一座桥。每架一座桥，都得有人一行一行写代码，调通了还不算完，过两个月接口一变又得回来改。

模型厂商呢，各搞各的。OpenAI 有一套自己的 function calling 格式，Anthropic 也有一套，Google 又是另一套。工具这边也是，今天这个 SDK 更新了，明天那个 API 改字段了。你夹在中间，天天当胶水工。

我当时就一个感觉，这帮人就不能坐下来商量商量，定个统一的标准吗。

还真有人这么干了。

USB-C 的故事

你想想 USB-C 这个东西出来之前，我们过的是什么日子。

抽屉里一堆充电线，micro-USB 的，老式宽口的，苹果 Lightning 的，各种乱七八糟。出门带三根线是常态。然后 USB-C 一统江湖，一根线充手机、充电脑、充耳机，甚至能接显示器。

爽。

MCP 干的事，跟这个一模一样。它的全称叫 Model Context Protocol，模型上下文协议，名字听着很唬人，但你不用管那些。你就记住一句话，它给 AI 和工具之间，统一了一个「插口」。

以前是每个模型厂商自己定一套接口，工具开发者得挨个适配。有了 MCP 之后，大家只要都按这个标准来，模型这边插上就能用，工具这边写一遍就全通。

你想想这有多省事。一个工具写好，所有支持 MCP 的模型都能接。一个模型支持了 MCP，所有现成的工具它都能用。N 乘 M，一下子变成了 N 加 M。

这个账谁都会算。

三层结构，各干各的

那这个东西到底是怎么搭起来的呢。我尽量用大白话讲，不讲那些协议细节，你就当它是个搭积木的过程。

一共三层。

最外面那层叫客户端。坦率的讲就是那个 AI 工具，比如你用的 Claude Desktop、Cursor，或者别的什么能跑模型的应用。它负责把你想干的事翻译给后面的工具，再把工具返回的结果喂回给模型。你可以把它理解成那个「插头」，长在设备这边。

中间那层叫服务端，也有人叫 MCP Server。它才是真正干活的。你想让它读数据库，就起一个数据库的 server；想让它查 GitHub，就起一个 GitHub 的 server。每个 server 都是一小段程序，对外说自己能提供什么能力，等着客户端来调用。这层就是那个「插座」，长在工具这边。

最底下那层是资源和工具。这俩东西是 server 暴露出来的具体能力。工具就是能执行的动作，比如「发一封邮件」「查一条订单」。资源是能读取的信息，比如「你的笔记目录」「这个仓库的代码」。一个 server 可以挂好几个工具和资源，就像一个插排上能插好几个设备。

三层各干各的，客户端管对话，服务端管连接，资源工具管具体活儿。插头插上插座，电流就通了。

就这么简单。

当然，背后真正实现起来有一堆细节，什么 JSON-RPC 啊，什么 stdio 传输 SSE 传输啊，但那些是开发者操心的事。你作为普通用户，知道这三层就够了。

标准是好事，但生态还很乱

讲到这里你是不是觉得，这玩意太美好了，是不是接上就能用了。

我得泼盆冷水。

我自己折腾了一段时间，最大的感受就是，标准是个好东西，但标准它只是张纸。真正能不能好用，得看生态跟不跟得上。

现在的情况是这样的。支持 MCP 的模型和客户端越来越多了，这个趋势没问题。Anthropic 自家肯定带头支持，OpenAI 后来也跟进了，Cursor、Windsurf 这些都在接。工具这边，社区里已经有了几百个开源的 MCP server，数据库的、文件系统的、各种 SaaS 的，看着挺热闹。

但你真去用，就会发现到处是坑。

有的 server 写得很好，文档清晰，一跑就通。有的 server 你拉下来，依赖装半天，报错一堆，作者半年没维护了。有的客户端说支持 MCP，但只支持一部分功能，比如只能用工具不能用资源。有的 server 在这个客户端上能跑，换一个就各种不兼容。

就是那种，标准是统一的，但每个人的实现都不太一样的尴尬阶段。

还有安全问题，这块需要注意一下。MCP 让模型能去调你的工具，能读你的文件，能发你的邮件，这事你细想想其实挺吓人的。一个 server 你拉过来用，它到底会干啥，你心里得有数。现在这方面的权限管控还比较粗，社区也在讨论怎么搞沙箱、怎么审计，但远没到让普通用户放心的程度。

我自己现在的做法是，只用在本地跑的、我能看懂源码的 server。公司内部的、涉及敏感数据的，我都是慎之又慎。这不是 MCP 本身的问题，是任何一个新标准早期的通病，当年 App Store 刚出来也是一堆乱七八糟的 App。但它确实意味着，现在还不是那种「插上就爽」的时候。

那我们普通用户图个啥

那既然这么乱，我们普通用户图个啥呢。

我觉得最值得期待的一件事，是以后换模型，可能不用重搭工具链了。

你想想现在的处境。你好不容易给一个模型配好了一堆工具，能查你的笔记，能读你的代码库，能帮你管待办。然后某天出了个新模型，能力碾压你手头这个。你心动了，想换。结果发现，新模型不支持你那套工具的接口，你之前的配置全废了。要么重写，要么忍着不换。

这就是没有标准的时候，用户被绑死在一个模型上的感觉。你不是不想换，是换的成本太高了。

有了 MCP 之后，这个事情可能会慢慢变。只要模型都支持这个协议，你配好的那些 server，换一个客户端就能接着用。工具是你的，数据是你的，模型只是那个插头，想换哪个换哪个。

这个方向，我觉得是对的。

我不是说 MCP 这个具体的标准就一定是最终答案，它也可能被后来的东西取代，也可能演进成另一个样子。但「统一接口」这个方向，几乎一定是趋势。就像当年 USB 之前，各种串口并口乱成一锅粥，最后不还是走向了统一。AI 工具这块也一样，不可能永远每个厂商自己玩自己的。

对非技术朋友来说，你不用现在就去折腾怎么搭 MCP server，那还是程序员的事。但你可以留意一个趋势，就是以后选 AI 工具的时候，看看它支不支持 MCP，或者类似的开放协议。支持的产品，说明它愿意让你把数据和能力带走，而不是把你锁死在它的笼子里。这种产品，长远看更值得押注。

我自己是挺兴奋的。因为这种基础设施层面的变化，往往不像一个新模型发布那么有冲击力，但它的影响是长期的、底层的。等哪天你换模型像换手机壳一样轻松的时候，你大概不会想到，是这么个不起眼的协议在背后托着。

写到这我有个挺深的感慨。技术的进步，其实很多时候不是靠一个天才的灵光一现，而是靠一群人坐下来，决定不再各自为战。USB 是这样，HTTP 是这样，MCP 大概也会是这样。统一这件事本身，就挺浪漫的。