当前位置： 首页 > news >正文

Model Control Protocol 一种开放的应用层协议，让大模型与工具能够协调配合起来，了解他的定义、定位、组成及实现机制...

news 2025/7/16 16:48:39

MCP 概述

  • 发展历程：MCP（Model Control Protocol）的崛起是长期积累后的成果。自 2024 年 11 月发布，经过数月沉淀与迭代，在 2025 年迎来爆发式增长，成为年度科技领域焦点。它由美国人工智能初创公司 Anthropic 主导开发，该公司还推出了 Claude 系列大语言模型。
  • 设计目的：旨在解决大语言模型与第三方系统集成日益增长的复杂性问题。在当前 AI 应用不断拓展的背景下，大语言模型需要与各种数据源、工具进行集成，MCP 的出现为这一过程提供了有效的解决方案。
  • 设计理念：在 GitHub、Hacker News 等平台上，MCP 的 “即插即用” 特性以及与底层模型解耦的设计理念备受关注。这种设计显著降低了开发者的使用门槛，为构建灵活且可扩展的 AI 应用奠定基础。开发者无需深入了解底层模型的细节，就可以方便地使用 MCP 进行开发。

MCP 的本质与特性

  • 开放的应用层协议：官方文档表明，MCP 是一种开放的应用层协议。“开放” 意味着它是公开的、非专有的，鼓励社区参与和推动，以实现广泛的采纳和互操作性，避免厂商锁定。这使得不同的开发者和企业可以基于 MCP 进行开发，促进了 AI 生态系统的多元化发展。

  • 标准化接口：MCP 为应用程序向大语言模型（LLM）提供上下文的方式进行了标准化。可以将其想象成 AI 应用程序的 USB - C 接口，为 AI 模型连接各种数据源和工具提供了标准化的接口。通过这种标准化，MCP 帮助开发者在 LLM 的基础上构建代理（agents）和复杂的工作流。具体而言，MCP 提供了以下几个方面的支持：

    • 持续增长的预构建集成列表：LLM 可直接使用这些预构建的集成，减少了开发过程中的重复工作，提高了开发效率。

    • 灵活切换不同的 LLM 提供商和厂商：开发者可以根据实际需求选择不同的 LLM 提供商，而无需对代码进行大规模修改，增强了系统的灵活性和可扩展性。

    • 在基础设施内安全地处理数据的最佳实践：在数据安全日益重要的今天，MCP 提供了安全处理数据的方法，确保数据在传输和处理过程中的安全性。

    • 在这里插入图片描述

