🦸🏻#14: 什么是MCP，为什么大家——突然间！——都在谈论它？

你需要了解的关于模型上下文协议的一切

“即使是最复杂的模型也受限于它们与数据的隔离——被困在信息孤岛和遗留系统中。” Anthropic，关于上下文集成的重要性

当今的大型语言模型（LLMs）在独立运行时非常智能，但一旦需要超出其固定训练数据范围的信息时，它们就会遇到困难。为了使AI代理真正有用，它们必须在正确的时间访问正确的上下文——无论是你的文件、知识库还是工具——甚至可以根据该上下文执行更新文档或发送电子邮件等操作。历史上，将AI模型连接到所有这些外部来源一直是一项混乱的、临时性的工作。开发人员必须为每个数据源或API编写自定义代码或使用专用插件。这使得“连接”集成变得脆弱且难以扩展。

为了简化这一点，Anthropic提出了模型上下文协议（MCP）——一个旨在将AI助手与数据和工具的世界连接起来的开放标准，以插入许多不同的上下文来源。他们于2024年11月宣布了这一消息。最初的反应有些平淡。但现在MCP正在流行，已经超越了Langchain，并有望很快超越OpenAPI和CrewAI。主要的AI参与者和开源社区正在围绕MCP聚集，将其视为构建代理AI系统的潜在游戏规则改变者。为什么？

在本文中，我们将深入探讨MCP——为什么它现在是一个热门话题，MCP如何实现向更集成、上下文感知AI的转变，它在代理工作流中的位置，以及开发人员、研究人员、AI工程师和技术高管应该了解的幕后细节。我们还将探讨一些很少有人尝试过的MCP创新应用。总的来说，这是一份很好的入门指南，对于那些已经尝试过MCP并希望了解更多信息的人也很有用。深入了解！

---

🔳 Turing Post 在 🤗 Hugging Face 上驻扎 -> 点击关注！

更新：如果你对协议感兴趣，你可能还想阅读我们对A2A的深入探讨

---

本期内容包括什么？

• 为什么MCP现在才引起轰动（而不是去年11月）？
• 那么，什么是MCP，它是如何工作的？
• MCP技术概述
• 我该如何开始使用MCP？
• 在MCP出现之前，AI系统是如何处理上下文和工具访问的？
• MCP是万能药吗？
• MCP在代理编排及其在代理工作流中的位置
• MCP解锁的新可能性
• 总结
• 深入学习的资源

为什么MCP现在才引起轰动（而不是去年11月）？

MCP最初于2024年11月下旬由Anthropic开源并宣布。当时，它是一个令人兴奋的想法，但没有多少人注意到并认真对待。直到2025年初，MCP才真正进入AI社区的视野。最近的这一波热潮有几个主要原因：

• 集成问题解决者： AI代理和代理工作流在2023-2024年成为热门词汇，但它们的致命弱点仍然存在：将这些代理与现实世界的业务系统和数据集成。最初，大部分注意力都集中在模型能力和提示技术上，而不是集成。MCP通过定义“如何连接现有数据源”（文件系统、数据库、API等）到AI工作流来直接解决这一差距。随着人们对此的理解加深，MCP开始被视为用于构建严肃的、生产就绪的AI代理的缺失拼图。（这是HumanX会议的观点之一：近年来，我们主要专注于构建单个AI模型，每个模型都专门用于特定任务。但随着复杂性和需求的增长，正在向集成系统转变——多个专业模型、软件组件、API、数据源和接口协同工作的编排。）
• 社区和采纳： 在短短几个月内，MCP从一个概念发展成为一个不断增长的生态系统。早期采用者包括Block（Square）、Apollo、Zed、Replit、Codeium和Sourcegraph等公司，它们开始集成MCP以增强其平台。快进到2025年，生态系统已经爆发——到2月份，已经有超过1000个社区构建的MCP服务器（连接器）可用。显然，随着行业向更集成、上下文感知的AI发展，MCP引起了共鸣。这种网络效应使得MCP更具吸引力：通过MCP可用的工具越多，采用该标准就越有用。
• 事实标准势头： 与又一个专有SDK或一次性框架不同，MCP是开放的、模型无关的，并得到了主要AI参与者的支持。这意味着任何AI模型（Claude、GPT-4、开源LLM等）都可以使用MCP，任何开发人员或公司都可以在未经许可的情况下创建MCP集成。社区中的许多人现在认为MCP很可能成为标准化AI系统连接外部数据竞赛的赢家（就像USB、HTTP或ODBC在其领域中变得无处不在的标准一样）。
• 快速演进和教育： Anthropic不仅发布了MCP并置之不理；他们一直在积极改进它并教育开发人员。在最近的AI峰会上，Anthropic的Mahesh Murag举办了一场病毒式传播的研讨会，加速了MCP的采用。（请记住，所有进一步学习的链接都包含在文章末尾。）

