MCP 定义与核心作用

MCP 定义：由 Anthropic 于 2024 年 11 月提出，是一套开放的标准协议，旨在连接大模型（LLM）与外部系统（GitHub、本地数据库、API 等）。

核心价值：解决 Agent 插件不可复用、维护困难以及厂商割裂的痛点。它被誉为 AI 界的 “USB 接口标准”。

大模型交互的“铁三角”关系

大模型仅作为 “大脑”，无法直接与外部系统连接，所有外部交互必须通过 Agent 完成。

三者关系类似皇帝（大模型）、钦差大臣（Agent）和地方官员（外部系统）：皇帝通过钦差与地方官对接，钦差执行后向皇帝汇报，循环直至任务完成。

Agent 的核心循环任务：

Agent 持续循环执行三项任务：

1. 收集信息发送给大模型；

2. 解析大模型返回的结构化意图（Function Calling）；

3. 执行指令并将结果反馈给大模型。

工具调用清单与机制

• 工具清单约定：Agent 需与大模型预先约定工具清单（含名称、描述、参数类型、参数描述、是否必传等），每次交互时将清单发送给大模型，大模型从清单中选择指令返回给 Agent。

• 执行主体：大模型仅下达指令，最终执行由 Agent 完成（类比 “菜单给顾客，顾客不做菜”）。

大模型不会去做任何事情，它只是脑子，如果要去调用工具，也是通过agent去进行调用最终返回结果给大模型，但是Agent的插件是有限的，所以就得去拓展插件，如果给每个Agent都去编写插件的话，Agent的不同，插件也不好去复用，并且也很难去做维护，所以这个时候MCP出来了，可以去解决不同的模型，不同的Agent，都可以按照MCP规范去开发，这样插件就可以通用了。

交互模式对比：前 MCP 时代 vs MCP 时代

以前（纯Function Calling 逻辑）

在以前MCP并没有出现的时候，是怎么去交互的：

1. 在用户未提问之前，就得提前准备好 真实的工具函数（例如调用天气函数），并且还有一段 Json Scheme（给AI看的说明书）（如果有必要的话，可以去调用xx工具 并且提供xx参数）

2. 当用户发起提问的时候，Agent会将（prompt和上面的工具函数以及说明书）一起发送给内置的LLM（例如 OpenAI 或 Anthropic）

3. LLM的知识是旧的，它并不知道此时的天气，但是它知道有查询天气的工具，所以就委托agent去帮忙查询，并且提供一段查询天气的参数 city='纽约'，json格式，这就是Function calling

4. 此时，Agent要做的事情要从LLM返回的JSON中提取 函数名get_weather 以及对应参数

      a. 首先agent会在它的工具列表中遍历这个函数名 看看是否匹配

     并且返回结果为大模型

   

痛点在于：

1. 对于开发者而言，要写很多个工具，并且要写对应的json scheme （AI说明书），万一改动某个工具，又得重新修改对应的AI说明书。

2. 胶水代码，当LLM返回给对应的Agent内容时，Agent根据返回回来的函数名去查询，这导致会写大量的if-else 语句，并且当你想分享这个脚本给其他人时候，你不仅得给对应的脚本，还有Json定义，以及这块if-else 。。。

3. 不兼容，对应不同的LLM，不同的厂商对应维护的tools列表都不同，风格不同，导致脚本都不能复用，要改大量的配置，以及不同LLM能力不同，解析出来的结果也可能会导致差异化

4. 安全问题。。。。

现在（基于MCP协议）

MCP引入了标准化的三层架构：

MCP Host (宿主软件/环境)： 这是你直接打交道的软件，比如 Claude Desktop、Cursor 或者你公司自研的 AI 助手界面。它是“大管家”，负责整体环境的运行。

MCP Client (客户端/连接器)： 它通常内置在 Host 里面。它的工作是**“翻译”**。它负责维持与各种 Server 的连接，把 LLM 的意图翻译成符合协议的指令发给 Server。

MCP Server (服务器/功能提供方)： 这是真正的“打工人”。每个 Server 负责一项具体技能（比如查天气、查 GitHub、查数据库）。它通过 MCP 协议向 Client 宣告：“我会查天气，我需要 city 这个参数。”

，并且它不管LLM是谁，它只认 MCP 标准协议。你传入什么，我返回给你什么

交互举例：

1. 可以理解成当你新增一个 Weather-Server (内置get_weather 查询天气功能）的时候，这个时候MCP服务会和你的agent已经建立好了连接

2. 这个时候当用户提出问题的时候（比如查询纽约当日天气），agent会先进行解析prompt，然后把解析后的结果交给大模型（并且还有对应agent拥有的MCP一并发送给大模型），

3. 大模型的知识是旧的，它并不知道此时的天气，但是它知道有查询天气的工具，所以就委托agent去帮忙查询，并且提供一段查询天气的参数 city='纽约'，json格式，这就是Function calling

4. 当agent接收之后，它会把大模型的指令再发送给内置的MCP Client

5. 此时MCP Clinet 会将符合标准MCP协议的内容发送给MCP Server 例如json格式

{"method": "tools/call", "params": {"name": "get_weather", "arguments": {"city": "纽约"}}}

1. 当 Weather-Server 接收到指令，它就会查询对应的天气，并且返回结果给MCP Client

2. MCP Client接收之后，Agent也就知道了，并且将结果返回给大模型

3. 大模型再查询组织好回答返回给Agent，再返回给用户

MCP的出现解决了啥：

1. 解决重复开发：只需要按照MCP标准写一个MCP Server，所有支持 MCP 的软件（Host，如 Cursor、Claude、Windsurf）都能即插即用，只需要配置好对应的MCP

2. 解决维护逻辑胶水代码问题：MCP实现了自动发现，不需要写大量的JSON scheme AI说明书和if-eles去分拣AI的指令，当连接好了MCP，会告知AI：“我会干什么，我需要什么参数”，会自动路由到对应的函数

3. 。。。。。。。。。。

FC和MCP关系

Function Calling 是啥？

一句话讲，让大模型用 “结构化格式” 告诉你：它想调用哪个工具、传什么参数。

它输出的就是一段格式固定的 JSON 调用给Agent

不用被名称误导（函数调用），实际上它只清楚表达了一个动作，并没有去触发

FC所解决的是：让模型清楚要做什么

MCP解决的是：怎么被各自AI复用工具，怎么跨平台，怎么安全调用

为什么很多人MCP代替FC？

其实两个东西根本就不在一个维度上面的东西，FC是模型输出层（表达意图），另一个是工具执行层，所以说两者并不是一个代替关系，并且必须一起用

误区1：产品宣传话术（一般各大AI厂商为吹捧某项技术，就说xxx统一了，xxx被替代了）

误区2：以前的旧方案是LLM FC + 本地硬编码函数 + 私有调用 , 现在MCP来了替换了后面那堆私有工具调用，就误以为MCP代替了FC。

思考：

MCP的出现解决了很多很多问题，提供了一个很好的生态，但后续又带来了哪些问题呢？