最初，大模型的应用主要通过像ChatGPT这样的聊天机器人展现其智能理解能力。随着技术的进步，基于大模型的智能代理（AI Agent）成为突破大模型能力边界的重要方向。这些智能代理能够执行一系列任务、解决问题，并进行决策，具备深刻理解用户需求和自主规划解决方案的能力，并能够根据规划结果，选择和使用各种工具来完成任务。然而，AI Agent系统面临的关键挑战是如何高效地将外部工具、知识、资源等迅速接入大模型，并实现有效利用。尤其是，如何将现有的工具和资源整合进大模型，提升其生产力能力，是一个亟待解决的问题。为应对这一挑战，Anthropic发布了全新的大模型上下文连接协议MCP（Model Context Protocol），该协议能够帮助大模型系统快速接入多种外部资源和工具，从而为用户提供更强大的服务能力。本文将介绍MCP协议的核心内容，并探讨它如何推动AI Agent的发展和应用。

• 大模型上下文协议（MCP）简介

• 大模型上下文协议（MCP）的技术实现

• MCP核心是暴露资源

• MCP支持Prompt模板的流转

• 1、标准化与一致性

• 2、资源控制和上下文管理

• 3、可维护性和扩展性

• 4、安全与权限控制

• 5、更强的灵活性

• 为什么是服务端定义Prompt，客户端选择使用？

• MCP支持工具的暴露

• 与资源（Resources）的区别

• 大模型上下文协议（MCP）的优点是什么？解决了什么问题？

• 大模型上下文协议（MCP）不仅是一个标准，更是一个生态系统

大模型上下文协议（MCP）简介

大模型上下文协议的英文全称是Model Context Protocol，缩写为MCP，这是由Anthropic（对，就是那个Claude模型背后的企业，这个企业的介绍参考：https://www.datalearner.com/ai-organizations/anthropic ）发布的大模型连接资源的协议，一个开放的连接标准，旨在简化AI工具与数据资源的对接方式，助力构建真正的上下文感知型AI系统。

在常规的大模型应用系统中，如果我们希望以大模型为核心控制器来规划任务并解决执行，需要将不同的资源和数据通过一种方式注入给模型。在没有MCP的情况下，系统的构建和开发过程通常会涉及到大量的定制化工作，因为每个数据源、工具或资源都需要独立的集成方式。

例如，假设我们创建一个大模型电脑助手，一旦我们新增一个软件给大模型使用，或者新创建一个文档给大模型使用，我们需要在大模型电脑助手中新增这部分软件的描述信息、使用方式，或者是数据信息以及访问方式。甚至还需要考虑任务编排以及独立集成方式（如引入特定的库，创建访问连接查询数据等）。

Anthropic提出的MCP是专为AI系统设计，旨在简化AI助手（如Claude）与多种数据源（本地或远程）的连接与交互，支持安全、高效的上下文数据访问。主要用于连接AI工具与复杂的数据环境，解决传统系统中的数据孤岛问题，帮助AI更好地利用上下文完成任务。

大模型上下文协议（MCP）的技术实现

MCP（Model Context Protocol）是一种让AI和各种工具、数据源之间更容易互相沟通的协议。可以把它想象成一个“通用接口”，通过它，AI系统可以方便地调用各种不同的服务，就像电脑通过USB接口连接各种配件一样。也就是说，MCP的实现很像让大模型系统开放一个USB接口，那么，任意有USB口的配件都可以被大模型使用。大模型系统的USB接口就是MCP的客户端，外部工具的USB接口就是MCP服务端。

MCP工作原理很简单：它基于客户端和服务器的模式。客户端就是需要请求服务的地方（比如AI助手），而服务器就是提供服务的地方（比如数据库、文件存储、分析工具等）。客户端和服务器通过MCP协议互相“对话”，客户端发出请求，服务器给出回应。

一个简单的流程是这样的：

1. 服务端（例如微信）通过通知消息，告诉客户端我有什么样的资源和工具（例如，历史消息统计，针对特定用户的历史消息搜索等）；

2. 客户端（AI助手）收到这个通知消息后，可以把这些资源和工具注册到自己的上下文环境中；

3. 客户端（AI助手）收到用户的请求（如我们问助手，查一下微信里面上个月我给XX发的关于YY的信息），那么助手认为这个任务可以通过微信提供的接口来完成，它就可以调用这个工具来实现这个能力；

通过这种方式，AI助手能够很方便地调用这些不同的服务，而不需要关心它们是怎么实现的。每个服务都是独立的模块，它们只需通过MCP协议暴露给AI助手，AI助手通过统一的方式去访问它们。

理论上，所有的内容都可以暴露给大模型。在当前MCP的官方文档中，官方给出了几个类型。

MCP核心是暴露资源

