什么是 MCP，为什么大家突然都在讨论它？

turingbooks

于 2025-04-11 14:07:40 发布

阅读量2.1k

点赞数

文章标签：人工智能

原文链接：https://mp.weixin.qq.com/s?__biz=MjM5Njc0MjIwMA==&mid=2649833787&idx=1&sn=a7307e9457e1e60320a67741ac11ad06&chksm=bf4e262a6e16dd4444c321f01601ec5de031c4abac6ba1e551a410a9705246bfeb8185cf075f&scene=126&sessionid=0

版权

“即使是最先进的模型，也会因为无法访问外部数据而受限——它们被困在信息孤岛和传统系统背后。”Anthropic 这样解释为什么上下文整合如此重要。

如今的大语言模型（LLM）在封闭环境下已经足够聪明，但一旦需要获取训练数据之外的信息，它们的表现就会大打折扣。要让 AI Agent 真正发挥作用，它必须能够在正确的时间访问到正确的上下文信息——无论是你的文件、知识库，还是各种工具——甚至还要能基于这些上下文完成一些操作，比如更新文档、发送邮件等。但在过去，将 AI 模型与这些外部信息源打通通常都是一个混乱、零散的过程。开发者不得不为每个数据源或 API 编写专门的适配代码或插件，这种“手工集成”的方式既脆弱又难以扩展。

为了解决这个问题，Anthropic 提出了 Model Context Protocol（MCP）——一个开放标准，旨在把 AI 助手与各种数据和工具连接起来，使模型可以同时接入多种不同来源的上下文信息。这个协议首次发布是在 2024 年 11 月。当时反响平平，但如今 MCP 已经开始流行，热度超过了 Langchain，并有望很快赶超 OpenAPI 和 CrewAI。越来越多的主流 AI 厂商和开源社区开始支持 MCP，认为它有潜力成为构建 Agent 化 AI 系统的关键工具。为什么 MCP 会被看好？

在这篇文章中，我们将深入解析 MCP——为什么它近期成为热门话题，MCP 如何推动 AI 朝着更高集成度和更强上下文感知的方向发展，它在 Agent 工作流中的角色，以及开发者、研究人员、AI 工程师和技术管理者应当了解的一些鲜为人知的细节。我们还将探讨一些鲜有人尝试但极具创新性的 MCP 应用案例。整体来看，这既是一篇非常适合入门的指南，也同样适用于那些已经开始尝试 MCP、希望进一步深入了解的用户。继续往下看！

本文内容包括：

为什么 MCP 现在才火（而不是去年 11 月）？
什么是 MCP，它是如何工作的？
MCP 的技术概览
如何真正开始使用 MCP？
在 MCP 之前，AI 系统是如何处理上下文和工具接入的？
MCP 是“银弹”式的万能解决方案吗？
MCP 在 Agent 编排中的角色及其在 Agent 工作流中的地位
MCP 解锁的新可能性
总结思考

为什么 MCP 现在才火（而不是去年 11 月）？

MCP 最早是在 2024 年 11 月由 Anthropic 以开源形式发布的。虽然当时这个想法很新颖，但并没有引起太多关注。而在 2025 年年初，MCP 真正开始在 AI 社区引爆，背后主要有几个关键原因：

集成问题的解决者

AI Agent 和 Agentic 工作流在 2023 到 2024 年成为热门概念，但它们的致命弱点始终没变——很难与真实的业务系统和数据进行集成。起初大家的关注点主要集中在模型能力和提示工程上，而非上下文集成。而 MCP 的出现正好填补了这一空白，它明确提出了“如何把已有的数据源（如文件系统、数据库、API 等）接入 AI 工作流”的标准。随着大家逐渐理解这一点，MCP 被视为构建真正可落地、面向生产环境的 AI Agent 所缺失的关键拼图。（这是 HumanX 大会上的一个重要观点：过去几年我们主要在构建单一的、面向特定任务的 AI 模型，而随着需求和复杂度的提升，趋势正在向系统集成方向演进——多个专业模型、软件组件、API、数据源和用户界面之间需要有序协作。）

