最近AI应用方向的面试风向变得挺快。前两年还在聊大模型微调、RAG怎么搭到了今年越来越多的团队把 Model Context ProtocolMCP写进了岗位要求里面试题库里也高频出现跟MCP相关的问题。你可能已经看过这个词——它在AI圈几乎是突然就成了协议层面的热门焦点但真正能把它讲清楚的人其实不算多。这份题库是我整理MCP核心知识点时攒下来的按面试官的提问习惯分成五块基础认知、协议原理、应用部署、高频追问、模拟实战。每道题都配了回答思路和易错点说明既能当面试前的速查手册也能当团队内部对齐认知的共学材料。你要是刚接触MCP连它的全称都还不熟也没关系顺着这些问题走一遍基本就是一条完整的入门路径。1. 基础认知题一上来先问“MCP到底是什么”面试官第一题通常不会让你背定义而是看你能否用通俗语言说清楚MCP存在的必要性。这一层答不好后面关于协议细节的追问基本就聊不下去了。1.1 第一问MCP解决的是AI应用里的哪个痛点这道题的答题质量很容易拉开差距。简单的回答是“MCP可以让AI连接外部数据和工具”但这只是描述不是回答。能拿高分的回答会先点出大模型应用的结构性痛点。过去做一个AI助手想要让它查数据库、调办公系统、发消息就需要为每一个系统单独写一套集成代码。A系统的接口是一种鉴权方式B系统又是一种数据格式C系统还要专门的SDK每接一个就写一段定制逻辑。更麻烦的是这些集成代码往往跟业务逻辑绑死换一个场景就得重新写一遍。站在大模型的角度看它虽然有对话和推理能力但对外部世界是“失明”的既看不到你的业务数据也碰不到你的内部工具。MCP做的事情就是把这些“连接”标准化。你可以把它类比成AI应用里的USB接口USB出现之前鼠标、键盘、打印机各有各的接口接起来非常痛苦USB出现后只要设备支持同一套标准插上就能用。MCP要解决的就是AI和工具之间的“接口统一”问题——一个MCP服务端把数据或能力暴露出来任何支持MCP的客户端都能直接对接不用为每个客户端单独适配。这个协议由某头部AI实验室在2024年底开源定位是一个中立的开放标准不是某个商业产品的私有协议。之所以强调“中立”是因为在面试里常常会遇到一个误解有人觉得MCP是不是某家公司用来绑定生态的。其实它的设计目标恰恰相反是让不同模型、不同客户端、不同工具之间能通过同一套协议互相通信。面试官在这个基础上还可能追问一句那MCP是不是就是AI版的API网关这时候你要抓住区别。API网关解决的是后端服务之间的流量调度和协议转换MCP解决的是AI应用与外部能力之间的交互标准化它需要同时考虑模型侧的调用习惯比如工具描述如何组织、上下文如何传递、权限如何协商这些都不是传统网关关心的点。1.2 第二问Host、Client、Server三个角色分别干什么这个问题是在考察你到底是听过概念还是真的拆解过架构。MCP架构里最核心的三个角色是Host宿主、Client客户端、Server服务端用一句话说清楚三者的关系Host是用户直接面对的AI应用Client是Host内部负责跟Server建立连接的通信组件Server是暴露具体数据和工具的服务。这么干讲不够直观我一般会拿聚会点餐来类比。Host就是坐在餐桌前的人他想吃什么、想要什么服务都是他说了算Client是他叫来的服务员负责跑腿把需求传达到后厨Server就是后厨菜品怎么准备、有没有食材、能不能做由后厨说了算。三个角色各自的职责边界要记清楚角色核心职责典型例子Host管理用户会话、决定调用哪些工具、处理模型与工具之间的上下文某个桌面端AI助手、某个IDE编辑器Client维护与Server的连接、发送协议消息、处理响应Host内置的MCP客户端模块Server暴露工具/资源/提示词执行实际的业务逻辑某个业务系统的连接器实际面试中常见的低分回答是把Client和Host混为一谈说“Host就是客户端”。严格来说通常一个Host内置了Client但Client只是Host的一个部件。Host里可能有多个Client同时连着多个Server甚至连接同一类型但配置不同的Server这是很常见的部署形态。还有一个高频追问既然有Server那谁来负责调用模型答案是Host。MCP协议只管Host与Server之间的通信模型调用发生在Host内部不在协议范围内。很多人想当然地以为MCP里面应该包含模型调度逻辑其实协议边界划得非常清楚模型是你自己的工具连接是MCP负责的。1.3 第三问MCP和插件、API的本质区别在哪里这道题在题库里出现频率很高因为很多人确实分不清这组概念。最稳妥的回答思路是从“集成成本”和“标准层级”两个角度切。传统API时代每个系统提供自己的接口调用方式、参数结构、鉴权机制各不相同。你需要针对系统A写一套封装针对系统B再写一套封装。MCP的定义方式则是一个服务端只要实现了MCP协议客户端的调用方式就统一了。服务端内部怎么实现不重要客户端只认协议。插件和MCP也不是一个层级的概念。插件通常指在某个具体应用内部扩展功能的机制强绑定宿主环境MCP是跨应用的开放协议同一个MCP服务端可以被不同的Host复用。换句话说插件是“应用定义的扩展约定”MCP是“行业定义的互联标准”。面试官如果想加大难度会问既然MCP这么好那是不是所有集成都应该改成MCP这时候要给出务实的答案——不需要。已经在稳定运行的内部API体系没必要推翻重来MCP适合的是AI需要动态发现和调用能力的场景。它不是万能的也不是银弹。能认识到这一点说明你对技术选型有真实经验不是背了概念就上场。2. 协议原理题工具、资源和提示词到底怎么运转过了基础概念关面试官就会把问题往下压开始考察协议内部的三类核心原语和一次完整调用流程。这部分答的是“知其所以然”需要理解协议消息的组织方式。2.1 三类核心原语要讲清楚MCP协议定义了三个关键原语Tools工具、Resources资源、Prompts提示词。你在准备这道题时最好能用表格横向对比面试官看到你主动用结构化方式回答印象分会高不少。原语作用类比由谁发起Tools让模型可以执行动作读数据、写数据、调接口都属于这一类给模型一双手模型主动调用Resources向模型提供上下文数据比如文档片段、表格内容、代码片段给模型一双眼睛应用侧按需加载Prompts定义可复用的提示词模板标准化一组对话模式给模型一套话术脚本用户或应用触发记住一个特性能帮你应付追问“模型是否能直接看到Resource里面的内容”。答案是不一定。Resource数据由Host和Server约定加载模型看到哪些内容取决于Host怎么组织上下文。有些资源是自动注入有些则需要模型先发起读取请求。很多人在这里误以为Resources等价于把数据塞进上下文并不是这样。讲这三类原语时最好能给一个落地例子。比如做一个客服知识库MCP服务端Resources可以暴露“退款政策”文档Tools可以暴露“查询订单状态”接口Prompts可以定义“生成客服回答”的模板。一个服务端把三类能力都占全了面试官会觉得你不是只读了概念文档而是真的设计过服务。2.2 手撕一次完整工具调用流程这道题几乎算MCP面试的必考题考察你是否理解协议通信的完整链路。完整的调用流程大致是客户端与服务端先建立连接然后初始化握手客户端通过工具列表发现可用能力模型根据用户意图选一个工具客户端发起工具调用请求服务端执行业务逻辑并把结果返回。协议底层使用JSON-RPC 2.0格式做消息封装这是MCP和很多内部自定义AI协议的重要区别。它没有另造一个通信协议而是站在成熟标准之上定义语义。面试时提到这一点能体现你对协议设计的理解深度。下面是我抓包简化后的四个关键消息面试时手写也可以用这个思路// 1. 初始化握手 { jsonrpc: 2.0, id: 1, method: initialize, params: { protocolVersion: 2025-06-18, capabilities: {}, clientInfo: { name: demo-host, version: 1.0.0 } } } // 2. 服务端返回能力与版本 { jsonrpc: 2.0, id: 1, result: { protocolVersion: 2025-06-18, capabilities: { tools: {} }, serverInfo: { name: order-server, version: 2.3.0 } } } // 3. 客户端列出可用工具 { jsonrpc: 2.0, id: 2, method: tools/list, params: {} } // 4. 客户端调用指定工具 { jsonrpc: 2.0, id: 3, method: tools/call, params: { name: query_order, arguments: { order_id: 20250121 } } }笔试或面试中如果能讲清楚四个节点分别在哪个角色上发生就已经胜过很多人。面试官通常会接着追问服务端怎么知道客户端调用的是哪个工具答案是靠工具名和入参结构工具名在tools/list返回里声明格式是JSON Schema客户端必须按格式传参。还有一个值得提前准备的细节initialize阶段双方会校验协议版本。如果版本不一致服务端可以选择拒绝连接或降级兼容。这个机制在分布式系统里很常见但很多人复习MCP时会忽略面试官一追就容易卡壳。2.3 MCP和Function Calling是不是一回事这个问题问出来基本是在试探你是否混淆了两个容易搞混的概念。MCP和Function Calling经常被拿来相提并论但它们的定位完全不同。Function Calling是模型侧的一种推理约定指的是模型在生成回答时决定“要不要调用一个函数、调用哪个函数、传什么参数”。它解决的是模型输出结构化的调用意图。MCP解决的是AI应用与外部服务之间的连接与交互标准化。一个偏模型内部行为一个偏应用外部通信。比较准确的描述是它们不是竞争关系而是可以协作的关系。模型经过Function Calling判断出需要调用某个工具那这个工具具体怎么找到、怎么连接、怎么执行可以由MCP来承担。很多AI框架里两者确实是一起出现的模型输出函数调用请求应用再通过MCP把这个请求路由到对应服务端。面试官如果问“MCP会不会取代Function Calling”可以这么回答不会取代因为前者管的是服务接入后者管的是模型决策。两个层面关注的问题不一样强行二选一反而是不合理的架构判断。3. 应用部署题怎么把MCP服务端真正落地基础概念和协议原理都聊完之后面试官通常会转向工程实践类问题。这一轮的问题没有标准答案但很能反映你实际做过多少项目。3.1 传输层选型stdio还是HTTP系MCP的传输层选择是面试中出现频率很高的一道工程题。当前实践中常见的传输方式有两类基于标准输入输出的stdio传输以及基于HTTP的远程传输。stdio方式的应用场景很典型——服务端和客户端在同一台机器上由客户端拉起一个本地子进程通过进程的标准输入输出来传JSON-RPC消息。好处是部署简单、隔离性好、不占用网络端口缺点是服务端只能在本地跑没法跨机器访问而且进程生命周期由客户端管理。HTTP系传输则是为了让服务端能被远程访问。在设计演进中业界出现过基于SSE的传输方式以及更推荐的streamable HTTP方式。核心思路都是通过HTTP端点接收请求、推送事件让远程服务端可以挂到多个客户端下面。假如面试官问“为什么远程场景不适合用stdio”不要只说“因为没法跨机器”还可以补充一点MCP服务端往往是常驻进程如果把远程进程暴露成stdio接口那客户端就得自己处理进程拉起、存活检查、状态同步等一系列问题。这些本来由操作系统管理本地进程时比较省心放到网络环境下就成了一场噩梦。HTTP系把连接生命周期和进程生命周期解耦才是合理的设计。可以用一个简单表格总结选型思路选型适合场景需要重点回答的关键点stdio本地开发、单机部署、测试子进程管理、日志输出到stderrstreamable HTTP跨机器服务、多客户端复用连接生命周期、服务端鉴权、流式响应我建议在准备面试时额外记住一点流式传输对AI场景很重要。模型生成回答本身就是流式的工具调用结果如果也要流式返回传输层就得支持。MCP协议为流式响应和通知机制预留了空间讲HTTP系方案时主动提这个点很容易让面试官觉得你是做过流式接口的人。3.2 鉴权与授权怎么答才不翻车这个问题让很多人翻车是因为习惯性地照着传统API的思路去答“我们用了API Key”。MCP里的鉴权话题有它自己的设计讲究。首先要把认证和授权分开。认证是“你是谁”授权是“你能干什么”。MCP协议本身不做用户认证它更关注服务端如何声明能力、客户端需要哪些授权才允许使用。在远程服务端场景里目前常见做法是引入OAuth 2.1这类成熟授权框架或者采用服务端自定义的令牌方案。我建议在面试中不要虚构一套复杂的鉴权体系而是给出一个直白的原则MCP服务端的权限设计应当遵循最小化原则。比如一个只读查询工具就不该返回超过查询所需的数据一个写入工具必须明确声明写入范围并由客户端展示给用户确认。“AI应用把用户的话当成指令”这件事带来了新的越权风险面试时主动提到这块说明你已经踩过授权的坑。还有一个容易忽略的点MCP客户端与本地stdio服务端通信时鉴权压力比远程场景低得多因为进程边界本身就是隔离。但即便在本地服务端也不该无条件信任客户端。基于这个思路展开回答比死记“本地不需要鉴权”要好得多。3.3 多服务端接入与安全隔离实际项目里一个Host往往要同时连接多个MCP服务端。面试官在这里想听的不是“能连”而是“怎么管理边界”。最稳妥的回答结构是分三层讲。第一层客户端层面不同的服务端在客户端里有独立的client实例维护各自的连接状态和会话上下文。第二层进程层面本地服务端尽量以子进程方式隔离不同服务端之间互不影响一个服务端崩溃了不该拖垮整个Host。第三层业务层面多个服务端的工具可能存在语义冲突比如两个服务端都有叫send_notification的工具客户端怎么选这时候需要给工具增加命名空间或分组。工具冲突这个点很多人想不到。你可以举个实际例子一个服务端管理内部工单另一个服务端管外部邮件它们都有send_reply接口。如果没有命名空间隔离模型按名字调用时很容易产生歧义。面试官听到这里通常会觉得你不是只会demo级开发的人。顺带还能补充安全隔离的另一个方向服务端能访问的资源和工具应严格限定在它职责范围内。比如一个日历MCP服务端就没必要暴露读取邮件的能力。权限边界清晰是MCP服务设计里最容易讲出深度的点。3.4 进阶追问采样与层级上下文如何理解这个问题不属于必考范围但如果面试官觉得前几轮你答得不错很可能用来试探上限。MCP里的Sampling采样是一个容易被忽略的特性它允许服务端反向请求Host“帮我去调用一次模型”。听起来有点绕但其实解决了一个很现实的问题——某些时候工具内部的决策也需要模型参与。举个例子一个文档处理服务端在整理资料时需要判断一段文本是否应该归入某个分类。服务端自己没法调用大模型就可以通过Sampling机制向Host发起请求Host调用模型拿到结果后返回给服务端。设计这个机制的原因很实在不是所有服务端都内置模型能力让Host统一管理模型调用比每个服务端各自接一个模型更省成本。层级上下文对应的是多级上下文管理。一个Host同时连多个Server时上下文的来源是分散的。如何把文档、数据库查询结果、工具返回结果统一组织成可供模型使用的上下文就涉及上下文分层和裁剪策略。回答时可以点出几个工程权衡哪些数据常驻上下文、哪些按需加载、哪些在工具返回后被丢弃。能把这几个权衡讲清楚你在面试官心里的定位会从“知道MCP的人”变成“用过MCP做系统的人”。4. 面试官视角八个高频追问及答题避坑这一节整理的是我在模拟面试和真实招聘里反复听到的追问方向。这些题目本身不难但考察的是你在压力下能不能保持概念清晰。4.1 MCP是REST API的替代品吗不是替代关系。REST API面向的是应用间通信的通用场景MCP面向的是AI应用接入外部能力的专用场景。MCP服务端内部完全可以封装一个REST API它暴露给客户端的则是标准化的工具语义。回答时可以加一句“从实现角度MCP的Server层经常是个很薄的适配层真正的业务逻辑还在下层服务里”直接点明关系。4.2 上下文窗口不够用怎么办这道题考察的是你是否理解Resource的按需加载。很多人的误区是把MCP服务端当成一个“把全部数据塞进上下文”的工具。正确思路是上下文大小始终受限MCP的价值在于把按需获取数据的机制标准化。回答时可以提三种策略精简工具返回结果、按需加载Resource、用工具分步读取大文件。不要跟面试官讨论“上下文窗口会越来越大所以这个问题会消失”那是把问题抛给未来不是工程设计思路。4.3 服务端连不上怎么排查这类排查题没有唯一答案核心是表达清晰的排查路径。我一般按下面顺序回答先看进程是否存活本地模式直接看子进程状态远程模式检查HTTP端点是否响应。再看握手是否成功MCP服务端连接后第一件事是initialize如果版本不匹配连接会被拒掉。然后检查协议消息格式用JSON-RPC格式做一次手动调用看返回是否符合预期。最后看具体业务报错工具执行本身抛异常不代表协议有问题。讲完顺序后可以加一句心得很多连接问题不是协议层面的问题而是鉴权失败或网络策略拦截。先判断问题边界再深入排查是这类题最好的答案。4.4 工具调用失败应该怎么答MCP的Tools/Call是同步且可能会失败的。面试官想听的不是“服务端报错就捕获异常”而是你对失败处理的完整思考。高分的回答一般分三步服务端对错误异常做结构化返回客户端把错误信息传给模型让模型决定怎么处理Host层做超时保护防止工具卡死整个对话。这里有个容易忽略的细节工具返回的错误信息应当是可读的、结构化的不能是一段无意义的堆栈。模型要靠错误信息来决策下一步如果你只在客户端硬编码“调用失败请重试”那模型就等于瞎了。把错误信息设计得对模型友好是MCP工程实践里很实际的加分项。我把这一节的要点整理成速查表方便面试前快速扫一眼追问方向建议回答要点避坑提醒与REST API关系面向场景不同MCP可封装REST不要说“取代”上下文窗口按需加载结果精简不要全量塞数据排查连接问题进程→握手→消息→业务不要从后往前查工具失败处理结构化错误返回模型决策不要只抛堆栈鉴权设计OAuth思路权限最小化不要说用单一API Key锁死多服务端独立client命名空间不要忽略工具冲突传输选型本地stdio远程HTTP不要只说“都行”协议版本兼容initialize协商不要忽视版本校验5. 模拟面试实战三道综合题带你走一遍最后这块我准备了三个更接近真实面试场景的综合题。这类题通常没有单选答案面试官看的是思路完整度。5.1 场景题把一套内部办公系统接入MCP题目一般长这样假设公司有一套内部审批系统想把它的能力开放给AI助手让你设计一个MCP服务端你会怎么做。完整的回答思路分四步。第一步梳理业务能力审批系统有哪些动作可用哪些适合让AI直接执行哪些只适合AI查看。第二步划分原语查询类能力适合做成Resource或带查询参数的Tool提起审批这种动作型能力适合做成Tool标准化的审批流程说明可以做Prompts。第三步设定权限边界只读操作和写操作要分开审批通过这类敏感操作应要求二次授权。第四步规划部署方式内部系统通常跑在私有网络上远程MCP服务端要考虑网络入口和鉴权。这道题能充分看出你是否具备架构思维。只回答“写个Server把接口包一下”是不及格的因为完全没有体现能力分级、权限干预和部署形态之间的取舍。5.2 场景题工具偶尔超时怎么处理面试官会给出一个具体故障场景某个MCP工具在高峰期偶尔响应很慢超过客户端超时阈值用户经常看到失败提示。让你给出处理方案。我的答题思路是分两端处理。服务端这端先确认慢是因为业务逻辑、下游依赖还是资源竞争然后做优化——加缓存、限流、异步化至少要让响应时间趋于稳定。客户端这端设计超时重试策略时注意两点一是区分幂等和非幂等工具查询类可以重试创建类操作重试要小心重复下单二是超时时间不能拍脑袋要根据服务端的P99耗时来定。最后补一句如果服务端能在超时前返回一个“任务已受理”之类的中间状态体验会好很多但这需要协议层面的配合。5.3 开放题MCP未来的演进方向开放题考察的是你对该领域的持续关注度。不建议去预测具体功能而是讲两个更底层的趋势。第一个趋势是协议标准化和生态治理。MCP还在快速演进版本兼容、能力协商、服务端可信度评估这些配套机制会越来越重要。第二个趋势是从“连接工具”走向“连接上下文”。AI应用的竞争重心正在从模型本身转向对上下文的理解和组织能力MCP作为上下文互通的底座会和其他配套技术一起形成新的应用基础设施。回答时带上自己的实际观察比如“我看到团队接入MCP后工具集成的维护成本确实降下来了”会让整段话更可信。最后分享一点个人体会这套题库整理下来我最大的感受是MCP的面试题不能靠背关键是理解协议设计背后的取舍。为什么传输层要区分stdio和HTTP为什么初始化要先握手再调用工具为什么授权要跟认证分离——每一个设计决策背后都有明确的工程原因。把这些问题都想通之后不管面试官用什么变体来问你都能从原理层给出答案。另外想提醒一句MCP还在快速演进中协议版本会更新工具定义模式也会变。题库里的知识点可以作为起点但真正的竞争力来自你亲手搭过一个MCP服务端、踩过一次连接失败、调过一次工具超时。那些实际经验才是面试时最拿得出手的东西。