什么是模型上下文协议 (MCP)？

您是否曾经尝试过建立多智能体系统 ，但却难以在每个专业智能体之间有效传播信息？提供给 AI 智能体的各种预建和自定义工具是否会导致工具执行或输出错误？或许，这些技术难题是否已让您彻底放弃了自主开发智能体的打算？

这些障碍可以通过模型上下文协议（MCP）来解决。MCP 允许 AI 智能体感知上下文， 同时遵守工具集成的标准化协议。

AI 智能体是指能够代表用户或其他系统自主执行任务的系统或程序。它通过设计工作流并利用可用工具来实现这些功能。多智能体系统由多个 AI 智能体组成，它们共同工作，代表用户或其他系统执行任务。

您可以将 MCP 在 AI 应用程序中的作用类比为 USB-C 接口在硬件设备中的作用。¹这一类比强调了 USB-C 端口为连接硬件提供的适应性，并将其与各种工具和数据源通过 MCP 为 AI 模型提供上下文的标准化方式进行了比较。

Granite、Gemini 和 Llama 等大语言模型 （LLM） 在部署时功能有限。在没有 AI 工具辅助的情况下，LLM 已在多个领域展现出核心能力，包括：

• 后续文本预测：提示 LLM 完成句子“Jack and Jill went up the...”时，系统会正确预测为“Jack and Jill went up the hill.”此提示和响应是后续文本预测的一个示例，在模型经过训练的文本上效果最佳。
• 基本问题解答： 由于 LLM 本身无法访问外部数据库或网络搜索，因此它可以回答与用于培训模型的数据信息相关的自然语言问题。例如，“告诉我凡尔赛条约”就是示例之一，因为通用模型的训练数据中很有可能包含有关主要世界大战的信息。LLM 通常以聊天机器人的形式进行文本生成。
• 情绪分析：LLM 可以处理文本并确定其表达的是积极、负面还是中立的情绪。
• 语言翻译：LLM 能够实现跨语言和地域的文本翻译。然而，并不是每个 LLM 都能在一种以上语言的数据上进行训练。

除基础功能外，未接入外部工具的 LLM 无法成功执行任何需要实时信息支持的用户查询。为了使 LLM 能够生成更有意义的结果，可以引入工具整合。提供外部工具，如网络搜索、数据集和 API，使 LLM 的能力扩展到训练数据之外。

为了更进一步，我们可以使用 LLM 及其可用工具构建 AI 智能体。总而言之，智能体系统为 LLM 提供了一套工具，使模型能够确定适当的工具使用方法，适应不断变化的环境，并根据工具输出形成综合结论。但要大规模应用，这些 AI 系统往往会失败。因此，Anthropic 于 2024 年推出的 MCP 为 AI 工具交互建立了开放标准。 ²

将外部服务连接到 LLM 非常麻烦。想象一下将电动机连接到各种电源的电路。MCP 就像这条电路的布线和配电盘，它决定流经电机的电流（信息）（AI 模型）。工具输出或模型上下文可类比为输入电流——它如同电源输出的电压，可包含记忆存储、工具调用及历史分析结果。

作为配电盘，MCP 决定连接哪些电源（工具输出或上下文）以及何时连接，调节电流（信息流），过滤输入并确定优先级。这样做是为了确保只有相关电线通电（加载相关上下文），管理电路的时序和布线，以免系统过载。

正如精心设计的电路可以防止过载并确保高效用电一样，MCP 可以作为一个连接器， 促进高效、相关和结构化地使用上下文，从而实现最佳 AI 模型性能。

MCP 为 AI 工程师制定了新的开源标准。然而，标准在软件行业并不是一个新概念。 例如， REST API 是行业标准，它通过符合 REST 设计原则的 HTTP 请求在应用程序之间提供一致的数据交换。

同样，MCP 通过设定标准统一 LLM 和外部服务，以进行高效通信。该标准允许“即插即用”工具的使用，而无需为每个工具的自定义整合编写代码。

MCP 不是智能体框架，而是智能体访问工具的标准化整合层。它是智能体编排框架的补充。 MCP 可以补充智能体编排框架，如 LangChain、LangGraph、BeeAI、LlamaIndex 和 crewAI，但并不能取代它们；MCP 不会决定何时调用工具以及调用的目的。

MCP 只是提供标准化的连接来简化工具整合³最终，LLM 根据用户请求的上下文确定调用哪些工具。

MCP 客户端/服务器模型可分解为三个关键架构组件：

AI 应用程序接收用户请求并通过 MCP 寻求访问上下文。该整合层可以包括 Cursor 或 Claude Desktop 等 IDE。它包含编排逻辑，并能将每个客户端连接到服务器。它包含编排逻辑，并可以将每个客户端连接到服务器。 ⁴