那么，什么是MCP，它是如何工作的？

MCP规定了AI如何发现、连接和使用外部工具的明确规则——无论是查询数据库还是运行命令。这使得模型能够超越其训练数据，使其更加灵活并感知周围的世界。

MCP技术概述

一个显著的特点是MCP的动态发现——AI代理自动检测可用的MCP服务器及其功能，无需硬编码集成。例如，如果你启动一个新的MCP服务器（如CRM），代理可以通过标准化的API立即识别并使用它，提供传统方法无法比拟的灵活性。

我该如何开始使用MCP？

最好的起点是官方的MCP文档和仓库。Anthropic开源了规范并提供了SDK（包括Python和现在的Java等语言）。通常的步骤是：

• 运行或安装您关注的工具或数据源的MCP服务器。 Anthropic有一个预构建的流行系统（Google Drive、Slack、Git、数据库等）服务器的开源仓库。您可以安装这些服务器并进行配置（通常只需使用您的凭据或密钥运行命令）。
• 在您的AI应用程序中设置MCP客户端。 如果您使用Claude的应用程序，您可以在UI中添加服务器。如果您正在编写自己的代理，请使用MCP SDK连接到服务器（提供地址/端口）。
• 一旦您在客户端中启用了MCP服务，客户端将获取额外提供的功能： 额外的工具、资源和提示模板。
• 调用并迭代。 模型/代理现在可以根据需要调用MCP工具操作。确保监控日志以查看它是否正确调用了服务器。您将看到请求命中MCP服务器并返回响应。

为了快速入门，Anthropic建议尝试Claude桌面集成（如果您有权限）或运行示例服务器并使用其提供的快速入门指南。社区也非常活跃——MCP服务器的目录正在迅速扩展。一些流行的连接器包括Google服务（Drive、Gmail、Calendar）、Slack（聊天和文件访问）、GitHub/Git（用于代码仓库）、Postgres等数据库、Web浏览器或Puppeteer（用于浏览网页）等等。许多服务器都列在社区目录中（一些开发人员已经创建了网站来索引它们）。官方的MCP GitHub也托管了大量连接器实现，供您入门。如果您有一个未涵盖的利基工具，您可以使用SDK构建自己的MCP服务器——通常它只是该工具API的一个薄包装器，以MCP格式暴露一个函数。

我们感谢Will Schenk澄清了MCP和如何开始使用它的一些事情。他分享了这个快速的动手演练，演示了MCP与Tezlab的特斯拉监控服务协同工作。

在MCP出现之前，AI系统是如何处理上下文和工具访问的？

让我们简要回顾一下为AI提供外部知识或行动的传统方法，以及MCP的不同之处

