前言

上一章讲完了Function Calling，大模型通过标准化的JSON格式，告诉Agent要调哪个工具、传什么参数。到这里，你已经理解了工具是什么、工具怎么被调用起来。

但实际开发Agent的时候，你会很快遇到下一个麻烦：工具集成本身，是个无底洞。

---

一、没有MCP之前：重复造轮子的噩梦

假设你正在开发一个Agent，需要它能读取GitHub代码仓库、查询公司数据库、操作本地文件系统、还能发Slack消息。

每一个工具，你都得自己来：

1. 自己研究这个工具的API文档

2. 自己把API封装成函数

3. 自己给每个函数写Function Calling定义（name、description、parameters）

4. 自己处理认证、错误处理、数据格式转换

光这四件事，就够你忙好几天。更麻烦的是，这些集成代码只能用在你这个项目里，团队里其他同学做类似的Agent，还得重新来一遍。

如果你的Agent还需要同时支持多个大模型，问题就更大了

• 10个工具 × 5个大模型 = 50套集成代码

• 不同模型的Function Calling格式还可能有细微差别，你要针对每个模型写适配层

• 哪天GitHub API升级了，50套代码你一个个去改

这还是基础设施代码，不是真正做产品该花时间的地方。

整个生态里，无数开发者都在重复做着同一件事：把GitHub、Slack、数据库、文件系统……这些常见服务接入自己的AI应用。每个人写一套，互相之间完全无法复用。

这就是没有统一标准时的现实——大家都在重复造同一个轮子。

---

二、MCP的出现：给AI工具世界定一个标准

这就是Anthropic在2024年11月推出的MCP（Model Context Protocol，模型上下文协议）的背景。

MCP要解决的核心问题，可以用一句话概括：

把工具的「写好」和「用起来」彻底拆开。

用USB-C来类比

在USB-C统一之前，各家手机厂商各有各的充电口：

• 苹果用Lightning

• 安卓早期用Micro-USB

• 各品牌之间完全不兼容，出门得带三四根不同的充电线

USB-C出来之后，只要设备支持USB-C，任何USB-C的线都能用，充电器、数据线全部通用。

MCP对于AI工具世界的意义，就和USB-C对于充电口的意义一模一样。

有了MCP之后

角色	只需要做什么
工具开发者	实现一套MCP Server，把工具能力按MCP协议暴露出来。之后所有支持MCP的AI应用，都能直接接入，不需要任何额外适配
AI开发者	只需要接入MCP Client，就能调用整个MCP生态里所有已有的工具，不用自己写任何工具集成代码

把N×M问题变成N+M

模式	工作量
没有MCP	N个工具 × M个模型 = N×M 套集成代码
有了MCP	N个工具各写一次MCP Server + M个应用各写一次MCP Client = N+M

然后任意组合，全部互通。

---

三、MCP的三大角色

MCP架构里有三个核心角色，弄清楚它们是谁、各自做什么，MCP就说明白一大半了。

1. Host（宿主）

Host就是你最终使用的那个AI应用，可以是：

• Claude Desktop

• 带AI功能的VS Code

• 或者你自己开发的Agent程序

Host是整个交互的起点——用户在Host里提问，Host决定要调用哪些工具来完成任务。

2. Client（客户端）

Client是Host内部的一个组件，专门负责管理和MCP Server的连接。

你可以把它理解为一个「连接器」：

• Host说「我要调用GitHub工具」

• Client就负责找到对应的MCP Server、建立连接、发送请求、拿回结果

每个Host通常会内置一个MCP Client，你不需要自己开发，直接配置就能用。

3. Server（服务端）

Server是对外暴露工具能力的轻量级服务程序。

• 一个MCP Server通常负责一类工具

• 比如：专门处理GitHub的MCP Server、专门操作本地文件的MCP Server、专门查询数据库的MCP Server

Server和Host可以运行在同一台机器上（本地Server），也可以部署在远程服务器上（远程Server）。对于Host和Client来说，这些细节完全透明，调用方式完全一致。

三者的关系（流程图）

text

用户提问
    ↓
   Host（AI应用，如Claude Desktop）
    ↓ （内置）
   Client（连接器）
    ↓ （通过MCP协议）
   Server（工具服务，如GitHub MCP Server）
    ↓
执行完毕，结果回传
    ↓
Host生成最终答案给用户

Host借助Client调用一个或多个MCP Server，Server执行完毕把结果回传，Host拿到结果后给用户生成最终答案。

---

四、MCP和Function Calling是什么关系？

学到这里，很多同学脑子里会冒出一个问题：

上一章学了Function Calling，说大模型通过Function Calling告诉Agent调哪个工具；这章又学了MCP，说Agent通过MCP来调用工具。这两个东西，到底有什么区别？MCP是不是把Function Calling给替代了？

完全不是。 Function Calling和MCP解决的是不同层面的问题，它们是配合关系，不是替代关系。

第一步：确认Function Calling工作在哪个层面

Function Calling解决的问题是：大模型做出「要调这个工具」的决策之后，怎么把这个决策用标准化JSON格式传给Agent。

这是大模型和Agent之间的通信协议，负责「大模型怎么开口下指令」这一段。

第二步：确认MCP工作在哪个层面

MCP解决的问题是：工具怎么被统一注册、统一发现、统一调用。

这是Agent和工具服务之间的连接协议，负责「Agent怎么找到并执行工具」这一段。

第三步：看两者怎么配合

把两者放进整个调用链条，位置就一目了然：

