高频面试题

MCP 协议是什么？它在 AI Agent 系统中解决了什么问题？

MCP 的重点不是“让模型会调用工具”，而是把 Agent 应用和工具 / 数据源之间的接入方式标准化，避免每个应用和每个工具都重新写一遍适配。

适合阶段：Agent 工程 / 工具生态设计面核心能力：Tool Integration · Context Access · Protocol Boundary · Security

面试官角度分析，想考什么

• MCP 是什么？解决了什么问题？
  考你能否把它说成 Agent 接工具和数据源的标准协议，用来消灭 N×M 适配。

• 它和 Function Calling 是替代关系吗？
  考分层：Function Calling 是模型怎么表达调用意图，MCP 是工具怎么标准化接入。

• 引入 MCP 的风险是什么？
  考工程边界：Server 信任、权限、prompt injection、工具副作用，协议本身不会自动变安全。

可直接抄走的 30 秒参考答案

MCP 是 Model Context Protocol，本质上是 Agent 应用和外部工具、数据源之间的标准连接协议。它解决的是工具集成的 N×M 问题：以前每个 Agent 应用都要为每个工具单独写适配，现在工具方实现一个 MCP Server，支持 MCP 的 Host 通过 Client 就能发现工具、读取资源、调用能力。它和 Function Calling 不冲突：Function Calling 是模型 API 层表达“我想调哪个工具”，MCP 是工具接入层负责“这个工具怎么被发现、连接和复用”。生产里还要配权限、沙箱、审计和 prompt injection 防护，协议本身不会自动让工具变安全。

面试回答详解，知其所以然

这道题最容易答浅成“MCP 就是 AI 的 USB-C”。这个比喻有用，但面试里不能停在这里，要继续讲清：MCP 标准化的是 Agent 应用和工具 / 数据源之间的连接层，不是模型 API 本身，也不是 Agent 与 Agent 的协作协议。

1. MCP 的基本定义

MCP 全称是 Model Context Protocol，由 Anthropic 在 2024 年发布。它定义了一套开放协议，让 LLM 应用可以用统一方式连接外部能力，例如文件系统、数据库、代码仓库、搜索服务、SaaS API、内部业务系统和可复用 prompt。

可以把它理解成：

LLM 应用 / Agent Host -> MCP Client -> MCP Server -> 外部工具 / 数据源

MCP Server 暴露能力，Host 内的 MCP Client 建立连接、发现能力并调用。这样工具提供方不需要为 Claude、Cursor、VS Code、Cline 或其他 Agent 框架分别写插件；Host 也不需要为每个工具维护一套私有 SDK 适配。

2. 它解决的是工具接入的 N×M 问题

没有 MCP 时，工具生态很容易变成：

N 个 Agent 应用 × M 个工具 / 数据源 = N×M 个适配层

比如一个团队想把 GitHub、Slack、Postgres、Linear、浏览器和内部 CRM 接入多个 Agent 产品，每个产品都要理解各工具的认证、schema、分页、错误码、权限和返回格式。工具多了以后，集成成本会爆炸，也很难统一审计。

MCP 的解法是把双方解耦：

• 工具方：实现一个 MCP Server，声明自己有哪些 tools、resources、prompts。
• 应用方：实现 MCP Client 能力，按协议发现和调用 server。
• 协议层：用统一的消息、生命周期、能力协商和传输方式连接双方。

这和 Language Server Protocol 的思路很像：编辑器不用为每门语言单独重写全部智能能力，语言实现一个 server，编辑器实现一个 client。

3. MCP 补齐的是 Agent 的上下文和行动能力

Agent 要完成真实任务，只靠模型参数里的知识不够。它需要读取环境、调用工具、拿到反馈，再继续推进。

MCP 让这些能力有了标准入口：

• Tools：让模型可通过 Host 间接执行动作，例如查 issue、跑查询、发请求、创建记录。
• Resources：让 Host 或用户把外部上下文读进来，例如文件、数据库记录、文档片段。
• Prompts：让 Server 提供可复用的任务模板或工作流提示。

所以 MCP 不只是“工具调用”。它还关心上下文如何被发现、读取、订阅和呈现给模型。对 Agent 来说，这相当于把外部世界接入到了可控的运行时里。

4. MCP 和 Function Calling 是上下游关系

