漫芽糖绘画app
38.89MB · 2025-11-14
本文来自微软MCP课程，我重新将内容进行了整理和翻译，去除掉了我自己认为的一些冗余内容，原文：
虽然，大模型使用起来非常容易，但随着应用使用时间的增加，你会期望AI可以集成各种功能和资源，比如访问电脑上的文件，或者想使用多个模型。随着应用规模的扩大，应用复杂度的提升，大模型的使用（更多大模型开发者的使用）越来越需要一个标准，这个标准就是Model Context Protocol（MCP)。
Model Context Protocol（MCP） 是一个开放、标准化的接口，允许大语言模型（LLMs）与外部工具、API 和数据源无缝交互。它提供了一种一致的架构，使 AI 模型的功能超越其训练数据，从而构建更智能、可扩展且响应更快的 AI 系统。
举个例子：假如你有一个非常博学的机器人，但他所有的知识都来自于几年前读过的书（这就像 AI 的“训练数据”）。他不知道今天的新闻，不会查天气，也不能帮你叫外卖。 MCP（模型上下文协议） 就像是给这个机器人配了一个万能插座和一堆智能工具（比如浏览器、计算器、外卖App）。 通过这个“万能插座”（也就是 MCP）：
Model Context Protocol（MCP）就像 USB-C 之于物理设备连接一样，为 AI 交互提供了通用标准。在 AI 领域，MCP 提供了一致的接口，使模型（客户端）能够与外部工具和数据提供方（服务器）无缝集成，无需为每个 API 或数据源开发不同的自定义协议。 在 MCP 下，兼容的工具（称为 MCP 服务器）遵循统一标准。这些服务器可以列出其提供的工具或操作，并在 AI 智能体请求时执行这些操作。支持 MCP 的 AI 智能体平台能够从服务器发现可用工具，并通过该标准协议调用它们。
在 MCP 出现之前，将模型与工具集成需要：
MCP 标准化的优势
| 优势 | 说明 |
|---|---|
| 互操作性 | LLM 可无缝使用来自不同供应商的工具 |
| 一致性 | 在不同平台和工具间行为统一 |
| 可复用性 | 一次构建的工具可在多个项目和系统中复用 |
| 加速开发 | 通过标准化、即插即用的接口减少开发时间 |
| 使用 MCP 的实际优势如下： |
MCP 采用客户端-服务器模型，其中：
MCP 服务器按以下方式运行：
---
title: MCP 架构与组件交互图
description: 展示 MCP 各组件之间数据流的示意图。
---
graph TD
Client[MCP 客户端/应用] -->|发送请求| H[MCP 宿主]
H -->|调用| A[AI 模型]
A -->|工具调用请求| H
H -->|MCP 协议| T1[MCP 服务器 工具01：网络搜索]
H -->|MCP 协议| T2[MCP 服务器 工具02：计算器]
H -->|MCP 协议| T3[MCP 服务器 工具03：数据库访问]
H -->|MCP 协议| T4[MCP 服务器 工具04：文件系统]
H -->|发送响应| Client
subgraph "MCP 宿主组件"
H
G[工具注册表]
I[身份验证]
J[请求处理器]
K[响应格式化器]
end
H <--> G
H <--> I
H <--> J
H <--> K
style A fill:#f9d5e5,stroke:#333,stroke-width:2px
style H fill:#eeeeee,stroke:#333,stroke-width:2px
style Client fill:#d5e8f9,stroke:#333,stroke-width:2px
style G fill:#fffbe6,stroke:#333,stroke-width:1px
style I fill:#fffbe6,stroke:#333,stroke-width:1px
style J fill:#fffbe6,stroke:#333,stroke-width:1px
style K fill:#fffbe6,stroke:#333,stroke-width:1px
style T1 fill:#c2f0c2,stroke:#333,stroke-width:1px
style T2 fill:#c2f0c2,stroke:#333,stroke-width:1px
style T3 fill:#c2f0c2,stroke:#333,stroke-width:1px
style T4 fill:#c2f0c2,stroke:#333,stroke-width:1px
MCP 通过扩展 AI 能力，支持广泛的应用：
除了提供工具，MCP 还促进知识访问。它使应用能够通过连接各种数据源，为大语言模型（LLMs）提供上下文。例如，一个 MCP 服务器可能代表公司的文档库，允许智能体按需检索相关信息；另一个服务器可能处理特定操作，如发送邮件或更新记录。对智能体而言，这些只是可使用的工具——有些返回数据（知识上下文），有些执行操作。MCP 高效地管理这两类功能。
智能体连接到 MCP 服务器后，会自动通过标准格式了解服务器的可用能力和可访问数据。这种标准化实现了动态工具可用性。例如，向智能体系统添加一个新的 MCP 服务器后，其功能可立即使用，无需进一步定制智能体的指令。
这种简化的集成与下图所示流程一致：服务器同时提供工具和知识，确保系统间无缝协作。
---
title: 使用 MCP 的可扩展智能体解决方案
description: 示意图展示用户如何与 LLM 交互，LLM 连接到多个 MCP 服务器，每个服务器同时提供知识和工具，形成可扩展的 AI 系统架构
---
graph TD
User -->|提示| LLM
LLM -->|响应| User
LLM -->|MCP| ServerA
LLM -->|MCP| ServerB
ServerA -->|通用连接器| ServerB
ServerA --> KnowledgeA
ServerA --> ToolsA
ServerB --> KnowledgeB
ServerB --> ToolsB
subgraph Server A
KnowledgeA[知识]
ToolsA[工具]
end
subgraph Server B
KnowledgeB[知识]
ToolsB[工具]
end
通用连接器使 MCP 服务器能够相互通信并共享能力，允许 ServerA 将任务委托给 ServerB 或访问其工具和知识。这实现了跨服务器的工具和数据联合，支持可扩展且模块化的智能体架构。由于 MCP 标准化了工具暴露方式，智能体可以动态发现并在服务器之间路由请求，而无需硬编码集成。
工具与知识联合：跨服务器访问工具和数据，支持更可扩展、模块化的智能体架构。
除了基本 MCP 架构，还存在更高级的场景：客户端和服务器端都包含 LLM，实现更复杂的交互。在下图中，客户端应用可能是一个集成多个 MCP 工具供 LLM 使用的 IDE：
---
title: 客户端-服务器 LLM 集成的高级 MCP 场景
description: 序列图展示用户、客户端应用、客户端 LLM、多个 MCP 服务器和服务器端 LLM 之间的详细交互流程，包括工具发现、用户交互、直接工具调用和功能协商阶段
---
sequenceDiagram
autonumber
actor User as 用户
participant ClientApp as ️ 客户端应用
participant ClientLLM as 客户端 LLM
participant Server1 as MCP 服务器 1
participant Server2 as MCP 服务器 2
participant ServerLLM as 服务器端 LLM
%% 发现阶段
rect rgb(220, 240, 255)
Note over ClientApp, Server2: 工具发现阶段
ClientApp->>+Server1: 请求可用工具/资源
Server1-->>-ClientApp: 返回工具列表（JSON）
ClientApp->>+Server2: 请求可用工具/资源
Server2-->>-ClientApp: 返回工具列表（JSON）
Note right of ClientApp: 本地存储合并后的工具目录
end
%% 用户交互
rect rgb(255, 240, 220)
Note over User, ClientLLM: 用户交互阶段
User->>+ClientApp: 输入自然语言提示
ClientApp->>+ClientLLM: 转发提示 + 工具目录
ClientLLM->>-ClientLLM: 分析提示并选择工具
end
%% 场景 A：直接工具调用
alt 直接工具调用
rect rgb(220, 255, 220)
Note over ClientApp, Server1: 场景 A：直接工具调用
ClientLLM->>+ClientApp: 请求执行工具
ClientApp->>+Server1: 执行指定工具
Server1-->>-ClientApp: 返回结果
ClientApp->>+ClientLLM: 处理结果
ClientLLM-->>-ClientApp: 生成响应
ClientApp-->>-User: 显示最终答案
end
%% 场景 B：功能协商（VS Code 风格）
else 功能协商（VS Code 风格）
rect rgb(255, 220, 220)
Note over ClientApp, ServerLLM: 场景 B：功能协商
ClientLLM->>+ClientApp: 识别所需能力
ClientApp->>+Server2: 协商功能/能力
Server2->>+ServerLLM: 请求额外上下文
ServerLLM-->>-Server2: 提供上下文
Server2-->>-ClientApp: 返回可用功能
ClientApp->>+Server2: 调用协商后的工具
Server2-->>-ClientApp: 返回结果
ClientApp->>+ClientLLM: 处理结果
ClientLLM-->>-ClientApp: 生成响应
ClientApp-->>-User: 显示最终答案
end
end
使用 MCP 的关键要点如下：
MCP 生态系统基于客户端 - 服务器模型构建。这种模块化结构使 AI 应用程序能够高效地与工具、数据库、API 和上下文资源进行交互。MCP中的一个host（宿主）应用程序可以连接到多个服务器。
在模型上下文协议中，MCP 宿主机是作为用户与协议交互主要接口的 AI 应用程序。宿主机通过为每个服务器连接创建专用的 MCP 客户端，来协调和管理到多个 MCP 服务器的连接。Host是协调 AI 模型交互的应用程序。它们：
客户端是维持宿主机与 MCP 服务器之间专用一对一连接的关键组件。每个 MCP 客户端由主机实例化，以连接到特定的 MCP 服务器，从而确保通信通道的组织性和安全性。多个客户端使得主机能够同时连接到多个服务器。 客户端是主机应用程序内的连接器组件。 它们：
服务器 是向 MCP 客户端提供上下文、工具和能力的程序。它们可以在本地（与主机同一台机器）或远程（在外部平台上）执行，负责处理客户端请求并提供结构化响应。服务器通过标准化的模型上下文协议暴露特定功能。 服务器是提供上下文和能力的服务。它们：
MCP Server提供了三个核心原语，定义客户端、主机和语言模型之间丰富交互的基本构建块。这些原语指定协议中可用的上下文信息和操作类型。 MCP 服务器可暴露以下三个核心原语的任意组合：
资源是为 AI 应用程序提供上下文信息的数据源。它们表示静态或动态内容，可增强模型理解和决策：
提示是可重用模板，帮助结构化与语言模型的交互。它们提供标准化交互模式和模板化工作流：
工具是 AI 模型可调用以执行特定操作的可执行函数。它们代表 MCP 生态系统的"动词"，使模型能够与外部系统交互：
在模型上下文协议中，客户端可以暴露原语，使服务器能够向主机应用程序请求额外的能力。这些客户端原语允许实现更丰富、更具交互性的服务器，从而访问 AI 模型能力和用户交互。
采样 允许服务器向客户端的 AI 应用程序请求语言模型补全。此原语使服务器能够在无需嵌入自身模型依赖项的情况下访问 LLM 能力：
启发 使服务器能够通过客户端界面向用户请求额外信息或确认：
日志记录 允许服务器向客户端发送结构化的日志消息，用于调试、监控和操作可见性：
模型上下文协议定义了主机、客户端、服务器和模型之间结构化的信息流。理解此流程有助于阐明用户请求如何处理以及外部工具和数据如何集成到模型响应中。
MCP 由数据层和传输层两个架构层次组成，它们协同工作以提供完整的通信框架。
数据层 使用 JSON-RPC 2.0 作为其基础来实现核心 MCP 协议。该层定义了消息结构、语义和交互模式： 核心组件：
传输层 管理 MCP 参与者之间的通信通道、消息帧和认证： 支持的传输机制：
MCP 包含几个内置的概念和机制，用于在整个协议中管理安全性和授权：