MCP 生态系统中主机和服务器之间的通信必须通过客户端。此客户端存在于主机中，并将用户请求转换为开放协议可以处理的结构化格式。一台 MCP 主机可以存在多个客户端，但每个客户端都与 MCP 服务器建立 1:1 关系。

MCP 客户端的示例包括 IBM BeeAI、Microsoft Copilot Studio、Claude.ai、Windsurf Editor 和 Postman。客户端充当会话管理器，负责处理中断、超时、重新连接和会话关闭。客户端还会解析响应、 处理错误，并验证响应是否与上下文相关和合适。⁴

通过将用户请求转换为服务器操作，为 LLM 提供上下文的外部服务。MCP 服务器整合的示例包括 Slack、GitHub、Git、Docker 或网络搜索。这些服务器通常为 GitHub 代码库，支持多种编程语言（如 C#、Java、TypeScript、Python 等），并提供 MCP 工具的调用接口。

通常情况下，这些 GitHub 代码库中会提供技术教程，以帮助实现技术集成。MCP 服务器还可通过 IBM、OpenAI 等 AI 平台提供商，将 LLM 推理能力接入 MCP SDK 开发框架。这样就创建了一个可重复使用的 MCP 服务，供客户作为“标准化”聊天工具访问。

MCP 服务器用途广泛，因为它们允许连接内外部资源和工具。根据 Anthropic 提供的文档，模型上下文协议服务器通过以下方式公开数据：

• 资源 ：从内部或外部数据库检索信息。资源返回数据，但不执行可操作的计算。⁵
• 工具：与工具间的信息交换可产生副作用，例如执行计算或通过 API 请求获取数据等操作。⁶
• 提示：用于 LLM 与服务器通信的可重复使用的模板和工作流。⁷

客户端和服务器之间的传输层负责双向消息转换。在客户端到服务器的流中，MCP 协议消息被转换为 JSON-RPC 格式，从而允许传输多个数据结构及其处理规则。⁸

在服务器到客户端的反向流中，接收到的 JSON-RPC 格式报文会转换回 MCP 协议报文。⁹三种 JSON-RPC 消息类型包括请求、响应和通知。请求需要服务器响应，而通知则不需要。

在客户端和服务器之间的传输层，MCP 协议主要有两种传输方法，这两种方法都以 JSON-RPC 2.0 格式传输消息。第一种是标准输入/输出 (stdio)，由于输入/输出信息传输简单，它最适合整合本地资源。此格式用于轻量级、同步消息传递。⁴此类资源包括本地文件系统、数据库和本地 API。

第二种是服务器发送事件 (SSE)，最适合集成远程资源。HTTP POST 请求用作从客户端传输到服务器消息的机制，而 SSE 则用于反向传输。这种格式可用于同时处理多个异步、事件驱动的服务器调用。⁴

想象一下，现实世界中的 AI 会扫描您的收件箱，安排客户会议，发送股票更新信息，并通过短信总结过去一小时的 Slack 活动。每个服务提供商的 API 构建方式都不同，要求传递不同的信息，返回不同的输出模式。因此，这些工具的轻微变化都可能导致整个 AI 工作流的崩溃。

工程师还需要承担很大的开发负担，需要手动构建这些工具连接、调试和维护 API 密钥和工具权限等身份验证。工具通常依赖于其他工具的输出，而在许多边缘情况下，这些连接都会失效。

因此，作为 LLM 和开发工具之间的中间层，提供 MCP 集成至关重要。在这一层中，MCP 可以将工具输出转换成模型可以理解的方式。无需在 CLI 之间切换，工具整合都可以一体化。

MCP 在实际应用中有着广泛的用例。 例如，MCP 通过使用通用工具的共享工作区增强了 多智能体编排和通信，从而消除了直接集成的需求。³

MCP 还可以用来补充检索增强生成 (RAG) 。MCP 可以通过服务器操作连接到矢量数据库，而不是提供检索器来搜索矢量存储或知识库。将数据库作为工具进行搜索，而不是在每次 LLM 调用中传递检索器，可以更有策略地使用该工具。这种方法还允许在数据检索时进一步调用工具。³

MCP代表了一种持续演进的 LLM 工具集成方案，其技术体系正不断成熟并重塑行业格局。 随着技术挑战的出现和 MCP 服务器的发展，标准会不断调整，MCP 也继续改进。

无论如何，标准化工具集成对于 AI 智能体自主运行并动态适应真实世界环境至关重要。¹⁰借助 MCP，我们可以简化复杂智能体式工作流的自动化，从而减少人工监督。 由此，MCP 推动的这一转变，使我们能够将时间投入到更需要人类智慧与直觉的精细化任务中。