tunan's blog

译者前言

最近在写一些关于MCP的文章，同时也在开发一些MCP Servers 例如 anki-mpc-server。

在这个学习过程中，于Keywords AI 论坛上看到了一篇不错的名为 A Complete Guide to the Model Context Protocol (MCP) in 2025的博客文章。

于是又忍不住，想翻译成中文分享给中文读者观看。下面是正文内容。

这是一个很长的文章，大约需要15-20 分钟的阅读时间。可以先收藏后看。等你读完这篇文章后，你就成MCP的专家了。

介绍

大语言模型现如今的能力已经是不可思议的了，但它们却经常独立运作。发展AI应用中最大的一个挑战就是以一种可靠且可扩展的方式源文档，为这些模型提供来自外部数据源（文档、数据库、API等）所需的上下文。通常，AI助手和数据源之间的每一次新集成都需要一个定制的解决方案，随之创建出很多难以维护的一次性的连接器。

为了解决这个问题，Anthropic（Claude AI助手背后的团队）于2024年晚些时候提出了模型上下文协议（MCP）。MCP是一个通用开放的标准，用于桥接AI模型和你的数据和工具所在之处，提供上下文信息因此更容易了。在本文中，我们将深入了解什么是MCP，为什么它是必要的，它是如何工作的，对开发者和更宽泛的AI行业意味着什么？

什么是MCP？

模型上下文协议是一个开放协议，它规范化了应用程序如何提供上下文信息给AI模型（尤其是指LLMs-大语言模型）。换言之，它是一门框架，定义了AI工具和外部数据源及服务相互联系的通用语言。Anthropic恰如其分地将MCP描述成“像是一个用于AI应用的USB-C端口”——一个通用的连接器，使得AI模型能以一致的方式连接到各种各样的工具和数据库中。就像USB-C规定了我们如何连接设备，MCP也规定了AI系统如何与不同的数据源及功能模块交互。

MCP的目的就是消弭AI模型与它们所需的大量信息间的隔阂。它使得开发者能够在AI应用和数据所在的系统之间搭建出安全且双向的连接通路。例如，使用MCP，一个AI助手可以从你的知识库获取文档、查询数据库或者调用一个外部API，所有这些都是基于一个统一协议。

这意味着AI应用不用再被“禁锢”，与企业中的信息和工具相隔离。相反，它们可以连续地获得它们所需要的及时性信息和上下文。MCP的最终目的是，在始终拥有正确上下文的情况下，帮助大模型产生更好、更具相关性的结果。

历史与发展

MCP由Anthropic发展而来，并于2024年年底开源出来，成为了AI领域那个日益增长问题的回应。在那时，业内还没有通用的标准来集成AI模型和外部数据及服务——每次的集成都是定制化且不能互用的。这就导致了Anthropic工程师所说的M×N问题，指的就是M个不同的AI模型连接到N个不同的工具或数据源时的组合激增。每对新组合都需要定制代码，这使得在现实世界应用中的AI系统难以扩展和维护。

Anthropic 看到这个痛点后设计了MCP来规范化AI助手和数据源之间的联系方式。他们在2024年的11月份发布了MCP的正式版，并为开发者们提供了正式的规范说明和SDKs(软件开发工具包)以及一套参考实现。从一开始，MCP就被设计成一个开源项目和开放标准，鼓励社区合作而不是依赖于单一的供应商。

早期的尝鲜者快速得拥抱起MCP。像Block（原名Square）和Apollo这些公司在MCP的初始发布期间就快速集成了MCP到了他们的系统中，同时像Zed、Replit、Codeium和Sourcegraph这些开发工具提供商也开始使用MCP来增强他们的平台了。

这些早期的支持彰显出市场对通用上下文协议的需求。正如 Block的CTO说的，“像模型上下文协议这种的开源技术就是连接AI和现实世界中各应用的桥梁，”强调了MCP在使AI集成易开发和可协作方面所担任的重要角色。

将MCP作为一种开放标准，Anthropic走了一条和其他成功开发标准相似的路（用于Web的Http或用于数据库的SQL）。除了Anthropic团队外，开源社区的贡献者们也出了不少力。现如今已经有了多种官方的不同语言的SDKs（Python、TypeScript、Java/Kotlin），以及持续增多的由社区为各种流行软件构建的开源MCP服务器。简言之，MCP开发是由简化AI-data集成的必要性所推动产生的。它的开源特性使其从一开始促使了一个易于合作的生态系统。

为什么使用MCP

