Fubune's Wiki

本页面只读。您可以查看源文件，但不能更改它。如果您觉得这是系统错误，请联系管理员。
====== MCP ======

**MCP（Model Context Protocol，模型上下文协议）** 是一种用于标准化连接 [[AI Agent]]、[[LLM]] 与外部工具、数据源和服务的开放协议。它最初由 [[Anthropic]] 的 David Soria Parra 和 Justin Spahr-Summers 等人提出，并于 2024 年 11 月 25 日正式开源。其核心目标是解决 AI 应用与外部系统之间集成方式碎片化的问题，使模型能够通过统一协议访问工具和上下文。

MCP 可以类比为 **AI 应用的 USB-C 接口**：USB-C 让不同设备能够通过统一接口连接外设，而 MCP 则试图让不同的 AI 应用通过统一协议连接不同的工具和数据源。

截至 2026 年 7 月，MCP 已发展为面向 [[AI Agent]] 工作流的重要基础协议，最新规范为 **2026-07-28**。该版本进一步引入了无状态协议核心（stateless protocol core）、多轮请求、基于 HTTP Header 的路由、可缓存的列表结果以及更完善的授权和扩展机制。

===== 为什么需要 MCP =====

传统的 AI 应用如果需要调用外部系统，通常需要针对每一个模型、工具和数据源单独编写集成代码。

例如，一个 AI 应用需要访问：

* GitHub
* Google Drive
* PostgreSQL
* Slack
* 文件系统
* 搜索引擎
* 浏览器

如果没有统一协议，开发者需要为不同的 AI 应用分别实现这些接口。

可以抽象成：

模型 A → GitHub API
模型 A → 数据库 API
模型 A → 文件系统 API

模型 B → GitHub API
模型 B → 数据库 API
模型 B → 文件系统 API

随着模型和工具数量增加，集成数量迅速增长。

MCP 希望将这种结构变成：

AI 应用 → MCP → GitHub
AI 应用 → MCP → 数据库
AI 应用 → MCP → 文件系统
AI 应用 → MCP → 浏览器

因此，工具只需要实现一次 MCP Server，支持 MCP 的 AI 应用就可以使用它。

===== 提出与发展 =====

MCP 最初由 Anthropic 提出。

* **2024 年 11 月 25 日**：Anthropic 正式发布并开源 MCP。
* **2025 年**：MCP 快速扩展到 Claude、代码编辑器、AI Agent 平台以及各种企业软件。
* **2025 年 7 月**：MCP 建立正式治理机制，通过 Specification Enhancement Proposal（SEP）等方式推进协议演化。
* **2025 年 11 月**：发布 MCP 2025-11-25 规范，引入任务（Tasks）、更完善的授权、安全机制以及服务器端采样等能力。
* **2026 年 7 月 28 日**：发布 MCP 2026-07-28 规范，将协议核心进一步转向无状态请求/响应架构，并加入多轮请求、Header 路由、缓存列表结果、扩展框架等能力。

MCP 后来被捐赠给 Linux Foundation 下的 **Agentic AI Foundation（AAIF）**，使其进一步向中立、开放的行业基础设施发展。

===== 核心架构 =====

MCP 主要由 **Host、Client 和 Server** 三类角色组成。

**Host**

Host 是运行 AI 应用的宿主程序，例如 AI 编程助手、桌面 AI 应用或者其他 [[AI Agent]] 平台。

Host 通常负责：

* 管理模型
* 管理 MCP Client
* 控制用户权限
* 将 MCP 提供的信息和工具交给模型使用

**Client**

MCP Client 是 Host 中负责与某个 MCP Server 建立连接的组件。

通常一个 MCP Server 对应一个 MCP Client 连接。

例如：

AI Agent
→ MCP Client
→ GitHub MCP Server

**Server**

MCP Server 是外部能力的提供者。

它可以将某个数据源、API、程序或者服务封装成 MCP 接口。

例如：

GitHub MCP Server
数据库 MCP Server
文件系统 MCP Server
浏览器 MCP Server

因此，MCP Server 并不一定是一个远程服务器，也可以运行在用户本地。

===== MCP 的核心能力 =====

MCP 最重要的能力可以概括为：

**Tools、Resources、Prompts。**

