专栏的上一章节聊了下大模型的智能化进程必备技术Function Calls，这章我们主要聊下最近很火的知识点MCP，很多人在网上都会听到大模型的博主或者文章不断的提到一个名词就是MCP。这章节我们主要聊下MCP的概念。
一、是什么
MCP (Model Context Protocol) 是一个由 OpenAI 推出的开放标准，它定义了大语言模型（LLM）与外部数据源、工具（如数据库、API、文件系统）之间如何安全、高效地通信和交换信息。
一个绝妙的比喻：模型世界的“USB协议”
把你电脑上的大模型（比如 ChatGPT）想象成一个超级大脑，但它是个“闭关修炼”的学者，只知道书本知识，不知道外面的世界。
现在，你想让这个“超级大脑”帮你：
读取公司服务器上的一个PDF文件。
查询一下今天的销售数据库。
帮你控制智能家居的灯光。
问题来了：大脑没有眼睛、没有手，它怎么去读文件、查数据库、开灯呢？
这就是 MCP 诞生的原因！MCP 就像是为这个“超级大脑”制定的一套“USB协议”。
大脑 (LLM)：电脑主机。
外部资源和工具 (数据源)：U盘、打印机、键盘、鼠标。
MCP 协议：USB协议标准。它规定了所有USB设备应该如何与主机通信、传输数据、获取电力。
MCP 服务器 (Server)：USB设备本身（比如你的U盘，鼠标，键盘）。它真正存储着数据或拥有执行操作的能力。
MCP 客户端 (Client)：电脑上的USB接口和驱动程序。它负责按USB协议的标准去识别设备、发起请求、读取数据。
有了MCP之后：任何厂商只要按照USB协议（MCP）去生产设备（开发Server），它就能即插即用（被LLM使用）。大脑（LLM）终于有了“眼睛”和“手”，可以感知和操作外部世界了！
二、MCP如何工作
要使用MCP，你需要理解三个核心角色和它们的工作流程。
核心角色
MCP 客户端 (Client)：
是什么：直接与大模型交互的应用。比如 Claude Desktop、Cursor Editor、你自己写的AI应用。
职责：代表用户向模型发送请求。当模型需要外部数据时，客户端会按照MCP标准向对应的Server发起请求，并将返回的数据整合给模型。
MCP 服务器 (Server)：
是什么：资源的提供者。它是一个独立的进程，负责管理特定的数据源或工具。例如：
一个专门连接公司 MySQL 数据库的Server。
一个专门读取 GitHub 仓库信息的Server。
一个可以操作 AWS S3 云存储文件的Server。
职责：监听客户端的请求，执行真正的操作（如执行SQL查询、读取文件列表），并将结果按MCP格式返回给客户端。
MCP 协议 (Protocol)：
是什么：连接Client和Server的通信规则。它基于JSON-RPC 2.0（一种轻量级的远程过程调用协议），规定了：
如何发现资源：Server能提供哪些数据或工具（称为
resources
tools
如何请求数据：Client应该如何请求一个文件或调用一个工具？
数据格式是什么：返回的数据应该长什么样？
工作流程（一次完整的请求）
假设你在Cursor编辑器里（Client）问：“帮我总结一下
/projects/my_app/src
建立连接：Cursor启动时，会加载并连接一个“文件系统MCP Server”。
发现能力：Cursor问Server：“你能提供什么？” Server回答：“我能提供
list_files
read_file
用户提问：你提出上述问题。“帮我总结一下
/projects/my_app/src
模型决策：Cursor内部的模型（如GPT-4）分析你的请求，意识到需要调用“文件系统Server”的
list_files
read_file
发起请求：Cursor（Client）按照MCP格式，向Server发送请求：“请调用
list_files
path=/projects/my_app/src
执行与返回：Server接收到请求，真正地去遍历那个目录，将文件列表按修改时间排序，返回前3个文件的路径给Cursor。
再次请求：Cursor再对这三个文件路径，逐个发送
read_file
整合与回复：Cursor将获取到的三个文件的内容发送给模型，模型根据这些实时上下文（Context），生成一个摘要回复给你。
整个过程，模型本身从未直接访问你的文件系统，它只是生成了“要调用什么工具”的指令，所有危险操作都由受你控制的Server完成，你的Server只是提供了这个服务，安全校验等操作都是Server自身来控制。
三、为什么要用MCP
1、解决了什么痛点？
在MCP之前，如果你想给模型接外部工具，通常有两种方式：
API集成：为每个工具写死代码，硬编码到应用中。缺点：工作量大、难以扩展、无法通用。
Function Calling：需要将工具的描述和权限在每次请求时都塞给模型。缺点：上下文窗口浪费严重，管理混乱。每次请求都是聚合了历史信息。很难管理，虽然现在提供了很多现成的封装好的方法，但是总体还是很浪费token。
2、核心优势
MCP通过解耦和标准化优雅地解决了这些问题。
标准化 (Standardization)：提供了一套统一的“插座”标准，避免了重复造轮子。任何符合 标准的Server可以被任何MCP Client使用。
安全性 (Security)：权限控制非常精细。你可以决定某个Server只能访问哪个特定文件夹，而不是整个硬盘。连接是本地的或受认证的，数据不会随意泄露到公网。
可扩展性 (Extensibility)：生态可以蓬勃发展。社区可以为你需要的任何资源（Notion、Jira、Google Drive等）开发MCP Server，你只需简单配置即可使用，无需修改Client应用。
效率 (Efficiency)：Server与Client分离，可以独立优化和部署。资源发现机制避免了在每次提问时都向模型传递大量的工具描述，节省了宝贵的上下文窗口。
3、如何开始使用？(Action!)
作为一个AI初学者，你可以通过以下路径逐步掌握MCP：
体验现有生态（最简单）：
下载 Claude Desktop 应用。它原生支持MCP，是其最主要的Client之一。
去MCP社区的GitHub（如
mcp-github
filesystem
学习编写配置：
学习MCP的
client.json
探索现有Server：
访问 MCP Hub 或 MCP Samples。这里有大量现成的Server，比如用于SQL、网页抓取、日历等的Server。尝试把它们配置到你的Client中。
尝试开发（进阶）：
当你熟悉了概念后，可以尝试用你熟悉的语言（Python/java/go等）编写一个简单的MCP Server。比如写一个Server，它可以返回当前时间或者查询你本地的待办事项列表。官方提供了完善的SDK，入门并不难。
总结一下：
把 MCP 理解为AI时代的“USB标准”。它让大模型能即插即用地使用各种外部资源和工具，极大地扩展了模型的能力边界。对于你日常工作的价值在于，你可以通过简单地“插拔”不同的MCP Server，让你使用的AI助手（如Cursor, Claude）轻松获得操作公司内部数据、API的能力，而无需等待应用厂商原生集成。
从今天开始，就去下载一个Claude Desktop，给它配置一个文件阅读Server，亲身体验一下这种“即插即用”的威力吧！这是你从AI初学者迈向AI应用构建者的重要一步。想要玩明白动动手就能真正的理解AI。然后对其祛魅。
四、Function Calls 和 MCP的区别
你看上面的描述赶紧跟Function Calls 差不多的功能，下面我们聊聊二者的区别。
它们不是相互竞争的技术，而是解决不同层面问题的、互补的方案。理解它们的区别，能让你在正确的场景选择正确的工具。
我们先从一个最精辟的总结开始：
Function Calling 是 “战术级” 的武器。它解决单次对话中“如何让模型指挥一个特定动作”的问题。它是一次调用方法。
MCP 是 “战略级” 的基础设施。它解决整个应用生态中“如何为模型安全、标准地接入无数资源和工具”的问题。它是一个标准协议。
牛逼的东西要用牛逼的比喻，我们用一个军事比喻：
Function Calling (函数调用)：
就像你给一名特种兵（大模型）配发了一把标准化的步枪（一个函数）。
你告诉他：“这是步枪（函数说明书），它可以射击（功能），你需要告诉我目标位置（参数）。”
在一次任务（一次对话）中，士兵看到敌人（用户意图），就会请求使用步枪（决定调用函数），并报出坐标（生成参数JSON）。但他只能使用你这次给他的这把步枪。不能使用火箭筒或者其他的武器。
MCP (模型上下文协议)：
就像你为整个军队建立了一套全球标准化后勤系统（MCP协议）。
这套系统规定了一切：如何申请物资、集装箱尺寸、运输流程等。
现在，任何供应商（Server开发者）只要按照这个标准（MCP）生产物资（工具和数据），比如坦克、飞机、午餐肉罐头，都可以被及时送到任何一支符合该标准的部队（MCP Client，如Claude、Cursor）手中。
特种兵（大模型）不再局限于自己背着的步枪，他可以通过后勤系统（MCP）呼叫炮火支援（数据库查询）、空中侦察（网络搜索）、或者请求送一顿热饭（读文件）。
这个比喻的精髓在于：
Function Calling 的“武器”是临时赋予的，一次性的。它只认识你给他提供的武器，别人做的武器它就不会用也不认识。
MCP 的“后勤系统”是永久性的、可扩展的，随时可以提供任何需要的“武器”和“物资”。
详细对比表格
| 特性 | Function Calling | MCP (Model Context Protocol) |
|---|---|---|
| 层级 | 应用层特性 | 协议层标准 |
| 核心目标 | 在单次对话中，让模型触发一个特定动作。 | 为模型构建一个可扩展的、安全的工具和数据生态。 |
| 工作范围 | 一次API调用/一次对话。工具定义随请求发送。 | 持续整个会话周期。工具在会话开始时连接，随时可用。 |
| 工具管理 | 临时、内置。工具列表和描述必须在每次请求时通过 |
永久、外挂。工具通过独立的Server提供，在Client启动时一次配置，长期有效。 |
| 耦合性 | 紧耦合。工具逻辑通常硬编码在你的应用程序中。 | 松耦合。Client（应用）和Server（工具提供者）完全解耦，通过标准协议通信。 |
| 扩展性 | 差。添加新工具需要修改应用程序代码并重新部署。 | 极佳。添加新工具只需配置一个新的MCP Server，无需修改Client应用。 |
| 安全性 | 由应用开发者控制。权限较粗放。 | 精细权限控制。可以为每个Server单独配置可访问的资源（如只能读某个文件夹）。 |
| 技术本质 | 一种API参数（ |
一个基于JSON-RPC的开放网络协议。 |
| 好比是 | 给你一把瑞士军刀（功能固定，随身携带）。 | 给你一个能召唤任何工具的万能工具箱，工具由专家无限提供（即插即用，生态丰富）。 |
工作流程对比（一看就懂）
Function Calling 流程（以查询天气为例）：
你的代码：构造API请求，在
messages
"旧金山天气?"
tools
get_weather
模型：看到问题和工具，决定调用
get_weather
{"location": "San Francisco"}
你的代码：执行自己写的
get_weather
你的代码：将天气结果再次发送给模型，让模型生成最终回复。
关键点：第1步中，工具的说明书每次都要传递，浪费Token且低效。
MCP 流程（以查询天气和数据库为例）：
事前配置：你在Claude Desktop（Client）的设置文件中，配置好两个MCP Server：
weather-server
company-db-server
启动连接：Claude启动，自动连接这两个Server，并询问它们：“你们能提供什么工具？” Server回复：“我能提供
get_weather
query_sql
用户提问：你问：“说说旧金山的天气，并对比一下我们公司上月在加州的销售额。”
模型决策：Claude内部的模型分析后，意识到需要同时调用两个工具。它通过MCP协议分别向两个Server发送请求。
执行与返回：两个Server独立工作，分别获取天气和数据库数据，返回给Claude。
整合回复：Claude将两份数据整合，生成一个聪明的回答。
关键点：工具是预先连接、随时待命的。模型可以像使用内置能力一样自由组合多个工具，无需你在代码中硬编码逻辑。
如何选择？给你最直白的建议
使用 Function Calling ：
你的应用功能简单、固定。
工具的数量很少，且不会经常变化。
你正在快速构建一个原型或一个特定的AI功能。
工具逻辑完全由你的应用自己控制，不需要外部生态。
使用 MCP ：
你希望你的AI应用（如智能助手）能力可扩展，能轻松接入新的数据源和工具。
你不想每次加新工具都修改代码和重新部署应用。
你需要精细的安全控制，对不同工具设置不同权限。
你希望利用社区生态，直接使用别人写好的工具（Server），而不是什么都自己从头开发。
终极总结
如果说 Function Calling 让大模型学会了“用手”（调用一个函数），那么 MCP 则是为它建造了一个“全球武器库和后勤网络”，让它能随心所欲地使用全世界最专业的“工具手”。
对于你个人日常使用，可以先从体验MCP Client（如Claude Desktop）开始，感受它“即插即用”的强大能力。当你需要开发自己的AI应用时，再根据功能的复杂度和扩展性需求，在Function Calling和MCP之间做出选择。简单玩一玩就Function Calls，企业级别的应用，直接搞MCP吧。
暂无评论内容