MCP分享
2025年4年29日 · 3811 字
看到不少人在讨论 MCP（Model Context Protocol），感觉挺火的，我也忍不住去查了不少资料、看了文档和一些项目，想趁这个机会整理一下思路，顺便做个分享。
不过我对这个协议还在摸索阶段，很多理解可能不够准确或者有偏差，还请大家多多包涵，也欢迎指出问题、一起交流
什么是MCP？
MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年底推出的一种开放协议，用于标准化应用程序向 LLM 提供上下文的方式。可以将 MCP 比作 AI 应用的 USB-C 接口：正如 USB-C 为设备提供了连接各种外设和配件的标准化方式，MCP 为 AI 模型提供了连接不同数据源和工具的标准化方式。
MCP系统架构
MCP宿主环境（Hosts）是面向最终用户的应用程序界面，如Anthropic的Claude Desktop或支持AI功能的IDE，负责处理用户交互并访问外部资源。
MCP客户端（Clients）作为宿主环境中的专用连接器，负责建立和维护与各个MCP服务器的安全通信链路。每个服务器对应一个独立的客户端实例，确保通信的隔离性。
MCP服务器（Servers）是实现标准MCP协议的轻量级中间件，负责连接宿主应用与外部资源。这些服务器充当桥梁，为应用程序提供对外部工具和数据源的标准化访问。
本地数据源（Local Data Sources）包含各类本地存储的资源，如文件系统、数据库和服务。MCP服务器通过标准化接口确保对这些资源的安全访问。
远程服务（Remote Services）指通过互联网访问的外部API和服务。MCP服务器负责规范化这些远程资源的调用过程，实现数据获取和操作执行。
聊到MCP，那么就绕不开一个概念Function Call。
什么是Function Calling？
Function Calling来源于2023年的OpenAI。我们详细看下OpenAI的标准调用协议，其中Function Calling对应json中的tools部分，另外多轮对话放在messages中。
**什么是函数调用以及它是如何工作的？函数调用是一项允许大语言模型（LLMs）通过返回结构化输出来调用外部函数或API的功能，该输出指定了函数名称和参数。模型不会直接执行函数，而是通过响应告诉应用程序应该调用什么函数以及使用什么参数，然后由应用程序执行该函数并将结果返回给模型。本质上，LLM充当规划者的角色：它决定是否应该使用函数、使用哪个函数以及使用什么输入，而将实际执行留给你的代码。
简单来说，Function Calling就像是AI给人类下达指令。比如你告诉AI"帮我订一张去北京的机票"，AI不会直接去订票，而是会告诉程序："请使用订票功能，出发地是上海，目的地是北京"。然后由程序去实际完成订票的操作。这样的设计既保证了安全性（AI不能直接操作系统），又让AI能够帮助我们完成实际的任务。
MCP与Function Calling的区别
MCP在功能上对Function Calling进行了扩展和规范化：
- 统一了tools调用规范，使不同模型和服务之间的交互更加标准化
- 定义了客户端和服务端之间的通信协议，包括数据格式、错误处理和状态管理
- 引入了结构化的提示词系统，确保通信双方能按照预定义的格式进行有效交互
可以理解为MCP是Function Calling的PRO版本，做了规范，增加了其它特性。
为了更好的理解整个Function Calling调用到MCP的发展，我们可以看看AI编程的演变，可以比较直白的看清楚里面的变化。
AI编程的演变
第一阶段：基于网页聊天框的代码生成与手动执行
描述：开发者通过网页上的聊天框与大型语言模型（如 ChatGPT）进行交互，提出编程需求，模型生成代码后，开发者手动复制并在本地环境中运行。
第二阶段：集成开发环境（IDE）与大模型的交互式代码修改
描述：开发者在集成开发环境（如 VS Code）中，直接在代码上提问，大型语言模型提供修改建议，开发者根据建议手动修改并运行代码。
第三阶段：智能开发环境（IDE）与大模型的自动化协作
描述：开发者在智能开发环境（cursor、windsurf等）中，直接告诉大型语言模型想要实现的功能，模型自动查询、修改文件并执行代码，实现一站式服务。
那么这里就涉及到前面提及的函数调用Function Calling。这里面的各种功能就是智能IDE自己开发的工具，然后去利用大语言模型的能力去调用它们来完成任务。
那么大语言模型又是怎么知道有哪些工具，和什么时候调用工具呢？其实就是用Prompt去实现的，大家感兴趣可以去查查Cursor写的Prompt，清晰易懂，非常有学习的价值。
然后我们来看看整个流程具体是怎么实现的？我们来看一张图。
代码重构示例流程
用户输入请求：用户输入"将 Foo 重构为使用 @api.py"，要求重构代码，使 Foo 类使用 @api.py 文件中的内容。
- 步骤一：查找相关代码系统使用"Tool: SearchCode('Foo method')"查找 Foo 类中的方法，识别需要修改的部分。
- 步骤二：读取代码文件通过工具 Tool: Read('[foo.py]', lines=(10, 50))读取 [foo.py] 文件的第 10 至 50 行，了解现有代码实现。
- 步骤三：编辑文件系统使用 Tool: EditFile('[foo.py]', '# … existing code …')编辑文件，将新代码插入适当位置。
- 步骤四：优化和检查
- 索引和重排序：系统将代码文件发送至"Code Vectorstore Index"和"Fast Re-ranking LLM" 应用优化：使用"Fast Apply LLM"应用优化策略 IDE 检查：使用 IDE Linter 工具检查语法和代码风格
最后，系统向用户显示"Done! I have made these changes …"，表明代码重构和优化已完成。
这就是一个大预言模型加工具的调度过程，这也是AI编程目前来说比较流行的用法。
AI编程工具的演进
- AI Chat仅提供建议，需要人类手动将 AI 的响应转化为实际行动和结果，比如复制粘贴或进行修改。
- AI Composer能够自动修改代码，但仍需人类参与确认，且功能仅限于代码修改。
- AI Agent一个完整的自动化程序，未来有望实现自动查询网络信息、生成代码、分析日志、调试代码，以及向 GitHub 推送代码等功能。
MCP Server 正是为实现 AI Agent 的自动化而设计的中间层。它向 AI Agent 提供可用的服务、API 和数据源信息，使 AI Agent 能够判断是否调用特定服务，并通过 Function Calling 执行相应函数。
所以说为什么MCP是一个突破？
当前大多数AI应用都是独立运行的新服务，与现有的企业系统和工具缺乏深度整合。这导致AI技术在实际业务场景中的应用受到了限制。
举个例子，我们还无法通过单一AI应用来实现文档管理、客户关系维护、财务分析等多个业务功能的无缝衔接。虽然每个单独功能都不复杂，但要将它们整合到同一个智能系统中仍面临诸多挑战。
为了更直观地理解这一点，让我们设想未来办公场景中，通过一个统一的AI助手可以完成以下工作：
- 通过AI分析公司内部销售数据，自动生成月度业绩报告
- 让AI查阅客户服务记录，快速定位和解决用户反馈的问题
- 利用AI自动整理会议记录，并将关键决策同步到项目管理系统
- 让AI协助管理企业资源，如自动调整人力资源配置和预算分配
借助MCP协议，这些跨系统的智能化协作场景正在逐步成为现实。
MCP核心概念
Resources（资源）
本质：Resources 是 MCP 里用来暴露数据的核心机制，相当于给 LLM 提供"原材料"。你可以把它想象成一个只读的数据库接口或者文件系统，里面装的是静态或者半动态的信息，比如日志文件、用户配置文件、股票价格啥的。
怎么用：服务器（MCP Server）把这些数据暴露出来，客户端（比如 LLM 应用）可以读取它们，然后塞进模型的上下文里去推理或者生成内容。比如你有个日志文件 app.log，通过 Resources 就能让 LLM 直接看到里面的错误信息。
特点：
- 应用控制：客户端决定啥时候用、怎么用这些资源。有的客户端像 Claude Desktop 得用户手动选，有的可能自动挑，灵活得很。
- 实时性：支持订阅更新，比如资源变了，服务器能通知客户端，拉取最新内容。
Tools（工具）
本质：Tools 是 MCP 里的"执行者"，让 LLM 不只是嘴炮，还能干活。简单说，就是服务器提供一些函数或者 API，LLM 可以直接调用去完成具体任务。
怎么用：服务器定义好工具（比如"计算两点距离"或者"发个邮件"），客户端发现这些工具后，LLM 就能根据需要调用。调用完结果会返回给 LLM，继续推理或者输出。
特点：
- 模型控制：设计上是让 LLM 自动调用的（当然可以加人工审核），不像 Resources 那么被动。
- 动态操作：不像 Resources 只读，Tools 是干活的，能改变状态，比如发送请求、写文件、甚至控制硬件。
- 灵活性：从简单的数学计算到复杂的爬虫、API 调用，都能做。
Prompts（提示）
本质：Prompts 是 MCP 的"模板大师"，提供预定义的交互模式或者推理指引。可以说它是 LLM 的"剧本"，告诉它怎么开口、怎么思考。
怎么用：服务器定义好一堆 Prompt 模板（比如"写个产品描述"或者"调试错误"），客户端可以直接选一个，填入参数，然后丢给 LLM 执行。
特点：
- 用户控制：不像 Tools 是模型自己玩，Prompts 通常是用户主动选的，适合标准化任务。
- 可重用：写一次，到处用，省得每次都从头编 Prompt。
- 带参数：可以动态填入变量，比如代码片段、错误信息，生成针对性的输出。
三者结合的威力
Resources + Tools + Prompts = 完全体：Resources 提供数据原料，Tools 提供动手能力，Prompts 提供套路，三者一结合，LLM 就能从一个只会聊天的基础对话模型变成能干活的超级助手。
用法举例：假设你有个 MCP 服务器接了个日志系统（Resources），配了个"查询数据库"的工具（Tools），再加个"生成故障报告"的模板（Prompts）。LLM 就能自动读日志、查数据库、写报告，一气呵成。
Sampling（采样）
本质：MCP 采样允许服务器通过客户端请求 LLM 完成。这意味着您的服务器可以向 LLM 发送请求并接收完成信息，从而继续解决任务。
怎么用：客户端定义好Sampling，服务端预设好情况，当触发某个场景，服务端会向客户端发出LLM请求，得到人工审批后LLM完成任务返回。
特点：
- 服务端更智能：使用人工智能根据可用信息做出明智的决策。
- 双重人工审核：用户需审核请求内容和LLM响应，确保控制权。
- 标准化协议：请求/响应为结构化JSON，支持动态模型选择和上下文控制。
Root（根）
本质：根是上下文定义 URI，用于为 MCP 服务器建立操作边界。它们充当 AI 代理在与您的系统交互时可以访问的"安全区域"或"允许的目录"。当 MCP 客户端为服务器提供根时，其本质上是在告诉您："您可以在这些特定区域内工作。"
怎么用：用户在客户端定义好Root，初始化阶段客户端和服务端会进行通信，告知可使用的区域范围。
特点：
- 安全性：如果已知服务器尊重根边界，则根就像栅栏一样，阻止服务器访问不应该访问的内容。
- 焦点：根引导服务器仅查看相关信息，例如为他们提供搜索位置的地图。
- 性能：通过限制服务器可以查看的位置，服务器可以运行得更快，并且搜索或过滤逻辑更少。
- 信任：用户知道服务器只能访问其授权的特定区域，会感到更安心。但这仍然取决于服务器对根目录的实现。
MCP 的消息格式
JSON-RPC 2.0 作为其传输格式，一个用JSON格式描述的远程调用标准，定义了"怎么发请求"和"怎么收响应"，与传输层无关。
MCP 两种标准传输实现
- 标准输入/输出（stdio）：客户端和服务器之间透過标准输入（stdin）和标准输出（stdout）进行直接通信，这种方式仅限于本地。
- 服务器发送事件（SSE）：客户端和服务器之间透过网络进行通讯，因此可以在不同的机器之间共享和使用。
总之，MCP 为 AI 应用提供了一个强大而灵活的基础设施，使得 LLMs 能够更好地与外部世界交互，拓展其应用范围。随着更多开发者和企业的加入，MCP 有望成为 AI 应用的标准协议，推动智能化时代的到来。
如果您对 MCP 感兴趣，建议参考以下资源以深入了解：
如需进一步探讨 MCP 的应用场景或技术细节，欢迎留言交流！
参考资料:
https://medium.com/@simon3458/mcp-intro-2025-41c85e3d56fd
https://guangzhengli.com/blog/zh/model-context-protocol