模型上下文协议(MCP)工作原理

人工智能领域正在快速发展。每周似乎都有新的工具、框架或模型出现，承诺让AI变得更好。但随着开发者构建更多AI应用，一个大问题不断出现：缺乏上下文。

每个工具都独立工作。每个模型都有自己的记忆、自己的数据和自己理解世界的方式。这使得AI系统的不同部分难以相互通信。

这就是模型上下文协议(Model Context Protocol，简称MCP)的用武之地。

它是一种新的标准，规定了AI工具如何共享上下文和通信。它允许大型语言模型和AI代理以结构化的方式连接到外部数据源、应用程序和工具。

MCP就像是帮助AI系统协同工作而不是分开工作的缺失部分。

MCP正在成为现代AI开发中最重要的理念之一。在本文中，您将了解MCP如何连接AI工具和数据源，使现代AI应用更智能、更快速且更易于构建。

断开连接的AI工具的问题

想象一下，您正在使用像GPT这样的大型语言模型构建客户支持聊天机器人。该模型可以生成很好的响应，但它对您的实际客户一无所知。

为了使它有用，您将其连接到CRM，以便它可以查找客户记录。然后将其连接到工单系统以查看未解决的案例。您可能还将其连接到知识库以供参考。

这些集成中的每一个都是单独的任务。您编写自定义API调用、格式化响应、管理身份验证和处理错误。每个新的数据源都意味着更多的粘合代码。LLM自然不知道如何与这些系统交互。

现在想象一下，您有五到十个这样的工具，比如您的AI助手、搜索引擎、摘要工具和一些自动化脚本。每个都以不同的方式存储信息。

它们都不共享上下文。如果一个模型了解了用户的意图，其他模型无法使用它。您最终得到的是智能孤岛，而不是连接的生态系统。

这就是MCP要解决的问题。

什么是模型上下文协议？

模型上下文协议是一个定义AI系统应如何交换上下文的标准。它被引入是为了使模型、工具和环境能够以可预测的方式进行通信。您可以将其视为"AI上下文的API"。

MCP的核心允许三种类型的通信：

模型可以从外部工具或数据源请求上下文
工具可以将更新或新信息发送回模型
两者都可以共享关于它们知道什么以及如何提供帮助的元数据

这听起来很技术性，但结果很简单。它使AI应用更了解其环境。

开发人员可以依赖定义一切如何组合在一起的共享协议，而不是手动连接集成。

从插件到协议

要理解MCP，回顾一下OpenAI之前如何处理这个问题会有所帮助。

当ChatGPT插件推出时，它们允许GPT模型访问外部API，例如预订航班、获取天气更新或搜索网络。每个插件都有自己的模式，描述它可以处理什么数据以及可以执行什么操作。

MCP进一步发展了这个想法。MCP定义了一种任何AI系统都可以使用的通用语言，而不是仅为ChatGPT设计的插件。这就像从私有集成转向开放标准。

如果您曾经使用过API，您可以将MCP视为为AI做了HTTP为Web所做的事情。HTTP允许浏览器和服务器使用共享规则进行通信。MCP允许模型和工具一致地共享上下文。

以下是一个伪代码示例，展示如何构建一个模型上下文协议(MCP)服务器，将SQL数据库作为上下文源暴露给AI模型。

这是概念性伪代码。它捕获流程，而不是特定语法，并假设存在一个MCP兼容的环境，其中LLM可以通过标准接口从外部工具请求数据。

目标是通过MCP服务器暴露您的SQL数据库（例如，客户或订单表），以便AI模型可以查询并上下文理解其内容。例如，您可以说"显示所有待处理的订单"。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55


// MCP SQL上下文服务器伪代码

// 步骤1：初始化服务器和依赖项
MCPServer = new MCPServer(name="SQLContextServer")

Database = connect_to_sql(
    host="localhost",
    user="admin",
    password="password",
    database="ecommerce"
)

// 步骤2：定义可用的上下文模式
// 这些描述了服务器可以提供什么数据
MCPServer.register_context_schema("orders", {
    "order_id": "integer",
    "customer_name": "string",
    "status": "string",
    "amount": "float",
    "created_at": "datetime"
})

// 步骤3：为上下文查询定义请求处理程序
MCPServer.on_context_request("orders", function(queryParams):
    sql_query = build_sql_query(
        table="orders",
        filters=queryParams.filters,
        limit=queryParams.limit or 50
    )
    results = Database.execute(sql_query)
    return MCPResponse(data=results)
)

// 步骤4：定义操作（可选）
// 允许模型执行更新、插入等
MCPServer.register_action("update_order_status", {
    "order_id": "integer",
    "new_status": "string"
}, function(args):
    Database.execute("UPDATE orders SET status = ? WHERE order_id = ?", 
                     [args.new_status, args.order_id])
    return MCPResponse(message="Order updated successfully")
)

