大模型学习之MCP
MCP
RAG 技术的局限性
RAG(检索增强生成,Retrieval-Augmented Generation)是当前大模型领域的热门方向。它结合了信息检索与生成式模型,旨在提升知识准确性、上下文理解和对最新信息的利用能力。
RAG 的主要缺点:
- 检索精度有限,可能无法获取最相关的信息
- 生成内容可能不完整或片面
- 缺乏全局视角
- 检索能力受限时效果下降
理论基础
Function Call
Function Call 是 OpenAI 于 2023 年提出的重要概念,本质上为大模型提供了与外部系统交互的能力,相当于为模型配备“外挂工具箱”。当模型无法直接回答问题时,可主动调用预设函数(如查询天气、计算数据、访问数据库等),获取实时且精准的信息后再生成回答。
Model Context Protocol(MCP)
MCP(模型上下文协议)由 Anthropic 公司提出,是一个开放标准协议,旨在解决 AI 模型与外部数据源、工具的交互难题。
开发者按照 MCP 协议开发,无需为每个模型与不同资源重复编写适配代码,大幅节省开发工作量。MCP Server 作为通用协议实现,可直接开放给开发者使用,进一步减少重复劳动。
核心特点:
- 协议标准化:统一工具调用格式(请求/响应/错误处理)
- 生态兼容性:一次开发对接所有兼容 MCP 的模型
- 动态扩展:新增工具无需修改模型代码,即插即用
核心价值:
- 数据孤岛 → 打通本地/云端数据源
- 重复开发 → 工具开发者只需适配 MCP 协议
- 生态割裂 → 形成统一工具市场
MCP 与 Function Call 对比
对比项 | Function Call (OpenAI) | MCP (Anthropic) |
---|---|---|
标准化 | 仅适用于 OpenAI 生态 | 开放标准,兼容多模型 |
工具接入 | 需为每个模型单独适配 | 一次开发,多模型复用 |
扩展性 | 新增工具需适配各模型 | 工具即插即用,无需修改模型代码 |
生态兼容性 | 主要服务于 OpenAI 平台 | 支持多家模型厂商 |
典型应用场景 | 聊天机器人、自动化助手 | 跨平台工具市场、企业级数据集成 |
简而言之,Function Call 更偏向于单一平台的工具调用,而 MCP 致力于打造跨平台、跨模型的统一工具生态。
MCP 的基本使用
MCP 客户端(Host)
MCP 客户端(Host)负责与 MCP Server 通信,发起请求并处理响应。开发者可通过 Host 集成 MCP 协议,实现模型与外部工具的数据交互。
MCP Client
MCP Client 是具体实现 MCP 协议的客户端库,支持多种编程语言。开发者可根据需求选择合适的 Client,快速集成 MCP 能力。
MCP Server
MCP Server 官方描述:一个轻量级程序,通过标准化模型上下文协议公开特定功能。
目前的局限性
- 避免让 AI 检索过大数据量。与 RAG 不同,MCP 每次会检索所需全部数据,若一次查询数据量过大,会消耗大量 Token,甚至导致客户端卡死。
- 许多 MCP 客户端依赖大量系统提示词与 MCP 工具通讯,因此使用 MCP 时 Token 消耗会显著增加。
- MCP 生态尚处于早期阶段,工具和资源数量有限,部分场景下可用性有待提升。
- 不同模型对 MCP 协议的支持程度不一,实际集成时需关注兼容性问题。
MCP开发步骤 待续。。。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 廾匸!