智能体 MCP 协议技术原理与应用实践

最新推荐文章于 2025-10-25 20:25:37 发布

范桂飓

最新推荐文章于 2025-10-25 20:25:37 发布

阅读量652

点赞数 22

CC 4.0 BY-SA版权

分类专栏： AI 技术原理与应用场景文章标签：人工智能

本文链接：https://blog.csdn.net/Jmilk/article/details/153050732

AI 技术原理与应用场景专栏收录该内容

30 篇文章

订阅专栏

MCP v.s. Function Calling

MCP 出现之前的主流是 Function Calling，但后者存在 2 个关键问题：

系统集成标准化需求：能够调用外部系统（数据、工具）是 Agent 的关键特征。但外部系统不具有标准时，代码维护大量 Tools 和系统集成的复杂度会非常高。如 OpenAI Function Calling API，只适用于特定 LLM 和平台，每个应用需要单独开发交互逻辑，难以复用和扩展。
上下文传输优化需求：Context 是 Agent 和 LLM 之间的传输对象，但 Agent 和 LLM 对话的过程中，往往需要维护复杂的 Context Updating 代码逻辑，难以高效地在 LLM 和外部系统间传递复杂上下文。

为此，Anthropic 于 2024 年 11 月推出 MCP（Model Context Protocol，模型上下文协议）作为一种以 Agent & LLM 为中心的开放标准通信协议，旨在简化与外部系统的集成架构和优化上下文传输的处理逻辑。

官网：https://modelcontextprotocol.io/docs/getting-started/intro

MCP 与 Function Calling 的处理流程的区别：
请添加图片描述

虽然 MCP 在某些方面和 RESTful API 以及 Function Calling 类似，但它们之间有很大的区别。
在这里插入图片描述

MCP 系统架构

MCP 是一个标准化的系统架构，在系统集成层面具有以下好处：

高可伸缩性与灵活性：在不修改现有工作流程的前提下，MCP 支持轻松集成新的工具和服务，满足不断变化的业务需求。
工具和服务的自动发现机制：注册 MCP 后，LLM 能够自动发现并集成相关的工具和服务。不再需要手动设置，提升了效率与便捷性。
降低开发复杂性：通过抽象化交互逻辑，减少代理开发的复杂性，使开发者能够专注于增强核心代理功能。
强化的安全性保障：采用成熟的安全传输层协议，确保数据与交互的安全可靠。
促进集体智能：通过标准化通信渠道共享见解和协调行动，使分布式 Agentic AI 系统能够实现单一架构无法实现的结果。

分层架构

如下图所示，MCP 处于 LLM 和 Agent 之间。
在这里插入图片描述

集成架构

请添加图片描述

MCP 系统的集成架构有 3 个核心组件：MCP Host、MCP Client 和 MCP Server。

MCP Host

定义：MCP Host 是希望通过 MCP 协议访问外部系统的 Agent 的运行环境。

功能：

提供用户界面，提供 Agent 的业务服务。
通过配置文件 config.json 来设置需要接入的 MCP 组件。
负责启动 MCP Client，通过 MCP Client 使用 MCP Server 的功能。
提供安全边界，用户授权，控制 Server 对 Host 环境的访问权限。

MCP Client

定义：通常作为 Agent 的一个功能模块，MCP Client 是和 MCP Server 保持 1:1 的协议连接，是连接 Agent & LLM 与 MCP Server 的桥梁。

功能：

连接管理：负责与 MCP Server 建立、维护和关闭连接，处理连接生命周期中的各种事件，如初始化、心跳检测和异常处理。
请求转发：将来自 Agent & LLM 的 request 转发到 MCP Server，并接受响应。
错误处理：负责处理连接和通信过程中可能出现的各种错误，并向上层应用提供适当的错误信息。
功能发现：负责查询 MCP Server 提供的能力，包括可用的 Resources、Tools 和 Prompts。

在 MCP 架构中，Host 和 Client 紧密协作。Host 提供 Agent 运行环境和安全边界，Client 负责具体的协议实现和通信管理。分层设计使 MCP 既灵活又安全，能够适应各种 AI 应用场景。

在这里插入图片描述

MCP Server

定义：是一个独立的、轻量的、作为 MCP Client 的服务器程序，同时也作为外部系统的前端程序，为 LLM 提供数据访问、工具执行和服务调用的能力。是连接 MCP Client 和外部系统的桥梁。通常的，每个 MCP Server 会专注于特定的功能领域，如文件系统操作、数据库访问、API 集成等。

