MCP 是什么？为何而生？ - 代码学习笔记

一、MCP 是什么？为何而生？

MCP（Model Context Protocol，模型上下文协议） 是一个开放协议，旨在标准化应用程序如何向大型语言模型（LLM）提供上下文。你可以把它想象成 LLM 世界的“USB-C 接口”：它定义了一套标准规范，让任何应用（宿主，Host）都能以统一的方式，为任何 LLM 接入外部数据、工具和能力。

在当前的 AI 开发中，将 LLM 与数据库、文件系统或第三方 API 集成往往是“一案一议”的定制开发，代码难以复用。MCP 的出现，就是为了解决这个“集成孤岛”问题，构建一个开放、可扩展的生态系统。

二、核心思想：资源、工具与提示

MCP 协议围绕三个核心抽象构建，它们共同构成了 LLM 与外部世界交互的桥梁：

Resource（资源）：代表可以被 LLM 读取的上下文数据。例如，一个文件的内容、一条数据库记录、一次 API 调用返回的结果。资源通过 URI 标识（如 file:///path/to/doc.md 或 db://users/123），其内容可以是文本或二进制数据。
Tool（工具）：代表 LLM 可以调用的可执行操作。工具可以执行代码、调用 API、进行计算等。它与“资源”的关键区别在于，工具会产生副作用或进行主动推理，例如“发送邮件”或“查询当前天气”。
Prompt（提示）：代表一组可复用的、结构化的对话或交互模板。提示由服务器定义，客户端可以调用它们来引导特定的对话流程，例如“代码审查助手”或“故事生成器”。

关键洞察：Resource 是被动的数据供给，Tool 是主动的“动手操作”，Prompt 是预设的“对话剧本”。三者分离的设计，使得 LLM 的上下文能力变得模块化和可组合。

三、协议架构：客户端-服务器模型

MCP 采用经典的客户端-服务器架构。理解两个核心角色是关键：

MCP 客户端（Client）：通常是宿主应用的一部分，负责与一个或多个 MCP 服务器建立连接，并代表 LLM 发起请求（如列出资源、调用工具）。它充当了 LLM 与服务器之间的“翻译官”和“调度员”。
MCP 服务器（Server）：是一个轻量级程序，通过标准协议暴露特定的资源、工具和提示。例如，一个“本地文件系统服务器”可以提供文件的读写能力；一个“GitHub 服务器”可以提供代码仓库的访问和操作能力。

它们之间的通信基于 JSON-RPC 2.0 协议，传输层可以灵活选择，如 stdio（标准输入输出，适合本地进程）或 SSE (Server-Sent Events) / HTTP（适合远程服务）。

四、一个简单的 MCP 交互示例（Python）

下面是一个简化的 Python 代码片段，模拟了 MCP 客户端如何连接到一个提供“天气查询工具”的服务器，并执行一次调用。这展示了协议在应用层的使用模式。

# 假设的MCP客户端API（例如来自 `mcp` Python SDK）
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

# 定义要连接的MCP服务器（这里是一个本地天气服务）
server_params = StdioServerParameters(
    command="python",
    args=["weather_mcp_server.py"], # 这是一个实现了MCP协议的服务端脚本
)

# 1. 建立连接
async with stdio_client(server_params) as (read, write):
    async with ClientSession(read, write) as session:
        # 2. 初始化协议版本
        await session.initialize()

        # 3. 发现服务器提供的工具
        tools = await session.list_tools()
        print("可用的工具:", [t.name for t in tools.tools])
        # 输出示例: 可用的工具: [‘get_current_weather‘, ‘get_forecast‘]

        # 4. 代表LLM调用某个工具
        # 假设LLM决定需要查询北京天气，并生成了如下参数
        tool_name = "get_current_weather"
        arguments = {"location": "Beijing", "unit": "celsius"}

        # 5. 客户端执行调用
        result = await session.call_tool(tool_name, arguments=arguments)
        print("工具执行结果:", result.content[0].text)
        # 输出示例: 工具执行结果: {"location": "Beijing", "temperature": 22, "condition": "Sunny"}

五、应用场景与生态想象

MCP 的价值在于其普适性和互操作性。一旦生态建立，任何 MCP 客户端都能无缝使用任何 MCP 服务器提供的能力，无需为每个组合编写定制代码。这催生了丰富的应用场景：

智能 IDE：一个支持 MCP 的 IDE（如 Cursor）可以同时接入“文件系统服务器”、“Git 服务器”、“Jira 服务器”，让 LLM 助手在编码时能自由地读写文件、查看提交历史、管理任务。
企业知识助手：通过接入“内部 Wiki 服务器”、“数据库查询服务器”、“客服工单服务器”，LLM 能成为一个基于全面、实时企业数据进行回答的超级助理。
个人 Agent 框架：开发者可以像组装积木一样，为自己的 AI Agent 添加各类 MCP 服务器（邮件、日历、笔记、智能家居），快速构建功能强大的个人助手。

展望：MCP 有潜力成为连接 LLM 与数字世界的“标准总线”。未来，我们或许能看到一个应用商店般的 MCP Server Registry，开发者可以轻松发现和集成所需能力。

六、挑战与当前局限

尽管前景广阔，MCP 在当前阶段也面临一些挑战：

安全性：这是最大的挑战。开放工具调用意味着 LLM 可能执行任意代码或访问敏感数据。协议需要健全的权限控制、认证和沙箱机制来保障安全。
性能与延迟：每一步工具调用都是一次网络或进程间通信。对于需要多步推理的复杂任务，累积的延迟可能会影响用户体验。需要优化协议效率或支持并行调用。
模型适配：目前的主流 LLM 并非为原生调用结构化工具而设计。需要更强大的模型或更精巧的 Prompt 工程，让 LLM 真正“理解”并有效利用这些标准化的上下文和工具。

七、总结：迈向可组合的 AI 未来

MCP 协议不仅仅是一个技术规范，它更是一种系统设计哲学的体现：通过定义清晰的边界和标准接口，将复杂的 LLM 集成问题解耦为独立、可复用的组件。它降低了开发门槛，促进了生态的繁荣。

作为开发者，我们可以将其视为构建下一代 AI 原生应用的重要工具。现在就可以尝试：

使用官方 SDK（如 Python/TypeScript）编写一个简单的 MCP Server，将你熟悉的 API（如天气、翻译）封装起来。
在支持 MCP 的客户端（如 Claude Desktop App）中体验调用过程。
思考如何将你的现有服务或数据源以 MCP Server 的形式暴露出来，为更广泛的 AI 应用赋能。

MCP 的旅程才刚刚开始，但它为我们描绘了一个 LLM 能力即插即用、无限扩展的激动人心的未来。