社区与生态初具规模

在短短几个月内，MCP 从一个概念演变为一个逐渐成型的生态系统。早期接入者包括 Block（Square）、Apollo、Zed、Replit、Codeium 和 Sourcegraph 等公司，它们开始将 MCP 集成进自己的平台中。到了 2025 年，整个生态快速壮大——仅到 2 月，社区就已经构建出超过 1,000 个 MCP server（也就是连接器）。MCP 显然击中了行业的痛点，在迈向更强上下文感知与集成式 AI 的大潮中，它成为越来越多人的选择。网络效应也进一步放大了它的价值：MCP 可接入的工具越多，使用 MCP 的吸引力就越大。

“事实标准”的势头

不同于又一个专属 SDK 或私有框架，MCP 是开放且与模型无关的标准，并由头部 AI 厂商背书。这意味着，无论是 Claude、GPT-4 还是各种开源 LLM，都可以接入 MCP，而开发者和企业也可以自由创建 MCP 接口，无需获得许可。社区中已经有不少人将 MCP 看作是连接 AI 系统与外部数据的标准化竞赛中的潜在赢家，就像 USB、HTTP 或 ODBC 在各自领域成为通用标准一样。

快速迭代与开发者教育

Anthropic 并非发布完 MCP 就撒手不管，而是持续在推动 MCP 的优化与推广。比如在最近的 AI 峰会上，Anthropic 的 Mahesh Murthy 举办的关于 MCP 的 workshop 引发广泛关注，加速了 MCP 的普及。

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

MCP（Model Context Protocol）制定了一套清晰的规则，指导 AI 模型如何查找、连接和使用外部工具，无论是查询数据库还是执行某个命令。这让模型不再受限于静态的训练数据，而是能够根据实际需求灵活调用资源，增强对现实世界的感知和响应能力。

MCP 的技术概览：

MCP 的一个亮点功能是它支持动态发现机制 —— AI Agent 可以自动检测可用的 MCP server 及其功能，而不需要手动写死每个集成逻辑。比如说，当你新启动了一个 MCP server（比如某个 CRM 系统），Agent 就可以立即通过标准化的 API 自动识别并调用它，这种灵活性是传统方式很难实现的。

那我该如何开始使用 MCP 呢？

最好的起点是查看官方的 MCP 文档和代码仓库。Anthropic 已经开源了 MCP 的协议规范，并提供了多种语言的 SDK（比如 Python，现在甚至支持 Java）。通常的入门步骤如下：

运行或安装一个 MCP server，用于连接你关注的工具或数据源。

Anthropic 的开源仓库中已经提供了多个热门系统的预构建 server（如 Google Drive、Slack、Git、数据库等），你只需安装并配置这些 server（一般就是运行一条命令并提供凭证或密钥）即可。

在你的 AI 应用中设置 MCP 客户端。

如果你使用的是 Claude 的应用，可以直接在界面中添加 MCP server。如果你正在开发自己的 Agent，可以通过 MCP SDK 将其连接到 server（提供地址和端口即可）。

一旦你在客户端启用了 MCP 服务，客户端就会自动识别并加载 MCP server 提供的扩展功能，包括新的工具、资源或提示模板。
开始调用并持续迭代。

模型或 Agent 就可以根据需要调用 MCP 提供的操作。你需要监控日志，确保请求能够正确地到达 MCP server 并收到响应。

如果你想快速体验 MCP，Anthropic 推荐你先试试 Claude 桌面端集成（如果你有权限），或者直接运行官方示例 server 并参考他们提供的 quickstart 指南。MCP 社区也非常活跃，目前已有大量 MCP server 的目录在不断扩展。一些热门的 connector 包括 Google 服务（如 Drive、Gmail、Calendar）、Slack（聊天和文件访问）、GitHub/Git（代码仓库）、Postgres 等数据库、网页浏览器或 Puppeteer（网页浏览能力）等。很多 server 已被收录在社区开发的目录网站中，官方 GitHub 上也汇总了大量可用的 connector 实现，方便你直接上手。如果你用的工具暂时没有现成的支持，也可以通过 SDK 自行开发 MCP server，通常只需要对该工具的 API 做一层简单封装，以 MCP 格式暴露相应的功能即可。