功能：

能力抽象：通过 Resources、Tools、Prompts 的方式抽象外部系统的能力。
功能发布：负责与 MCP Client 建立连接，通过 MCP 协议向 MCP Client 公布这些功能。
请求转发：左边接受 MCP Client 的请求，右边将请求翻译并转发到外部系统，例如：API、DB、File、SSE、Internet 等。

Local / Remote Resources

MCP 还提供了 2 种核心资源：

Local Resources：运行在 MCP Host 本地环境，MCP Server 通过本地网络或协议进行安全访问的本地资源，例如：本地文件系统、数据库、应用程序等。敏感数据优先考虑本地执行，保障数据隐私和安全。
Remote Resources：运行在 Internet 外部环境，MCP Server 通过 Web APIs 进行安全访问的远程服务，例如：云存储、远程 API、在线服务等。

在这里插入图片描述

MCP 通信协议

MCP 通信协议定义了 Client 和 Server 之间的传输协议、通信模型、消息格式和通信规则。

MCP 是一种有状态、能保持上下文的通信协议，在通信的层面具有以下特性：

实时双向通信：区别于传统 REQ-RESP RESTFul API 模式，MCP 支持实时的、双向的、动态的发送与获取消息的能力，实现了信息的即时互通与流转。
卓越的上下文感知能力：在 Agent 和 LLM 交互的过程中，MCP 提供了标准化的 Context 容器字段来维护特定于会话的长期记忆，确保信息的连贯性与持续性，令 LLM 生成更理想的响应。
上下文传输性能：传统 JSON 格式输入 10K token 的上下文到 LLM 需 500ms+，而 MCP 压缩后仅需 20ms。并且局部更新（如新增对话）需重传全量上下文到 LLM，而 MCP 支持增量更新。

传输层（Transport Layer）

MCP 的 Transport Layer 采用了 JSON-RPC 2.0 结构化通信协议，支持多种数据传输方式，要求能够同时支持有状态和无状态请求调用。

Stdio（标准输入输出）
HTTP over SSE（服务器推送事件流）
Streamable HTTP

Stdio

Stdio 适用于本地集成，特别适合同一机器上的通信。Client 和 Server 通过 OS/Kernel 的 stdin、stdout、stderr 管道进行数据传输。

在这里插入图片描述

HTTP over SSE（已被替代）

HTTP over SSE 适用于基于网络的远程通信集成，以实现实时更新和持久连接。

Server 会启动 2 个 Endpoint：

SSE Endpoint：使用 Server-Sent Events 实现 S2C（服务器到客户端）的消息推送；
HTTP Endpoint：使用 HTTP POST 实现 C2S（客户端到服务器）的消息传递。

Client 和 Server 交互时，首先通过 SSE Endpoint 完成连接的建立，然后 Server 向 Client 推送一个 HTTP Endpoint，最后 Client 通过 HTTP Endpoint 向 Server 发送请求。

在这里插入图片描述
HTTP over SSE 存在明显的弊端：

需要长连接，消耗资源。
强依赖会话粘性，不利于水平扩容。
断开连接后，必须重新建立连接。

所以自 2025/03/26 之后就被 Streamable HTTP 所替代了。

Streamable HTTP（新引入）

Streamable HTTP 的 MCP Server 可以处理多个 Client 连接。

MCP Server 会提供一个 HTTP Endpoint，同时支持 GET 和 POST 请求。
MCP Client 发送消息需要包括 Accept header，支持 application/json 和 text/event-stream 类型。
MCP Client 通过 GET 请求打开一个 SSE stream，此时 Accept header 为 text/event-stream 类型。
如果要使用有状态的通讯方式，需要使用 Mcp-Session-Id header 进行传输。

协议层（Protocol Layer）

连接生命周期管理

MCP 的连接生命周期管理，管理的是 MCP Client 和 MCP Server 之间的交互状态及转换，它确保了整个交互过程中通信的稳健性与功能的可靠性。包括：Connection 初始化、Session 管理、版本与能力协商、用户授权与鉴权、用户权限控等。

在这里插入图片描述

MCP 连接的初始化机制确保了即使在不同版本或实现之间，MCP 协议也能够保持兼容性和可扩展性。

initial request（初始化请求）：启动 Client 后立即向 Server 发送 initial request，其中包含了 version 协议版本字段和 capabilities 能力协商字段。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "0.3.0",
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    },
    "capabilities": {
      "resources": {},
      "tools": {},
      "prompts": {}
    }
  }
}

