AI助手会计早已成为大模型应用开发中的高频热词，但许多开发者仍停留在“会用MCP SDK调接口”的阶段，面对面试官追问“MCP与Function Call有何区别”“MCP底层依赖什么机制”时往往语塞。本文从问题出发，由浅入深拆解模型上下文协议（Model Context Protocol，MCP） 的技术本质、架构设计与实现原理，配合代码示例与面试考点，帮你建立完整知识链路。

一、痛点切入：为什么需要MCP？

在MCP出现之前，想让AI模型调用外部工具，开发者通常会这样做：写一个HTTP请求调用REST API，把返回结果拼接到提示词里传给模型。

 传统方式：手工调用API + 拼接到提示词

import requests

def get_weather(city):
    resp = requests.get(f"https://api.weather.com/{city}")
    return resp.json()

weather_data = get_weather("北京")
prompt = f"根据以下天气数据回答问题：{weather_data}"
 再将prompt发送给模型...

这种方式的缺点很明显：

• 耦合高：每个工具都需要单独写调用代码，工具接口变了就得改代码

• 扩展性差：N个模型 × M个工具 = N×M个定制集成

• 维护困难：跨平台工具集成平均消耗开发周期的47%，兼容性故障占比达38%-2

• 无运行时发现：模型无法“主动发现”有哪些工具可用，全靠开发者硬编码

这就是MCP要解决的问题。

二、MCP是什么？

模型上下文协议（Model Context Protocol，MCP） 是由Anthropic于2024年11月提出并开源的标准化协议，旨在定义AI模型如何与外部工具、数据源和业务系统建立安全、高效、可审计的双向连接-1。

🔌 USB-C for AI——最通俗的理解

MCP的设计思想可类比USB-C接口：以前每个设备都有专属充电线（每个AI模型需为每个工具定制集成），而USB-C统一了接口标准。MCP就是AI领域的“USB-C”——任何支持MCP的AI应用，都能像“即插即用”一样接入任何支持MCP的外部工具-4。

截至2026年3月，MCP的月SDK下载量已达到约9700万次，全球活跃MCP服务器超过10,000个，Anthropic、OpenAI、Google、微软、AWS等主流厂商均已支持该标准-69。

三、MCP架构与核心组件

🏗️ 三层架构

MCP采用主机-客户端-服务器三层架构-2：

📦 三大核心原语

MCP定义了Server可暴露的三类能力-2-5：

1. Tools（工具）：可被AI调用的可执行函数。需包含名称、描述、参数schema与执行逻辑

2. Resources（资源）：提供上下文数据的数据源。如文件内容、数据库记录

3. Prompts（提示模板）：可复用的交互模板，如few-shot示例

🔄 工作流程

一个典型的MCP调用流程包含以下阶段-7：

1. 初始化：Client向Server发送initialize请求，协商协议版本与能力

2. 工具发现：Client调用tools/list获取可用工具清单

3. 工具调用：Client发送tools/call请求，携带参数

4. 结果返回：Server执行并返回结构化结果

MCP支持两种传输方式：STDIO（本地进程间通信，低延迟）和Streamable HTTP（远程部署，支持鉴权与流式传输），底层统一使用JSON-RPC 2.0作为消息格式-7。

四、代码示例：从零搭建一个MCP Server

下面用Python MCP SDK演示一个最简服务端实现-33。

环境准备

pip install mcp

服务端代码（server.py）

from mcp.server.fastmcp import FastMCP

 创建MCP服务器实例
mcp = FastMCP("我的助手工具集")

 1. 注册一个工具：加法计算
@mcp.tool()
def add(a: int, b: int) -> int:
    """计算两个整数的和"""
    return a + b

 2. 注册一个资源：动态问候
@mcp.resource("greeting://{name}")
def get_greeting(name: str) -> str:
    """根据用户名返回个性化问候"""
    return f"你好，{name}，欢迎使用MCP服务！"

 启动服务器（STDIO模式）
if __name__ == "__main__":
    mcp.run()

关键代码解析

发生了什么？

当AI应用（如Claude Desktop）连接到该Server后：

1. 调用tools/list → 返回包含add工具的清单及参数schema

2. AI根据任务选择调用add(3, 5) → Server执行并返回8