• 自定义API集成（一次性连接器）： 最常见的方法是为每个服务编写自定义代码或使用SDK。例如，如果你想让你的AI代理访问Google Drive和SQL数据库，你需要分别集成Google的API和数据库驱动程序，每个都有自己的身份验证、数据格式和怪癖。这真是个麻烦！相比之下，MCP提供了一个单一的“钥匙”（协议），可以打开许多门，并且无需更改客户端即可添加新的MCP服务器。
• 语言模型插件（OpenAI插件等）： 2023年引入的另一种方法是为模型提供标准化插件规范（通常是OpenAPI模式），以便它能够以受控方式调用外部API（例如ChatGPT插件系统）。虽然在概念上与MCP相似（标准化工具访问），但这些插件是专有的且受限的——每个插件仍需单独构建和托管，并且只有某些平台（如ChatGPT或Bing Chat）才能使用它们。插件也倾向于专注于单向数据检索（模型调用API并获取信息），而不是维护持续的交互式会话。MCP的不同之处在于它是开源和通用的（任何人都可以实现它，不与任何AI提供商绑定），并支持丰富的双向交互。它就像AI和工具之间的对话，而插件通常是无状态的问答调用。
• 通过框架使用工具（LangChain工具、代理）： 代理编排库（如LangChain）普及了为模型提供带有描述的“工具”（函数）的想法。例如，你可能有一个search()工具或一个calculate()工具，代理（通过LLM）决定何时调用它们。这很强大，但每个工具在底层仍然需要自定义实现——LangChain的库发展到500多个以一致界面实现的工具，但开发人员仍然需要连接这些工具或确保它们符合他们的需求。MCP在这里可以被视为补充：它为工具的实现提供了一个标准化的接口。实际上，你可以将MCP服务器视为一个随时可用的工具库，任何代理都可以使用。区别在于标准化所处的位置。LangChain创建了一个面向开发人员的标准（其工具类接口）来将工具集成到代理的代码中。MCP创建了一个面向模型的标准——运行中的AI代理本身可以在运行时发现和使用任何MCP定义的工具。这意味着即使你没有为特定工具自定义构建代理的代码，模型也可以即时集成它。实际上，这些想法正在融合：例如，LangChain的团队（当注意到MCP的激增时）提供了一个适配器，以便所有这些MCP服务器（连接器）都可以轻松地被视为LangChain工具。因此，在LangChain或其他框架中构建的代理可以像调用任何其他工具一样调用MCP工具，从而受益于不断增长的MCP生态系统。
• 检索增强生成（RAG）和向量数据库： 为LLM提供上下文的一种常用方法是使用检索器搜索知识库（文档、嵌入）并将顶部结果注入到提示中。这解决了模型的知识截止或有限记忆问题。然而，RAG通常处理静态文本片段，并且本身不允许模型执行超出索引范围的操作或查询。MCP实际上可以与RAG协同工作——例如，MCP服务器可以与向量数据库或搜索引擎接口，允许模型将搜索查询作为工具发出，而不是隐式地在每个提示中依赖检索。可以说MCP是一种更通用的机制：RAG提供被动上下文，而MCP允许模型通过定义的通道主动获取或操作上下文。在需要最新或交互式数据的场景中（例如，查询实时数据库或发布更新），MCP超越了仅仅检索文本——它可以触发操作。

MCP是万能药吗？

