做技术面试这几年我最大的感触是大部分候选人听到 MCP 三个字母第一反应是“哦那个 AI 工具调用协议”然后……就没有然后了。再往下追问一句“那它究竟解决的是什么层面的问题Server 里到底有哪些核心构件一次工具调用从模型到外部服务之间发生了什么”很多人就开始含糊其辞。这篇内容我就把 MCP 的核心知识点整理成一套面试题库的样子并且把每道题背后的原理讲透。不管你是准备 AI 应用方向的面试、要给团队做内部技术分享还是单纯想把自己脑子里关于 MCP 的零散信息串成一张完整的知识地图都可以按这个顺序过一遍。我把它拆成六个部分先讲它解决什么问题再讲核心构件和原语然后是高频考点、深度追问、代码手撕最后是实际踩坑记录。越到后面越偏实战面试官越往深问你越有话说。1. 先搞清楚MCP 到底解决什么问题1.1 一个协议诞生的需求场景在 MCP 出现之前AI 应用要接入外部工具基本是“各玩各的”。每个应用都自己定义一套调用约定有的用 HTTP 接口直接打有的用消息队列有的干脆在代码里硬编码外部服务的调用逻辑。结果就是N 个应用对接 N 个服务集成关系像蜘蛛网一样越织越密每接入一个新系统就要重新写一遍适配代码。打个比方这就像你家里有一堆电子设备每个设备都带不同的充电头出门要带一大把线。后来大家统一了 USB-C一根线解决大部分问题。MCP 在 AI 应用和外部系统之间干的也是类似的事只不过它统一的不只是“通电”而是“任务描述”“参数传递”“结果返回”这一整套交互方式。更深一层看MCP 要解决的是两件事一是让应用和外部系统之间不再互相绑定二是让“接入一次”的工作可以被反复复用。过去某个 AI 助手接了一个内部工单系统以后换一个 AI 客户端这套接入逻辑就废了。但有了 MCP 之后一个相同的 Server 可以同时服务多个客户端同一个客户端也能灵活接上多个 Server。面试答这道题的时候千万别只停留在“USB-C 接口”这个类比。面试官更想听的是这就是一个标准化的接口协议目标是解耦 AI 应用与外部数据源、工具、服务之间的连接方式让集成成本从“每家各做一遍”变成“做一遍到处用”。1.2 MCP 的本质把 AI 能力与外部世界“接口化”我见过很多人把 MCP 和 AI 框架混为一谈觉得“用了 MCP 就等于用了一个中间件平台”。这是一个必须纠正的误解。MCP 本质上是一个基于 JSON-RPC 2.0 的消息交换协议它不是推理引擎不是运行时环境也不是服务网格它只是一套双方共同遵守的“对话约定”。整个协议里智能决策仍然在客户端侧的模型手里MCP Server 本身不部署模型也不负责思考。Server 唯一的职责是把自己可以提供的工具、资源、提示词模板暴露出来并响应外部调用。换句话说MCP Server 是一个“能力适配层”它把外部系统的能力翻译成模型能够理解和调用的接口。理解了这一点很多衍生问题就能顺藤摸瓜。比如面试官问“MCP 能提升模型准确率吗”正确答案大概率是“间接提升”。因为模型本身的智力水平不变但 MCP 给了模型更多可操作的工具、更可靠的上下文来源让它在决策时有更多依据而不是让它变得更聪明。1.3 三个高频名词Host、Client、Server面试必考的第一个概念题通常是MCP 架构里有哪些角色老实说能把 Host、Client、Server 三者讲清楚的人不多。很多人开口就是“客户端和服务端”但漏了最重要的 Host。Host承载 AI 应用的进程或应用本身。它负责触发模型推理、管理上下文、处理用户交互是整个过程的“主持人”。比如一个智能助手应用、一个代码编辑器的 AI 插件都是 Host。Client在 Host 内部与 Server 建立连接的那一层协议客户端。它专门负责 MCP 的协议通信把 Host 的请求打包成 JSON-RPC 消息发给 Server再把 Server 的响应解析回来。一个 Host 里可以有多个 Client分别连接不同的 Server。Server外部能力与服务所在的一端。它向外暴露工具、资源、提示词等能力负责实际执行任务或提供数据。责任划分是面试时容易被问到的一个细节。Host 不直接和外部服务对话而是通过 Client 走协议。Server 不直接调用模型而是通过协议把结果交给 Host 侧的模型去决策。两边各管各的降低耦合。2. MCP 核心原语面试必考的四板斧2.1 Tools 工具让模型能真正“做事”Tools 是 MCP 里最核心、也是面试中出现频率最高的原语。它的本质是一个可执行操作模型通过调用 Tool 来完成具体动作比如查航班、提交订单、运行一段脚本、调用某个内部系统接口。每个工具对外暴露三样东西名称、描述、输入参数。其中输入参数用的是 JSON Schema 来定义这和普通函数接口很像。面试官如果深挖这里一般会问两个问题第一什么时候会用到工具答案是当模型需要影响外部世界时。如果只是想获取信息可能走 Resources 就够了但如果要“做动作”就必须通过 Tools。第二模型是怎么知道应该调用哪个工具的工具的描述文本就至关重要了。描述写得模糊模型就会犹豫不决甚至选错。我建议准备一个例子。比如有一个工具叫query_order_status描述是“根据订单号查询订单当前状态包含是否发货、物流轨迹”。另一个工具叫cancel_order描述是“取消指定订单并触发退款流程”。模型在处理用户“订单怎么还没到”这类问题时如果第一个工具描述写得清晰模型就能迅速判断该查哪个。反过来工具描述一旦写得含糊模型可能把取消失误说成查询引发线上事故。2.2 Resources 资源只走数据不动手Resources 在面试题里很容易被忽略但它才是 MCP 名字里“Context”的真正体现。它的作用是向模型提供结构化的外部数据比如文件内容、数据库查询结果、网页文本、配置信息等。和 Tools 最大的区别在哪里一句话Tools 是动词Resources 是名词。Tools 负责执行操作是会产生副作用的Resources 负责提供上下文是纯读取、无副作用的。具体使用上Resources 通过 URI 来定位。客户端可以拉取资源列表再按需读取某个资源的内容。面试官问“MCP 和 RAG 有什么关系”时如果你能提到 Resources 被设计成一种按需读取上下文的机制说明你已经比 80% 的候选人理解了协议的设计意图。值得注意的细节是Resources 不是一股脑把数据全部塞进提示词而是由 Host 侧的模型或应用按需决定要不要读取、读取哪部分。这个“按需读取”和 RAG 按相关性检索文档在思路上有相似之处但实现层级完全不同。2.3 Prompts 提示词模板服务端统一管理MCP 里的 Prompts 指的是存储在 Server 端的提示词模板。客户端可以获取这些模板把它们组合进当前对话上下文。它解决的问题很实际像“帮我生成周报”“分析这次性能测试结果”这类高频业务提示词通常很复杂、很长如果分散写在各个客户端里维护就是灾难。把模板放到 Server 端统一管理业务方改模板所有接入的客户端就同时生效。面试官如果问出“Prompts 和普通提示词有什么不同”你要抓住的点是“模板化、复用、集中维护”。普通提示词是一个临时输入而 MCP 的 Prompt 是服务能力的一部分由 Server 声明并提供客户端拿到后可以按需塞进上下文。不过这里有个容易混淆的小坑在某些实现里Prompts 也可能会被当成一种特殊工具来实现。面试时如果你能把“它本质上是消息模板而不是可执行函数”这个边界讲清楚印象分会明显提升。2.4 Sampling 采样让协议“双向调用”Sampling 是四板斧里相对冷门的但如果你主动提一嘴面试官通常会眼前一亮。它的作用方向是反向的普通的流程是 Client 调 Server而 Sampling 是 Server 请求 Client 侧的模型完成一次采样补全。举个场景某个 MCP Server 在处理一段文本时需要从中提取核心要点但 Server 自己没有大模型 API 密钥也不直接持有模型能力。这时候它可以通过 Sampling 能力向 Host 发一个请求让 Host 调用它所接入的模型来帮忙完成“摘要”这个子任务再把结果返回给 Server 继续处理。这里可以看出 MCP 并不只是客户端单向调用工具它承载的是一种更对等的“模型上下文交换”理念。Server 同样可以请求模型能力。虽然在实际工程里用得不多但作为知识储备和面试亮点它值得你花时间理解。3. 从面试角度拆解高频考点3.1 高频问题MCP 和 Function Calling 有什么区别这几乎是每场面试都会撞上的问题。很多候选人会习惯性地说“MCP 就是标准化的 Function Calling”这个说法虽然不完全错但过于粗糙。面试官想听的对比维度至少有四个维度Function CallingMCP设计目标让模型能调用厂商自己的函数接口建立 AI 应用与外部系统的通用连接标准标准化程度绑定特定模型厂商的 API 约定与模型厂商解耦任何符合协议的角色都能接入数据上下文支持专注于工具调用附带能力有限工具、资源、提示词模板一体化上下文移交更完整适用场景单个应用内的轻量函数调用跨系统、跨团队、跨应用的可复用集成答题策略上不要急着否定 Function Calling。你可以先说 Function Calling 在“单一应用内让模型调函数”这件事上非常高效然后转折强调当外部系统变多、团队协作变复杂、客户端需要复用能力时一个松耦合的开放协议就更合适。这样既显示你理解两种方案的适用场景也避免“非黑即白”的粗糙判断。再补充一个金句Function Calling 是“应用内部”的机制MCP 是“系统之间”的标准。把这句话放在前面面试官基本知道你是真懂。3.2 高频问题MCP 的传输方式有哪些关于传输层最常考的是两种一种用于本地子进程通信一种用于远程网络通信。stdio 传输MCP 客户端以子进程方式启动 Server通过标准输入输出流交换 JSON-RPC 消息。适合本地工具、本机运行的轻量服务优势是免部署、起停方便缺点是不适合跨机器调用。很多桌面端 AI 工具的本地工具都走这个模式。HTTP 流式传输面向远程服务场景Server 独立部署成 HTTP 服务客户端通过网络发起请求。协议支持流式响应Long-running 任务可以通过流式方式持续输出进度。早期基于 SSE 的传输实现在新版本里已经逐步让位于更通用的 HTTP 流式形态。面试官如果追加“你项目里用哪个”不要只答“用的 stdio”要补上理由。比如本地方案需要快速集成且不愿意增加网络暴露面于是选了 stdio远程团队需要多个客户端共享同一个能力中心于是选了 HTTP。每一句话都在传递“你做过取舍”。3.3 高频问题一次工具调用完整的链路是什么这道题能筛掉很多“背概念型”选手。知道 Tools 是什么只是第一步能把一次调用的完整链路讲清楚才是真正理解协议运行方式。完整链路大致是下面几步初始化与握手Client 和 Server 建立连接交换协议版本协商双方支持的能力集。能力发现Client 向 Server 发起工具列表查询拿到当前可用的工具清单包括名称、描述、参数 Schema。模型决策Host 把当前对话上下文和工具信息交给模型模型判断是否需要调用工具、调用哪个、传什么参数。调用请求Client 向 Server 发起工具调用请求消息里包含工具名和参数。服务端执行Server 执行对应的业务逻辑比如调数据库、调第三方接口。结果返回Server 把执行结果返回给 Client模型根据结果生成最终对用户的回复如果执行报错Server 返回错误信息由模型决定下一步怎么处理。每一步都有可以被追问的细节。比如“能力协商到底协商什么”答案是双方各自声明支持哪些原语、支持哪些传输特性。比如“工具参数校验谁负责”规范上 Server 应该校验并返回结构化错误但实际上不少 Server 把参数校验当成摆设这也为后面踩坑埋下了伏笔。3.4 高频考点速查表整理一张速查表方便面试前快速过一遍考点应该答出的关键点MCP 是什么开放协议基于 JSON-RPC 2.0标准化 AI 应用与外部系统的连接核心角色Host / Client / Server 三层职责分离核心原语Tools 做事、Resources 供数据、Prompts 管模板、Sampling 反查模型传输方式stdio 本地进程、HTTP 流式远程一次调用流程握手 → 列表发现 → 模型决策 → 调用 → 执行 → 返回与 Function Calling 区别应用内 vs 系统间绑定厂商 vs 开放标准与 RAG 区别RAG 解决知识检索MCP 解决系统连接两者互补4. 面试中的深度追问与拔高题4.1 设计一个生产级 MCP Server 要考虑什么这一题几乎是“送命题”因为它没有标准答案考的是工程视野。我建议按三个层面去回答。第一层协议层。Server 要正确实现能力协商明确声明自己支持哪些原语工具的输入 Schema 必须严谨JSON Schema 的 required、type、enum 都要仔细定义否则模型传参就是一场灾难。第二层业务层。每个工具背后都是真实的系统调用要综合考虑连接管理、超时控制、并发限制、幂等设计。比如“取消订单”这种有副作用的操作就必须支持幂等否则网络抖动重试会造成重复取消。第三层治理层。包括日志、监控、鉴权、审计。谁在什么时间调用了哪个工具、传了什么参数、结果是什么这些都需要留痕。如果面试官继续追问“怎么鉴权”可以补一句MCP 的认证体系本身基于 OAuth 2.1 框架设计Server 可以作为资源服务器存在访问受保护工具前需要拿到合法令牌。这个回答能体现你对协议安全体系有过系统性了解。4.2 多个工具同名冲突怎么办这个问题不长见但问出来就是要看你有没有线上经验。MCP 的标准做法是工具名在整个 Server 范围内必须唯一所以同名的冲突本质上是“命名空间设计”的问题。不同团队接同一个 Server 时一般通过前缀来区分比如订单相关工具统一加order_前缀支付相关工具统一加payment_前缀。同时客户端侧也要有自己的兼容策略如果同时连接了多个 Server且多个 Server 暴露了同名工具客户端可以在本地做路由把请求分发到正确的 Server 上。这类问题没有唯一答案关键是展示你“提前意识到了命名冲突会真实发生”的经验。4.3 MCP 和 RAG 是替代关系吗这题答错很容易。RAG 强调的是“检索增强生成”核心是把知识库里的相关内容检索出来塞进上下文帮助模型回答MCP 强调的是“连接和互操作”核心是让应用能按需调用外部服务和数据。二者不但不冲突反而可以配合使用。一个很好的表述是RAG 是“让模型知道”MCP 是“让模型能办”。先通过 RAG 式检索让模型了解政策条款再通过 MCP 工具让模型帮忙提交申请、查询进度。也可以直接用 MCP 连接一个向量检索服务把检索能力也封装成工具或资源提供给模型。如果面试官问“你会怎么设计一个带知识库的智能客服”把 RAG 做知识问答、MCP 做业务操作组合起来讲这题就稳了。4.4 MCP 的安全模型怎么设计安全是 MCP 面试题里最容易答空泛的。我的经验是拆成三个层次。第一层工具权限。不是所有工具对所有用户开放涉及资金、隐私、删除类操作必须走独立的授权流程。第二层调用确认。对于高风险的业务操作Host 应该在模型发起调用前弹出用户确认而不是模型说调就调。第三层传输安全。远程 Server 必须走加密通道令牌不能硬编码进客户端要使用标准授权流程获取短期凭证。再补一个容易被忽略的点工具返回的“数据”本身也要警惕。如果某个工具从外部接口拉取了未经清洗的内容再喂给模型这中间存在提示词注入的风险。在设计 Server 时就要考虑对返回内容做格式约束和敏感信息过滤而不是拿到什么就给模型读什么。5. 手撕环节与代码级理解5.1 一个最小 MCP Server 长什么样面试手撕题不要求你写出可运行的完整代码但要求你能把关键骨架写对。用 Python 风格做一个最小化示例重点在于展示“如何暴露一个工具”# 示意代码最小 MCP Server 的核心骨架 from mcp.server import Server, tool server Server(demo-server) tool async def calculate_discount(price: float, rate: float 0.9) - float: 计算折后价格rate 为折扣率默认 0.9 return price * rate async def main(): # 连接传输层stdio 模式 async with server.run_stdio() as transport: await transport.wait()这段代码演示了几件事Server 实例、工具注册、描述文本、传输层启动。面试时你甚至不需要完整写出run_stdio的细节只要让面试官看到你知道“工具注册是核心传输层是出入口”就够了。真正的加分项是你主动说一句这只是最外层骨架生产环境里真正的复杂度在工具内部的业务处理、参数校验、鉴权重试以及异常如何转成协议错误返回。5.2 客户端调用链的细节如果你能描述出客户端侧的实现细节就说明你不是只看过架构图。客户端的核心逻辑可以拆成这几块连接管理建立与 Server 的传输通道支持按需重连。消息对应JSON-RPC 的请求和响应要通过唯一 ID 匹配Message ID 一旦错乱整个调用链路就废了。能力协商初始化时记录对方声明的能力后续请求只在协商过的能力范围内发起。错误处理协议层面的错误和业务执行失败要分开处理。协议错误说明 Server 实现有问题业务错误则要原样反馈给模型让模型决定怎么向用户解释。这段如果面试官有耐心听完通常会在心里给你打上“真正写过客户端”的标签。5.3 如果没有 SDK你还能不能用这是一个拉差距的开放性问题。MCP 本身是传输层 JSON-RPC 2.0 消息格式语言 SDK 只是帮你封装了这些细节。所以即使不使用任何官方 SDK只要目标语言能发起进程通信或 HTTP 请求、能构造 JSON就可以实现一个最小可运行的客户端。面试时你可以说我会先列出协议规定的核心方法比如 initialize、tools/call然后按 JSON-RPC 2.0 的报文格式构造请求再实现消息收发和 ID 匹配。剩下的就是按状态机处理握手流程。这样回答既显得你有协议底层的掌控力也能避免过度依赖工具库的形象。6. 实战踩坑记录与避坑清单6.1 我遇到过的典型问题这里把我在实际项目里踩过的坑整理成清单面试讲故事时可以直接用。第一个坑工具 Schema 定义太随意。刚开始我们把参数全部定义为字符串结果模型经常把数字、日期也传成字符串服务端又缺少强校验最终一步错步步错。后来我们把 JSON Schema 写严谨该用 number 的地方用 number该限制枚举的地方限制枚举错误率立刻降下来。面试官问“MCP 落地难点”时这个例子非常真实。第二个坑工具描述写成了“流水账”。把描述写得像散文模型理解成本极高甚至出现“应该调用查询接口却调用了取消接口”的低级事故。后来我们形成规范每段描述第一句用最简短的祈使句说明用途再补一句典型场景最后写上注意事项。这样模型一眼就能锁定目标工具。第三个坑长任务的超时处理。某次一个数据分析工具执行要跑两分钟但客户端默认超时只有 30 秒任务被中途断开。后来我们改造为流式进度更新客户端不到最终结果就不判定失败。面试官如果问“流式传输有什么实际价值”这就是现成的答案。第四个坑进程异常退出没有守护。stdio 模式下Server 进程如果因为未捕获异常退出客户端不会自动拉起。生产环境里必须做进程守护和自动重启否则一个偶发崩溃就是一次线上事故。第五个坑同名单冲突。两个团队各自封装了自己的“获取用户信息”工具接到同一个 Host 后就打架。我们在协议层面通过工具名前缀约束解决并把前缀规则写进了部门规范。这件事让我彻底意识到没有命名规范就没有可维护性。6.2 抓住一张完整的答题闭环面试的最后如果能用一段 30 秒的话把整个 MCP 的认知闭环讲完会很加分。我建议的表述是MCP 的核心价值是通过标准协议把 AI 应用和外部系统解耦让能力可以被复用它的基础是 JSON-RPC 2.0核心角色是 Host、Client、Server 三层能力模型由工具、资源、提示词模板、采样四类原语构成落到工程上需要关心传输方式、安全性、Schema 质量、幂等重试和可观测性。这段话信息量够又有节奏感比散装的知识点强太多。我个人在实际项目里还有一个体会不要一上来就想搭建“完美的大一统架构”而是先找一个高频、低风险的工具场景跑通比如让模型可以查询订单状态、读取监控数据这类只读操作等整个链路稳定了再逐步加入有业务副作用的写操作。这样既能快速验证 MCP 的价值也能积累足够多的安全与运维经验后面再往上扩展你心里就有底了。