---

开篇回顾

上篇我们搭建了天气查询和数据库查询两个 MCP Server，并成功对接了阿里云百炼 + Qwen 智能体。本篇我们深入一层：MCP 协议底层是怎么通信的？2026 年国内生态发展到什么程度？生产环境怎么落地？面试会问什么？

---

一、MCP 协议怎么工作的

1.1 JSON-RPC 2.0：通信的语言

MCP 所有通信都是标准 JSON-RPC 2.0 格式。一次工具调用的请求长这样：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": {
      "city": "北京"
    }
  }
}

Server 处理后返回：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "晴，25°C，湿度 40%"
      }
    ]
  }
}

就是普通的 JSON，没有任何黑魔法。

1.2 三大核心能力

MCP Server 不只提供工具调用，还有两个重要能力：

能力	方法	用途
Tools	tools/list → tools/call	执行操作（查天气、查数据库）
Resources	resources/list → resources/read	提供数据（文档、配置、知识库）
Prompts	prompts/list → prompts/get	提供提示词模板

Resources 的典型场景：把公司内部文档注册为 Resource，大模型回答用户问题时能自动引用。

Prompts 的典型场景：预设"生成周报"、"代码审查"等模板，User 一键调用。

1.3 一次调用的完整生命周期

用户提问："北京天气怎么样？"
    ↓
Host 将问题 + 工具清单发给大模型
    ↓
大模型判断："需要调用 get_weather 工具，参数 city=北京"
    ↓
Host 通过 MCP Client 发送 tools/call 请求
    ↓
MCP Server 执行 get_weather("北京")，返回 "晴，25°C"
    ↓
Host 将结果交还给大模型
    ↓
大模型组织回复："北京今天晴天，气温 25°C，适合出行。"

整个过程对用户完全透明，体验就像是模型自己知道天气。

---

二、MCP 生态现状（2026）

2.1 国内平台支持

平台	MCP 支持方式	特点
阿里云百炼	原生 MCP 服务广场	预置 50+ 云端服务 + 20+ 本地工具，业界最完整
通义千问	API 层原生支持	Qwen3.7 可直接对接 MCP Server
百度千帆	AppBuilder 集成	低代码方式接入 MCP 工具
扣子（Coze）	插件市场兼容 MCP	扣子插件可导出为 MCP Server

2.2 主流 SDK

语言	SDK	适用场景
Python	mcp	快速原型、AI 应用开发
TypeScript	@modelcontextprotocol/sdk	前端工具、Node.js 服务
Java	Spring AI MCP	企业级后端集成

Java 开发者可以在 Spring Boot 项目中直接引入：

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-mcp</artifactId>
</dependency>

然后用注解定义一个 MCP 工具，Spring AI 自动完成协议适配。

2.3 MCP 服务广场

不需要从零写 Server 的场景：阿里云百炼 MCP 服务广场已预置了 高德地图、天气、快递查询、机票酒店、MySQL、PostgreSQL、飞书、钉钉 等 50+ 常用服务。在广场一键添加，无需部署，直接使用。

---

三、生产环境落地指南

3.1 部署方式选择

方式	启动延迟	运维成本	适用场景
本地 STDIO	即时	无	个人开发、桌面端
云函数（FC）	< 100ms	极低	生产环境推荐
Docker	秒级	中等	需要复杂依赖
K8s Deployment	秒级	较高	企业级高可用

推荐路径：开发用 STDIO，上线用阿里云 FC，零运维、按调用量付费。

3.2 三个最常见的坑

坑一：工具超时

MCP Server 调用外部 API 时可能超时，大模型会一直等。

解决：设置合理的超时时间（建议 10-30 秒），超时后返回友好错误信息，让模型换策略。

@server.call_tool()
async def call_tool(name, arguments):
    try:
        result = await asyncio.wait_for(call_external_api(), timeout=10)
        return result
    except asyncio.TimeoutError:
        return {"content": [{"type": "text",
            "text": "查询超时，请稍后重试"}]}

