MCP (Model Context Protocol) 与 HTTP API：大模型时代的通信新范式

在数字世界的两端，API 扮演着不可或缺的桥梁角色。我们熟知的 HTTP API 是 Web 互联互通的基石，驱动着无数应用程序的交互。然而，随着大型语言模型（LLMs）的崛起，一种新的通信范式——MCP (Model Context Protocol) 正在崭露头角，它专为解决与大模型交互时的独特挑战而设计。

---

HTTP API：通用、无状态的请求-响应模型

HTTP (Hypertext Transfer Protocol) 作为应用层协议，以其简单、无状态和请求-响应的特性，成为了构建 Web 服务和 API 的事实标准。

1. HTTP API 的核心特点回顾

• 无状态： 服务器不保存客户端的会话信息。每个请求都必须包含完成其操作所需的所有数据。
• 请求/响应模式： 客户端发送请求，服务器返回响应，通信结束后连接通常会关闭（除非使用持久连接）。
• 通用性强： 广泛应用于各种 Web 服务、RESTful API、微服务架构。
• 易于调试： 借助 curl、浏览器开发者工具等，可以直观地查看请求和响应。
• 数据格式灵活： 主要使用 JSON、XML、表单数据等。

2. HTTP API 与大模型的初步交互

在使用 HTTP API 与大模型交互时，典型的做法是：

1. 客户端（您的应用）构建一个包含用户查询和所有必要上下文的 完整请求。
2. 这个请求通过 HTTP 发送到大模型服务。
3. 大模型处理请求，并返回一个包含生成内容的 HTTP 响应。

import requests
import jsonllm_api_endpoint = "https://api.openai.com/v1/chat/completions" # 示例端点
headers = {"Content-Type": "application/json","Authorization": "Bearer YOUR_API_KEY"
}# 每次请求都需要完整传递上下文
context = "用户正在撰写一篇关于人工智能历史的文章。"
user_query = "请总结1950年代人工智能的起源。"payload = {"model": "gpt-4","messages": [{"role": "system", "content": context},{"role": "user", "content": user_query}]
}try:response = requests.post(llm_api_endpoint, headers=headers, json=payload)response.raise_for_status() # Raise an exception for HTTP errors (4xx or 5xx)result = response.json()print("LLM 响应:")print(json.dumps(result['choices'][0]['message']['content'], indent=2, ensure_ascii=False))except requests.exceptions.RequestException as e:print(f"请求LLM API时发生错误: {e}")

3. HTTP API 通信流程 (与大模型交互)

下图展示了典型的 HTTP API 如何与大模型服务进行交互。每次请求都需要携带完整的上下文，这在大模型长对话场景中可能效率低下。

---

MCP (Model Context Protocol)：为大模型上下文而生

MCP (Model Context Protocol) 并非一个标准组织定义的通用协议，而是一个概念性框架或是一类协议的设计理念，旨在优化大模型在多轮对话、持续学习或复杂推理场景中的上下文管理。它的核心目标是：

1. 高效管理长上下文： 避免在每轮交互中重复传输大量上下文。
2. 支持上下文的增量更新： 只传递上下文的变化部分。
3. 促进模型状态感知： 让模型能够“记住”或引用之前的对话或操作。
4. 优化 Token 使用和成本： 减少冗余的 Token 传输和处理。

MCP 通常会引入**会话（Session）或上下文 ID（Context ID）**的概念。

1. MCP 的核心特点（概念性）

• 会话导向/有状态： 在一个会话中，模型可以保留并维护上下文状态。
• 增量式上下文更新： 客户端只需发送与上次交互相比发生变化的上下文，而不是整个历史。
• Token 优化： 减少重复 Token 的传输和模型处理。
• 复杂性更高： 需要客户端和服务器（模型服务）都实现上下文管理逻辑。
• 潜在的定制化协议： 可能不是基于 HTTP 的，或者是在 HTTP 之上构建的、具有特定上下文管理逻辑的协议。

2. MCP 交互流程示例（概念性）

假设存在一个 MCP API，它允许我们建立一个上下文会话。

