当前位置：首页 > news >正文

AI Agent 学习day5 MCP 协议入门与实践

news 2026/5/31 1:56:15

MCP 协议入门与实践

一句话核心

MCP = 大模型调用外部工具的标准化协议。

Function Call 让模型“会调用工具”，但工具一多，就会出现定义难维护、跨语言难集成、权限难控制、调用难追踪的问题。MCP 的作用是在 Function Call 之上，提供一套统一的工具管理和调用标准。

为什么重要

Function Call 适合工具少的场景。

比如只有两个工具：

查年假
查订单

你可以手写 JSON Schema，然后用 if-else 路由。

但如果工具变成 20 个：

查考勤
查销售数据
查报销进度
查会议室
查库存
查物流
查合同

这时候问题就来了：

工具定义难维护：每个工具都要手写 JSON Schema。
工具发现困难：系统里有哪些工具，只能翻代码。
跨语言集成麻烦：Java、Python、HTTP API 都要单独适配。
权限和安全复杂：谁能调用哪个工具，需要自己写逻辑。
可观测性差：工具调用次数、耗时、失败率、调用链路都要自己埋点。

所以，MCP 不是为了解决“能不能调工具”，而是解决“工具规模化之后怎么管”。

核心知识点

1. Function Call 解决的是“调用工具”

Function Call 的核心能力是：

模型根据用户问题，判断是否需要调用工具，并输出结构化的调用意图。

比如用户问：

我还剩几天年假？

模型可能输出：

json { "function": "getUserAnnualLeave", "arguments": { "userId": "user_123" } }

然后由程序真正执行这个函数，再把结果交给模型生成回答。

一句话记忆：Function Call 让模型从“只会回答”变成“能调用工具”。

2. Function Call 的痛点是“工具多了管不住”

Function Call 本身不负责工具管理。

它没有解决：

工具怎么统一定义
工具怎么动态发现
工具怎么跨语言调用
工具权限怎么控制
工具调用链路怎么监控

所以工具少时 Function Call 很好用，工具多时就容易变成一堆 JSON Schema 和 if-else。

一句话记忆：Function Call 适合小规模工具调用，不适合大规模工具治理。

3. MCP 是“大模型世界的 USB 接口”

MCP 全称是 Model Context Protocol，模型上下文协议。

它的核心思想是：

只要工具实现了 MCP 协议，就可以被任何支持 MCP 的客户端调用。

类比 USB：

工具 = 鼠标、键盘、U 盘
AI 应用 = 电脑
MCP = USB 标准

没有 MCP 时，每个工具都要单独适配。

有 MCP 后，只要工具实现 MCP Server，Claude Desktop、Cursor、企业知识库助手等 MCP Client 都可以调用。

一句话记忆：MCP 让不同语言、不同系统、不同工具通过统一协议接入 AI 应用。

4. MCP 的三层架构：Host、Client、Server

MCP 架构主要分三层：

text Host 宿主应用 ↓ MCP Client 客户端 ↓ MCP Server 服务端

Host：用户直接使用的 AI 应用

比如：

Claude Desktop
Cursor
企业知识库助手
Ragent

职责：

接收用户输入，调用大模型，协调工具调用，展示最终结果。

Client：Host 内部的通信组件

职责：

和 MCP Server 建立连接，获取工具列表，发送工具调用请求，接收调用结果。

一个 Host 可以有多个 Client，每个 Client 通常连接一个 Server。

Server：真正提供工具的一方

职责：

声明自己有哪些工具，接收调用请求，执行工具逻辑，返回结果。

比如：

HR MCP Server：查年假、查考勤
Order MCP Server：查订单、查物流
Knowledge MCP Server：查知识库

一句话记忆：Host 面向用户，Client 负责通信，Server 提供工具。

5. MCP 的核心能力：Tools、Resources、Prompts

MCP 主要定义三类能力。

Tools：工具调用

最重要，也是最常用的能力。

比如：

查询年假
查询订单
查询天气
搜索知识库
执行数据库查询

Tools 对应 Function Call 里的“函数调用”，但区别在于：

MCP 的工具定义在 Server 端，Client 启动时可以动态发现工具列表。

Resources：资源访问

Resources 用来提供上下文数据。

比如：

文件内容
数据库记录
日志文件
配置文件

它更偏“读取资料”，不是“执行动作”。

Prompts：提示词模板

Prompts 是预定义的提示词模板。

比如：

代码审查模板
文档总结模板
SQL 优化分析模板

实际项目里 Tools 最核心，Resources 和 Prompts 了解即可。

一句话记忆：Tools 负责调用工具，Resources 负责提供数据，Prompts 负责复用提示词模板。

6. MCP 和 Function Call 不是替代关系，而是增强关系

MCP 不是替代 Function Call。

它们的关系是：

text Function Call：模型输出调用意图 MCP：管理工具定义、发现、通信和调用

Function Call 更像“发动机”，MCP 更像“整车”。

发动机让车能动，但真正上路还需要方向盘、刹车、仪表盘、接口标准。

一句话记忆：Function Call 负责让模型会调工具，MCP 负责让工具体系可管理、可复用、可扩展。

7. MCP 协议和 Spring AI 框架要分清

MCP 是协议，不是某个具体框架。

Spring AI 是 MCP 的一种 Java 实现方式。

MCP 协议层解决：

工具元数据格式
Client 和 Server 通信协议
工具发现机制
跨语言互通

Spring AI 框架层解决：