资源是Model Context Protocol（MCP）中的一个核心概念，允许服务器暴露数据和内容，客户端可以读取这些数据，并将其作为上下文用于大型语言模型（LLM）的交互。在MCP中，资源指的是任何可以被客户端（例如AI助手）访问的数据或内容。这些资源可以是数据库中的数据、文件系统中的文件，或者其他任何有用的信息。这个概念可以从如下几个角度理解：

• 资源（Resources）：在MCP中，资源指的是任何可以被客户端（例如AI助手）访问的数据或内容。这些资源可以是数据库中的数据、文件系统中的文件，或者其他任何有用的信息。

• 服务器暴露资源：这意味着服务器通过MCP协议把这些数据或内容开放出来，使得其他系统（客户端）可以访问。例如，一个数据库服务器可以暴露它的表格数据作为资源，AI助手可以通过MCP读取这些数据。

• 客户端读取资源：客户端（如AI助手）通过MCP协议读取服务器提供的资源。客户端可以使用这些资源来执行任务或生成响应。

• 作为上下文用于LLM交互：LLM（大型语言模型）通常需要上下文来理解并生成合理的回答。MCP允许服务器提供的资源（如数据库查询结果、文档内容等）作为上下文，帮助LLM更好地理解当前任务并生成更准确的回答。

MCP支持Prompt模板的流转

在MCP中，Prompt（提示）是一种预定义的模板，可以帮助服务器和客户端之间的交互变得更规范和高效。简单来说，Prompt是“任务模板”或者“工作流程模板”，它们定义了一种标准的方式，用于引导AI系统（LLM）如何与用户或其他系统进行交互。

这些模板可以用来执行某些常见的任务，比如询问问题、提供建议、执行查询等。它们不仅帮助标准化交互，还可以通过动态参数和上下文来定制每次的交互。在MCP的标准中，通常是服务端定义这些Prompt模板后，客户端（如AI助手）可以很容易地展示它们给用户，或者直接传递给大型语言模型（LLM）进行处理。

为什么是服务端定义Prompt，客户端选择使用？

服务端除了暴露资源外，也可以暴露prompt给客户端使用，这样做好处很多。这里我们列举如下：

1、标准化与一致性

服务端定义的Prompt可以确保在多个客户端之间使用统一的交互方式，这有助于在不同的系统、应用或AI助手之间保持一致性。
服务端可以预设一些标准化的任务模板，确保每个客户端执行任务时遵循相同的流程和规范。比如，生成财务报告的Prompt模板可能在不同的AI助手中表现一致，避免了客户端的重复工作和不必要的复杂性。

2、资源控制和上下文管理

服务端不仅定义Prompt，还能管理上下文和与之相关的资源。通过MCP，服务端可以确保Prompt与所需的数据、计算工具等资源整合在一起。例如，服务端可以将数据库查询、数据分析工具和报告生成模板打包成一个完整的Prompt，客户端只需要选择并执行这个任务。

服务端的角色是控制和管理资源的访问，比如获取实时数据、使用正确的API等，这样可以减少客户端开发的复杂度。

3、可维护性和扩展性

服务端集中管理Prompt使得整个系统更易于维护和扩展。假设有多个AI客户端，它们可能都需要执行“生成报告”的任务。如果每个客户端都单独定义自己的Prompt，那将会导致多个版本的报告生成模板，更新和维护变得非常困难。相反，如果所有客户端都通过MCP选择和使用服务器定义的统一Prompt，当需要修改或扩展功能时，只需要在服务端更新Prompt，而客户端无需做任何修改。

例如，服务器可以对“生成财务报告”的Prompt进行更新（比如调整报告格式或增加数据字段），所有连接到该服务器的客户端都可以自动使用更新后的Prompt。

4、安全与权限控制

服务端可以通过MCP来控制哪些Prompt可以被客户端使用，确保只有授权的用户或系统可以访问特定的功能。比如，某个敏感的数据处理任务可能只允许特定用户调用服务器定义的Prompt，而客户端不能随意定义或调用这些任务。
通过服务器集中管理Prompt，开发者可以对客户端的操作进行更严格的控制和监督，避免可能的滥用或不当操作。

5、更强的灵活性

服务器端定义Prompt，意味着可以动态地为客户端提供不同的任务模板，而客户端只需要选择并执行。客户端不需要编写复杂的代码来实现这些模板，也不用自己维护这些模板的版本控制。它们可以专注于如何使用这些标准化模板来完成任务，而不需要关心这些任务背后的实现细节。
例如，服务器可以根据用户的输入动态提供不同的Prompt，确保用户始终能够选择最适合当前任务的模板。

举个例子，假设我们有一个AI助手，用来生成财务报告，下面展示了服务器和客户端之间如何通过MCP进行交互。

服务端定义Prompt：在服务器端，我们定义了多个财务报告生成的模板，每个模板对应不同类型的报告（例如季度报告、年度报告、预算报告等）。

