超简洁易懂的MCP 完全解析：AI 世界的 USB-C，怎么连、怎么用、怎么不被坑

lincats

345人浏览 · 2026-08-16 18:54:04

lincats · 2026-08-16 18:54:04 发布

18 个月内，MCP 从每月 10 万次下载暴涨到 9700 万次，成了 AI 连接外部世界的标准方式。然而每天在用它的绝大多数人，仍然说不清它到底是什么。这篇文章用一个贯穿始终的类比，把它彻底讲透。

如果现在有人问起 Model Context Protocol 到底是什么，能给出一个清晰答案的人并不多。这个词已经无处不在，从 Claude、Cursor 到 ChatGPT 都在用它，但它到底解决什么问题、坐在智能体的哪个位置，多数人的理解还停留在「好像是一种连接工具」。

本文基于 Aishwarya Srinivasan 的讲解视频《MCP Complete Explanation》改写，用一个贯穿全篇的类比，把 MCP 是什么、怎么运作、与 function calling 和 API 的区别、如何安全接入、怎么自己写一个，一次讲清楚。

一个塞满充电器的抽屉

在理解 MCP 之前，得先感受它解决的痛点。设想正在构建一个 AI 应用，模型需要与数据库、CRM、文件系统甚至 Slack 对话。每一个这样的连接都是一次自定义集成，要单独去写、去测、去维护。

把这个规模放大，10 个 AI 应用配 100 个工具，就意味着潜在的上千个不同集成。这很像 USB-C 出现之前人人都有的那个塞满充电器的抽屉，每个设备一根线，彼此完全不通用。

MCP 要解决的，就是把这个「一设备一线」的局面，换成「一个接口通吃」。

MCP 是 AI 世界的 USB-C

MCP 就是 AI 世界的 USB-C。它是一个开放标准，最初由 Anthropic 在 2024 年 11 月发布，为「把 AI 模型连接到外部工具和数据」提供了一种通用语言。

构建一次连接器，任何兼容 MCP 的 AI 应用都能用它。不管是 Claude、ChatGPT、Cursor，还是自己搭建的自定义智能体，都共用同一个连接器，无需任何改写。

更关键的是，这已经不再是一家公司的事了。2025 年 12 月，Anthropic 把 MCP 捐给了 Linux 基金会，它从此成为一个厂商中立、社区治理的标准。这也是下载量爆炸式增长的根本原因，整个行业在「插头的形状」上达成了共识。

三个部件：Host、Client、Server

搞清楚 MCP 怎么运作，只需要抓住三个部件。过去眯着眼看过的每一张 MCP 架构图，在理解了这三个部件之后都会豁然开朗。

USB-C 的类比在这里依然贴切。Host 是 AI 应用本身，比如 Claude、Cursor、VS Code、ChatGPT，可以把它想成手机。MCP Client 住在 Host 内部，就是手机上的那个 USB-C 端口，负责说协议、管理连接，使用者几乎永远不需要看到它。MCP Server 则是插进来的外设，一个把工具或数据源包装成标准 MCP 格式的小程序。

无需被「server」这个词吓到。一个 MCP server 可以就是跑在本机上的 100 行 Python 代码。

一个 server 到底提供什么

一个 MCP server 对外提供三样东西，tools、resources 和 prompts。

用给新员工办入职来类比很好记。给员工软件权限，让他们能真正执行操作，这是 tools。给员工公司的 Wiki 页面，让他们能读到所需内容，这是 resources。给员工常见工作流的标准操作流程，那些是 prompts。

一句话概括，tools 是模型能做什么，resources 是它能读什么，prompts 是让它把任务做好的可复用模板。

真正优雅的地方在于发现机制。当 Client 连上来时，直接问一句「你有什么」，Server 就把自己的 tools、resources、prompts 连同描述和带类型的输入参数一起列出来。一切都在运行时动态发现，没有任何硬编码。正是这个发现步骤，让 MCP 相比手工接线集成有了魔法般的感觉。

MCP 坐在智能体的哪个位置

MCP 单独并不是智能体，这一点是多数讲解都会跳过的部分。当人们说「AI 智能体」时，真正在跑的是一个 harness，一个围绕模型的循环。

模型负责推理，harness 负责其余一切，管理记忆、跟踪状态、决定何时再走一轮循环，最关键的是在真实世界里执行动作。可以把智能体想成一个聪明的新员工，模型是大脑，harness 是工位和工作流程，而 MCP 是公司工牌，一个标准化的访问层，让智能体得以进入每一个被允许接触的系统。

整个循环只有三步。模型判定自己需要某个外部的东西，harness 把这个意图通过 MCP Client 路由到正确的 Server，Server 完成实际工作，结果流回模型的上下文，让模型继续推理。模型决策、harness 执行、MCP 连接，整套「舞蹈」就这三步。

这也是 MCP 会随智能体一起起飞的原因。一个智能体的价值取决于它能触达的系统，而 MCP 把「触达系统」这件事从定制化变成了标准化。

三组最容易搞错的对比

Function calling 是能力，MCP 是协议

这是第一大混淆点。Function calling 是模型的一种能力，模型看着任务，判定需要某个工具，随后生成一个带正确参数的结构化请求。MCP 则是承载这个请求、把它送到工具并带回结果的协议。

这两者各司其职，分属互补的两层。Function calling 回答的是「该不该打这通电话、该说什么」，MCP 回答的是「这通电话究竟怎么到达对端」。前者像是决定给某人打电话并拨号，后者则是电话网络，让任何一部电话都能打到任何另一部电话。两者缺一不可，用 MCP 构建时，function calling 依然在场，MCP 只是为它提供一个标准化的落地之处。

API 哪儿也不会去