感谢 Will Schenk 对 MCP 的使用方式做出的澄清和讲解。他还分享了一个快速上手指南，结合 Tezlab 的特斯拉监控服务，展示了 MCP 实际运行的流程。

www.youtube.com/watch?v=O3AZ0beYHFE

在 MCP 出现之前，AI 系统是如何处理上下文信息和工具调用的？

我们来简单回顾下传统的几种方式，并对比 MCP 的不同之处：

自定义 API 集成（一次性连接器）

最常见的方法是为每个服务单独编写自定义代码或使用特定 SDK。比如，如果你想让 AI Agent 同时访问 Google Drive 和一个 SQL 数据库，就需要分别集成 Google 的 API 和数据库驱动，每一个都要处理独立的认证机制、数据格式和各种兼容问题，开发体验非常繁琐。而 MCP 则像是一把通用“钥匙”（协议），可以解锁很多“门”。更重要的是，只要新增一个 MCP server，客户端无需做任何修改就能使用。

语言模型插件（如 OpenAI Plugins 等）

另一种方法是在 2023 年兴起，即为模型提供标准化插件接口（通常是 OpenAPI 格式），让它可以受控地调用外部 API（比如 ChatGPT 的 Plugins 系统）。虽然从理念上看这和 MCP 有些相似（标准化工具访问方式），但这些插件通常是专有的，而且受限较多 —— 每个插件都要单独开发和托管，只能在特定平台（如 ChatGPT 或 Bing Chat）使用。

而且插件大多是单向信息获取（模型调用 API 返回结果），不支持持续的交互会话。相比之下，MCP 是开源且通用的（任何人都可以实现它，不受限于某个 AI 平台），并支持丰富的双向交互。你可以把 MCP 理解成模型和工具之间的对话，而插件更像是“问一句答一句”的静态问答。

通过框架调用工具（LangChain 工具、Agent）

像 LangChain 这样的 Agent 编排框架，让“给模型配工具”这个思路广为流行。比如你可以定义一个 search() 工具或 calculate() 工具，Agent（通过 LLM）判断何时调用这些工具。这种方式很强大，但每个工具的底层仍需要开发者手动实现。LangChain 虽然提供了 500 多个标准化接口的工具，但开发者仍需要自行连接和配置。MCP 和它是互补的 —— MCP 提供的是“工具实现层”的标准化接口。

你可以把 MCP server 理解为一个“可直接调用的工具库”，任何 Agent 都可以使用。它们的关键差异在于标准化的“入口”：LangChain 面向开发者（Tool 接口类）统一工具接入代码，而 MCP 面向模型本身 —— AI Agent 可以在运行时自主发现和调用 MCP 工具。这意味着就算你没有专门为某个工具写对接逻辑，模型也能即时调用。

事实上，两者正在融合：LangChain 团队在注意到 MCP 热度后，也发布了适配器，使 MCP server 可以被当作 LangChain 工具调用。因此，无论你是在 LangChain 或其他框架中构建的 Agent，都能像使用本地函数一样使用 MCP 工具，同时享受到日益扩展的 MCP 生态。

RAG 与向量数据库（Retrieval-Augmented Generation）

一种流行的方法是通过 RAG 架构为模型提供上下文信息，也就是用 retriever 检索文档知识库（文本或向量），再将检索结果注入 prompt，弥补模型的知识截止问题或记忆局限。但这种方式一般只能提供静态文本片段，模型无法主动发起操作或查询。

MCP 和 RAG 是可以协同工作的，比如你可以通过 MCP server 接入向量数据库或搜索引擎，让模型主动“发请求”去查询，而不是被动等待系统帮它“塞内容”。

