MCP解析 | 文雅的疯狂的学习笔记

Button

type

status

date

slug

MCP 核心理念: 一次开发，随处使用

比如开发一个能够使用高德地图规划路线的 MCP 服务器后，需要将它接入 Cursor 时，修改 cursor 后台 MCP 服务器配置文件；需要将它接入 claude 桌面应用，则修改对应 MCP 服务器配置文件，以此类推。这就是为什么可以将 MCP 比作 USB 接口

AI 应用们为什么乐于接受 MCP？

现在各家大模型能力已经很接近，提供什么样的功能成为破局的关键点。如果一个 AI 应用提供非常多让用户链接外部资源的功能，帮助用户提高大模型生产力，肯定至少有助于增长其用户量

但提供哪些功能是个问题。联网、执行代码等通用能力大多数 AI 应用都已集成，剩下就是如何尽可能满足用户对特定资源的集成需求。不同用户，甚至同一用户的需求都有非常多种，很难像集成 Google Drive 那样集成那么多能力

MCP 协议的出现很好地解决了这个问题。用户可以根据实际需求，选择性地将具有需求功能的 MCP 服务器接入 AI 应用中(未来可能由 AI 代理自动化实现)，精准解决对特定能力的需求

另一方面，AI 应用本身集成 MCP 协议并不难，成本也很低，所以这其实是一个很有性价比的动作

如何实现集成 MCP

MCP 的本质与函数调用(function calling)相同，目的都是给大模型附加集成外部资源的能力。不同点在于通过 MCP 开发功能时，需要按规定写法写需要的参数，MCP 服务器的具体作用等，这样才能让 MCP 客户端识别到并调用

通过规定这种协议，MCP 解决了 function calling 写法不一，适配繁琐的问题。具体写法可参考课程第五节课，「Creating an MCP Server」

对于 AI 应用本身，在 MCP 中也可以叫 MCP Host，在适配 MCP 时，只需要在原来对话逻辑的外层添加一个解析 MCP 配置文件的逻辑，就能让大模型知道有哪些 MCP 服务器可用，并像原来调用 function calling 一样调用对应功能

注意，由于未来 MCP 计划使用多代理架构与注册表机制，让 AI 自主搜索并调用需要的 MCP 服务器，这种适配逻辑可能会变化

MCP 主要架构

MCP 宿主/主机(host)

比如 Claude, Cursor, Cherry Studio 这些 AI 应用，它们主要负责 MCP 服务器如何呈现给用户，包括但不限于以下这些：

一、是否有 MCP 服务器安全验证机制及如何实现（就是那个问你是否允许使用 MCP 的对话框）

二、 MCP 服务器呈现的工具/资源/提示如何提供给用户。比如 claude 桌面端是通过左下角「+」号 -> 选择对应 MCP 服务器来选择其对应的资源/提示

三、当 MCP 数量急剧增加，宿主需要提供对应策略管理 MCP 服务器的上下文，否则会减少上下文窗口与分散注意力，变相削弱大模型能力

现在的 Host 普遍给用户提供一些开关，让用户选择将哪些 MCP 服务器添加到上下文中。比如 Cursor

但课程最后一节课讲到，未来 MCP 协议计划引入多代理架构与“注册表「机制，实现让 AI 自己根据需要实时安装、调用 MCP 服务器，而不是预装一堆 MCP 服务器，导致前面说的”上下文爆炸“问题。这样可以极大扩展 AI 链接外部资源的能力，如果实现，我想 AI 代理能力将获得质的飞跃

MCP 服务器(Server)

MCP 提供三种「Primitives」，原语。即工具，资源和提示词/提示词模板

其中，资源和提示词是 MCP 区别于 function calling 比较重要的一个点。MCP 服务器本身自带这些内容，不需要再向外部请求

MCP 服务器在提供这三个原语时，方式是一样的。都使用装饰器，提供描述、作用、参数等信息，所以在 MCP 宿主中解包这些信息让大模型了解它们的作用用的是一套逻辑

工具

本质上与之前的函数调用，function calling 一致，也是 MCP 服务器的核心功能，是大模型用来从外部获取资源最重要的东西

资源

分为两种，一种是预设好的文件夹/静态文件，另外一种是在 MCP 服务器运行过程中实时更新的数据

提示词/提示词模板

开发者可以利用 MCP 为用户提供一套能够最大化开发出 MCP 服务器能力的提示词或者提示词模板。这样用户就不用自己研究 MCP 的功能。个人觉得这也是一些具有复杂功能 MCP 的最佳实践

MCP 客户端

用于与 MCP 服务器建立连接，主要起通信的作用

MCP 客户端与 MCP 服务器之间的通信

MCP 客户端与 MCP 服务器之间的通信支持三种方式，专门用于本地的 Stdio，用于远程的 SSE，还有最新的 Streamable HTTP

Tips:在三种协议之间切换比较简单，其他代码不用动，只需把协议对应的名称换一下就行

Standard I/O

也是大家最常见到的缩写，stdio，现在大多数 MCP 服务器都使用这个。它是一种无状态(Stateless)连接，会话过程中的信息不在通信中保存。但一般在使用 MCP 时，过程中产生的信息会被 MCP 宿主维持在对话上下文中。换句话说，MCP 宿主在这里起着维持状态的作用

SSE

全称 Server Sent Event，服务器发送事件。为远程服务器设计的一种有状态 (Stateful) 的长连接通信方式。适合实现资源动态更新、实时通知等功能。但不利于横向扩展，负载均衡会导致会话中断。SSE 是旧版通信，现在的 MCP 服务器还是采用 Stdio 比较多，它延迟低，可横向扩展，而且上下文状态可交由 MCP 宿主实现

Streamable HTTP

新一代，更灵活的标准，同时支持有状态与无状态两种模式。视频中说等这个协议出来，新的 MCP 服务器都会使用这个协议，以前的服务器也都会迁移到它

小结

一般普通用户其实也不用懂太多，知道几个主要功能就行，但如果你想了解 MCP 底层工作方式，更好地利用 AI，还是建议认真学下像 DeepLearning.ai 上这种系统的 MCP 课程

MCP 和function calling 相比，最直观的变化有两点。一个是速度，另一个是可用性

速度上，以前 function calling 在大多数场景下一次对话中只能用两三次，而现在 MCP 随便调用个十几次工具都不带喘气的。可用性上，以前 function calling 基本只能通过 API 自己开发自己用，现在有了 MCP，加上 AI 大玩家们纷纷入局，我们在很多客户端上都能给 AI 附加自己想要的能力，不再局限于 AI 应用本身提供的功能

最后，还是很期待教程中提到的多代理架构和注册表机制的，实现让 AI 自己根据需求动态安装 MCP 服务器，应该能极大提升 AI 的代理能力

如果对你有帮助，记得三连哦~