什么是 MCP（模型上下文协议）？它解决了什么问题？

- - [一、它解决了什么核心问题？](#一、它解决了什么核心问题？)
  - [二、 MCP 与 Function Calling 的区别](#二、 MCP 与 Function Calling 的区别)
  - [三、存在的局限性（面试官提到的考点）](#三、存在的局限性（面试官提到的考点）)

简单来说，MCP (Model Context Protocol) 是由 Anthropic 公司提出的一种开放标准协议，旨在为 AI 模型（如 Claude、GPT）与外部数据源、工具之间搭建一座"通用桥梁"。

你可以把它想象成 AI 界的 "USB 接口"：在 USB 出现之前，鼠标、键盘、打印机都有各自的接口；而有了 USB，任何设备只要符合标准，插上电脑就能直接使用。MCP 的目标就是让 AI 能够"即插即用"地访问你的数据库、Slack、GitHub 或本地文件。

在 MCP 出现之前，AI 开发者面临着严重的碎片化 和集成成本高的问题：

重复造轮子（碎片化）
- 问题：如果 Cursor 想读取你的 GitHub 仓库，它得写一套代码；如果 Claude Desktop 也想读，它又得重写一遍。每个 AI 工具都在为同一个数据源重复开发连接器。
- 解决：MCP 提供了一套标准，开发者只需写一次"MCP Server"（比如一个 GitHub MCP Server），任何支持 MCP 的 AI 客户端（Host）就都能直接调用它。
上下文管理的混乱
- 问题：传统方式下，给 AI 提供外部信息通常靠手动复制粘贴或者硬编码的 API 调用，难以管理海量且动态的数据。
- 解决：MCP 定义了三种核心交互方式：Resources （让 AI 读取静态数据）、Prompts （提供预定义的指令模板）、Tools（让 AI 执行动态操作，如查天气、运行代码）。
模型与工具的耦合
- 问题：以前 AI 的能力往往绑定在特定的平台上。
- 解决：通过 MCP，数据源（Server）与 AI 客户端（Host）实现了完全解耦。你的数据留在你的服务器上，只有在需要时通过受控的协议暴露给模型。

根据你之前的面试复盘，这也是面试官非常关注的点：

复用性：Function Calling 通常是为特定任务、在特定代码里写死的函数；而 MCP 是独立的服务，一次注册，所有支持该协议的 AI 都能复用。
复杂度：Function Calling 适合简单的业务逻辑；MCP 支持更复杂的上下文协议，能够承载更大规模的工具集。
网络通信：Function Calling 往往在代码内部定义；MCP 则明确涉及 Client 与 Server 之间的网络请求（如通过 JSON-RPC）。

正如你在小红书一面中所讨论的，MCP 并不是完美的，它目前还存在以下挑战：

上下文污染（Context Bloat）：如果你接入了上百个 MCP Server，它们的 Schema（描述信息）都会塞进 AI 的上下文窗口，可能导致有效信息被淹没。
状态管理与观测性差：目前对于 MCP 调用的中间状态监控、错误回溯还比较原始。
安全性与网络稳定性：由于涉及外部 RPC 调用，网络抖动和数据隐私保护是实际落地中的难题。

一句话总结：

MCP 解决了 AI 访问外部世界的"协议不统一"问题，让 AI 从一个只能"空谈"的大脑，变成了拥有无数"插槽"的超级工作站。

既然你之前在面试中聊到了 MCP 的缺点，你觉得在实际的 Multi-Agent（多智能体） 场景下，是让每个 Agent 都挂载 MCP，还是由一个专门的"调度 Agent"统一管理 MCP 更好？