initial response（初始化响应）：Server 利用自身的协议版本和能力进行响应。开始进行能力协商，声明 Server 支持的 capabilities，包括：prompts、tools、resources 等，仅协商成功的能力可在 Session 中使用。成功响应如下所示，但如果版本不兼容或请求无效，服务器会返回错误响应。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "0.3.0",
    "serverInfo": {
      "name": "example-server",
      "version": "1.0.0"
    },
    "capabilities": {
      "resources": {
        "list": {},
        "read": {}
      },
      "tools": {
        "list": {},
        "call": {}
      }
    }
  }
}

notification（通知）：Client 接受响应完成能力协商后，会再发送一个 initialized 初始化通知，确认连接成功建立。

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized",
  "params": {}
}

message exchange（消息交换）：连接准备就绪后，Client 和 Server 之间会建立一个 Session，用于维护 Connection Status、Context 和其他 Metadata。并且可以开始正常的消息交换了。

连接建立成功后，Client 会主动向 Server 请求当前可用的 tools/resources 清单及其描述信息。这些信息会由 Agent/Client 在必要时连同 User Query 一同被注入到 LLM 中。

在这里插入图片描述

而连接的终止可通过以下几种方式实现：

优雅关闭（Clean Shutdown）：Client 或 Server 通过调用 close() 方法实现。双方都有机会完成处理中的请求并清理资源。

{
  "jsonrpc": "2.0",
  "id": 999,
  "method": "shutdown",
  "params": {
    "reason": "user_request"
  }
}

强制终止（Forced Termination）：由于错误、超时或其他异常情况导致的意外关闭。
- 传输断开：当通信通道丢失时，会发生此情况。
- 错误条件：若遇到错误，也可能导致连接终止。

在这里插入图片描述

通信模式与消息体封装

初始化阶段之后，MCP 支持以下 2 种通信模式：

双向的请求-响应（Request-Response）模式：客户端或服务器均可发送请求，并由另一方作出响应。
单向的通知（Notification）模式：任何一方均可发送单向消息，无需对方响应。适用于状态更新、事件通知等场景。例如：在长时间运行的操作中，发送方可以通过特殊的进度 notification msg 实现。

Request-Response 通信模式中交换的 Message 类型有 3 种：

Request 消息体：发出请求，具有 id，method 和 params 字段。

{ "jsonrpc": "2.0", "id": 1, "method": "resources/list", "params": {} }

Result 消息体：请求成功的响应。具有 id，和 req-id 一一对应。

{ "jsonrpc": "2.0", "id": 1, "result": {} }

Error 消息体：请求失败的响应，具有 Code 和 Message。具有 id，和 req-id 一一对应。

{ "jsonrpc": "2.0", "id": 1, "error": { "code": -32601, "message": "Method not found" } }

MCP 定义了一套标准的 Error Code 以便有效地管理可能出现的问题。此外 Agent 还能够自定义错误代码，其范围起始于 -32000。

enum ErrorCode {
  // Standard JSON-RPC error codes
  ParseError = -32700,
  InvalidRequest = -32600,
  MethodNotFound = -32601,
  InvalidParams = -32602,
  InternalError = -32603
}

Notification 通信模式中交换的 Message 类型只有 1 种：

Notification 消息体：单向通知，无需响应。

{ "jsonrpc": "2.0", "method": "resources/updated", "params": {} }

在这里插入图片描述

功能层（Feature Layer）

MCP 的 Feature Layer 负责 Agent & LLM 的业务服务支撑，包括下列能力。

MCP Client 具有 Sampling（采样）、Roots（根目录）等扩展能力。
MCP Server 具有 Prompts（提示）、Resources（资源）、Tools（工具）三大核心能力。

这些能力都通过上文中的 2 种通信模式和消息体进行封装与传输。
在这里插入图片描述

MCP Client 能力

在这里插入图片描述

Sampling（采样）

Server 可请求 Client 访问 LLM 进行采样：

Server 请求 Client 访问 LLM，然后 Client 从 LLM 获取结果，并返回给 Server。
Client 可检查并可修改请求。这种人在循环（human-in-the-loop）设计确保用户对 Server 和 LLM 之间的交互保持控制。

Sampling 的相关操作请求：

sampling/createMessage：请求 LLM 生成内容。

