MCP 模型上下文协议生产实战

摘要：MCP（Model Context Protocol，模型上下文协议）由 Anthropic 于 2024-11-25 开源，目标是解决「M×N 集成爆炸」——即 M 个模型与 N 个工具各自硬编码对接。它用一套基于 JSON-RPC 的客户端/服务器协议，把「工具/数据」与「AI 应用」解耦。本文讲清 MCP 架构、五大原语、Python Server 实战与传输/安全选型。

核心概念：USB-C for AI

MCP 被官方比喻为「AI 领域的 USB-C」：一次实现，处处可用。在 MCP 之前，每个 AI 应用要对接 Google Drive、Slack、GitHub 都要写定制代码；MCP 之后，工具方只需实现一个 MCP Server，任何实现了 MCP Client 的 AI 应用即可即插即用。

协议基于 Language Server Protocol (LSP) 的设计思路，采用 客户端—服务器 架构，通信使用 JSON-RPC 2.0 消息。关键原语（primitives）分两侧：

侧	原语	作用
Server	Tools	可执行函数，模型可调用以取数或执行动作
Server	Resources	可纳入 prompt 上下文的结构化数据（如文件、DB 行）
Server	Prompts	指令/模板，用于表达不同「意图」
Client	Roots	客户端侧文件系统的入口，授权 Server 访问
Client	Sampling	Server 反向请求客户端 LLM 补全（需人工确认）

为什么 MCP 不只是「又一种工具调用」

MCP 把 Tools / Resources / Prompts 拆成不同概念，表达「可执行动作」「上下文数据」「指令模板」三种不同意图，而不是全压成 tool use。这让权限、上下文管理、审计可以分而治之。详见 function-calling.md 对比。

架构与原理

建立连接的典型流程：Client 与 Server 先 能力协商（Capability Negotiation） 确定双方支持的协议版本与原语，之后 Client 可 list_tools / call_tool / read_resource 等。Anthropic 官方提供了 Python、TypeScript、Java 等 SDK。

生产实践：快速搭建一个 MCP Server

下面用官方 Python SDK 暴露一个天气 Tool。安装后实现一个 @mcp.tool。

bash

pip install "mcp[cli]"  # [版本相关] 包名/版本以 PyPI 为准

python

# weather_server.py —— 最小 MCP Server（示意 [未实测]，请按官方 SDK 调整装饰器签名）
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_weather(location: str) -> str:
    """获取指定城市天气。location 为城市名，如 'Beijing'。"""
    # 真实实现调用天气 API；此处占位
    return f"[mock] {location}: 18C, sunny"

if __name__ == "__main__":
    mcp.run(transport="stdio")  # stdio 适合本地; 远程用 streamable-http/sse

客户端（如 Claude Desktop 或任意 MCP Client）配置该 Server 后即可在对话中调用 get_weather。远程生产部署推荐使用 streamable-http 传输而非 stdio。

操作步骤 / 配置

本地 stdio 接入（以可读取配置的 MCP Client 为例）：

json

{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["weather_server.py"],
      "env": { "WEATHER_API_KEY": "..." }
    }
  }
}

bash

# 启动并冒烟测试（具体命令取决于所用 Client/SDK）
mcp dev weather_server.py   # [版本相关] 参考官方 MCP CLI 文档

验证

在 Client 中列出工具，应能看到 get_weather 及其描述。
发起一次需要天气的提问，确认 Client 调用了 Server 并返回 Observation。
检查 Server 日志，确认连接建立与能力协商成功（协议版本、支持原语）。

Sampling 必须人工确认

Client 侧的 Sampling 原语允许 Server 反向请求 LLM 补全，官方明确要求「应始终有人类在环、可拒绝 sampling 请求」。生产上不要默认开启无确认 Sampling，否则 Server 可能驱动模型产生不可控输出。

回滚 / 清理

MCP Server 作为独立进程/服务，回滚即停掉该 Server 并从 Client 配置移除；对 AI 应用无侵入。
远程 Server 下线前，先在 Client 配置中指向旧版本或临时禁用，避免请求失败雪崩。
清理：吊销 Server 使用的下游 API Key，删除本地遗留的配置与日志（可能含用户查询）。

故障排查

连接建立失败：检查传输方式（stdio 需进程可拉起；http 需网络可达与鉴权头）。
工具列不出来：确认 Server 启动时注册了 tool，且 Client 能力协商支持 Tools。
调用超时：远程 Server 默认无超时兜底，Client 侧必须设调用超时与重试退避。
版本不兼容：协议版本随规范演进，Client/Server 需协商共同支持的版本；不要硬编码旧版本。

安全与合规

提示注入：Server 返回的 Resource/Tool 结果可能含注入指令，Client 必须将其视为不可信数据。
越权访问：Roots 授权 Server 访问客户端文件系统，需最小化授权目录；远程 Server 更要做来源校验。
数据泄露：Server 可能把本地数据外发，需对出站做审计；敏感 Server 放内网 + 隧道（MCP tunnel）。
成本失控：Tool 调用次数不受模型侧限制，需在 Server 或网关层做限流、配额与调用审计。

成本 / 性能

MCP 本身不收费，成本来自 Server 背后的下游 API 调用与 LLM token。性能上，每个 Tool 调用是一次网络往返，远程 Server 的延迟会叠加进 Agent 步数。建议：高频工具就近部署（同可用区）、对稳定 Resource 做缓存、在网关层做调用合并与限流。以远程 Server 单次调用 p99 50ms、日 10 万次估算，仅网络开销可忽略，但下游 API 按调用计费需单独核算 [版本相关]。

MCP 模型上下文协议生产实战 ​

核心概念：USB-C for AI ​

架构与原理 ​

生产实践：快速搭建一个 MCP Server ​

操作步骤 / 配置 ​

验证 ​

回滚 / 清理 ​

故障排查 ​

安全与合规 ​

成本 / 性能 ​

参考资料 ​