用 @Tool 注解定义工具
自动生成 JSON Schema
自动注册工具
封装通信细节

类比：

text MCP 协议 ≈ HTTP 协议 Spring AI ≈ Spring MVC

HTTP 是标准，Spring MVC 是方便写 HTTP 服务的框架。

MCP 是标准，Spring AI 是方便写 MCP Server 的框架。

一句话记忆：MCP 是标准，Spring AI 是实现这个标准的工具。

8. MCP 的两种传输方式

MCP 主要有两种通信方式。

Stdio：本地进程通信

Client 启动本地 Server 进程，通过标准输入输出通信。

适合：

本地开发
个人工具
Claude Desktop 本地插件
Cursor 本地工具

优点：

简单
不需要网络
不暴露端口
安全性较高

缺点：

只能本地使用
不适合团队共享

Streamable HTTP：远程 HTTP 通信

MCP Server 作为 HTTP 服务运行，Client 通过 HTTP 请求调用。

适合：

企业内部工具平台
团队共享工具
生产环境
远程服务调用

优点：

支持远程访问
支持多个 Client 连接
可利用 HTTP 生态做认证、监控、负载均衡

缺点：

需要网络配置
需要考虑认证和安全

一句话记忆：个人本地工具用 Stdio，团队和生产环境用 Streamable HTTP。

9. MCP 在 RAG 系统中的作用

RAG 本来解决的是：

先检索知识库，再让模型基于资料回答。

但 RAG 系统不一定只查知识库，还可能要调用业务系统。

比如用户问：

我的订单 12345 能退货吗？

这个问题需要两类能力：

查询订单状态：调用订单系统工具
查询退货政策：检索知识库

在 MCP 架构下，可以拆成多个 Server：

text Order MCP Server：查订单状态 Knowledge MCP Server：查退货政策 HR MCP Server：查年假考勤

Host 根据模型判断，调用不同 MCP Server，最后综合生成答案。

一句话记忆：MCP 可以把知识检索、业务查询、外部 API 都封装成标准工具，让 RAG 系统升级成更完整的 Agent 系统。

必要例子

例子 1：没有 MCP 的 Function Call

用户问：

查一下我的年假。

传统 Function Call 流程：

text 1. Client 端手写 getUserAnnualLeave 的 JSON Schema 2. 把工具定义发给模型 3. 模型输出 tool_calls 4. 代码用 if-else 判断调用哪个函数 5. 执行函数 6. 把结果返回给模型生成回答

问题是：工具一多，JSON Schema 和 if-else 会越来越难维护。

例子 2：有 MCP 之后

HR 团队提供一个 MCP Server：

text HR MCP Server: - getUserAnnualLeave - getUserAttendance - getSalaryInfo

订单团队提供一个 MCP Server：

text Order MCP Server: - getOrderStatus - getLogisticsInfo - getRefundStatus

Host 启动时自动连接这些 Server，获取工具列表。

用户问：

我的订单 12345 到哪了？

模型选择 getLogisticsInfo 工具，Host 通过 MCP Client 调用 Order MCP Server，拿到结果后生成回答。

好处是：

工具定义在 Server 端，Client 不用手写 JSON Schema，也不用为每个工具写一堆适配代码。

例子 3：MCP + RAG

用户问：

我的订单 12345 能不能退？

系统需要：

text 1. 调用订单 MCP Server 查询订单状态 2. 调用知识库 MCP Server 检索退货规则 3. 模型综合两个结果生成答案

这就不是单纯 RAG 了，而是：

RAG + 工具调用 + 多系统协同。

面试表达版

如果面试官问：MCP 是什么？

可以这样答：

MCP，全称 Model Context Protocol，是一种面向大模型应用的开放协议，主要用于标准化模型和外部工具、数据源之间的连接。Function Call 解决的是模型能不能调用工具的问题，而 MCP 进一步解决工具规模化后的管理问题，比如工具定义、动态发现、跨语言调用、传输协议、资源访问等。可以把 MCP 理解成大模型世界里的 USB 接口，只要工具实现了 MCP Server，任何支持 MCP 的 Host 或 Client 都可以调用它。

如果面试官问：MCP 和 Function Call 有什么区别？

可以这样答：

Function Call 是模型侧的能力，它让模型能够根据用户意图输出结构化的工具调用请求。MCP 不是替代 Function Call，而是在 Function Call 之上提供标准化的工具管理协议。Function Call 更关注“模型怎么发起调用”，MCP 更关注“工具怎么定义、发现、通信和复用”。简单说，Function Call 负责调用意图，MCP 负责工具治理。

如果面试官问：MCP 的架构是什么？

可以这样答：

MCP 主要分为 Host、Client、Server 三层。Host 是用户直接使用的 AI 应用，比如 Claude Desktop、Cursor 或企业知识库助手；Client 是 Host 内部负责和 MCP Server 通信的组件；Server 是真正提供工具的一方，负责声明工具、接收调用请求、执行工具逻辑并返回结果。一个 Host 可以连接多个 MCP Server，从而组合不同系统的能力。

如果面试官问：MCP 在 RAG 系统里有什么用？

可以这样答：

在 RAG 系统中，MCP 可以把知识库检索、业务系统查询、第三方 API 都封装成标准工具。比如用户问订单能不能退，系统可以一边调用订单 MCP Server 查询订单状态，一边调用知识库 MCP Server 检索退货规则，最后让模型综合生成答案。这样 RAG 就不只是查文档，而是可以连接真实业务系统，升级成更完整的 Agent 应用。