==== Tools ====

**Tool（工具）** 是 MCP Server 提供给 AI 应用调用的可执行能力。

例如：

* 查询数据库
* 搜索 GitHub
* 创建文件
* 修改代码
* 发送消息
* 执行程序
* 调用第三方 API

模型可以根据 Tool 的描述决定是否调用它。

例如，一个 MCP Server 可以提供：

`search_code(query)`

模型首先理解用户任务，然后决定：

理解任务 → 发现可用 Tool → 选择 Tool → 生成参数 → 调用 Tool → 获取结果 → 继续推理

MCP 本身并不负责决定模型什么时候调用工具；模型或 AI Agent 的上层逻辑负责进行工具选择，而 MCP 负责标准化工具的描述、发现和调用过程。

==== Resources ====

**Resource（资源）** 用于向 AI 应用提供上下文数据。

例如：

* 文件
* 数据库记录
* 文档
* 配置
* 项目状态
* API 返回的数据

Resources 更接近“可以被读取的上下文”，而 Tools 更接近“可以执行的操作”。

可以简单理解为：

Tool → **做什么**

Resource → **有什么信息**

==== Prompts ====

**Prompt** 是 MCP Server 可以提供的提示模板或交互模板。

它允许服务器向客户端提供结构化的提示内容，从而帮助用户或 AI 应用按照特定方式使用某项能力。

因此，MCP 不只是简单的“工具调用协议”，而是同时定义了工具、资源和提示等能力。

===== Tool Calling =====

MCP 与 [[Function Calling]] 有密切关系，但二者并不是同一个概念。

Function Calling 通常描述：

LLM → 函数名称 + 参数

而 MCP 进一步标准化了：

AI 应用 → MCP Server → Tool Discovery → Tool Call → Tool Result

因此可以认为：

**Function Calling 解决“模型如何调用一个函数”，而 MCP 更关注“AI 应用如何以统一协议发现、连接和使用大量外部能力”。**

MCP Server 可以向客户端声明自己提供哪些 Tool，以及这些 Tool 所需要的参数结构。

===== 一个典型 MCP 工作流程 =====

用户：

“帮我分析 GitHub 项目中的 Bug。”

可能发生：

用户请求 → [[LLM]] 理解任务 → MCP Client 获取可用 Tools → 模型选择 GitHub Tool → MCP Client 调用 MCP Server → MCP Server 查询 GitHub → 返回结果 → LLM 分析结果 → 输出答案

因此 MCP 本身并不是模型。

它位于：

[[LLM]] / [[AI Agent]]
↓
MCP Client
↓
MCP Server
↓
外部工具 / 数据 / API

===== MCP 与 AI Agent =====

MCP 的重要意义之一，是它为 [[AI Agent]] 提供了统一的“工具层”。

一个 Agent 通常需要：

* 感知环境
* 获取信息
* 调用工具
* 执行动作
* 获取执行结果
* 根据结果继续规划

如果每一个工具都使用不同的 API，那么 Agent 系统会非常复杂。

MCP 将工具接口标准化以后，可以形成：

用户
↓
[[AI Agent]]
↓
[[LLM]]
↓
MCP
↓
工具 / 数据库 / 文件 / API / Web 服务
↓
执行结果
↓
Agent 继续推理

因此 MCP 可以看作现代 Agent 系统中的一种 **工具与上下文互操作层**。

===== MCP 与 RAG 的关系 =====

MCP 与 [[RAG]] 也容易混淆。

RAG 主要解决：

**如何从外部知识中检索相关信息并提供给模型。**

MCP 主要解决：

**AI 应用如何以统一协议连接外部数据和工具。**

因此 MCP Server 可以提供搜索、数据库查询等能力，从而实现 RAG，但 MCP 本身并不是 RAG 算法。

例如：

用户问题
↓
MCP Tool：搜索知识库
↓
返回相关文档
↓
LLM 生成答案

这里 MCP 负责连接，RAG 负责检索增强。

===== MCP 与 API 的关系 =====

MCP 不是 API 的替代品。

传统 API：

AI 应用 → API → 服务

MCP：

AI 应用 → MCP Client → MCP Server → API / 数据库 / 本地程序