当然，MCP并非万能药，它是一个极其方便的集成层。但像任何新兴技术一样，它也带来了自己的一系列复杂性和挑战，开发人员和组织在大规模采用之前必须考虑这些：主要担忧之一是管理多个工具服务器带来的额外开销。运行和维护与这些本地服务器的连接可能很繁琐，尤其是在正常运行时间、安全性和可伸缩性至关重要的生产环境中。MCP的初始实现是为本地和桌面使用而设计的，这引发了它在基于云的架构和多用户场景中表现如何的问题。开发人员已经提出使MCP更无状态并适应分布式环境，但这仍然是一个持续的挑战。另一个问题在于工具可用性。仅仅因为MCP扩展了AI模型的工具集，并不意味着模型会有效地使用这些工具。以前基于代理的框架已经表明，AI模型可能在工具选择和执行方面遇到困难。MCP试图通过提供结构化的工具描述和规范来缓解这种情况，但成功仍然取决于这些描述的质量以及AI正确解释它们的能力。LangChain创始人Harrison Chase强调的社区驱动方法表明，文档齐全的工具可以提高可用性，但这仍是一个持续改进的领域。除了实施障碍，MCP的成熟度也是一个考虑因素。作为一项相对较新的技术，它会受到快速变化和不断发展的标准的影响。这可能导致破坏性更改，需要频繁更新服务器和客户端。虽然MCP的核心概念看起来稳定，但开发人员应该预期并为版本升级和不断发展的最佳实践做好准备。兼容性是另一个限制因素。 目前，MCP在Anthropic的生态系统（例如Claude）中获得一流支持，但更广泛的采用仍不确定。其他AI提供商可能不会原生支持MCP，需要额外的适配器或自定义集成。在MCP在AI平台中获得更广泛接受之前，其效用将受到一定限制。对于更简单的应用程序，MCP甚至可能过于复杂。 如果AI模型只需要访问一两个简单的API，直接API调用可能比实现MCP更有效的解决方案。与MCP的消息传递系统和服务器设置相关的学习曲线意味着，需要权衡其优势和复杂性。安全和监控也带来了持续的挑战。 由于MCP充当中间层，它需要强大的身份验证和权限控制以防止未经授权的访问。像MCP Guardian这样的开源计划已经出现，通过记录请求和强制执行策略来解决这些问题，但在企业环境中保护MCP仍然是一项正在进行的工作。

总的来说，这些限制都不是障碍，但明智的做法是从实验性或非关键部署开始，以了解其运作方式。 MCP最好的地方之一是——积极参与的社区。由于它是开放的，您面临的问题可以共同讨论和解决。

MCP在代理编排及其在代理工作流中的位置

在之前的文章中，我们探讨了自主代理的构成要素：分析（身份和上下文）、知识、记忆、推理/规划、反思和行动。代理需要观察和理解其环境（分析/知识），记住过去的交互（记忆），规划其行动（推理），执行行动（执行工具调用或输出），然后反思和学习。MCP的作用是什么？

MCP本身不是一个“代理框架”；相反，它充当代理的标准化集成层。MCP主要关注行动部分——具体来说，为代理提供一种标准化的方式来执行涉及外部数据或工具的行动。它提供了将AI代理以安全、结构化的方式连接到外部世界的管道。没有MCP（或类似的东西），每次代理需要在世界上做某事——无论是获取文件、查询数据库还是调用API——开发人员都必须连接自定义集成或使用临时解决方案。这就像建造一个机器人，但必须定制每个手指以抓取不同的物体——繁琐且不可扩展。

重要的是再次强调，MCP本身不是编排引擎或代理大脑。相反，它是代理架构中的一个集成层。它通过充当统一的“工具箱”来补充LangChain、LangGraph、CrewAI或LlamaIndex等代理编排工具，AI代理可以从中调用外部操作。它不取代编排——编排决定代理何时以及为何使用工具——MCP定义了这些工具如何被调用以及信息如何交换。

它类似于代理的标准API网关，通过允许客户端（代理）和服务器（工具）之间的通用兼容性，将集成复杂性从“N×M”问题简化为“N+M”问题。最终，MCP简化了外部功能的集成，使代理更具通用性、适应性，并能够在各种上下文中执行复杂的任务。

MCP解锁的新可能性

MCP仍然很新，其全部潜力才刚刚开始被探索。第一波用例是显而易见的——将企业数据连接到聊天助手，或通过仓库访问增强编码代理。但一些新兴的应用可能会将AI代理提升到新的水平。