Function Calling / Tool Calling 通常发生在 LLM API 层：Host 把工具 schema 传给模型，模型返回要调用哪个函数和参数。

MCP 发生在 Host 和工具服务之间：Host 从 MCP Server 拉取工具定义，再把这些定义转成模型可理解的 tool schema；模型产生 tool call 后，Host 再把调用路由到对应 MCP Server。

两者的关系可以这样说：

• Function Calling：模型怎么表达“我要调用这个工具”。
• MCP：工具怎么被应用发现、连接、隔离、调用和复用。
• Agent Runtime：什么时候调用、调用后如何更新状态、是否继续下一轮。

所以 MCP 不是 Function Calling 的替代品，而是让工具生态跨应用复用的一层标准。

5. MCP 也带来新的生产边界

MCP 降低了集成成本，但不等于天然安全。一个 MCP Server 可能访问本地文件、网络、企业系统或用户账号，一旦信任边界没设好，风险比普通文本生成更高。

生产落地要特别注意：

• Server 来源可信，依赖和发布链路要审计。
• OAuth scope、文件系统挂载和网络访问要最小化。
• 高风险工具要有人类确认、幂等控制和操作审计。
• Resource 内容可能携带间接 prompt injection，不能无脑塞进上下文。
• 远程 MCP Server 要考虑身份认证、会话隔离、租户隔离和日志脱敏。
• Host 不能盲信工具描述，工具 annotations 只能作为提示，不能当安全证明。

成熟回答要承认：MCP 解决的是接入标准化，不是把权限、安全、成本和可靠性问题全部自动消掉。它降低了集成成本，也把“信任哪些工具”这个问题推到了 Host 和企业治理层。

面试官追问3个问题

追问一：MCP 和 Function Calling 有什么区别？

• 考察点：是否有协议分层意识。
• 回答方向：Function Calling 是模型 API 层的工具调用表达方式；MCP 是 Host 与外部工具 / 数据源之间的连接协议。实际链路是 Host 通过 MCP 获取工具定义，再转成 Function Calling schema 给模型，模型返回调用意图后由 Host 通过 MCP 执行。

追问二：MCP 为什么不是普通 REST API？

• 考察点：是否理解能力发现、生命周期和上下文接入。
• 回答方向：REST API 只定义某个服务的 HTTP 接口，MCP 还定义了初始化、能力协商、tools/resources/prompts、通知、会话和多种 transport。MCP Server 内部可以调用 REST API，但 MCP 对 Host 暴露的是更适合 Agent 工具生态的抽象。

追问三：MCP 会不会让工具调用更安全？

• 考察点：是否会把协议标准化和安全保障混为一谈。
• 回答方向：MCP 有利于统一接入、审计和权限框架，但协议本身不能证明 server 可信。生产里仍要做 server 来源审计、最小权限、沙箱、用户确认、日志追踪和资源内容的 prompt injection 防护。

扩展知识

为什么 MCP 常被类比为 LSP

LSP 解决的是“编辑器 × 编程语言”的组合爆炸。MCP 解决的是“LLM 应用 × 工具 / 数据源”的组合爆炸。

没有标准：每个应用分别适配每个工具
有 MCP：每个工具实现 Server，每个应用实现 Client

这个类比能帮助面试官判断你是否理解协议的生态价值：MCP 的意义不在于某个工具调用格式更漂亮，而在于把工具供应方和 Agent 应用方解耦。

MCP 的三个 primitive

MCP Server 不只暴露函数，通常可以暴露三类能力：

• Tool：模型可选择调用的动作，适合有明确输入输出、可能产生副作用的操作。
• Resource：可读取的上下文数据，适合文件、文档、数据库记录、日志片段等。
• Prompt：可复用的提示模板或工作流入口，适合把领域经验封装给 Host 使用。

面试时最好别把所有能力都说成 tool。Tool、Resource、Prompt 的拆分，正是 MCP 区别于普通函数列表的地方。

MCP 不负责 Agent 之间协作

MCP 的通信对象是：

Agent Host / LLM 应用 <-> 工具或上下文 Server

如果问题是“一个 Agent 如何发现、委托和协作另一个 Agent”，那更接近 A2A 这类 Agent-to-Agent 协议。一个多 Agent 系统可以同时使用两层：每个 Agent 用 MCP 接工具，Agent 之间用 A2A 通信。