坑二：模型"幻觉调用"

大模型可能编造不存在的工具名，或传入格式错误的参数。

解决：Server 端做好参数校验 + 返回清晰的错误信息。同时写好工具描述，让模型更容易理解工具的边界。

坑三：敏感信息泄漏

数据库密码、API Key 写在代码里提交到 Git。

解决：所有敏感信息走环境变量或密钥管理服务。

import os
DB_PASSWORD = os.environ["DB_PASSWORD"]  # 绝不硬编码

3.3 提示词技巧

想让大模型更准确地调用你的 MCP 工具，工具描述要写好：

❌ 差：查询天气
✅ 好：根据城市名称查询实时天气，返回温度、天气状况和湿度。
       仅支持中国城市，输入格式如"北京"、"上海浦东"。

描述里写清楚：功能、输入格式、限制条件、返回内容。

---

四、面试高频考点

以下 8 道题是 2026 年面试中出现频率最高的 MCP 相关问题：

Q1：MCP 和 Function Call 的本质区别？

MCP 是协议，Function Call 是功能。MCP 定义了模型与工具之间通信的标准，具有跨模型、跨平台、可复用的特点；Function Call 是单个模型提供的函数调用能力，工具定义与模型绑定。就像 USB 协议 vs 某个设备的专用接口。

Q2：MCP Server 的并发模型怎么设计？

取决于部署场景。STDIO 模式天然单连接，无需考虑并发；HTTP/云函数模式下，每个请求独立，平台自动处理并发。如果自己用 Docker 部署，建议用异步框架（Python asyncio / Node.js），单进程可处理数百并发连接。

Q3：MCP Server 如何保证安全？

三层防护：① 数据库账号只读权限，最小化授权；② Server 层 SQL 白名单，禁止危险操作；③ 敏感信息走环境变量或密钥管理服务，不入代码仓库。

Q4：工具调用失败了，MCP 协议层面怎么处理？

MCP 返回标准 JSON-RPC 错误响应，包含 code 和 message。大模型读取错误信息后，可以尝试换参数重试或向用户说明失败原因。关键是要返回结构化的、模型能理解的错误信息。

Q5：MCP 适合什么场景，不适合什么场景？

适合：需要大模型与外部系统交互的场景——数据库查询、API 调用、文件操作、发送通知。不适合：纯文本对话、需要极高实时性的场景（MCP 多一跳有延迟）、单次调用耗时超过 30 秒的重任务。

Q6：一个 Host 可以接多少个 MCP Server？

理论上无上限。实际取决于 Host 的上下文窗口——注册的 Server 越多，工具清单越长，会挤占模型的 context。建议控制在 5-10 个 Server、总共不超过 30 个工具。

Q7：Resources 和 Tools 什么时候用哪个？

Tools 是"做事情"（查天气、发邮件），Resources 是"给资料"（文档、知识库、配置文件）。用户问"帮我查订单"用 Tool，用户问"公司请假流程是什么"用 Resource。

Q8：如果我想把现有的 REST API 变成 MCP Server，怎么做？

两种方式：① 包装模式——在 MCP Server 的 call_tool() 里调用现有 API，最快速；② 阿里云百炼支持直接从 OpenAPI 规范生成 MCP Server，上传 Swagger/OpenAPI 文件即可。

---

写在最后

MCP 协议解决了一个朴素的问题：大模型再聪明，没有手就干不了活。

它不是什么高深的技术，只是一个标准化的协议。但正是这个标准化，让 AI 应用开发从一个"手工作坊"变成了"工业流水线"——写完一个 MCP Server，所有模型都能用。

2026 年，MCP 已经从早期的概念验证进入了大规模落地阶段。现在学习 MCP，不算早，也绝不算晚，刚好是最合适的时机。

---

系列文章：

• 上篇：MCP 协议实战（上）：什么是 MCP，怎么跑起来
• 下篇：MCP 协议实战（下）：背后的机制与面试指南（本文）