# 这是一个概念性的示例，展示MCP的理念，并非真实存在的API库
class MCPClient:def __init__(self, llm_endpoint):self.llm_endpoint = llm_endpointself.session_id = Noneself.context_version = 0 # 跟踪上下文版本def start_session(self, initial_context):# 模拟启动会话，发送初始上下文print("MCP: 启动新会话...")response = requests.post(f"{self.llm_endpoint}/sessions/start",json={"initial_context": initial_context}).json()self.session_id = response.get("session_id")self.context_version = 1print(f"MCP: 会话 {self.session_id} 已启动。")return self.session_iddef chat(self, user_query, new_context_delta=None):# 模拟在一个会话中发送用户查询和可选的增量上下文print(f"MCP: 会话 {self.session_id} - 发送查询...")payload = {"session_id": self.session_id,"user_query": user_query,"context_delta": new_context_delta, # 只发送变化的部分"current_context_version": self.context_version}response = requests.post(f"{self.llm_endpoint}/sessions/{self.session_id}/chat",json=payload).json()# 假设模型服务会返回新的上下文版本self.context_version = response.get("new_context_version", self.context_version + 1)return response.get("llm_response")def end_session(self):print(f"MCP: 结束会话 {self.session_id}。")requests.post(f"{self.llm_endpoint}/sessions/{self.session_id}/end")self.session_id = Noneself.context_version = 0# --- 使用示例 ---
if __name__ == "__main__":mcp_client = MCPClient("") # 概念性端点initial_context = "你是一位历史学家，专门研究20世纪早期的科学发展。"session_id = mcp_client.start_session(initial_context)# 第一轮对话：只需发送用户查询，上下文已在服务端维护response1 = mcp_client.chat("请告诉我爱因斯坦相对论的主要观点。")print(f"\n模型响应 1: {response1}")# 第二轮对话：用户增加了新的上下文片段，但不是整个历史new_context_delta = "请特别关注他对量子力学的看法。"response2 = mcp_client.chat("他对量子力学有什么贡献？", new_context_delta=new_context_delta)print(f"\n模型响应 2: {response2}")# 第三轮对话：继续讨论，无需发送任何额外上下文response3 = mcp_client.chat("那么，他的统一场理论的目标是什么？")print(f"\n模型响应 3: {response3}")mcp_client.end_session()

3. MCP 通信流程 (与大模型交互)

下图描绘了 MCP 在概念上的通信流程。客户端首先建立一个会话并发送初始上下文。随后，在会话中，客户端只需发送用户查询和上下文的增量变化，大大减少了重复数据的传输。

---

核心区别对比

---

特性	HTTP API (与 LLM 交互时)	MCP (Model Context Protocol, 概念性)
上下文管理	每次请求都需完整传递所有上下文 Token	会话导向，模型或中间层维护上下文，支持增量更新
通信开销	随上下文长度增加线性增长，可能重复传输大量 Token	初始开销较高，后续轮次仅传输增量或查询，降低 Token 成本
状态	无状态	有状态 (会话状态，上下文状态)
适用场景	单轮问答、短文本生成、模型微调等无需维护长对话历史的场景	多轮对话、复杂推理、长期记忆、Agent 协作等需要维护复杂上下文的场景
实现复杂度	客户端只需构建请求，服务器无上下文存储负担	客户端和服务器都需要实现复杂的上下文管理逻辑，协议设计更复杂
可伸缩性	无状态特性天然利于横向扩展	会话状态管理可能增加横向扩展的复杂度，需要分布式状态存储
调试	简单，每次请求独立可见	更复杂，需要跟踪会话状态和上下文变化
常见形态	RESTful API、JSON RPC over HTTP	可能是基于 WebSocket、gRPC 或其他定制协议，承载上下文管理逻辑

---

总结与展望

HTTP API 凭借其简洁性和通用性，在大模型应用的早期和许多单次查询场景中依然是首选。它易于实现，且与现有 Web 基础设施无缝集成。

然而，随着大模型能力边界的拓展，用户对更连贯、更智能、更接近人类对话体验的需求日益增长。这使得 HTTP API 在处理长上下文和多轮对话时的效率瓶颈逐渐显现：

• 成本问题： 每次发送整个对话历史，会导致 Token 消耗飙升。
• 性能问题： 传输和处理大量重复 Token 增加延迟。
• 模型限制： 达到上下文窗口上限时，模型“失忆”。

MCP (Model Context Protocol) 正是为了解决这些痛点而生的概念。它代表了一种更智能、更高效地管理大模型上下文的通信范式。通过会话管理和增量式更新，MCP 旨在减少不必要的 Token 传输，优化交互效率和成本，并允许大模型在更长时间跨度内保持连贯性。

尽管目前“MCP”还没有一个统一的行业标准，但其核心理念已经渗透到各种大模型框架和云服务的设计中，例如：

• LangChain、LlamaIndex 等框架中的 Memory 模块，就是在应用层面模拟 MCP 的上下文管理。
• 部分 API 服务商 可能会在 HTTP 之上构建自己的长连接或会话管理机制，以优化与模型的交互。

未来，随着大模型应用场景的日益丰富和复杂，我们可以预见，类似 MCP 这样专注于上下文管理和优化的协议或设计模式，将变得越来越重要，成为构建下一代智能应用的关键技术。