博主入职字节跳动已经有一个月了，感觉有点跳不动了，但是秉承着对于技术的热爱，写博客的爱好依然不能放下，最近在学习大模型相关知识，通过写一写自己的理解来加深印象，希望大家能喜欢。
MCP （Model Context Protocol，模型上下文协议） 是由 Anthropic 在 2024 年底推出的一种开放协议，它通过提供一种标准化的接口，旨在通过标准化的接口实现大语言模型 （LLM） 与外部数据源及工具的无缝集成。
可以将 MCP 视为 AI 应用程序的 USB-C 端口。正如 USB-C 提供了一种将设备连接到各种外围设备和配件的标准化方式一样，MCP 提供了一种将 AI 模型连接到不同数据源和工具的标准化方式。
最初推出时，仅有 Claude 的桌面应用支持，市场反响平平，且不乏质疑之声。但近期，随着诸多 AI 编辑器 （如 Cursor、Windsurf，甚至 Cline 等插件 如何用AI工具辅助开发提效（Cursor、Trae、deepseek等）） 纷纷加入对 MCP 的支持，其热度逐渐攀升，已然展现出成为事实标准的潜力。
为什么需要 MCP
LLM 的模型参数蕴含丰富的通用知识，但通常无法掌握以下两类信息：
- LLM 无法访问你的专属内容，例如文件系统中的文件、数据库里的订单，或私有 wiki 和笔记中的文本。
- 若无法联网，LLM 也无法获取实时信息，例如当前股价、最新财报、明日天气预报或前沿科技新闻。
此外，LLM 的核心功能是生成 token 和提供答案，因此它无法直接执行一些精细且需操作的具体任务，这也不是当前 LLM 的强项：
-
比如调用其他服务的 API 帮你完成订餐和购票。
-
又比如比较 9.8 和 9.11 哪个大，或者计算 Strawberry 中到底有几个 r（虽然现在已有方案能解决了 传送门->比FunctionCall更强大？全代码LLM开发框架详解）
看看 Cursor 的 AI Agent 发展过程，我们会发现整个 AI 自动化的过程发展会是从 Chat 到 Composer 再进化到完整的 AI Agent。
AI Chat 只是提供建议，如何将 AI 的 response 转化为行为和最终的结果，全部依靠人类，例如手动复制粘贴，或者进行某些修改。
AI Composer 是可以自动修改代码，但是需要人类参与和确认，并且无法做到除了修改代码之外的其它操作。
AI Agent 是一个完全的自动化程序，未来完全可以做到自动读取 Figma 的图片，自动生产代码，自动读取日志，自动调试代码，自动 push 代码到 GitHub。
而 MCP Server 就是为了实现 AI Agent 的自动化而存在的，它是一个中间层，告诉 AI Agent 目前存在哪些服务，哪些 API，哪些数据源，AI Agent 可以根据 Server 提供的信息来决定是否调用某个服务，然后通过 Function Calling 来执行函数。
三分钟看懂 MCP
MCP 提供一套标准协议来解决这些问题。简而言之，它通过一组外部工具，帮助 LLM 获取其无法直接知晓的信息或者难以执行的操作。
下面是一个基本的 MCP 工作流程图，其中：
- User：当然就是用户你啦。
- MCP Client：实现了 MCP 的客户端，也就是上面提到的 Claude 桌面 app，Cursor 、Cline 等一众 app，以及未来可能进行支持的各个 Chat box app 等。
- MCP Server：通常是一段运行在本地的 Python 或 JavaScript 代码。为确保安全，Anthropic 当前仅支持 MCP 在本地运行。该 Server 既可执行本地操作 （如浏览文件系统），也能通过网络访问 API （包括第三方 API 或远程数据库）。
- 支持了 MCP 的 LLM。
启动客户端后，客户端读取配置文件，连接 server 并按照协议获取工具列表。和传统一问一答或者推理模型不同，当存在可用的 MCP 工具时，在发送用户问题时，需要把可用工具列表一并发送。LLM 将判断是否需要调用工具完成任务，并把这个指示返回给客户端。客户端如果接受到需要调用工具的指示，则按照 LLM 的指示和 MCP 中规定的调用方式，配置好参数联系 server 进行工具调用，并将调用结果再次发给 LLM，组织出最后的答案。
如何开发 / 使用 MCP
MCP 的官网提供了详尽的文档和 SDK，开发者只需遵循这些资源即可轻松实现 MCP。
MCP 因能有效弥补 LLM 的部分缺陷，逐渐从最初的质疑转为广受认可与欢迎。社区对 MCP 也有 awesome 的定番 repo 和同好社群，可供搜索已有的 server。如下列举了部分 MCP 集合链接，可按需服用。