普通的 API 是一个到某个服务的点对点连接，MCP 则是架在 API 之上的一层标准，让 AI 模型能以一致的方式发现并调用它们。API 仍然在工作，MCP 只是给每个模型提供同一种「找到它、跟它对话」的方式。所以如果有人声称 MCP 会取代 API，那便是完全没搞懂这套技术栈。

插件时代为什么悄悄落幕

回到 2023 年，ChatGPT 插件是当时的热门，而它恰好有个致命问题，插件是专有的，为一个平台构建，想把同样的能力带到别处就得重新构建一遍。插件就像是旧的专有充电器，每个品牌一根线。

MCP 翻转了这套模式。不再是每个 AI 平台各自开插件商店，而是只有一个开放协议，每个平台实现同一个端口。构建一次 server，就能在 Claude、ChatGPT、Cursor、VS Code 以及任何智能体框架上工作。这就是插件时代悄悄落幕的原因，连那些建了插件商店的平台自己都转向了 MCP。

先搜，再建

市面上的 MCP server 早已成千上万，最近一次统计超过 1 万个公开的，所以发现反而成了最容易的一步。三个去处值得记住。

官方 MCP registry 是权威词典，越来越多经过验证的发布者把 server 列在这里。GitHub 上的 modelcontextprotocol/servers 仓库提供文件系统、fetch、memory 等参考实现，是整个领域 star 数最多的仓库之一。像 Pulse MCP 这样的社区目录则适合按类别浏览，无论是 Notion、Postgres 还是 GitHub 的 server 都能找到。

一条经验法则是，动手构建之前先搜一搜，需要的那个集成很可能已经存在了。

具体用起来，MCP server 分本地和远程两种形态。本地 server 跑在自己的机器上，通过 stdio 与 Client 通信，适合处理本地文件、做实验。远程 server 托管在别处，通过 HTTP 连接，通常用 OAuth 认证，是大多数公司对外暴露产品的方式。

接入过程本身并不复杂。在 Claude Desktop、Cursor 或 VS Code 里加一小条配置，要么是启动本地 server 的命令，要么是远程 server 的 URL，重启之后 Client 自动处理握手并发现工具，随后正常与 AI 对话，它在需要时自然会调用那个工具。

几乎没人讲的安全问题

这部分是几乎所有 MCP 教程都不讲的，也是作者特别希望读者认真对待的内容。一个 MCP server 是能直达 AI 上下文、并且常常直达真实账号和数据的代码。随便装一个 MCP server，就像把一个在停车场捡到的 U 盘插进自己的笔记本，它可能就这么吓人。

数据也印证了这种担忧。一项独立普查发现，公开可用的 MCP server 里只有 13% 在文档、维护和可靠性上达到高信任门槛。2026 年初出现了几十起 CVE 工具投毒攻击，恶意指令被藏在工具描述里，另有一个托管平台存在路径穿越漏洞，实际暴露了数千个应用。这些都是已经真实发生过的攻击事件。

实践者的应对可以收敛成四条。

优先用经过验证发布者的官方 server，或运行前先读代码，代码通常小到真能读得完。
永远坚持最小权限，一个 server 只需要读数据，就只给它只读凭证。
对所有敏感或不可逆的操作保持人在环中，比如写入、删除或发送消息。
团队规模下，把 server 放在中心网关或内部 registry 后面，精确控制智能体到底能触达哪些 server，默认只读，敏感操作置于人工批准之后。

这套设置每天能处理数千次工具调用，却永远不会把「所有东西的钥匙」交给智能体。安全与规模化并不对立，护栏恰恰是让规模化得以实现的东西。

15 分钟，自己写一个

第一个可用的 MCP server，不过是一个 15 分钟的项目。Python 是最短路径，官方 Python SDK 内置 FastMCP，写一个带类型注解和 docstring 的普通函数，加一个装饰器，SDK 就自动把它变成描述完整的 MCP 工具。TypeScript 开发者用官方 SDK 同样扎实。

写好后用 MCP Inspector 测试，这是一个本地 Web 界面，能在任何模型触碰之前先手动触发工具。确认没问题，就把配置加进 Claude Desktop 或 Cursor 的配置文件，随后即可看到 AI 调用这段代码。

本周可以做的项目是，挑一个每天都在用的 API 或数据源，比如 Notion、天气 API 或数据库的只读视图，包装成一个跑在 stdio 上的工具，在 Inspector 里验证，先只接自己的 Client，只有当不止一个人需要时才升级到 HTTP 和 OAuth。大多数人第一个 server 都过度设计了，没有必要那么做。

最后记住一句话

如果只能从这篇文章里带走一点，记住这一点。MCP 属于「管道」那一部分，智能的部分由模型负责。眼下那些靠 AI 取胜的团队，恰恰是「管道」让模型真正触碰到真实世界数据的团队。

理解它、接入它、安全地用它，随后动手写出第一个 server。从「先搜再建」开始，把护栏搭好，剩下的交给管道去通。

附录　术语对照与来源说明

本文基于 Aishwarya Srinivasan 的讲解视频《MCP Complete Explanation》改写整理。文中观点与数据忠于原视频。

术语	说明
MCP	Model Context Protocol，AI 连接外部工具与数据的开放标准
Host	承载智能体的 AI 应用本身，如 Claude、Cursor、VS Code
MCP Client	Host 内部的连接端口，负责协议与管理连接
MCP Server	把工具或数据源包装成标准 MCP 格式的程序
tools / resources / prompts	模型能做什么 / 能读什么 / 可复用的任务模板
harness	围绕模型的执行循环，负责记忆、状态与动作
function calling	模型生成结构化工具调用的能力
stdio / HTTP	本地 server 与远程 server 的两种通信方式
registry	MCP server 的公开目录，如官方 registry 与社区目录