• 时间:
  • 分类:

你以为大家在聊“协议”，其实面试官在看你会不会把 AI 系统做成基础设施

这半年，AI 圈有个词越来越常见：MCP。

只要你做过 Agent、工具调用、知识库问答、IDE AI 助手、企业内部 Copilot，大概率都会听到有人说：

“我们后面准备把工具层统一成 MCP。”

很多人第一次听到这个词，会觉得它很高级。

但真正到了面试里，面试官想听的，绝对不是一句：

“MCP 就是让模型更方便调用外部工具的一个协议。”

这句话不能算错。

可如果你只能讲到这里，那在一个稍微懂点 AI 工程的人眼里，你大概率只是知道这个名词火了，还没有真正理解它为什么会火，也没有真的把它接进系统里。

因为真正做过的人都知道，MCP 不是一个“更时髦的 Function Call 包装壳”，它背后其实是在解决一个非常现实的问题：

当模型、工具、上下文、客户端越来越多的时候，系统到底该怎么接，才能不越做越乱？

而且面试官一旦顺着这个问题往下问，后面通常全是硬题：

  • MCP 和普通 Function Call 到底有什么区别？
  • 为什么大家突然开始强调“协议层”？
  • MCP 解决的是“模型能力问题”，还是“系统集成问题”？
  • MCP Server 到底暴露的是什么，工具、资源还是 Prompt？
  • 你们为什么需要 MCP，而不是自己写一套工具注册中心？
  • MCP 真上生产以后，权限、稳定性、调试、版本兼容怎么做？

这时候很多人就会开始发虚。

因为 AI 项目最容易出现的一种幻觉就是：

你以为自己在做智能，实际上你在补基础设施。

今天我们就借着 MCP 这个热点，把 5 个最容易被追问的关键问题，一次讲透。

🎯 第一问：MCP 到底是什么？别只会说“它是一个协议”

MCP，很多人第一反应就是：

“Model Context Protocol，模型上下文协议。”

没错，但这只是字面解释。

真正更有用的理解是：

MCP 本质上是一套让模型宿主、安全工具、外部数据源、提示模板之间可以标准化协作的接口约定。

换句话说，它最重要的价值，不是“发明了新能力”，而是：

  • 把工具接入方式统一起来
  • 把上下文来源描述清楚
  • 把模型能看到什么、能调用什么，变成标准接口
  • 让不同客户端和不同服务端之间，少写很多胶水代码

你可以把它想象成 AI 时代的一层“通用插座”。

以前很多团队做 Agent，通常是这样接的：

每来一个新工具
  -> 手写一份工具描述
  -> 自己定义参数结构
  -> 自己写鉴权
  -> 自己拼提示词
  -> 自己处理返回格式
  -> 自己做兼容

工具少的时候，这样还能扛。

但一旦工具多起来，比如：

  • 文档检索
  • 数据库查询
  • 工单系统
  • 日历
  • 邮件
  • 代码仓库
  • 内部知识平台

很快就会变成一锅粥。

这时候 MCP 想解决的核心问题就出现了：

客户端怎么发现能力
客户端怎么理解能力
模型怎么安全地使用能力
工具结果怎么标准化回传

所以 MCP 的重点不是“让模型更聪明”，而是“让模型周围那圈能力更容易组织起来”。

一句更像做过项目的人会说的话是：

MCP 的本质不是提升模型智商，而是降低 AI 系统集成复杂度，让上下文和工具能力从“项目私有逻辑”变成“可复用基础设施”。

⚙️ 第二问：MCP 和 Function Call 到底有什么区别？

这题特别容易答浅。

很多人会说：

  • Function Call 是调用函数
  • MCP 是协议

不能说错，但太薄了。

你真正需要讲明白的是：

这两者解决的问题根本不在同一层。

Function Call 解决的，本质上是：

模型在当前对话里，如何用一种结构化格式表达“我想调用哪个工具、传什么参数”。

它偏向的是单次决策接口。

而 MCP 解决的，更像是：

一个客户端如何发现外部能力、读取能力描述、获取上下文资源、注册提示模板，并把这些能力持续提供给模型使用。

它偏向的是系统级能力接入协议。

可以粗暴理解成这样：

  • Function Call 更像“模型这一轮想干什么”
  • MCP 更像“这个系统里到底接了哪些能力，以及这些能力怎么被规范地暴露出来”

再具体一点：

  • Function Call 更关注一次调用的 name + arguments
  • MCP 更关注工具、资源、Prompt、采样能力这些对象如何被统一发现和管理

