MCP（Model Context Protocol，模型上下文协议）是 Anthropic（Claude 的母公司）于 2024 年底推出的一种开放标准协议 。你可以把它理解为 "AI 应用的 USB-C 接口"。
在 MCP 出现之前，如果你想让 AI 连接数据库、查天气、操作本地文件，需要为每一个 工具单独写胶水代码（即 LangChain 中的 @tool 函数）。MCP 的出现，就是要把这些零散的接口统一起来，实现"一次编写，随处调用"。
🧠 1. 一句话核心定义
MCP 是一个标准化协议，用于让 AI 模型（如 Claude、GPT）通过统一的接口动态发现和调用外部工具、数据源（如数据库、API、本地文件），而无需为每个工具编写定制代码。
🛠️ 2. MCP 解决了什么痛点？（为什么需要它？）
| 传统方式（无 MCP） | MCP 方式 |
|---|---|
用 LangChain 时，每接入一个 API（比如飞书、Slack、数据库），都要写一个 @tool 函数，并手动维护参数 schema。 |
工具提供方直接启动一个 MCP Server，通过协议标准暴露能力。Agent 只需连接该 Server，就能自动获取所有工具列表并调用。 |
| 切换模型（比如从 GPT 切到 Claude）时，工具代码可能需要重写，因为各家的 Function Calling 格式略有不同。 | 协议被主流模型厂商（Anthropic、OpenAI 等）共同支持，一次开发，所有兼容 MCP 的客户端都能用。 |
| 工具和 Agent 紧耦合，修改工具逻辑需要重启整个 Agent 服务。 | 工具以独立进程（Server）运行，Agent（Client）动态连接，支持热插拔。 |
🧩 3. MCP 的核心架构（三个角色）
在 MCP 体系中，有三个关键角色：
- MCP Host（主机） ：即你的 Agent 应用（比如 LangGraph 智能体）。它是发起请求的一方，需要调用工具来完成任务。
- MCP Client（客户端） ：集成在 Host 内部的协议处理层。负责与 MCP Server 通信，负责发送请求和接收工具响应。在代码中，我们通常用
MultiServerMCPClient来充当这个角色。 - MCP Server（服务端） ：暴露工具 的服务进程。它将具体的功能（如"查询 MySQL"、"发送邮件"）封装成标准化的 Tool，并等待 Client 连接。在你之前的代码中，
math_server.py和weather_server.py就是两个 MCP Server。
📦 4. MCP Server 能提供什么？（不仅仅是工具）
MCP 协议定义的资源非常丰富，而不仅仅是"工具调用"：
- Tools（工具） ：可执行的函数（如
get_weather），AI 决定何时调用。 - Resources（资源） ：类似文件或只读数据（如
file:///docs/report.pdf），AI 可以读取它们作为上下文。 - Prompts（提示模板）：预定义的提示词模板，Client 端可以直接拉取使用。
但在咱们之前的实战中，最主要接触的还是 Tools。
⚙️ 5. 技术原理（它是怎么通信的？）
MCP 底层基于 JSON-RPC 2.0，支持两种传输方式：
- stdio（标准输入输出） ：通过子进程通信。适合本地工具（如你写的
math_server.py）。Client 启动子进程，通过 stdin/stdout 传递 JSON 消息。 - SSE（Server-Sent Events）：基于 HTTP 长连接。适合远程服务（如你从魔搭社区获取的 12306 MCP 服务）。
通信流程大致是：
- Client 发起
initialize握手。 - Client 请求
tools/list，Server 返回工具列表（名称、描述、参数 Schema）。 - Agent 决策后，Client 发送
tools/call请求执行具体工具。 - Server 执行并返回结果。
📝 6. MCP vs LangChain 工具（面试高频对比）
| 对比维度 | LangChain 原生 @tool |
MCP 协议 |
|---|---|---|
| 紧耦合程度 | 高。工具直接写在 Python 代码里，随 Agent 启动而加载。 | 低。工具运行在独立进程中，Agent 通过网络或进程间通信调用。 |
| 跨语言支持 | 差。只能用 Python 写工具（如果用的是 Python LangChain）。 | 强。Server 可以用 Node.js、Java、Python 等任何语言编写。 |
| 动态发现 | 无。工具必须在代码中预先定义好。 | 有。Agent 启动时动态拉取工具列表，支持热更新。 |
| 隔离性 | 差。一个工具报错可能导致整个 Agent 崩溃。 | 好。Server 进程崩溃不影响主 Agent（除非主 Agent 强依赖它）。 |
| 适用场景 | 快速原型开发，简单的内部工具。 | 大型企业级应用，多团队协作，需要跨语言支持的生产环境。 |
💡 7. 总结（面试可以这样回答）
"MCP 是一个标准化的 AI 工具接入协议 。它通过在 Agent 和工具之间增加一个标准化的中间层，解决了以往工具集成'各自为政'、'高耦合'、'难以跨语言复用'的问题。在项目中，我通常用它来解耦 那些需要频繁变更或由其他语言团队维护的服务（比如一个 Node.js 编写的图像处理模块），我用 Python 的
MultiServerMCPClient作为客户端，通过 stdio 或 SSE 与这些独立的 MCP Server 通信，LangGraph 的 Agent 就能像使用本地函数一样调用它们，极大地降低了维护成本。"
一句话记住 MCP：它是 AI 领域的"USB-C"，让任何工具都能即插即用，打通了 AI 应用落地的"最后一公里"。
嵌入模型（Embedding Model） ，简单来说，是一台将"人类的语言"转换成"数学向量"的翻译机器 。它把文本、图像或音频转换成一组固定长度的数字列表（即向量），让计算机能够理解和比较这些内容的"语义"。
结合你之前学习的 RAG（检索增强生成）和向量数据库（Chroma / Milvus），嵌入模型就是那个负责把所有文字转化成坐标的核心部件。
🧠 1. 核心原理：语义即位置
嵌入模型基于深度学习（通常是 Transformer 架构），其核心思想是：语义越相近的文本，在向量空间中的距离就越近。
- "国王" - "男人" + "女人" ≈ "女王"：这是最经典的类比。嵌入模型通过大量语料学习，能够捕捉到这种深层的语言规律。
- 不是关键词匹配 ：它不依赖"是否包含相同词汇"，而是理解"意思是否相同"。
- "天气很热" 和 "今天温度很高" 这两个句子虽然没有一个字相同，但它们的向量在空间中是紧挨在一起的，这就是语义检索的基础。
🛠️ 2. 嵌入模型 vs. 大语言模型（LLM）
这是面试中经常混淆的点，务必区分清楚：
| 对比维度 | 嵌入模型 (Embedding Model) | 大语言模型 (LLM / 生成模型) |
|---|---|---|
| 核心任务 | 理解与匹配（判别式）。把内容转化成坐标，用于检索、聚类、推荐。 | 生成与创作（生成式）。根据上文预测下一个字，用于写作、对话、编程。 |
| 输入/输出 | 输入文本，输出固定长度的向量（例如 768 维的浮点数数组）。 | 输入文本，输出不定长的自然语言文本。 |
| 典型模型 | text-embedding-ada-002 (OpenAI)、BAAI/bge-large-zh (智源)、sentence-transformers/all-MiniLM-L6-v2。 |
GPT-4、Claude 3、Qwen-Plus、DeepSeek-V3。 |
| 参数量级 | 通常较小（几百万到几亿参数），推理速度极快。 | 通常极大（几十亿到上万亿参数），推理速度慢且昂贵。 |
| 在你的项目中的位置 | 在写入向量库前（Indexing）和用户提问时（Querying）使用。 | 在检索到资料后，负责阅读资料并生成最终回答。 |
一句话总结 ：嵌入模型决定"找得准不准"，大语言模型决定"答得好不好"。
🔍 3. 嵌入模型在 RAG 中的具体角色
结合你之前的代码，嵌入模型贯穿了 RAG 的整个流程：
-
离线阶段（数据入库）：
- 你加载 PDF 并切分成 Chunks。
- 调用嵌入模型（如
HuggingFaceEmbeddings）将每个 Chunk 变成向量。 - 将这些向量存入向量数据库（Chroma/Milvus）。
-
在线阶段（用户查询）：
- 用户提问。
- 调用同一个嵌入模型，将用户的问题也变成一个向量。
- 拿着这个向量去向量库里进行 相似度计算（如余弦相似度），找出离它最近的 Top-K 个 Chunks。
🎯 4. 如何选择嵌入模型（面试高频考点）
在你本地开发时，用的是 paraphrase-multilingual-MiniLM-L12-v2。而在生产环境中，可以按以下维度选择：
- 语言支持 ：如果处理纯中文，
BAAI/bge-large-zh或text-embedding-v3（阿里云）效果更好；处理多语言，可用multilingual-e5-large。 - 向量维度：维度越高（如 1024 维 vs 384 维），表达能力越强，但存储和计算开销也越大。
- 上下文长度 ：有些模型只能处理 512 个 token，有些（如
BGE-M3）能处理 8192 个，这对长文档分块很重要。 - Embedding 模型的"致命伤" ：它不知道"新鲜事"。比如 2026 年发生了新事件，如果你用 2023 年训练的嵌入模型去检索，它可能会找不到最相关的资料。解决方案是：用更强的模型微调，或使用支持混合检索（BM25 + 向量）的策略来兜底。
💡 5. 面试常见追问与回答话术
Q：既然 LLM 能理解文本，为什么不直接用 LLM 来做检索？
A：LLM 做一次推理耗时约 1~2 秒，成本约 $0.01；而嵌入模型算一次向量仅需 < 10ms，成本几乎为零。在 RAG 系统中，检索阶段要处理海量候选数据（百万级），必须依赖高效的嵌入模型。
Q：为什么每次都要用同一个嵌入模型？
A ：因为不同模型生成的向量空间分布不同。如果你用模型 A 给数据库做索引，却用模型 B 给用户提问做查询，那么"风和日丽"和"天气不错"在各自的向量空间中不兼容，会导致检索结果完全错误。必须保持模型版本一致。
Q：如何评估一个嵌入模型的好坏？
A ：主要看 MTEB（大规模文本嵌入基准测试） 排行榜。主要关注 检索（Retrieval） 任务的平均准确率（NDCG@10），以及在中文数据集（如 C-MTEB）上的表现。