在这里插入图片描述

Roots（根目录）

定义了 Server 可操作的 Host 文件系统的边界，以特定的安全访问目录作为 Root 目录。

Server 访问 Client 获得 Roots，主要用于文件系统路径，但也可以是任何有效 URI。
Server 以此来知悉资源访问范围，但仅具有指导性而非强制性。

在这里插入图片描述

MCP Server 能力

MCP 将各种数据源、工具和服务抽象为了 Resources、Tools、Prompts 这 3 大能力，标准化了调用方式，降低系统集成的复杂性。MCP Server 的代码实现通常基于外部系统提供的 SDK。

在这里插入图片描述

Resources

Resources 是 MCP Server 能够提供的数据资源，例如：文件内容、数据库记录、API 响应等数据资源。

每个资源都有 URI、name、description 和 MIME 类型等属性；
使用 URI 进行唯一标识；
Client 可以通过 resources/list 和 resources/read Endpoint 来发现和访问 Resource。

Resource 相关请求类型：

resources/list：列出可用的资源，
resources/read：读取资源内容
resources/subscribe：订阅资源更新
resources/unsubscribe：取消订阅资源更新

具有 2 种基本的 Resource 类型：

文本资源：包含 UTF-8 编码的文本数据。确保文件使用 UTF-8 编码，避免中文乱码。
二进制资源：包含以 base64 编码的原始二进制数据。

在这里插入图片描述

资源的 URI（统一资源标识符）通常由 MCP Server 定义，遵循以下格式：

[protocol]://[host]/[path]

例如：

# 本地文件
file:///home/user/documents/report.pdf
# 数据库模式
postgres://database/customers/schema
# 屏幕内容
screen://localhost/display1
# 来自 Web API 的数据
http://api.example.com/data
# Git 仓库中的源代码
git://repository/main/src

URI 也可以包含查询参数，进一步细化对资源的访问，例如：

weather://forecast?city=beijing&days=5

Client 可以直接通过 resource/list 来获取 Server 的静态资源列表，还允许 Client 通过 URI 模板来定义动态资源。例如：

# 获取特定城市的天气预报
weather://{city}/forecast
# 访问特定用户资料
user://{id}/profile
# 获取特定数据库表记录
database://{table}/{id}

URI 模板中的 {} 变量可以被 Client 替换为具体的值以创建有效的 URI。这使得 Client 能够动态构建资源请求，而无需预先知道所有可能的资源 URI。

Tools

MCP Server 能够提供的 Tools 工具集合，可被 LLM 发现和调用。Tool 的本质就是一个可执行函数，包含参数校验、结果处理、错误处理等逻辑。

具有 Unique name、description 和基于 JSON Schema 的输入参数定义。
Client 可以通过 tools/list 和 tools/call Endpoint 来发现和调用 Tool。
工具执行需要用户确认，确保安全性。

Tools 的执行是一个严格受控的多步骤过程，以此来提供 Human-in-loop（人工介入）、操作可靠和可观测。在工具执行过程，人类充当着关键的监督角色，是重要的安全机制。

批准或拒绝拟议的工具调用。
审查和可能修改调用参数。
评估工具结果和后续步骤。
提供额外的上下文或纠正错误理解。

MCP 也可以根据 Tool 的性质或用户偏好提供不同级别的审批要求，例如：

每次调用都需要批准。
仅对特定工具或参数范围需要批准。
批量批准类似操作。
为低风险操作提供自动批准。

在这里插入图片描述

Tools 相关请求类型：

tools/list：列出可用的工具。
tools/call：调用工具并执行操作。

在这里插入图片描述

Client 获取工具列表。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "cursor": "optional-cursor-value"
  }
}

Client 调用工具。

{  "jsonrpc": "2.0",  
   "id": 2,  
   "method": "tools/call",  
   "params": {
     "name": "get_weather",
       "arguments": {
         "location": "New York"
       }
    }  
}

Server 发送变更通知。

{  
   "jsonrpc": "2.0",  
   "method": "notifications/tools/list_changed"  
}

Prompts

Prompts 是 MCP Server 为 Resources、Tools 或特定使用场景所提供的提示词模板，支持参数化渲染和复用，帮助 LLM 生成特定类型的响应，例如：可以设计成多步骤的逻辑链，引导用户完成复杂的任务。保障了 MCP Server 运行的有效和稳定。