为什么企业需要MCP，为什么你可能想在你的项目中使用它？简单说，喂给AI模型上下文信息一直颇具挑战，MCP为此提供了优雅的解决方案。下面是一些关键问题以及MCP是如何解决的：

支离破碎的集成：在MCP出现前，如果你想让AI模型来访问，比如说，你的Google Drive，客户数据库，Slack，你可能要实现三种不同的插件或连接器——每个都有独属的API和特性。这种分散性会导致大量的重复性工作、更多的Bug和过时的集成。MCP用一种标准化的协议替代了这些定制化的实现。你可以使用同一套方案嵌入任何数据源和服务到模型中，极大地简化了开发。
扩展和维护：定制化的集成不能自由地扩展。每次API改变或采用一个新模型，你都要重来一遍。随着时间推移，维护将是一个噩梦。设计MCP的明确目的就是解决这种“多对多”的集成问题。使用MCP后，同时支持该协议的AI工具和数据服务可以立即配对，不要再额外写适配代码。这种标准化意味着当在做某种升级时，联系不会轻易中断以及更容易扩展新用例。
上下文质量和相关性：即使是最智能的AI，它也局限于它拥有的训练数据。如果没有便捷的途径去刷新上下文内容，模型可能就给不出具体的、实时的答案，因为它们是没有能力看到实时数据的。MCP确保模型可以经常在它们所需之时去拉取及时性的相关上下文信息。例如，模型会通过MCP连接到你的知识库中并获取确切的信息，而非从训练数据中推测出一个答案。
互通性：在快速发展的AI领域，你可能会尝试不同的LLM和工具。如果没有某种规范，每次转换都需要以一种新方式重新集成。MCP提供了一个不依赖特定供应方的接口，从而可以随意更换底层模型（比如Claude和其他AI系统）或者添加新的工具，只要双方都遵循MCP协议，集成就能始终有效。这种弹性设计节省了开发时间，也避免了锁定在同一个LLMs提供方，对于开发者和组织来说是巨大的双赢。
安全性和控制：提供上下文意味着经常会给AI一些敏感数据。对于将内部数据发送给第三方服务或进入公域之中，许多开发者（合理地）对此有些谨慎和担忧。MCP在设计之初就考虑了安全性方面的最佳实现。因为它是开源协议，你可以在你自己的基础设施上托管MCP服务，不让数据迈过防火墙。你可以通过协议只暴露所需要的数据。MCP的规范化实现也使得监管和执行AI访问数据的方式更容易（例如，特定的数据需要特定的鉴权）。总之，MCP使你不需要担心数据失控，可以安全地分享数据。

通过解决这些挑战性问题，MCP让构建具有情景理解力的AI应用变得更简单了。开发者再也不用深陷无休止的定制化集成之中了，可以将精力转移到他们应用的核心逻辑之上。并且完全可以相信MCP能够以一致且安全的方式来处理上下文信息。从而实现更快的开发周期和更健壮的AI解决方案。

MCP的主要优点

为了总结这些优化，下面罗列了在AL/ML应用中使用上下文协议的主要优点。

提升AI的表现和相关性：因为模型可以容易地获取它所需的信息了，所以它能产生更准确的、内容丰富的回答。Anthropic设计MCP的目的是通过打破数据孤岛，帮助“前沿模型产生更好、更相关的响应”。早期的使用者发现，让AI直接获取相关数据（通过MCP）会让其产生更细致和准确的输出——例如，当AI编程助手处于特定的工程项目上下文中，会用更少的推测来产生更有效的代码。
跨系统的互通性：MCP是一个开放标准，不绑定在任何单一的AI供应商或数据平台之上。这意味着它可以作为通用桥梁跨立在多方系统之间。一个遵循MCP的数据源可以给任意支持了MCP的AI客户端提供数据，反之亦然，就像是连接任意设备到一个统一端口。这促进了一个丰富的生态系统，来自不同开发者的不同工具和模型可以立即拆箱即用。这为了新集成提供未来保障。
开发效率和重复利用：使用MCP，开发者不需要为新集成再造轮子。你可以对标规范协议进行一次开发并在多个项目中重复使用。现成的MCP 连接器（服务器）数量还在增长，比如为了一些像Google Drive、Slack、GitHub、database等流行服务所做的MCP服务器。你可以很方便的嵌入它们，而不是再写定制代码。
模块化与可扩展性：MCP推崇AI系统中使用模块化的架构。通过一个良好设计的协议将AI模型和数据源解耦开，每个组件可以独立地扩展和升级。需要添加一个新的数据源？直接添加一个新的MCP服务器就可以了。想要同时使用多个AI模型吗？它们可以通过MCP共享相同的上下文来源。这使可组合的AI代理能够像乐高积木一样进行功能的混合搭配。
增强安全和合规性：MCP支持将数据控制在你的基础设施之上，只通过受控的通道交换所需数据。你可以在本地或者云上运行你的MCP服务器，使用鉴权和签名确保安全。这使得满足数据隐私法规又仍然保留强大的AI能力。