// 步骤5：启动MCP服务器并监听模型请求
MCPServer.start(port=8080)
log("MCP SQL Context Server is running on port 8080")

// 模型如何调用此服务器的示例：
//
// Model -> MCPServer:
//   RequestContext("orders", filters={"status": "pending"})
//
// MCPServer -> Model:
//   [{"order_id": 42, "customer_name": "John Doe", "status": "pending", "amount": 199.99}]

工作原理：

模型通过MCP发送请求，要求提供上下文，如状态为"待处理"的订单
服务器将其转换为SQL查询，获取数据，并将其作为结构化上下文返回
模型现在使用此上下文给出准确的答案，自动化工作流程或做出决策（如"向超过5天的待处理订单发送退款邮件"）
可选的MCP操作允许模型执行安全更新，实现双向工作流程（上下文输入，操作输出）

让AI应用更智能

AI的智能不仅来自模型的大小。它还来自模型拥有多少相关上下文。

具有丰富上下文的小型模型可以胜过不了解其环境的大型模型。使用MCP，模型可以在正确的时间访问正确的上下文。

例如，假设客户支持机器人收到一条消息说：

“我还在等待我的退款。”

通常，模型可能会用通用的道歉来回应。但使用MCP，它可以从连接的工具中提取客户的订单历史，检查退款状态，并回复类似：

“您的订单#1423的退款已处理，应在周二前到达您的账户。”

这是可能的，因为MCP允许模型使用结构化调用从外部源请求信息。它不再盲目工作。它使用上下文工作，使响应更相关和准确。

随着更多工具采用MCP，模型将在多个领域（从金融和医疗保健到软件开发和教育）变得具有上下文感知能力。

让AI应用更快（更简单）

AI应用中的速度不仅仅是关于模型生成文本的速度。真正的速度来自系统收集、处理和应用信息的效率。

没有MCP，AI系统浪费时间做重复性工作，如从不同来源获取数据、清理数据并将其转换为兼容格式。

每个新的集成都会增加延迟。开发人员通常构建缓存层、编写适配器或批处理数据，只是为了让事情顺利运行。所有这些都增加了复杂性并减慢了开发速度。

MCP消除了大部分这种开销。因为它为上下文定义了共享结构，模型和工具可以无缝交换数据。由于所有东西都说相同的语言，无需翻译或重新格式化信息。结果是更低的延迟、更快的响应和更清晰的架构。

考虑一个例子：您正在构建一个AI编码助手。没有MCP，您需要手动连接到您的文件系统、Git存储库和IDE，每个都需要不同的集成。

使用MCP，所有三个都可以通过单个共享协议进行通信。助手立即理解您的代码在哪里、哪些文件已更改以及它可以执行什么操作。

这种简单性不仅使开发人员受益，也使用户受益。使用MCP，您的上下文、偏好、最近的工作和开放项目可以随您跨不同的应用程序移动。这就像为AI世界提供了一个便携式记忆层，无论您走到哪里，它都能让每个工具了解您正在做什么。

更大的图景

MCP的兴起指向了我们思考AI系统方式的转变。我们正在从孤立的模型转向连接的生态系统。

在Web的早期，每个站点都是自己的孤岛。然后出现了像HTTP和HTML这样的标准，这使得一切都可以互操作。那时Web才真正爆发。

AI正处于类似点。现在，每家公司都在构建自己的堆栈、自己的集成、提示和记忆系统。但这种方法无法扩展。MCP可能是连接它们所有层的层。

一旦上下文变得可共享和可移植，AI应用就可以以新的方式协作。写作助手可以与您的研究工具对话。设计机器人可以与您的文件系统一起工作。编码助手可以与您的部署管理器协调。

这种共享智能是使AI真正有用的原因。它不再是一个模型做所有事情。它是关于许多专业模型无缝协作。

结论

MCP仍然很新，但其背后的理念是强大的。通过为上下文创建共享协议，它降低了创新的障碍。

开发人员可以专注于他们的AI做什么，而不是如何连接。公司可以构建与其他产品良好配合的产品，而不是将用户锁定在封闭系统中。

从长远来看，这可能导致一个开放的AI生态系统，其中模型、工具和数据源自由交互，就像今天的网站一样。您可以无摩擦地混合和匹配功能。

目标不仅是更智能的AI，而且是更简单的AI。理解周围发生的事情、实时反应并与您已经使用的工具自然协作的AI。

模型上下文协议是迈向那个未来的重要一步。它是智能和上下文之间的桥梁，它将使明天的AI系统更快、更可靠，并且在它们理解世界的方式上更加人性化。