怎么考「MCP 是什么？它和 Function Calling 是什么关系、解决了 FC 的什么问题？」

我要答我要考
Q3-08MCP 协议中高频

谁在问：2026 一二面必问；接过 MCP 的团队用 07-28 规范改版来区分「用过」和「读过规范」

开场怎么问

MCP 你怎么理解？它跟 Function Calling 是替代关系吗？

换个问法

  • 我们本来 FC 用得好好的，为什么要接 MCP？
  • 你接过 MCP 吗？说说踩过的坑。

五层追问链

左边照着问，右边对着听。最后一层是压力面，不必每个候选人都问到。

接了 MCP 之后，模型侧的调用方式变了吗？

期望
没变。客户端把 MCP Server 的工具清单拉下来，转成模型接口要的 tools schema，模型照样用 FC 返回 tool_call，客户端再通过 MCP 把调用转发给 server。模型不知道 MCP 的存在。 变的是三件事：工具从哪来（运行时发现而不是编译期写死）、谁维护（server 方而不是你）、鉴权与传输走谁的规范。能顺带说出「所以 MCP 不会提升模型的工具选择准确率，那是描述设计的事」最好。
信号
明确说"模型不知道 MCP 存在"的，接过；答「MCP 让模型能直接调用外部工具」的，把两层混成一层了。

2026-07 规范为什么要把协议核心改成无状态？对部署有什么实际影响？

期望
有状态会话在分布式部署里是最贵的约束——需要粘性路由、扩容缩容要考虑会话迁移、断线要恢复状态、Serverless 基本没法跑。改成无状态之后，任意实例都能处理任意请求，网关配合 Mcp-Method / Mcp-Name 头可以在不解 body 的情况下做路由和限流，运维复杂度大幅下降。代价是原本靠会话承载的多步交互要换机制——由 MRTR 和工具返回 handle 来承担，业务状态从协议层挪到了应用层。还要提一句迁移现实：HTTP+SSE 传输和 Roots/Sampling/Logging 进了 12 个月弃用窗口，存量系统要排迁移计划（截至 2026-08）。
信号
能说出「粘性会话与扩容」这个真实痛点、并知道状态被挪去了 handle 的，读过规范也部署过；只会说「无状态更简单」的，是听说的。

接了三个第三方 MCP Server，工具从 8 个变成 60 个，会发生什么？

期望
三件事同时恶化——上下文固定开销变大（工具定义每轮重发）、选择准确率下降（边界模糊、命名冲突，比如两个 server 都叫 search）、prompt 缓存更容易被击穿（对方更新描述就等于你的上下文前缀变了）。治理手段：在客户端或网关做白名单和裁剪（只放行当前场景需要的工具）、按阶段/角色分批装载、加命名空间前缀避免撞名、利用 ttlMs / cacheScope 控制清单刷新节奏而不是每次连接都全量拉。关键认知是：第三方工具清单是外部输入，必须经过你的一层治理再进上下文，不能直接透传。
信号
提出"网关侧白名单 + 命名空间 + 清单缓存节奏"的，运营过多 server 环境；只答「工具太多要精简」的，没意识到这次的清单不受自己控制。

MCP、Agent Skills、A2A 三者的边界你怎么划？

期望
按"解决什么问题"划。MCP 解决能力接入（我的 Agent 怎么拿到工具）；Skills 解决知识与流程的按需加载（同样的工具，怎么做才对；靠渐进式披露避免把长篇规范常驻上下文）；A2A 解决Agent 之间的协作（把一个任务委托给另一个组织的 Agent，对方内部实现对我不可见）。一句话记忆：MCP 是手，Skills 是手册，A2A 是同事。判断题里常见的坑是"能不能用 MCP 做多 Agent 通信"——技术上能凑合，但语义不对：MCP 面向的是工具调用，A2A 面向的是任务委托与状态跟踪，核心设计词是 opaque（互不暴露内部）。
信号
用"解决什么问题"来划分并点出 A2A 的 opaque 设计意图的，跟上了 2026 生态；把三者说成"差不多的东西"或按发布时间排序理解的，只看过新闻标题。