协议	负责段落	解决什么问题
Function Calling	上半段	大模型用标准格式告诉Agent「调哪个工具、传什么参数」
MCP	下半段	Agent通过MCP协议，找到对应的MCP Server，把工具真正执行起来

用一个具体例子把两者串联起来

还是查天气的场景，用户问「上海明天天气怎样」：

text

第1步：大模型通过Function Calling返回调用指令
       → 「调 check_weather，city=上海」
       【Function Calling层：大模型在开口下指令】

第2步：Agent里的MCP Client收到Function Calling指令
       → 通过MCP协议找到天气MCP Server，把请求路由过去
       【MCP层：Agent在找到并执行工具】

第3步：天气MCP Server调用真实的天气API，拿到结果，按MCP格式回传

第4步：大模型收到结果，整理成自然语言告诉用户

一句话总结

协议	本质
Function Calling	「说什么」的规范
MCP	「怎么找到并执行」的规范

少了Function Calling，大模型不知道怎么开口下指令；少了MCP，Agent不知道去哪里找工具来执行。两者分别在调用链的不同位置发挥作用，缺一不可。

---

五、MCP Server的三种能力

一个MCP Server可以暴露三种类型的能力，分别对应AI在不同场景下的不同需求。

1. Tools（工具）

这是MCP Server最核心的能力，也是和上一章讲的工具概念最直接对应的部分。

Tools就是AI可以主动调用执行的函数：

• 发邮件

• 查数据库

• 提交代码

• 搜索网页

AI调用Tool的机制，底层就是Function Calling。MCP在这之上做了一层标准化封装——你不需要手写每个Tool的Function Calling定义，MCP Server会自动按标准格式对外声明工具清单。

2. Resources（资源）

Resources是AI可以读取访问的数据：

• 文件内容

• 数据库记录

• 代码仓库

• 网页内容

Tools和Resources的区别

类型	本质	副作用	权限控制
Tools	「做一件事」	✅ 有副作用，会改变外部状态	需要更谨慎
Resources	「读一份数据」	❌ 只读，不会改变任何东西	相对宽松

这个区分很重要，因为AI系统通常对「会产生副作用的操作」需要更谨慎的权限控制——读数据和写数据，应该分开授权。

3. Prompts（提示模板）

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

当你有一些常用的、固定结构的提示词（比如「代码Review模板」「会议纪要生成模板」），可以把它们封装成MCP Prompts，在不同Agent项目里直接复用，不用每次重新写。

---

六、一次完整的MCP调用流程

用「帮我查一下GitHub上React仓库最近的commit」这个任务，走一遍完整的MCP调用流程：

步骤	谁	做什么
1	用户	在Host（比如Claude Desktop）里输入「帮我查一下React仓库最近的commit」
2	Host（大模型）	分析任务，判断需要调用GitHub工具，生成Function Call格式的调用指令
3	Host	把调用指令交给内置的MCP Client
4	Client	根据工具名，找到负责GitHub能力的MCP Server，把请求发过去
5	Server	GitHub MCP Server调用GitHub API，拿到最近的commit列表
6	Server → Client → Host	结果按MCP协议格式回传
7	Host（大模型）	拿到结果，整理成自然语言回复给用户

关键洞察

整个过程中，Host和背后的大模型完全不需要知道GitHub API的任何细节。它只管说「我要调GitHub工具」，剩下的事情MCP Server全权负责。

这就是「解耦」的价值：工具的实现细节，和AI的调用决策，完全分离。

---

七、一张表看懂：没有MCP vs 有MCP

对比维度	没有MCP（自己写集成）	有MCP
工具集成方式	每个工具自己写Function Calling定义、自己对接API、自己处理格式	直接接入已有MCP Server，工具现成可用
多模型支持	N个工具 × M个模型 = N×M套集成代码	N个工具 + M个模型，各写一遍标准接口，任意组合
跨项目复用	几乎不可能，每个项目重新写一遍	MCP Server一次实现，所有项目直接接入
工具API升级	所有集成代码都要跟着改	只需更新对应的MCP Server，所有Host自动受益
生态	各自为战，没有共享生态	全球开发者贡献MCP Server，接入即可使用海量现成工具
开发成本	极高，大量时间花在工具集成而非业务逻辑上	极低，专注业务逻辑，工具接入开箱即用

---

八、总结

整理一下这一章的核心认知：

1. MCP是什么？

Anthropic推出的开放标准协议，定义了AI应用和工具服务之间如何标准化通信。

它是AI工具世界的「USB-C」。

2. 为什么需要它？

没有MCP	有MCP
每个工具都要自己写集成	工具写一次，全平台可用
多模型场景下是N×M的重复工作量	把N×M问题变成N+M
工具升级要改所有集成代码	只改MCP Server，所有Host自动受益
没有共享生态	全球开发者贡献的MCP生态

3. 三大角色

角色	说明	类比
Host	AI应用（如Claude Desktop）	用电设备（手机）
Client	Host内部的连接器	充电线
Server	暴露工具能力的服务程序	充电头

4. 三种能力

能力	本质	副作用
Tools	可执行操作	✅ 有
Resources	可读取数据	❌ 无
Prompts	可复用模板	❌ 无

5. MCP和Function Calling的关系

协议	负责段落	本质
Function Calling	上半段：大模型→Agent	「说什么」的规范
MCP	下半段：Agent→工具服务	「怎么找到并执行」的规范

两者是配合关系，不是替代关系。缺一不可。