所以很多成熟系统里，这两者并不是替代关系，而是上下游关系：

MCP 负责把外部能力标准化暴露出来
  -> 客户端读取这些能力
  -> 再把适合当前任务的能力交给模型
  -> 模型通过 Function Call 或类似机制决定具体调用

这就像什么？

  • MCP 像在搭建商场
  • Function Call 像用户走进商场后，决定这一次具体买什么

面试里比较加分的一句话是：

Function Call 解决的是“调用表达问题”，MCP 解决的是“能力接入与上下文协作问题”。前者更像模型推理链中的一个动作，后者更像整个 AI 系统的接口标准层。

这句话一出来，层次感就拉开了。

🧭 第三问：为什么大家突然开始重视 MCP？

如果一个技术概念突然变热，背后通常都不是因为它名字好听，而是因为旧方案开始扛不住了。

MCP 也是一样。

过去很多 AI 应用，工具少、场景单一，所以大家更喜欢直接写：

  • 一份工具注册表
  • 一套 JSON Schema
  • 一层业务路由
  • 一段系统提示词

跑 Demo 很快，做 PoC 也没问题。

但真正往企业场景走，就会遇到 4 个非常现实的问题。

1. 工具越来越多，接入成本越来越高

每个团队都在重复造一套：

  • 工具描述格式
  • 参数规范
  • 返回值约定
  • 权限校验
  • 会话上下文拼装

这本质上是在重复写胶水。

2. 客户端越来越多，兼容越来越难

今天你接的是 Web Copilot，明天接 IDE 插件，后天又要接桌面助手。

如果没有统一协议，每多一个客户端，基本就要多写一套适配层。

3. 上下文来源越来越复杂

AI 不再只看聊天记录，它还要看：

  • 本地文件
  • 代码仓库
  • 数据库结果
  • 网页内容
  • 企业文档
  • 运行时状态

这时候问题就不是“能不能拿到数据”，而是“怎么把这些上下文标准化交给模型”。

4. 安全和治理开始压过 Demo 体验

Demo 阶段最关心的是“能不能跑起来”。

生产阶段更关心的是：

  • 谁能调用这个工具
  • 谁能看到这个资源
  • 工具返回的数据会不会泄露
  • 服务升级会不会把客户端搞崩

所以 MCP 火起来，不是因为大家突然爱上协议设计，而是因为 AI 应用发展到这个阶段后，工程秩序开始比概念新鲜更重要了。

一句很像一线经验总结的话是：

当 AI 系统里的能力数量和接入方数量同时增长时，最大的成本往往不在模型本身，而在能力编排、上下文传递和接口治理。MCP 的价值，正是在这个阶段开始显现出来。

📦 第四问：MCP Server 暴露的到底是什么？为什么不只是工具？

这是很多人最容易忽略的一点。

一提到 MCP，很多人脑子里只有“工具调用”。

但如果你真的去理解它的设计思路，你会发现它想标准化的，不止是工具。

更完整地看，它关注的是几类不同能力对象。

1. Tools：可执行动作

这类最好理解，比如：

  • 搜索文档
  • 查询数据库
  • 创建工单
  • 读取 Git 提交
  • 发送消息

它强调的是“做一件事”。

2. Resources：可读取上下文

比如：

  • 一个文件
  • 一段日志
  • 一个文档页面
  • 某个表的查询结果
  • 某个 URI 对应的内容

它强调的是“给模型看什么”。

3. Prompts：可复用提示模板

比如：

  • 代码审查 Prompt
  • SQL 分析 Prompt
  • 面试辅导 Prompt
  • 某个垂直场景的结构化任务模板

它强调的是“怎么组织模型思考”。

这三个东西混在一起看，你就会发现 MCP 想做的，其实不只是“工具市场”，而是一种：

把动作、数据、提示三类能力统一纳入 AI 宿主可发现、可消费、可治理的标准结构。

这点很关键。

因为很多时候，AI 系统的瓶颈根本不是“工具太少”，而是：

  • 模型拿不到对的上下文
  • 不知道该用哪套提示模板
  • 工具和资源之间缺乏统一视图

所以一个成熟回答应该是：

MCP Server 暴露的不只是 callable tools，它更像是一个能力提供方，向外标准化提供可执行动作、可读取资源以及可复用 Prompt。这样客户端不需要为每一类能力单独发明一套接入协议。

这就比“它就是工具调用协议”高了不止一层。

🔒 第五问：MCP 真接进生产，难点到底在哪？