可以说，MCP 是一种更通用的机制：RAG 提供的是“被动”上下文，而 MCP 让模型能“主动”获取和操作上下文，借助标准接口触发实际操作。特别是在需要实时、交互式数据的场景下（比如实时查询数据库、发布内容），MCP 的能力远超“只检索文本”的方案。

MCP 是“银弹”式的万能解决方案吗？

MCP 当然不是万能钥匙，它更像是一个非常方便的集成层。但就像所有新兴技术一样，MCP 也带来了它自身的一系列复杂性和挑战，在大规模采用前，开发者和组织都需要认真考虑。例如，其中一个主要问题是管理多个工具 server 所带来的额外负担。

在生产环境中，为了保证服务稳定、安全并具备可扩展性，运行和维护这些本地 server 往往是个棘手的问题。MCP 的最初设计主要面向本地和桌面环境使用，这也引发了人们对其在云架构和多用户场景中适应性的担忧。虽然社区中已有开发者提出让 MCP 更加无状态、支持分布式部署的改进方向，但这仍是一个持续推进中的问题。

另一个问题是工具的可用性。虽然 MCP 扩展了 AI 模型可调用的工具集，但这并不意味着模型就一定能高效使用这些工具。之前的 Agent 框架就已表明，模型在工具选择和调用方面仍然存在困难。MCP 尝试通过提供结构化的工具描述和规范来缓解这个问题，但最终效果仍取决于工具定义的质量以及 AI 对这些描述的理解能力。正如 LangChain 创始人 Harrison Chase 所强调的，社区主导的方式有助于改进工具文档，进而提升可用性，但这方面仍在不断打磨中。

除了落地过程中的问题，MCP 的成熟度也是一个必须考虑的因素。作为一项相对较新的技术，它仍在快速演进，标准尚未完全稳定。这就可能导致版本不兼容的变更，开发者需要频繁更新 server 和 client。虽然 MCP 的核心思想已经相对稳定，但仍建议开发者为版本升级和最佳实践的演进做好准备。

兼容性是另一个潜在限制。目前，MCP 在 Anthropic 生态中（如 Claude）得到了原生支持，但在更广泛的 AI 平台上仍未普及，其他厂商可能尚未原生集成 MCP，这就需要通过适配器或自定义集成来解决。在 MCP 没有被主流平台广泛接受前，其使用范围会受到一定限制。对于某些简单场景来说，MCP 可能显得有些“杀鸡用牛刀” —— 如果模型只需要调用一两个简单 API，直接调用 API 可能比引入 MCP 更高效。而 MCP 的消息机制和 server 配置确实存在一定学习门槛，因此它带来的便利是否值得，还需要和引入的复杂性进行权衡。

安全性和可观测性同样是 MCP 需要解决的问题。由于 MCP 本身是中间层，如何进行身份认证和权限控制，防止未经授权的访问，是系统设计中必须考虑的方面。目前社区中已有像 MCP Guardian 这样的开源项目，试图通过日志记录和策略管控来提升安全性，但在真正的企业级应用中，如何全面保障 MCP 的安全仍是一个持续优化的过程。

总体来看，虽然 MCP 存在一些限制，但这些并不是阻碍使用的“致命问题”。最理想的方式是从一些试验性或非关键场景开始使用，逐步熟悉它的机制和潜力。MCP 的一大优势就是拥有一个活跃的开源社区 —— 因为它是开放的，使用过程中遇到的问题往往可以通过社区协作来快速解决。

MCP 在 Agentic Orchestration 中的角色及其在 Agent 工作流中的位置。

以前我们探讨了构建自主 Agent 的核心模块：身份与上下文（Profiling）、知识（Knowledge）、记忆（Memory）、推理与规划（Reasoning/Planning）、反思（Reflection）和行动（Action）。

一个合格的 Agent 需要观察并理解环境（Profiling/Knowledge），记住过往交互（Memory），规划下一步行动（Reasoning），执行操作（调用工具或生成输出），最后进行反思和学习。那么 MCP 属于哪一部分呢？