支持动态的参数渲染
支持嵌入资源上下文。
支持多个交互会话。
Client 通过 prompts/list 和 prompts/get Endpoint 来发现和使用 Prompt。

Prompt 相关请求操作：

prompts/list：列出可用的提示模板。
prompts/get：获取提示模板的内容。

在这里插入图片描述

MCP 上下文窗口

MCP 具有一个动态的 Context Window，用于存储会话记录（询问/回答）以及环境数据，会随每次交互而扩展。

同时，为避免数据过载，MCP 在保留关键细节的同时，也会将非关键信息压缩成 embedding 形式。例如：将 10 条消息的聊天内容概括为意图向量。

在这里插入图片描述

MCP 安全与信任机制

MCP 的核心原则之一是 ”安全可控”，LLM 能力的扩展不应以牺牲用户控制和数据安全为代价。

在这里插入图片描述

如上图所示。在设计层面，MCP 采用了多层安全模型：

本地优先：Server 默认在 Host 本地运行，减少网络风险。同时 Host 需获得用户同意后方可暴露数据。
用户确认：所有数据访问、工具调用需用户显式授权。
工具安全：工具调用需用户确认，描述信息需谨慎对待。
采样控制：采样 LLM 需用户批准，Server 无法直接读取全部上下文。
资源边界：通过 Roots 限制资源访问范围。
命令权限：Server 以用户账户权限运行，访问受限。
传输安全：支持加密传输和认证机制。

在实现层面，MCP 建议：

采用 TLS 安全传输协议。
采用 OAuth 2.0 进行身份验证。
采用 RBAC 进行权限控制。

在这里插入图片描述

MCP 工作流程

请添加图片描述
在这里插入图片描述
一个具体的 MCP 工作流程示例如下：

使用 LLM 应用总结代码库中最近的 5 次提交。MCP Host with Client 首先调用 MCP Server，询问有哪些可用的 Tools List。
然后 MCP Host 将这些 Tools 输入到 LLM。LLM 接收到这些信息后，会选择使用某个工具。然后 MCP Host 再向 MCP Server 发送具体某个工具的使用请求，并收到工具执行结果。
最后，MCP Host 将工具执行结果输入到 LLM。LLM 返回最终的响应结果给用户。

MCP 应用实践

Claude Desktop MCP

MCP 使用体验最典型的案例就是 Anthropic Claude Desktop。
在这里插入图片描述

环境信息：

macOS
Claude Desktop
MCP Server：FileSystem-mcp-server
权限要求：管理员权限、本地文件系统访问权限、网络访问权限

安装 Claude Desktop

Claude Desktop 作为 MCP Host 和 MCP Client。

下载地址：https://claude.ai/download

配置你的个性化需求。
在这里插入图片描述

MCP Server 配置文件解析

claude_desktop_config.json 是 Claude Desktop 的配置文件。

$ ll ~/Library/Application\ Support/Claude/claude_desktop_config.json

在这里插入图片描述

其中 MCP Server 配置的名称是 mcpServers，格式如下：

command：用于启动 MCP Server 的命令。对于运行在本地的 MCP Server 而言，启动命令通常是 npx（Node.js app）或 uvx（Python app）。
args：传递给 command 的启动参数，取决于 MCP Server。

{
  "mcpServers": {
    "server1": {
      "command": "命令名称",
      "args": ["参数1", "参数2", ...]
    },
    "server2": {
      "command": "命令名称",
      "args": ["参数1", "参数2", ...]
    },
    ...
  }
}

NOTE：

每次修改配置文件后，需要重启 Claude Desktop 应用才能生效。
确保 JSON 格式正确，否则 Claude Desktop 无法识别配置。

使用 FileSystem MCP Server

FileSystem MCP Server 是最常用的 Claude Desktop 官方扩展之一，支持以下功能：

read_file：读取指定文件的内容。
write_file：创建或修改文件内容。
file_info：获取文件的元数据，如大小、修改时间等。
list_directory：显示目录中的文件和子目录。
make_directory：创建新目录。
remove：删除文件或目录。
等

通过 Desktop UI 可以直接安装和配置。
在这里插入图片描述

配置 MCP Server config：

-y：自动确认所有提示，跳过确认步骤。
@modelcontextprotocol/server-filesystem：指定使用的 Filesystem MCP Server 的包是官方包（https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem），也可以指定用其他提供方的包。
最后一个参数：指定允许访问的目录路径。

$ vim ~/Library/Application\ Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/fanguiju/Documents"
      ]
    }
  }
}