本质上，MCP创造了双赢的局面：模型表现和能力提升，同时为开发者和组织提升了效率、伸缩性和安全性。

MCP是如何工作的？（实现概览）

所以我们如何真正地使用MCP呢？在上层视角，MCP遵循client-server架构去连接AI模型和外部上下文。这里是一个简单的概览：

MCP 服务器（数据/工具的连接器）：一个MCP服务器与特定的数据源和服务相联系，通过MCP规范向外暴露自己。例如，存在针对Google Drive、Git、GitHub、SQL和Slack的MCP服务器。这些MCP服务器通常是开源且可自行修改的。
MCP 客户端（在AI应用中）：AI应用中包含MCP的客户端，用于连接MCP服务器并传递上下文/数据给AI模型。Cluade的桌面程序默认包含这个客户端。
规范化行为（原语¹）
- 提示²——模型可以用的指示和模版
- 资源³——模型可以阅读的结构化文档
- 工具⁴——模型可以执行的功能
客户端原语
- 根节点⁵——入口点（如文件夹或数据库域）
- 采样⁶——让服务器向模型询问子问题
集成工作流：开发者通常为他们想接入的数据运行一个MCP服务器并使用SDKs来联结客户端。这种JSON-RPC的抽象化支持多种环境。
开发者体验：SDKs(Python、TypeScript等语言)简化了MCP服务器的实现。Claude甚至可以帮助编写MCP代码。它是开放、可扩展且对开发者友好的。

MCP的未来和它对AI行业的影响

MCP仍很年轻，但它的发展之路野心勃勃：

更多的使用者：更多的AI工具、平台和模型供应商采纳了MCP，并将集成标准化贯穿到整个行业。这标志着LLMs和工具之间的兼容性可以做到即插即用。
远程和云上集成：基于网络的MCP安全使用一直在增长——云托管的MCP服务器，远程AI代理和企业中心正蓬勃发展。
多模式的支持：MCP最终可处理图像、声音和视频内容。未来的AI可以通过MCP将图表、录制内容或者其他渲染结果纳入到上下文信息中。
标准化的影响：如果MCP获得了广泛的支持，其他工具会天然地实现它——例如提供了MCP端点的CRMs或者项目管理工具，从而实现无缝接入AI。
社区驱动的治理：Anthropic计划为MCP进行开放的管理——可能形成一个独立的标准组织。社区的声音将影响协议的演变。

总结

模型上下文协议在AI世界中是一个振奋人心的发展成果，因为它解决了一个实际的问题：如何将强大的AI模型和它所需且真正有用的外部知识和数据连接起来。通过提供一个共用的上下文协议，MCP使开发者开发智能应用更加简单，这些智能应用的视野和能力也超出了内置的训练集。

在这篇文章中，我们介绍了MCP，看到了它为什么被创造出来，它所提供的好处，它是如何工作的以及它的未来方向。对于开发者和科技爱好者而言，MCP代表了朝着更互联、更灵活、更易于协作的AI迈出的重要一步。

随着这个标准被接纳，我们可以眺望未来，在未来连接AI模型到新的数据源将和插入一台设备一样简单——由于像MCP这种的创新，身边的AI系统将变得更集成和更加容易理解上下文语境。

注

原语-Primitives 在英文里，primitive 本义是 “原始的、基础的、最简单的”。在计算机/数学/工程里，它常常翻译为：基本元素、原语、基础构件。
提示-Prompts 是AI中最经常用的英文之一。
资源-Resources 指MCP协议中的资源，告诉AI模型MCP服务器都能提供哪些资源。
工具-Tools 指MCP协议中的工具方案，告诉AI模型MCP服务器都能提供哪些方法来处理资源。
根节点-Roots
采样-Sampling 指服务器从模型中"采集"或"获取"对特定子问题的响应样本

为了贴合中文读者的语言习惯，全文基本上都是古法翻译的，如有错误之处烦请指出、不吝赐教。

本文翻译尚未获取授权，如有侵权，请联系我删除

原文请点击：A Complete Guide to the Model Context Protocol (MCP) in 2025

2025年MCP最全指南🍃