点击箭头处“蓝色字”，关注更多及时AI资讯哦！！
无论是构建AI驱动的IDE、聊天界面，还是创建自定义的AI工作流，都需要依赖数据源来连接LLM与应用所需的上下文，但是实际情况是，即使是最先进的模型，也会因为受制于传统系统和信息流的低集成度，以及定制化的集成过程，这些都使得系统难以高效的扩展，也导致LLM能力无法完全在垂直场景中得以完全的发挥。
MCP的出现就是面向在解决大型语言模型(LLM)在连接数据源时遇到的难题，通过提供一种通用的连接方式，允许AI助手与各种本地和远程数据源无缝连接，用一个统一的方案代替分散的数据源集成方式，通过更简单和更可信的方式来让AI应用灵活高效的接入任何需要的数据!
MCP可以理解为是一个通用接口标准，让任何AI模型都能以标准和高效的方式和外部数据源对接。我们不必再为每个数据源写定制的集成代码了，LLM的能力放大上高速了!
官方讲解的文档链接：https://modelcontextprotocol.io/quickstart
接下来我们来一起解读一下这个古希腊掌管AI界数据接入秩序的神!
MCP解决的问题
在MCP出现之前，要想实现LLM对数据源的接入，需要通过/function-calling的方式，在项目中预定义tool工具函数和请求对应的结构体，LangChain、Vercel AI SDK等针对这个情况也有各自的封装和提效，比如统一的工具定义管理、自动化的调用执行流程、标准化的返回结果处理，虽然简化了流程，但函数调用工具仍需在编译时确定，动态接入的灵活性有限，而且也还是需要一定的开发量。
MCP直面以上的情况提供了灵活的解决方案，旨在解决AI工具与模型数据库对接不统一的问题，并通过标准化接口实现快速数据访问。MCP允许运行时动态添加或移除工具，无需重新编译代码，显著提升了功能扩展的效率和便捷性。无论是本地部署还是云端部署，MCP 都能很好地适应多种场景和需求。以 Claude Desktop 为例，该应用通过 MCP 实现了工具能力的动态扩展，仅需修改配置文件并重启，就能即时获得 MCP 服务器提供的全新工具支持。总结来说，MCP的核心特点如下：
1. 开放性：开发者可以自定义工具的实现，并支持私有化部署 MCP 服务器，从而方便地与现有系统进行深度集成。
2. 标准化：基于统一的通信协议、标准化的接口，为开发者提供提供清晰的工具定义接口和一致的调用执行流程，包括模型上下文协议规范、SDK以及开源代码库，开发者可以根据这些规范快速构建协议范例。
3. 灵活性：允许运行时动态添加或移除工具，而无需重新编译代码。
什么是MCP模型上下文协议?
MCP模型上下文协议准确的说是一种开放标准，使开发人员能够在数据源和AI应用之间建立安全的双向连接。该架构非常简单：开发人员可以通过 MCP 服务器公开数据，也可以构建连接到这些服务器的 AI 应用程序(MCP 客户端)。
MCP主要包含三个主要组件：
1.模型上下文协议规范和 SDKMCP（官网：https://modelcontextprotocol.ioMCP、GitHub：https://github.com/modelcontextprotocol）
2.Claud桌面应用程序中的本地 MCP Server服
务器支持：通过 Claude 桌面应用快速实现本地化数据连接，应用安装链接 https://claude.ai/download。
3.MCP服务器的开源存储库：包含 Google Drive、Slack、GitHub 等流行系统的预构建实现，便于直接部署和测试https://github.com/modelcontextprotocol/servers
Claude 3.5 Sonnet 模型还支持快速开发 MCP 服务器，开发人员现在可以MCP根据标准协议进行构建，而不是为每个数据源维护单独的连接器，使个人和企业能够以最低的门槛实现与重要数据集的对接。
MCP核心组件&工作原理
MCP 遵循客户端-服务器架构，其中：
1. Hosts(主机)是发起连接的 LLM 应用程序(如 Claude Desktop 或 IDE)
2. Clients(客户端)在主机应用程序内部与服务器保持 1:1 连接
3. Servers(服务器)向客户端提供上下文、工具和提示
client客户端与server服务端简单的交互流程如下：
1. 客户端发送带有协议版本和功能的初始化请求
2. 服务器响应其协议版本和功能
3. 客户端发送初始化通知作为确认
4. 正常消息交换开始
MCP 支持多种传输机制：
1. Stdio 传输
使用标准输入/输出进行通信
适合本地进程间通信
2. 基于 HTTP 和 SSE 的传输
使用 Server-Sent Events（SSE） 进行服务器到客户端的消息传递
使用 HTTP POST 进行客户端到服务器的消息传递
所有传输机制都采用 JSON-RPC 2.0 协议进行消息交换。详细的 MCP 消息格式规范可参考相关文档。
MCP协议中，主机应用程序可以连接到多个服务器
MCP Hosts: 想要通过 MCP 访问资源的程序，例如 Claude Desktop、IDE 或 AI 工具
MCP Protocol: 与服务器保持 1:1 连接的协议客户端，其双向安全连接的协议，允许数据源和AI助手之间安全地共享信息并实现闭环交互。
MCP Servers: 通过标准化模型上下文协议公开特定功能的一个个轻量级程序(A、B、C)
Local Resources: MCP server 服务器可以安全访问的计算机资源，比如数据库、文件、服务等
Remote Resources: MCP server 服务器可以连接到的互联网上数据资源，例如通过 API请求等等
MCP接入效果
通过Anthropic的AI工具Claude Desktop，MCP还可以轻松实现与GitHub等工具的快速交互，仅需几分钟即可完成创建代码仓库等任务，接下来我们来结合本地的Claude桌面与SQLite的连接示例来帮助大家理解上面的流程：
在这个流程中：
1. Claude Desktop充当我们的MCP Server客户端
2. SQLite MCP Server服务器用来提供安全的数据库访问
3. 本地 SQLite数据库存储实际数据，也就是第一张图中的Local Resources
SQLite MCP Server 服务器和本地 SQLite 数据库之间的通信完全是完全发生在我们的计算机上，我们的 SQLite 数据库不会暴露在 Internet 上。MCP模型上下文协议会确保 Claude Desktop 只能通过明确定义的接口执行系统允许的数据库操作。这为用户提供了一种安全的方式来让 Claude可以分析和接入我们的本地数据。
具体配置和操作步骤大家可以参考这个文档：https://modelcontextprotocol.io/quickstart#installing-prerequisites-macos
最终的效果演示
基于Claude Desktop提问：Can you connect to my SQLite database and tell me what products are available, and their prices?
接着Claude Desktop会先是连接到 SQLite MCP 服务器，然后查询本地数据库，最后将查询到的数据格式化并呈现结果
这效果背后，MCP协议与Claude Desktop交互时的步骤为：
1. 服务器发现：Claude Desktop 在启动时连接到您配置的 MCP 服务器
2. 协议握手：当我们基于Claude Desktop进行数据询问时：
Claude Desktop会先确定哪个 MCP 服务器可以提供帮助(在本例中为 sqlite)
Claude Desktop通过MCP协议协商能力从
MCP服务器请求数据或操作
交互流程：
MCP的意义
Block 首席技术官 Dhanji R. Prasanna 表示：“像模型上下文协议这样的开放技术是将人工智能连接到现实世界的应用程序的桥梁，确保创新是可访问的、透明的，并且植根于协作，我们很高兴能与该协议合作并使用它来构建代理系统。消除机械负担，来让人们可以专注于创意。”
引擎当下的趋势是蒸馏，让模型更小以适应用户延迟窗口，但这样势必会导致「知识」丢失。如今，各大AI公司都在尝试不同的方法来挂载数据，比如谷歌依赖于自己的内部服务：搜索、Gmail、日历;微软正在尝试使用其安全的Office Copilot应用程序获取企业用户上下文;苹果试图通过隐私保护继续获取用户上下文，同时允许访问ChatGPT进行高级查询;而OpenAI已经尝试了GPT，现在正在尝试通过ChatGPT桌面应用程序连接应用程序。ChatGPT的愿景是通过屏幕共享控制用户桌面。
而Anthropic的解决方案是，提供一个干净的协议，通过该协议，任何网站，API或系统资源都可以被任何AI访问，而MCP的加入，或许会为AI的发展带来一些变化：
1. 随着AI模型能够原生接入第三方数据源，应用程序之前建立的独特数据集成优势正在消失，属于应用侧的数据护城河正被削弱。
2. 未来，各大AI模型会竞相提供与不同内容库的原生连接能力，前沿模型在「预集成」到各种内容商店能力上展开竞争。
3. 将会看到前沿AI模型与特定数据源公司建立独家的合作关系
延展：Function Calling与MCP对比
Function Calling与MCP的目标是一致的，本质是为了让大模型可以调用外挂的服务，对接更多的数据和能力，再作为补充上下文回答用户的问题;而Function Calling 由大模型通过 HTTP 请求第三方的外挂 API，而 MCP 是由大模型通过 RPC 请求第三方的外挂服务;
Function Calling 和 MCP 的核心和难点都在于大模型侧的意图识别，用户随机提问，如何找到匹配的外挂服务，实现 RAG，这是所有大模型面临的通用难题(比如 ChatGPT 有几百万的 GPTs 应用，如何根据用户提问路由到最匹配的那个 GPTs 来回答问题)，而MCP协议并不能解决这个问题。Claude 客户端目前的实现方式，是让用户自己写个配置文件，告诉大模型有哪些可以调用的服务，再由 Claude 在对话时自动识别，跟ChatGPT之前让用户选择使用哪些 Plugins 的逻辑一致
总结
MCP 的亮点是定义了一套标准且相对完善的协议，对于大模型和应用的生态协同有很大的指导意义。类似由微软提出并在 VS Code 实现的 LSP 协议一样(定义了编辑器如何与第三方语言服务交互，实现代码补全/类型约束/错误提示等功能)。MCP 协议的适用对象主要是大模型/应用客户端和第三方服务，跟 LSP 不同的是，编程语言的数量相对有限，最多几百个语言服务，社区协同下很快就能全部支持，编辑器可以根据文件的后缀快速定位到要调用的语言服务。
MCP 适用的第三方服务是海量的，MCP 的发展取决于有多少第三方服务愿意基于这套协议去实现 RPC 服务，最关键的还是大模型/应用客户端对海量 MCP 服务的路由寻址问题，目前来看这里没有固定的后缀，还是只能靠意图识别或者人工配置。
这就好比OpenAI最初开放的API协议，现在俨然已经成了一个约定俗成的标准，后来的大模型在开放自家 API 时都会选择兼容 OpenAI 的 API，主要原因有两个：一是 OpenAI 的 API 开放的早，很多应用接入了，兼容它对第三方接入友好;二是OpenAI的 API 实现的确实很规范，具备被抄作业的资格哇。
目前，多家公司如Block、Apollo等已经将MCP集成到其系统中，而Replit、Codeium和Sourcegraph等开发工具公司也在其平台上添加了对MCP的支持，协议也适用于 Google Drive、Slack、GitHub、Git、Postgres 和 Puppeteer 等流行企业系统的预构建 MCP 服务器。MCP协议作为第一个定义标准的规范，后面如果有越来越多的第三方服务基于这套协议开放了自己的服务，其他大模型/应用客户端应该会跟进;同时如果主流的大模型/应用客户端都支持了这套协议，那么作为一个第三方，也肯定愿意按这套协议开放自己的服务，比起为 GPTs / Coze / Dify 分别写一个 API 给智能体调用，MCP 服务只需要写一次，可以在任意支持 MCP 的客户端调用，按照现在各家接入趋势来看，MCP成为一个通用规范指日可待。
AI时代不掉队
同桌会的你都会