MCP 本身并不是一个 “Agent 框架”，它更像是 Agent 系统中的标准化集成层，专注于“行动”模块，特别是如何让 Agent 以统一方式与外部工具或数据进行交互。MCP 提供了连接 AI Agent 和外部世界的数据通道，既规范又安全。没有 MCP（或类似机制）的话，每当 Agent 需要与外部交互 —— 比如获取文件、查询数据库、调用 API —— 开发者都需要编写定制集成代码或使用零散的方案。这就像是你在造一个机器人，但每根手指都要手工打造来抓不同物体 —— 工作量巨大且不可扩展。

需要特别强调的是，MCP 并不是 Agent 的编排引擎或大脑，而是 Agent 架构中的集成层。它是对 LangChain、LangGraph、CrewAI、LlamaIndex 等编排框架的补充，为 Agent 提供一个统一的“工具箱”接口，让其能够标准化调用外部工具。MCP 并不取代“何时使用工具、为什么使用工具”的决策逻辑 —— 这部分依旧是编排引擎的职责，而 MCP 负责定义“如何调用工具”以及“如何传递信息”。

你可以将 MCP 理解为 Agent 的 API 网关，通过统一协议连接各类 client（Agent）与 server（工具），将集成难度从“ N×M 问题”降维为 “N+M 问题”，实现 client 和 server 的通用兼容。最终，MCP 简化了外部功能的集成方式，让 Agent 更具多样性、适应性和跨场景任务能力。

MCP 解锁的新可能性

MCP 仍然是一项新技术，它的全部潜力还在不断被探索中。第一波应用场景已经比较明显 —— 比如把企业数据接入聊天助手，或者让代码 Agent 能访问代码仓库。但一些正在出现的新应用，可能会真正把 AI Agent 推向新的高度。

多步骤、跨系统的工作流。在现实中，Agent 系统常常需要跨平台协作。 比如一个 AI 需要帮你规划活动：它要查看你的日历、预订场地、发送邀请邮件、安排交通、更新预算表。现在，要实现这些流程，通常需要手动拼接多个 API 接口。而通过 MCP，所有这些操作都可以通过一个统一接口完成。Agent 只需要调用一系列 MCP 工具（每个任务对应一个工具），整个过程中上下文保持一致 —— 不会断链、不需要每个工具都做定制集成。
具备环境感知能力的 Agent（包括机器人）。除了调用工具，MCP 还可以赋能那些嵌入在智能环境中的 AI Agent —— 无论是智能家居，还是操作系统。AI 助理可以通过标准化的 MCP server 与传感器、IoT 设备或系统功能交互。AI 不再是孤立运行的程序，而是能够实时感知环境，从而提供更自然、更主动的帮助。
多 Agent 协作（Agent 社会）。这个方向特别令人期待 —— MCP 还可以作为多 Agent 系统的共享工作空间。不同专长的 AI Agent —— 有的负责调研、有的负责规划、有的负责执行 —— 可以通过 MCP 动态交换信息、协同完成任务。每个 Agent 不需要集成所有工具，它们只需访问一个共享的工具集即可。
深度集成的个人 AI 助理。MCP 也可以让用户自行配置 AI 安全访问个人数据和应用。比如，本地部署一个 MCP server，可以让 AI 访问用户的邮件、笔记、智能设备，同时又不用把敏感数据暴露给第三方服务。这就有可能打造一个“超个性化”的 AI 助理，而不依赖云端平台。
企业级治理与安全控制。对企业而言，MCP 提供了标准化的 AI 接入方式，大幅减少集成成本。同时，它也带来了治理能力：所有 AI 的交互都可以被记录、监控和审查，从而防止出现意料之外的操作，同时保障系统效率。

以上只是 MCP 潜力的冰山一角。通过让 AI 能够进行流畅、具备上下文感知能力的多步骤交互，MCP 正在推动 Agent 向真正的自主工作流执行迈进。