MCP
MCP是一种开放协议，它标准化了应用程序向大型语言模型(LLM)提供上下文的方式。可以将MCP想象成AI应用的USB-C接口。就像USB-C为设备连接各种外设和附件提供标准化方式一样，MCP为AI模型连接不同数据源和工具提供了标准化方法。
深入理解MCP：从LLM的本质说起
为了深入理解MCP，我们需要先回顾一下LLM和AI应用的历史发展。
LLM的本质
LLM本质上只是简单的token生成器。它们只是逐个预测下一个token，本质上是文本生成器。这一点并不总是那么显而易见，因为在如今具有代理行为(Agentic)的系统中，人们往往认为LLM具有超能力，可以完成各种任务。
但实际情况是：
- LLM只能输出文本，或者如果是多模态LLM，也可以输出图像和其他格式
- 它们绝对不能直接执行外部操作
- 搜索网络、执行深度研究推理或调用Python函数等额外功能实际上是集成到运行LLM的应用程序中的外部工具
工具使用的实现机制
例如， 当你使用ChatGPT并启用网络搜索选项时，背后实际是OpenAI工程师编写的外部代码在工作，而非LLM本身的能力。
LLM工具调用的工作原理是：
- 使用精心设计的系统提示(system prompt)
- LLM不直接回答问题，而是生成工具调用格式的文本（如"get_weather(city='New York’)"）
- 这种工具调用使用特定格式，便于解析函数名称和参数
- 应用程序解析这个输出，执行相应的外部功能
- 执行结果再与原始查询一起送回LLM生成最终回答
这就是几乎所有AI代理的基本功能。需要注意的是，由于LLM是基于统计的系统，工具调用机制并不能保证100%正确，但在大多数情况下效果相当不错。
第一步，“使用精心设计的系统提示”，下面是一个示例：
注意第二条和第五条，它是整个Agentic工具的核心工作原理
MCP的定位和作用
MCP让开发者可以专注于编写这些工具并将它们暴露在MCP服务器中。我们编写的这些工具可以被所有支持函数调用的应用程序使用，包括:
- ChatGPT (他们已宣布将支持MCP)
- Claude Desktop
- Cursor
MCP实质上是简化了开发者创建和部署可供大型语言模型调用的工具的平台，让专业功能可以更容易地集成到AI系统中。
MCP协议详解：组件交互与工作流程
让我们了解下MCP协议的核心机制，以及各组件之间如何交互协作。
MCP架构组成
在MCP协议架构中，有几个关键组件：
- 用户：发起查询的主体
- 应用程序(APP)：如Cursor、Cloud Desktop或任何集成MCP的应用
- 语言模型(LLM)：处理用户查询并决定工具调用
- MCP服务器：提供工具和资源的服务端
- MCP客户端：内置于应用程序(APP)中的组件，负责与MCP服务器通信
值得注意的是，一个APP应用可以包含多个MCP客户端，每个客户端连接到不同的MCP服务器。
MCP工作流程
1.初始化阶段
当我们启动应用程序时，首先发生的是连接建立：
- 应用内的MCP客户端向MCP服务器发起连接请求
- MCP服务器确认连接，双方建立通信通道
- MCP服务器向客户端告知其提供的所有可用工具、资源和提示(Tool, Resource, Prompt)
这一切都发生在用户交互之前，是应用启动时的预处理阶段
2.用户查询处理阶段
当用户发送查询后：
- 应用程序将用户查询与可用工具信息一起转发给LLM
- LLM分析后，可能直接回答或决定调用某个工具, 如需调用工具，语言模型会指定工具名称和所需参数
3.工具执行阶段
这是MCP与其他框架(如LangChain)的关键区别：
- MCP中，工具执行发生在MCP服务器端，而非应用层
- 应用通过MCP客户端将工具调用请求发送给MCP服务器
- MCP服务器执行工具操作并返回结果
这种解耦设计使系统更易扩展、监控和部署
4. 结果处理阶段
- MCP服务器将工具执行结果返回给客户端
- 应用程序将用户查询和工具结果再次发送给LLM语言模型
- LLM决定是结束会话还是继续调用其他工具
最终答案通过应用程序呈现给用户
MCP架构的独特优势
- 解耦工具执行与编排逻辑：应用负责决策何时调用工具，而MCP服务器负责实际执行
- 动态工具更新：服务端工具可以独立更新，客户端定期初始化获取最新工具
- 简化部署与扩展：服务端可独立扩展，支持Kubernetes或无服务架构
- 标准化接口：提供统一的接口进行工具调用和资源管理