这些Prompt模板已经定义了如何从财务数据库获取数据、如何生成报告内容以及如何格式化输出。服务器还可以为每个报告定义上下文，比如使用当前日期、特定的财务数据等。

客户端选择Prompt：AI助手（客户端）会向服务器请求“财务报告”相关的Prompt模板。假设用户想要生成一个季度报告，AI助手会通过MCP请求服务器暴露的季度报告生成Prompt，并将需要的参数（如日期范围）传递给服务器。

客户端并不需要自己定义如何生成报告，它只需要调用服务器提供的Prompt模板，省去了开发和维护工作。

任务执行：服务器接收到客户端的请求后，使用预定义的Prompt模板来执行任务，获取所需的财务数据，生成报告，并将结果返回给客户端。客户端可以将报告显示给用户或执行其他操作。

MCP支持工具的暴露

在MCP中，Tools（工具）是指那些允许服务器暴露可执行功能，让AI模型（LLM）通过客户端来调用并执行的功能。简单来说，工具是可以执行某些“实际操作”的功能，它们不仅仅是提供数据或内容（像资源一样），而是可以改变数据的状态或与外部系统互动（例如调用API、执行计算、修改文件等）。

Tools的作用

执行操作：工具不仅仅提供数据，它们可以执行实际的动作，比如：

1. 计算数学公式（例如计算税率、汇率转换等）

2. 执行API请求（例如获取外部数据、控制外部设备等）

3. 执行复杂的业务逻辑（例如订单处理、数据同步等）

模型控制：工具的设计是由AI模型控制的，也就是说，AI模型可以根据需要自动调用这些工具来完成任务。当然，用户批准是一个重要的安全机制（例如通过提示框确认），保证工具的执行是有权限和安全的。

与资源（Resources）的区别

前面已经说了，MCP的核心是暴露资源，让资源变成大模型的上下文。而这里所说的工具则是与资源不同的一种能力。资源通常是静态的数据或内容，比如数据库中的数据、文件中的内容等。这些资源可以被客户端读取或引用，但它们不会执行任何操作。与资源不同，工具是可执行的功能。它们不仅能提供数据，还能执行操作，例如修改数据库记录、发送请求、执行计算等。工具通常会改变状态或与外部系统进行互动。

大模型上下文协议（MCP）的优点是什么？解决了什么问题？

如前所述，MCP最大的优点是简化了大模型系统与其它资源的集成过程，简化了大模型使用新工具新资源的复杂性。MCP协议的设计目标是抽象化资源和服务，使其以标准化接口形式呈现。通过MCP Server，所有资源或工具（如数据库、文件存储、API服务等）都可以暴露给大模型客户端。这种机制可以被视为服务网络的标准化协议。

为什么MCP这么有用？我们认为主要有以下三点：
简化了开发：开发者不需要为每个服务写独立的代码，只需要用MCP将它们连接起来。比如，想增加一个新的文件查找服务，开发者只需要创建一个MCP服务器暴露该服务，AI助手就可以直接访问。
灵活扩展：当需要新增功能时，开发者只需要提供一个新的MCP服务，AI助手就能无缝地使用这个服务。
提高效率：AI助手通过MCP协议能够自动获取所需的信息并执行任务，避免了繁琐的手动操作。

大模型上下文协议（MCP）不仅是一个标准，更是一个生态系统

MCP是由Anthropic推出的一种大模型上下文协议，它可以大幅提高大模型使用外部资源和工具的效率。MCP的出现为AI与工具的深度集成提供了全新路径。但显然，如果想要实现这套机制需要生态系统的配合。如果MCP生态能够不断扩展，它将显著提升大模型的通用性和实际应用价值，至少可以：

1. 服务多样化：每一个新构建的MCP Server都为大模型赋予新的能力，例如访问特殊领域的数据或执行特定领域的任务。

2. 模块化扩展：企业或开发者只需专注于构建符合MCP协议的服务模块，而无需关注如何适配特定大模型。

3. 全球共享的服务网络：当越来越多的组织和开发者贡献MCP Server时，它们实际上构建了一个分布式的服务网络，大模型客户端可以动态访问这些服务。

目前，Anthropic自己的客户端都已经实现了MCP的客户端能力，也提供了很多预构建的MCP服务器（如Google Drive、Git、Postgres等），并允许开发者扩展协议支持新的资源类型。MCP的出现，将大模型从“单一回答者”转变为“任务执行者”，而这些任务执行能力的核心驱动力是MCP Server提供的服务和资源。随着服务生态的丰富，大模型不仅能够理解复杂问题，还可以基于MCP协议调用资源和工具，主动解决问题，形成高效的任务闭环。

如果未来Google、OpenAI等加入，这个生态将会有极高的价值。