因此 MCP 可以作为 API 之上的标准化适配层。

例如，一个 MCP Server 可以把 GitHub API 封装起来，让不同的 AI Agent 使用统一 MCP 接口访问 GitHub。

===== MCP 的传输与通信 =====

MCP 的早期实现主要支持本地进程之间的通信以及基于 HTTP 的远程通信。

随着协议发展，其通信模型也不断演化。

2026-07-28 规范的重要变化之一，是将 MCP 核心推进为 **stateless protocol core（无状态协议核心）**，更加适合部署在普通 HTTP 基础设施上。

这使 MCP 更适合：

* 云端部署
* Serverless
* 负载均衡
* 多实例部署
* 大规模 Agent 系统

===== MCP Server 的本质 =====

MCP Server 本质上可以看成一个“能力适配器”。

例如：

GitHub API
↓
GitHub MCP Server
↓
标准化 MCP Tools
↓
AI Agent

数据库：

PostgreSQL
↓
Database MCP Server
↓
标准化 MCP Tools
↓
AI Agent

因此 MCP 的价值并不主要来自某一个具体工具，而来自 **统一接口带来的互操作性**。

===== MCP 的优势 =====

**统一接口**

不同 AI 应用可以使用相同的协议连接外部能力。

**降低集成成本**

工具开发者不需要针对每个 AI 应用分别开发接口。

**工具生态**

一个 MCP Server 可以被多个 MCP Client 使用。

**适合 Agent**

Agent 可以动态发现和调用外部工具。

**可扩展**

MCP 可以通过协议扩展不断加入新的能力。

**开放标准**

MCP 并不要求使用某一家模型，可以由不同的 AI 应用实现。

===== MCP 的局限与问题 =====

MCP 并不会自动解决 Agent 的所有问题。

**工具选择问题**

当一个 Agent 面对数百甚至数千个 Tool 时，如何选择正确工具仍然是 [[LLM]] 的问题。

**上下文开销**

工具描述和工具返回结果都可能占用模型的 [[Context Window]]。

**安全问题**

MCP Server 可能拥有文件读写、数据库访问、代码执行等高权限能力，因此必须考虑：

* 权限控制
* 身份认证
* 授权
* 输入验证
* 沙箱
* Tool Injection
* Prompt Injection

**可靠性**

外部工具可能失败、超时或返回错误数据，因此 Agent 必须具备错误处理和重试能力。

===== MCP 与 AI 基础设施 =====

随着 [[LLM]] 从单纯的文本生成模型逐渐发展为能够使用工具、执行任务的 [[AI Agent]]，模型本身已经不再是完整系统。

一个现代 Agent 系统通常可以分成：

模型层 → [[LLM]]
推理层 → [[Reasoning]]
工具层 → MCP
数据层 → [[RAG]] / 数据库
执行层 → [[Computer Use]] / 代码执行
控制层 → Agent Loop

在这个结构中，MCP 更接近 **连接模型与外部世界的基础设施层**。

===== 意义 =====

MCP 最重要的意义并不是增加了某一个新的 AI 能力，而是尝试建立一个 **AI 与外部世界之间的通用接口标准**。

过去：

每个 Agent 都需要自己实现各种工具连接。

MCP：

工具提供者实现 MCP Server → 不同 Agent 可以复用。

因此 MCP 的长期价值类似于其他基础设施协议：

**标准化接口 → 降低集成成本 → 形成生态 → 提高互操作性。**

随着 [[AI Agent]] 成为越来越重要的 AI 软件形态，MCP 逐渐从 Anthropic 的一个开源项目发展成为 Agent 工具与数据连接的重要开放标准。

===== 相关条目 =====

* [[AI Agent]]
* [[LLM]]
* [[Function Calling]]
* [[Tool Use]]
* [[RAG]]
* [[Context Window]]
* [[Computer Use]]
* [[OpenAI]]

===== 参考资料 =====

* Anthropic, 2024, *Introducing the Model Context Protocol*
* Model Context Protocol, 2026-07-28 Specification
* Model Context Protocol Blog, *The 2026-07-28 Specification*
* Anthropic, *Model Context Protocol Documentation*
* Model Context Protocol Blog, *Building to Last: A New Governance Model for MCP*