你们依赖的第三方 MCP Server 昨天更新了工具描述，线上任务成功率掉了 15%。怎么止血、怎么防复发？

期望
先止血，分钟级。 如果客户端缓存了旧的工具清单，先把清单刷新关掉、锁回上一份快照；没有快照的话，在网关侧临时用自己的 schema 覆盖对方的描述（只要工具名和参数没变就能救回来）；再不行就把该工具降级下线，走备用路径或转人工。优先恢复，不要先查根因。 再归因。 对比新旧工具清单的 diff：是描述改了导致模型选择变化，还是参数字段改名/新增必填导致填参失败？这两类在 trace 上表现不同——前者是选错工具，后者是工具报参数错（正好用 Q3-04 的两类失败分法）。 防复发靠制度，不靠祈祷。 ① 工具清单快照 + 每次刷新做 diff，有变更就告警并阻断自动生效，人工确认后再放行；② 版本锁定，只在灰度环境先跑对方新版；③ 自建 adapter 层，把第三方描述翻译成自己维护的一套（多一层维护成本，换来变更隔离，值得）；④ 回归集必须覆盖依赖的第三方工具，把这次的 case 加进去；⑤ 和对方确认变更通知渠道和 SLA，没有 SLA 的依赖应当有降级路径。 对内沟通：这是供应链风险不是模型问题，结论应该落到"关键依赖必须有隔离层和变更告警"，否则同样的事下个月会再来一次。
信号
先恢复后归因（顺序对）、能用「选错工具 vs 参数填错」快速分类、并且把结论落到 adapter 隔离层和变更告警的，管过外部依赖；只答「联系对方问问怎么改的」或者一头扎进根因分析不先止血的，都缺线上意识。

危险信号

听到这些话，基本可以判定是背题而不是做过。

「MCP 是 Function Calling 的升级版/替代品」——层次错误，本题最致命的一条。
只会背「MCP 是 AI 应用的 USB-C 接口」，再问一句实现细节就空——2026 最典型的背诵型回答。
「接了 MCP 模型就能自动调用各种工具了」——以为协议提升了模型能力。
讲的还是 initialize 握手 + 会话 id 那套模型，不知道 07-28 已转无状态（知识停在两年前）。
完全不提代价，把 MCP 说成纯收益。
对第三方 server 直接透传工具清单进上下文，没有白名单、快照和 diff 意识。
说不出 Skills 和 A2A 的区别，认为都是"MCP 的一部分"。

评分卡

  1. 明确 FC 与 MCP 不在一层，不是替代关系
  2. 说清串联关系：MCP 工具 → 转成 tools schema → 模型仍用 FC
  3. 知道 MCP 解决的是 M×N 集成、发现、鉴权、传输，不提升模型能力
  4. 说得出代价：多一跳、清单不可控、供应链风险、调试链路变长
  5. 能说出什么时候不该上 MCP（内部少量工具、极致延迟、需冻结工具集）
  6. 加分：知道 2026-07-28 规范核心转无状态及其部署收益
  7. 加分：知道业务状态新范式是工具返回显式 handle
  8. 加分：知道弃用窗口（HTTP+SSE、Roots/Sampling/Logging）与迁移压力
  9. 加分：能划清 MCP / Skills / A2A 的边界
参考答案与考察意图面试中途别看这一段

考察意图

这题在 2026 是开场必问，也因此成了背诵重灾区。面试官在筛四层：

  1. 层次分不分得清。 把 MCP 说成"FC 的升级版"的人，等于承认没看过任一侧的实现——它俩根本不在一层。
  2. 知不知道它解决的是集成问题而非能力问题。 MCP 不会让模型更会用工具，它解决的是工具从哪来、怎么接、谁维护。
  3. 说不说得出代价。 2026 年"MCP 是 AI 界的 USB-C"这句话人人会背，能讲清多一跳延迟、供应链风险、工具清单失控的人才有区分度。
  4. 跟没跟上规范演进。 2026-07-28 那版改动很大（协议核心转无状态），只讲 2024–2025 那套握手模型的人，暴露的是知识停在两年前。

