一、引文
在 LLM（大语言模型）飞速发展的今天，我们正从"对话框 AI"转向"智能体（Agent）"。然而，开发者在集成 AI 时一直面临一个巨大的痛点：数据孤岛。
为了解决这个问题，Anthropic 发布了 MCP (Model Context Protocol)。它被誉为 AI 时代的"USB 协议"。今天，我们就来彻底拆解 MCP 的含义、诞生原因、与 Function Calling 的关系，以及它的核心架构。
二、什么是 MCP
MCP (Model Context Protocol) ，即 模型上下文协议。
简单来说，它是一套开放的标准，允许开发者通过统一的方式，将本地或远程的数据源、工具和服务安全地连接到 AI 模型（如 Claude、GPT 等）。
官方定义：一种将 AI 应用程序与外部数据源和工具连接的通用标准。
形象比喻 ：在 USB 出现之前，打印机、鼠标、键盘都有各自奇怪的接口（串口、并口等）。USB 出现后，一个标准接口搞定所有外设。MCP 就是 AI 与外部数据世界之间的"USB 接口"。
三、MCP 诞生的原因
在 MCP 出现之前，如果你想让 AI 访问你的 Notion 笔记、读取 GitHub 代码或查询 SQL 数据库，你需要：
针对每个 API 编写特定的"胶水代码"。
在不同的 AI 平台（如 Claude Desktop, IDE, 自建 App）中重复实现这些集成。
手动管理复杂的上下文注入和权限。
这种现状导致了两个主要问题：
碎片化严重：每个工具都要为每个 AI 重写一遍插件。
上下文隔离：数据分散在不同地方，AI 很难获取完整、实时的背景信息。
MCP 的使命： 实现"一次编写，到处运行"。只要你写了一个 MCP Server（比如 GitHub 插件），任何支持 MCP 的 Client（比如 Claude 或 Cursor）都能立即使用它，无需重复开发。
四、MCP vs. Function Calling
很多人会问："这不就是 Function Calling（函数调用）吗？"
其实，两者层级不同：
维度 Function Calling (函数调用) MCP (模型上下文协议) 本质 模型输出一种格式化的 JSON，提示开发者去执行某个函数。 一套完整的通信协议，定义了客户端与服务器如何交换数据。 范围 局限于"模型告诉我怎么做"，逻辑由开发者手动实现。 涵盖了资源发现、工具调用、提示词模版等整套生态。 复用性 差。你为 App A 写的函数，App B 无法直接复用。 强。符合 MCP 标准的服务可以被任何支持 MCP 的软件直接连接。 动态性 静态。函数定义通常写死在 Prompt 或代码里。 动态。Client 可以实时查询 Server 具备哪些能力。 联系：
MCP 在底层利用了 Function Calling 的能力。当模型通过 MCP 决定使用某个工具时，它依然是发起一个调用请求，但 MCP 规范了这种请求的传输方式、安全认证和数据格式。
五、MCP 的核心架构
1.Host
这是用户直接使用的 AI 环境。
例子：Claude Desktop 客户端、IDE (如 Cursor, VS Code)、自建的 AI 聊天网页。
职责：它包含了 MCP Client，决定何时调用哪些 Server，并负责与模型进行最终的交互。
2.Client
存在于 Host 内部的协议实现层。
- 职责：它维护与各个 Server 的连接。它会向 Server 发送请求（比如："告诉我你有什么工具？"），并将 Server 返回的结果翻译给 AI 模型。
3. Server
这是连接具体数据源的"适配器"。
例子：一个连接 Google Drive 的 MCP Server，或者一个能执行 Python 代码的 MCP Server。
职责：
Resources (资源)：提供只读数据（如读取文件、数据库记录）。
Tools (工具)：提供执行动作的能力（如创建 GitHub Issue、发送邮件）。
Prompts (提示模板)：提供预设的指令模板。
工作流程图：
你的问题 → Claude Desktop(Host) → Claude 模型 → 需要文件信息 → MCP Client 连接 → 文件系统 MCP Server → 执行操作 → 返回结果 → Claude 生成回答 → 显示在 Claude Desktop 上。
这种架构设计使得 Claude 可以在不同场景下灵活调用各种工具和数据源，而开发者只需专注于开发对应的 MCP Server，无需关心 Host 和 Client 的实现细节。
六、Server 与 Client 传输层通信机制
在 MCP（模型上下文协议）的设计中，为了适应不同的应用场景（比如本地运行还是远程调用），官方定义了三种核心的传输层机制（Transport Mechanisms）。
虽然它们在底层都使用 JSON-RPC 2.0 进行消息交换，但"传球"的方式截然不同：
1.stdio
这是目前 MCP 最常用、最简单的一种方式，主要用于本地连接。
工作原理：
Host (宿主程序) （如 Claude Desktop 或 Cursor）直接启动 Server 作为一个子进程（Child Process）。
Client 和 Server 通过操作系统的
stdin（标准输入）和stdout（标准输出）进行通信。Client 向 Server 的
stdin写入 JSON 指令，Server 处理完后通过stdout把结果甩回来。特点：
极速且私密：数据不经过网络，全部在内存和本地管道中流动，安全性最高。
生命周期同步：当 Host 关闭时，Server 子进程也会随之被杀掉，不会残留后台进程。
配置简单 ：只需要在配置文件里写明
command（如node或python）和文件路径即可。适用场景：你电脑本地的工具，比如读取你本地代码库、操作本地文件、查询本地数据库。
2.SSE
这种方式主要用于远程连接 或跨网络通信。
工作原理：
Server 作为一个独立的 Web 服务器运行（通常基于 HTTP 协议）。
Client 通过 HTTP 发起连接。
双向通信实现：
从 Server 到 Client ：使用 SSE (Server-Sent Events)。这是一种长连接技术，允许服务器主动向客户端推送消息。
从 Client 到 Server ：使用普通的 HTTP POST 请求来发送指令。
特点：
跨设备能力：Server 可以部署在云端（如 AWS, Vercel），Client 可以在任何地方连接。
标准 Web 技术：利用了现成的 HTTP 基础设施，容易穿透防火墙。
复杂性略高：需要处理网络延迟、身份验证（Auth）和跨域（CORS）问题。
适用场景：集成云端 SaaS 服务（如实时天气、远程 CRM 系统）或者由第三方机构维护的公共 AI 工具。
3.Streamable HTTP
Streamable HTTP 是 MCP 协议较新推出的传输方式，简化了 SSE Transport 的双通道架构：
- Client 的请求通过 HTTP POST 发送，响应体可以是普通 JSON（简单请求），也可以是 SSE 流（需要流式返回或服务器主动推送时）
- 不需要预先建立 SSE 长连接，按需建立连接
- Server 可以在响应头里返回 Session ID，Client 后续请求带上这个 ID 来关联会话
相比 SSE Transport，Streamable HTTP 更简洁------不需要维护一个额外的 SSE 长连接通道，每个 POST 请求的响应本身就可以是流式的。
这是 MCP 协议目前主推的远程传输方式，适合企业级生产环境部署。
3.三种机制对比总结
| 特性 | stdio (本地管道) | SSE + POST (MCP远程标准) | Streamable HTTP (如 WebSockets) |
|---|---|---|---|
| 主要定位 | 本地插件、本地开发 | 跨网络、云端集成 | 实时高性能通信 |
| 实现难度 | 极简 (一行代码启动进程) | 中等 (标准 Web 开发) | 较高 (需处理状态机和心跳) |
| 穿透力 | N/A (不走网络) | 极强 (标准 HTTP 路径) | 一般 (常被代理服务器拦截) |
| 资源消耗 | 极低 | 低 (无状态 POST + 挂起 GET) | 较高 (服务器需维持大量长连接状态) |
| 调试便利性 | 一般 (需查看进程日志) | 极高 (浏览器控制台可见) | 一般 (需专用调试工具) |
| MCP 官方地位 | 核心标准 | 核心标准 | 暂非标准 (可能作为扩展) |
七、MCP 三大核心能力
在 MCP（模型上下文协议）中，Resources（资源） 、Tools（工具） 和 Prompts（提示模板） 是 Server 向 Client 提供的 三种核心能力。
如果把 AI 想象成一个"办公室职员"，这三者的关系可以这样理解：
Resources 是他桌子上的参考资料（只读）。
Tools 是他手里的办公器具（可操作、有结果）。
Prompts 是你给他的工作模版（教他怎么做）。
1.Resources
Resources 是 Server 暴露给 AI 的只读数据。它们是静态的或实时的信息，模型可以读取它们作为回答问题的上下文。
特点：通常是只读的。可以是本地文件、数据库内容、甚至是实时日志。
标识方式 ：每个资源都有一个唯一的 URI （类似于网址），例如
file:///logs/app.log或postgres://database/table/schema。使用场景：
读取一个本地的
README.md文件。获取数据库的表结构描述。
查看服务器的最新运行日志。
模型视角：模型知道这些资源的存在，当它需要背景知识时，会通过 Client 请求读取这些内容。
2.Tools
Tools 是 Server 提供的可执行代码/功能。它们允许 AI "采取行动"并对外部世界产生影响。
特点 ：动态执行。工具可以接受参数（Arguments），执行后返回结果。它具有"副作用"（Side Effects），比如修改文件、发送邮件。
交互逻辑：模型决定"我要用这个工具，参数是 X"，Server 执行并将结果返回给模型。
使用场景：
计算类：运行一段 Python 代码计算数学题。
API类：在 GitHub 上创建一个 Issue。
系统类：在本地创建一个新的文件夹。
模型视角 ：这是模型发现自己"能做的事"。比如模型发现自己不能直接联网，但看到有一个
google_search的 Tool，它就会调用这个工具。
3.Prompts
Prompts 是 Server 预先定义好的交互模版。它告诉 AI 应该以什么样的角色、逻辑和步骤来处理任务。
特点 ：包含占位符的可重用提示语。它不仅是简单的文字，还可以引导模型去关联特定的 Resource 或 Tool。
使用场景：
代码审查模板 ：一个名为
review-code的 Prompt，预设了检查逻辑，并要求用户传入"代码文件"作为参数。翻译助手：预设好"你是一个专业翻译官，请将以下文本翻译为 [语言]"的模版。
模型视角：这更像是用户或开发者给出的"指令捷径"。用户只需选择一个 Prompt 模板，剩下的上下文由 MCP 自动填充
八、总结
本文围绕模型上下文协议MCP展开介绍，先阐释其定义，再说明其诞生是为解决传统交互模式的局限。对比Function Calling仅输出格式化JSON、依赖开发者实现逻辑、复用性与动态性不足的问题，MCP作为完整通信协议，具备完善生态、强复用性与动态发现能力。其核心架构包含Host、Client、Server三大角色，支撑起Resources、Tools、Prompts三大核心能力，实现资源、工具与提示词模板的标准化交互。以及对比 MCP 中 Server 与 Client 传输层三种通信机制，阐释了不同场合下的传输层应用。MCP突破了函数调用的静态与碎片化缺陷，构建起标准化、可复用、动态互通的AI交互体系，为不同软件与模型服务的高效对接提供了统一规范，大幅提升AI工具与能力集成的灵活性和通用性。