MCP 模型上下文协议 Model Context Protocol
所属：01-fundamentals / 04-agent-architecture
面试权重：★★★
来源：通用领域知识（B站「AI Agent 八股」合集高频）；未做一手考证
相关项目：QueWI —— MCP 工具链接入 → 见02-interview/projects/quewi-chatbot.md
一句话#
MCP 是一套把「LLM 应用 ↔ 外部工具与数据源」的接入方式标准化的开放协议，2024 年由 Anthropic 提出；它把 M×N 的适配工作收敛成 M+N，让工具提供方实现一次、所有支持 MCP 的客户端都能用。
为什么重要（面试角度）#
MCP 是 2025–2026 年 agent 工程里最热的关键词之一，但它也是最容易被答成营销话术的题。面试官想听的恰恰是反面：
- 你知不知道 MCP 到底解决了什么、没解决什么
- 说不说得清 host / client / server 三层，以及 tools / resources / prompts 三种原语的区别
- 知不知道**「标准化接入」和「选对工具」是两件事** —— MCP 解决前者，一点忙都不帮后者
- 有没有真实的落地经验：鉴权、server 粒度、版本兼容、多 server 的工具爆炸
QueWI 里你用 MCP 接了工具链，答题必须落到「为什么用它」「哪里不好用」。
核心内容#
它解决的问题：M×N 爆炸#
没有协议时，接入成本是乘法：
M 个 LLM 应用 × N 个外部系统（数据库、SaaS、内部 API）
→ 每个应用都要为每个系统写一遍适配（认证、参数映射、错误处理、返回值整形）
→ M × N 份适配代码，且每改一处都要改多个地方有了统一协议，成本变成加法：
每个应用实现一个 MCP client（M 份）
每个系统实现一个 MCP server（N 份）
→ M + N，两两之间自动互通这与驱动模型 / LSP 的思路完全一样：把「一对一适配」变成「大家都遵守一个接口」。这个类比在面试里很好用 —— 它直接说明了收益的规模效应：M 和 N 越大，收益越大；如果只有一个应用接一个工具，MCP 反而是多余的抽象。
三层架构：host / client / server#
| 角色 | 是什么 | 职责 |
|---|---|---|
| Host | 用户直接使用的 LLM 应用（IDE、聊天客户端、你的 agent 平台） | 拥有模型、决定策略、决定暴露哪些能力给模型、管权限与用户同意 |
| Client | host 内部的连接器，与一个 server 一对一 | 维护与某个 server 的连接、做能力协商、转发请求 |
| Server | 提供能力的轻量服务 | 暴露 tools / resources / prompts，不一定有独立进程 |
关键点：一个 host 可以同时挂多个 client，从而同时连多个 server。所以「agent 平台接入了一堆 MCP server」在架构上就是 host 持有 N 个 client。
server 通常是能力包装层，不是业务逻辑的所在。 它把已有的 API 包成 MCP 语义 —— 这也是为什么写一个 MCP server 往往是「薄适配器」，含金量在接口设计（暴露哪些工具、参数怎么设计、粒度多粗）而不是在实现。
三种原语：tools / resources / prompts#
这是 MCP 设计的核心，也是面试高频考点。三者的区别在于由谁控制：
| 原语 | 谁控制 | 语义 | 类比 |
|---|---|---|---|
| Tools | 模型 | 可执行的动作，可能产生副作用 | POST / 函数调用 |
| Resources | 应用 / 用户 | 可读取的上下文数据，只读 | GET / 文件 |
| Prompts | 用户 | 预置的提示模板，供用户显式选用 | 斜杠命令 / 模板 |
为什么这个区分重要：因为控制权决定了安全模型。
- tools 是模型自主发起的 → 天然是风险面，需要审批、权限、审计（见
tool-use.md、human-in-the-loop.md） - resources 是应用决定读什么 → 更像「把资料放进上下文」，风险低但需要访问控制
- prompts 是用户显式触发 → 相当于可复用的工作流入口
面试里能主动说出「这三者的区分本质是控制权与信任边界」，比背定义高一个层次。
注：MCP 的规范里除了 server 侧这三类能力，也有 client 侧的能力（例如让 server 反向请求 host 做模型补全、声明文件系统根目录、向用户追问等）。这些在实践中用得少，面试提到「MCP 有双向能力」即可，不必展开细节 —— 规范的版本在演进，具体能力集以你实际使用的规范版本为准。
传输（transport）#
两种主流形态，区别是进程边界：
| 传输 | 形态 | 适用 |
|---|---|---|
| stdio | host 把 server 作为子进程拉起，通过标准输入输出通信 | 本地工具、开发者机器上的 server。无网络暴露面，部署简单 |
| HTTP（可流式） | server 作为远端服务，通过 HTTP 通信，支持流式返回 | 远程 / 共享 / 多租户的 server，需要鉴权与伸缩 |
注意规范的演进：早期远程传输用过 HTTP + SSE 的形态，后来规范调整为可流式的 HTTP 传输。这是一个版本相关的问题 —— 面试时应该说「stdio 与 HTTP 两类，远端形态在规范演进中调整过」，而不要去背某个具体的传输名，除非你确认过当前规范。
选型要点：
- stdio 简单但天然单机：进程随 host 起停，无法共享、无法独立伸缩
- 远程 server 才能被多个 host / 多人共享，但必须解决鉴权、多租户隔离、限流与审计 —— 这些是协议层不提供、要你自己做的
- 从 stdio 迁移到远程，最大的工作量通常不在协议，而在认证与权限模型
与 function calling 的关系（最重要的区分）#
MCP 和 function calling 不是竞争关系，是不同层次的东西：
MCP 是「接入层」：统一怎么发现、连接、描述、调用外部能力
Function calling 是「模型层」：模型如何表达「我要调用某个工具」真实链路是：host 从 MCP server 拉取工具清单（含 JSON Schema）→ 转成模型的 function calling 定义注入上下文 → 模型输出调用 → host 执行（可能是转发给 server）→ 结果回灌。
所以「有了 MCP 就不需要 function calling」是错的；「MCP 让 agent 更聪明」也是错的。MCP 只是把工具接进来的方式标准化了。
MCP 不解决什么（重点）#
面试里这一节最能拉开差距：
| MCP 不解决 | 为什么 |
|---|---|
| 工具选择准确率 | 工具描述质量、工具数量的影响、模型的选择能力 —— 全都不在协议范围内（见 tool-use.md） |
| 工具描述质量 | 协议规定了描述的格式，没规定描述的内容。写得烂的 server 一样让模型选错 |
| 工具爆炸 | 接得越容易，工具越多。多 server 挂上去后，「先选哪个 server 再选哪个工具」的问题反而更严重 |
| 鉴权与权限策略 | 协议给了连接与能力协商的框架，授权模型、多租户隔离、最小权限是应用自己的事 |
| prompt injection | 工具返回值里的恶意指令仍会被模型读到。MCP 不提供隔离 |
| 延迟与成本 | server 多一跳、多一个进程，协议不优化性能 |
| 可靠性与状态 | server 挂了怎么办、重试语义、幂等 —— 协议不替你设计 |
| 评测 | 没有「MCP 让效果提升多少」这回事，效果取决于工具与描述本身 |
一句话总结（可以直接说出口）：MCP 解决的是「接得麻烦」，不是「用得对」。工具的接入标准化和模型的选择准确性是两个正交的问题。
这一层在上面还有几层。 面试里有一类题会把 MCP / Prompt / CLI / Skill / Harness 摆在一起问「什么关系」—— 那考的就是「每样东西在哪一层」。一句话是：Harness 评测 Agent，Agent 调用 Skill，Skill 通过 MCP 调用 CLI 等底层工具，Prompt 贯穿全程。 本文只负责 MCP 这一层；完整的层次图、Tool 与 Skill 的分界线、以及「训练 harness ≠ 生产 harness」这个独立失效模式，见
08-agent-stack.md。
工程实践要点#
- server 粒度：按领域拆（一个业务系统一个 server），不要按函数拆（一个 API 一个 server）。粒度太细 → server 数量爆炸、连接管理复杂；太粗 → 一个 server 里几十个工具，选择准确率又掉。
- 工具设计就是 API 设计：暴露
get_customer(id)而不是execute_sql(query)。窄接口 = 可控权限 = 可审计。 - 鉴权：远程 server 常见做法是走标准的 OAuth 类授权流程，把用户身份与授权范围传下去，而不是用一个全局服务账号 —— 否则多租户下权限会串。具体授权流程与规范版本相关，落地时以实际使用的规范与实现为准。
- 版本与兼容：协议在演进，server 与 host 的能力需要协商。生产上要锁定规范版本并做兼容测试，不能假设「都是 MCP 就能互通」。
- 可观测性：多一层 server 就多一个失败点。每一次调用都要能从 host 追到 server、追到下游系统。否则线上排障时你不知道是模型选错了工具，还是工具本身挂了。
- 失败语义：server 不可用时的降级 —— 是把这个工具从清单里摘掉，还是让调用返回错误让模型改策略？这两者对 agent 的行为影响完全不同。
常见面试问法#
Q：MCP 解决了什么问题？ A：把 LLM 应用与外部工具/数据源的接入标准化，把 M×N 的适配工作收敛为 M+N。工具提供方实现一次 server，所有支持 MCP 的 host 都能接。这和驱动程序、LSP 是同一类思路。收益随 M、N 增长。
Q：MCP 的架构说一下。 A：host（用户使用的 LLM 应用，拥有模型与策略）/ client（host 内与单个 server 一对一的连接器）/ server（暴露能力）。一个 host 可以挂多个 client 连多个 server。能力形态三类：tools（模型控制，动作）、resources（应用控制，只读数据）、prompts（用户控制，模板），其区分本质是控制权与信任边界。
Q：MCP 和 function calling 什么关系？ A：不同层次。MCP 是接入层（发现、连接、描述、调用外部能力的标准化方式），function calling 是模型层的表达机制（模型如何输出一个调用请求）。实际链路是 host 从 server 拉到工具定义，转成 function calling 的 schema 注入给模型。不是替代关系。
Q：用了 MCP 之后工具选择准确率会提升吗？
A：不会。这是这道题最关键的澄清：MCP 解决接入标准化，不解决选择准确性。后者取决于工具描述写得怎么样、工具数量有多少、以及模型的能力 —— 而 MCP 恰恰让接工具变容易了，所以工具数量可能更多，选择问题反而可能更严重。解决办法仍然是 tool-use.md 里的那套：精简合并工具、写清「何时用/何时不用」、分组分层、工具检索、子 agent 隔离工具集。
Q：怎么把 MCP 工具链落地到生产？ A：四个要点：① server 按领域拆而不是按函数拆；② 工具接口窄而有语义（不要暴露通用的「执行任意查询」）；③ 远程 server 必须做鉴权与多租户隔离，不能用全局账号；④ 加可观测性，能区分「模型选错工具」和「工具本身失败」，并设计 server 不可用时的降级策略。
易错点#
- ❌ 说「MCP 让 agent 更聪明 / 效果更好」—— 它只解决接入。
- ❌ 说 MCP 会取代 function calling —— 两者是不同层次，MCP 的工具最终仍以 function calling 的形式给模型。
- ❌ 认为用了 MCP 就自动解决了工具选择问题。
- ❌ 把 MCP 说成「一个能连数据库的框架」—— 它是协议，不是运行时也不是工具库。
- ❌ 忽略鉴权与多租户：远程 server 用全局服务账号是常见且严重的错误。
- ❌ 背具体的传输名和规范版本号 —— 协议在演进，说「stdio 与 HTTP 两类，远端形态调整过」更安全。
- ❌ 把 tools / resources / prompts 混为一谈，说不清控制权差异。
- ❌ 认为 server 越多越好：server 数量增长会带来新的「先选 server 再选工具」的层级选择问题。
自测#
1. MCP 的 M×N → M+N 具体指什么？什么情况下 MCP 反而不划算？
答案
M 指 LLM 应用（host）的数量，N 指外部系统（工具/数据源）的数量。没有统一协议时，每个应用都要为每个系统写一套适配（认证、参数映射、错误处理、返回值整形），总工作量是 M×N。有了 MCP，每个应用实现一次 client、每个系统实现一次 server，总工作量降为 M+N，任意组合自动互通。不划算的情况：M 和 N 都很小（例如只有一个应用接一个内部 API）—— 这时引入协议层只是增加了一层间接和部署复杂度，收益不足以覆盖成本。收益随 M、N 的规模增长。
2. tools、resources、prompts 三者的区别是什么？为什么说这个区分本质是「控制权」？
答案
tools 是模型可以自主发起的可执行动作，可能有副作用（类比 POST）；resources 是可读取的上下文数据，只读，由应用或用户决定读哪个（类比 GET）；prompts 是预置的提示模板，由用户显式选用触发（类比斜杠命令）。区别的本质在于谁发起、谁信任：模型自主发起的动作构成风险面，因此需要审批、权限与审计；应用决定读取的数据需要访问控制但风险较低；用户显式触发的模板相当于可复用的工作流入口。这个区分直接对应了不同的安全模型，所以是关键设计而不是术语游戏。
3. 面试官问「我们用 MCP 把工具接进来了，为什么模型还是老选错工具」，你怎么答？
答案
要点是澄清 MCP 的边界：MCP 标准化的是接入方式（怎么发现、连接、描述、调用），而模型选错工具取决于工具描述的质量、工具的数量与相似度、以及模型自身的选择能力 —— 这三项都不在协议范围内。MCP 甚至可能让问题变严重，因为它把接工具的门槛降低了，工具会更多，而且多个 server 还引入了新的层级选择问题。解法回到 tool use 那一套：合并高度相似的工具、在描述里写清「何时用/何时不用」、收敛枚举与参数说明、分组分层或做工具检索、以及用子 agent 做工具集隔离。如果工具集稳定且量大，还可以在自有工具调用数据上做 SFT。
4. 从 stdio 的本地 server 迁到远程 server，主要工作量和新增风险在哪？
答案
工作量的大头通常不在协议本身，而在认证与权限：需要设计授权流程，让 server 能识别调用方是谁、被允许访问哪些数据，而不是用一个全局服务账号（那会导致多租户权限串号）。新增风险包括：网络暴露面（需要限流、防滥用）、server 成为共享故障点、延迟增加一跳、以及协议版本兼容问题（server 与 host 的能力需要协商，不能假设「都是 MCP 就能互通」）。工程上还要保证可观测性，能区分「模型选错工具」与「server 侧失败」，并为 server 不可用设计降级策略。
5. 为什么说 MCP 不解决 prompt injection？它和工具安全的关系是什么？
答案
MCP 定义的是连接、发现与调用的标准化方式，不提供内容隔离机制。工具返回值仍然会进入模型上下文，而模型无法可靠区分数据与指令 —— 攻击者只要污染 agent 会读到的内容（网页、邮件、数据库字段），就能构成间接 prompt injection，这一点不因使用 MCP 而改变。MCP 对安全的正向作用只是让权限边界更清晰（每个 server / 每个 tool 是显式的权限单元，便于做最小权限与审批），但协议本身不替你做授权策略、出口限制或人工审批。