参考答案

图 2 · 60 分与 90 分差在哪：代价、演进、怎么验证
60

60 分答案（及格线）

它俩不在一层，不是替代关系。

  • Function Calling 是模型侧的表达方式：模型输出"我要调 X 工具、参数是 Y"这样一段结构化意图，执行永远在你的代码里（见 Q3-03）。
  • MCP（Model Context Protocol）是工具侧的接入协议：规定一个工具服务怎么把自己的能力暴露出来、怎么被发现、怎么鉴权、怎么传输。

两者是串联的：MCP Server 提供的工具，客户端拿到后仍然要转成模型的 tools schema 发给模型，模型仍然用 FC 的方式返回调用意图。接了 MCP，模型侧一个字都没变。

MCP 解决的是集成爆炸：M 个应用 × N 个工具原本要写 M×N 套对接，有了统一协议变成 M+N。附带好处是工具可以在运行时被发现、鉴权和传输方式统一、社区生态可复用。

90

90 分答案（有生产经验的回答）

补三层。

1. 三段式看 MCP。

  • 解决什么：集成的组合爆炸、工具的运行时发现、鉴权与传输的统一、生态复用（别人写好的 server 直接接）。
  • 代价是什么：多一跳网络延迟；工具清单不完全受你控制（对方一更新，你的上下文和选择准确率就变）；供应链与安全面扩大（第三方 server 的描述本身就是进入你上下文的文本，见 Q3-10）；调试链路变长（出问题要分清是模型选错、client 转换错、还是 server 返回错）；版本与兼容负担。
  • 什么时候不该用：只有自家几个内部工具且不打算对外开放时，直接写 FC 工具更简单也更快；对延迟极敏感的链路；强审计场景下需要工具集完全冻结的系统——那种情况即使用 MCP 也要在网关侧固化白名单。

2. 2026-07-28 规范的改版要讲到，这是分水岭。 截至 2026-08，MCP 最重要的变化是协议核心转向无状态：取消了 initialize 握手和会话 id（Mcp-Session-Id）。工程影响很直接——不再需要粘性会话，服务可以水平扩容、可以跑在 Serverless 上、断线重连不用恢复会话状态。配套的几项：

  • **MRTR（多轮往返）**用来处理原本要靠会话承载的多步交互；
  • 新增 Mcp-Method / Mcp-Name 请求头做头部路由，网关不用解包 body 就能路由、限流、鉴权；
  • list 类结果带上 ttlMs / cacheScope，工具清单可以被客户端缓存并按需刷新；
  • 动态客户端注册（DCR）弃用，转向 CIMD；
  • Roots / Sampling / Logging 与 HTTP+SSE 传输进入 12 个月弃用窗口；
  • Tasks、MCP Apps、企业级授权等从核心规范挪到扩展（extensions）。

最需要记住的一条：协议无状态之后，业务状态的新范式是工具返回显式 handle——状态不再挂在协议会话上，而是由工具返回一个句柄，后续调用凭句柄继续。这和长结果处理的做法正好统一（见 Q3-05）。

3. 和 Skills、A2A 的分工，一句话各自归位。 MCP 是手（能力接入）；Agent Skills 是操作手册（怎么把事做对，四级渐进式披露：约 100 token 的广告 → 加载 5000 token 以内的 SKILL.md → 读 references → 跑 scripts）；A2A 是对外协作协议（Agent 之间互相委托任务，见 Q3-11）。三者不冲突，一个生产系统里可能同时存在。

攒够了去组卷页一键生成可打印的面试题单