《从零开始学AI-实操手册》

第06节：MCP-模型上下文协议

在前面的章节中，我们了解了大模型是如何理解和生成文本的。但是，大模型本身像一个知识渊博但与世隔绝的学者，它知道很多事情（主要来自训练数据），但对于训练之后发生的新鲜事，或者特定场景下的私有信息，它就无能为力了。

想象一下，你问AI助手：“我上次订的机票是什么时候？” 如果AI助手只能依赖它训练时学到的通用知识，它肯定答不上来。这时，我们就需要一种方法，让AI能够“走出去”，获取它当前需要但自身不具备的信息。MCP模型上下文协议（Model Context Protocol） 就是为此而生的。

1. 为什么需要MCP：让AI"活"在当下

大模型虽然强大，但它们通常面临一些固有的局限性：

  • 知识截止日期：模型的知识停留在训练数据被收集的那个时间点。比如，一个2023年初训练的模型，不知道2024年发生的大事件。
  • 缺乏实时信息：无法获取最新的新闻、股价、天气等。
  • 无法访问私有数据：不能直接查询你的个人邮件、公司的内部数据库等。
  • 执行实际操作的限制：本身不能直接帮你订餐、发送邮件或调用其他软件功能。

MCP的目标就是打破这些壁垒，让大模型能够连接到外部世界，获取实时、特定领域或私有的上下文信息，并能借助外部工具执行更广泛的任务。

简单来说，MCP就像是给大模型配上了一部可以随时查资料、打电话求助的"智能手机"。

2. MCP是如何工作的：AI的"外部大脑"连接器

当我们希望AI处理一个需要外部信息或能力的任务时，MCP就派上用场了。我们可以把MCP理解为一个标准化的"沟通桥梁"。

这个桥梁连接两端：

  • MCP客户端 (MCP Client)：通常内嵌在AI应用（比如你用的聊天机器人、智能助手）中。当AI应用发现自己需要额外信息才能回答问题或完成任务时，它就通过客户端发出"求助信号"。
  • MCP服务器 (MCP Server)：连接着各种外部数据源（如数据库、API接口、知识库）或工具（如代码执行器、计算器、订票系统）。服务器接收到客户端的"求助信号"后，会去对应的数据源查找信息，或者调用相应的工具执行操作，然后把结果按照MCP规定的格式传回给客户端，最终交给AI使用。

举个例子：

你问AI助手："帮我查一下明天北京的天气，并预订一张下午去上海的高铁票。"

  1. AI应用（内置MCP客户端）分析需求：

    • "明天北京的天气" -> 需要实时天气信息。
    • "预订下午去上海的高铁票" -> 需要查询高铁时刻并执行预订操作。 这些都不是AI凭空能知道或做到的。

  2. MCP客户端发出请求：

    • 向连接天气服务的MCP服务器请求："获取北京明天天气"。
    • 向连接票务系统的MCP服务器请求："查询明天下午北京到上海的高铁票"，并在用户确认后，"预订选定的车票"。

  3. MCP服务器执行与响应：

    • 天气MCP服务器调用天气API，获取到天气数据（如"晴，15-25摄氏度"），格式化后返回。
    • 票务MCP服务器查询票务系统，返回可选车次，待用户选择后，再执行预订操作，并返回预订结果（如"预订成功，订单号XXX"）。

  4. AI应用整合信息并回复： AI助手收到MCP传回的信息后，就可以给你一个完整的答复了："明天北京天气晴朗，15到25摄氏度。已为您查询到下午有多趟前往上海的高铁，请问您选择哪一趟？... 确认后，已为您预订成功，订单号是XXX。"

+-------------------+       MCP协议       +----------------------+
|  AI应用           |-------------------|  外部数据/工具        |
| (内置MCP客户端)   |  1. 请求信息/操作  | (通过MCP服务器接入)   |
|  - 我需要天气数据   |                   |  - 天气API           |
|  - 我需要订票      <-------------------|  - 订票系统          |
+-------------------+   2. 返回结果      +----------------------+

通过这种方式，AI就好像拥有了无数个可以按需连接的"外部大脑"和"外部手臂"。

