大模型应用中我们为什么需要MCP

MCP 采用客户端-主机-服务器架构,基于 JSON-RPC 2.0,通过能力协商机制实现客户端与服务器之间的上下文交换和采样协调,支持跨应用程序集成 AI 功能,同时保持安全边界和关注点隔离,但他远不是表面看起来像一个简单的 api 接口。MCP 不仅仅是一个 API,而且能够到普通的 WEB API 无法做到的事情。

一、传统API的运作模式及其局限性

他们为什么与传统的WEB API不同?为什么说 MCP 不仅仅是一个普通的 WEB API?

首先我们为了开始讨论这个,我们先来看看普通的 API 是什么样的,这是我们熟悉的模式,有一个 API 服务暴露了一些功能,如下图,在这个例子中,我们有产品,订单和用户,然后有一个客户端使用这个 API。 现在想想一下,你的代码在客户端应用程序使用,你会调用这个 API 提供固定的服务,比如调用产品的接口服务,并提供该接口所有需要的任何入参,然后完成所有的这些调用,但是明天,你决定更改这个 API,比如数据库的里面的产品太多了,你想给 API 添加一个分页功能,我们有产品、订单和用户,然后有一个客户端功能使用了这个 API。

  1. 破坏性变更

    如果API开发者决定更改了接口,例如为/products添加分页功能(新增参数page和limit),客户端必须同步更新代码以适配新接口。否则,客户端将因接口约定变更而无法正常工作。这种情况被称为"破坏性变更"。

    假设你还能控制你的客户端,如果这个 API 非常受欢迎,很多客户端都在使用他,你对 API 做了更改,基本上每个客户端都得跟着改,否则他们就无法正常工作。

  2. 版本控制

    每当你需要对 API 做破坏性变更时,你得创建一个新版本,基本上就是一个全新的 API。通常人们会在 URL 中加入版本号来区分(如/v1/products、/v2/products),但这仍然是一个完全不同的 API。这没问题,因为这对于人类使用的系统与 API 交互来说是没问题的。

这些问题在人类主导的系统中尚可接受,但在AI优先的世界中,传统API的局限性变得更加突出。但 MCP 可能并不是试图解决人类主导的系统中的这些问题,AI应用需要更高的灵活性、动态性和双向通信能力。

二、MCP的运作机制与创新优势

MCP 是面向未来的,它试图为一个 AI 主导的世界解决问题。好吧,也许"AI 主导"不是最贴切的词,但至少是一个"AI 优先"的世界。那么这种通信会是什么样子呢?

  1. 能力协商机制

    MCP的核心创新之一是能力协商,在连接建立时,客户端与服务器会交换各自的能力信息

    在这种情况下,我们仍然有客户端,现在我称之为 MCP 客户端;我们仍然有所谓的"API",我称之为 MCP 服务器。基本上,服务器会提供一些功能供客户端使用。这就是它的工作原理。 在这个例子中,我们先关注"工具"。把"工具"想象成像/products、/orders 这样的端口服务点,或者是服务器暴露的能力。我会给你们展示一个简单的例子。

    • 在构建的 MCP 服务器中有一个工具叫"invoke model"(调用模型)。这个工具需要一个负载(payload),用类型提示(type hints)指定了这个负载的格式。我也用类型提示指定了这个工具响应的格式。
    • 在文档字符串(docstring)中告诉调用这个工具的人如何使用它:它做什么,参数是什么,参数的示例是什么,调用者应该期待什么回应,响应的意义是什么。
  2. 客户端和服务器会交换能力

    当客户端第一次连接到服务器时,客户端和服务器会交换能力( exchange of capabilities)。连接的第一个步骤就是交换能力,这是协议驱动的。服务器会告诉客户端:"这些是我支持的工具以及它们的工作方式。"下次客户端中的代理(agent)想做某事时,它可以检查这些能力,决定是否要调用服务器。

    这个工具是自我描述的。不需要一个单独的文件来解释这个工具做什么,不需要另一个网站,也不需要一个带 API 文档的 URL。所有东西都在一起------代码和文档合二为一。传统的 WEB API 想让工具根据需要自动使用这些 API,你就必须提供文档。

    MCP它是"自我修复"的------其实不该说是修复,因为它之前没坏,但它能动态理解变更。回到之前的例子,假设我们需要更改某个工具。比如现在的"invoke model"接收一个负载,明天我想再传一个 URL。我希望"invoke model"能接收一个 URL。这是契约的变更,但因为这不是传统 API,调用这个功能不是硬编码的,不需要更改任何客户端。

  3. smmpling机制

    假设你在MCP服务器中构建一个能力,需要用大语言模型(LLM)做某事,比如对某些内容进行情感分析。传统方式是服务器连接到 Open AI API,使用 GPT 来完成这个能力,然后把响应返回给客户端。这没问题。但我们可以用"sAmpling"。在 MCP 中,服务器可以问客户端:"你能帮我运行这个查询吗?"这一切都运行在大语言模型的上下文中,有一个代理决定调用哪些工具。所以如果服务器能请求客户端:"嘿,我需要运行这个查询,你能用你已有的 LLM 帮我跑一下吗?"甚至服务器还能指定用哪个模型,比如"请用 GPT-4,如果有的话。"客户端会运行查询,把响应发回给服务器。

服务器与客户端通信应该有人工介入(human-in-the-loop),为了信任、安全和保障,用户得能拒绝采样请求。按序列图,服务器请求客户端运行查询,客户端先把请求给用户,用户批准后,客户端发给 LLM,LLM 生成响应,响应回到客户端,用户再次批准,然后发回服务器。这就是采样的工作方式。

三、总结

好的,用更精简的话概括MCP:

MCP 是什么?

  • 一种面向AI应用的新型通信架构。
  • 基于客户端-主机-服务器模式,用JSON-RPC 2.0协议。
  • 核心是"能力协商"和"采样"机制。

MCP 的特点:

  • 动态灵活,能适应接口变化。
  • 分布式AI处理,利用客户端LLM能力。
  • 注重安全,支持人工介入。
  • 面向未来AI应用。

MCP 与传统 API 的区别:

  • 传统API:静态、集中式。
  • MCP:动态、分布式、更安全。

简单来说,MCP是为了更好的支持AI应用,而设计的一种新式的API架构。

四、参考

  1. Model Context Protocol Specification
  2. MCP IS awesome and here is why
相关推荐
gnip1 小时前
vite中自动根据约定目录生成路由配置
前端·javascript
前端橙一陈2 小时前
LocalStorage Token vs HttpOnly Cookie 认证方案
前端·spring boot
哥不是小萝莉2 小时前
了解DeepSeek V3.2和Claude Sonnet 4.5
deepseek·claude 4.5
~无忧花开~2 小时前
JavaScript学习笔记(十五):ES6模板字符串使用指南
开发语言·前端·javascript·vue.js·学习·es6·js
泰迪智能科技012 小时前
图书推荐丨Web数据可视化(ECharts 5)(微课版)
前端·信息可视化·echarts
大模型真好玩2 小时前
架构大突破! DeepSeek-V3.2发布,五分钟速通DeepSeek-V3.2核心特性
人工智能·python·deepseek
CodeCraft Studio3 小时前
借助Aspose.Email,使用 Python 读取 Outlook MSG 文件
前端·python·outlook·aspose·email·msg·python读取msg文件
家里有只小肥猫4 小时前
react 初体验2
前端·react.js·前端框架
慧慧吖@4 小时前
前端发送请求时,参数的传递格式
前端
L李什么李4 小时前
HTML——使用表格制作简历
前端·javascript·html