搞不懂 MCP？那就动手搓一个...

MCP 火了有一阵了，市面上相关教程也不少，无奈看完，依旧一头雾水。

原因无他，没动手而已。

这两天实操了一把，发现 MCP 确实以一种更优雅的方式，帮我解决了之前难以搞定的问题。

今天从实战出发，和大家聊聊：如何把 MCP 接入自己的 LLM，希望给有需要的朋友，一点点参考。

本文将首先回答：

• 万能的 LLM 为啥干啥啥不行？
• Function Call 是怎么诞生的？
• MCP 解决了 Function Call 的什么痛点？

然后，以实操的方式回答：

• MCP Server 有哪些实现方式？
• MCP Client 和 Server 是如何通信的？
• 如何把 MCP 接入 LLM？

1. LLM 的局限性

各大厂商竞相发布 LLM，即便 benchmark 指标刷上天，拉到现实场景中，依然解决不了各种问题。

因为大模型训练完，它的信息量就不再更新。

比如用户要查个天气，就必须借助高德/百度地图等外部 API 来获取最新数据。

笔者在微信 AI 机器人的实现中，就是首先让 LLM 识别用户意图，然后再调用外部 API，获取相关消息后，进行回答：

为了实现各种功能，必须在提示词中写明所有意图标签，然后逐一开发对应功能：

实际你会发现，即便非常明确告诉它这些意图，意图识别也不是 100% 正确。

当然，解决上述问题的另外一个思路是：Function call，这也是聊 MCP 之前，绕不开的话题。

2. Function call 的局限性

Function call（下文简称 FC） 早在 2023 年，就由 OpenAI 提出，主要就是为了解决上述 LLM 的局限性。

你在 Coze/Dify 等智能体平台上，看到的各种插件，本质就是基于 FC 实现的。

但 FC 的缺点也很明显：必须要 LLM 本身支持，然后在 OpenAI 的接口中传入 tools 参数：

但是不同 LLM 训练时，因为各种实现方式不一样，导致输入/输出结构、触发结构都不一样。

所以，换个 LLM 就得适配上面的 tools，实在是太难受。

只是 Coze/Dify 等平台，做了大量适配工作，才让你感到用起来很爽。

但是，即便是生态丰富的 Coze，也不是万能的，总有一些个性化需求，平台是满足不了的。

还是绕不开要定制化开发，然后面临这个头疼的问题：一顿操作写了个接口，换个 LLM 居然理解不了。

所以，MCP，它来了！

3. MCP 是啥

MCP 全称 Model Context Protocol，模型上下文协议。

就像 Type-C 为设备连接各种外设提供了标准化方式，MCP 为 LLM 连接各种工具提供了统一方式。

3.1 整体架构

Anthropic 公司最早提出 MCP 时的一张图，非常形象刻画出了它的整体架构：

图中有几个关键概念：

• MCP hosts：应用程序，比如各种 AI 工具或 IDE，最新版 Trae 就已接入
• MCP clients：客户端组件，和服务端维持连接
• MCP server：服务端，通过 MCP 协议提供各种功能
• Local data：本地资源，比如本地文件、数据库等
• Remote services：远程服务，通过网络访问

抛开这些概念不谈，MCP 和 Function call 在应用层面有什么区别？

没区别，还是上面这张图，只是其中的 tools 交给