3. MCP的核心要素：沟通的规则

为了让客户端和服务器能够顺畅地交流，MCP定义了一些核心的规则和概念：

  • 协议规范 (Protocol Specification)：这是MCP的"法律法规"，详细定义了客户端和服务器之间如何打招呼（能力协商）、如何提问（请求结构）、如何回答（响应结构）、数据长什么样（数据格式）以及遇到问题怎么办（错误处理机制）。这确保了不同的AI应用和外部服务只要都遵守这套规范，就能互相理解和协作。
  • MCP客户端 (MCP Client)：AI应用中的"外交官"，负责按照协议规范把AI的需求包装成标准的请求，发送给服务器，并接收和解析服务器返回的响应。
  • MCP服务器 (MCP Server)：外部数据或工具的"代言人"，负责接收客户端的请求，与实际的数据源或工具互动，然后把获取到的信息或操作结果按照协议规范打包，返回给客户端。
  • 上下文信息交换 (Contextual Information Exchange)：这是主要目的，即在AI和外部系统之间高效、准确地传递完成任务所需的上下文信息。
  • 能力协商 (Capability Negotiation)：在正式开始沟通前，客户端和服务器会先"对个暗号"，确认一下双方都支持哪些功能和协议版本，确保后续沟通不会"鸡同鸭讲"。

4. MCP带来了哪些好处？

引入MCP模型上下文协议，能给AI应用带来诸多益处：

  1. 更强的能力：AI不再局限于训练数据，可以处理更广泛、更复杂的任务，例如：
    • 回答关于最新事件的问题。
    • 查询和操作私有数据（当然，需要有合适的权限控制）。
    • 与其他软件或服务互动，完成订票、下单等操作。
  2. 更高的准确性：通过获取实时和相关的上下文信息，AI的回答可以更加精准和可靠。
  3. 更好的用户体验：
    • 连贯性：在多轮对话中，AI可以借助MCP获取历史对话信息或用户偏好，使得对话更加自然和连贯。想象一下，你对AI说"帮我找找那家我常去的意大利餐厅"，如果AI能通过MCP查到你的历史记录，就能准确理解"那家"。
    • 减少重复：用户不需要反复解释背景信息。
  4. 标准化与互操作性：MCP提供了一个开放标准，这意味着不同的开发者、不同的AI模型、不同的外部服务可以更容易地集成和协作，促进AI生态的发展。

5. 简单理解MCP的技术实现

虽然我们不需要深入到代码层面，但了解一点技术背景有助于更好地理解MCP。

  • 基于JSON-RPC 2.0：MCP的核心通信协议是基于JSON-RPC 2.0的。这是一种轻量级的远程过程调用（RPC）协议，使用JSON这种人类易读、机器易解析的数据格式来交换信息。你可以把它想象成一种"普通话"，让客户端和服务器都能听懂对方在说什么。
  • 状态化连接：客户端和服务器一旦连接上，会保持这个连接状态，允许在一次连接中进行多次请求和响应，就像两个人打电话，只要电话没挂，就可以一直聊。
  • 服务器可提供的能力：
    • 资源 (Resources)：提供给AI模型或用户使用的上下文数据，比如一篇文档、一个数据库记录。
    • 提示 (Prompts)：一些模板化的消息或工作流程，引导用户或AI如何进行。
    • 工具 (Tools)：AI模型可以调用的函数或操作，比如"计算器"、"搜索网页"、"发送邮件"。
  • 客户端可提供的能力：
    • 采样 (Sampling)：允许服务器发起一些代理行为或递归的LLM交互。这稍微复杂一些，可以理解为服务器有时也需要AI客户端帮忙做点事情。

通过这些机制，MCP为大模型应用搭建了一个强大而灵活的框架，使其能够有效地与外部世界互动。

总而言之，MCP模型上下文协议通过一套标准化的接口和流程，极大地扩展了大型语言模型的能力边界，使其从一个"静态的知识库"转变为能够动态获取信息、利用工具解决实际问题的"智能助手"。这对于构建更强大、更实用、更智能的AI应用至关重要。