本节目标:用最直白的话讲清楚 MCP 是什么、为什么 2025 年它突然成为 AI 行业最热的协议、以及它会怎么改变你和 AI 工具的相处方式——不管你是开发者、产品经理、还是只想用好 AI 的普通用户。
一、先讲个故事:AI 的"接线员困境"
1.1 一个真实的痛苦
想象你刚买了一个智能音箱,这个音箱本身很聪明,可以听懂你说的任何话。但你发现它有个尴尬的毛病:
- 你说"帮我查一下今天的日程",它说:"对不起,我连不上你的日历。"
- 你说"把这份文档发给小王",它说:"对不起,我连不上你的微信。"
- 你说"看看公司的销售数据",它说:"对不起,我连不上你们的数据库。"
你气坏了。这个音箱本身值 5000 块,可它什么都干不了——因为它和外面的世界是断开的。
2024 年之前的 AI 大致就是这个状态:
┌─────────────┐
│ AI 模型 │ ← 学富五车,但是只会"说"
│ │
└─────────────┘
│
× 没办法连接外部世界
│
┌─────────────────────────────────────┐
│ 文件 │ 数据库 │ 邮箱 │ 日历 │ GitHub │
└─────────────────────────────────────┘
1.2 第一次尝试:每家自己造接口
各大 AI 公司当然意识到了这个问题。最早的解法是各干各的:
- OpenAI 搞了 ChatGPT Plugins(已停用)
- 各种 AI 助手自己写一套"工具调用"
- 每个开发者给每个 AI 重新写一遍集成代码
没有 MCP 的世界(2024 年):
ChatGPT ──专属插件──→ GitHub
ChatGPT ──专属插件──→ Notion
Claude ──自己写代码─→ GitHub ← 又写一遍
Claude ──自己写代码─→ Notion ← 又写一遍
Gemini ──另写一套──→ GitHub ← 再写一遍
Gemini ──另写一套──→ Notion ← 再写一遍
M 个 AI × N 个工具 = M × N 套集成代码
这就是"M×N 灾难"。如果有 10 个 AI 应用、100 个外部工具,你就要写 1000 套集成代码,而且每家协议都不一样,换个 AI 一切重来。
1.3 终极解法:USB 思维
2024 年 11 月,Anthropic 公司(Claude 的开发商)做了一件事:发布了一个开放协议,起名叫 MCP(Model Context Protocol,模型上下文协议)。
它的核心理念非常朴素——让全世界的 AI 和全世界的工具用同一种语言对话。
打个最直白的比方:
┌──────────────────────────────────────────────┐
│ MCP = AI 世界的 USB 接口标准 │
│ │
│ USB 出现之前: │
│ 打印机有打印机的接口 │
│ 鼠标有鼠标的接口 │
│ 硬盘有硬盘的接口 │
│ 每接一个新设备就得换一根线 │
│ │
│ USB 出现之后: │
│ 所有设备都用 USB │
│ 电脑只要支持 USB,就能接全世界的 USB 设备 │
│ │
│ MCP 之于 AI,就是 USB 之于电脑 │
└──────────────────────────────────────────────┘
只要一个工具按 MCP 标准做了一次,任何支持 MCP 的 AI 都能直接用。再也不用为每个 AI 重写一遍。
有 MCP 的世界(2025 年起):
ChatGPT ─┐ ┌→ GitHub MCP Server
Claude ─┤── MCP 协议 ──┤→ Notion MCP Server
Gemini ─┤ ├→ Slack MCP Server
Cursor ─┘ └→ 数据库 MCP Server
M 个 AI + N 个工具 = M + N 套集成
一次开发,全网通用
二、MCP 一年之内是怎么火起来的
很多协议提出来之后默默无闻。但 MCP 不一样——它在不到一年的时间里,从一家公司的提案变成了整个行业的事实标准。
来看一条简化的时间线:
2024 年 11 月 Anthropic 发布 MCP 协议,开源 SDK
★ 起步,没人敢说一定会成功
2024 年 12 月 Block(Cash App)、Apollo 等率先采用
★ 第一批吃螃蟹的
2025 年 03 月 OpenAI 官方宣布 ChatGPT 与 Agents SDK 支持 MCP
★★ 关键时刻,行业老大下场
2025 年 04 月 Google DeepMind 宣布 Gemini 系列支持 MCP
★★ 三大巨头齐了
2025 年 05 月 Microsoft 把 MCP 集成到 Windows、Copilot Studio
★ 操作系统级支持
2025 年 06 月 MCP 协议大版本更新(2025-06-18 spec):
- 工具注解(Tool Annotations)
- 结构化输出(Structured Output)
- 用户询问(Elicitation)
★ 协议趋于成熟
2025 年 09 月 官方 MCP Registry 上线,数千个 Server 可检索
2026 年 几乎所有主流 AI IDE、AI 助手都默认支持 MCP
Cursor、Windsurf、Zed、Replit、Continue……
★ 已经是 AI 时代的"水电煤"
如果你是开发者,你会切身感受到:今天写一个 MCP Server,明天就能被全世界的 AI 用上。
如果你是普通用户,你会感受到:你用的 AI 工具突然能干越来越多事了——它接上了你的代码仓库、你的文件、你的日程,甚至你公司的内部系统。
三、MCP 的核心架构:三个角色
要理解 MCP 怎么工作,只需要记住三个角色——Host(宿主)、Client(客户端)、Server(服务端)。听起来抽象,我们用一个生活场景类比。
3.1 把 MCP 想象成一家餐厅
┌────────────────────────────────────────────────────┐
│ MCP 三层架构 = 餐厅运转 │
│ │
│ Host(宿主) ≈ 餐厅本身 │
│ └── 你接触到的"店面",比如 Claude Desktop、 │
│ Cursor、ChatGPT App,负责整体体验 │
│ │
│ Client(客户端) ≈ 服务员 │
│ └── 在 Host 内部,负责跑堂——把你的需求传给厨房, │
│ 把菜端到你面前 │
│ │
│ Server(服务端) ≈ 厨房 / 后厨 │
│ └── 真正干活的地方:操作文件、查数据库、发邮件 │
│ 每个 Server 是一个"专项厨房": │
│ - 文件系统 Server = 中餐厨房 │
│ - GitHub Server = 西餐厨房 │
│ - 数据库 Server = 甜品厨房 │
└────────────────────────────────────────────────────┘
你(用户)只需要跟餐厅(Host)打交道。服务员(Client)替你跑前跑后,后厨(Server)做出真正的能力。后厨里多开几个分厨,餐厅就能上更多菜——这就是为什么 MCP 能让一个 AI 应用"接入万物"。
3.2 一次完整的"点菜流程"
用户:"看看我桌面上有哪些 PDF 文件"
│
▼
┌──────────────────────┐
│ Host (Claude) │ AI 大脑:理解需求,决定要调用工具
│ │
│ ┌─────────────────┐ │
│ │ Client │ │ 服务员:打开和文件系统 Server 的通道
│ │ │─┼─── MCP 协议 ────┐
│ └─────────────────┘ │ │
└──────────────────────┘ │
▼
┌─────────────────────┐
│ 文件系统 Server │
│ 扫描桌面,返回 PDF │
└─────────────────────┘
│
▼
["报告.pdf", "合同.pdf", ...]
│
▼
AI 用结果生成自然语言回答给用户
整个过程,用户始终只在和 Host 对话,完全不知道背后有 MCP 协议、有 Server、有 JSON 通信。这就是好协议的样子——隐形的水管。
四、MCP 给 AI 提供了哪些"能力插座"
MCP Server 不止能提供"工具"。它一共能提供四种能力,各有各的用处:
┌──────────────────────────────────────────────────────┐
│ MCP 的四种能力 │
├──────────────┬───────────────────────────────────────┤
│ │ │
│ Tools │ 工具:让 AI 能"做事" │
│ (工具) │ 例:发邮件、查数据库、写文件 │
│ │ ★ 最常用、最核心的一种 │
│ │ │
├──────────────┼───────────────────────────────────────┤
│ │ │
│ Resources │ 资源:让 AI 能"读到东西" │
│ (资源) │ 例:某份文档、某个 API 的返回 │
│ │ 类似"只读的数据通道" │
│ │ │
├──────────────┼───────────────────────────────────────┤
│ │ │
│ Prompts │ 提示词模板:让 AI 在特定场景按规矩办事 │
│ (模板) │ 例:"代码审查"模板、"翻译"模板 │
│ │ 用户在 UI 上选一下就能套用 │
│ │ │
├──────────────┼───────────────────────────────────────┤
│ │ │
│ Sampling │ 让 Server 反过来请 AI 帮忙生成内容 │
│ (采样) │ 例:Server 收集了一堆数据需要总结 │
│ │ ☆ 进阶能力,日常很少直接遇到 │
└──────────────┴───────────────────────────────────────┘
举个生活例子,理解为什么需要这么多种:
假设你雇了一个新助理:
- Tools = 你给他的工具箱(让他能做事)
- Resources = 你给他的资料柜(让他能查阅)
- Prompts = 你给他的工作手册(让他知道遇到 X 场景应该按什么流程做)
- Sampling = 助理需要帮忙时,可以反过来请你出主意
一个完善的助理应该这四样都有。MCP 给 AI 设计的能力体系,正是照着"完善助理"这个目标搭的。
五、MCP 是怎么"通话"的:传输方式
如果你只关心怎么用,这一节可以略读。但如果你打算自己装一个 MCP Server,有一个变化很重要:老的 SSE 传输已经被废弃了,新的叫 Streamable HTTP。
5.1 两种主流传输方式
┌────────────────┬──────────────────────────────────┐
│ 传输方式 │ 说明 │
├────────────────┼──────────────────────────────────┤
│ │ │
│ stdio │ 本地通信:Server 作为子进程跑 │
│ (标准输入输出) │ 适合:本地工具(读你电脑的文件) │
│ │ 特点:零配置、安全、最常用 │
│ │ │
├────────────────┼──────────────────────────────────┤
│ │ │
│ Streamable │ 远程通信:基于 HTTP 的双向流 │
│ HTTP │ 适合:云端服务、团队共享 │
│ │ 特点:支持认证、可扩展、能跨网络 │
│ │ ★ 2025 年起的官方推荐 │
│ │ │
└────────────────┴──────────────────────────────────┘
旧版的 HTTP+SSE 已经被官方标记为弃用(deprecated)
请新写的 Server 直接用 Streamable HTTP
简单说:
- 如果工具运行在你自己的电脑上(比如读取本地文件、查本地数据库),用 stdio,启动一个本地小程序就行。
- 如果工具运行在云端(比如某家 SaaS 提供的官方 MCP Server),用 Streamable HTTP,通过网络访问。
5.2 远程 MCP 的安全问题:OAuth 出场
让 AI 通过网络访问你的 GitHub、你的 Slack、你的银行账户……听起来就有点怕。MCP 在 2025 年的更新里把这件事正式纳入协议:
远程 MCP Server 现在要求使用 OAuth 2.1 认证:
你 ──→ "我想让 AI 操作我的 GitHub"
│
▼
AI 应用打开浏览器 → 跳转到 GitHub 授权页
│
▼
你点击"允许 AI 访问"
│
▼
GitHub 颁发一个有效期、有作用域的令牌(Token)
│
▼
AI 拿这个令牌去调用,只能做你授权过的事
关键点:
- AI 拿不到你的 GitHub 密码
- 令牌可以随时撤销
- 令牌权限范围由你决定(只读?还是可写?)
- 即使令牌泄露,影响也限定在那一份令牌的权限内
这个设计参考了你已经熟悉的"用 GitHub 登录某网站""用微信登录某 App"的逻辑——永远不交出密码,只授权特定动作。
六、看一眼:接入一个 MCP Server 长什么样
为了让你有个具体感受,看一眼最常见的"在 Claude Desktop 里接一个文件系统 Server"长什么样。整个配置文件就几行:
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/你的用户名/Documents"
]
}
}
}
翻译成人话:
"嘿 Claude,启动一个叫 filesystem 的 MCP Server。它的运行命令是
npx,后面跟着这些参数。允许它访问的目录是/Users/你的用户名/Documents。"
就这一段配置,你的 Claude 就拥有了"读写 Documents 文件夹"的能力。
配置之前的对话:
你:"帮我看看 Documents 里有什么 Word 文档"
Claude:"我没有访问你电脑文件的能力。"
配置之后的对话:
你:"帮我看看 Documents 里有什么 Word 文档"
Claude:(扫描了一下) "你 Documents 里有 12 个 .docx 文件,
其中最近修改的三个是:简历.docx、合同v3.docx、年终总结.docx。
需要我帮你做什么吗?"
这就是 MCP 给普通用户的直接价值:通过几行配置,让你的 AI 助手获得连接现实世界的能力。
七、MCP 生态:现在能用上的"工具箱"
到 2026 年初,MCP 生态已经非常丰富。简单分几类:
7.1 官方维护的常用 Server
┌─────────────────┬────────────────────────────────┐
│ Server 名称 │ 能干什么 │
├─────────────────┼────────────────────────────────┤
│ filesystem │ 读写本地文件 │
│ git │ 操作 git 仓库 │
│ github │ PR、Issue、代码检索 │
│ slack │ 收发 Slack 消息 │
│ google-drive │ 访问 Google Drive 文件 │
│ postgres │ 查 PostgreSQL │
│ sqlite │ 操作 SQLite │
│ fetch │ 抓取网页 │
│ memory │ 让 AI 拥有"长期记忆" │
│ puppeteer │ 控制浏览器(截图、爬取等) │
└─────────────────┴────────────────────────────────┘
7.2 第三方厂商的官方 Server
各大 SaaS 已经主动出官方 MCP Server,大致如下(还在快速增加中):
代码与协作:GitHub、GitLab、Linear、Jira、Notion、Confluence
聊天通讯:Slack、Discord、Teams、飞书、钉钉
数据库:PostgreSQL、MySQL、MongoDB、Redis、Snowflake、ClickHouse
云服务:AWS、Azure、GCP、Cloudflare
设计工具:Figma、Canva
办公:Google Workspace、Microsoft 365、Notion
浏览:Brave Search、Perplexity、Tavily
开发工具:Sentry、Datadog、Vercel
7.3 怎么找 Server
官方注册中心:registry.modelcontextprotocol.io
★ 2025 年 9 月上线,官方背书
社区目录: mcp.so、glama.ai/mcp、smithery.ai
★ 数千个第三方 Server,有点像"AI 时代的 npm"
源码仓库: github.com/modelcontextprotocol/servers
★ 官方示例和参考实现
八、2025 年后的新能力:MCP 协议的进化
如果你在 2024 年底接触过 MCP,2026 年再回来看,会发现协议本身长大了不少。重点说三个新东西,对日常使用都有切身影响:
8.1 工具注解(Tool Annotations)
每个工具现在可以"自报家门",告诉 AI 自己的"性格":
┌─────────────────────────────────────────────────┐
│ 工具注解的几种"性格" │
├─────────────────────────────────────────────────┤
│ │
│ readOnlyHint 这个工具不会改变任何东西 │
│ ★ 例:查询、读取 │
│ │
│ destructiveHint 这个工具可能造成破坏 │
│ ★ 例:删除文件、清空数据库 │
│ AI 应该多确认几次 │
│ │
│ idempotentHint 多次调用结果一样 │
│ ★ 例:设置某项配置为 X │
│ AI 可以放心重试 │
│ │
│ openWorldHint 会接触外部世界 │
│ ★ 例:发邮件、调用 API │
│ │
└─────────────────────────────────────────────────┘
这些标注让 AI 在调用工具前能更聪明地判断:"这个动作要不要先问用户?"——对应到产品里,就是为什么有的操作 AI 会直接做、有的会弹一个确认框。
8.2 用户询问(Elicitation)
以前 MCP 是"AI 问 → Server 答"的单向模式。新协议加了一种反向请求:Server 在执行任务时,可以让 Host 弹一个对话框,让用户填一些信息。
之前的尴尬:
AI:"我帮你建一个新仓库"
Server:(发现需要选择是公开还是私有,可它没法问用户)
Server:(只能默认选一个)
AI:"建好了,默认设为私有了"
你:"我其实想公开的……"
现在的样子:
AI:"我帮你建一个新仓库"
Server:"请用户选择:公开 / 私有 / 内部"
↓
Host 弹出选择框
↓
你点"公开"
↓
Server 用你的选择继续执行
这让 MCP 工具能处理更复杂的交互场景,而不只是"一问一答"。
8.3 结构化输出(Structured Output)
老版本里,工具返回的内容只能是文本。AI 拿到一段文本之后还得再"解析一遍"。新协议允许工具返回结构化数据(JSON),AI 能直接读懂,不容易看错。
传统输出(纯文本):
"用户列表如下:小明 25 岁、小红 30 岁、小李 28 岁"
AI 还得费劲从这段话里识别"姓名"和"年龄"
结构化输出:
[
{ "name": "小明", "age": 25 },
{ "name": "小红", "age": 30 },
{ "name": "小李", "age": 28 }
]
AI 直接知道这是 3 条用户记录
带来的实际好处:输出更准、更少幻觉、更适合做下一步处理。
九、MCP 怎么影响你
不同身份的人,从 MCP 拿到的好处不一样。对号入座一下:
9.1 如果你是普通用户
你以前用 ChatGPT/Claude,主要靠它"说"。现在,你的 AI 可以——
- 读你的本地文件、改你的文档
- 帮你查公司内部知识库
- 替你整理邮件、安排日程
- 在你授权的范围内操作 GitHub、Notion、Slack……
而且你不需要懂任何技术——大部分 AI 应用都已经把 MCP 配置做成"点几下就能装"的样子。
9.2 如果你是产品经理 / 设计师
你不用学怎么写 MCP Server,但你应该知道:
- 你的产品如果不打算自己做 AI,可以做一个 MCP Server,让用户在任何 AI 里都能用上你的产品
- 这是一种新的分发渠道——别人的 AI 流量,流到你的服务里
- 设计 AI 工具时,要考虑"如何让 AI 优雅地用我的功能",这是一种新的产品维度
9.3 如果你是开发者
- 不用为每个 AI 写一遍工具集成
- 写一次 MCP Server,所有支持 MCP 的 AI 都能用
- 自家公司的内部工具也可以做成 MCP Server,接入团队所有 AI 助手
- 学习成本不高,官方有 Python、TypeScript、Java、Go 等多种 SDK
9.4 如果你是企业决策者
- MCP 是"AI + 企业系统"集成的事实标准,新项目应该按这个方向走
- 内部 MCP Server 可以集中权限、审计、限流,比每个 AI 各自接系统更安全
- 私有 MCP Server 能让企业知识进入 AI,不用把数据交给外部模型训练
十、安全:把 AI 拉进你家之前的几条底线
MCP 让 AI 真的能"动手了",这意味着风险也是真的。简单总结几条对普通用户和团队都重要的原则:
┌────────────────────────────────────────────────────┐
│ 和 MCP 共处的安全底线 │
│ │
│ 1. 只装你信任来源的 Server │
│ └── 优先官方注册中心、官方 SaaS 提供的 Server │
│ └── 第三方 Server 等同于装第三方插件,谨慎对待 │
│ │
│ 2. 给 Server 最小权限 │
│ └── 文件系统 Server 只指向需要的目录 │
│ └── 数据库 Server 优先给只读账号 │
│ │
│ 3. 对"破坏性"操作多按一道确认 │
│ └── 删除、转账、发消息这类不可逆操作 │
│ └── 让 AI 先告诉你它要做什么,再点确认 │
│ │
│ 4. 用 OAuth,不要把密码塞进配置文件 │
│ └── 远程 Server 用 OAuth 2.1 │
│ └── 令牌可撤销、有作用域、有时效 │
│ │
│ 5. 留下日志,出事可查 │
│ └── Host 应该记录所有工具调用 │
│ └── 团队场景下日志要进集中审计 │
└────────────────────────────────────────────────────┘
一句话总结:把 MCP 想成"在家里给装修工人开门"——你愿意让他进来,但你会盯着他干哪些活、不会把所有钥匙都给他、走的时候要看一眼有没有少东西。
十一、MCP vs Function Calling:它们是什么关系?
上一篇我们讲过 Function Calling。很多人会问:MCP 是不是把 Function Calling 替代了?
答案是:不是替代,而是封装。
┌────────────────────────────────────────────────────┐
│ Function Calling vs MCP │
│ │
│ Function Calling = 模型本身的"能调用工具"机制 │
│ 一个底层能力,各家模型都有 │
│ │
│ MCP = 在 Function Calling 之上, │
│ 定义"工具应该怎么提供、 │
│ 怎么发现、怎么共享" │
│ 一个生态级的协议 │
│ │
│ 类比: │
│ Function Calling ≈ 电脑能插 USB 线 │
│ MCP ≈ USB 接口的物理标准 │
│ │
│ 没有 Function Calling,模型根本调不了工具 │
│ 没有 MCP,Function Calling 只能各家自玩 │
│ │
│ 两者搭配:模型用 Function Calling 决定"调谁", │
│ MCP 负责"工具从哪里来、怎么接进来" │
└────────────────────────────────────────────────────┘
实际产品里你看到的样子是:你点一下"安装某个 MCP Server",系统自动把这个 Server 提供的工具列表注册进 AI 的 Function Calling 通道。你看到的是"装了一个能力",底层是 MCP + Function Calling 配合工作。
十二、本篇小结
┌─────────────────────────────────────────────────┐
│ 本篇知识地图 │
│ │
│ MCP = AI 世界的 USB 接口标准 │
│ 一次接入、全网通用 │
│ │
│ 起源: │
│ └── 2024-11 Anthropic 提出 │
│ └── 2025 OpenAI、Google、Microsoft 全部跟进 │
│ └── 2026 已是行业事实标准 │
│ │
│ 架构: │
│ └── Host(餐厅) → Client(服务员) → Server(后厨) │
│ │
│ 四种能力: │
│ ├── Tools 工具(让 AI 做事) │
│ ├── Resources 资源(让 AI 读数据) │
│ ├── Prompts 模板(让 AI 按规矩办事) │
│ └── Sampling 反向请求(Server 请 AI 帮忙) │
│ │
│ 传输: │
│ ├── stdio 本地、零配置 │
│ └── Streamable HTTP 远程、官方推荐(2025起) │
│ │
│ 新能力(2025-06 协议大版本): │
│ ├── 工具注解 告诉 AI"我是只读还是破坏性" │
│ ├── 用户询问 Server 可弹框问用户 │
│ └── 结构化输出 工具直接返回 JSON │
│ │
│ 生态: │
│ ├── 官方注册中心 registry.modelcontextprotocol │
│ ├── 社区目录 mcp.so、glama.ai、smithery │
│ └── 数千个 Server,覆盖几乎所有主流 SaaS │
│ │
│ 安全要点: │
│ └── 信任来源 + 最小权限 + OAuth + 日志 │
│ │
│ 和 Function Calling 的关系: │
│ └── 不替代,是它之上的生态协议 │
└─────────────────────────────────────────────────┘
记住一句话就够:
MCP 是 AI 应用和外部世界之间的通用语言。
它把"AI 接入万物"这件事,从一次性的私活,变成了一次开发、全网通用的标准件。
十三、扩展学习资源
必读
- MCP 官方网站 —— 协议规范、教程、示例,一切的源头
- MCP 官方介绍博客(Anthropic) —— 官方的"为什么要做 MCP"
- MCP 官方 Server 仓库 —— 经典 Server 的源码
推荐
- MCP 官方注册中心 —— 官方背书的 Server 目录
- mcp.so —— 最大的社区 Server 目录之一
- Smithery —— 一键安装 MCP Server 的工具
- Claude Code 中的 MCP —— 在 Claude Code 里用 MCP 的实操指南
动手实践
- 在你的 Claude Desktop 或 Cursor 里装一个 filesystem Server,亲手体验一下"AI 操作我电脑文件"的感觉
- 翻一翻 mcp.so,挑一个你工作中用得到的 Server(比如 Notion / GitHub),装上,让 AI 帮你做一件以前要手动做的事
- 如果你写代码,选一个你公司内部小工具,用官方 SDK 把它包成 MCP Server,接到团队的 AI 助手里
> 下一篇预告:将讲解 Skill 系统与能力封装——如果说 MCP 给了 AI 一把"螺丝刀",那 Skill 就是把"如何装修一间房"打包成一种可复用的能力。它是比 MCP 更高一层的抽象,也是真正让 AI 像"老师傅"而不是"实习生"的关键。
觉得有用的话，点个关注吧!大模型方面你想看什么？留言区说，我来写。
声明：本博客内容素材来源于网络，文章由AI技术辅助生成。如有侵权或不当引用，请联系作者进行下架或删除处理。