MCP 的核心机制

  • 上下文信息流动标准化：MCP 通过定义标准的 “交换方式”（如统一的消息格式 JSON、明确的请求 / 响应模式、发布 / 订阅机制）和 “交互行为”（如组件如何请求信息、提供更新、触发动作、报告事件），确保多样化的上下文信息能够在不同组件间顺畅、准确地流动。其核心在于通过对上下文表示和传递的标准化，打破人工智能组件之间的信息壁垒，构建更为完善、高效且和谐的智能协同生态。
  • AI 应用标准接口：MCP 的核心目标之一是为 AI 应用提供一套标准化的接口，简化 AI 能力的集成、管理和协同工作。这不仅降低了技术门槛，还促进了 AI 生态系统的开放性和创新性。主要体现在以下三个方面：
    • 统一工具调用标准
      • 标准化的工具能力描述：MCP 要求每个可供调用的工具（MCP 客户端，MCP Client）能够以标准化的方式声明其能力。通常借鉴 OpenAPI 规范或 JSON Schema 的理念来定义工具属性，包括唯一标识符（如工具名称、版本号等）、功能描述（对工具能够执行的任务进行清晰准确的自然语言描述）、输入参数规范（详细定义工具执行所需的每一个输入参数，包括参数名、数据类型、是否必需、默认值、取值范围或枚举值、格式约束等，还支持描述参数如何从当前的共享上下文中动态获取）。
      • 标准化的交互方法：MCP 定义了一组核心的协议方法（Method）和通知（Notification），用于实现 MCP 主机（MCP Host）与 MCP Client 之间调用工具的标准化交互流程。
        • 工具发现（tool/discover）：MCP Host 可以通过此请求向已连接 MCP 的 MCP Client（或 MCP Server 作为工具代理）查询其所能提供的工具列表及详细的能力描述。响应中会包含遵循上述标准化格式的工具元数据，使 MCP Host 能够动态了解当前环境中可用的 AI 能力。
        • 工具执行（tool/execute）：当 MCP Host 决定调用某个工具时，会发送此请求。请求参数中通常包含要执行的工具的唯一标识符以及一个结构化的对象或数组，其中包含按照工具能力描述中定义的输入参数规范所准备的实际参数值。这些参数值可以直接提供，也可以引用当前 MCP 上下文中的数据。
        • 工具执行结果 / 进度通知（Tool Execution Result/Progress Notification）：对于同步执行的工具，其结果会作为 tool execute 请求的响应直接返回。对于耗时较长的异步工具，MCP Client 可能会先确认收到执行请求，然后在执行过程中或执行完成后，通过一个或多个标准化的通知（如 tool progress Update 或 tool execution Result）将中间进度或最终结果异步推送给 MCP Host。这些通知也应遵循预定义的结构。通过这种标准化的工具描述和交互方法，应用开发者可以采用统一的编程模型来与各种不同的 AI 工具进行交互，AI 模型（尤其是 LLM）也更容易理解和生成符合 MCP 规范的工具调用请求。
    • 动态工具集成
      • 运行时工具发现与加载：MCP Host 能通过 tool/discover 机制或高级服务发现协议（如 DNS - SD、mDNS、Consul、etcd 等），在运行时主动发现并按需连接网络中的 MCP Client，无需重启应用即可扩展功能。这使得 AI 应用能够根据实际需求动态调整其功能，提高了系统的灵活性和响应速度。
      • 插件化架构的实现：动态集成支持将 AI 工具封装为独立的 MCP Client 插件，用户或管理员可按需部署、启用或停用。例如，智能客服平台可以动态加载特定知识库插件，以满足不同场景的需求。
      • 按需服务与资源优化：对于不常用或资源消耗大的工具，MCP Host 可按需激活，然后在任务完成后释放连接或使其休眠，以优化资源利用。这有助于降低系统的运行成本，提高资源利用率。
      • 版本管理与依赖协商：MCP 可包含版本协商机制，允许 MCP Host 和 MCP Client 在初始化时交换协议和接口版本信息。MCP Client 声明能力时可明确依赖版本，MCP Host 据此选择兼容工具，高级实现甚至可集成依赖解析与冲突解决。这确保了不同版本的工具和组件之间能够相互兼容，提高了系统的稳定性。
    • 语义对齐
      • 上下文模式与数据字典：MCP 倡导使用明确的模式（Schema）来定义共享上下文中各个数据项的结构、数据类型、约束条件以及其业务含义。这些模式可以基于通用的数据建模语言，如 JSON Schema，它允许详细描述 JSON 数据的结构和验证规则。通过使用上下文模式和数据字典，不同组件可以对数据有一致的理解，减少了语义歧义。
      • 共享词汇表与本体库：在特定业务领域或跨领域协作中，为了达到更深层次的语义互操作，可以引入共享词汇表与本体库。共享词汇表为特定概念提供一组预定义的、受控的术语列表，例如在电商领域，商品分类、订单状态等都可以使用共享词汇表来规范化。本体库则更为形式化和丰富地描述一个领域内的概念、属性以及它们之间的关系（如 is - a、part - of、related - to 等），通常使用如 RDF/RDFS、OWL 等标准语言进行定义。MCP 上下文中的数据项可以链接到本体库中相应的概念或实例上，从而赋予其明确的、计算机可处理的语义。例如，上下文中的一个产品 id 可以链接到一个本体，该本体描述了该产品的类别、品牌、功能属性等，使得 AI 模型能够基于这些语义关系进行更复杂的推理。
      • 元数据描述与溯源：MCP 鼓励在上下文中不仅包含数据本身，还应包含描述数据的元数据，如数据来源（数据是由哪个组件或系统产生的）、时间戳（数据生成或最后更新的时间）。元数据描述与溯源有助于提高数据的可信度和可追溯性，方便对数据进行管理和维护。
      • 上下文协商与转换服务：在异构系统集成的复杂场景下，即使有上述机制，不同组件对上下文的理解和表示方式仍可能存在差异。MCP 支持上下文协商的机制，允许组件在交互开始时就其期望的上下文格式和语义进行沟通。此外，可以引入独立的 “上下文转换服务”（Context Transformation Service）作为 MCP Client，负责在不同语义表示之间进行映射和转换。实现完全的语义对齐是一个涉及技术、标准、社区共识和持续治理的复杂工程。