这题一旦答得好，面试官基本就知道你不只是看过概念图。

因为所有协议，Demo 都好看，真正难的是上生产。

MCP 真落地以后，通常至少要面对 5 类问题。

1. 权限边界怎么划？

模型能看到什么、能调用什么，绝对不能只靠提示词约束。

真正要靠的是宿主系统的控制能力，比如：

  • 用户身份透传
  • 工具级授权
  • 资源级访问控制
  • 敏感字段脱敏
  • 审计日志

如果这层没有做好，工具越多，风险越大。

2. 能力描述怎么长期维护？

工具不是接完就结束了。

只要参数、返回值、业务语义变了，描述就可能失真。

一旦描述失真，会发生什么？

  • 模型误选工具
  • 参数构造错误
  • 调用成功但结果不可用
  • Prompt 对工具的理解逐渐偏移

所以能力文档本身，也是一种需要治理的资产。

3. 稳定性和超时怎么兜底？

模型不是直接调用内存里的函数，而是在和外部服务打交道。

那就绕不开这些老问题：

  • 超时
  • 重试
  • 降级
  • 熔断
  • 幂等
  • 缓存

很多 AI 团队前期容易忽略这点，最后发现不是模型不行，而是工具链太脆。

4. 调试链路怎么打通？

一条调用失败，到底错在哪？

可能错在：

  • 模型理解错意图
  • 选错工具
  • 参数拼错
  • 服务端描述不清
  • 工具执行报错
  • 返回结果太脏
  • 模型对结果再次误解

如果你没有可观测性，排查会极其痛苦。

真正成熟的系统，通常会留这些东西：

  • 工具选择日志
  • 参数校验日志
  • 服务端执行日志
  • 资源读取轨迹
  • 最终答案引用链路

5. 版本兼容怎么做？

客户端、服务端、模型适配层，三边只要有一边升级，就可能出现兼容问题。

比如：

  • 参数 schema 变了
  • 某类资源 URI 规则变了
  • Prompt 模板入参变了
  • 客户端只认识旧字段

这也是为什么越往后做，你越会发现：

MCP 不是“接一个协议”的工作，而是“建设一套 AI 能力治理体系”的开始。

面试里比较有分量的一句话可以这样说：

MCP 上生产后的难点，不在于把 server 跑起来，而在于如何把权限、稳定性、观测性和兼容性一起做进去。否则它只是统一了接入方式，却没有真正统一系统质量。

🎤 面试里的高分收尾话术

如果面试官从 MCP 一路追到了 Function Call、工具治理、上下文管理、生产稳定性，你最后可以用这段话收住：

我理解 MCP 不是一个单纯的“工具调用新名词”，它更像 AI 系统里的接口标准层。它解决的重点不是模型怎么思考，而是模型宿主如何以统一方式发现、组织和治理外部能力。
如果说 Function Call 主要解决的是模型如何表达一次调用意图，那 MCP 解决的就是工具、资源、Prompt 这些能力如何标准化接入，并在不同客户端和不同服务之间复用。
所以它真正的价值，不在 Demo 演示里，而在系统规模变大之后，能不能把复杂度、接入成本和治理成本压下来。

这段话的好处在于，它会让面试官感觉你看见的是“架构层问题”，不是只会背几个 SDK 概念。

✅ 为什么现在大厂和团队越来越爱聊 MCP？

因为 AI 应用已经开始进入下一阶段了。

前一阶段，大家比的是：

  • 谁先把模型接上
  • 谁先把工具跑通
  • 谁先把聊天效果做出来

而现在越来越多团队比的是：

  • 谁能把能力接得更快
  • 谁能让多个客户端复用同一套能力层
  • 谁能把权限、审计、稳定性一起做好
  • 谁能把一个 AI Demo 长成真正的产品基础设施

表面上，MCP 聊的是协议。

实际上，它考的是：

  • 你有没有系统化看待 AI 工程
  • 你有没有意识到上下文也是基础设施
  • 你知不知道工具接入最难的不是“能调用”，而是“能治理”

  • 你能不能把模型能力从一次性项目，变成可复用平台能力

    END

写在最后：

最近私信问我面试题的小伙伴实在太多了，一个个回有点回不过来。

我大家公认最容易挂的 AI/Go/Java 面试坑点 整理成了一份 PDF 文档。里面不光有题，还有解题思路和避坑指南。

想要的同学，直接加我微信wangzhongyang1993，或者关注并私信我 【面试】，我统一发给大家。

标签: none

添加新评论