图解「模型上下文协议(MCP)」:从与传统 API 的比较入手
编者按: AI 应用如何像智能终端连接配件一样,无缝集成多样化的工具和数据源?答案或许就藏在近期热议的「模型上下文协议(MCP)」中。
我们今天带来的这篇文章,作者的核心观点是:MCP 通过标准化通信协议,让 AI 应用与外部工具、数据的交互如同 USB-C 接口一般高效且灵活,彻底改变传统 API 架构的僵化限制。
文章详细介绍了 MCP 的核心架构,包括 Host(提供 AI 交互环境的应用程序)、Client(实现与 MCP Servers 通信)和 Server(提供特定能力和数据访问)三大组件。重点解释了 MCP 的 Capability Exchange(能力交换)机制如何使系统更加动态灵活,允许服务器随时更新其功能而无需客户端重写代码。
作者 | Avi Chawla
编译 | 岳扬
最近,关于模型上下文协议(MCP)的讨论非常热烈。你一定听说过它。
今天,让我们一起来了解一下模型上下文协议(MCP)。
直观地说,MCP 就像 AI 应用的 USB-C 接口。
正如 USB-C 为设备连接各种配件提供了标准化方案,MCP 也将 AI 应用连接到不同数据源和工具的方式标准化了。
接下来从技术角度进行深入探讨。
MCP 的核心遵循客户端-服务器(client-server)架构,Host 应用程序可以连接到多个 Server。
它包含三个主要组件:
- Host
- Client
- Server
在我们进行深入探讨之前,先来了解一下整体架构👇
Host 代表任何提供 AI 交互环境、访问外部工具和数据源并运行 MCP Client 的 AI 应用(如 Claude 桌面版、Cursor)。
MCP Client 在 Host 内运行,实现与 MCP Servers 的通信。
MCP Server 对外开放特定能力,并提供对数据源的访问权限,包括:
- Tools:使大语言模型能够通过你的 Server 执行操作。
- Resources:将 Server 上的数据和内容开放给大语言模型。
- Prompts:创建可复用的提示词模板和工作流程。
要构建属于你自己的 MCP 系统,理解客户端-服务器通信机制是必不可少的。
现在我们来解析客户端与服务器的通信流程。
本文将对该过程进行逐步拆解,请看下方这张示意图...
首先进行 Capability Exchange(译者注:Capability Exchange(能力交换)是一种动态服务发现与适配机制,是MCP连接建立的必经步骤,类似于"握手协议"。),流程如下:
- 客户端发送初始请求,获取服务器能力信息
- 服务器返回其能力信息详情
- 例如当天气 API 服务器被调用时,它可以返回可用的"tools"、"prompts templates"及其他资源供客户端使用
交换完成后,客户端确认连接成功,然后继续交换消息。
这种机制非常强大,原因如下:
在传统的 API 架构中:
- 如果你的 API 最初需要两个参数(例如,天气服务的 location 参数(译者注:地理位置)和 date 参数(译者注:日期)),用户需严格按此参数结构构建应用。
- 之后,如果你决定为该 API 添加第三个必选参数(例如,unit参数(译者注:温度单位)),将API "契约"进行变更。
- 这意味着该 API 的所有用户都必须更新代码,增加对新参数的支持,如果未及时更新,他们的请求可能会失败、报错或提供不完整的结果。
MCP 的设计解决了这个问题,具体方法如下:
- MCP 引入了一种动态、灵活的方法,与传统 API 形成鲜明对比。
- 当 Client(例如 Claude Desktop 这类 AI 应用)连接 MCP Server(例如天气服务)时,会发送初始请求,以便了解 Server 的能力。
- Server 的响应包含可用的 tools、resources、prompts 以及相关参数的详细信息。例如,若天气 API 最初仅支持 location 和 date 参数,服务器会通过能力交换告知这些信息。
- 当新增 unit 参数时,MCP Server 可在下次进行能力交换时动态更新能力描述。Client 无需硬编码或预定义参数,只需查询 Server 的最新能力并自动适配。
- 这样,Client 就能使用更新后的新功能(例如在其请求中包含 unit 参数),实时调整行为,而无需重写或重新部署代码。
希望本文能阐明 MCP 的作用。
后续我们将探索如何创建自定义的 MCP servers 并围绕它们构建实践演示,敬请期待!
Thanks for reading!
Hope you have enjoyed and learned new things from this blog!
END
本期互动内容 🍻
❓你认为标准化的 MCP 会加速 AI 创新还是限制创新?为什么?
原文链接:
https://blog.dailydoseofds.com/p/visual-guide-to-model-context-protocol

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
史诗级革新 | Apache Flink 2.0 正式发布
在数据处理领域,Apache Flink 一直以其强大的实时流处理能力而闻名。3 月 24 日,Flink 2.0 正式发布,这不仅是对以往版本的一次重大升级,更是实时数据处理领域的一次史诗级革新。本文将带你深入了解 Flink 是什么,它的适用场景,以及 Flink 2.0 中那些值得关注的新特性。 Apache Flink Apache Flink 是一款分布式流处理框架,专为有状态计算设计,能够高效处理无界和有界数据流。自 2014 年成为 Apache 顶级项目以来,Flink 凭借其低延迟、高吞吐、精确一次(Exactly-Once)语义和流批一体化能力,成为全球实时计算领域的标杆技术。 核心特性: 流处理优先 :原生支持事件时间(Event Time)处理和状态管理,适用于动态数据流场景。 流批一体 :同一套 API 同时支持流式与批量数据处理,简化开发流程。 高容错性 :基于分布式快照(Checkpoint)和保存点(Savepoint)实现故障恢复与版本升级无缝衔接。 灵活部署 :支持 YARN、Kubernetes、独立集群等多种部署模式,适配云原生架构。 Flink...
- 下一篇
首个提出 GraphRAG 的团队在做什么?
导读:“NebulaGraph 作为一款云原生图数据库,属于传统 Infra, 但我们逐渐意识到,AI 的发展将彻底改变数据库的应用场景和技术架构。于是,我们团队开始探索图数据库在 AI 领域的价值。”本文整理自 NebulaGraph @尚卓燃 在 KCD Beijing 上的演讲, 与大家分享 NebulaGraph GenAI Team 的工作与进展。 本文首发于「NebulaGraph 技术社区」,了解更多 NebulaGraph 信息,可访问官网 Part 1 背景趋势 01 传统 RAG 方法的痛点 传统 RAG 方法在实际应用中面临诸多挑战: 细粒度知识检索能力不足:举个例子,做 chunk 分块是一个很强的对信息浓度的假设,无论是用语义的方式还是固定大小来分块,一旦确定了这个分块,其实对知识被召回的数据的信息浓度做了一个很强的假设,有的时候就存在一些重要而细粒度的分散的信息没办法进行召回,质量就会有些损失。 全局上下文关联缺失:索引的知识块中,核心知识点和其他知识点的关联,有些知识有局部性,例如 A 和 B 在一个块关联,B 和 C 在一个块关联,C 和 D 在一个块关...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8安装Docker,最新的服务器搭配容器使用
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19