MCP 的核心功能

  • 上下文管理：负责管理和维护不同组件之间的上下文信息，确保信息的准确传递和共享。通过标准化的上下文表示和传递方式，提高了系统的协同效率。

  • 工具调用：基于统一的工具调用标准，实现 MCP Host 与 MCP Client 之间的工具调用交互。开发者可以方便地调用各种工具，无需关注工具的具体实现细节。

  • 能力协商：在 MCP Host 和 MCP Client 之间进行能力协商，确保双方能够理解和支持对方的功能和特性。例如，通过版本协商机制选择兼容的工具和协议版本。

  • 会话管理：对用户与系统之间的会话进行管理，包括会话的创建、维护和结束。会话管理有助于提高系统的交互性和用户体验。

  • MCP的推广和普及在很大程度上得益于其完善的软件开发工具包(SDK)和不断壮大的开发者生态系统。Anthropic 官方提供了多种主流编程语言( 包括 TypeScript、Python、Java、C#、Kotlin、Rust和 Swift 等)的 SDK。这些 SDK 极大地降低了开发者在各自项目中集成 MCP 的门槛，使他们能够更便捷地构建 MCP Client 和 MCP Server。

  • 在 MCP 出现之前，许多开发者使用 LangChain 等框架为模型提供工具。在 LangChain 等框架的设置中，开发者定义一组工具函数(附带描述)和代理的提示逻辑，以便 LLM 可以决定是否使用它们。这是一种可行的办法，但每个工具在幕后仍需要定制实现–LangChain 在其库中维护了数百个工具集成。本质上，LangChain 为开发者提供了一个面向开发者的标准(Python 类接口)，用于将工具集成到代理的代码库中，但没有为模型在运行时动态发现新工具提供任何方法。

    • 技术定位核心目标适用场景
      MCP开放协议（AI 原生）标准化 AI 模型与外部系统的交互复杂工作流、动态工具集成
      LangChain开发框架（Python 优先）提供工具集成的代码范式单语言环境、静态工具链
      OpenAI 插件闭源生态（绑定 GPT）扩展 GPT 功能轻量级插件（如天气查询）
      OpenAPI/JSON-RPC传统 API 标准（面向应用）定义接口格式前后端交互
      RESTful API请求 - 响应范式（无状态）数据传输简单接口调用

  • MCP 是LangChain 类框架的补充，将标准化转向面向模型。使用 MCP，代理可以发现和使用 MCP Server 提供的任何工具，即使代理的代码在之前没有明确包含相应工具。事实上，LangChain 已经增加了支持，可以将 MCP Server 视为另一个工具来源–这意味着使用 LangChain 构建的代理可以利用不断壮大的 MCP 生态系统,轻松调用 MCP 工具。当然，这两者的区别在于，MCP通过协议(JSON-RPC、附带元数据等)规范化了接使其更容易集成到不同的环境中，而不仅仅是 Python 框架。同样，OpenAI 的原生函数调用功能可以看作处理函数调用的格式(型输出一个JSON 函数调用)，而MCP以标准化的方式处理该调用的执行。OpenAI的函数调用和 MCP 经常协同工作:LLM生成结构化的调用,MCP Client/Server执行它并返回结果，共同实现工具的无缝使用。

核心定位

  • AI 生态的「USB-C 标准」：MCP 是 开放的应用层协议，旨在标准化 AI 模型（LLM/Agent）与外部系统（数据源、工具、服务）的交互，解决「定制化集成」痛点。区别于传统 API（面向应用），MCP 是 面向 AI 模型的协议，支持模型动态发现、调用工具，实现「即插即用」的智能协同。
  • 场景驱动：聚焦 多模态、多工具、多步骤的复杂 AI 工作流，如智能客服（集成知识库 + CRM + 工单系统）、RAG 应用（动态检索 + 生成）、自主代理（调度日历 + 邮件 + API）。

三大组件架构

  • MCP Host（AI 应用）：
    • 承载 LLM/Agent 的运行环境（如 Claude Desktop、Cursor AI IDE），负责发起工具调用请求。
    • 核心功能：会话管理、上下文存储、LLM 推理调度（如决定是否调用工具）。
  • MCP Client（协议适配器）：
    • 嵌入 Host 中的客户端，管理与 单个 MCP Server 的连接（1:1 映射）。
    • 职责：协议消息编解码（JSON-RPC）、安全认证（OAuth 2.0/TLS）、能力协商（版本 / 工具元数据）。
  • MCP Server（工具封装器）：
    • 对外暴露工具（Tool）、资源（Resource）、提示（Prompt）三类能力，如数据库查询、API 调用、知识库检索。
    • 实现标准：遵循 MCP 元数据规范（类似 OpenAPI，但增加 AI 专属字段，如工具对 LLM 的「提示模板」）。

关键实现机制

  • 动态工具发现：通过 tool/discover 接口，Host 实时获取 Server 提供的工具列表（含输入参数、语义描述），支持 mDNS/DNS-SD 等服务发现协议。

  • 流式上下文管理：支持多模态输入（语音 + 文本 + 图像）的时间戳对齐，通过 context/update 接口持续同步上下文（如用户偏好、对话历史）。基于 JSON-RPC 的流式扩展（类似 gRPC），支持 Server 主动推送进度（如异步任务通知）。

  • 语义对齐强化：强制使用 JSON Schema 定义数据结构，集成本体库（如电商领域的产品分类标准），通过 context/negotiate 接口自动转换异构数据。

  • 安全与权限：传输层：TLS 1.3 加密；认证层：OAuth 2.0 + JWT；权限层：RBAC（基于角色的访问控制，如限制 Agent 调用支付工具）。支持审计日志（请求 / 响应记录），满足 GDPR、HIPAA 等合规要求。

  • 基础协议：JSON-RPC 2.0（消息格式） + HTTP/SSE（传输） + WebSocket（未来）。上下文存储：Redis（会话级）、PostgreSQL（长期上下文）。

  • 降低集成成本：开发者只需实现 MCP Server 接口，即可被所有兼容 Host 调用（对比 LangChain 需为每个工具写 Python 类）。动态扩展能力：Host 无需重启即可加载新工具，支持插件化热插拔（如客服系统实时接入「法律条款检索 Server」）。跨厂商互操作：MCP 工具可同时被 Claude、GPT-4o 调用，打破「模型孤岛」（OpenAI 插件仅支持 GPT）。语义级协同：通过本体库和上下文转换服务，解决传统 API「数据格式对齐」的浅层问题，支持深层语义推理。MCP 协议通过标准化模型与外部资源的交互方式，提升 LLM 应用的功能性、灵活性和可扩展性。MCP 通过标准化人工智能应用生态系统中的通信规则，为开发者提供了一个统一、高效且可互操作的开发环境。

协议的关键部分 - 消息

  • MCP 的核心是使用 JSON-RPC 2.0 作为消息格式，为客户端和服务器之间的通信提供了一种标准化的方式。基础协议定义了三种基本消息类型，分别是请求（Requests）、响应（Responses）和通知（Notifications）。

  • 请求消息用于从客户端向服务器发起操作，或者从服务器向客户端发起操作。请求消息的结构如下：

    • {"jsonrpc": "2.0","id": "string | number","method": "string","params": {"[key: string]": "unknown"}
}

    • jsonrpc：协议版本，固定为"2.0"。id：请求的唯一标识符，可以是字符串或数字。method：要调用的方法名称，是一个字符串。params：方法的参数，是一个可选的键值对对象，其中键是字符串，值可以是任意类型。

  • 响应消息是对请求的答复，从服务器发送到客户端，或者从客户端发送到服务器。响应消息的结构如下：

    • {"jsonrpc": "2.0","id": "string | number","result": {"[key: string]": "unknown"},"error": {"code": "number","message": "string","data": "unknown"}
}

    • id：与请求中的id相对应，用于标识响应所对应的请求。result：如果请求成功，result字段包含操作的结果，是一个键值对对象。error：如果请求失败，error字段包含错误信息，其中：code：错误代码，是一个数字。message：错误描述，是一个字符串。data：可选的附加错误信息，可以是任意类型。

  • 通知消息是一种单向消息，不需要接收方回复。通知消息的结构如下：

    • {"jsonrpc": "2.0","method": "string","params": {"[key: string]": "unknown"}
}

    {
    “jsonrpc”: “2.0”,
    “method”: “string”,
    “params”: {
    “[key: string]”: “unknown”
    }
    }

  • 请求和响应是一对一的，客户端发送请求后，服务器会返回一个响应。id字段用于关联请求和响应。通知是单向的，发送方不需要等待接收方的回复。通知通常用于事件推送或状态更新等场景。如果请求失败，响应中会包含error字段，提供错误代码和描述，帮助开发者快速定位问题。


文章转载自：
http://cherish.kjawz.cn
http://buttonless.kjawz.cn
http://adumbrative.kjawz.cn
http://authorial.kjawz.cn
http://amoco.kjawz.cn
http://austria.kjawz.cn
http://apoplexy.kjawz.cn
http://bacterize.kjawz.cn
http://atretic.kjawz.cn
http://bog.kjawz.cn
http://centralia.kjawz.cn
http://bloodstained.kjawz.cn
http://bumpkin.kjawz.cn
http://acyclic.kjawz.cn
http://blackberry.kjawz.cn
http://blousy.kjawz.cn
http://aps.kjawz.cn
http://boondoggle.kjawz.cn
http://celotomy.kjawz.cn
http://amenably.kjawz.cn
http://alleviant.kjawz.cn
http://atlantis.kjawz.cn
http://beggardom.kjawz.cn
http://casual.kjawz.cn
http://calvinist.kjawz.cn
http://carifta.kjawz.cn
http://aboard.kjawz.cn
http://axletree.kjawz.cn
http://childie.kjawz.cn
http://bitstock.kjawz.cn
http://www.dtcms.com/a/281782.html

相关文章：

  • 手提式干粉灭火器检查工作，如何做到可执行、可追溯、可管理？
  • 移动碰撞法 ——套料排版算法——CAD c#
  • java基础(day08)-面向对象
  • Redis 高频面试题
  • 【删库跑路】一次删除pip的所有第三方库
  • vllm本地部署qwen3-4b
  • 场景设计题+智力题
  • windows下安装difi（无docker desktop版）
  • 7.15 腾讯云智面经整理
  • Wiz笔记二次开发
  • AI大模型开发架构设计（22）——LangChain的大模型架构案例实战
  • 记忆力训练day41
  • 1-Nodejs介绍与安装
  • 基于STM32的智能火灾报警系统设计
  • 【人工智能99问】激活函数有哪些，如何选择使用哪个激活函数？(5/99)
  • ADAU系列DSP用MCU来做控制，怎么去理解这个逻辑
  • Vue3 + MapLibre 地图管理工具 useMap 使用指南
  • 牛客：HJ22 汽水瓶[华为机考][数字处理]
  • 基于Sentinel-1雷达数据的洪水动态监测（附完整GEE代码）
  • 深入理解红锁
  • Vue3入门-指令补充
  • 学习C++、QT---26（QT中实现记事本项目实现文件路径的提示、C++类模板、记事本的行高亮的操作的讲解）
  • 面向对象与面向过程、函数式编程
  • C++回顾 Day8
  • 【时时三省】(C语言基础)通过指针引用多维数组
  • 【09】MFC入门到精通——MFC 属性页对话框的 CPropertyPage类 和 CPropertySheet 类
  • burpsuite使用中遇到的一些问题（bp启动后浏览器无法连接）/如何导入证书
  • css实现烧香效果
  • 20.如何在 Python 字典中找到最小值或最大值的键？
  • 【卡尔曼滤波第六期】集合变换卡尔曼滤波 ETKF