初识MCP-模型上下文协议

Iseeyore
0 阅读7分钟

大语言模型 (LLM) 功能强大，但存在两大局限性：其知识在训练时就已固定，且无法与外部世界交互。这意味着它们无法访问实时数据，也无法执行如预订会议或更新客户记录等操作。

MCP即模型上下文协议（Model Context Protocol），是一种开放的通信协议，是人工智能领域的 “USB 接口”，由 Anthropic 于 2024 年 11 月推出。MCP在大模型和外部数据源（数据、工具、开发环境等）之间建立了双向且更加安全的连接，使用单一的标准协议取代碎片化的集成方式。如果把 LLM 比作人的大脑，MCP 就是手脚。LLM 不断提升智能下限，MCP 则是不断提升创意上限。

在 MCP 出现前，大模型和数据源之间是如何连接的？

  • 利用 API 接口：如果数据源提供了 API 接口，开源大模型可以通过调用 API 来获取数据，包括数据的读取和写入等操作。

  • 基于特定代码编写：开发者针对具体的开源大模型和数据源，依据其各自的接口规范与数据格式要求，使用编程语言（如 Python）编写连接代码。以连接 MySQL 数据库与开源大模型为例，可利用 Python 的pymysql库来建立数据库连接，获取数据后进行处理和转换，使其能被大模型理解和使用。

  • AI 应用开发平台&编程框架

    • LangChain：是一个用于开发由语言模型驱动的应用程序的框架，能将开源大模型与各种数据源集成。如可以通过 LangChain 的SQLDatabaseChain将大模型与关系型数据库连接，实现基于数据库数据的问答等功能。
    • LlamaIndex：主要用于构建向量数据库索引，方便大模型高效检索和利用数据。能将文本数据等处理成向量形式存入向量数据库，如 Pinecone 等，大模型在运行时可快速从向量数据库中获取相关上下文信息。
    • Dify&百炼：低代码 AI 应用开发平台，支持将开源大模型与多种数据源连接。用户通过简单的配置和少量代码，就能让大模型访问数据库、文件存储等数据源中的数据。

  • 采用插件系统：部分大模型有插件系统，类似于 OpenAI 的 ChatGPT 插件。开发者可开发插件来连接特定数据源，比如开发一个连接企业内部知识库的插件，使大模型能获取知识库中的信息进行回答。

MCP 的出现给开发者们提供了更多的选项，省去了接口代码的编写和维护工作。

MCP 的核心架构

MCP 采用客户端-服务端架构，以下是 MCP 官方展示的架构：

image

  • MCP Client（客户端）：作为调用方，是用户与 MCP 生态的交互入口。

    例如，聊天应用类，提供自然语言交互服务，让用户通过对话调用 AI 能力；编码工具类，在 IDE 里调用外部应用和系统的能力；任务自动化类，帮用户自动化执行重复性任务，如数据处理、流程调度，以提升效率。

  • MCP Server（服务端）：作为被调用方，提供后端服务支撑，包含各类核心功能模块。

    例如，数据库类（如 ClickHouse、Supabase）负责数据存储、查询与管理；设计类（如 Figma、Blender）支撑设计创作、文件协作等功能；生产力工具类（如 Notion、Obsidian）提供笔记管理、知识整理等办公协作服务；支付类（如 Stripe），处理在线支付交易，支持商业场景的资金流转。

  • Local MCP Server（本地数据源）：MCP 服务器可以安全访问本地计算机上的文件、数据库和服务。

  • Remote MCP Server（远程服务源）：MCP 服务器可以通过互联网（例如通过 API）连接到外部系统。

MCP 的运作机制

image

如上图所示，一次基于MCP的调用，一共有6个核心的步骤。我们先拟定一个前提：

  • 我要开发一个获取时间的AI Agent，用户在使用这个AI Agent时，只需要问类似“现在几点了？”这种问题即可。
  • 我已经有了一个关于处理时间的MCP Server，这个MCP Server里有2个MCP Tool，一个负责获取当前时区，一个负责获取当前时间。

调用步骤解析：

  • 第一步：用户向AI Agent提问“现在几点了？”，此时AI Agent就是MCP Client，它会把用户的问题和处理时间的MCP Server以及MCP Tool的信息一起发送给LLM。

  • 第二步：LLM拿到信息后开始推理，基于用户的问题和MCP Server的信息，选出解决用户问题最合适的MCP Server和MCP Tool，然后返回给AI Agent（MCP Client）。

    LLM返回给AI Agent的信息是：“你可以使用time这个MCP Server里的get_current_time这个MCP Tool，它可以解决用户的问题”。

  • 第三步：AI Agent（MCP Client）现在知道应该使用哪个MCP Server里的哪个MCP Tool了，直接调用该MCP Tool，获取结果。

    调用名称为time的MCP Server里的get_current_time MCP Tool。

  • 第四步：Time MCP Server返回结果（当前的时间）给AI Agent（MCP Client）。

  • 第五步：AI Agent（MCP Client）把用户的问题和从Time MCP Server处拿到的结果再一次给了LLM，目的是让LLM结合问题和答案再规整一下内容。

  • 第六步：LLM把整理后的内容返回给AI Agent（MCP Client），最后AI Agent（MCP Client）再原封不动地返回给用户。

在MCP的整个调用过程中有一个非常关键之处就是MCP Server 以及 MCP Tool 的信息。 从第一步、第二步可以看出，这个信息非常关键，是它让LLM知道了该如何解决用户的问题，这个信息就是MCP中最重要的System Prompt，本质上就是PE工程。

为什么需要 MCP？

MCP 模型上下文协议有以下优势：

  • 标准化与通用性

    • 统一规范：MCP 是一种开放标准，提供了统一的协议规范，如同 AI 应用程序的 “USB - C 接口”，使 AI 模型连接不同数据源和工具时遵循相同标准，而其他方式如特定代码编写、插件系统、API 接口等，通常需针对不同数据源和模型单独处理。
    • 跨系统兼容：能实现不同类型数据源与 AI 模型的无缝连接，无论是本地资源（如数据库、文件），还是远程资源（如 Slack 或 GitHub）等 API，都可通过统一协议处理。

  • 开发效率与便捷性

    • 简化开发流程：开发者无需为每种数据类型或服务编写专门接口代码，利用 MCP 的 SDK 可快速在系统中实现连接，如开发智能家居系统时，采用 MCP 协议可将所有设备数据通过 MCP 服务器统一管理。
    • 预构建服务器支持：Anthropic 提供了针对 Google Drive、Slack、GitHub 和 Postgres 等流行系统的预构建 MCP 服务器，开发者可直接使用，无需从零搭建。

  • 上下文管理与交互能力

    • 分布式上下文管理：对 “上下文状态” 进行抽象化处理，让上下文状态可通过协议标准化传递，不再局限于 prompt 本身，使交互更轻量化。
    • 双向通信：支持数据源与 AI 模型间的双向数据流动，数据源可向 AI 模型传输信息，AI 模型也能将输出反馈给数据源，形成更高效的交互闭环。

  • 安全性与可扩展性

    • 安全机制完善：提供强访问控制、详细权限设置和审计跟踪，内置安全监测工具，降低数据泄露风险，保障敏感数据安全。
    • 灵活扩展：具有良好的扩展性，开发者可轻松为其应用构建新的 plugin 或模块，能方便地添加新数据源或功能，快速适应不同业务需求。
avatar
文章
阅读
粉丝