• 多步骤、跨系统工作流：代理系统通常需要在不同平台之间进行协调。 假设AI计划一个事件：它检查你的日历，预订场地，通过电子邮件邀请客人，安排旅行，并更新预算表。目前，这需要手动拼接API。有了MCP，所有这些操作都可以通过一个单一的接口进行。代理调用一系列MCP工具（每个任务一个），并在它们之间保持共享上下文——没有丢失的线程，没有自定义集成。
• 理解其环境的代理（包括机器人）： 除了工具访问，MCP还可以使嵌入在智能环境（无论是智能家居还是操作系统）中的AI代理。AI助手可以通过标准化的MCP服务器与传感器、物联网设备或操作系统功能进行交互。AI不再孤立运行，而是获得实时感知，从而实现更自然和主动的协助。
• 协作代理（代理社会）——对此我非常兴奋——MCP还可以充当多代理系统的共享工作空间。专门的AI代理——一个用于研究，一个用于规划，另一个用于执行——可以使用MCP动态交换信息和协调任务。有了MCP，每个代理都不需要直接集成；它们只需访问一个通用工具集。
• 深度集成的个人AI助手： MCP可以允许用户配置自己的AI，以安全地与个人数据和应用程序交互。本地MCP服务器可以授予AI访问电子邮件、笔记和智能设备的权限，而无需将敏感数据暴露给第三方。这可以创建一个超个性化的AI助手，而无需依赖基于云的服务。
• 企业治理和安全： 对于企业而言，MCP将AI对内部工具的访问标准化，减少了集成开销。它还实现了治理：AI交互可以通过监督层进行日志记录、监控和控制，防止意外操作，同时保持效率。

这些只是MCP潜力的初步展望。通过实现流畅、上下文感知、多步骤的交互，它使AI代理更接近真正的自主工作流执行。

结束语

MCP正迅速发展成为一个强大的标准协议，将AI从一个孤立的“大脑”转变为一个多功能的“执行者”。通过简化代理与外部系统的连接方式，它为更强大、更具交互性、更用户友好的AI工作流铺平了道路。

即将推出的关键功能（基于Anthropic的Mahesh Murag的研讨会）

远程服务器和OAuth

• 使用SSE实现无缝远程托管。
• 内置OAuth 2.0，用于安全集成（例如Slack）。

官方MCP注册表

• 服务器的集中发现和验证。
• 企业友好：主机可以运行私人注册表。

知名端点

• 用于第一方服务器发现的标准化.well-known/mcp文件。

进一步增强

• 流支持、无状态连接、主动服务器行为和更好的命名空间。

每一次更新都将使MCP更加健壮，帮助AI代理更深入地集成到实际工作流中。这是一项社区驱动的工作，因此请关注路线图，加入讨论，并帮助塑造AI和软件交叉的未来。

MCP迅速崛起，我们甚至不得不为此更改了我们的编辑计划。这个话题需要解释。在讨论代理工作流中的行动之后，涵盖它感觉很自然。在下一期中，我们将探讨人机通信和人机回路（HITL）集成，然后转向多代理协作。敬请期待。

分享这篇文章有助于我们成长并接触更多人——谢谢！

深入学习资源：

• Anthropic推出模型上下文协议
• 模型上下文协议文档和快速入门指南
• MCP文档
• GitHub上的模型上下文协议
• GitHub上的MCP服务器集合
• 使用模型上下文协议构建代理（特别是关于MCP下一步的部分）——来自Anthropic的Mahesh Murag，AI Engineering Summit研讨会
• 为什么MCP获胜——来自Latent Space的swyx
• GitHub Star历史（图表）
• MCP：昙花一现还是未来标准？——来自LangChain
• GitHub上的MCP Guardian
• 使用MCP暴露服务
• Reddit上对MCP的初步反应

来自 Turing Post 的资料

• 🦸🏻#1：开放性和 AI 智能体——从生成式 AI 到创造性 AI 的路径？
• 🦸🏻#5：智能体系统的构建模块
• 🦸🏻#9：AI 会记忆吗？记忆在代理工作流中的作用
• 🦸🏻#10：当今的生成式 AI 真的能推理吗？
• 🦸🏻#11：智能体如何规划和推理？
• 🦸🏻#12：代理如何从自己的错误中学习？反思在AI中的作用
• 🦸🏻#13：行动！AI代理如何使用UI和API工具执行任务

感谢您的阅读！

---

📨 如果您想直接在收件箱中收到我们的文章，请在此订阅

---