3. AI调用resources/read获取greeting://小明 → 返回"你好，小明，欢迎使用MCP服务！"

与传统API调用的直观对比：传统方式需要为每个工具写单独的HTTP请求代码；而MCP方式只需一次性声明工具，AI就能通过标准化协议“自主发现”并“按需调用”-19。

五、MCP vs 传统API：概念关系与核心区别

MCP并非要“取代”API，而是在API之上增加一层标准化适配层。

一句话概括：API是让开发者“写代码调服务”，MCP是让AI“自己决定用哪个工具”-19-21。

使用建议

• 用MCP：当AI工作流涉及3个以上外部集成，或需要动态工具发现时-19

• 用API：单目的自动化脚本、非AI应用、对延迟极度敏感的场景-20

六、底层原理：MCP是如何“跑起来”的？

MCP的底层实现依赖以下技术栈-7-5：

1. JSON-RPC 2.0：消息协议基础。所有请求、响应、通知均遵循该格式，语言无关、实现成本低

2. 传输层适配：STDIO（本地进程间通信）或HTTP+SSE（远程部署）

3. 会话管理：有状态协议，需在初始化时做能力协商（capability negotiation）

4. 动态发现机制：通过资源描述符实现，Server启动时自动注册/resources端点，AI可实时获取可用工具清单-2

这些底层机制共同支撑了MCP“一次开发，多端适配”的能力。MCP的生态已在2026年路线图中规划了传输演进（支持无状态水平扩展）、智能体通信（异步任务生命周期）和治理成熟化三个方向-1。

七、高频面试题与参考答案

Q1：什么是MCP？它的核心作用是什么？

参考答案：MCP（Model Context Protocol）是由Anthropic提出的开放标准协议，定义了AI模型与外部工具、数据源、业务系统之间的标准化交互方式。核心作用是统一通信标准：通过协议规范实现工具描述、参数传递、结果接收的统一，确保不同AI模型可以无缝调用不同工具，解决N×M集成问题-45。

踩分点：定义来源（Anthropic）、三大核心规范、解决的问题

Q2：MCP与传统Function Call有什么区别？

参考答案：①消费对象不同：Function Call是为开发者调用而设计的硬编码工具列表；MCP让AI自主动态发现工具。②发现机制不同：Function Call需预定义工具；MCP通过tools/list运行时发现。③解耦程度不同：Function Call将工具定义与模型绑定；MCP实现工具与模型完全解耦-46。

踩分点：动态发现、解耦程度、使用场景

Q3：MCP的架构包含哪些核心组件？各自职责是什么？

参考答案：三层架构：①Host（主机） ——AI应用本体，管理对话上下文与工具权限；②Client（客户端） ——与Server建立连接，处理协议通信；③Server（服务器） ——封装外部工具能力，暴露Tools/Resources/Prompts三类原语-2。

踩分点：三层命名、各自职责、三大原语

Q4：MCP和Skills有什么区别？

参考答案：MCP是标准化通信协议，定义“如何连接”外部工具；Skills是封装在模型内部的能力单元。MCP重在跨系统互操作，Skills重在单一模型内部的能力复用。业界常言“MCP是理想，Skills是现实”-46。

八、总结与进阶方向

核心知识点回顾

• MCP定义：AI领域的“USB-C”标准，解决N×M集成难题

• 三层架构：Host → Client → Server，职责清晰解耦

• 三大原语：Tools（可执行函数）、Resources（上下文数据）、Prompts（交互模板）

• 与传统API的区别：动态发现 vs 硬编码、AI消费 vs 开发者消费

• 底层依赖：JSON-RPC 2.0 + STDIO/HTTP传输 + 会话管理

易错点提醒

• MCP不是用来替代API的，而是在API之上增加标准化适配层

• MCP引入300–800ms的基线延迟开销，简单场景不一定适用-20

• MCP当前在生产环境中面临会话状态管理和水平扩展的挑战，2026年路线图正在解决这些问题-1

进阶方向

• 学习MCP的流式HTTP传输实现（Streamable HTTP）

• 研究MCP Gateway如何实现协议转换与工具编排

• 关注MCP在零信任安全中的应用——通过嵌入上下文实现最低特权访问

下一篇将深入MCP底层协议细节，讲解JSON-RPC帧结构与会话状态机，敬请期待。