一、 为什么我们需要 MCP？（背景与痛点）

在 MCP 出现之前，我们主要使用 Function Call 让大模型调用工具。但这在工具数量激增时，面临着“硬编码模式”的四大崩溃点：

1. 维护累：成百上千行的 JSON Schema 需要手写。一旦参数变更，代码和 Schema 极易不同步，导致线上故障。

2. 复用难：语言墙厚重。Python 写的工具 Java 调不了，跨语言调用需要重复造轮子。

3. 发现慢：工具藏在全是 if-else 的代码里，新人和模型都不知道系统到底有哪些能力。

4. 扩展差：每加一个工具就要改代码、重启服务，开发效率极低。

MCP 的核心价值

MCP 就像 AI 世界的 USB-C 接口。任何工具只要实现了 MCP 协议，就能被任何支持 MCP 的客户端调用，无需关心对方是什么语言、什么平台。它解决了“如何管理成百上千个工具”的问题，将工具定义从客户端转移到了服务端。

二、 MCP 的三层架构

MCP 采用客户端-服务器架构，清晰地定义了参与者的职责。

1. Host（宿主应用）

   1. 定义：用户直接交互的应用，内部包含 MCP Client。

   2. 例子：Claude Desktop、Cursor IDE、企业知识库助手（如 Ragent）。

   3. 职责：接收用户输入 → 调用大模型 → 根据模型指令通过 MCP Client 调用工具 → 返回最终答案。

2. Client（MCP 客户端）

   1. 定义：Host 内部的通信组件。

   2. 职责：

      • 与 Server 建立连接（Stdio 或 HTTP）。

      • 动态发现 Server 提供的工具列表。

      • 调用工具并获取结果。

      • 管理连接生命周期（初始化、握手、关闭）。

3. Server（MCP 服务端）

   1. 定义：提供工具的一方，暴露一组工具接口。

   2. 形式：可以是本地进程（Stdio 通信）或远程 HTTP 服务。

   3. 职责：

      • 声明工具元数据（名称、描述、JSON Schema）。

      • 接收请求，执行逻辑，返回结果。

一个完整的调用流程

用户在 RAG Desktop 里问：查下我的年假，顺便看周五有没有会。完整的调用流程是这样的：

四、 MCP 的三大核心能力

1. Tools（工具调用）

   1. 核心：Server 定义，Client 发现并调用。

   2. 区别：Function Call 的工具定义在客户端代码里（手写 Schema）；MCP 的工具定义在 Server 端，Client 动态获取。这实现了真正的解耦。

2. Resources（资源访问）

   1. 定义：类似 REST API 的 GET 请求，用于提供上下文数据。

   2. 场景：读取文件内容、数据库记录、系统日志等只读数据。

3. Prompts（提示词模板）

   1. 定义：Server 可以向 Client 提供预定义的提示词模板。

   2. 场景：规范模型与用户的交互方式，例如“代码审查”或“写测试用例”的标准化提示。

五：传输机制：Client 与 Server 如何通信

MCP 抽象了底层通信细节，主要支持两种传输方式：

1. Stdio（标准输入输出）

   1. 场景：本地工具、CLI 集成。

   2. 原理：Server 作为 Host 的子进程启动。Host 通过 stdin 写入 JSON-RPC 请求，读取 stdout 获取响应。

   3. 优势：简单、低延迟，适合本地文件操作或脚本。

2. Streamable HTTP（可流式 HTTP）

   1. 场景：远程服务、企业级部署。

   2. 原理：Server 作为 HTTP 服务运行。Client 发送 POST 请求。

   3. 优势：支持跨网络调用，支持 SSE（Server-Sent Events）进行流式推送（如进度条通知、长任务结果）。

实战：MCP 在 RAG 系统中的演进

在传统的 RAG 系统中，知识检索通常是硬编码在逻辑里的。引入 MCP 后，RAG 系统发生了质变：

1. 知识检索 MCP 化

   1. 将知识检索能力封装为一个标准的 MCP 工具（search_knowledge_base）。

   2. 效果：知识检索不再局限于特定系统，任何支持 MCP 的客户端（如 Claude Desktop、IDE 插件）都能直接调用企业的知识库。

2. 多工具智能编排

   1. 场景：用户问“查下这个报错怎么处理，并帮我提个工单”。

   2. 流程：

      • LLM 首先调用 MCP 工具 search_knowledge_base 检索故障排查文档。

      • 获取解决方案后，LLM 接着调用 MCP 工具 create_ticket 发起流程。

   3. 优势：模型自动判断何时查知识库，何时调业务 API，实现了“问答 + 操作”的闭环。