MCP协议，你可以把它理解成大模型和外部世界之间的合规通信桥梁。它能极大提升AI应用的效率。这篇文章主要聊三个方向：MCP为什么会出现、它由哪些核心部件构成、以及在实际开发、分析和办公中怎么用。
AI圈最近又热闹了。不过这次不是因为某个新模型，也不是因为某个爆款应用，而是一个协议——Anthropic在2024年11月推出的MCP。
这玩意儿其实已经热了一阵子，但前期用得不多，所以一直没动笔。最近补了补课，觉得是时候聊聊了。
先聊聊为什么会出现MCP。
大模型刚出来那会儿，只能聊天，问一句答一句，哪怕多模态能看图、看视频，本质上还是问答。离我们真正想要的AI——能帮我们“做事”——差距不小。
后来有了function call，可以通过调用外部API，让大模型跟外部能力打通。那时候的架构大概是这样的：
这么一搞，整个生态的复杂度就指数级上升了。更要命的是，实际工作中，你在模型A里集成了一个能力（比如操作Gitee代码仓库），到了模型B里，那套代码基本得重写。大量工作重复浪费，实在吃不消。
所以，MCP应运而生。
MCP全称Model Context Protocol，模型上下文协议。它的目标很明确：用一套统一的标准，来约定大模型和外部数据（资源）、外部能力（工具）之间的通信方式。
核心组件不外乎三个角色：
- Host——宿主程序，也就是当前大模型所在的载体应用，比如Claude Desktop、Cursor、字节的Trae等等。
- Client——MCP客户端，负责跟MCP Server通信，内嵌在Host里。像Cursor就已经内置了，直接配好MCP Server就能用。
- Server——MCP服务器，真正提供外部数据和能力的地方，一般独立在Host之外。可以是本地文件的封装，也可以是远程REST接口的封装。
另外还有几个关键概念：
- Resources：大模型外部的资源，文本类的（源码、日志）或者二进制文件（PDF、图片）都算。包括文件内容、数据库记录、API响应、实时系统数据、截图、日志等。
- Tools：大模型外部的工具，有的由已有接口改造而来，也有全新开发的。比如文件系统接口、数据库访问（SQL）、API接口、企业微信等各类应用。
刚看到的消息，MCP最初的响应协议用的SSE方案，前几天已经升级为Streamable HTTP，更快，更方便。
简单举几个例子，大家感受下MCP的实际价值：
- 代码开发：把自有组件或者不常用的组件文档集成进来，让AI辅助编码更准确；再集成浏览器MCP，自动抓取网页错误日志，调试效率直接拉满。
- 数据分析：直接连数据库、Excel等数据源，让大模型帮你分析各种指标，省去手动导数据、写脚本的麻烦。
- 企业办公：邮箱、企业微信这类常用工具，借助MCP，不仅能一步获取相关数据，还能代替人工自动回复邮件、发送消息。
这次分享主要梳理了MCP的理论框架，希望能帮大家建立起一个直观认识。下一篇可以聊点实战——怎么搭建自己的MCP Server，敬请期待。